Géolocalisation : par où elle sort d’une application mobile, et jusqu’où elle va

Ce qu’un point de localisation dit d’une personne

La CNIL le formule ainsi : « Les déplacements des personnes en disent long sur elles. Ils révèlent leurs habitudes (domicile, lieu de travail, sorties), mais aussi leurs centres d’intérêt, leurs fréquentations et parfois même leurs convictions ou autres données sensibles (fréquentations de lieux de cultes, locaux d’un syndicat ou d’une association, séjour dans un hôpital, etc.). »

Elle ajoute une précision qui vide l’argument de l’anonymat : « Contrairement à une idée reçue, il n’est pas toujours nécessaire de connaître le nom d’une personne pour l’identifier. Quelques points de localisation suffisent souvent à reconnaître un individu, notamment lorsqu’ils révèlent son domicile, son lieu de travail ou ses habitudes de déplacement. »

Ce n’est pas une hypothèse de laboratoire. Le LINC, le laboratoire de recherche de la CNIL, l’a vérifié en achetant lui-même un jeu de données à un courtier, sans « aucune contrainte ou vérification ». L’échantillon contenait 100 millions de relevés de position et 5 millions d’identifiants de téléphones, dont environ 800 000 exploitables.

La méthode tient en trois gestes. L’équipe a pris vingt identifiants au hasard. Elle a regardé où chaque téléphone passait ses nuits, et où il passait ses journées. Puis elle a cherché les adresses correspondantes sur une carte publique. En une journée de travail, elle avait retrouvé l’identité de sept de ces vingt personnes. Le compte rendu conclut : « Anonymes nous disions donc… »

Le laboratoire donne aussi le prix de ce marché, « quelques milliers d’euros par mois ou plus d’une centaine de milliers d’euros par an » selon les zones visées. Puis il ajoute la phrase qui devrait retenir l’attention de tout éditeur : « Les applications qui ont permis à ce data broker d’agréger ces informations ne sont, pour l’heure, pas connues. » Même l’autorité, une fois la donnée achetée, ne sait pas de quelles applications elle provient.

La permission règle une question, et une seule

Sur Android, la localisation passe par deux permissions distinctes, et la documentation de Google chiffre leur écart. La localisation approximative situe le téléphone dans une zone d’environ 3 kilomètres carrés, soit un quartier. La localisation précise le situe en général à 50 mètres près, parfois à quelques mètres. Depuis Android 12, c’est l’utilisateur qui choisit entre les deux quand l’application le lui demande, et son choix l’emporte sur ce que l’application avait prévu.

Cette boîte de dialogue tranche une question : l’application a-t-elle le droit de lire la position. Elle ne dit rien de ce qui en est fait ensuite, ni de qui la reçoit. La CNIL le résume en une phrase : « l’autorisation technique donnée par le système d’exploitation ne vaut pas, à elle seule, consentement pour les usages des données de localisation, notamment à des fins publicitaires ou de partage avec des tiers. »

La règle qui en découle est nette. Un consentement libre, spécifique, éclairé et univoque est nécessaire dès que la localisation n’est pas strictement nécessaire au service, et « c’est le cas, notamment, de l’usage publicitaire de ces données ou la revente à des fins marketing ». À l’inverse, une application de navigation qui a besoin de la position pour calculer un itinéraire en est dispensée. La distinction ne porte pas sur la donnée, elle porte sur l’usage. C’est le même raisonnement que celui qui gouverne l’ensemble de la recommandation applications mobiles.

Par où la position sort d’une application

Le premier chemin est le plus visible. Un SDK tiers embarqué dans l’application lit la position que l’application a demandée pour sa propre fonctionnalité. La permission a été accordée une fois, à l’application ; le code tiers qu’elle héberge en hérite. La CNIL l’écrit sans détour : « Si une permission est accordée à l’application, tous les SDK intégrés ont, par défaut, la capacité technique d’accéder aux données. Ces accès par le SDK peuvent alors échapper au contrôle du développeur. » Elle rappelle au passage qu’« une application Android embarque en moyenne plus de 15 SDK ».

La recommandation tranche aussi la responsabilité : l’éditeur est responsable de traitement pour « l’inclusion au sein de l’application d’un SDK ayant pour fonction d’accéder à la donnée de localisation », le fournisseur du SDK étant son sous-traitant lorsqu’il ne poursuit aucune finalité propre. La CNIL cite elle-même un précédent parlant : en 2020, une application de prière a été accusée de vendre les données de localisation de ses utilisateurs à des courtiers, avant de déclarer avoir rompu ses relations contractuelles avec les SDK à l’origine de la collecte. L’éditeur répondait de ce qu’il n’avait pas vu.

