Protection anti-pistage de Safari 27 : ce que ça change pour la mesure des conversions

Safari 27 est sorti en version bêta pour développeurs en juin 2026. Les notes de mise à jour officielles mentionnent des corrections CSS et des améliorations au niveau du rendu. On a creusé un peu plus et on a examiné le code open source de WebKit sur github.com/WebKit/WebKit, l'infrastructure de confidentialité qui gère en fait la façon dont Safari traite les demandes de suivi. Voici ce qu'on a découvert.

Cet article fait suite à notre analyse de Safari 26. Si tu veux en savoir plus sur la protection avancée contre le « fingerprinting » et sur le fonctionnement de la protection contre le suivi des liens, commence par lire cet article-là. Celui-ci présente les nouveautés de la version 27.

Les notes de mise à jour officielles d'Apple pour Safari 27 beta sont disponibles sur le site des développeurs Apple.

Un changement structurel qui aggrave tout le reste

Avant d'entrer dans les détails, il y a un élément tiré de la source qui est important pour bien comprendre tout ce qui va suivre.

Les règles de confidentialité de Safari ne sont pas intégrées au fichier binaire du navigateur. Quels identifiants de clic sont supprimés, quels scripts sont restreints, quelles adresses IP sont bloquées : Apple stocke toutes ces informations dans une bibliothèque système distincte qui se met à jour indépendamment de Safari lui-même. Apple peut ajouter un nouveau domaine de suivi, un nouveau paramètre d’identifiant de clic ou une nouvelle plage d’adresses IP de réseau publicitaire à la liste noire sans avoir à publier de mise à jour du navigateur. N’importe quel appareil sur lequel Safari est installé peut recevoir ces règles mises à jour en arrière-plan, sans que tu t’en rendes compte.

En pratique, ça veut dire que même si Apple ne fait aucune annonce concernant le suivi dans une version donnée de Safari, les règles qui régissent tes campagnes peuvent changer à tout moment. La mise à jour de Safari 27 élargit ces listes, mais la prochaine mise à jour de ces listes pourrait avoir lieu sans annonce publique.

La protection contre le suivi des liens s'étend désormais à davantage de plateformes

Depuis la version 17, Safari supprime les paramètres de suivi connus des URL. En mode de navigation privée, dans Mail et dans Messages, les identifiants de clic disparaissent avant même que la page de destination ne se charge. La liste des paramètres concernés s'allonge à chaque nouvelle version.

Nouveauté dans Safari 27 : trois nouvelles plateformes viennent s'ajouter au filtre :

• Sujets: xmt est dépouillé
• YouTube: « si » est supprimé
• X (anciennement Twitter) : les identifiants « twclid », « cn » et « cxt » sont supprimés

On a déjà parlé des identifiants de clic de Google et de Meta. L'ajout de Threads, YouTube et X est important pour tous ceux qui mènent des campagnes payantes sur ces plateformes.

Le twclid est l'identifiant de clic principal de X, tout comme le gclid l'est pour Google Ads. Le si est un identifiant de source de partage et de session ajouté aux liens de partage YouTube. Ce n'est pas un identifiant de clic payant comme le twclid, mais sa suppression enlève quand même le contexte de source au trafic YouTube dans les sessions Safari. La perte de l'un ou de l'autre dans les sessions Safari crée le même problème d'attribution que les annonceurs Google Ads connaissent déjà à cause de la façon dont Safari gère le gclid.

La mise en place du LTP dans la navigation normale (non privée) sur Safari se poursuit progressivement. À partir de Safari 26, les identifiants de clic ont continué à être transmis dans les sessions standard. Apple a pour habitude d'élargir d'abord la liste, puis d'étendre l'application à la navigation normale lors d'une mise à jour ultérieure. Les paramètres sont en place. L'application à toutes les sessions est la prochaine étape logique.

L'AFP n'est pas un bloc binaire

