Privacy Sandbox Est Mort : Ce Que Cela Signifie pour Votre Stack Analytics

Le 17 octobre 2025, Google a officiellement retiré le cœur de son initiative Privacy Sandbox. Topics, Attribution Reporting, Protected Audience et sept autres API sont en cours de suppression de Chrome et d'Android après six ans de développement, de pression réglementaire et de résistance de l'industrie. Le projet censé remplacer les cookies tiers sans perdre la capacité de mesure s'est terminé sans qu'aucun des deux objectifs ne soit atteint.

Pour les développeurs qui avaient planifié autour de ces API, les conséquences sont immédiates. Pour les développeurs qui ont construit sur des signaux first-party, cela confirme ce que l'architecture impliquait déjà.

Ce qui a été réellement arrêté

Les API retirées couvrent les deux principaux problèmes que Privacy Sandbox tentait de résoudre : le ciblage par centres d'intérêt et l'attribution des conversions.

Topics API remplaçait le profilage comportemental en assignant les utilisateurs à de larges catégories d'intérêt dérivées de l'historique de navigation — entièrement sur l'appareil. Les annonceurs pouvaient demander ces catégories sans jamais voir les données de navigation brutes. En pratique, l'adoption était si faible que Google l'a citée comme raison principale de l'arrêt. Le Private Advertising Technology Working Group du W3C a hérité du problème et travaille sur des normes successrices sans calendrier ferme.

Attribution Reporting API était le remplacement des pixels de conversion qui reposaient sur les cookies cross-site. Elle permettait à un navigateur de faire correspondre de manière privée une impression publicitaire à une conversion sans exposer l'identité de l'utilisateur à l'une ou l'autre partie. L'API était sophistiquée — elle utilisait du bruit de confidentialité différentielle pour empêcher la reconstruction au niveau individuel — mais les éditeurs ont jugé l'impact sur les revenus inacceptable. Le rapport de juin 2025 de la Competition and Markets Authority du Royaume-Uni a constaté que les revenus des éditeurs étaient environ 30 % plus bas en s'appuyant sur les outils Sandbox plutôt que sur les cookies standard.

Protected Audience (anciennement FLEDGE) permettait des enchères de remarketing sur l'appareil. Private Aggregation et Shared Storage permettaient un reporting agrégé entre les sites. Tous disparaissent.

Ce qui reste est une liste plus courte de technologies conservées : CHIPS (Cookies Having Independent Partitioned State), qui partitionne les cookies par site de niveau supérieur ; FedCM, qui rationalise la fédération d'identité sans suivi cross-site ; et Private State Tokens, qui aident à signaler la fraude sans exposer l'identité. Ce sont des fonctionnalités de plomberie, pas des fonctionnalités de mesure. Elles ne résolvent pas le problème des analytics.

Pourquoi l'arrêt compte pour les analytics

L'échec de Sandbox laisse les analytics sans remplacement natif du navigateur pour le suivi tiers. Les développeurs qui ont construit leur architecture de mesure autour d'Attribution Reporting doivent maintenant la reconstruire. Mais la conséquence la plus significative est structurelle : le navigateur ne tente plus de résoudre la mesure cross-site à votre place.

Safari et Firefox n'ont jamais participé à l'approche Sandbox du tout. L'Intelligent Tracking Prevention d'Apple bloque les cookies tiers par défaut depuis 2020. Firefox a suivi. Chrome a maintenu les cookies tiers en vie en 2024 précisément parce que les alternatives Sandbox ne pouvaient pas égaler leur valeur de mesure — et désormais ces alternatives ont disparu aussi.

L'effet net est que le suivi cross-site des utilisateurs, avec ou sans cookies, n'a pas d'avenir fiable dans le navigateur. La voie d'application qui a tué Sandbox (pression réglementaire de la CMA, de l'UE et de l'affaire antitrust du DOJ américain) n'a pas disparu. Tout nouveau schéma d'identifiant cross-site fait face au même examen réglementaire.

L'architecture de données first-party qui demeure

Sans identifiants cross-site, la mesure se scinde nettement en deux catégories.

L'attribution cross-site — connecter une impression publicitaire sur un domaine à un achat sur un autre — n'a pas de solution navigateur préservant la vie privée. La correspondance d'événements côté serveur, la modélisation média-mix et les tests d'incrémentalité sont les outils restants, et tous nécessitent une infrastructure et une sophistication statistique au-delà de la plupart des produits construits par des développeurs.

Les analytics first-party de site — comprendre le trafic de votre propre site sans le connecter à des identifiants externes — n'ont jamais été le problème que Privacy Sandbox tentait de résoudre. C'était déjà résoluble sans cookies cross-site, et l'arrêt de Sandbox ne change rien à son fonctionnement.

Une architecture analytics first-party minimale traite une requête en périphérie, dérive des signaux agrégés de la requête elle-même et ne stocke rien qui requiert un identifiant inter-appareils persistant. Le pays vient de request.cf.country. Le type d'appareil vient d'un parsing grossier du User-Agent. La famille de navigateur vient du même en-tête de requête. Le domaine référent — pas l'URL complète — vient de l'en-tête Referer. La déduplication des visiteurs au sein d'une journée utilise un hachage côté serveur :

visitor_hash = SHA-256(IP + UA + SALT_SECRET + YYYY-MM-DD)

L'IP et le User-Agent ne sont jamais stockés. Le hachage se réinitialise quotidiennement. Il n'y a pas d'identifiant inter-sessions, pas d'identifiant cross-site, et rien que les protections anti-suivi du navigateur puissent bloquer. Cette architecture n'a pas été conçue comme un contournement de l'échec de Sandbox — elle précède Sandbox et survivra à ce qui viendra ensuite.

À quoi ressemble le calendrier de suppression

Chrome 144 déprécie Topics ; Chrome 150 le supprime. Attribution Reporting et Protected Audience suivent des calendriers similaires par étapes. Si vous exécutez des appels d'API Sandbox en production, auditez-les maintenant — les API renverront des erreurs ou des réponses vides avant que la suppression ne soit complète. Pour les sites sans dépendance à ces API, il n'y a rien à migrer. Les changements de politique du navigateur ne nécessitent aucune réponse lorsque votre modèle de données ne dépend pas d'identifiants gérés par le navigateur.

La leçon de six ans de normalisation ratée

Le projet Sandbox a tenté de résoudre un problème techniquement réel — l'attribution cross-site préservant la vie privée — et a échoué pour une combinaison de raisons : l'impact sur les revenus était trop important, la complexité de l'API était trop élevée pour une adoption large, et les régulateurs au Royaume-Uni et dans l'UE se demandaient si Google pouvait concevoir un système qui améliorait la vie privée des utilisateurs sans renforcer sa propre position concurrentielle.

La leçon n'est pas que la mesure préservant la vie privée est impossible. C'est que la mesure cross-site avec de fortes garanties de confidentialité nécessite un niveau de coordination industrielle et de confiance réglementaire qui ne s'est pas matérialisé dans le contexte du navigateur. Les développeurs qui ont besoin d'une compréhension au niveau du site de leur trafic n'ont pas besoin de cette coordination. Ils ont besoin d'un modèle de données précis sur ce qu'il collecte et honnête sur ce qu'il ne collecte pas.

Les analytics first-party, à portée de session, non persistants ne sont pas un trou en forme de Privacy Sandbox attendant d'être comblé par la prochaine initiative du navigateur. C'est une réponse complète à la question que la plupart des développeurs posent réellement.