Pister avant le consentement : ce que la recherche a mesuré dans les applications mobiles

Ce que « avant le consentement » veut dire

Une bannière de consentement laisse croire que rien ne commence avant le choix de l’utilisateur. Sur mobile, ce n’est pas le cas. Une application peut contacter un serveur tiers dès son ouverture, avant le moindre appui, parfois avant même que la bannière s’affiche.

La distinction est simple et lourde de conséquences. « Avant toute interaction » désigne ce qui part au premier lancement, quand l’utilisateur n’a encore rien touché. « Sans consentement » désigne ce qui part alors qu’aucun choix valable n’a été recueilli, ou malgré un refus. Les travaux ci-dessous mesurent l’un et l’autre.

Sept applications sur dix pistent avant le moindre geste

L’étude la plus directe sur ce point vient de l’université d’Oxford. En lançant plus de mille applications Android et en observant leur trafic au tout premier démarrage, les chercheurs ont constaté que 71,3 % d’entre elles contactaient au moins une société de pistage avant toute interaction de l’utilisateur. Pas après un clic sur « Accepter » : à l’ouverture.

Sur le même échantillon, moins d’une application sur dix demandait un consentement, et moins de 3,5 % laissaient un véritable choix de refus. Chaque application contactait en moyenne près de trois serveurs de pistage différents, et une large majorité joignait un domaine appartenant à Google.

À grande échelle, le constat tient

Un échantillon plus large confirme l’ordre de grandeur. Une équipe du centre allemand CISPA a analysé 86 163 applications et constaté que près d’une sur trois envoyait des données personnelles à des tiers sans consentement préalable : identifiant publicitaire, localisation, autres identifiants d’appareil.

Une autre mesure d’Oxford, portant sur près d’un million d’applications, montre qu’une application embarque cinq sociétés de pistage en médiane, autrement dit que la moitié des applications en embarquent davantage. Le chiffre est resté stable avant et après le RGPD. Le même travail montre que Google pouvait recevoir des données depuis près de neuf applications sur dix. Ce ne sont pas des cas isolés : c’est la norme, mesurée sur des jeux de données indépendants qui pointent tous dans la même direction.

Même les applications qui affichent une bannière

Afficher un bandeau ne règle pas la question. Une étude présentée à la conférence ACM CCS s’est intéressée aux applications qui, elles, demandent bien un consentement avant de partager des données avec des tiers. Parmi celles qui ont pu être analysées, une sur cinq violait au moins une exigence du RGPD sur le consentement. Certaines continuaient d’émettre des données après un refus explicite.

Le constat est encore plus net sur le cadre publicitaire le plus répandu. Un travail publié en 2026 s’est concentré sur les applications utilisant le TCF, le cadre de consentement de l’industrie de la publicité. Résultat : 55,3 % d’entre elles partageaient l’identifiant publicitaire avant même que l’utilisateur touche la bannière, et 66,2 % le faisaient sans base légale. La bannière était là ; le partage avait déjà eu lieu.

Contourner la permission elle-même

Certaines applications ne se contentent pas d’ignorer le consentement : elles contournent le système de permissions du téléphone. C’est ce qu’a documenté « 50 Ways to Leak Your Data », une étude menée sur plus de 88 000 applications Android et primée par le prix CNIL-INRIA en 2021.

Les chercheurs y décrivent des chemins de contournement. Une application privée de la permission de localisation lisait l’adresse matérielle de la box du logement, puis la comparait à une base publique pour en déduire la position. Ailleurs, un kit disposant du droit de lire le numéro de série du téléphone en déposait une copie sur la carte mémoire, où d’autres applications, qui n’y avaient pas droit, venaient la récupérer. Dans les deux cas, la donnée protégée sortait quand même, par un chemin que la liste des permissions ne montre pas.

Ces mécaniques ont une caractéristique commune : elles sont invisibles à la lecture du code. On ne les voit qu’en observant l’application pendant qu’elle s’exécute.

La localisation en est le cas d’école. Elle quitte une application par au moins quatre chemins distincts, dont deux ne réclament aucune permission.