Le deuxième chemin ne suppose la présence d’aucun code du destinataire dans l’application. Quand un espace publicitaire doit s’afficher, l’application le met aux enchères, en une fraction de seconde. Le format standard de ces enchères prévoit des champs dédiés à la position : latitude, longitude, précision estimée en mètres, ancienneté du relevé, et la façon dont la position a été obtenue. S’y ajoute l’identifiant publicitaire du téléphone, ce numéro que le système attribue à chaque appareil pour la publicité et qui permet de le reconnaître d’une fois sur l’autre.

La demande part simultanément à tous les acheteurs éligibles. Un seul remporte l’enchère. Tous l’ont lue.

Le troisième chemin ne réclame aucune permission de localisation. L’accès à Internet, lui, est accordé automatiquement à l’installation : Android ne le range pas parmi les permissions sensibles, celles qui déclenchent une question à l’utilisateur. Or l’adresse IP suffit à situer un téléphone à l’échelle d’une ville ou d’un quartier. Le format d’enchère prévoit d’ailleurs ce cas de figure, et va jusqu’à nommer les sociétés qui vendent ce service. L’étude « 50 Ways to Leak Your Data » l’a observé sur des applications réelles : 70 d’entre elles envoyaient la position à 45 domaines distincts alors qu’aucune n’avait la permission de localisation, le plus souvent parce que la régie publicitaire la leur renvoyait dans sa réponse.

Le quatrième chemin est le plus discret. La même étude a montré qu’un fichier du système, que n’importe quelle application peut lire et que rien ne protège, contient l’adresse matérielle de la box à laquelle le téléphone est connecté. Il suffit de comparer cette adresse à une base publique pour obtenir une position à la rue près. Les auteurs ont trouvé cette technique dans le kit d’une régie publicitaire, avec un détail qui dit tout : le code ne s’en servait qu’après que l’utilisateur avait refusé l’accès à sa localisation.

Un régulateur avait déjà documenté ce mécanisme. En 2016, la FTC sanctionnait une régie publicitaire mobile de 4 millions de dollars : même lorsqu’un utilisateur avait refusé l’accès à la localisation, la société relevait les réseaux Wi-Fi environnants, leur nom et la puissance de leur signal, puis les comparait à sa propre base pour en déduire la position. L’étude de 2019 décrit une variante qui ne passe pas du tout par le réseau : lire les informations que l’appareil photo inscrit dans chaque cliché, dont le lieu et la date de la prise de vue. Une application qui accède à la photothèque récupère ainsi un historique de déplacements, et pas seulement la position du moment.

Ces deux derniers chemins partagent une propriété. Le refus de l’utilisateur est techniquement respecté : l’application n’a pas la permission, l’indicateur de localisation ne s’allume pas. Et la position sort quand même. C’est précisément le genre d’écart qu’une lecture du code ne révèle pas.

Ce que la CNIL avait déjà constaté en 2018

La France a un précédent que l’on cite rarement. Entre juin et octobre 2018, la CNIL a mis en demeure quatre sociétés de publicité géolocalisée, toutes sur le même schéma : un SDK intégré aux applications de partenaires, qui collecte l’identifiant publicitaire du téléphone et sa position. Les décisions sont publiques ; les noms des sociétés ne le sont plus, la CNIL ayant depuis retiré leur identification.

Les cadences de collecte figurent dans les décisions, et elles sont parlantes. Dans la décision MED-2018-022 du 25 juin 2018, « le SDK collecte les données de géolocalisation des personnes environ toutes les cinq minutes ». Sur une seule journée, les contrôleurs de la CNIL ont relevé « 1 635 402 identifiants publicitaires associés à des données de géolocalisation », et près de 14 millions d’identifiants distincts sur treize mois.

Dans la décision MED-2018-043 du 8 octobre 2018, la collecte se déclenche « tous les 200 mètres » sur iOS et « toutes les cinq minutes » sur Android. La base contenait « 14 344 670 identifiants publicitaires distincts dont 5 529 383 identifiants sont associés à des données de géolocalisation », issus d’environ 25 applications. Autrement dit, cinq millions et demi de téléphones dont on pouvait retracer les déplacements.