La plupart des articles sur la fonctionnalité « Advanced Fingerprinting Protection » la décrivent ainsi : « Safari bloque ces scripts ». Le code source donne une image plus détaillée, et c'est important pour comprendre quelles parties de ton suivi sont réellement bloquées.

Quand Apple classe un script comme un outil de « fingerprinting », ça ne se contente pas de le bloquer. Elle attribue à ce script un ensemble précis d'autorisations : une liste de ce à quoi le script a le droit d'accéder et de ce à quoi il n'a pas le droit d'accéder. Les catégories qu'Apple peut révoquer individuellement comprennent :

• Paramètres de requête URL (identifiants de clic, valeurs UTM)
• Données de référence (source du trafic)
• Accès aux cookies
• Accès au stockage local
• API Canvas (une surface couramment utilisée pour le fingerprinting)
• Taille de l'écran et dimensions de la fenêtre d'affichage
• Informations sur la concurrence matérielle
• Demandes réseau

Un script classé comme « confidentiel » peut perdre l'accès aux paramètres d'URL et aux données de référent, tout en conservant la possibilité d'effectuer des requêtes réseau. Il peut aussi se voir interdire l'accès aux API Canvas et audio, tout en conservant l'accès aux cookies. L'impact précis dépend des autorisations qu'Apple retire à ce script en particulier.

