Consent Mode v2 et Privacy Sandbox : ce qui reste après 2025

Depuis mars 2024, Consent Mode v2 est obligatoire pour tous les annonceurs qui utilisent Google Ads, le remarketing ou le suivi des conversions dans l'EEE et au Royaume-Uni. Sans Consent Mode correctement implémenté, Google ne diffuse plus d'annonces personnalisées et désactive les fonctionnalités de remarketing. En parallèle, la situation de départ de tout le secteur du tracking a changé en 2025 : Google a abandonné l'essentiel de la Privacy Sandbox, présentée pendant des années comme le successeur des cookies tiers. Pour les entreprises B2B en Europe, la mission est claire : mesurer en conformité avec la loi, sans miser sur un avenir des cookies qui n'arrivera pas.

Cet article replace les deux évolutions dans leur contexte technique et explique la bonne configuration de Consent Mode v2, la modélisation des conversions qui la sous-tend et les conséquences pour la mesure côté serveur, les Core Web Vitals et la visibilité auprès des crawlers IA.

Pourquoi Consent Mode v2 et la fin de la Privacy Sandbox vont désormais de pair

Les deux sujets semblent distincts, mais ils sont liés. Consent Mode v2 règle la façon dont un annonceur transmet à Google le statut de consentement d'un utilisateur. La Privacy Sandbox devait fournir le socle technique sur lequel la publicité fonctionnerait après la disparition des cookies tiers. Avec la fin de ces projets, la réalité actuelle perdure, et c'est justement cette réalité qui rend Consent Mode v2 si important.

Les données sont nettes : selon le HTTP Archive Web Almanac, 61 % de l'ensemble des cookies sur les sites du top 1 million sont des cookies tiers, et même 77 % dans le top 1 000 (mesure internationale). Près de 100 % de ces cookies tiers définissent l'attribut SameSite=None pour pouvoir être envoyés d'un site à l'autre. Cela montre à quel point l'écosystème publicitaire dépend toujours de ces mêmes cookies dont la fin est annoncée depuis des années.

S'y ajoute la perte de consentements due aux bandeaux conformes. Une étude de référence menée dans la zone DACH (Allemagne, Autriche, Suisse) le montre : avec une conception conforme, environ 60 % des données de visite sont perdues en moyenne parce que les utilisateurs refusent (données pour l'Allemagne/UE). Cela correspond à un taux d'acceptation d'environ 40 %. Qui mesure dans l'EEE travaille donc structurellement avec des données lacunaires, et Consent Mode v2 est précisément la réponse de Google à cette lacune.

Ce qu'est techniquement Consent Mode v2 : mode de base, mode avancé et les quatre signaux

Consent Mode v2 est une interface qui transmet le statut du consentement aux balises Google. Au lieu de simplement bloquer les balises, Consent Mode adapte leur comportement au statut. Il existe deux variantes d'implémentation.

• Consent Mode de base : les balises Google ne se chargent qu'une fois que l'utilisateur a donné son consentement. Avant, aucune donnée n'est envoyée à Google, pas même des pings sans cookies. Si l'utilisateur refuse, les données manquent entièrement et Google ne modélise qu'à partir d'observations agrégées.
• Consent Mode avancé : les balises Google se chargent dès le départ, mais sans consentement elles n'envoient que des signaux anonymes, sans cookies ni identifiants personnels. Ces pings fournissent les données sur lesquelles s'appuie la modélisation des conversions. Dès que l'utilisateur consent, les balises passent en mode de mesure complète.

Quatre signaux pilotent ce comportement. ad_storage régit le dépôt de cookies publicitaires. analytics_storage contrôle les cookies d'analyse, par exemple dans Google Analytics 4. ad_user_data détermine si des données utilisateur peuvent être envoyées à Google à des fins publicitaires. ad_personalization décide de la publicité personnalisée et du remarketing. Les deux derniers signaux sont arrivés avec la version 2 et expliquent pourquoi la migration est devenue obligatoire.

