Résolution d’identité : Safari coupe la clé e-mail de vos campagnes

Une adresse e-mail saisie dans un formulaire d’inscription ne vaut plus, sur un iPhone à jour, ce qu’elle valait il y a six semaines. Le 19 octobre, l’équipe WebKit a publié la justification d’un blocage entré en vigueur avec les versions 27 d’iOS, iPadOS, macOS et visionOS : Safari refuse désormais les connexions réseau vers les prestataires de « résolution d’identité », ceux qui transforment une adresse e-mail en identifiant de pistage réutilisable ailleurs.

La nouvelle a circulé comme un sujet d’adtech. Elle en est un. Mais le mécanisme visé est exactement celui sur lequel reposent une partie des dispositifs de ciblage vendus aux directions commerciales B2B, et la note de WebKit mérite d’être lue par ceux qui achètent ces dispositifs, pas seulement par ceux qui les vendent.

Le mécanisme visé, décrit par Apple

La description donnée par John Wilander, Charlie Wolfe et Matthew Finkel est précise. Un tiers présent sur la page, invisible pour le visiteur, récupère l’adresse e-mail au moment où celui-ci la saisit : connexion, abonnement à une newsletter, création de compte. Ce tiers conserve l’adresse, fabrique un identifiant persistant qui lui est attaché, et renvoie cet identifiant au site. L’identifiant circule ensuite d’un site à l’autre.

Deux points de la note méritent d’être relevés, parce qu’ils ne relèvent pas du ciblage publicitaire mais de la gouvernance des données :

• se déconnecter ou se désabonner ne supprime ni l’identifiant ni l’adresse détenue par le tiers ;
• même un résolveur qui ne traite les données que d’une seule entreprise reste, techniquement, un tiers détenant des données multi-sites — ce qui lui donne une capacité de recoupement qu’aucun éditeur de site n’a isolément.

Le blocage s’applique au nom de domaine. Changer la structure d’une requête ne permet donc pas de le contourner. Apple ne publie pas la liste des domaines concernés et n’explique pas comment ils ont été retenus.

Qui est visé

La note WebKit ne nomme personne. Le signalement technique du 21 septembre, à l’origine du dossier et déposé par un ingénieur de The Trade Desk, mentionnait neuf domaines rattachés à UID2, ID5, LiveRamp, Permutive et Audigent. Le domaine principal de The Trade Desk, adsrvr.org, dont le blocage empêchait l’affichage des publicités sur Safari, a été retiré de la liste dans une version de test.

L’ampleur mesurée aujourd’hui

Les chiffres disponibles viennent d’Aditude, un prestataire de monétisation, et décrivent donc le point de vue des éditeurs, pas celui des annonceurs B2B.

Un point de revenu, ce n’est rien. C’est le chiffre que retiendra une direction qui cherche à ne rien changer. Le deuxième chiffre est plus intéressant : sur les appareils à jour, l’effet est déjà de dix points. L’écart entre les deux ne tient qu’au rythme de mise à jour, c’est-à-dire à une variable qui se résorbe seule en quelques mois.

Ce que cela change pour une campagne B2B

Le raisonnement n’est pas dans la note d’Apple, qui parle de vie privée et pas de prospection. Il est néanmoins direct : si le ciblage d’un compte repose sur le rapprochement d’un fichier d’e-mails avec un identifiant fourni par un tiers, ce rapprochement ne se produit plus sur une session Safari 27. La requête d’enchère part sans identifiant, le segment ne se reconnaît plus, et la portée baisse sur les appareils Apple.

Trois conséquences pratiques, à distinguer selon ce qui porte réellement votre dispositif.

• Le matching d’e-mails via un tiers devient peu fiable sur l’écosystème Apple. Un plan média ABM dont la promesse de couverture s’appuie dessus doit être réévalué, pas reconduit.
• La personnalisation par le site lui-même n’est pas concernée : Apple indique explicitement que ce n’est pas la cible de la protection. Ce qui vaut pour votre site vaut pour vos données propriétaires — et renforce l’intérêt d’un référentiel interne solide plutôt que d’une clé louée à un tiers. C’est le même arbitrage que celui qui se joue sur la qualité de l’enrichissement à l’entrée du CRM.
• Le poids relatif du contact humain remonte. Dans un parcours d’achat où douze des dix-sept mois se déroulent sans échange avec un fournisseur, le ciblage publicitaire était l’un des rares leviers d’existence pendant cette phase. Un levier qui s’affaiblit sur une partie du parc.

Ce que la source ne dit pas

Trois limites, à poser avant d’en tirer une stratégie. La note WebKit ne cite ni Google ni Meta, et ne tranche donc rien sur les balises de ces plateformes. Elle ne traite pas des adresses hachées. Et les mesures d’impact citées plus haut sont celles d’un acteur de la monétisation publicitaire grand public : aucune donnée publique ne chiffre, à ce jour, l’effet sur des campagnes strictement B2B, dont les volumes et les mécaniques diffèrent.

Trois questions à poser à votre agence ou à votre équipe

1. Quelle part de notre audience adressable repose sur un identifiant fourni par un prestataire tiers, et lequel ?
2. Que devient la couverture annoncée dans notre plan média si on en retire les sessions Safari ?
3. Nos remontées de données passent-elles par le navigateur ou par un flux serveur à serveur — et qui, chez nous, sait répondre à cette question ?

La troisième est la plus utile. Dans beaucoup d’organisations, personne n’en connaît la réponse, et c’est précisément ce qui rend ce type de blocage coûteux : il ne casse pas un outil identifié, il dégrade silencieusement un indicateur de couverture que plus personne ne rapproche de sa source.

Référence : la note de l’équipe WebKit du 19 octobre 2026, et le compte rendu détaillé publié par le Blog du Modérateur le 22 octobre.