Article mis à jour en octobre 2026 avec Safari 26 et Safari 27.
Apple a été le premier acteur majeur du web à placer la protection de la vie privée au cœur de sa stratégie. Bien avant la vague RGPD et le feuilleton des cookies tiers sur Chrome, la marque à la pomme avait déjà enclenché un mouvement de fond : réduire les capacités de suivi des utilisateurs.
Depuis près de vingt ans, les équipes marketing et data voient donc leurs outils d’attribution, d’analyse et de tracking évoluer au rythme des décisions d’Apple. Retour sur les grandes étapes de cette révolution, de Safari à iOS 14.5, iOS 16.4, puis Safari 26 et 27. Avec pour chaque avancée importante un vrai point d’étape sur les solutions tracking et analytics mises en place.
Une première étape dès 2005 (!!)
Dès 2005, Safari devient le premier navigateur à bloquer par défaut les cookies tiers. Cette décision, passée relativement inaperçue à l’époque, marque pourtant une rupture fondamentale : alors que l’écosystème publicitaire repose presque exclusivement sur les cookies tiers utilisés pour suivre la navigation des internautes, Apple prend une première décision forte.
En pratique, la mise en place de cette mesure signifie que les régies et plateformes de tracking ne peuvent plus « suivre » un internaute de site en site à travers les cookies tiers. Les premières versions de Safari ont donc réduit, avant tout le monde, la capacité de cibler et de mesurer précisément les campagnes.
Cette orientation, longtemps isolée, deviendra pourtant la norme : Firefox, Brave et d’autres suivront le mouvement des années plus tard. Chrome, lui, a finalement décidé de conserver les cookies tiers. Pour Apple, c’est le début d’une longue histoire d’ajustements techniques visant à restreindre les pratiques intrusives sans altérer l’expérience utilisateur.
IOS 14.5, un tournant en 2021
Si Apple a toujours limité le tracking sur Safari, c’est iOS 14.5, sorti en 2021, qui a véritablement bouleversé l’écosystème publicitaire. Avec la mise à jour iOS 14.5, deux dispositifs sont venus durcir les règles :
- ATT (App Tracking Transparency), côté applis, qui oblige les applications à demander explicitement à l’utilisateur s’il accepte d’être suivi ;
- ITP (Intelligent Tracking Prevention), côté web, qui encadre toujours plus strictement la durée de vie et la portée des cookies.
La combinaison des deux a eu un effet majeur sur la mesure des performances publicitaires.
Avant iOS 14.5, lorsqu’un internaute cliquait sur une publicité Meta Ads ou Google Ads via un outil de la suite Apple, la plateforme déposait via le pixel ou la balise un cookie dit « first party ». Ce cookie servait à reconnaître l’utilisateur et à attribuer une conversion à une source.
Mais en 2021, Apple a mis en place de nouvelles règles qui ont profondément restreint le fonctionnement des cookies.
Depuis, tous les cookies créés via JavaScript sont concernés : leur durée de vie dépend de la provenance du trafic. Ainsi, lorsqu’un cookie est associé à une source publicitaire — comme un clic provenant d’une régie ou d’un lien comportant des paramètres de suivi — sa durée est limitée à 24 heures. Pour les visites dites « naturelles » (SEO, accès direct, etc.), cette durée peut aller jusqu’à 7 jours maximum.
Seuls les cookies HTTP échappent à ces restrictions.
Résultat :
- Les plateformes comme Meta Ads ou Google Ads ont perdu une grande partie de leur capacité à attribuer correctement les conversions ;
- Les solutions analytiques ont vu une explosion artificielle des « nouveaux utilisateurs » ;
- Les CMP (Consent Management Platforms) se redéclenchent fréquemment, puisque les cookies de consentement expirent eux aussi plus vite.
iOS 14.5 a donc marqué la fin d’une ère : celle du tracking web « persistant ».
Face à IOS 14.5, la solution server side
Pour « contourner » ces restrictions, la solution réside dans la mise en place d’une nouvelle approche : le server-side tracking. L’idée est simple : plutôt que de laisser le navigateur (et donc Apple) gérer la création et la durée de vie des cookies, on transfère une partie du travail côté serveur.
Les cookies peuvent alors être écrits par le serveur via le protocole HTTP, et non par du JavaScript exécuté dans le navigateur. Comme ces cookies sont considérés comme plus « techniques » (liés à la sécurité ou au fonctionnement du site), ils échappent alors aux limites imposées par ITP.
Cette approche a connu un essor rapide :
- Google a lancé GTM Server-Side ;
- Meta a renforcé sa Conversions API ;
- De nombreuses solutions comme Addingwell proposent désormais des passerelles hybrides.
Bon à savoir : le tracking server-side ne sert pas seulement à contourner les blocages : il sert aussi à améliorer la vitesse de chargement, la fiabilité des données et la conformité RGPD (en maîtrisant ce qui transite).
IOS 16.4, une nouvelle mise en place d’Apple pour la protection des données
En mars 2023, Apple déploie iOS 16.4 — et avec lui, une nouvelle itération d’ITP. Jusque-là, les cookies déposés par un serveur « first-party » pouvaient conserver une durée de vie normale. Désormais, Safari vérifie l’adresse IP du serveur qui écrit le cookie :
- Si l’IP correspond à celle du site, le cookie est conservé ;
- Si elle diffère trop, le cookie est considéré comme suspect et sa durée de vie tombe à 7 jours maximum.
Concrètement, cela signifie que les serveurs de tracking externes — souvent hébergés sur des infrastructures distinctes (AWS, Cloud, etc.) — ne peuvent plus définir de cookies longue durée au nom d’un site. Cette mise à jour a de nouveau rebattu les cartes : les stratégies server-side « classiques » sont encore intéressantes mais ne suffisent plus à collecter l’ensemble des données. Il faut désormais s’assurer que le serveur de tracking partage la même IP ou du moins la même zone réseau que le site web concerné.
Pour contourner cette nouvelle contrainte, les spécialistes du tracking ont mis en place une solution : le reverse proxy. L’objectif est de faire transiter le serveur de tracking et celui du site par une même adresse IP. À l’aide d’un reverse proxy (comme Cloudflare, par exemple), le trafic entre le visiteur et le serveur est redirigé de façon à ce que Safari perçoive l’ensemble comme provenant d’une seule et même source. Résultat : les cookies ne sont plus raccourcis.
Cette approche demande une grande rigueur : gestion de la conformité, sécurité, scalabilité et documentation doivent impérativement être mis en place.
Le lien avec le server-side
La frontière entre le server-side et le reverse proxy n’est pas évidente pour les non-initiés. En pratique, beaucoup d’entreprises combinent les deux :
- Le tracking s’effectue côté serveur (pour fiabiliser la collecte) ;
- Le reverse proxy assure la cohérence IP pour éviter la purge des cookies.
Cependant, Safari va encore plus loin : en navigation privée, certains scripts connus de tracking sont bloqués en amont, et les identifiants de clic (gclid, fbclid) sont retirés des URL. Cela complique encore davantage la collecte et rend l’attribution très difficile sur ces sessions.
La seule parade consiste alors à utiliser des API de conversion avancées : lorsqu’un utilisateur remplit un formulaire ou passe commande, certaines plateformes peuvent rapprocher les informations (comme l’email, haché) avec leurs bases pour reconstituer une attribution probabiliste. Mais dans l’ensemble, la navigation privée reste un angle mort difficilement contournable.
Safari 26 : les scripts de tracking sous surveillance
Avec Safari 26, sorti en septembre 2025, Apple étend sa protection contre l’empreinte numérique (fingerprinting) à toutes les sessions, et plus seulement à la navigation privée. Concrètement, Safari classe certains scripts comme des outils de pistage et leur retire une partie de leurs droits : lecture des paramètres d’URL (donc des identifiants de clic et des UTM), du référent, de certaines informations sur l’appareil ou du stockage.
Ce n’est pas un blocage total : un script peut continuer à envoyer des requêtes… sans les informations qui permettent de relier une conversion à une campagne.
Safari 27 : le blocage descend au niveau du réseau
Safari 27, déployé à l’automne 2026 avec iOS 27 et macOS 27, franchit une nouvelle étape :
- Un blocage au niveau du réseau. Safari ne se contente plus de bloquer des scripts : il peut couper une connexion en vérifiant l’adresse IP de destination. Charger un script depuis votre propre domaine ne suffit plus si les données partent ensuite du navigateur vers les serveurs d’une plateforme publicitaire. C’est aussi la limite du Google Tag Gateway : il change le domaine du script, mais l’envoi des données reste fait par le navigateur.
- Plus d’identifiants de clic supprimés. Après ceux de Google, Meta et Microsoft, la liste des paramètres retirés des liens en navigation privée s’étend à X, YouTube et Threads.
- Les emails envoyés depuis le navigateur dans le viseur. Safari coupe les requêtes vers certains services qui transforment un email en identifiant publicitaire. Les pixels Google et Meta passent encore, mais le mécanisme visé est exactement celui des conversions avancées configurées côté navigateur.
- Des règles qui changent sans prévenir. Les listes utilisées par Safari sont mises à jour indépendamment du navigateur. Les règles du jeu peuvent donc évoluer sans nouvelle version ni annonce.
La tendance est claire : tout ce qui part du navigateur vers une plateforme publicitaire est de plus en plus fragile sur Safari. Ce qui passe par votre serveur, beaucoup moins.
Comment s’adapter dès aujourd’hui ?
Face à ces évolutions successives, la meilleure stratégie reste l’anticipation. Voici quelques bonnes pratiques concrètes :
- Mettre le consentement au centre. S’assurer que la CMP déclenche correctement les balises, en fonction du choix réel de l’utilisateur. Un tracking sans consentement explicite est désormais aussi risqué qu’inefficace.
- Adopter un server-side conforme. Utiliser le server-side pour fiabiliser la donnée, pas pour la cacher.
- Faire passer les données sensibles par le serveur. Emails et téléphones hachés pour les conversions avancées Google Ads, la CAPI Meta, TikTok ou LinkedIn : envoyés depuis votre serveur, toujours avec le consentement, plutôt que depuis le navigateur.
- Diversifier les signaux d’attribution. Intégrer les API de conversion, les identifiants déclaratifs (emails hachés, logins), et la modélisation statistique pour compléter les données manquantes.
- Surveiller vos chiffres Safari. Comparez régulièrement vos taux de conversion Safari et Chrome dans GA4 : un écart qui se creuse après une mise à jour est le premier signal à traiter. C'est d'ailleurs l'un des points de ma checklist tracking avant le Black Friday.
- Faire appel à une agence de tracking server-side dédiée. Le tracking et la webanalytics représentent des enjeux conséquents : faites-vous accompagner pour avoir une longueur d’avance sur vos concurrents.
En conclusion
Ce qu’Apple a enclenché il y a vingt ans avec Safari est devenu une lame de fond. Ce n’est plus un simple durcissement technique : c’est une redéfinition complète de la webanalyse.
Aujourd’hui, les solutions existent — server-side, reverse proxy, conversions API, modélisation — mais elles ne doivent pas être vues comme des échappatoires. Le server-side ne sert pas à contourner Safari : il sert à ne plus dépendre du navigateur pour vos données les plus précieuses. Une nouvelle façon d’envisager la donnée : plus sobre, plus maîtrisée, plus éthique.
Si vous voulez savoir ce que Safari coûte réellement à votre tracking, vous pouvez prendre 20 minutes avec moi.