Le LinkedIn Insight Tag (snap.licdn.com) figure sur la liste des techniques de « fingerprinting ». Pour le suivi des conversions, les restrictions les plus préjudiciables sont la perte d'accès aux paramètres de requête (impossible de lire l'identifiant de clic) et la perte des données de référent (impossible d'attribuer la source du trafic). Le script peut peut-être encore envoyer une requête réseau aux serveurs de LinkedIn, mais sans les identifiants nécessaires pour associer une conversion à un clic, les données qu’il envoie ne peuvent pas être reliées à une campagne.

Cette liste comprend notamment Tealium, Segment, DPG Media et Blueonic.

Quand une plateforme de données client (CDP) comme Tealium ou Segment est classée comme outil de « fingerprinting », chaque balise qu'elle déclenche est soumise aux mêmes restrictions. Un pixel de conversion déployé via un conteneur CDP soumis à des restrictions perd les mêmes droits d'accès qu'un script directement classé comme tel.

Apple utilise les listes de détection de publicités de Chromium

La source montre que le « Resource Monitor » de Safari, cette fonctionnalité qui bloque des points de suivi entiers plutôt que de simples paramètres, compile ses règles dans le même format que celui utilisé par les extensions de blocage de contenu de Safari. Les données de filtrage proprement dites proviennent de la bibliothèque système d'Apple.

En examinant les règles sur un appareil équipé de la version bêta de Safari 27, on constate que les modèles de blocage correspondent aux entrées de filtre de l'infrastructure open source de détection des publicités de Chromium. Apple utilise les mêmes données de filtrage que celles créées par Google et mises à disposition en open source pour les navigateurs basés sur Chromium.

Source : https://github.com/chromium/chromium-ads-detection

Le blocage s'est déplacé en dessous de la couche application

Dans les versions précédentes de Safari, la protection contre le suivi fonctionnait au niveau de la couche application. Les scripts étaient bloqués ou limités avant même de pouvoir s'exécuter, ou les requêtes réseau étaient bloquées en fonction du nom de domaine. Avec Safari 27, une partie du blocage se fait désormais au niveau de la couche de transport réseau, qui fonctionne en amont de tout ce qui se trouve sur la page.

Quand un script essaie d'envoyer des données de conversion, il ouvre une connexion réseau vers un serveur de destination. Safari 27 intercepte cette connexion avant qu'elle ne soit établie. Pas en analysant le contenu de la requête, mais en comparant l'adresse IP de destination à une liste de sous-réseaux de réseaux publicitaires connus.

Par exemple, bat.bing.com est le point de terminaison UET de Bing. Il renvoie vers l'infrastructure publicitaire de Microsoft. Si la plage d'adresses IP des serveurs publicitaires de Microsoft figure dans la liste noire, la connexion est coupée avant même que des données ne quittent le navigateur. Peu importe d'où vient le script, depuis quel domaine il a été chargé ou comment la requête a été construite.

La configuration de proxys « first-party » est une solution courante qui consiste à charger un script de suivi depuis ton propre sous-domaine. Mais cette solution ne marche pas dans ce cas-là. Le script se charge depuis ton domaine, mais il doit quand même envoyer ses données vers les serveurs d'une plateforme publicitaire. Ces serveurs ont des adresses IP fixes. C'est justement la connexion vers ces adresses IP que Safari bloque.

On trouve également dans le code source des indices indiquant l'existence d'une catégorie distincte de domaines codés en dur comme pouvant être bloqués sans condition, quels que soient les paramètres de confidentialité activés par l'utilisateur. Le mécanisme est visible dans le code ; le contenu précis de cette liste ne l'est pas, puisqu'il se trouve dans un fichier Apple non publié. Considère que l'existence de cette catégorie est avérée, mais que son étendue exacte n'est pas vérifiée.

L'historique des blocages de Safari, couche par couche

Chaque nouvelle version majeure ajoute une nouvelle surface.

• 2017 : l'ITP a instauré des restrictions sur les cookies et des dates d'expiration pour leur stockage
• Safari 17 : l'ATFP a ajouté le blocage réseau au niveau du domaine en mode de navigation privée et la suppression des identifiants de clic dans les liens
• Safari 26 : l'AFP a ajouté la classification des scripts par empreinte digitale dans tous les modes de navigation, avec la possibilité de révoquer les autorisations script par script
• Safari 27 : blocage de plages d'adresses IP au niveau de la couche de transport réseau, filtre d'identifiants de clic amélioré et ajout de CDP à la liste des empreintes numériques

Les mesures de protection précédentes visaient ce que les scripts pouvaient lire ou stocker. Le blocage au niveau du réseau cible les destinations vers lesquelles les données peuvent être transmises. Tu peux modifier le nom d'un fichier de script, un chemin d'accès URL ou un sous-domaine propriétaire. Mais les adresses IP sur lesquelles sont hébergés les serveurs publicitaires de Microsoft ou de LinkedIn ? Celles-là, elles ne changent pas.

La place de TAGGRS

Le GTM server-side modifie l'architecture de telle sorte que les restrictions imposées par Safari au niveau du navigateur n'ont plus d'importance. Pas parce qu'il contourne quoi que ce soit de manière ingénieuse, mais parce que les requêtes de suivi que Safari bloque ne passent jamais par le navigateur.

Avec une configuration standard côté client, le navigateur exécute le script, récupère les informations dont il a besoin sur la page, puis envoie la requête de conversion vers le point de terminaison d'une plateforme publicitaire. La couche réseau de Safari détecte cette connexion sortante et la bloque.

Avec sGTM, le navigateur envoie une seule requête à ton propre serveur, sur ton propre sous-domaine, à ta propre adresse IP. À partir de là, c'est le serveur qui s'occupe de tout. Il traite les événements et transmet les données à Google, Meta, LinkedIn ou Bing via des appels de serveur à serveur qui ne passent jamais par le navigateur de l'utilisateur. Safari n'a donc rien à intercepter.

bat.bing.com et snap.licdn.com sont bloqués au niveau du domaine et de l'adresse IP. Avec sGTM, ta configuration n'appelle jamais ces URL depuis le navigateur. Les connexions aux plateformes publicitaires s'effectuent sur le serveur une fois que l'interaction avec le navigateur a déjà été enregistrée.

Le script de suivi amélioré de TAGGRS ajoute une couche de protection supplémentaire : il crypte la requête envoyée par le navigateur au serveur, ce qui empêche les bloqueurs de pub d'identifier la requête comme du trafic de suivi avant même qu'elle ne quitte la page.

Pour LinkedIn, la solution pratique, c'est d'utiliser LinkedIn CAPI via le conteneur sGTM, en remplaçant l'Insight Tag par un appel de conversion server-side. Pour Bing, c'est l'équivalent via l'API Microsoft Ads. Ces deux solutions permettent de ne plus dépendre de l'exécution de scripts côté navigateur, que Safari bloque désormais.

Les avantages s'accumulent. Comme la requête de conversion ne passe jamais par le point de terminaison d'une plateforme publicitaire depuis le navigateur, la couche réseau de Safari n'a rien à intercepter, et le blocage n'a tout simplement aucune surface sur laquelle agir.

Tu bénéficies aussi de la propriété des données de première partie : l'événement arrive d'abord sur ton serveur, ce qui te permet de contrôler ce qui est transmis et comment. Les temps de chargement s'améliorent, puisque les balises lourdes côté client sont supprimées de la page. Cette configuration est plus pérenne que les solutions de contournement côté navigateur. Quand Apple élargit sa liste de blocage ou sort une nouvelle version de Safari, une architecture server-side n'a pas besoin d'être mise à jour, car elle n'a jamais dépendu de l'exécution côté navigateur.

Ce qui est déjà menacé

La version stable de Safari 27 sera fournie avec iOS 27 et macOS 27, dont la sortie est prévue plus tard en 2026. L'analyse de la source permet d'identifier les vulnérabilités avant que la mise à jour ne soit déployée en production.

Campagnes YouTube et X: « si » et « twclid » sont inclus dans le nouveau filtre d'identifiant de clic. L'attribution pour les utilisateurs de Safari qui cliquent sur des liens YouTube ou des publicités X présentera des lacunes une fois que l'application de la politique LTP s'étendra à la navigation classique. YouTube fait partie des plateformes publicitaires les plus fréquentées. « twclid » est le principal identifiant de clic de X. Aucun des deux n'est un cas marginal.

Les CDP qui gèrent les balises de conversion – Tealium et Segment figurent sur la liste des scripts d'empreinte numérique. Tout pixel de conversion ou balise de remarketing déclenché via un CDP soumis à des restrictions hérite des mêmes restrictions d'accès. C'est le CDP lui-même qui devient le point de défaillance, et non la balise en elle-même.

LinkedIn Insight Tag et Bing UET: l'Insight Tag figure sur la liste des techniques de « fingerprinting », et l'accès aux paramètres de requête et aux référents lui a été retiré. Le point de terminaison Bing UET est bloqué à la fois au niveau du domaine et par sous-réseau IP. Ces deux éléments ont été confirmés par l'analyse à la source.

Configurations de proxy « first-party » : le blocage au niveau du réseau de Safari vérifie l'adresse IP de destination, et non le domaine d'origine du script. Un proxy hébergé sur ton propre domaine continue de transférer les données vers les serveurs d'une plateforme publicitaire. C'est la connexion à ces serveurs qui est coupée.

Toutes les solutions de contournement basées sur le navigateur, comme les proxys propriétaires, les scripts renommés ou les nouveaux sous-domaines, se trouvent du mauvais côté de la barrière que Safari a désormais érigée. Le suivi server-side fait disparaître complètement les données de conversion de ces interfaces ; il ne reste donc plus rien que Safari puisse intercepter.

Si tu veux voir comment cette configuration fonctionne concrètement, notre analyse de Safari 26 te présente en détail l'architecture sGTM.

Prêt à te lancer dans le suivi server-side ? Crée un compte TAGGRS gratuit.

FAQ

Est-ce que Safari bloque vraiment les traceurs ?

Oui. Safari bloque à plusieurs niveaux : restrictions sur les cookies (Intelligent Tracking Prevention), blocage réseau au niveau des domaines en mode de navigation privée (Private Browsing 2.0), restrictions sur les scripts d'empreinte numérique (notes de mise à jour de Safari 26.0 issues de WebKit), et le blocage de plages d’adresses IP au niveau de la couche de transport réseau dans Safari 27 (confirmé par l’analyse du code source de WebKit, mais pas encore mentionné dans les notes de mise à jour publiques d’Apple). Le suivi via le navigateur pour les utilisateurs de Safari devient de moins en moins fiable à chaque nouvelle version. Les configurations server-side ne sont pas affectées, car aucune requête de suivi ne passe par le navigateur.

Quels paramètres Safari 27 supprime-t-il des URL ?

En mode de navigation privée et lorsque des liens sont ouverts depuis Mail ou Messages, Safari supprime une liste de plus en plus longue de paramètres d'identification de clic grâce à la protection contre le suivi des liens. Apple explique le fonctionnement ici : les paramètres de requête de suivi connus sont supprimés avant la navigation, et les scripts tiers sur la page de destination ne peuvent pas lire l'URL complète. Nouveautés dans Safari 27 : xmt (Threads), si (YouTube), twclid, cn, cxt (X/Twitter). Les paramètres déjà pris en charge incluent gclid, fbclid et msclkid. Pour comprendre pourquoi les identifiants de clic dans les URL sont si importants, jette un œil à l'article de WebKit sur l'ITP 2.3 consacré à la « link decoration ». Les paramètres UTM standard (utm_source, utm_medium, utm_campaign) ne sont pas concernés.

Est-ce que ces changements vont aussi avoir un impact sur la navigation habituelle dans Safari ?

La protection contre le suivi des liens en navigation normale (non privée) est en cours de mise en place progressive. À partir de Safari 26, les identifiants de clic sont toujours transmis lors des sessions standard. Safari 27 élargit la liste des filtres, mais Apple a tendance à déployer cette fonctionnalité par étapes. Les utilisateurs peuvent déjà choisir de bénéficier des protections renforcées de la navigation privée pour toutes les sessions grâce à la « Protection avancée contre le suivi et l'empreinte numérique » (à régler sur « Toute la navigation » dans les réglages de Safari ; voir le guide Safari d'Apple). L'application complète de ces mesures à toutes les sessions, même sans activer cette option, est la direction vers laquelle Apple s'oriente.