Techniquement, le pilotage passe par deux commandes. La commande default définit l'état initial avant le déclenchement de la moindre balise. Dans l'EEE, ce default doit être sur denied pour toutes les catégories non nécessaires. La commande update met à jour le statut après le choix de l'utilisateur. L'ordre et le timing sont décisifs : la commande default doit être exécutée avant le chargement des balises Google, sinon une balise se déclenche avant que le statut du consentement soit connu. En pratique, c'est le plus souvent une plateforme de gestion du consentement qui assure ce pilotage et transmet les signaux à la balise Google ou à Google Tag Manager.

Modélisation des conversions : comment Google estime les conversions manquantes

La modélisation des conversions est le véritable intérêt du Consent Mode avancé. Quand un utilisateur refuse, le lien direct entre le clic sur l'annonce et la conversion disparaît. Google comble cette lacune avec un modèle statistique qui déduit les parcours non observables à partir des parcours observables et consentis.

Google fournit lui-même l'ordre de grandeur : en moyenne, la modélisation des conversions du Consent Mode récupère plus de 70 % des parcours entre clic sur une annonce et conversion perdus faute de consentement aux cookies (données internationales de Google, 2021). La réserve que Google formule expressément compte : les résultats varient fortement selon le taux d'acceptation et la qualité de l'implémentation.

C'est là que se situe le problème du B2B. La modélisation a besoin de volume. Google n'active la modélisation des conversions dans le Consent Mode qu'à partir d'un volume minimal de clics sur les annonces et d'utilisateurs. Beaucoup de comptes B2B n'atteignent pas ce seuil : un fournisseur de niche avec quelques centaines de clics par mois reste en dessous. Pour ces comptes, seul s'applique alors le modèle plus général et moins précis au niveau de Google.

L'attente réaliste pour le B2B à faible volume est donc la suivante : la modélisation des conversions n'est pas un interrupteur qui ramène à coup sûr les conversions perdues. Elle fonctionne bien là où le trafic est suffisant. Avec peu de volume, mieux vaut miser sur une stratégie de données first-party rigoureuse et sur la mesure côté serveur plutôt que de compter sur la modélisation.

Bien interpréter la fin de la Privacy Sandbox en 2025

La chronologie compte, car elle est souvent présentée de façon raccourcie. En avril 2025, Google a annoncé qu'il n'introduirait pas dans Chrome de fenêtre de choix dédiée aux cookies tiers et qu'il conserverait le modèle existant. En octobre 2025 est venue l'étape décisive. Selon le blog officiel de la Privacy Sandbox, Google a annoncé l'abandon d'une série de technologies de la Privacy Sandbox, dont l'API Attribution Reporting, Protected Audience et Topics, ainsi que le maintien dans Chrome de sa gestion actuelle du choix relatif aux cookies tiers (annonce du 17 octobre 2025).

Point important pour bien interpréter la décision : Google abandonne une liste précise de technologies, pas toutes les fonctionnalités en bloc. Sont notamment abandonnés Topics, Protected Audience, l'API Attribution Reporting, Private Aggregation, IP Protection et Related Website Sets. Ce qui reste en pratique :

• Cookies tiers dans Chrome : ils ne disparaîtront pas dans un avenir prévisible. Le modèle existant est maintenu, et aucune nouvelle fenêtre de choix distincte pour les cookies n'a été annoncée.
• CHIPS (Cookies Having Independent Partitioned State) : les cookies partitionnés restent disponibles en tant que mécanisme et utilisables indépendamment des API abandonnées.
• Le cadre juridique : le RGPD et la directive ePrivacy ne changent pas avec la décision de Google. Le consentement reste obligatoire, quelle que soit la technologie de navigateur disponible.

