Ce que font les grandes applications de presse françaises après un refus de pistage

Comment on a mesuré

Tout vient d’un téléphone Android physique sous Android 15, pas d’un émulateur. La marche à suivre était la même pour chaque application. La lancer, avec l’instrumentation en place pour enregistrer ce qu’elle envoie et ce qu’elle écrit sur l’appareil. Appuyer sur refuser dès que l’invite apparaît. Puis parcourir l’accueil, faire défiler, ouvrir quelques articles, lancer une vidéo, pendant environ deux minutes. Les graphes montrent ce qui s’est passé dans cette fenêtre.

Quatre-vingt-quinze vendors tiers

Commençons par le décompte. Sur ces applications, on relève 95 vendors tiers distincts, répartis sur près de 150 domaines, plus de 300 en comptant les sous-domaines. Le pistage était refusé sur l’ensemble du parcours mesuré.

La plupart sont là pour la publicité : 40 sur 95, environ 42 pour cent. En ajoutant les courtiers en identité et en données, la mesure d’audience et les réseaux sociaux, les finalités de pistage atteignent 65 pour cent du total. Le reste, c’est l’infrastructure, la vidéo, le paiement et les outils de consentement eux-mêmes.

La bannière n’est pas absente

La question est bien posée. On a identifié quatre plateformes de consentement, Didomi loin devant, puis OneTrust, AppConsent by SFBX et TrustArc. Quelques noms reviennent aussi dans presque chaque application. Google est présent dans toutes, Didomi dans près des trois quarts, Piano Analytics et Meta suivent.

Le problème, c’est le moment

Environ quatre contacts de vendors sur dix ont lieu dans les dix premières secondes. La bannière, elle, apparaît autour de la neuvième seconde. Une partie de la collecte a donc déjà commencé avant que la question soit à l’écran, et le reste se déclenche pendant que la bannière attend une réponse.

Ce qui quitte l’appareil

Ce qui part n’est pas anodin non plus. 41 vendors envoient au moins un identifiant avant tout consentement. Le plus fréquent est un pseudonyme persistant, et environ neuf identifiants sur dix sont persistants plutôt que jetables. Certains sont des identifiants partagés, la même valeur reçue par plusieurs vendors distincts, ce qui leur permet de reconnaître la même personne d’un acteur à l’autre.

Le pistage ne s’arrête pas au réseau

Sur l’appareil, des données sont écrites dès l’ouverture de l’application, surtout dans les préférences et les bases locales, et une bonne part provient de SDK de pistage. À nouveau, avant tout consentement.

Deux choses encore, en marge. Dans une application, des adresses e-mail ont été envoyées à un outil de suivi d’erreurs. Et deux SDK, dont le SDK publicitaire de Google et Batch, chiffrent leur charge utile par-dessus le HTTPS, ce qui rend le contenu illisible à une inspection réseau ordinaire.

Une requête à regarder de près

Le reste relève d’un schéma général. Celle-ci est une requête unique, et difficile à lire autrement. Le même comportement apparaît dans cinq des applications, depuis un SDK publicitaire nommé Start.io.

Le pistage refusé, le SDK appelle ses serveurs, et la requête prouve qu’il a reçu le message : l’identifiant publicitaire est mis à zéro, et un indicateur nommé limit ad tracking est passé à true. Pris isolément, on dirait un acteur qui fait ce qu’il faut.

Puis on lit le reste du corps. Dans la même requête, il transmet son propre identifiant d’appareil, que notre détection signale comme persistant, à côté d’une empreinte du téléphone : modèle et fabricant, version de l’OS, mémoire libre et utilisée, type de réseau et itinérance, temps depuis le dernier démarrage, et si l’appareil est rooté. L’identifiant officiel est neutralisé. L’appareil est reconnu par tout ce qui l’entoure à la place.

Une preuve qu’un DPO ne peut pas balayer

C’est la partie qu’un DPO ne peut pas vraiment écarter. La requête est elle-même la preuve que le refus a été reçu, puisque le SDK a mis l’identifiant publicitaire à zéro et levé l’indicateur de son propre chef. Collecter un identifiant persistant et une empreinte matérielle dans le même geste n’est pas un besoin technique pour lire l’actualité. C’est de la reconnaissance par d’autres moyens, après un non.

Ce que la bannière déclare, et ce qui tourne vraiment

La bannière est censée nommer les vendors avec lesquels une application travaille. Une plateforme de consentement peut les déclarer de trois façons : via la liste des vendors de l’IAB, via des vendors personnalisés ajoutés à la main par l’éditeur, et via la liste Additional Consent de Google pour la publicité hors IAB. Un vendor est déclaré s’il figure dans l’une des trois.

On a donc pris chaque vendor publicitaire, d’identité, d’analytics et social qui s’est déclenché avant consentement, et on l’a vérifié contre les trois. Un vendor qui tourne sans apparaître dans aucune est actif sans être déclaré. On n’a pu le faire que là où la configuration de consentement était entièrement lisible, ce qui ici désigne les applications sur la plus répandue des quatre plateformes.

Après cette vérification, treize vendors ressortent actifs avant consentement tout en manquant à la déclaration dans au moins une application. Une seule application suffit à compter.

L’écart prend trois formes

Un vendor enregistré auprès de l’IAB que l’application a simplement laissé hors de sa liste. Un fournisseur publicitaire Google que l’application n’a pas sélectionné. Et un vendor qui n’est nulle part dans la configuration de consentement. Adjust, un SDK d’attribution, tourne hors liste dans trois des applications. Meta est actif avant consentement dans une application sans y être déclaré, alors qu’une autre application le déclare via la liste de Google, le genre de chose qu’on ne repère qu’en vérifiant les trois canaux.

Une lecture prudente

Quelques-uns appellent une lecture qu’un DPO pourrait proposer. Un vendor d’analytics peut invoquer l’exemption de mesure d’audience. Deux des noms sociaux sont des publications intégrées et un module de commentaires plutôt que des partenaires choisis par l’éditeur. En les retirant, il reste la publicité et l’attribution, les vendors dont toute la finalité exige un consentement.

Même dans cette lecture prudente, des vendors publicitaires et d’attribution tournent avant consentement, sans que la bannière les nomme jamais.

Comment lire tout ceci

Ce sont des signaux, pas des verdicts. Ce qui régit la lecture et l’écriture d’informations sur un appareil en France, c’est l’article 82 de la loi Informatique et Libertés, pas la base d’intérêt légitime que l’on invoque souvent. Savoir si tout cela est conforme revient au DPO, avec le contexte complet de chaque application en main.

C’est précisément la raison d’être de Skanopy : rejouer l’analyse à chaque version, garder une trace reproductible, et laisser la qualification à ceux dont c’est le métier.