Une demande de suppression vient d'arriver. Et maintenant ?

Publier la page de suppression est la partie dont tout le monde parle. Ce qui se passe une fois que quelqu’un l’utilise est la partie qui détermine si vous êtes réellement en conformité — et c’est une question de processus, pas d’hébergement.

Où les demandes doivent-elles arriver ?

Là où un humain les voit en quelques jours, pas dans une boîte de réception que vous consultez quand quelque chose casse.

Le mode d’échec est précis et courant : une page recueille les demandes dans une boîte aux lettres que personne ne lit, ou un service de formulaires dont les e-mails de notification finissent en spam. L’utilisateur croit que sa demande est passée. Juridiquement, vous êtes désormais en infraction avec un délai dont vous ignorez qu’il court.

Règles pratiques :

• Pas une adresse personnelle que vous risquez d’abandonner. Les e-mails de support venant d’une fiche du store arrivent par vagues — rien pendant des mois, puis une série.
• Un endroit avec une notification impossible à manquer. Pour un développeur solo, c’est souvent un canal de discussion plutôt que l’e-mail, précisément parce que l’e-mail est l’endroit où les choses sont ignorées.
• Plus d’une voie si possible. Si un canal tombe en panne sans bruit, vous en voulez un second.
• Testez-le. Déposez une demande via votre propre page publique et vérifiez qu’elle vous parvient. Recommencez après toute modification de la page.

De combien de temps disposez-vous ?

Si certains de vos utilisateurs sont dans l’UE ou au Royaume-Uni, le délai du RGPD s’applique. L’article 12(3) exige une réponse dans les meilleurs délais et en tout état de cause dans un délai d’un mois à compter de la réception. Pour les demandes réellement complexes, ce délai peut être prolongé de deux mois supplémentaires — mais vous devez informer la personne de cette prolongation dans le premier mois.

Deux détails que les développeurs manquent régulièrement :

• « Nous avons bien reçu votre demande » n’est pas une réponse. Lorsque vous donnez suite à une demande d’effacement, vous confirmez que l’effacement a été effectué et ce qui a été supprimé.
• Si vous refusez, vous devez quand même répondre — dans le mois, avec vos motifs, en indiquant à la personne qu’elle peut introduire une réclamation auprès d’une autorité de contrôle ou former un recours juridictionnel.

D’autres régimes ont leurs propres délais. Si vous avez des utilisateurs en Californie, au Brésil ou ailleurs avec des lois similaires, vérifiez celle qui s’applique plutôt que de supposer qu’un mois vous couvre partout.

Qu’est-ce qui doit réellement être supprimé ?

Le compte et les données personnelles qui s’y rattachent — et pas seulement dans votre propre base de données :

Où se trouvent les données	Ce que vous faites
Votre base de données principale	Supprimer, pas faire une suppression logique puis oublier
Sauvegardes	Indiquer honnêtement dans votre politique combien de temps les sauvegardes persistent et qu’elles expirent
Analytics / rapports de plantages	Utiliser l’API de suppression de l’éditeur lui-même quand il y en a une
Outils d’e-mailing ou CRM	Retirer des listes vers lesquelles vous les avez exportées
Sous-traitants et sous-traitants ultérieurs	Leur demander de supprimer, et relancer — c’est votre obligation, pas la leur
Journaux	Fixer une durée de conservation et l’appliquer

Si votre app s’appuie sur des prestataires pour traiter les données des utilisateurs, les supprimer de vos propres serveurs ne fait que la moitié du travail — vous devez aussi demander au prestataire d’en faire autant.

Que pouvez-vous conserver ?

Certaines choses, pour des raisons énoncées. Les plus courantes :

• Les données de facturation et fiscales, généralement conservées plusieurs années en vertu de la loi.
• Une trace de la suppression elle-même — vous devez pouvoir montrer qu’elle a eu lieu.
• Des marqueurs de fraude ou d’abus, lorsque vous avez un motif légitime et l’avez indiqué.
• Des agrégats anonymisés, s’ils ne permettent réellement pas de réidentifier quiconque.

Indiquez lesquels s’appliquent dans votre politique de confidentialité, avec la durée de conservation, avant que quelqu’un ne le demande. Le décider au moment de la demande, c’est ainsi qu’on finit soit par trop promettre, soit par improviser.

Que doit dire la réponse ?

Courte, précise, datée :

Nous avons reçu votre demande de suppression le 3 mars. Votre compte et les données personnelles qui y sont associées ont été supprimés. Nous avons conservé vos factures, que nous sommes tenus de garder sept ans à des fins fiscales, ainsi qu’une trace de cette demande. Rien d’autre ne subsiste.

C’est une réponse conforme. « C’est fait ✅ » ne l’est pas, car cela ne confirme rien.

Gardez le registre

Quel que soit le volume, tenez un registre : qui a demandé, quand, ce que vous avez supprimé, ce que vous avez conservé et pourquoi, quand vous avez répondu. « Nous l’avons supprimé » est une affirmation ; une liste datée est une preuve — et c’est une preuve que demande un régulateur, bien après que vous avez oublié la demande.

C’est aussi la raison de conserver les demandes dans un endroit structuré plutôt que sous forme d’e-mails épars. Un dossier de réponses n’est pas un registre.

Une réserve sur tout ce qui précède

Cette page décrit un processus, pas vos obligations légales. Les régimes qui s’appliquent à vous dépendent de l’endroit où se trouvent vos utilisateurs et de ce que fait votre app, les délais et les exemptions diffèrent de l’un à l’autre, et les durées de conservation de l’exemple de réponse sont illustratives, pas un chiffre à recopier. Si vous traitez des demandes de suppression en quelque volume que ce soit, ou si votre app touche aux données de santé, à la finance ou aux enfants, l’heure d’avocat qui transforme ceci en votre propre procédure écrite en vaut la peine.

Ce que fait AppFoyer ici

Nous hébergeons la page, enregistrons la demande comme votre piste d’audit, et vous prévenons sur les canaux que vous avez configurés — par e-mail avec n’importe quelle formule, par Telegram ou Slack avec une formule payante, via notre propre bot et notre propre app plutôt qu’avec des identifiants à vous. Le tableau de bord conserve chaque demande avec un flux done → archive → delete (traité → archivé → supprimé), si bien que le registre décrit plus haut est quelque chose que vous avez déjà, pas quelque chose à construire.

Deux choses que nous ne faisons pas, et ne prétendrons pas faire : nous ne contactons jamais l’utilisateur final, et nous ne supprimons jamais rien dans vos systèmes — nous n’y avons pas accès. La suppression, la réponse et les décisions de conservation vous appartiennent. C’est ce que l’exigence vous demande réellement, et aucune page hébergée ne peut s’y substituer.

Les sources qui font foi

• Comprendre les exigences de Google Play en matière de suppression de compte — Aide Google Play
• Droit à l’effacement — l’Information Commissioner’s Office du Royaume-Uni, les consignes d’un régulateur
• Article 12 du RGPD et article 17 — le délai et le droit lui-même