Conséquence pour les annonceurs : des années de préparation à un avenir sans cookies via les API de la Sandbox deviennent caduques. L'attention se déplace durablement vers le consentement, les données first-party et l'architecture côté serveur. Les restrictions côté navigateur, comme l'Intelligent Tracking Prevention d'Apple dans Safari, qui détient environ 20 % de parts de marché en Europe (données pour l'Europe ; Chrome environ 60 %, Edge environ 7 %), continuent de s'appliquer sans changement.

RGPD, TKG 2021, TDDDG et omnibus numérique de l'UE

En Autriche, l'accès aux terminaux relève de la loi sur les télécommunications (TKG 2021), plus précisément de sa transposition de la directive ePrivacy. Les cookies non strictement nécessaires et les technologies comparables requièrent un consentement préalable et actif. En Allemagne, la loi autrefois appelée TTDSG et rebaptisée depuis TDDDG remplit la même fonction via son § 25. Les deux exigent un consentement explicite pour tous les cookies non essentiels ; continuer à faire défiler la page ne suffit pas.

La jurisprudence autrichienne a encore relevé le niveau d'exigence en 2025. Dans une décision du 13 août 2025, le Tribunal administratif fédéral a jugé illégal un bandeau Pay-or-Okay global sans possibilité de choix granulaire (décision pour l'Autriche). Le tribunal a relevé que les utilisateurs ne pouvaient pas consentir ou refuser de façon granulaire des finalités de traitement précises comme la publicité, le profilage et l'analyse. En pratique, la granularité n'est pas optionnelle : c'est une condition d'un consentement valable.

Au niveau de l'UE, les choses bougent. Avec la proposition d'omnibus numérique du 19 novembre 2025, la Commission européenne prévoit un bouton de refus en un clic obligatoire, un paramétrage centralisé des préférences lisible par machine, par exemple via le navigateur, ainsi que la suppression des pop-ups de consentement pour les finalités sans risque comme le simple comptage des visites (proposition de la Commission européenne). Si la proposition devient loi, elle pourrait modifier sensiblement le paysage des bandeaux. D'ici là, le cadre actuel, avec un bouton de refus équivalent et des finalités granulaires, s'applique sans changement.

Tagging côté serveur et données first-party face à la perte de signaux

Le tagging côté serveur, le plus souvent mis en œuvre sous forme de sGTM (Server-Side Google Tag Manager), est la réponse technique aux restrictions des navigateurs et à la perte de signaux. Au lieu d'exécuter les balises dans le navigateur de l'utilisateur, le conteneur de balises tourne sur un serveur dédié qui reçoit les données, les traite et les transmet de façon contrôlée aux systèmes cibles.

Les bénéfices se situent à plusieurs niveaux :

• Durée de vie des cookies prolongée : les cookies que le serveur dépose en contexte first-party via la réponse HTTP échappent aux délais courts qu'ITP impose aux cookies déposés en JavaScript. Mais cela ne vaut que si Safari ne classe pas le serveur de tagging comme tiers. Si ITP détecte un tiers via le CNAME ou l'adresse IP, il plafonne aussi les cookies déposés côté serveur à 7 jours. Un sGTM sur un sous-domaine qui pointe par CNAME vers un hébergeur cloud externe tombe généralement dans ce cas. Si le serveur de tagging tourne dans la même plage IP que le site, il stabilise la mesure dans Safari.
• Maîtrise des données avant transmission : sur le serveur, les champs personnels peuvent être filtrés, tronqués ou pseudonymisés avant que les données ne partent vers des tiers. Cela soutient la minimisation des données au sens du RGPD.
• Conversions améliorées : les données first-party hachées, comme les adresses e-mail, sont transmises de façon sécurisée côté serveur et améliorent l'attribution des conversions, à condition qu'un consentement valable existe.

La délimitation est importante : le tagging côté serveur ne permet pas de contourner le consentement. Il change l'architecture des flux de données, pas la base juridique. Qui mesure côté serveur sans consentement enfreint la TKG et le RGPD tout autant que côté client. Le sGTM améliore donc la qualité et la maîtrise des données, mais ne remplace jamais le consentement.

CMP et IAB TCF : obligatoires pour les éditeurs, au choix pour les annonceurs

