Guides Formulaires des stores et SDK
Comment savoir ce que collectent vos SDK
Une méthode reproductible, un exemple concret avec les tableaux publiés par Firebase lui-même, et où chercher pour les fournisseurs qui n'en publient pas.
Ouvrez votre fichier de dépendances, listez chaque SDK tiers, puis lisez la page de divulgation des données de chaque fournisseur — Firebase, par exemple, publie précisément quelles données collecte chacun de ses produits. Cette liste est la substance de votre politique de confidentialité et la source d'où doivent venir vos réponses Data safety et App Privacy.
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.
Toutes les exigences des stores concernant les données se ramènent à une seule liste, et presque personne ne la met par écrit. Votre politique de confidentialité, votre formulaire Data safety et vos réponses App Privacy sont trois versions de la même liste — l’établir une fois, correctement, c’est tout le travail.
Les deux stores disent explicitement que le comportement des SDK vous est imputable. Google Play indique que la collecte de données « includes data collected and handled through any third-party libraries or SDKs used in their apps » (inclut les données collectées et traitées via toute bibliothèque ou tout SDK tiers utilisé dans leurs apps). Apple vous demande d’identifier les données que « you or your third-party partners collect » (vous ou vos partenaires tiers collectez).
Étape 1 — trouver chaque SDK
Lisez les fichiers, ne vous fiez pas à votre mémoire :
| Plateforme | Fichiers |
|---|---|
| Android | build.gradle / build.gradle.kts, libs.versions.toml, AndroidManifest.xml (permissions, meta-data) |
| iOS | Podfile, Package.swift, *.pbxproj, Info.plist (chaînes d’usage), *.entitlements |
| Flutter | pubspec.yaml |
| React Native / Expo | package.json, app.json |
Incluez les dépendances transitives que vous n’avez pas choisies : un SDK qui embarque une bibliothèque publicitaire collecte ce que cette bibliothèque collecte.
Étape 2 — lire la divulgation de chaque fournisseur
La plupart des fournisseurs sérieux publient une page qui dit exactement ce qu’envoie leur SDK, parce que leurs clients en ont besoin pour ces mêmes formulaires. Cette page — pas un article de blog, pas une réponse de forum — est votre source.
Firebase est l’exemple concret, car Google publie une ventilation par produit, alignée sur les catégories App Privacy d’Apple :
| Produit Firebase | Ce qu’il collecte, selon la documentation de Google |
|---|---|
| Analytics | App instance ID, propriétés utilisateur, événements, adresse IP |
| Crashlytics | Stack traces et état de l’application au moment du plantage, informations sur l’appareil et l’OS, plus les clés personnalisées, logs et identifiants utilisateur que vous y joignez |
| Cloud Messaging | Le token push associé à un identifiant d’installation de l’app ; modèle d’appareil, langue, fuseau horaire, version de l’OS, identifiant et version de l’app |
| Authentication | Les identifiants qu’il génère, plus les adresses email, numéros de téléphone et noms affichés provenant des fournisseurs de connexion que vous activez |
| Performance Monitoring | Des métriques de performance comme le temps de lancement et la latence réseau, des informations sur l’appareil et l’OS, l’adresse IP pour la segmentation géographique |
| Remote Config | Code de pays et de langue, fuseau horaire, version de l’OS, identifiants de l’app et du bundle |
Relisez ce tableau si vous utilisez Crashlytics : la dernière colonne dépend en partie de vous. Les clés personnalisées et les identifiants utilisateur que vous joignez aux rapports de plantage sont des données que vous avez choisi d’envoyer, et elles ont leur place dans votre politique, avec vos propres mots.
D’autres fournisseurs dont les divulgations publiées valent d’être consultées directement : les réseaux publicitaires (AdMob, AppLovin, Unity, ironSource), les outils d’attribution (AppsFlyer, Adjust), le suivi des erreurs (Sentry, Bugsnag), les achats (RevenueCat, Adapty) et les fournisseurs d’authentification.
Étape 3 — quand le fournisseur ne publie rien
Ça arrive, surtout avec les petites bibliothèques. Dans ce cas :
- Lisez le trafic réseau. Faites passer l’app par un proxy et regardez ce qu’envoie le SDK. C’est la seule méthode incontestable, et elle règle la question en un après-midi.
- Lisez le code source, s’il est ouvert.
- Interrogez le fournisseur par écrit et conservez la réponse.
- Envisagez de le retirer. Une dépendance dont personne ne veut décrire le comportement en matière de données est un risque que vous portez pour le confort de quelqu’un d’autre.
Étape 4 — transformer la liste en trois documents
Une liste, trois versions, dans cet ordre :
- La politique de confidentialité — catégories, finalités, tiers nommés, conservation, contact.
- Le formulaire Data safety dans la Play Console — les mêmes informations sous forme de cases à cocher.
- App Privacy dans App Store Connect — encore les mêmes informations, dans les catégories d’Apple.
Remplissez-les à partir de la liste, jamais l’un à partir de l’autre. Quand deux d’entre eux divergent, le store croit le SDK : Google Play indique que « when Google becomes aware of a discrepancy between your app behavior and your declaration, we may take appropriate action, including enforcement action » (lorsque Google constate un écart entre le comportement de votre app et votre déclaration, nous pouvons prendre les mesures appropriées, y compris des mesures coercitives).
La garder exacte
L’événement qui invalide les trois est toujours le même : une dépendance a changé. Ajoutez une ligne à votre checklist de release — une dépendance a-t-elle changé dans cette release ? si oui, revérifiez la politique et les deux formulaires — car les deux stores exigent que ces documents restent exacts, pas seulement qu’ils l’aient été au lancement.
Ce que fait AppFoyer
Cette méthode, c’est ce que notre agent automatise. Pointez un agent de code vers le dépôt : il lit ces fichiers de dépendances, compare ce qu’il trouve à une table de SDK connus, et rédige la politique de confidentialité en nommant les tiers trouvés — en indiquant le fichier et la ligne d’où provient chaque fait, pour que vous puissiez le vérifier plutôt que de lui faire confiance. Sans agent, un court formulaire pose les mêmes questions.
Ce qu’il produit est un brouillon que vous relisez. Il ne peut pas voir une bibliothèque qu’il ne reconnaît pas, et il ne publie jamais rien sans votre clic.
Les sources de référence
- Privacy and security in Firebase et App Store data collection — Google. Le tableau ci-dessus provient de ces pages ; ce sont elles qui font autorité, pas celle-ci.
- Provide information for Google Play’s Data safety section — Aide Google Play Console
- App privacy details on the App Store — Apple