Ce que Privacy Sandbox remplace réellement

Les cookies tiers assuraient quatre fonctions publicitaires distinctes : le ciblage par centres d'intérêt, le reciblage, la mesure des conversions et le plafonnement de la fréquence. Privacy Sandbox divise ces fonctions en API séparées, chacune avec son propre profil de consentement.

Topics API — Ciblage par centres d'intérêt

L'API Topics attribue à chaque navigateur un petit ensemble de sujets d'intérêt à granularité grossière — environ cinq sujets par semaine, tirés d'une taxonomie organisée de quelques centaines de catégories. Lorsqu'un éditeur appelle document.browsingTopics(), le navigateur renvoie jusqu'à trois sujets que l'écosystème adtech peut utiliser pour la personnalisation contextuelle sans aucun identifiant intersites. Les sujets sont calculés localement, stockés sur l'appareil, se renouvellent chaque semaine et sont soumis aux contrôles des utilisateurs dans chrome://settings/adPrivacy.

Protected Audience API — Reciblage et remarketing

Protected Audience, anciennement FLEDGE, maintient le reciblage en vie sans identifiant intersites partagé. Les annonceurs font rejoindre à un utilisateur un groupe d'intérêt sur leur propre site ; lorsque l'utilisateur visite un éditeur participant, une enchère sur l'appareil s'exécute dans un Fenced Frame et sélectionne un créatif. L'annonce gagnante est rendue sans que l'éditeur sache quel groupe d'intérêt a correspondu.

Attribution Reporting API — Mesure des conversions

Attribution Reporting remplace les pixels de conversion pour un sous-ensemble de cas d'usage de mesure. Il prend en charge les rapports au niveau des événements (bruyants, avec perte, par conversion) et les rapports récapitulatifs agrégés (cumuls dé-biaisés statistiquement). Contrairement au pixel hérité, il n'expose pas le lien individuel utilisateur-conversion.

Shared Storage et Fenced Frames

Shared Storage est un magasin clé-valeur en écriture partout, lecture en sandbox pour les cas d'usage intersites comme le plafonnement de la fréquence et la cohérence des expériences A/B. Les Fenced Frames sont des iframes isolés qui empêchent la page environnante de lire l'annonce rendue ou ses données d'interaction.

Privacy Sandbox nécessite-t-il un consentement ?

C'est la question la plus mal comprise du paysage adtech 2026, et la réponse est spécifique à la juridiction.

Sous GDPR et ePrivacy

Le Comité européen de la protection des données n'a pas émis de position globale, mais les autorités nationales ont été plus explicites. L'ICO britannique, le Garante italien et la CNIL française ont tous pris la position que Topics et Protected Audience nécessitent un consentement préalable opt-in lorsqu'ils traitent des données personnelles, y compris tout traitement qui écrit ou lit un état sur l'appareil de l'utilisateur. La logique : le navigateur stocke toujours localement les sujets d'intérêt et les groupes d'intérêt, et l'appel document.browsingTopics() transmet des données personnelles inférées à un tiers. Cela est réglementé en vertu de l'article 5(3) de la directive ePrivacy, qui exige un consentement pour tout accès à ou stockage sur l'équipement terminal de l'utilisateur au-delà de ce qui est strictement nécessaire au service demandé.

La position de Google est plus permissive — ils soutiennent que les API sont conçues pour préserver la confidentialité et que les exigences de consentement peuvent ne pas s'appliquer dans tous les contextes. Ce n'est pas une position de régulateur. Traiter Privacy Sandbox comme exempté de consentement en Europe est une posture à haut risque.

Sous CCPA, CPRA et les lois des États américains

Aux États-Unis, les flux Privacy Sandbox sont généralement traités comme un partage d'informations personnelles pour la publicité comportementale en contexte croisé en vertu du CPRA. Cela signifie qu'ils déclenchent le droit d'opposition et doivent être respectés via les signaux Global Privacy Control et d'autres mécanismes d'opposition universels. Le fait que les données Topics soient dérivées du navigateur plutôt que vendues par un courtier tiers ne les exempte pas.

Les propres contrôles de Chrome

Chrome fournit des bascules accessibles à l'utilisateur dans chrome://settings/adPrivacy pour Topics, Protected Audience et Attribution Reporting. Ces choix des utilisateurs se trouvent aux côtés — et non à la place — de l'état de consentement de votre CMP. Un utilisateur qui a dit non aux cookies publicitaires dans votre bannière mais oui à Topics dans les paramètres globaux de Chrome vous a quand même dit non via la bannière. Votre pile doit respecter le plus strict des deux signaux.

La couche de consentement dont vous avez réellement besoin

Une pile de consentement de niveau production pour 2026 traite les API Privacy Sandbox comme des activités de traitement distinctes, chacune contrôlée via les finalités IAB TCF ou des catégories équivalentes de droit des États.

Correspondance des API Sandbox avec les finalités TCF

• Topics API — Finalité 2 IAB TCF (Sélectionner des publicités basiques) et Finalité 3 (Créer un profil de publicités personnalisées) au minimum ; Finalité 4 (Sélectionner des publicités personnalisées) si les sujets alimentent le ciblage.
• Protected Audience — Finalités 3 et 4, plus Finalité 7 (Mesurer les performances des publicités) si l'enchère utilise des données de résultats.
• Attribution Reporting — Finalité 7 (Mesurer les performances des publicités) et Finalité 9 (Comprendre les audiences grâce aux statistiques).
• Shared Storage pour le plafonnement de fréquence — Finalité 3 lorsqu'il alimente la personnalisation, ou une base d'intérêt légitime lorsqu'il s'agit purement de contrôle de fréquence.