Pour les annonceurs, Google n'impose pas de plateforme de gestion du consentement certifiée. Consent Mode v2 peut aussi se mettre en place via une implémentation gtag ou Tag Manager maison, tant que default et update sont transmis correctement. Une CMP certifiée par Google avec l'IAB Transparency and Consent Framework (TCF) n'est obligatoire que pour les éditeurs qui diffusent des annonces personnalisées dans l'EEE, au Royaume-Uni et en Suisse via AdSense, Ad Manager ou AdMob. Selon Google, les annonceurs sont libres d'utiliser aussi une CMP hors du programme partenaires pour Consent Mode. Une CMP partenaire reste intéressante : elle recueille le consentement, le conserve de façon probante et transmet de manière fiable les quatre signaux au Consent Mode.

Pour le choix et l'intégration, trois points comptent :

• Bien comprendre la certification : les éditeurs qui utilisent AdSense, Ad Manager ou AdMob choisissent dans la liste des fournisseurs certifiés par Google. Les annonceurs vérifient plutôt si la CMP transmet les quatre signaux du Consent Mode. La liste des partenaires de Google est un bon point de départ pour cela.
• Bonne connexion au Consent Mode : la CMP doit placer les signaux default sur denied avant le chargement des balises, puis envoyer un update après le choix de l'utilisateur. Cet enchaînement est le point de défaillance le plus fréquent.
• Refléter des finalités granulaires : le TCF fonctionne avec des finalités et des fournisseurs définis. L'interface du bandeau doit les présenter de façon granulaire pour que le consentement résiste à la jurisprudence autrichienne.

Impact sur les crawlers IA et le GEO

Au-delà de la mesure, les configurations de consentement et de tracking influencent aussi la visibilité auprès des crawlers IA comme GPTBot, ClaudeBot et PerplexityBot. Le mécanisme est technique et facile à négliger.

Sur un point central, les crawlers IA se comportent comme les robots des moteurs de recherche classiques : ils ne ferment pas les bandeaux cookies et ne donnent pas de consentement. Qui cache du contenu derrière un cookie wall ou ne charge des blocs de texte essentiels en JavaScript qu'après le consentement risque que ce contenu reste invisible pour les systèmes d'IA. Il en découle trois principes pour le GEO :

• Ne pas lier le contenu au consentement : le texte éditorial, les définitions et le contenu spécialisé vont dans le HTML initial, pas dans des scripts qui ne se déclenchent qu'après acceptation. Seuls le tracking et les balises marketing passent derrière le consentement.
• Éviter les cookie walls : un cookie wall strict qui bloque tout le contenu nuit autant à l'indexation classique qu'à la visibilité IA. Il est en outre juridiquement contesté.
• Privilégier le rendu côté serveur : le contenu rendu côté serveur reste accessible indépendamment du consentement et du JavaScript côté client. Dans les architectures Next.js, c'est la base la plus solide pour les crawlers IA et les réponses des IA.

La séparation est donc claire : la mesure derrière le consentement, le contenu devant. Mélanger les deux fait perdre de la visibilité précisément dans les canaux qui, en B2B, décident de plus en plus de qui est trouvé.

Core Web Vitals : les scripts de consentement sur le chemin critique

Les scripts de cookies et de consentement s'exécutent par nature tôt et de façon bloquante, puisque le bandeau doit apparaître avant toute interaction. C'est précisément ce qui en fait un risque pour les Core Web Vitals. Un script de CMP lourd retarde le rendu et pèse surtout sur deux métriques.

• LCP (Largest Contentful Paint) : un script de consentement qui bloque le rendu repousse l'affichage du plus grand contenu visible. Si le bandeau recouvre le contenu principal, il peut devenir lui-même l'élément LCP et dégrader la mesure.
• INP (Interaction to Next Paint) : une logique de CMP volumineuse bloque le thread principal et retarde la réaction à la première interaction de l'utilisateur, par exemple le clic sur Accepter ou Refuser.

