Formulaire Data safety de Google Play : le guide complet

Le formulaire Data safety est un questionnaire que vous devez remplir pour chaque application que vous téléversez sur Google Play ; vous y déclarez quels types de données votre application collecte, pourquoi, et si ces données sont partagées avec des tiers. Dans Play Console, il se trouve sous Policy > App content > Data safety, une fois votre application sélectionnée.

Ce formulaire alimente la section « Data safety » que les utilisateurs voient sur votre fiche de la boutique ; chaque élément que vous déclarez devient partie d'une liste que les utilisateurs potentiels voient avant d'installer. Le formulaire ne remplace pas l'URL de politique de confidentialité, exigée séparément — les deux doivent être complétés.

Vous ne pouvez pas atteindre la production sans avoir rempli le formulaire ; une section Data safety laissée vide ou jamais ouverte apparaît comme un avertissement bloquant dans le flux de publication.

Le formulaire interroge selon deux axes distincts : la collecte de données et le partage de données. Selon la définition officielle de Google, la collecte consiste à transmettre des données hors de l'appareil de l'utilisateur — par votre application ou par un SDK qu'elle utilise ; les données uniquement traitées sur l'appareil et jamais envoyées ailleurs (traitement éphémère, sur l'appareil) ne comptent pas comme une collecte et n'ont pas besoin d'être déclarées. Le partage signifie transférer les données utilisateur collectées à un tiers (un réseau publicitaire, un fournisseur d'analytique) — quel que soit le but initial de la collecte, ce transfert à un tiers compte comme un partage. Les deux ne sont pas la même chose, et le formulaire vous fait les cocher séparément.

Par exemple, un SDK publicitaire qui récupère l'Advertising ID pour la personnalisation des annonces et l'envoie à ses propres serveurs compte à la fois comme collecte et comme partage : le SDK transmet la donnée hors de l'appareil (collecte), et cette donnée est traitée sur les propres serveurs du réseau publicitaire (partage). En revanche, une donnée envoyée uniquement vers votre propre serveur backend (un serveur que vous exploitez directement, pas un tiers) compte comme collecte mais pas comme partage, puisqu'aucun tiers n'intervient. Une donnée qui ne quitte jamais l'appareil — conservée uniquement en stockage local, comme un thème ou une préférence de langue que l'application mémorise localement — ne compte même pas comme une collecte ; selon la définition officielle de Google, ce type de donnée n'a pas du tout besoin d'être déclaré dans le formulaire.

Pour chaque type de données, le formulaire demande également le but (fonctionnalité de l'application, analytique, publicité/marketing, prévention de la fraude, personnalisation, et similaires), si elle est facultative, et si elle est chiffrée en transit. Ne pas faire correspondre ces champs au comportement réel de votre SDK est la source la plus fréquente d'incohérences signalées.

Si vous utilisez AdMob, vous devez déclarer que l'Advertising ID est collecté et utilisé pour la personnalisation des annonces ; AdMob peut aussi traiter la position approximative et les informations sur l'appareil/l'application à des fins de diffusion publicitaire et de prévention de la fraude. C'est une déclaration que les propres politiques éditeurs d'AdMob exigent des développeurs — l'omettre cause des problèmes à la fois lors de l'examen Play et dans la console AdMob.

Si vous utilisez Firebase Analytics, vous devez cocher que les interactions dans l'application et les données d'utilisation sont collectées à des fins d'analytique. Si vous utilisez Firebase Crashlytics, vous devez déclarer séparément que les journaux de plantage, les identifiants d'appareil et les données de diagnostic sont collectés — fusionner Crashlytics sur la même ligne qu'Analytics peut compter comme une sous-déclaration, puisque ce sont des SDK distincts méritant des lignes séparées dans le formulaire.

Si votre application collecte ses propres données indépendamment de tout SDK — e-mail ou téléphone de connexion, informations de paiement, autorisation de localisation — déclarez-les également séparément. La section de documentation propre à chaque SDK sur les déclarations data-safety/confidentialité est la référence la plus fiable pour remplir le formulaire ; celles-ci peuvent changer d'une version de SDK à l'autre.

Vos déclarations Data safety et le texte de votre politique de confidentialité doivent correspondre. Cocher « advertising ID collecté » dans le formulaire alors que votre politique ne mentionne jamais AdMob — ou l'inverse — peut être signalé comme une incohérence lors de l'examen, et dans le pire des cas déclencher un processus menant à la suspension de l'application.

L'approche pratique consiste à : d'abord lister chaque SDK que vous utilisez et ce que chacun collecte, puis reporter cette même liste à la fois dans le formulaire Data safety et dans votre politique de confidentialité, avec un niveau de détail équivalent. Chaque fois que vous ajoutez un nouveau SDK ou une nouvelle autorisation à l'application, mettre à jour les deux documents dans la même version élimine l'essentiel du risque d'incohérence ultérieure.

Le problème le plus fréquent est la sous-déclaration : l'application collecte des données via un SDK, mais le formulaire ne le reflète jamais. Cela se produit généralement lorsque le formulaire n'est pas mis à jour après l'intégration d'un SDK, et cela peut être détecté comme une incohérence lors de l'examen automatisé ou manuel de Play.

Le deuxième cas est une URL de politique de confidentialité vide, inaccessible, ou contenant un texte contredisant les déclarations du formulaire ; cette discordance est un motif de rejet distinct et peut être signalée indépendamment du formulaire Data safety lui-même.

Le troisième cas est de ne pas revenir sur le formulaire après des changements de contenu : ajouter un nouveau SDK, une nouvelle autorisation (la localisation, par exemple), ou une nouvelle intégration tierce sans mettre à jour le formulaire laisse la déclaration existante désynchronisée du comportement réel de l'application. Google peut réévaluer périodiquement les versions à cet égard.