C'est quoi l'AFP, et est-ce que ça bloque complètement un script ?

L'AFP (Advanced Fingerprinting Protection) classe les scripts comme des outils de « fingerprinting » et applique à chacun d'entre eux un ensemble spécifique de restrictions d'accès. Il ne s'agit pas d'un blocage total. L'annonce de Safari 26.0 par WebKit décrit ce qui est restreint : les API qui révèlent les caractéristiques de l'appareil (taille de l'écran, concurrence matérielle, canvas, audio), le stockage géré par des scripts (cookies, localStorage) et les données de navigation (paramètres de requête, document.referrer). Apple peut en révoquer certaines tout en laissant d’autres intactes. L’impact concret dépend des accès qu’Apple révoque pour ce script en particulier. La version originale de la navigation privée est expliquée dans la section « Advanced Fingerprinting Protection » de WebKit.

Quelle est la différence entre l'AFP et l'ATFP ?

L'AFP (Advanced Fingerprinting Protection) limite l'accès aux scripts de fingerprinting classés comme dangereux. L'ATFP (Advanced Tracking and Fingerprinting Protection) est le paramètre de Safari accessible à l'utilisateur qui, lorsqu'il est activé, étend les protections de la navigation privée (notamment la suppression des paramètres des liens et le blocage des traceurs au niveau du domaine) à la navigation normale. L'article de WebKit sur la navigation privée 2.0 aborde ces deux aspects : l'AFP gère les restrictions des scripts d'empreinte numérique, tandis que le bouton « Protection avancée contre le suivi et l'empreinte numérique » permet de choisir si le LTP et le blocage des traceurs s'appliquent en dehors de la navigation privée. L'ATFP est activée par défaut uniquement en navigation privée. Les protections AFP ont été étendues à toutes les sessions dans Safari 26. Tu trouveras la présentation d'Apple de ces fonctionnalités pour les particuliers sur apple.com/privacy/features.