Comment remplir le formulaire Data safety de Google Play et les App Privacy details d'Apple

Dressez une seule liste de ce que votre app envoie hors de l’appareil, SDK compris, et répondez aux deux questionnaires à partir d’elle. Le formulaire Data safety de Google Play et les App Privacy details d’Apple portent sur les mêmes faits, formulés différemment. Quand vos réponses viennent de deux souvenirs distincts, elles divergent.

Toute app sur Google Play doit remplir le formulaire Data safety, y compris une app qui ne collecte rien. Seules les apps disponibles sur des canaux de test interne en sont exemptées (l’aide Data safety de Google Play). Apple demande des App Privacy details pour chaque app de l’App Store (les App Privacy details d’Apple).

Où se trouvent les formulaires

• Google Play : Play Console → votre app → App content → Data safety.
• App Store : App Store Connect → votre app → App Privacy.

Étape 1 : établir la liste

1. Chaque SDK tiers. Lisez vos fichiers de dépendances : build.gradle / libs.versions.toml, Podfile / Package.swift, pubspec.yaml, package.json. Les deux stores considèrent ce qu’un SDK collecte comme étant collecté par vous. Apple vous tient responsable de tout le code de votre app, y compris le code que vous n’avez pas écrit.
2. Ce que chacun envoie. Utilisez la page de l’éditeur lui-même. Certains éditeurs publient leurs réponses dans le vocabulaire même de Play, dont RevenueCat, Unity Ads et OneSignal. Google publie des tableaux pour AdMob et pour chaque produit Firebase. Sur iOS, la plupart des SDK actuels incluent un privacy manifest (PrivacyInfo.xcprivacy). Dans Xcode, ouvrez Organizer, faites un clic droit sur une archive et choisissez Generate Privacy Report pour voir tous les manifests de votre build sur une seule page (la documentation d’Apple sur les privacy manifests).
3. Votre propre collecte. Les comptes (e-mail, identifiant utilisateur), tout ce que votre backend stocke, la localisation que lit votre propre code, les historiques d’achat que conserve votre serveur.

Certains éditeurs ne publient rien. AppLovin n’a de liste de types de données pour aucun des deux stores, et plusieurs SDK d’analytics n’ont pas de correspondance pour Play. Pour ceux-là, lisez la documentation du SDK sur ce qu’il transmet et notez la lacune. Ne devinez pas.

Étape 2 : les questions de Google Play

Pour chaque type de données, Play demande :

• Collecté, partagé, ou les deux ? « Collecté » signifie envoyé hors de l’appareil. « Partagé » signifie envoyé à un tiers. Un prestataire qui traite les données pour votre compte ne compte pas comme un partage, pas plus que des données entièrement anonymisées. C’est pourquoi Firebase Analytics est généralement « collecté, non partagé » et un SDK publicitaire généralement « collecté et partagé ».
• Traité de manière éphémère ? Seulement si les données sont conservées en mémoire juste le temps de servir cette requête précise, comme une position envoyée pour obtenir la météo et non stockée.
• Obligatoire ou facultatif ? Facultatif signifie que l’utilisateur peut choisir si elles sont collectées.
• Pourquoi ? Les finalités de Play sont : App functionality, Analytics, Developer communications, Advertising or marketing, Fraud prevention, security, and compliance, Personalization, Account management. La collecte et le partage ont chacun leurs propres finalités.

Viennent ensuite deux questions de sécurité. Toutes les données utilisateur sont-elles chiffrées en transit ? Vous seul pouvez le vérifier. Un seul point d’accès en http:// simple suffit à rendre la réponse Non. Les utilisateurs peuvent-ils demander la suppression ? Vous pouvez répondre Oui si vous offrez un moyen de la demander, ou si vous supprimez les données automatiquement sous 90 jours.

Si votre app permet de créer des comptes, les questions Data deletion du même formulaire demandent aussi un lien web où les utilisateurs peuvent demander la suppression de leur compte (les exigences de Google Play sur la suppression de compte). Voir le guide sur l’URL de suppression de compte.

Les informations de paiement saisies dans la propre fenêtre de facturation de Google Play n’ont pas à être déclarées tant que votre app n’y accède jamais. Les historiques d’achat que votre app ou un SDK reçoit restent à déclarer par vous.

Étape 3 : les questions d’Apple

Pour chaque type de données, Apple demande la finalité et pose deux questions par oui ou non :

• Lié à l’utilisateur ? Les données comptent comme liées, sauf si elles sont désidentifiées avant d’être collectées. Un compte, un identifiant utilisateur ou un identifiant d’appareil suffit à les lier.
• Utilisé pour le suivi ? Le suivi (tracking) consiste à combiner les données de votre app sur un utilisateur ou un appareil avec les données d’autres entreprises pour de la publicité ciblée ou de la mesure publicitaire, ou à les partager avec un courtier en données. Un SDK peut le faire même si vous n’utilisez jamais cette fonctionnalité. Si quoi que ce soit est utilisé pour le suivi, l’app doit d’abord demander l’autorisation via App Tracking Transparency (la page d’Apple sur la confidentialité et l’utilisation des données).

Les finalités d’Apple sont : Third-Party Advertising, Developer’s Advertising or Marketing, Analytics, Product Personalization, App Functionality, Other Purposes.

Apple vous permet d’omettre un type de données uniquement si les quatre conditions suivantes sont toutes remplies. Il ne doit pas être utilisé pour le suivi ou la publicité. Il ne doit être collecté que rarement, en dehors de la fonction principale de l’app, et au choix de l’utilisateur. Et l’utilisateur doit le fournir en connaissance de cause à chaque fois. La plupart des données de SDK échouent dès la première condition.

Les trois réponses où l’on se trompe

