Se préparer à un contrôle CNIL sur son application mobile
La CNIL a posé le cadre avec sa recommandation sur les applications mobiles, publiée le 24 septembre 2024 et modifiée en avril 2025. Depuis le printemps 2025, les applications mobiles sont l’une de ses priorités de contrôle, avec une campagne dédiée qui cible le paramétrage des SDK et l’accès aux données du téléphone. Le message est clair : la conformité d’une application ne se présume plus, elle se démontre.
Et c’est l’éditeur qui en répond. Pas le fournisseur du SDK intégré, pas le développeur sous-traitant, mais l’entreprise qui distribue l’application sous son nom. Le choix des SDK, le déclenchement de la collecte et la réponse faite à l’utilisateur relèvent de lui, même quand la mécanique est écrite par un tiers. Un contrôle ne s’adresse pas au SDK d’attribution qui émet un identifiant ; il s’adresse à celui qui l’a embarqué.
Se préparer, ce n’est donc pas cocher des cases la veille. C’est savoir, à froid, ce que votre application fait réellement, et pouvoir le démontrer. Voici ce qu’un contrôle regarde sur une application mobile, et comment le vérifier soi-même avant qu’on ne vous le demande.
Ce qu’un contrôle regarde vraiment
La recommandation s’adresse à tout l’écosystème, éditeur, développeur, fournisseur de SDK, système d’exploitation et magasin d’applications, mais c’est l’éditeur qui concentre l’essentiel des obligations. Quelques points clés y reviennent sans cesse, et ce sont eux qu’un contrôleur vérifie en priorité.
Le consentement d’abord : rien qui ne soit strictement nécessaire au service ne devrait se déclencher avant un choix libre et éclairé. Ni lecture, ni écriture, ni collecte par un SDK tiers tant que la personne n’a pas accepté.
La minimisation ensuite. Chaque permission demandée, localisation, contacts, identifiants, doit correspondre à une fonctionnalité réelle et visible pour l’utilisateur. Une permission sans usage apparent est un signal pour le contrôleur. La même logique vaut pour les données : on ne collecte que ce que le service exige, pas ce qu’un SDK sait faire remonter.
L’information au bon moment : une politique de confidentialité accessible avant le téléchargement comme dans l’application, et une explication claire de ce qui est collecté et pourquoi. La fiche du magasin en fait partie, et elle a l’inconvénient d’être publique et datée.
Le refus, enfin, aussi simple que l’acceptation. Deux options d’égale évidence, pas un « tout accepter » en pleine lumière face à un refus enfoui sous plusieurs écrans.
Et par-dessus tout cela, l’encadrement des tiers, qui est le vrai centre de gravité d’un contrôle sur mobile. L’éditeur choisit ses SDK et en répond : la recommandation rappelle qu’il assume a minima une co-responsabilité pour les traceurs qu’un SDK intégré met en œuvre. Externaliser la mesure d’audience ou la monétisation n’externalise pas la responsabilité. C’est pourquoi un contrôle ne s’arrête jamais au texte affiché à l’utilisateur : il descend jusqu’à ce que les SDK font, un par un.
Aucun de ces points ne se juge sur l’intention. Ils se constatent sur des faits techniques : à quel instant une requête part, quel identifiant elle transporte, quel bouton coupe réellement quel flux. C’est un terrain que le régulateur maîtrise, et sur lequel une déclaration de bonne foi ne suffit pas.
Le point aveugle : le comportement réel de l’app
Tous ces points ont un dénominateur commun : ils se jouent dans le comportement réel de l’application, pas dans sa documentation. Et c’est précisément là que la plupart des éditeurs sont aveugles.
Une revue de la politique de confidentialité vous dit ce que l’application est censée faire. Elle ne vous dit pas ce qu’elle fait. Les SDK tiers, régie publicitaire, mesure d’audience, attribution, se déclenchent selon leur propre logique, à l’initialisation, en tâche de fond, parfois avant même que la bannière s’affiche. L’éditeur ne les a pas écrits et ne voit pas ce qu’ils émettent.
Sur le web, un onglet réseau suffirait à lever le doute. Sur mobile, non : le trafic est chiffré, parfois épinglé, et continue souvent après un refus sans que rien ne l’annonce à l’écran. Le seul moyen de savoir ce que vos traceurs font vraiment, c’est d’observer l’application en fonctionnement, sur un vrai téléphone, et de lire ce qu’elle envoie, même chiffré.
Cet écart n’est pas théorique. Quand on mesure une application réelle, il se matérialise : des tiers contactés avant tout choix, des flux qui ne s’arrêtent pas au refus, un identifiant persistant qui repart dans une requête que l’éditeur ne relit jamais. Aucun de ces comportements n’apparaît dans une revue documentaire, tous apparaissent dès qu’on observe le trafic.
Se préparer, point par point
De ce constat découle une préparation méthodique, et elle tient en quatre vérifications. Ce sont celles qu’un contrôle mène, dans cet ordre ; les conduire avant lui, c’est déjà répondre à la moitié de ses questions.
Cartographier les acteurs tiers réellement actifs. Pas la liste théorique déclarée au store, mais les entités que l’application contacte pendant une session réelle : c’est le point de départ de toute cartographie des acteurs tiers, et souvent la première surprise.
Tracer ce qui quitte l’appareil, et vers qui. Identifiant publicitaire, identifiant d’installation, données du terminal : il faut savoir quelles données personnelles sont transmises, à quel destinataire, et sous quelle forme.
Vérifier la bannière. Le consentement recueilli doit correspondre aux acteurs réellement actifs, et le refus doit couper ce qu’il annonce couper. Un audit de la bannière confronte ce qui est déclaré à ce qui part vraiment.
Recommencer à chaque version. Une application change à chaque release, ses SDK aussi ; un suivi des versions évite qu’une mise à jour ne réintroduise ce qu’un correctif avait retiré.
Ces quatre vérifications sont exactement celles qu’un contrôleur mène. Sur une application d’actualité française, nous les avons appliquées et mesuré l’écart : des vendors contactés avant tout choix, un trafic qui ne baisse pas après le refus. C’est ce différentiel qu’un contrôle cherche, et que vous avez tout intérêt à connaître avant lui.
Menées ensemble, ces quatre vérifications produisent une image complète : qui est contacté, ce qui part, si le consentement tient, et comment tout cela évolue d’une version à l’autre. C’est exactement le dossier qu’un contrôleur reconstitue, à ceci près qu’ici l’éditeur l’a en main avant lui.
Documenter, pas seulement corriger
Corriger ne suffit pas : le RGPD impose de pouvoir démontrer sa conformité. C’est le principe de responsabilité, à l’article 5.2. La charge n’est pas de prouver qu’on n’a rien à se reprocher, mais de montrer qu’on sait ce que l’application fait et qu’on le suit. Face à un contrôleur, une affirmation pèse moins qu’une preuve.
Un constat factuel, daté et reproductible, est cette preuve : voici ce que l’application envoyait, à cette date, à ces destinataires. Il documente aussi bien un comportement à corriger qu’une diligence tenue dans le temps. Et comme une application évolue à chaque version, la preuve doit suivre : c’est pourquoi l’audit ponctuel ne suffit plus, et pourquoi un historique daté vaut mieux qu’un rapport isolé.
C’est aussi ce qui change la position de l’éditeur le jour du contrôle. Présenter un historique d’analyses datées, montrer qu’un écart a été repéré puis corrigé d’une version à l’autre, c’est démontrer une diligence continue plutôt que de la promettre. Le contrôleur n’attend pas la perfection ; il attend que vous sachiez, et que vous puissiez le prouver.
Le constat, avant le contrôle
C’est précisément ce que produit Skanopy : à partir d’un lien Google Play ou d’un fichier d’installation, un rapport d’analyse factuel, daté et reproductible, qui montre ce que l’application contacte, ce qu’elle transmet et à qui. Le rapport ne juge pas la conformité, il en établit les faits ; l’interprétation reste au DPO. De quoi aborder un contrôle en sachant, à l’avance, ce qu’il y trouvera.
Le déroulé complet est décrit sur la page audit RGPD d’une application mobile, et les attentes de la CNIL point par point dans les 166 vérifications de sa recommandation.