Six ans de roadmaps, de conférences et de decks stratégiques construits sur une promesse que Google vient de rayer d’un trait : le Privacy Sandbox est mort en 2026. Début janvier, Chrome 150 a retiré Topics API, Protected Audience et Attribution Reporting API, les trois piliers censés remplacer les cookies tiers. Si vous aviez calé votre roadmap cookieless dessus, vous n’êtes pas seul, et vous avez surtout un problème très concret à régler maintenant. Le souci, c’est que six mois après la fermeture, la plupart des équipes tracking ne savent toujours pas ce qui a réellement disparu, ce qui reste dans le navigateur, et ce qu’il faut faire. Ce guide démêle le vrai du faux, puis vous donne un plan d’action opérationnel pour reconstruire votre mesure sans compter sur Google.
Ce qui est vraiment mort (et ce qui reste)
Avant de paniquer ou de tout casser, il faut poser proprement l’inventaire. Le Privacy Sandbox n’était pas une seule technologie mais une constellation d’APIs, et Google n’a pas tout jeté au même endroit. Voici la vue d’ensemble.
| Statut | Composant | Ce que ça faisait |
|---|---|---|
| Retiré (Chrome 150) | Topics API | Ciblage par centres d’intérêt côté navigateur |
| Retiré (Chrome 150) | Protected Audience (FLEDGE) | Remarketing sans cookies tiers |
| Retiré (Chrome 150) | Attribution Reporting API | Mesure de conversion privacy-first |
| Retiré (Chrome 150) | Private Aggregation, SelectURL, Related Website Sets | Reporting agrégé et partage inter-domaines |
| Conservé | CHIPS | Cookies partitionnés par site (état inter-domaines cloisonné) |
| Conservé | FedCM | Connexion fédérée sans cookies tiers |
| Conservé | Private State Tokens | Signaux anti-fraude et anti-bot |
| Inchangé | Cookies tiers | Toujours présents dans Chrome |
Les APIs enterrées dans Chrome 150
Topics, Protected Audience et Attribution Reporting API formaient le cœur publicitaire du projet. C’est précisément ce qui devait sauver le remarketing et la mesure de conversion dans un monde sans cookies tiers. Tout est parti. Concrètement, si vous testiez un fournisseur adtech qui s’appuyait sur ces APIs, sa techno n’a plus de socle navigateur. Private Aggregation, SelectURL et Related Website Sets, plus discrets, ont suivi dans la même vague.
Ce qui survit dans le navigateur
Trois briques restent bien vivantes, et elles ne sont pas anecdotiques. CHIPS permet de poser des cookies partitionnés par site : utile pour maintenir un état inter-domaines cloisonné, par exemple pour un widget embarqué, sans réintroduire le pistage cross-site. FedCM gère la connexion fédérée (le fameux “se connecter avec”) sans cookies tiers. Private State Tokens sert surtout à distinguer un humain d’un bot, un enjeu réel pour la qualité de vos données. Aucune de ces trois ne remplace le ciblage publicitaire, mais elles restent des outils légitimes à connaître.
Le retournement que personne n’avait vu venir
Voici le point qui génère le plus de confusion, alors soyons clairs. Les cookies tiers n’ont pas disparu de Chrome. Google a abandonné leur suppression en 2024, puis a enterré l’alternative qu’il avait promise pour la remplacer. Autrement dit : ce n’est pas la fin des cookies tiers, c’est la fin du plan B. Vos tags qui reposent encore sur des cookies tiers continuent de fonctionner dans Chrome pour l’instant. Mais “pour l’instant” est le mot important, et c’est exactement la raison pour laquelle il ne faut surtout pas relâcher l’effort cookieless.
Pourquoi Google a tout arrêté
Trois forces ont eu raison du projet. D’abord, l’adoption : l’écosystème adtech n’a jamais vraiment basculé sur ces APIs, jugées trop complexes et trop peu performantes face aux cookies existants. Ensuite, la pression réglementaire : la CMA au Royaume-Uni et la DG Concurrence européenne surveillaient de près un dispositif qui donnait à Google le contrôle des tuyaux publicitaires du web. Enfin, les limites techniques : les résultats de ciblage et de mesure restaient en dessous de ce que promettaient les cookies tiers. Entre un standard imparfait que personne n’adopte et des cookies tiers qui marchent encore, Google a choisi le statu quo.
Ce que ça change concrètement pour votre tracking
C’est là que ça compte. Bonne nouvelle d’abord : pour la majorité des setups GA4 et Google Ads classiques, l’impact immédiat est faible, parce que ces outils ne dépendaient pas du Privacy Sandbox pour fonctionner. La vraie conséquence est stratégique, pas technique. Détaillons.
Impact sur GA4
GA4 ne s’appuyait pas sur le Privacy Sandbox : il continue de collecter, d’attribuer et de rapporter exactement comme avant. Rien ne casse dans vos rapports du jour au lendemain. Ce qui change, c’est le contexte : la promesse d’une mesure “privacy-first” native au navigateur s’évapore, et la responsabilité de la robustesse retombe entièrement sur votre implémentation. Le vrai levier reste le consentement. Si votre Consent Mode v2 est mal réglé, vous perdez des conversions et des audiences, Privacy Sandbox ou pas. C’est aujourd’hui la brique de conformité et de mesure la plus déterminante, et elle n’a pas bougé.
Impact sur l’attribution Google Ads
L’Attribution Reporting API devait offrir à terme une voie de mesure de conversion sans cookies tiers pour Google Ads. Elle n’existe plus. En pratique, Google Ads continue de s’appuyer sur ses signaux habituels : cookies (encore là), Enhanced Conversions et données first-party. Si vous comptiez sur le Privacy Sandbox pour compenser la future perte des cookies tiers, ce plan est caduc. Votre attribution repose désormais sur la qualité de vos signaux serveur, pas sur une API navigateur providentielle.
Impact sur vos Conversions API (CAPI)
C’est peut-être la meilleure nouvelle de l’histoire : les Conversions API n’ont jamais eu besoin du Privacy Sandbox. Elles envoient les conversions de serveur à serveur, en s’appuyant sur des données first-party hachées. La mort du Privacy Sandbox renforce même leur intérêt : elles deviennent la voie la plus fiable pour transmettre vos conversions aux plateformes, indépendamment de ce que fait ou défait le navigateur. Si votre match quality est faible, c’est là qu’il faut investir, pas dans une techno enterrée.
Votre plan d’action post-Privacy Sandbox
Assez de constat, passons au concret. Voici la check-list à dérouler dans l’ordre, de la plus rapide à la plus structurante.
Check-list post-Privacy Sandbox
- Auditez votre Consent Mode v2. C’est le point le plus rentable et le plus rapide. Vérifiez que
ad_storageetanalytics_storageremontent le bon signal depuis la bannière jusqu’au tag. Un réglage cassé ici coûte plus de conversions que toute la fermeture du Privacy Sandbox réunie. - Évaluez le server-side si ce n’est pas déjà fait. Les adblockers coupent plus de 40 % des sessions client-side sur certains marchés (Allemagne, France, tech US). Ce chiffre justifie le server-side à lui seul, totalement indépendamment du Privacy Sandbox. Notre guide GTM Server-Side détaille la migration, et le comparatif Google Tag Gateway vs Server-Side GTM vous aide à choisir la bonne porte d’entrée.
- Activez l’export BigQuery pour modéliser sur vos first-party data. Quand le signal navigateur se fragilise, la donnée brute exportée devient votre meilleure assurance. Notre guide sur l’export GA4 vers BigQuery montre comment transformer ces tables en base de modélisation exploitable.
- Mesurez le match quality de vos CAPI. Un bon EMQ (Meta), un bon match rate (Google) fait toute la différence sur la déduplication et la remontée des conversions. C’est le chantier qui rapporte le plus une fois le server-side en place.
À ces quatre priorités, ajoutez une veille sur les nouveaux enjeux d’attribution qui s’empilent, comme le trafic issu des IA génératives, largement sous-mesuré dans GA4. La problématique cookieless ne vit pas seule : elle s’inscrit dans un paysage de mesure qui bouge vite.
Les trois erreurs à éviter maintenant
J’ai vu passer, ces derniers mois, les mêmes réflexes contre-productifs. Autant les nommer.
Première erreur : croire que “les cookies sont sauvés” et tout arrêter. C’est le contresens le plus fréquent. Les cookies tiers restent dans Chrome, mais Safari (ITP) et Firefox (ETP) les bloquent déjà depuis des années, et les adblockers coupent une part énorme du signal client-side quel que soit le navigateur. La fermeture du Privacy Sandbox ne change rien à cette érosion. Si vous relâchez maintenant, vous ne faites que reporter le problème.
Deuxième erreur : migrer en server-side pour de mauvaises raisons. Le server-side n’est pas une case à cocher parce que “Google a changé d’avis”. C’est un investissement qui se justifie par la récupération de signal et le contrôle de la donnée. Si vous n’avez pas d’abord réglé votre consentement, vous allez server-sidiser un signal déjà cassé en amont. L’ordre compte : consentement d’abord, collecte robuste ensuite.
Troisième erreur : chercher un remplaçant one-to-one du Privacy Sandbox. Il n’y en a pas, et il n’y en aura pas. La bonne mentalité n’est pas “quelle API remplace Topics ?”, mais “comment je construis une mesure qui ne dépend d’aucune API navigateur providentielle ?”. La réponse est un empilement (consentement, server-side, first-party data, CAPI), pas une brique magique.
Ce qu’il faut retenir
Le Privacy Sandbox est mort, mais ce n’est pas une catastrophe pour votre tracking : c’est un rappel. Google ne construira pas votre stratégie de mesure à votre place, et le navigateur ne vous sauvera pas. La bonne réponse n’a pas changé depuis deux ans, la fermeture ne fait que la rendre incontournable : consentement propre, collecte server-side, first-party data structurée dans BigQuery, et CAPI au match quality soigné. Si vous ne deviez lancer qu’une seule action cette semaine, auditez votre Consent Mode v2. C’est là que se cache le plus gros retour sur effort, et c’est la brique sur laquelle tout le reste repose.