1. « Nous ne collectons rien. » Les outils de rapport de plantages et d’analytics envoient des identifiants d’appareil et des diagnostics, même quand votre propre code n’envoie rien.
2. « Non partagé » pour un SDK publicitaire. Les régies reçoivent des identifiants et des interactions pour leurs propres finalités publicitaires. C’est un partage.
3. Un formulaire en désaccord avec la politique de confidentialité. Les stores lisent les deux ensemble, donc un désaccord suffit à lui seul. Rédigez les deux à partir de la même liste. Voir quand les deux se contredisent.

Les tenir à jour

Les réponses ne sont pas plus à jour que votre liste de SDK. Quand vous ajoutez un SDK, mettez à jour les deux formulaires et votre politique de confidentialité dans le même changement. Les éditeurs révisent aussi leurs déclarations avec les nouvelles versions de leurs SDK.

Laisser un assistant IA trouver les SDK

La partie lente est l’étape 1, et un agent de code ouvert dans le dépôt de votre app peut la faire à votre place : Claude Code, Cursor, Codex et autres. Le prompt ci-dessous lui demande de lire uniquement vos fichiers de build et de nommer chaque SDK et chaque fait sur les données, avec le fichier d’où il provient. Il ne lui demande pas ce que collecte chaque SDK. Le souvenir qu’a un modèle de la déclaration d’un éditeur est une supposition, et cette partie doit venir de l’éditeur.

Il répond dans un petit format JSON que lit le tableau de bord AppFoyer. Sans AppFoyer, la liste qu’il vous montre à l’étape 2 reste celle à partir de laquelle remplir les deux formulaires.

You are helping me fill in Google Play's Data safety form and Apple's App Privacy details for my mobile app. AppFoyer turns your answer into draft answers for both forms, using each SDK vendor's own published disclosure. Your job is only to find what is in the build — not to say what any SDK collects.

## About the app

- App name: [app name]
- Platforms: [Android, iOS or both]

## Step 1 — read the build files

Read only the app's build, manifest and store-metadata files — for example `build.gradle(.kts)`, `gradle/libs.versions.toml`, `AndroidManifest.xml`, `Podfile.lock`, `Package.swift`, `Package.resolved`, `Info.plist`, `*.entitlements`, `PrivacyInfo.xcprivacy`, `pubspec.yaml`, `package.json`, `app.json`. Do not open `.env` files, keystores, credentials or any other secrets, and do not change any file. If you cannot read the code, ask me which SDKs the app uses instead.

Find:

1. Every third-party SDK in the build. Match it to one of these ids where it fits:

- `admob` — Google Mobile Ads (AdMob)
- `applovin-max` — AppLovin MAX
- `unity-ads` — Unity Ads
- `firebase-analytics` — Google Analytics for Firebase
- `mixpanel` — Mixpanel
- `amplitude` — Amplitude
- `meta-app-events` — Meta SDK — App Events
- `firebase-crashlytics` — Firebase Crashlytics
- `sentry` — Sentry
- `firebase-auth` — Firebase Authentication
- `google-sign-in` — Google Sign-In
- `meta-login` — Meta SDK — Facebook Login
- `revenuecat` — RevenueCat
- `firebase-messaging` — Firebase Cloud Messaging
- `onesignal` — OneSignal

   An SDK that fits none of them goes under `otherSdks` with its package name. Never force a match.

2. Which of these facts are true, from the dependencies, permissions and usage-description keys:

- `account` — users sign in or create accounts
- `analytics` — usage analytics
- `ads` — advertising
- `crash` — crash reporting or diagnostics
- `location` — the app reads the device location
- `purchases` — in-app purchases or subscriptions

   If none is true, the facts are `["none"]`.

Keep the file, and the line where you can, for every SDK and every fact. A README sentence is not evidence.

## Step 2 — confirm with me

Show me the list, grouped as SDKs, other SDKs and facts, each with its file. Ask me to confirm or correct it, and to add anything the build files cannot show — for example an SDK loaded at runtime. Wait for my answer.

## Step 3 — reply in AppFoyer's format

Reply with one ```json code block and nothing after it, exactly in this shape:

```json
{
  "format": "appfoyer-store-forms/1",
  "platform": "android | ios | both",
  "sdks": [{ "id": "admob", "file": "app/build.gradle.kts", "line": 42 }],
  "otherSdks": [{ "name": "com.example:tracker", "file": "app/build.gradle.kts", "line": 57 }],
  "facts": [{ "fact": "ads", "file": "app/src/main/AndroidManifest.xml", "line": 12 }]
}
```

- `id` is one of the ids above, spelled exactly. `fact` is one of the facts above, or `none`.
- `line` is a number, or leave it out when you do not know it.
- Empty lists are `[]`. No comments inside the JSON.
- Do not describe what an SDK collects, and do not add fields.

Avec AppFoyer

Chaque app du tableau de bord a un onglet Store forms. Cochez les SDK que contient votre build, et il rédige les brouillons des réponses Data safety et App Privacy à partir de ceux-ci et des paramètres de votre app. Chaque réponse indique sa source : les réponses de l’éditeur lui-même, son privacy manifest, ou notre lecture de sa liste de données. L’onglet signale un SDK que votre politique de confidentialité ne mentionne pas, et vous donne le lien de suppression de compte à coller. Le plugin Claude Code remplit la liste des SDK à partir de vos fichiers de build. Avec un autre assistant, copiez le prompt depuis l’onglet, lancez-le et recollez la réponse : l’onglet montre les réponses qui en découlent avant que quoi que ce soit ne soit enregistré. Vous saisissez toujours les réponses dans chaque console et les vérifiez là-bas. Ce sont des brouillons, pas un conseil juridique. L’onglet est gratuit avec toutes les formules.