Garder votre politique de confidentialité en phase avec votre build

Rédiger une politique de confidentialité est un travail ponctuel. La garder exacte ne l’est pas : la politique décrit le build que vous aviez quand vous l’avez écrite, et le build ne cesse de changer. Une pull request ajoute du rapport de plantages, une bibliothèque d’abonnements ou une permission de localisation, l’app est publiée, et la politique, le formulaire Data safety et les App Privacy details décrivent toujours l’ancienne app.

Les deux stores considèrent que c’est votre problème, pas le leur. Google Play indique que vos réponses Data safety doivent rester exactes et complètes en permanence, et que les données collectées par les bibliothèques et SDK tiers de votre app sont à déclarer par vous. Apple dit la même chose des App Privacy details, et ajoute que vous pouvez modifier les réponses dans App Store Connect à tout moment sans soumettre de mise à jour.

D’où vient réellement l’écart

Presque jamais d’une décision de « collecter plus de données ». Il vient du travail d’ingénierie ordinaire :

• Une nouvelle dépendance. Rapport de plantages, analytics, un SDK de paywall, une bibliothèque de cartes.
• Une nouvelle permission. La localisation pour une fonctionnalité, l’appareil photo pour un scanner, le suivi pour la publicité.
• Un flavor ou une target. Un build gratuit reçoit un SDK publicitaire que le build payant n’a pas.
• Une suppression. C’est aussi un écart — la politique déclare désormais trop, ce qui est l’erreur la moins risquée, mais reste une erreur.

Chacun de ces changements aboutit dans un fichier de build — build.gradle, AndroidManifest.xml, Podfile, Package.swift, Info.plist, pubspec.yaml, package.json. C’est ce qui le rend vérifiable.

L’approche : un enregistrement, et une vérification sur chaque pull request

1. Quand vos pages sont rédigées, enregistrez à partir de quoi elles l’ont été : les SDK, les types de données et les permissions présents dans le build à ce moment-là.
2. À chaque pull request, relisez les fichiers de build et comparez.
3. Quand quelque chose diffère, indiquez quoi, où (fichier et ligne), et quelle page ou quel formulaire peut être concerné.

Deux propriétés comptent. La vérification ne doit lire que les fichiers de build — jamais le code source, jamais les secrets — pour pouvoir tourner sans risque sur n’importe quel dépôt. Et elle doit dire « peut être obsolète », pas « infraction » : une bibliothèque dans un fichier de build ne prouve pas que l’app l’utilise, et vous seul savez si cela change ce que collecte votre app.

La mettre en place avec AppFoyer

La vérification est gratuite avec toutes les formules. Elle ne lit que les fichiers de build, n’a besoin d’aucune clé ni d’aucun secret, n’envoie rien nulle part et ne modifie jamais une page.

Avec le plugin Claude Code

1. Dites “make this app store-ready”. En plus de rédiger les brouillons des pages, le plugin écrit appfoyer.json à la racine de votre dépôt : l’enregistrement de ce à partir de quoi les pages ont été rédigées.
2. Dites “add the AppFoyer drift check”. Il vous montre un workflow GitHub et écrit .github/workflows/appfoyer.yml quand vous acceptez.
3. Committez les deux fichiers. Le plugin ne fait jamais de commit ni de push à votre place.

Sans le plugin

Ajoutez le workflow vous-même :

name: AppFoyer drift check
on: pull_request
permissions:
  contents: read
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: appfoyer/check-action@v1

Ouvrez une pull request. S’il n’y a pas encore de appfoyer.json dans le dépôt, le résumé du job affiche le fichier qu’il écrirait à partir de votre build. Comparez-le à vos pages publiées et committez-le.

Ou créez-le en local — le même scanner, publié sur npm :

npx @appfoyer/check init

Sur un autre système de CI

Le package npm fonctionne partout où tourne Node 20 ou plus récent. Pour GitLab, par exemple :

appfoyer-drift-check:
  image: node:22
  script:
    - npx -y @appfoyer/check --fail-on-drift

--format markdown produit le même rapport que celui du résumé de job GitHub ; --format json est destiné aux scripts.

À quoi ressemble un résultat

Une pull request qui ajoute RevenueCat à une app dont les pages ont été rédigées sans lui :

"Trail Notes": 2 changes
  + In-app purchases / subscriptions (data collected)  app/build.gradle.kts:28
      → Privacy policy may not declare "In-app purchases / subscriptions"
      → Google Play Data safety and Apple App Privacy answers may be outdated
      → Terms may not cover purchases and subscriptions
  + RevenueCat (SDK)  app/build.gradle.kts:28
      → Store forms: RevenueCat is not in the app's SDK list
      → Privacy policy may not name this SDK

Par défaut, le job signale et réussit. Ajoutez fail-on-drift: "true" sous with: pour le faire échouer tant que l’enregistrement n’est pas mis à jour.

Quand elle signale un changement

1. Mettez à jour ce que le changement affecte. Redites “make this app store-ready” sur la même branche : le plugin relit le build, met à jour les faits de l’app, réécrit les brouillons des pages concernées par le changement et réécrit appfoyer.json. Ou modifiez vous-même les pages et l’onglet Store forms dans le tableau de bord.
2. Rafraîchissez l’enregistrement. Le plugin l’a déjà fait. Après une modification dans le tableau de bord, lancez npx @appfoyer/check update, ou copiez le fichier rafraîchi depuis le résumé du job, où il figure sous les résultats.
3. Committez-le dans la même pull request. L’exécution suivante n’affiche aucun changement, et l’historique montre la dépendance et le changement de déclaration arrivant ensemble.
4. Mettez à jour les formulaires des stores dans les consoles. Ni la vérification ni AppFoyer ne peuvent accéder à la Play Console ou à App Store Connect. Les brouillons de réponses se trouvent dans l’onglet Store forms du tableau de bord.
5. Publiez les brouillons mis à jour depuis l’écran de relecture.

Plusieurs apps dans un même dépôt

appfoyer.json contient une entrée par fiche de store. Un product flavor avec son propre application id a sa propre entrée, de sorte qu’un SDK publicitaire utilisé uniquement par le flavor gratuit est comparé aux pages du flavor gratuit et non à celles du payant. Le plugin écrit une entrée par flavor qu’il a rendu store-ready. À la main, une entrée prend une liste sourceSets — ["free"], ou pour un build à plusieurs dimensions chaque flavor de la combinaison plus la combinaison elle-même — et un dossier root quand l’app se trouve dans un monorepo.

Ce qu’elle ne peut pas voir

• Les dépendances des dépendances, sauf sur iOS, où Podfile.lock les liste. Un SDK apporté par une autre bibliothèque n’apparaît pas dans votre fichier de build, donc il n’apparaît pas ici non plus.
• La configuration en code uniquement. app.config.js / app.config.ts dans Expo est du JavaScript et n’est pas lu ; app.json et package.json le sont.
• Si vous utilisez ce que vous déclarez. Une dépendance présente mais inutilisée est quand même signalée.
• Votre backend. Rien dans un fichier de build ne dit ce que votre serveur stocke ni pendant combien de temps.

C’est un rappel au moment où un changement est le moins coûteux à déclarer, pas un verdict de conformité et pas un conseil juridique.

Les sources qui font foi

• Fournir des informations pour la section Data safety de Google Play — Aide Google Play Console : garder le formulaire exact, et les données des SDK tiers
• Les App Privacy details sur l’App Store — Apple : garder les réponses à jour, et les mettre à jour sans mise à jour de l’app
• appfoyer/check-action et @appfoyer/check — l’Action et le package npm, avec ce qu’ils lisent