La quatrième décision, MED-2018-042 du 30 octobre 2018, va plus loin, parce que la société contrôlée recevait des données par deux voies. La première est le SDK, comme les autres. La seconde ne suppose aucun code chez l’éditeur : « la société X est destinataire de données à caractère personnel, notamment des données de géolocalisation et des identifiants publicitaires d’ordiphones, par le biais d’enchères en temps réel ». La CNIL constate alors ce qu’il en advient : « la société conserve et traite ultérieurement ces données personnelles qu’elle ait ou non enchéri sur l’enchère en question ».

Le contrôle chiffre les deux stocks, conservés dans une même base : 24 688 863 identifiants publicitaires provenant d’enchères auxquelles la société avait répondu, et 42 934 160 provenant d’enchères auxquelles elle n’avait pas répondu. La part la plus importante de sa base venait donc d’enchères auxquelles elle n’avait jamais participé.

Le même mécanisme, ailleurs, à une autre échelle

En décembre 2024, la Federal Trade Commission américaine a agi contre un courtier sur exactement ce point. Selon sa plainte, la société conservait les informations contenues dans les demandes d’enchère même quand elle ne remportait pas l’enchère, alors que les règles de ces places de marché le lui interdisaient. C’est la première fois que l’autorité américaine qualifie cette pratique de déloyale.

Les chiffres donnent l’échelle. Le courtier estimait lui-même que près de 60 % de ses données venaient de ces enchères. Sur deux ans et demi, la FTC lui attribue plus de 500 millions d’identifiants publicitaires associés à une position précise.

La même autorité avait, en janvier 2024, interdit à un autre courtier de vendre des données de localisation sensibles. Son approvisionnement était décrit ainsi : des applications tierces qui intègrent son kit de développement, ses propres applications, et l’achat auprès d’autres courtiers. Sa plainte chiffre la chose : le kit était intégré à plus de 300 applications, et la société ingérait chaque jour plus de 10 milliards de points de localisation, dont elle vantait une exactitude de 70 % à 20 mètres près. La FTC précisait que ces données brutes, associées aux identifiants publicitaires mobiles, ne sont pas anonymisées et permettent de relier un appareil aux lieux qu’il a fréquentés.

Côté européen, une enquête au long cours menée par netzpolitik.org et la radiotélévision bavaroise, publiée en France avec Le Monde en décembre 2025, a travaillé sur des jeux de données obtenus auprès de courtiers. Pour le seul échantillon gratuit, le volet français porte sur environ un milliard de points de localisation rattachés à jusqu’à 16,4 millions d’appareils en France.

En janvier 2025, la fuite de données d’un courtier a rendu le circuit lisible de l’extérieur. Le chercheur français Baptiste Robert a publié la liste des applications Android présentes dans l’échantillon : 3 455 paquets, du jeu occasionnel à l’application de rencontre, de la météo au suivi de grossesse. Plusieurs éditeurs cités ont déclaré n’avoir aucun lien commercial avec ce courtier, tout en reconnaissant afficher de la publicité dans leur application. Les deux affirmations sont parfaitement compatibles, et c’est tout le problème : la chaîne engage l’éditeur sans qu’il l’ait choisie.

Ce que la CNIL demande aux éditeurs

La recommandation applications mobiles consacre une fiche à la localisation. Elle demande à l’éditeur de retenir, parmi les permissions offertes par le système, celle qui suffit : « une localisation approximative plutôt que précise », « une permission limitée à une seule fois plutôt qu’une permission permanente », « une permission uniquement active quand l’application est en premier plan plutôt qu’en permanence », et « une permission qui ne transmet pas d’information à des tiers lorsque cela est possible ».

Deux exigences y sont plus concrètes que la plupart de ce qui s’écrit sur le sujet. D’abord tronquer avant d’envoyer : « Avant tout envoi des données de localisation vers les serveurs de l’application, l’éditeur doit identifier le niveau de précision minimal nécessaire pour atteindre ses finalités et tronquer localement les coordonnées en fonction de celui-ci ». Ensuite ne pas collecter en veille : « La CNIL recommande de ne pas collecter la localisation quand l’application n’est pas activement utilisée par l’utilisateur ».

