Le correctif pour le plafond de cookies JavaScript de Safari est conceptuellement simple : définir des cookies depuis un serveur plutôt que depuis JavaScript. Le plafond de 7 jours de Safari cible spécifiquement les cookies écrits via document.cookie. Les cookies définis via des en-têtes de réponse HTTP Set-Cookie depuis un serveur same-domain sont traités comme des cookies first-party légitimes avec leur durée de vie complète prévue.
C’est le fondement technique derrière le cookie FPID de GTM Server-Side. Comprendre exactement comment cela fonctionne — et où ça casse — est le prérequis pour comprendre pourquoi certains déploiements voient encore des durées de vie de cookies tronquées même après être passés au server-side.
Le mécanisme FPID
Quand GTM Server-Side traite une requête entrante, le client GA4 peut répondre avec un en-tête HTTP Set-Cookie. Cela crée le cookie First Party Identifier (FPID), généralement avec le flag HttpOnly.
Le flag HttpOnly fait deux choses simultanément. Premièrement, il rend le cookie invisible à JavaScript — il ne peut pas être lu par document.cookie dans le navigateur. Deuxièmement, et plus important pour la qualité des données, il évite de déclencher les heuristiques de détection de cookies côté client d’ITP. ITP a appris à identifier les cookies qui ressemblent à des identifiants de suivi quand ils sont écrits par JavaScript sur des domaines à fort trafic ; les cookies HttpOnly contournent entièrement cette classification.
L’avantage de durée de vie est significatif. Alors que les cookies définis par JavaScript sont plafonnés à 7 jours et peuvent tomber à 24 heures quand des paramètres de suivi sont présents dans l’URL, les cookies first-party définis via HTTP peuvent avoir des durées de vie de 90 à 400 jours — selon votre configuration dans l’en-tête Set-Cookie. Pour la précision de l’attribution, la différence entre un cookie de 24 heures et un cookie de 400 jours détermine si un utilisateur qui revient une semaine plus tard est vu comme la même personne ou un nouveau visiteur.
Le problème de l’adresse IP
Safari 16.4 a introduit une complication qui casse de nombreux déploiements server-side : ITP compare désormais l’adresse IP du serveur qui définit le cookie avec l’adresse IP du site web principal.
Si votre sous-domaine de suivi (gtm.votredomaine.com) résout vers une plage d’IP différente de votre site principal (votredomaine.com), Safari traite le sous-domaine de suivi comme tiers quelle que soit la correspondance du nom de domaine. Le plafond de 7 jours s’applique quand même.
Cela compte pratiquement en raison de la structure des déploiements GTM server-side standard. Un déploiement Cloud Run avec un enregistrement CNAME place votre instance sGTM sur l’infrastructure IP de Google, tandis que votre site web se trouve généralement chez un hébergeur différent. Safari voit la non-concordance d’IP et classe le cookie comme tiers. La technique CNAME — utiliser votre propre sous-domaine pour pointer vers le serveur de suivi — résout la vérification du nom de domaine mais pas la vérification de l’adresse IP.
C’est pourquoi passer à GTM server-side seul ne garantit pas la récupération de la durée de vie des cookies sur Safari. L’architecture de déploiement compte.
Trois approches qui résolvent le problème d’IP
First Party Mode (Google)
Le First Party Mode (FPM) de Google, en beta début 2026, route le suivi via une infrastructure qui partage le même contexte IP que votre domaine principal. L’implémentation est gérée via l’infrastructure de Google plutôt que de nécessiter une configuration manuelle de reverse proxy.
L’avantage est la simplicité — Google gère la concordance d’IP. L’inconvénient est qu’il était encore en beta, ce qui signifie une disponibilité limitée, des changements potentiels de l’implémentation, et une dépendance aux délais de Google pour la prise en charge de GA.
Reverse Proxy
Un reverse proxy route à la fois votre site principal et votre sous-domaine de suivi via la même infrastructure. Si votre site est derrière Cloudflare (ou un autre CDN/proxy), vous configurez votre sous-domaine de suivi pour également passer par Cloudflare. Les deux domaines semblent désormais provenir de la même plage d’IP. Safari voit des IP concordantes et traite le cookie comme genuinement first-party.
Cette approche fonctionne avec n’importe quelle infrastructure proxy et ne nécessite pas d’utiliser les programmes beta de Google. Le compromis est la complexité de configuration — vous devez correctement router les requêtes de suivi via le proxy sans perturber le payload de suivi, et les coûts proxy augmentent avec le volume de trafic.
Stape Cookie Keeper
Le Cookie Keeper de Stape adopte un angle complètement différent : plutôt que de résoudre la non-concordance d’IP, il rafraîchit régulièrement les cookies que Safari expirerait autrement. Le service surveille les durées de vie des cookies et les redéfinit avant qu’ils n’atteignent le plafond ITP, étendant effectivement les durées de vie à 90 jours ou 13 mois sans nécessiter de concordance d’adresse IP.
C’est une solution managée par un tiers, ce qui signifie une dépendance à la fiabilité et la tarification du service de Stape. Mais elle contourne entièrement le problème d’architecture IP, ce qui la rend viable pour les déploiements où la configuration du reverse proxy est complexe ou où le First Party Mode n’est pas disponible.
Estimations réalistes de récupération de données
La valeur de résoudre le problème des cookies Safari dépend entièrement de la composition de votre audience. Estimations approximatives de ce que les cookies first-party server-side récupèrent par rapport au client-side uniquement :
- Sites à forte démographie mobile/jeune (où la part de Safari est la plus élevée) : récupération de 25 à 35 % des signaux perdus
- Sites mixtes desktop/mobile : récupération de 15 à 25 %
- Sites B2B lourds en desktop : récupération de 10 à 15 %
Le cadrage plus large : le suivi CNAME first-party capture 95 %+ des sessions contre 60 à 70 % avec des scripts tiers. L’écart est réel mais la borne supérieure dépend de la résolution du problème d’adresse IP, pas seulement du déploiement de GTM server-side.
Choisir un CMP compatible avec le server-side
La définition de cookies server-side n’élimine pas le besoin d’une plateforme de gestion du consentement — elle change l’endroit où le consentement est appliqué. Une fois que vous avez un conteneur server-side, la CMP capture le consentement côté client et transmet les signaux au conteneur serveur via les paramètres Consent Mode. Le conteneur serveur lit ces signaux et décide quels tags déclencher.
Pour les éditeurs de l’écosystème Google, Google exige l’utilisation d’une CMP certifiée avec intégration TCF v2.2 pour les publicités personnalisées en EEE/UK. Les principales options certifiées incluent Usercentrics/Cookiebot, OneTrust, Didomi, CookieYes, Axeptio et Ketch. Lors de l’évaluation, priorisez : le niveau de certification Google, l’intégration native du Consent Mode v2, la prise en charge multi-juridictions (opt-in UE plus opt-out US dans une seule plateforme), la reconnaissance du signal GPC, et un impact de latence sous 500 ms sur les Core Web Vitals.
Le modèle de propagation du consentement server-side est là où cela devient techniquement nuancé : les tags Google gèrent le consentement automatiquement dans le conteneur serveur, mais les tags non-Google (Meta CAPI, TikTok Events API, LinkedIn CAPI) nécessitent des conditions de déclenchement explicites pour appliquer l’état du consentement.
Ce que le server-side ne règle pas
Les cookies server-side résolvent le problème des restrictions navigateur pour Safari ITP. Ils ne résolvent pas :
- Les bloqueurs de publicités : si le bloqueur d’un utilisateur bloque les requêtes vers votre domaine de suivi, server-side ou non, aucune requête n’atteint le serveur. Le cookie n’est jamais défini.
- L’attribution cross-device : un cookie suit un appareil. Un utilisateur qui visite sur iPhone et convertit sur desktop reste deux identités séparées sans infrastructure supplémentaire de résolution d’identité.
- Le suivi post-suppression : si un utilisateur efface ses cookies, l’identifiant first-party disparaît. L’infrastructure server-side peut en définir un nouveau, mais la connexion aux sessions précédentes est rompue.
Ces limites expliquent pourquoi les Conversions Améliorées, UID2 et les data clean rooms existent aux côtés du suivi server-side plutôt qu’en étant remplacés par lui.