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.

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 :

Pièges courants

La plupart des échecs sont opérationnels, non juridiques. Méfiez-vous de ce qui suit :

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

← Blog Tout lire →