Section Sécurité des données du Play Store : la déclaration que personne ne vérifie
Avant d’installer une application, un utilisateur dispose d’une seule page qui décrit ce qu’elle fait de ses données : la section Sécurité des données de sa fiche Play Store. C’est la description publique la plus structurée qui existe, et sur Android, la seule que la plupart des gens verront jamais.
Trois phrases de la documentation de Google suffisent à savoir ce qu’elle vaut. La première : « Vous seul êtes responsable de fournir des informations complètes et exactes sur la fiche Play Store de votre application sur Google Play. » La deuxième donne l’étendue de cette responsabilité : « Cela inclut les données collectées et gérées via les bibliothèques ou SDK tiers utilisés dans leurs applications. » La troisième dit ce que Google fait de son côté : « Google Play vérifie que les applications respectent l’intégralité du règlement. Cependant, nous ne pouvons pas déterminer à la place des développeurs la façon dont ils gèrent les données utilisateur. »
Autrement dit, l’éditeur répond seul, y compris pour du code qu’il n’a pas écrit, et sa réponse n’est recoupée avec le comportement réel de l’application par personne. Ce serait une simple règle de magasin si la CNIL ne désignait pas cette même page comme un support d’information des personnes. Elle le fait, et elle énumère ce qu’on devrait y trouver. La comparaison des deux listes est instructive.
Ce que la fiche affiche, et ce qu’elle n’affiche pas
La section décrit des catégories de données, de la localisation aux identifiants de l’appareil, en passant par les contacts, les messages, les photos, les informations financières et l’activité dans l’application. Pour chacune, elle indique si la donnée est collectée, si elle est partagée, et pour quelles finalités : fonctionnement de l’application, analyse d’audience, publicité, personnalisation. S’y ajoutent quelques engagements, comme le chiffrement en transit ou la possibilité de demander une suppression.
Ce qu’elle n’affiche jamais, c’est un nom. Une donnée peut être déclarée partagée sans qu’aucun destinataire ne soit identifié. Aucun pays n’est demandé. Et aucune liste des briques logicielles tierces intégrées à l’application, ces SDK que l’éditeur assemble pour la mesure d’audience, la publicité ou l’attribution des campagnes, n’apparaît nulle part.
Le mot « partage » est lui-même plus étroit qu’il n’en a l’air. Google le définit comme « le transfert des données utilisateur collectées depuis votre application vers un tiers », puis en retire quatre cas. Les données entièrement anonymisées. Les transferts imposés par une obligation légale. Ceux qu’un utilisateur déclenche lui-même en connaissance de cause. Et surtout le premier de la liste : « Transfert de données utilisateur à un “fournisseur de services” qui les traite pour le compte du développeur. »
Cette exclusion se défend parfaitement dans la logique du magasin. Elle ne coïncide simplement pas avec celle du RGPD. Là où Google compte les transferts vers des tiers hors relation de sous-traitance, le règlement s’intéresse aux destinataires, et l’article 13 impose de les indiquer, sous-traitants compris. Une fiche peut donc être irréprochable au regard des règles du magasin et rester muette sur les acteurs qui reçoivent effectivement les données.
Ce que la CNIL attend de cette même page
La recommandation de la CNIL relative aux applications mobiles, dans sa version modifiée publiée le 8 avril 2025, s’adresse successivement aux éditeurs, aux développeurs, aux fournisseurs de SDK, aux systèmes d’exploitation et aux magasins d’applications. Deux passages concernent directement la fiche.
Le premier s’adresse à l’éditeur. Après avoir rappelé les obligations d’information des articles 12 à 14 du RGPD, la CNIL recommande de mettre la politique de confidentialité à disposition avant tout téléchargement, « par exemple sur son site ou, lorsque cela est possible, d’utiliser la page dédiée à l’application dans le magasin d’applications », pour y indiquer l’identité de l’éditeur, les finalités des traitements et les modalités d’exercice des droits. Sur les partenaires, elle va plus loin et recommande « de mettre en évidence, auprès des personnes concernées, le nombre et le secteur d’activité des partenaires qui seraient rendus destinataires des données ».
Le second s’adresse au magasin lui-même. La CNIL y énumère les informations qu’un magasin devrait obtenir de chaque éditeur : les catégories de données et les finalités poursuivies, « les tiers qui ont accès aux données ou qui sont susceptibles d’y avoir accès, ce qui peut inclure la liste des fournisseurs de SDK utilisés », « la liste exhaustive des permissions système demandées par l’application » avec leur caractère obligatoire ou optionnel et leurs finalités, et « le cas échéant, le pays tiers dans lequel les données seront stockées et traitées ». Elle coupe court à l’objection habituelle par une phrase sans ambiguïté : « La CNIL rappelle qu’aucune des informations précitées n’est confidentielle. »
Plus loin, elle dit ce qui devrait figurer sur la page de chaque application. Elle « encourage les fournisseurs de magasins d’applications à offrir un niveau d’information suffisant, notamment la liste des SDK tiers utilisés par chaque application, pour permettre aux utilisateurs d’exercer leurs droits plus facilement ».
Les deux listes décrivent la même page. Elles ne se recoupent sur aucun des trois points qui intéressent un délégué à la protection des données : qui reçoit, dans quel pays, et avec quelles permissions.
L’éditeur répond pour du code qu’il n’observe pas
Le formulaire pose des questions de comportement. Cette application collecte-t-elle un identifiant d’appareil, le partage-t-elle, à quelle fin. L’éditeur, lui, répond sur pièces : ce qu’il a fait développer, ce qu’annonce la documentation des SDK qu’il a intégrés. Entre les deux, il y a tout ce qu’une bibliothèque tierce fait sans le lui dire.
Ce n’est pas une hypothèse. Une étude présentée en 2026 à la conférence MOBILESoft a interrogé 41 développeurs Android sur ce formulaire, puis analysé 172 discussions publiques réunissant 642 développeurs de plus. 58,53 % des personnes interrogées trouvent l’exercice difficile. Et 37,79 % des discussions portent sur les données traitées par les bibliothèques tierces, c’est-à-dire précisément sur la partie de la question à laquelle l’éditeur n’a pas la réponse.
Quant au résultat, il se mesure. En février 2023, la fondation Mozilla a comparé, pour les vingt applications gratuites et les vingt applications payantes les plus populaires du Play Store, la politique de confidentialité de chaque application avec sa propre fiche Sécurité des données. Deux documents produits par le même éditeur, sur le même sujet.
Trois applications n’avaient pas rempli le formulaire. Sur les trente-sept restantes, six seulement présentaient deux documents cohérents. Il ne s’agissait pourtant pas encore de confronter la fiche au trafic réel de l’application : juste de mettre côte à côte deux textes du même auteur.
Une autre étude, publiée en mars 2026, a comparé les déclarations de 41 jeux mobiles aux indicateurs qu’on peut extraire de leur fichier d’installation. La localisation en ressort comme le point le plus incohérent, avec 56,1 % de désaccords. C’est aussi celle sur laquelle la CNIL est la plus exigeante, puisqu’elle demande à l’éditeur de « tronquer localement les coordonnées » au niveau de précision minimal nécessaire avant tout envoi.
En France, ce n’est pas qu’une règle de magasin
Un éditeur français qui remplit ce formulaire pense souvent satisfaire une exigence de Google. Dans les faits, il alimente aussi une information publique sur ses traitements. Le RGPD ne connaît pas la « section Sécurité des données », mais il connaît l’obligation d’informer les personnes de manière exacte, et la CNIL désigne cette page comme l’un des endroits où le faire.
La recommandation ajoute une observation qui décrit la plupart des organisations : « Si la responsabilité relative à la publication d’une application ou de ses mises à jour dans un magasin d’applications repose sur l’éditeur, il est fréquent que cette opération soit effectuée en pratique par le développeur. » La responsabilité est d’un côté, la main sur le formulaire de l’autre.
Le scénario est banal. Le formulaire a été rempli à la première publication, par une agence, sur la base des SDK d’alors. Depuis, deux d’entre eux ont été mis à jour, un troisième a été ajouté pour l’attribution des campagnes, et personne n’est revenu sur la fiche. Ce que l’application embarque engage pourtant l’éditeur, et la fiche est l’endroit où cet engagement devient public.
Ce qui s’établit en exécutant l’application
Trois des informations que la CNIL veut voir sur cette page ne se lisent nulle part dans un dépôt de code. Elles s’observent en faisant tourner l’application.
Les acteurs tiers réellement contactés, d’abord. Pas la liste des SDK intégrés, qui dit ce qui a été assemblé, mais celle des serveurs que l’application interroge quand elle s’exécute. Les deux ne coïncident pas : un flux publicitaire atteint des sociétés avec lesquelles l’éditeur n’a rien signé. Les permissions ensuite : non pas celles que l’application déclare, mais celles dont elle se sert, et à quel moment. Le pays du serveur enfin, déduit de son adresse, avec l’organisation qui l’héberge.
Une prudence s’impose sur ce dernier point, et elle mérite d’être écrite noir sur blanc dans un dossier. Un serveur situé en Europe ne prouve pas que les données y restent : un constat de géolocalisation établit le premier point de contact, pas la trajectoire complète. Sur une fiche, cette nuance change la formulation, pas la conclusion : si le premier point de contact est déjà hors de l’Union, la question est posée.
Rien de tout cela ne se lit à l’écran. C’est ce qui sépare l’analyse d’une application de celle d’un site web : le trafic d’une application ne s’affiche nulle part.
Reprendre la fiche avec des faits
Avant de valider une section Sécurité des données, quatre questions suffisent à savoir si elle repose sur des faits ou sur de la documentation.
Quels acteurs tiers l’application contacte-t-elle réellement, et lesquels figurent dans la fiche ? Les données déclarées non partagées partent-elles vers un sous-traitant, cas exclu par le magasin mais qui reste un destinataire au sens du RGPD ? Les permissions demandées servent-elles les finalités annoncées ? Et vers quels pays partent les premières connexions ?
Skanopy exécute automatiquement l’application sur un vrai téléphone et relève ce qu’elle émet : les acteurs contactés, les données transmises, les permissions utilisées, le pays et l’organisation derrière chaque serveur. C’est la matière factuelle qui manque au moment de remplir une fiche, comme au moment de la contrôler. Le rapport établit les faits, il ne juge pas la conformité ; la qualification reste au délégué à la protection des données.
Une fiche vieillit vite, puisqu’un SDK mis à jour peut changer de comportement sans qu’une ligne du dépôt ne bouge : cette vérification vaut mieux répétée à chaque version que faite une fois. C’est aussi l’un des rares documents publics qu’un contrôleur peut lire avant même de vous écrire, aux côtés de la politique de confidentialité et de la bannière de consentement : autant qu’il dise vrai.
Sources
Chaque constat de cet article renvoie à l’un de ces documents.
- Google PlayFournir les informations pour la section Sécurité des donnéesAide Play Console, Google
- Google PlayCe que la section Sécurité des données présente aux utilisateursAide Google Play
- CNIL ’25Recommandation relative aux applications mobiles, version modifiéeCNIL, délibération n° 2025-024 du 27 mars 2025
- MOBILESoft ’26Challenges in Android Data Disclosure: An Empirical StudyKhedkar, Schlichtig, Soliman et Bodden, université de Paderborn et Fraunhofer IEM
- Mozilla ’23Les mentions de confidentialité des grandes applications du Play Store sont fausses ou trompeusesMozilla Foundation, 23 février 2023
- arXiv ’26An Empirical Analysis of Google Play Data Safety DisclosuresBakheet Aljedaani, 25 mars 2026