En octobre 2025, Google a discrètement enterré le Privacy Sandbox. Six ans de développement, trois API phares — Topics, Protected Audience (ex-FLEDGE) et Attribution Reporting — remisées d'un coup. Et quelques mois plus tôt, en avril 2025, la firme renonçait déjà à supprimer les cookies tiers de Chrome : pas de dépréciation, pas même le fameux prompt de choix utilisateur.
Sur le papier, c'est une bonne nouvelle pour les équipes techniques : les cookies tiers restent là, le statu quo est préservé, rien à refaire. Sauf que non. Ce « répit » est un piège, et votre collecte de données est probablement plus fragile aujourd'hui qu'il y a deux ans.
Voici pourquoi — et comment on répare ça côté serveur.
Le faux répit des cookies tiers
Chrome garde les cookies tiers, certes. Mais Chrome n'est pas le seul navigateur, et les cookies tiers étaient déjà à moitié morts avant même l'histoire du Privacy Sandbox.
- Safari bloque les cookies tiers par défaut depuis 2020 (Intelligent Tracking Prevention), et raccourcit la durée de vie des cookies first-party posés en JavaScript à 7 jours, voire 24 h dans certains cas.
- Firefox applique le même blocage par défaut via l'Enhanced Tracking Protection.
- iOS / App Tracking Transparency ampute une partie du signal dès que l'utilisateur refuse le suivi — c'est-à-dire la grande majorité.
- Bloqueurs de pub et extensions coupent purement et simplement le chargement de vos balises.
- RGPD et refus de consentement : chaque « Tout refuser » est un événement que votre pixel client-side ne verra jamais.
Autrement dit : même si Chrome ne bouge pas, une part majeure de votre trafic — Safari et iOS en tête — échappe déjà à la mesure côté navigateur. Le pixel qui se déclenche dans le navigateur est devenu la partie la moins fiable de votre chaîne de collecte. Décision de Google ou pas, le problème reste entier.
La vraie réponse : déplacer la collecte côté serveur
L'idée tient en une phrase : au lieu d'envoyer les événements directement du navigateur vers Google, Meta, TikTok & co, on les envoie d'abord vers votre propre serveur, qui les relaie ensuite aux plateformes.
Trois briques, complémentaires :
1. Un conteneur GTM server-side
Le navigateur envoie l'événement à un endpoint que vous hébergez (votre sous-domaine, ex. sgtm.exemple.com). Le conteneur server-side reçoit, enrichit et redistribue. Bénéfices concrets : les cookies sont posés en first-party côté serveur (durée de vie préservée, hors de portée de l'ITP), la charge JavaScript côté client diminue, et vous reprenez le contrôle sur ce qui part réellement — et vers qui.
2. Le Consent Mode, câblé pour de vrai
Depuis mars 2024, le Consent Mode v2 est exigé dans l'EEE pour tout annonceur qui exploite les audiences Google. Bien paramétré, il vous laisse continuer à modéliser les conversions même quand l'utilisateur refuse, dans les clous du droit :
// À poser AVANT le chargement de gtag, état par défaut = refus
gtag('consent', 'default', {
ad_storage: 'denied',
ad_user_data: 'denied',
ad_personalization: 'denied',
analytics_storage: 'denied',
wait_for_update: 500
});
// Puis, après le choix de l'utilisateur dans la CMP :
gtag('consent', 'update', {
ad_storage: 'granted',
analytics_storage: 'granted'
});
La subtilité, c'est que « bien paramétré » cache un vrai travail d'articulation entre votre CMP (Axeptio, Cookiebot, Didomi…), GTM et les plateformes. Un Consent Mode mal branché, c'est soit de la donnée perdue, soit un risque juridique.
3. La déduplication via event_id
Dès qu'on envoie le même événement par deux canaux — le pixel navigateur et l'API serveur (Conversions API de Meta, par exemple) — il faut éviter de compter deux fois. La clé, c'est un identifiant d'événement partagé entre les deux envois :
// Côté navigateur (pixel Meta)
const eventId = crypto.randomUUID();
fbq('track', 'Purchase', { value: 79.90, currency: 'EUR' }, { eventID: eventId });
// Le MÊME eventId part côté serveur (CAPI), et Meta dédoublonne
// server: POST /events { event_name: "Purchase", event_id: eventId, ... }
Même logique pour la TikTok Events API ou l'Enhanced Conversions de Google Ads. Sans ce fil rouge, vos chiffres gonflent artificiellement et vos algorithmes d'enchères apprennent sur du bruit.
Le vrai coût, c'est l'ingénierie et la recette
Rien de tout ça n'est magique, et surtout rien n'est « configure-and-forget ». La collecte server-side, c'est de l'infrastructure (un conteneur à héberger, à monitorer, à mettre à jour), un plan de marquage à formaliser, et surtout une recette systématique : vérifier balise par balise que chaque événement se déclenche au bon moment, avec les bons paramètres, dans le respect du consentement. C'est cette recette qui sépare une mesure qu'on croit fiable d'une mesure qui l'est réellement.
C'est aussi pour ça que beaucoup d'équipes e-commerce — surtout sur des stacks comme Sylius, Shopify ou Magento — préfèrent déléguer cette partie à une agence tracking spécialisée plutôt que d'y engloutir le temps de leurs devs. Le choix vous appartient ; l'important est de ne pas laisser le sujet de côté sous prétexte que « Google a fait marche arrière ».
En résumé
- Le Privacy Sandbox est mort (octobre 2025), les cookies tiers survivent dans Chrome — mais ça ne restaure ni le signal Safari/Firefox, ni celui perdu au consentement.
- Le pixel côté navigateur est devenu la brique la moins fiable de votre collecte.
- La réponse durable : collecte server-side + Consent Mode câblé proprement + déduplication
event_id. - Ce n'est pas un réglage, c'est un chantier d'ingénierie avec une recette rigoureuse à la clé.
Et vous, où en êtes-vous sur le passage au server-side ? Vous l'avez déjà déployé, ou le pixel client-side tourne encore seul ? 👇
Top comments (0)