Safari 27 : ce qui casse vraiment dans votre tracking

Safari 27 sort avec iOS 27 le 14 septembre 2026, et depuis juillet votre fil LinkedIn répète la même prophétie : le tracking va s’effondrer, migrez en server-side tout de suite. Avant de dépenser un budget, une info qui change tout : les notes de version officielles d’Apple ne parlent que de CSS et de rendu. Rien sur le tracking. Tout ce qui circule sur l’impact de Safari 27 sur le tracking vient de l’analyse du code source WebKit, publiée pour l’essentiel par des hébergeurs sGTM, c’est-à-dire par des gens qui vendent la solution au problème qu’ils décrivent. Cet article fait le tri : ce qui est confirmé par Apple, ce qui est seulement observé dans le code, ce qui relève du FUD commercial. Puis il donne la seule chose que les autres oublient : la méthode pour chiffrer votre propre exposition avant de rearchitecturer quoi que ce soit.

Un rappel utile pour calmer le jeu. Avant Safari 26, la même industrie annonçait le strip universel des click IDs. En version stable, ça n’est jamais arrivé. Ceux qui ont paniqué ont dépensé leur budget un an trop tôt.

Trois niveaux de fiabilité, pas un seul

Le problème des contenus qui tournent, c’est qu’ils mélangent trois choses de statut très différent. Voici la grille que j’utilise, et que je vous recommande d’appliquer à tout ce que vous lirez sur le sujet.

Gardez cette colonne “statut” en tête tout du long. C’est elle qui sépare une décision rationnelle d’une réaction de panique.

Ce qu’Apple a réellement publié (confirmé)

Les notes de version de Safari 27.0 bêta (build 20625.1.18, 8 juin 2026) sont publiques. Elles décrivent des nouveautés CSS, des améliorations de rendu, des corrections de moteur. Elles ne mentionnent aucune nouvelle règle de blocage de tracking, aucun changement d’ITP, aucun élargissement de filtre de paramètres d’URL. C’est un point factuel, pas une opinion : sur le tracking, la communication officielle d’Apple pour Safari 27 est, à ce jour, un silence complet.

Ça ne veut pas dire qu’il ne se passe rien. Apple documente rarement ses tours de vis anti-tracking dans les notes grand public. Mais ça veut dire qu’aucune des affirmations alarmistes que vous lisez ne peut se réclamer d’une source Apple. Elles viennent toutes de l’étape suivante.

Safari 27 et le tracking : ce qui est observé dans le code WebKit

Depuis début juillet 2026, plusieurs analyses du code source WebKit décrivent des mécanismes crédibles. Crédibles ne veut pas dire actifs en version stable. Voici les quatre qui reviennent, avec leur portée réelle.

Les blocklists ne vivent plus dans le navigateur

Le changement le plus structurant est aussi le plus discret. Historiquement, les listes de domaines et de paramètres filtrés étaient compilées dans Safari : pour savoir ce qui était bloqué, il suffisait de regarder la version du navigateur. Le code observé déplace ces listes dans une bibliothèque système qui se met à jour indépendamment de Safari.

Concrètement, ça veut dire qu’Apple peut durcir le filtrage sans publier de nouvelle version de Safari, et sans que vous le voyiez passer dans un changelog. Surveiller le numéro de version ne suffit plus. C’est le vrai enseignement de Safari 27, bien plus que n’importe quel paramètre précis : le rythme du durcissement se détache du rythme des mises à jour visibles.

Link Tracking Protection élargi : les click IDs, pas les UTM

Link Tracking Protection retire certains paramètres de tracking des URLs. Le code observé ajoute à la liste historique (gclid, fbclid, msclkid) une série de nouveaux identifiants : twclid, cn et cxt pour X, si pour YouTube, xmt pour Threads.

