On a cartographié une grande application française. Voilà tout ce qu’elle émet.
On parle beaucoup de ce que les applications collectent. Nous, on le mesure. Sur un appareil réel, en conditions réelles, avec des techniques avancées, notre moteur observe ce qu’une application transmet vraiment une fois lancée : quelles données partent, et vers qui. Voici un extrait, sur une grande application française grand public, entièrement anonymisé.
La co-responsabilité de l’éditeur
La CNIL est explicite : un éditeur assume au minimum une co-responsabilité pour les traceurs embarqués via un SDK tiers. Choisir d’intégrer une régie, c’est répondre de ce qu’elle collecte.
Autrement dit, le déclaré ne suffit pas. Ce qui engage l’éditeur, ce n’est pas la liste de partenaires annoncée, mais ce que l’application transmet réellement. C’est précisément ce que nous mesurons.
Le trafic, observé pendant que l’application tourne
En quelques dizaines de secondes d’utilisation normale, sur un appareil physique, l’application a contacté cinquante hôtes distincts et émis plus de cent quarante requêtes vers des tiers.
Ces tiers se rangent en quelques familles : attribution marketing, mesure d’audience, régies publicitaires et enchères en temps réel, diagnostic. Voici les principaux, observés en train d’être contactés pendant l’exécution.
Adjust · attribution marketing AT Internet · mesure d’audience AppNexus · enchères publicitaires Smart · publicité Google AdMob · publicité Google Tag Manager· orchestration de tags Batch · engagement et notifications Google Crashlytics· diagnostic
Un acteur écrase le trafic
Toutes les requêtes ne se valent pas en volume. Sur cette session, un seul réseau publicitaire concentre la majorité des appels vers des tiers, loin devant les autres.
Trois requêtes, telles qu’elles quittent l’appareil
Le détail est plus parlant que le décompte. Voici trois requêtes, anonymisées, choisies parce qu’elles illustrent trois mécaniques différentes : l’attribution, la mesure et l’enchère.
Une plateforme d’attribution reçoit ce que vous regardez
Cette requête part vers une plateforme d’attribution marketing. Le rôle d’un tel outil : relier une action dans l’application, consulter une annonce par exemple, à une campagne publicitaire. Pour cela, il a besoin de savoir ce que vous faites.
La requête ne transporte donc pas qu’un identifiant. Elle décrit l’écran consulté jusqu’au détail : la catégorie, la sous-catégorie, l’identifiant de l’annonce, et même une valeur de conversion. Mis bout à bout sur une session, ces évènements dessinent l’intérêt précis du porteur de l’appareil, et la gamme de prix qui l’intéresse.
POST app.adjust.com/event Authorization: Signature signature="Tr4wNW…[tronqué]" partner_params : Category_name = « Véhicules » Sub_category_name = « Équipement moto » ListId = 321…[masqué] ConversionValue = 380.0 app_instance_id = b1e0e4…[tronqué] android_id = 3a67…[masqué] app_token = 3ouw…[tronqué]
Un outil de mesure accumule les identifiants
Le même appareil est suivi par plusieurs identifiants persistants dans un seul appel de mesure d’audience : l’identifiant publicitaire et trois identifiants de visiteur distincts cohabitent dans la même charge utile.
Cette multiplication n’est pas neutre. Un identifiant publicitaire peut être réinitialisé par l’utilisateur. Des identifiants propriétaires, eux, persistent et permettent de recoller les sessions même après cette réinitialisation.
POST logws1357.ati-host.net/event User-Agent: Piano Analytics SDK 3.6.0 events[0].data : adv_id = 48d49bf2-…-…e560c1 experiment_visitor_id = f9bfeb8c…[tronqué] secure_instance_id = 29ee196c-…[tronqué] rollout_visitor_id = 61a07ac8-…[tronqué] marketplace_brand = [redacted] device = smartphone
L’appareil entre dans une enchère publicitaire en temps réel
À l’ouverture d’un emplacement publicitaire, l’application diffuse son contexte dans une enchère programmatique. Le principe : en quelques millisecondes, des acheteurs reçoivent une description de l’espace disponible et enchérissent pour l’afficher.
Cette description inclut le nom de paquet, le domaine, l’écran exact et les caractéristiques de l’appareil. C’est ce contexte qui part aux enchères, à de nombreux acheteurs à la fois.
POST ib.adnxs.com/openrtb2/prebid imp[0].ext.gpid = « /[redacted]/Android/Homepage/Interstitiel/ » app.name = [redacted] app.bundle = [redacted] app.domain = [redacted] device.ua = « Mozilla/5.0 (Linux; Android 15) … »
Voir la structure, pas seulement une liste
Une liste de traceurs dit qui est présent. Elle ne dit pas comment les données circulent. Ce graphe montre la structure réelle des échanges observés sur l’appareil : ce qui part directement de l’application, et les liens entre tiers, quand la réponse d’un acteur en redirige vers un autre ou qu’un en-tête désigne l’acteur d’origine.
C’est là que se joue la responsabilité de l’éditeur. Un contrôle ne s’arrête pas à la liste de partenaires déclarée : il regarde ce qui sort réellement, et vers qui. Un éditeur qui ne voit qu’une liste plate passe à côté des relais et des chaînes ; le graphe les rend visibles, et marque ce qui part avant tout consentement.
Une limite, dite franchement : ce graphe montre ce qui est observable sur le réseau de l’appareil. Les échanges de serveur à serveur, entre les tiers eux-mêmes, ne s’y voient pas. Ce qu’il montre, en revanche, est mesuré, pas déclaré.
Comment lire ces signaux
Pris isolément, chaque champ paraît anodin. C’est leur accumulation qui fait le profil. Un identifiant publicitaire, partagé par plusieurs tiers, devient une clé commune : elle relie l’activité d’une même personne entre applications et entre régies.
Les données comportementales, comme la catégorie consultée ou le prix regardé, ajoutent l’intention. Les identifiants persistants ajoutent la continuité dans le temps. Les enchères en temps réel ajoutent la diffusion, à de nombreux acheteurs, en un instant. Ensemble, ils transforment quelques requêtes en un portrait.
Pourquoi c’est sérieux
Rien ici n’est théorique. Ces extraits proviennent d’une exécution réelle, sur un téléphone réel. C’est précisément le niveau de détail qu’attend un contrôleur : non pas la liste déclarée des partenaires, mais ce que l’application transmet effectivement, à qui, et avec quoi.
C’est exactement ce que Skanopy produit, automatiquement, sur le trafic réel, sur n’importe quelle application Android. Sans configuration et sans accès au code source de l’éditeur, dans un rapport unique et reproductible.
Questions fréquentes
- Comment savoir quelles données une application mobile envoie ?
- En interceptant ses échanges pendant qu’elle tourne, puis en lisant le contenu des requêtes. On y trouve les identifiants d’appareil et de publicité, des données de parcours, parfois la position, et les paramètres passés aux régies. Rien de tout cela ne se lit depuis l’écran ni depuis la fiche du magasin.
- Comment savoir à qui une application mobile envoie des données ?
- Chaque connexion sortante désigne un domaine, et chaque domaine appartient à un acteur identifiable. La liste des destinataires réels dépasse presque toujours celle qu’annonce la politique de confidentialité, parce que les SDK embarqués contactent leurs propres partenaires sans que l’éditeur l’ait décidé requête par requête.