Pourquoi la liste des SDK ne suffit pas

Il existe des outils qui listent les traceurs présents dans une application en lisant son code, sans la lancer. Le plus connu, Exodus, recense plus de quatre cents traceurs et retrouve l’outil de mesure de Google dans près de six applications sur dix. C’est précieux, mais c’est une photographie de ce qui est embarqué, pas de ce qui part.

Une liste de SDK dit ce qu’une application peut faire. Elle ne dit pas si ce code s’exécute, à quel moment il se déclenche, ni ce qui quitte réellement l’appareil. Un SDK présent peut rester inerte ; un autre peut émettre avant le consentement. Seule l’observation de l’application en fonctionnement mesure cet écart, et c’est pourquoi auditer une application mobile est plus difficile qu’un site web : sur le web, le trafic est sous les yeux ; sur mobile, il faut le provoquer et le déchiffrer.

Les résultats qui ont fait bouger les régulateurs sont précisément ceux que la lecture du code ne produit pas : le déclenchement avant consentement, les canaux détournés, la donnée qui part après un refus. Nous l’avons montré sur une grande application française, extrait de trafic réel à l’appui.

Ce que la CNIL en attend désormais

Cette méthode n’est pas restée dans les laboratoires. La CNIL a publié en septembre 2024 une recommandation sur les applications mobiles, révisée en avril 2025, qui demande aux éditeurs de choisir, pour chaque permission, « la version la moins intrusive » répondant au besoin. Elle rappelle qu’obtenir une permission technique ne se confond pas avec recueillir un consentement.

En 2025, l’autorité a lancé une campagne de contrôles portant, selon ses propres termes, « essentiellement sur le paramétrage des SDK ainsi que les accès aux données du téléphone via la gestion des permissions ». Son bilan fait état de 323 contrôles sur l’année. Le sujet est passé de la recherche au terrain.

La continuité est directe. L’étude « 50 Ways to Leak Your Data » a reçu le prix de la CNIL et d’INRIA ; ce que le régulateur récompense, puis contrôle, c’est cette observation du comportement réel, pas la lecture d’une liste déclarée.

De la mesure ponctuelle au contrôle continu

Ces études ont un point commun et une limite : chacune est une photographie, prise à un instant, par une équipe qui prépare les applications une par une, à la main. C’est lourd, et une application change à chaque version. Ce qui était propre au printemps peut ne plus l’être à l’automne.

Skanopy applique cette méthode automatiquement, sur le trafic réel, sur n’importe quelle application Android. Il suffit d’un lien Google Play ou d’un fichier d’installation, sans accès au code de l’éditeur.

Le résultat est un rapport factuel, daté et reproductible : ce que l’application a contacté, ce qu’elle a transmis, à qui, et à quel moment par rapport au consentement. Le rapport établit les faits, il ne juge pas la conformité ; l’interprétation reste au DPO. Ce que des chercheurs mesurent au cas par cas, un éditeur peut le suivre à chaque version, au lieu d’un audit ponctuel qui vieillit vite.

Sources

Chaque constat de cet article renvoie à l’un de ces travaux.

1. SOUPS ’21A Fait Accompli? An Empirical Study into the Absence of Consent to Third-Party Tracking in Android AppsKollnig et al., Oxford
2. IPR ’21Before and after GDPR: tracking in mobile appsKollnig et al., Oxford
3. USENIX ’21Share First, Ask Later (or Never?)Nguyen et al., CISPA
4. ACM CCS ’22Freely Given Consent?Nguyen et al., CISPA
5. PETS ’26The TCF doesn’t really A(A)IDMorel, Santos et al.
6. USENIX ’1950 Ways to Leak Your DataReardon et al., prix CNIL-INRIA 2021
7. CNIL ’24Recommandation applications mobilesCNIL, 2024 (révisée 2025)
8. CNIL ’25Les contrôles de la CNIL en 2025CNIL, bilan annuel
9. ExodusListe des traceursExodus Privacy, analyse statique