Correspondance avec Google Consent Mode v2

Les signaux de Consent Mode v2 de Google correspondent au comportement de Privacy Sandbox :

• ad_storage refusé — désactiver entièrement les appels aux API Topics et Protected Audience
• ad_user_data refusé — bloquer Attribution Reporting de l'envoi de données à portée utilisateur
• ad_personalization refusé — ignorer les entrées Topics dans la logique de ciblage

Gestion des signaux des États américains

Pour le trafic américain, votre couche de consentement doit inspecter Global Privacy Control et les signaux d'opposition des États applicables. Lorsqu'un utilisateur américain s'est opposé au partage, supprimez document.browsingTopics(), n'appelez pas joinAdInterestGroup, et supprimez les en-têtes d'enregistrement d'Attribution Reporting.

Modèles d'implémentation pratiques

Les éditeurs qui ont déjà déployé Privacy Sandbox suivent généralement l'un des deux modèles architecturaux.

Modèle 1 : Orchestration côté serveur

Un gestionnaire de balises propriétaire sur votre origine collecte l'état de consentement, la juridiction de l'utilisateur et les remplacements de signaux, puis rend conditionnellement les hooks Privacy Sandbox dans la page. Le serveur publicitaire et le SSP reçoivent les indicateurs de consentement via la demande d'enchère, et ils décident d'appeler Topics, Protected Audience, ou aucun des deux. Ce modèle centralise la logique et maintient l'état de consentement comme référence.

Modèle 2 : Intégration du wrapper de header bidding

Prebid.js et d'autres wrappers de header bidding prennent désormais en charge les modules Privacy Sandbox. Le wrapper lit le signal de consentement, configure le comportement d'appel Topics et transmet le résultat de l'enchère via Protected Audience lorsque cela est autorisé. Cette approche est plus légère à déployer, mais pousse davantage de logique vers le client et resserre votre dépendance au rythme de publication du wrapper.

Ce qu'il faut auditer

• Confirmer que document.browsingTopics() n'est pas appelé sauf si le consentement publicitaire du CMP est affirmatif et qu'aucun signal d'opposition n'est présent
• Confirmer que joinAdInterestGroup et runAdAuction sont contrôlés par les mêmes conditions
• Confirmer que les en-têtes d'enregistrement d'Attribution Reporting ne sont envoyés que dans les réponses aux utilisateurs dont l'état de consentement autorise la mesure
• Confirmer que votre liste de fournisseurs dans la chaîne TCF correspond toujours aux SSP et DSP utilisant les API Sandbox sur votre inventaire
• Confirmer que votre politique de confidentialité décrit Topics, Protected Audience et Attribution Reporting comme des activités de traitement distinctes, avec base légale et durée de conservation

Ce que Privacy Sandbox ne fait pas

Plusieurs idées fausses communes doivent disparaître avant que vous ne budgétiez en leur faveur.

Ce n'est pas un contournement du consentement

Les API réduisent les données personnelles exposées aux annonceurs, mais elles ne rendent pas le traitement sous-jacent exempté de consentement en vertu du droit européen. La théorie de conformité selon laquelle l'adoption du Sandbox vous permet de passer outre un CMP est incorrecte dans toutes les juridictions EU/EEA.

Ce n'est pas un remplacement complet des cookies aujourd'hui

Topics fournit un signal de ciblage grossier et avec pertes qui est généralement plus faible que les audiences basées sur les cookies. Les échelles de reciblage de Protected Audience sont encore en maturation. Attribution Reporting comporte des seuils de bruit de mesure qui peuvent masquer de petites augmentations de conversion. Un éditeur qui déplace toute sa monétisation vers Sandbox aujourd'hui devrait s'attendre à des baisses de RPM de 10 à 30 pour cent par rapport à une pile basée sur les cookies sur un inventaire typique.

Ce n'est pas permanent dans sa forme actuelle

La spécification Privacy Sandbox est encore en évolution. La taxonomie Topics s'élargit, les limites de groupes d'intérêt de Protected Audience sont en cours de révision, et la réponse réglementaire est en cours. Concevez votre couche de consentement pour qu'elle soit pilotée par la configuration, non codée en dur par rapport à la spécification actuelle.

La bonne posture pour 2026

Privacy Sandbox se comprend mieux comme une couche d'une stratégie sans cookies plus large, aux côtés des données propriétaires, des audiences définies par les vendeurs, du ciblage contextuel et du header bidding côté serveur. Les éditeurs qui gagneront en 2026 seront ceux qui traitent le consentement comme l'arbitre, non comme l'obstacle — alimentant les API Sandbox uniquement là où la loi et le choix de l'utilisateur le permettent, se repliant proprement sur le contextuel partout ailleurs, et mesurant les résultats sur les deux chemins avec des outils qui ne présupposent pas l'identité.

La pire posture est celle du wait-and-see. Les régulateurs rédigent déjà la prochaine vague de règles — les engagements Sandbox de la Competition and Markets Authority britannique, les directives en cours de la CNIL, et les dispositions de profilage de l'EU AI Act couvrent tous ce terrain. Les éditeurs qui intègrent Privacy Sandbox dans une pile de consentement correctement contrôlée en 2026 seront prêts pour ces règles. Ceux qui le connectent en remplacement de cookie de dernière minute se retrouveront à réécrire sous pression.