Depuis la mi-septembre, une partie des requêtes publicitaires n'aboutit plus sur les iPhone à jour. Pas de panne, pas d'erreur serveur : Safari refuse la connexion vers les serveurs d'une poignée d'intermédiaires. Le 19 octobre, Apple a enfin expliqué ce que les intéressés subissaient depuis un mois — le blocage de la résolution d'identité, livré avec iOS 27, iPadOS 27, macOS 27 et visionOS 27, sans annonce préalable.
Le principe est vieux comme le pistage post-cookie, et assez élégant dans son genre. Un prestataire présent sur la page, invisible pour le visiteur, intercepte l'adresse email saisie dans un formulaire de connexion ou d'inscription à une newsletter. Il l'envoie à ses serveurs, la lie à un identifiant opaque, et renvoie cet identifiant au site. À partir de là, le site dispose d'une clé stable, rattachée à une personne, utilisable pour profiler sa navigation et lui servir de la publicité ailleurs.
Ce que faisait vraiment la résolution d'identité
La subtilité tient à ce que l'adresse email est un identifiant quasi permanent. On la garde des années, souvent des décennies, et elle traverse les appareils. Un identifiant publicitaire classique se perd au changement de téléphone ou à la réinitialisation ; une adresse email, non. Les acteurs de la résolution d'identité construisent ainsi des graphes d'identité qui relient comptes, formulaires, appareils et historiques de navigation, y compris pour des gens qui n'ont jamais consenti à ce rapprochement.
Apple insiste sur un point qui n'est pas anecdotique : se désabonner ne remet pas les compteurs à zéro. Le billet publié sur le blog de WebKit le formule sans détour.
Se déconnecter ou se désabonner de la newsletter ne supprime ni l'identifiant de suivi, ni l'adresse email conservés par le tiers.
Un blocage par domaine, donc coûteux à contourner
Safari ne filtre pas les requêtes au cas par cas : il bloque l'accès réseau aux domaines concernés. Changer la structure de la requête ne suffit donc pas à passer entre les mailles. En revanche, Apple ne publie ni la liste des domaines visés, ni la procédure pour en sortir. Les noms qui circulent proviennent d'un ticket ouvert le 21 septembre sur le bug tracker public de WebKit par un ingénieur de The Trade Desk : neuf domaines, dont ceux d'UID2, ID5, LiveRamp, Permutive et Audigent.
Le même ticket contestait le blocage d'adsrvr.org, le domaine principal de The Trade Desk, qui empêchait purement et simplement l'affichage d'annonces dans Safari sous iOS 27. Apple l'a retiré de la liste dans une version bêta, mais le correctif ne devait pas atteindre les utilisateurs avant la fin du mois. Un délai qui, pour un réseau publicitaire, se traduit en revenus perdus.
Les premiers chiffres, et ce qu'ils ne disent pas
Les mesures disponibles viennent des éditeurs, pas d'Apple. Chez les clients d'Aditude, prestataire de monétisation cité par Digiday, Safari sur iPhone et iPad représente 12 % des publicités affichées et 11 % des revenus publicitaires. Sur les appareils déjà passés à iOS 27, l'eCPM (coût effectif pour mille impressions) a reculé de plus de 10 %. Mais comme environ 8 % des utilisateurs seulement avaient installé la mise à jour à la mi-octobre, l'impact global reste estimé à 1 % des revenus.
Ce 1 % est trompeur dans les deux sens. Il va mécaniquement grossir à mesure que l'adoption d'iOS 27 progresse, sans que la mesure devienne plus sévère pour autant. Et il masque des écarts considérables selon le type de site : un média financé par la publicité et une boutique en ligne ne perdent pas la même chose.
Ce que ça change pour un site ordinaire
Pour la plupart des sites, l'effet direct est modeste. L'effet indirect, lui, est réel : des scripts installés il y a trois ans, souvent via un gestionnaire de balises, continuent de tourner sans que personne ne sache exactement ce qu'ils collectent. Le blocage d'Apple est l'occasion de faire le tri.
- Lister les scripts tiers chargés sur les pages newsletter, connexion, compte et paiement, et vérifier qui les a ajoutés.
- Identifier les outils de mesure qui reposent sur un rapprochement d'emails, et savoir ce qu'ils deviennent quand ce rapprochement échoue.
- Distinguer la mesure first-party — analytics serveur, événements propres — de l'attribution publicitaire cross-site, qui ne se comporte pas de la même façon.
- Prévoir une explication aux clients : une baisse de conversions attribuées n'est pas forcément une baisse de conversions réelles.
C'est probablement le point le plus délicat de l'affaire. Une partie du marketing s'est habituée à des chiffres gonflés par le matching d'emails. Quand ce matching disparaît, les tableaux de bord baissent, et il faut pouvoir dire pourquoi sans donner l'impression de se défausser.
Le malentendu à éviter
Bloquer la résolution d'identité ne met pas fin au pistage. Le stockage côté serveur, le fingerprinting, les murs de connexion et les identifiants first-party restent disponibles. Apple le dit lui-même : la personnalisation par le site n'est pas du pistage. La mesure ferme une porte, pas le couloir.
Deuxième malentendu : croire que le débat est tranché. Une liste noire secrète, sans procédure de recours publique, appliquée à des domaines qui servent aussi à diffuser des annonces légitimes, pose une question de méthode. Et Apple vend de la publicité : l'argument de l'adtech sur un conflit d'intérêts n'est pas absurde, même s'il ne rend pas la pratique de la résolution d'identité plus acceptable.
Reste une incertitude honnête. On ne sait pas si la liste s'allongera, ni si les revenus des éditeurs se stabiliseront une fois les outils adaptés. Une chose est sûre : l'adresse email n'est plus un cookie comme les autres, et les sites qui n'ont pas audité leurs scripts finiront par le découvrir dans leurs chiffres.