Le point à marteler, parce que c’est la confusion numéro un : vos UTM ne sont pas concernés. utm_source, utm_medium, utm_campaign ne figurent pas dans ce filtre. Ce qui saute, ce sont les click IDs propriétaires des régies, pas vos paramètres de campagne. Si un article vous dit que Safari 27 “efface vos UTM”, fermez-le : il confond deux mécanismes.

Pour X en particulier, la perte de twclid en navigation Safari a un effet direct sur la déduplication et la qualité du signal côté régie. C’est exactement le cas où la récupération server-side du click ID prend son sens, un sujet que je détaille dans mon guide sur la Conversions API X (Twitter) en server-side GTM.

App-Bound / AFP : une révocation permission par permission

Advanced Fingerprinting Protection n’est pas un interrupteur binaire “bloqué / pas bloqué”. Le mécanisme observé révoque des permissions script par script : accès aux paramètres d’URL, au referrer, aux cookies, au localStorage, au canvas, aux requêtes réseau. Un script classé peut perdre l’accès au referrer mais garder autre chose, selon ce qu’Apple lui attribue.

Sur la liste des scripts concernés reviennent des noms lourds : Insight Tag LinkedIn, Tealium, Segment. Et un piège d’architecture : un tag tiré au travers d’un CDP lui-même classé hérite des restrictions du conteneur. Vous pouvez donc voir un tag “propre” se faire limiter parce qu’il transite par un chargeur classé. Pour LinkedIn, dont l’Insight Tag est directement visé, la sortie propre passe par une Conversions API en flux serveur-à-serveur.

Blocage au niveau du transport (IP de destination)

Le mécanisme le plus lourd de conséquences est aussi le plus radical. Au lieu de filtrer un paramètre ou de brider un script, le code observé vérifie l’IP de destination d’une requête contre des plages d’ad networks, avant même d’établir la connexion. Le domaine bat.bing.com (UET Microsoft) est cité comme exemple.

Pourquoi c’est différent, et pourquoi ça compte pour votre architecture : un blocage au niveau transport ne se contourne pas en renommant un script ou en changeant de sous-domaine, parce qu’il agit sur l’adresse de destination, pas sur le nom que vous donnez à la requête. Pour Microsoft Ads, bat.bing.com visé au niveau domaine et potentiellement au niveau IP fait de la Conversions API Microsoft server-side la vraie porte de sortie. Et ce point rouvre une question que je croyais réglée sur le blog, j’y reviens plus bas.

Ce qui n’est pas vérifié (et qu’on présente comme acquis)

Deux éléments sont régulièrement présentés comme certains alors qu’ils ne le sont pas.

Le premier : la catégorie de domaines “bloquables inconditionnellement”. Le mécanisme est visible dans le code, mais le contenu de la liste vit dans un fichier Apple non publié. On voit la serrure, pas ce qu’elle enferme. Affirmer “tel domaine sera bloqué” relève de la supposition, pas du constat.

Le second : l’application de Link Tracking Protection en navigation normale. Historiquement, Apple déploie ces filtres par étapes, souvent d’abord en navigation privée. En Safari 26, les click IDs passaient encore en session standard. Rien dans le code observé ne garantit que l’élargissement de LTP s’applique d’emblée à la navigation normale de tous les utilisateurs. Souvenez-vous du faux départ : avant Safari 26, le strip universel des click IDs était annoncé comme imminent, et la version stable ne l’a jamais embarqué.

Chiffrez votre exposition avant d’agir

Voici la partie que personne ne vous donne, et la seule qui compte pour décider. Avant de rearchitecturer, mesurez. Trois chiffres suffisent à transformer une angoisse en arbitrage.

D’abord, la part de Safari dans votre trafic, et surtout dans votre chiffre d’affaires. Une part de sessions ne dit rien : ce qui compte, c’est le CA concerné. Sur l’export BigQuery de GA4, cette requête vous donne les deux, par navigateur :

