Garder la conformité en ordre sur dix apps
Ce qui doit être propre à chaque app, ce qui peut être partagé, les deux erreurs des portefeuilles, et le registre qui change une panique annuelle en après-midi.
Le travail n'évolue pas de façon linéaire — chaque app a besoin de ses propres URL, de son propre parcours de suppression et de ses propres déclarations, parce que chacune a sa propre fiche. Ce qui passe à l'échelle, c'est la méthode : un schéma de noms d'hôte, un modèle par type de page, et une liste de dépendances par app que vous régénérez plutôt que de la mémoriser.
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.
Une app, c’est une liste de contrôle. Dix apps, c’est un système, et le mode de défaillance change : rien n’est difficile, mais il y a toujours quelque chose de légèrement obsolète, et vous l’apprenez par un rejet sur l’app que vous avez touchée le moins récemment.
Ce qui doit être propre à chaque app
Non négociable, parce que chaque app a sa propre fiche et son propre comportement vis-à-vis des données :
- La politique de confidentialité. Des ensembles de SDK différents impliquent des déclarations différentes. Une politique partagée couvrant « nos apps » est l’erreur classique des portefeuilles — voir plus bas.
- La page de suppression de compte, et un parcours qui vous parvient, pour chaque app.
- Les déclarations Data safety et App Privacy. Remplies par fiche, à partir de la liste de dépendances de cette app.
app-ads.txt, si l’app affiche des annonces — il est localisé via le site web indiqué dans la fiche de cette app.- Les URL elles-mêmes, parce que chaque fiche a ses propres champs.
Ce qui peut réellement être partagé
- Le modèle. Une structure pour toutes les politiques de confidentialité, une pour les conditions, remplie par app.
- Le schéma de noms d’hôte. Une adresse prévisible par app vaut mieux qu’un dossier d’URL improvisées.
- L’adresse de support, si une seule boîte de réception les sert vraiment toutes.
- Votre connaissance des SDK. Ce que collecte Crashlytics ou AdMob est le même fait dans chaque app ; seules diffèrent les apps qui les incluent.
- Le processus — la liste de contrôle de version, le rythme de revue, le registre ci-dessous.
Les deux erreurs des portefeuilles
Une seule politique pour toutes les apps. C’est l’économie évidente, et elle échoue dans les deux sens : la politique liste des données que la petite app utilitaire ne touche jamais, et oublie quelque chose que la dernière app a ajouté le mois dernier. Dans les deux cas, cela contredit un formulaire Data safety rempli honnêtement, et un examinateur qui compare les deux voit une politique qui ne parle pas de cette app.
Une boîte de suppression partagée que personne n’attribue. Des demandes arrivent disant « merci de supprimer mon compte » sans indiquer de laquelle de vos dix apps il s’agit. Vous ne pouvez pas traiter ce que vous ne pouvez pas identifier, et le délai du RGPD court pendant que vous cherchez. Acheminez les demandes de chaque app de façon que l’app soit évidente dans la notification.
Le registre
Ce qui rend un portefeuille gérable, c’est un seul tableau que vous tenez réellement à jour — un tableur suffit. Une ligne par app, et ces colonnes :
| Colonne | Pourquoi |
|---|---|
| Nom de l’app, bundle id / application id | Identité |
| Boutiques où elle est listée | Détermine le nombre de consoles à mettre à jour |
| URL de la politique de confidentialité | Celle que vous collez et recollez |
| URL de suppression de compte | Idem |
| Adresse / page de support | Idem |
| Site web du développeur déclaré | Où app-ads.txt est recherché |
| Affiche des annonces ? | Si app-ads.txt s’applique tout court |
| A des comptes ? | Si la suppression s’applique tout court |
| SDK principaux | La liste de dépendances, en résumé |
| Dernière revue de la politique | La date qui vous dit ce qui est obsolète |
La dernière colonne est celle qui justifie sa place. Les deux boutiques exigent que les déclarations restent exactes — pas seulement qu’elles l’aient été au lancement — et « dernière revue » est le moyen de trouver les trois apps qui ont dérivé sans relire les dix.
Un rythme qui fonctionne
- À chaque version, pour chaque app : une dépendance a-t-elle changé ? Si oui, revérifiez la politique de cette app et les deux formulaires de données. Mettez-le dans la liste de contrôle de version, pas dans votre mémoire.
- Chaque trimestre, sur tout le portefeuille : ouvrez le registre, triez par « dernière revue », vérifiez les quelques plus anciennes. Confirmez que chaque URL renvoie toujours 200 sans connexion.
- Chaque fois qu’une URL change : mettez à jour chaque console pour chaque app concernée, et gardez l’ancienne adresse en redirection. Avec dix apps, c’est le changement le plus susceptible d’être fait aux neuf dixièmes.
Un script de dix lignes qui lance curl sur chaque URL du registre et signale les réponses autres que 200 représente un après-midi de travail et attrape la défaillance qui se produit réellement — un hébergeur qui a disparu sans bruit.
Ce que fait AppFoyer
Chaque app est une app à part entière : son propre sous-domaine, ses cinq pages, son propre
app-ads.txt, ses propres canaux de notification, sa propre liste de contrôle. Il n’y a pas de
politique partagée à rater, et les demandes de suppression de chaque app arrivent identifiées par app.
La liste de contrôle du tableau de bord est la moitié vivante du registre — pour chaque app, elle indique quel champ de boutique est encore vide et pourquoi cela compte, de sorte que « ce qui est obsolète » est un écran plutôt qu’une colonne de tableur que vous avez oublié de mettre à jour. Les forfaits diffèrent par le nombre d’apps que vous pouvez publier : une sur Free, dix sur Pro, cinquante sur Advanced.
Soyons francs sur les limites : la modification groupée et les groupes d’apps n’existent pas encore. Ajouter une ligne de réseau publicitaire à quinze apps, c’est aujourd’hui quinze modifications. Ce travail est prévu et n’est pas livré, et une page qui vous vend un outil de portefeuille devrait dire ce qui en est réel.
Les sources qui font foi
- Provide information for Google Play’s Data safety section — Aide Google Play Console, sur le maintien de l’exactitude des déclarations
- App privacy details on the App Store — Apple, sur la mise à jour des réponses
- Set up app-ads.txt — Aide AdMob