Le consentement, lui, ne dispense de rien : « Même en présence d’un consentement, les acteurs ne peuvent pas collecter une géolocalisation plus précise que nécessaire ni conserver des historiques de déplacements sur une longue durée à des fins de ciblage ou de revente. » Et la responsabilité ne s’arrête pas à l’éditeur, puisque ces obligations s’imposent « à l’ensemble des acteurs qui interviennent dans la chaîne de traitement des données de géolocalisation », partenaires publicitaires, régies et courtiers en données compris.

La doctrine a été suivie de contrôles. En 2025, les données collectées via les applications mobiles figuraient parmi les thèmes prioritaires de la CNIL, éditeurs et fournisseurs de SDK compris. Son rapport annuel indique avoir contrôlé dix applications ou fournisseurs de code embarqué, et résume le constat : « un manque de transparence dans les informations fournies aux personnes, y compris lors de la collecte du consentement pour l’usage de la géolocalisation ». C’est le genre de constat qu’un éditeur a intérêt à faire avant qu’on le fasse pour lui, et la préparation tient en quelques vérifications.

Google Play ajoute une règle que beaucoup d’éditeurs découvrent tard. La déclaration de collecte du magasin couvre aussi les bibliothèques et SDK tiers, et le développeur en est seul responsable. La politique du magasin précise qu’il ne faut jamais demander une permission de localisation dans le seul but de la publicité ou de la mesure d’audience, et que la position d’un appareil ne peut être ni vendue ni partagée en vue d’une vente.

Les questions auxquelles seule l’exécution répond

Une politique de confidentialité décrit une intention. Une liste de SDK décrit ce qui est embarqué. Ni l’une ni l’autre ne dit ce qui est réellement parti du téléphone, à quelle précision, vers qui, ni à quel moment.

Les questions utiles sont concrètes. La position part-elle alors qu’aucune permission de localisation n’a été accordée ? Avec combien de décimales, c’est-à-dire à quelle échelle ? Part-elle avant l’affichage de la bannière de consentement ? Un refus l’arrête-t-il vraiment, ou seulement sur le chemin principal ? Combien de destinataires distincts la reçoivent, et lesquels ne figurent pas dans la liste déclarée ? Continue-t-elle de partir quand l’application n’est plus au premier plan ?

On ne répond à ces questions qu’en exécutant l’application sur un vrai téléphone et en lisant son trafic. C’est ce que fait Skanopy : la cartographie de ce qu’une application émet réellement, chaque constat adossé à la requête qui le prouve, datée. Le rapport établit les faits, il ne juge pas la conformité ; l’interprétation reste au DPO. Et parce qu’une application change à chaque version, cette vérification vaut mieux répétée que ponctuelle.

Sources

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

1. CNIL ’26Géolocalisation et applications mobiles : quelles règles pour protéger les données des utilisateurs ?CNIL, 7 juillet 2026
2. CNIL ’25Recommandation applications mobiles, version modifiéeCNIL, délibération n° 2025-024
3. CNIL ’25Permissions : les recommandations de la CNIL pour respecter la vie privéeCNIL, 14 janvier 2025
4. CNIL ’25Applications mobiles : comment intégrer des SDK et respecter la vie privéeCNIL, 21 janvier 2025
5. LINC ’23GeoTrouveTous : projet de réidentification par géolocalisationLINC, laboratoire de recherche de la CNIL
6. MED-2018-042Décision du 30 octobre 2018, SDK et enchères en temps réelCNIL, via Légifrance
7. MED-2018-022Décision du 25 juin 2018, collecte toutes les cinq minutesCNIL, via Légifrance
8. MED-2018-043Décision du 8 octobre 2018, collecte tous les 200 mètresCNIL, via Légifrance
9. FTC ’24Action contre un courtier collectant les données des enchères perduesFederal Trade Commission, 3 décembre 2024
10. FTC ’24Interdiction de vendre des données de localisation sensiblesFederal Trade Commission, 9 janvier 2024
11. FTC ’16Une régie déduisait la localisation malgré le refus de l’utilisateurFederal Trade Commission, juin 2016
12. USENIX ’1950 Ways to Leak Your DataReardon et al., prix CNIL-INRIA 2021
13. OpenRTB 2.6Spécification des enchères publicitaires, objet GeoIAB Tech Lab
14. AndroidPermissions de localisation et précision associéeDocumentation développeur Android
15. Databroker FilesLe volet français des données de localisation vendues par des courtiersnetzpolitik.org, BR et Le Monde, décembre 2025