Aller au contenu
AppFoyer
Commencer

Guides Politique de confidentialité

L'URL de politique de confidentialité dont une app Android a besoin

Où va l'URL, ce que la politique doit couvrir, et le piège des SDK qui attrape les développeurs persuadés que leur app ne collecte rien.

Les deux stores exigent une URL de politique de confidentialité accessible publiquement, qui se charge sans connexion. Sur Google Play, elle se renseigne sous App content → Privacy policy ; chez Apple, c'est un champ d'App Store Connect. Le plus dur n'est pas l'URL mais le contenu : il doit couvrir ce que collecte chaque SDK de votre build.

1:03
Vidéo de 1:03 · s'ouvre sur YouTube

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.

Commencer gratuitement Voir un exemple en ligne

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.

Les deux stores veulent une URL publiquement accessible pour votre politique de confidentialité, et les deux la vérifient. Côté Google Play, la politique User Data le dit clairement — « all apps must post a privacy policy link in the designated field within Play Console, and a privacy policy link or text within the app itself » (toutes les apps doivent publier un lien vers une politique de confidentialité dans le champ prévu de la Play Console, ainsi qu’un lien ou un texte de politique de confidentialité dans l’app elle-même) — et ce champ se trouve sous App content → Privacy policy. Côté Apple, c’est un champ obligatoire d’App Store Connect. La page doit se charger sans connexion, nommer votre app et votre société, décrire ce que collectent l’app et tout ce qu’elle contient, et fonctionner encore des mois plus tard — une fiche est vérifiée plus d’une fois.

L’exigence n’est pas difficile. Ce qui piège les gens, c’est le troisième point de cette liste, et il mérite le reste de cette page.

« Mais mon app ne collecte rien »

C’est l’hypothèse qui coûte une semaine.

Votre code ne collecte peut-être rien. Vos dépendances, presque certainement si. Un outil de rapports de plantage envoie des identifiants d’appareil et des stack traces. Un SDK d’analytics envoie des événements et un identifiant publicitaire. Un SDK publicitaire envoie beaucoup de choses. Une bibliothèque de push enregistre un token qui est, par définition, lié à un appareil.

La vraie question n’est donc pas « qu’est-ce que je collecte » mais « qu’est-ce que tout ce qui se trouve dans mon build collecte ». Ouvrez votre fichier de dépendances et parcourez-le ligne par ligne — cette liste est la substance de votre politique de confidentialité, et c’est ce qu’un reviewer compare à vos réponses Data safety.

Quand les deux divergent, le store croit le SDK.

Ce que la politique doit couvrir

Au minimum, dans un langage qu’une personne peut lire :

  • Ce qui est collecté — des catégories, pas un schéma de base de données.
  • Pourquoi — la finalité de chaque catégorie.
  • Qui d’autre y a accès — nommez les tiers. C’est là que va votre liste de SDK.
  • Combien de temps les données sont conservées.
  • Comment vous contacter, et comment demander la suppression.

Si vous avez des utilisateurs dans l’UE, au Royaume-Uni, en Californie ou au Brésil, chaque régime attend des éléments spécifiques. Cette page ne peut pas vous dire lesquels s’appliquent à vous — cela dépend réellement de vos utilisateurs et de votre activité, et une heure d’avocat vaut la peine si quoi que ce soit dans votre app sort de l’ordinaire.

Ce qui fait concrètement rejeter la page

  • Une URL qui exige une connexion, ou qui est bloquée dans certaines régions.
  • Un PDF ou un Google Doc. Parfois accepté, souvent non, et cela fait improvisé.
  • Une politique qui nomme une autre app ou une autre société — le signe du copier-coller. Les reviewers le remarquent.
  • Une politique qui contredit votre formulaire Data safety. Les deux sont lus ensemble.
  • Un lien mort. Six mois après le lancement, l’hébergeur gratuit que vous utilisiez a disparu.

Est-ce que ça doit coûter de l’argent ?

Non. Une politique de confidentialité, c’est du texte sur une page ; ce qui coûte de l’argent, c’est un domaine, un endroit pour l’héberger qui existera encore l’an prochain, et le temps d’écrire quelque chose qui correspond à votre app réelle.

Méfiez-vous des générateurs facturés par app et par mois. Ce que vous louez, c’est un modèle — vérifiez ce que devient votre URL quand vous arrêtez de payer, car une URL de confidentialité qui tombe alors qu’elle figure dans une fiche en ligne sur le store est un problème dont vous entendrez parler par le store, pas par le fournisseur.

Ce que fait AppFoyer

Nous générons la politique à partir des SDK trouvés dans vos fichiers de build — avec un agent de code qui lit le dépôt, ou à partir d’un court formulaire — et nous l’hébergeons sur son propre sous-domaine. La checklist continue de vous avertir tant que vous n’avez pas remplacé le texte provisoire à l’endroit où vos tiers sont nommés, car c’est la partie qu’un reviewer lit vraiment.

Les modèles sont un point de départ, pas un conseil juridique, et chaque page générée le dit.

Les sources de référence