Demandes d'accès des personnes concernées (DSAR) au titre du RGPD : un manuel pour éditeurs mobiles
Ce qu'est réellement une DSAR
Une demande d'accès d'une personne concernée (DSAR) est le moment où un utilisateur exerce les droits que le RGPD lui accorde sur ses données personnelles. Pour un éditeur mobile, cette « personne concernée » est l'un de vos joueurs ou utilisateurs, et la demande peut arriver par e-mail, ticket d'assistance, avis sur la boutique d'applications ou formulaire intégré à l'application. Le déclencheur est simple : quelqu'un veut savoir ce que vous détenez à son sujet — ou veut que vous agissiez en conséquence.
Point crucial : une DSAR n'a pas besoin de mentionner le RGPD, d'employer le mot « DSAR » ni de suivre un quelconque modèle. Un message d'une ligne comme « envoyez-moi mes données » ou « supprimez mon compte » déclenche le chronomètre tout aussi sûrement qu'une lettre juridique formelle. Ne traiter comme valides que les demandes d'apparence officielle est un moyen rapide de manquer un délai.
Les droits derrière la demande
Les DSAR regroupent plusieurs droits distincts, et un même message peut en invoquer plusieurs. Savoir lequel est lequel détermine ce que vous devez réellement faire.
- Accès — l'utilisateur peut demander une copie de ses données personnelles ainsi que le contexte : ce que vous collectez, pourquoi, avec qui vous le partagez et combien de temps vous le conservez.
- Effacement (« droit à l'oubli ») — suppression de ses données, y compris les copies transmises aux partenaires publicitaires et d'analyse, sous réserve d'exceptions juridiques étroites.
- Portabilité — les données qu'il vous a fournies, restituées dans un format structuré et lisible par machine tel que JSON ou CSV afin de pouvoir être transférées ailleurs.
- Rectification — correction de données inexactes ou incomplètes, par exemple un e-mail ou une région erronés.
Des droits connexes — l'opposition au traitement et la limitation — accompagnent souvent ces derniers, notamment autour de la personnalisation publicitaire où un utilisateur peut retirer son consentement plutôt que de supprimer purement et simplement son compte.
Les délais sont stricts
Vous devez répondre sans retard injustifié et dans un délai d'un mois calendaire à compter de la réception de la demande. Le chronomètre démarre le jour où la demande arrive, et non le jour où quelqu'un dans votre équipe la remarque. Vous pouvez prolonger de deux mois supplémentaires pour les demandes véritablement complexes, mais seulement si vous en informez l'utilisateur dans ce premier mois et en expliquez la raison.
Les réponses sont normalement gratuites. Vous ne pouvez facturer des frais raisonnables ou refuser que lorsqu'une demande est manifestement infondée ou excessive, et la charge d'en apporter la preuve vous incombe. Pour la plupart des éditeurs, l'hypothèse sûre est : gratuit et dans les trente jours. Manquer ce délai est exactement le type de défaillance que les régulateurs pointent du doigt lorsqu'ils évaluent les amendes.
Construire un flux de travail qui passe à l'échelle
Les éditeurs qui gèrent les DSAR avec sérénité en ont fait un processus reproductible plutôt qu'une mobilisation d'urgence. Un flux de travail viable ressemble à ceci :
- Réception. Publiez un canal unique et annoncé — un formulaire intégré à l'application ou une adresse privacy@ dédiée — et acheminez tout par celui-ci afin que rien ne se perde dans les files d'assistance.
- Vérifier l'identité. Confirmez que le demandeur est bien le titulaire du compte, mais ne demandez que ce dont vous avez besoin. Exiger un scan de passeport pour retrouver un identifiant de jeu constitue en soi un problème de conformité.
- Journaliser et horodater. Enregistrez immédiatement la date d'arrivée ; c'est le point d'ancrage de votre délai.
- Localiser les données. Tenez à jour une cartographie des données de chaque entrepôt — votre backend, les journaux de plantage, l'analytique, les SDK publicitaires, le CRM — qui touche aux données utilisateur, indexée par un identifiant stable.
- Traiter & répondre. Exportez, supprimez ou corrigez selon la demande, propagez les suppressions aux sous-traitants et répondez dans un langage clair.
- Boucler la boucle. Archivez la demande et votre réponse comme preuve que vous avez agi dans les délais.
Pièges courants
La plupart des échecs sont opérationnels, non juridiques. Méfiez-vous de ce qui suit :
- Entrepôts de données oubliés. Les SDK publicitaires et d'attribution, les fournisseurs de notifications push et les rapporteurs de plantage détiennent tous des données utilisateur. Une suppression qui les omet est incomplète.
- Sur-collecte lors de la vérification, transformant une demande de confidentialité en risque pour la confidentialité.
- Traiter les messages informels comme des non-demandes et laisser le mois s'écouler.
- Aucune preuve de consentement. Si un utilisateur conteste que vous ayez jamais eu une base légale pour traiter ses données à des fins publicitaires, vous devez montrer ce qu'il a accepté et quand.
Comment une CMP rend les DSAR gérables
C'est ici que votre couche de consentement prouve sa valeur. Une DSAR est bien plus facile à traiter lorsque vous pouvez montrer instantanément ce à quoi un utilisateur a consenti, quand et sous quel cadre. FlexyConsent — une CMP certifiée par Google prenant en charge l'IAB TCF 2.3 et Google Consent Mode v2 — stocke un enregistrement de consentement et une piste d'audit horodatés pour chaque utilisateur. Lorsqu'une demande d'accès arrive, cet enregistrement devient un élément tout prêt de votre réponse : les finalités acceptées, les fournisseurs concernés et la version de la notice affichée. Lorsqu'une demande d'effacement ou d'opposition arrive, le même enregistrement prouve que vous avez arrêté les signaux publicitaires personnalisés au bon moment. Associer cet historique de consentement à votre cartographie des données transforme une DSAR d'une course effrénée en une simple recherche.
Cet article constitue une information générale destinée aux éditeurs et ne constitue pas un conseil juridique ; consultez un professionnel qualifié pour votre situation spécifique.
Points clés à retenir
- Toute demande — aussi informelle soit-elle — peut être une DSAR, et le délai d'un mois, généralement gratuit, démarre le jour où elle arrive.
- Cartographiez chaque entrepôt de données, y compris les SDK publicitaires et d'analyse, afin que l'accès et la suppression soient réellement complets.
- Vérifiez l'identité de manière proportionnée et journalisez chaque demande pour prouver que vous avez répondu dans les délais.
- Les enregistrements de consentement et la piste d'audit de FlexyConsent vous fournissent une preuve instantanée et défendable pour traiter les demandes d'accès, d'effacement et d'opposition.