Les contre-mesures concrètes consistent à garder le script de la CMP aussi léger que possible, à le charger de façon asynchrone quand la logique le permet et à éviter les décalages de mise en page en réservant de la place pour le bandeau, afin que le CLS reste stable. Les solutions d'analytics respectueuses de la vie privée, sans cookies et au script léger, réduisent encore la charge et offrent une vue de mesure agrégée qui ne requiert pas de consentement.

Erreurs fréquentes lors de l'implémentation

Les erreurs typiques se répètent et se corrigent le plus souvent avec un effort raisonnable.

• Default sur granted dans l'EEE : si le statut par défaut n'est pas réglé sur denied, les balises se déclenchent avant le consentement avec un tracking complet. C'est l'infraction la plus grave et la plus fréquente.
• Signal update manquant : la commande default est en place, mais l'update après le choix de l'utilisateur manque. Le statut reste alors en permanence sur denied, et même les utilisateurs qui ont consenti ne sont pas mesurés complètement.
• Mauvais ordre : le snippet Consent Mode se charge après les balises Google. Une balise se déclenche alors avant que le statut soit connu.
• Bouton de refus non équivalent : un bouton Accepter en couleur à côté d'un lien Refuser en gris est considéré comme du nudging illicite et compromet la validité du consentement.
• Contenu derrière le consentement : le texte éditorial ne se charge qu'après acceptation et disparaît ainsi pour les crawlers des moteurs de recherche et des IA.
• CMP non certifiée chez les éditeurs : qui diffuse des annonces personnalisées via AdSense, Ad Manager ou AdMob en utilisant une CMP sans certification Google ou sans TCF à jour ne respecte pas l'exigence de Google pour les éditeurs. Pour les annonceurs qui utilisent Consent Mode, une CMP certifiée n'est pas obligatoire.

Métriques, mesure et débogage

L'efficacité d'une configuration Consent Mode v2 doit être vérifiée et surveillée activement. Un bandeau mis en place une fois ne prouve pas qu'il fonctionne correctement.

• Vérifier Tag Assistant et le statut du consentement : Google Tag Assistant permet de voir quels signaux de consentement sont définis et si default se déclenche avant update. Idéalement, le mode débogage affiche le passage du statut denied à granted après l'acceptation.
• Surveiller les conversions modélisées : dans Google Ads et GA4, il faut suivre les conversions modélisées comme une grandeur à part. Une chute soudaine signale une configuration cassée.
• Le taux de consentement comme indicateur : le taux d'acceptation est lui-même un indicateur de pilotage. Avec un taux typique d'environ 40 %, il permet de jauger les données disponibles et d'évaluer la conception du bandeau.
• Évaluer les seuils avec réalisme : les comptes B2B à faible volume en particulier devraient vérifier s'il y a assez de volume pour la modélisation des conversions, plutôt que d'interpréter les valeurs modélisées sans recul.
• Des tendances plutôt que des valeurs absolues : comme les données sont systématiquement lacunaires, les évolutions relatives dans le temps sont plus parlantes que les chiffres absolus.

Pour aller plus loin

Consent Mode v2 et la fin de la Privacy Sandbox marquent le même tournant : l'avenir de la mesure ne repose pas sur une technologie de navigateur sans cookies, mais sur le consentement, les données first-party et l'architecture côté serveur. Pour les entreprises B2B en Europe, il en découle un ordre clair. D'abord, un bandeau granulaire avec un bouton de refus équivalent et une CMP qui conserve les consentements de façon probante. Ensuite, une configuration Consent Mode v2 propre, avec default sur denied et un update correct. Sur cette base, le tagging côté serveur et les conversions améliorées, là où le volume et le consentement le permettent. Et, tout au long, la séparation entre contenu et mesure, pour que les moteurs de recherche et les crawlers IA voient le contenu pendant que le tracking ne s'exécute qu'après acceptation. Qui applique cette chaîne avec rigueur mesure en sécurité juridique et reste visible, quelle que soit la prochaine technologie de navigateur qui arrive ou disparaît.