En 2026, chaque navigateur majeur applique ses propres restrictions de cookies. L’effet combiné — les plafonds de durée de vie de Safari, le partitionnement de Firefox, plus les bloqueurs de publicités — signifie que le tracking côté client manque 20 à 40 % des visiteurs avant même de tenir compte des taux de consentement. Cette note documente ce que fait chaque navigateur et comment ces restrictions interagissent avec la définition de cookies côté serveur.
Safari : Intelligent Tracking Prevention
L’Intelligent Tracking Prevention (ITP) de Safari applique les restrictions les plus strictes. iOS amplifie sa portée : chaque navigateur sur iOS fonctionne sur le moteur WebKit d’Apple et est soumis à l’ITP.
Plafonds de durée de vie des cookies. Les cookies définis via JavaScript (document.cookie) sont plafonnés à 7 jours. Lorsqu’un utilisateur arrive via un lien contenant des paramètres de tracking comme gclid ou fbclid, ce plafond tombe à 24 heures — Safari les détecte comme des vecteurs de tracking inter-sites et traite la session avec suspicion. Après 30 jours d’inactivité, Safari supprime entièrement toutes les données du site.
Vérifications des adresses IP (depuis Safari 16.4). L’ITP inspecte désormais aussi l’adresse IP de tout serveur qui définit des cookies. Si votre sous-domaine de tracking (par exemple gtm.votredomaine.com) se résout vers une plage d’IP différente de celle de votre site principal, Safari traite ces cookies comme tiers même s’ils sont définis sous votre domaine. Le plafond de 7 jours s’applique que le cookie ait été défini par JavaScript ou un en-tête HTTP.
Ajouts de Safari 17. La protection avancée contre le tracking peut bloquer purement et simplement les domaines CDN de GTM et GA. La Link Tracking Protection supprime les paramètres gclid et fbclid des URLs avant que votre code puisse les lire — le paramètre de tracking n’atteint donc jamais votre tag, et encore moins n’est stocké.
Le multiplicateur iOS. Chaque navigateur sur iOS — Chrome, Firefox, Edge, tout navigateur tiers — fonctionne sur le moteur WebKit d’Apple. Les restrictions ITP s’appliquent à tous les navigateurs iOS, pas seulement à Safari. Cela affecte environ 27 % du trafic mobile quel que soit le navigateur ouvert par l’utilisateur.
Firefox : Total Cookie Protection
Firefox adopte une approche architecturale différente. Plutôt que de plafonner les durées de vie des cookies, il partitionne le stockage des cookies.
Partitionnement des cookies tiers. Les cookies tiers peuvent toujours être définis, mais chaque site de niveau supérieur obtient son propre “bocal à cookies” isolé. Un cookie défini par tracker.example.com sur site-a.com est invisible quand le même utilisateur visite site-b.com. Le tracking inter-sites qui dépend d’identifiants partagés entre domaines est complètement cassé. Mais les durées de vie des cookies first-party ne sont pas restreintes — une distinction qui compte pour évaluer les approches de cookies côté serveur.
Bounce Tracking Protection. En mode Strict, Firefox détecte le tracking basé sur les redirections (où une URL passe par un domaine de tracking lors d’une redirection) et efface les données de ces trackers. Cela affecte certains flux de réseaux publicitaires à affiliés et à redirections multiples.
L’approche de Firefox est sensiblement différente de celle de Safari. Elle cible spécifiquement le cas d’usage du tracking inter-sites plutôt qu’imposer des restrictions générales de durée de vie. Une implémentation analytique first-party qui définit des cookies directement sous votre domaine n’est pas impactée par les restrictions de Firefox de la même façon qu’elle l’est par celles de Safari.
Chrome : l’exception permissive
Chrome maintient les cookies tiers activés par défaut. Après l’effondrement effectif du projet Privacy Sandbox en 2024 — Google a choisi de ne pas supprimer les cookies tiers — la part de marché mondiale d’environ 67 % de Chrome permet encore le tracking cross-site traditionnel par cookies.
La principale restriction est SameSite=Lax comme attribut de cookie par défaut. Cela signifie que les cookies ne voyagent qu’avec les navigations de niveau supérieur (un utilisateur cliquant sur un lien), pas avec les requêtes cross-site intégrées (iframes, appels fetch depuis un script tiers). Pour la plupart des implémentations analytiques, c’est une contrainte mineure plutôt qu’un problème de perte de données.
Chrome est l’exception dans le paysage actuel du secteur. Sa permissivité affecte les chiffres agrégés de perte de données, mais les sites avec une exposition significative à Safari ou aux bloqueurs de publicités voient des pertes que la permissivité de Chrome ne compense pas.
L’effet combiné
Entre les plafonds de Safari (touchant environ 27 % du trafic mobile), le partitionnement de Firefox, et les bloqueurs de publicités (utilisés par environ 31,5 % des internautes mondiaux), le tracking côté client manque réalistement 20 à 40 % des visiteurs pour la plupart des sites. La variance est large car elle dépend de votre mix d’audience.
Les sites avec des démographies jeunes ou un usage mobile élevé tendent vers le haut de la fourchette. Les sites B2B avec un trafic lourd sur desktop et réseau d’entreprise tendent vers le bas — bien que les bloqueurs de publicités soient très concentrés chez les utilisateurs techniques, donc le B2B n’est pas automatiquement à l’abri.
Cette perte de données est la raison fondamentale pour laquelle la définition de cookies côté serveur existe comme pratique technique. Elle résout le problème de Safari ITP spécifiquement en définissant des cookies via un en-tête HTTP depuis un serveur du même domaine plutôt que via JavaScript — contournant ainsi le plafond de 7 jours. Mais elle ne résout pas les bloqueurs de publicités, et elle ne résout pas la vérification des adresses IP introduite dans Safari 16.4 sans infrastructure supplémentaire.
La couche de consentement interagit avec cela indépendamment. Les restrictions des navigateurs réduisent le signal quel que soit le statut de consentement. Le Consent Mode opère en plus du signal restant, réduisant davantage ce que vous observez lorsque le consentement est refusé. Les deux forces se cumulent, et le cadre juridique européen ajoute une dimension de conformité qui contraint ce que vous pouvez faire même avec une infrastructure côté serveur.
La priorisation pratique dépend de la composition de l’audience : part de Safari (répartie mobile/desktop), part iOS et taux de bloqueurs mesuré. Ces chiffres déterminent l’impact relatif de chaque restriction.