SELECT
  device.web_info.browser AS browser,
  COUNT(DISTINCT CONCAT(user_pseudo_id, CAST((SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS STRING))) AS sessions,
  ROUND(SUM(ecommerce.purchase_revenue), 2) AS revenue
FROM `votre_projet.analytics_XXXXXX.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260601' AND '20260831'
GROUP BY browser
ORDER BY revenue DESC

Regardez la ligne Safari et rapportez son revenue au total. Si Safari pèse 6 % de votre CA, un durcissement partiel de son tracking n’est pas une urgence stratégique. S’il pèse 40 %, la conversation est différente.

Ensuite, le taux d’arrivée des click IDs. Comparez la proportion de sessions Safari qui arrivent encore avec un twclid ou un msclkid à la même proportion sur Chrome. Un écart marqué mesure directement ce que LTP vous coûte déjà, aujourd’hui, avant même Safari 27.

Enfin, la rotation des client IDs Safari, bon proxy du plafond cookie (7 jours, parfois 24 h). Si un même appareil Safari génère de nouveaux client IDs à un rythme anormal par rapport à Chrome, vos utilisateurs Safari sont déjà largement vus comme “nouveaux” à chaque visite. C’est un problème d’attribution qui existe indépendamment de Safari 27.

Un mot de contexte marché pour calibrer l’enjeu : Safari représente environ 51,8 % du trafic mobile humain aux États-Unis et environ 17,7 % du trafic web mondial. Et surtout, tous les navigateurs iOS utilisent WebKit : Chrome sur iPhone est un habillage au-dessus du même moteur, donc concerné par les mêmes règles. Votre “part Chrome” masque une part iOS qui suit la logique Safari.

Matrice de décision : trois cas, trois réponses

Une fois vos chiffres en main, vous tombez dans l’un de ces trois cas. Ils n’appellent pas la même action.

Le cas du milieu mérite une mise au point, parce qu’il me concerne directement. J’ai un comparatif Google Tag Gateway vs sGTM sur ce blog qui présente le proxy first-party comme une option légère et souvent suffisante. Le blocage au niveau transport, s’il se confirme en stable, affaiblit cet argument : un proxy first-party réécrit le nom de domaine de la requête, mais si Safari filtre sur l’IP de destination en aval, le proxy ne suffit plus à faire passer le tag. Je maintiens l’article, mais j’assume la nuance : sur les régies visées par un filtrage IP, le proxy first-party seul n’est plus une garantie, et seul un vrai flux serveur-à-serveur reprend la main.

Ce que je ne recommande pas

Renommer vos scripts pour tromper une classification. Le blocage transport agit sur l’IP, pas sur le nom, et le renommage se fait rattraper à la prochaine mise à jour de liste système.

Changer de sous-domaine dans l’espoir d’échapper à un filtre. Même logique : vous jouez au chat et à la souris avec une liste qu’Apple met à jour côté serveur, hors de votre contrôle.

Vous précipiter sur une bêta pour “tester en avance”. Ce qui shippe réellement en stable prime sur ce qu’on lit dans le code d’une préversion. Si vous devez tester, testez sur la version publique du 14 septembre, pas avant.

Ce que je ferais, concrètement

Cette semaine, lancez les trois requêtes et posez vos chiffres. La part de CA Safari, le taux d’arrivée des click IDs, la rotation des client IDs. Ces trois nombres décident à votre place, mieux que n’importe quel post alarmiste.

Après le 14 septembre, vérifiez la version stable : ce qui a réellement shippé prime sur la bêta, et l’histoire de Safari 26 rappelle que l’écart entre le code et le déploiement peut être large. Si vos chiffres disent que Safari pèse lourd et que vous êtes encore en client-side ou en proxy first-party seul, planifiez une vraie migration server-side, en dimensionnant l’effort et le budget avant de la lancer, sans urgence factice. Et si vos chiffres disent que Safari est marginal chez vous, la meilleure décision cette semaine est peut-être de ne rien faire, et de garder votre budget pour un problème réel.