L'URL de suppression de compte que demande Google Play
La Play Console demande une URL web publique (App content → Data deletion). Ce que la page doit permettre sans connexion, et les erreurs qui font renvoyer une soumission.
Google Play demande aux apps avec comptes deux voies de suppression : une dans l'app, et une URL web publique où la même demande peut être faite sans se connecter ni réinstaller. Vous déclarez l'URL web sous App content → Data deletion. La page recueille la demande ; supprimer les données dans vos propres systèmes reste votre affaire.
Faites-le plutôt en quelques minutes
AppFoyer héberge les pages dont parle ce guide — politique de confidentialité, conditions, support, suppression de compte et app-ads.txt — sur leur propre sous-domaine, sans domaine ni serveur à vous. Une app est gratuite, et rien de ce qu'exige un store n'est jamais payant.
Vérifié le 19 septembre 2026. Les règles des stores changent, parfois sans préavis. Tout ce qui suit renvoie à la documentation officielle, et c'est elle — pas cette page — qui fait autorité. Si les deux se contredisent, c'est le store qui a raison. Ce guide est traduit de l'anglais ; les citations de la documentation des stores restent en anglais, dans leur version originale.
Si votre app permet de créer un compte, Google Play demande deux voies pour le supprimer : une dans l’app, et une URL web accessible publiquement où la même demande peut être faite. Vous déclarez l’URL web dans la Play Console sous App content → Data deletion (Contenu de l’app → Suppression des données), et l’aide Google Play indique qu’elle “must be functional (for example, loads without error), relevant in scope” (traduction : doit être fonctionnelle — par exemple se charger sans erreur — et pertinente quant à son périmètre). Quelqu’un qui a déjà désinstallé l’app doit pouvoir l’utiliser.
Voilà l’exigence en un paragraphe. Le reste de cette page porte sur ce que la page elle-même doit faire, et sur les erreurs qui font renvoyer une soumission.
Deux choses sont demandées ici, et on les confond facilement :
- Une page publique où une demande peut être déposée.
- La suppression effective des données dans vos propres systèmes quand une demande arrive.
La première est un problème d’hébergement. La seconde ne relève que de vous, et aucun service ne peut la faire à votre place — quiconque affirme le contraire n’a pas accès à votre base de données.
Ce que la page doit permettre à l’utilisateur
L’exigence est écrite du point de vue de l’utilisateur, alors lisez-la de ce point de vue. Quelqu’un qui a désinstallé votre app, oublié son mot de passe, ou n’en a jamais eu, doit quand même pouvoir atteindre la page et vous demander de supprimer son compte.
Cela exclut certaines configurations courantes :
- Une page derrière une connexion. Si l’utilisateur doit se connecter pour demander la suppression, ceux qui en ont le plus besoin ne peuvent pas l’utiliser.
- Uniquement un chemin dans l’app. La voie dans l’app est obligatoire aussi, mais elle ne remplace pas l’URL web : celle-ci est accessible depuis la fiche du store, par quelqu’un qui n’a plus l’app.
- Une URL qui renvoie une erreur 404. C’est celle qui se fait réellement repérer, parce que c’est trivial à vérifier.
La page doit dire quelles données sont supprimées, ce qui est conservé et pendant combien de temps (les données de facturation doivent souvent être conservées en vertu de la loi), et combien de temps prend la suppression.
Là où l’on se trompe : recevoir la demande
Une page qui affiche un formulaire ne suffit pas à elle seule — la demande doit vous parvenir.
C’est la seule partie qu’un simple hébergeur de fichiers ne sait pas faire seul. GitHub Pages, un bucket derrière un CDN : ils servent des fichiers, ils ne peuvent pas recevoir un POST. La plupart des hébergeurs qu’un développeur choisirait vraiment règlent la question — Cloudflare Workers, les fonctions Netlify et Vercel, Netlify Forms — c’est donc un travail de câblage, pas un mur. Mais il faut que quelque chose reçoive la demande, et la solution maison habituelle aboutit à l’un de ces quatre résultats :
- une adresse e-mail affichée sur la page, sans rien pour empêcher qu’elle soit aspirée ;
- un service de formulaires tiers, qui voit désormais les adresses e-mail de vos utilisateurs ;
- une fonction edge chez votre hébergeur, quelques lignes seulement, mais désormais du code que vous maintenez pour chaque app ;
- un petit serveur à garder en marche pour peut-être deux demandes par an.
Quelle que soit l’option choisie, choisissez-la délibérément. Une page de suppression qui perd des demandes sans rien dire est pire que pas de page du tout : vous dites à un utilisateur que sa demande a été reçue.
Gardez une trace
Quoi que vous construisiez, tenez un registre des demandes : l’adresse, la date, ce que vous avez fait. Si un régulateur ou un store vous le demande un jour, « nous l’avons supprimé » est une affirmation, et une liste datée est une preuve.
Ce que fait AppFoyer ici
Nous hébergeons la page et relayons la demande. Un utilisateur la dépose, nous l’enregistrons comme votre piste d’audit, et nous vous prévenons — par e-mail avec n’importe quelle offre, ou par Telegram ou Slack avec une offre payante. C’est vous qui faites la suppression dans vos propres systèmes — nous n’y avons pas accès, et nous ne prétendons jamais le contraire.
Cette page reste en ligne même si vous arrêtez de nous payer, car vos utilisateurs n’y sont pour rien.
La source qui fait foi
- Fournir des informations sur la suppression des données — Aide Google Play. Lisez-la avant de soumettre ; c’est cette page qui décide, pas celle-ci.