Google Consent Mode v2 pour ceux qui livrent : les sept signaux, basique contre avancé, et le changement de juin 2026

Ce qu’est Consent Mode, et ce qu’il n’est pas

Consent Mode est une API que les balises Google écoutent. Avant qu’une balise ne s’exécute, votre page dit à Google ce que le visiteur a accepté ou non ; quand le visiteur décide, votre page met le message à jour ; les balises Google adaptent leur comportement. C’est tout le mécanisme. Il ne bloque rien par lui-même, il ne demande rien à personne, et il ne rend pas une bannière conforme. Ce qu’il fait, c’est laisser Google Ads et GA4 continuer à fonctionner, sous forme réduite, pour ceux qui ont dit non, et pleinement pour ceux qui ont dit oui.

Cette distinction compte parce que beaucoup de bannières « Consent Mode v2 ready » posent les signaux, chargent les balises, et s’arrêtent là. Sous la directive ePrivacy, une balise qui écrit un cookie avant le consentement est une infraction, quel que soit le signal reçu. La bannière doit toujours bloquer ; Consent Mode est ce que vous faites en plus, pour que le blocage ne vous coûte pas votre mesure.

Les sept signaux

Consent Mode a commencé avec deux signaux en 2020 : ad_storage pour les cookies publicitaires et analytics_storage pour les cookies de statistiques. La version 2, rendue obligatoire par Google pour les annonceurs de l’EEE en mars 2024, en a ajouté deux : ad_user_data, si des données utilisateur peuvent être envoyées à Google à des fins publicitaires, et ad_personalization, si les annonces peuvent être personnalisées. Ces quatre-là sont ceux sur lesquels Google Ads et GA4 agissent. Trois autres signaux couvrent le stockage de fonctionnalité, de personnalisation et de sécurité ; le dernier est toujours accordé.

Les signaux sont posés deux fois. Un appel default s’exécute avant le chargement de toute balise et dit « denied » pour les visiteurs de l’EEE, du Royaume-Uni et de la Suisse (et « granted », si vous voulez, ailleurs). Un appel update s’exécute dès que le visiteur choisit et porte la décision réelle. L’ordre est ce que les gens ratent : si une balise Google se charge avant l’appel default, elle démarre sans aucun état de consentement, ce que Google traite comme accordé. C’est pourquoi le runtime de consentement doit être le premier script du head, et pourquoi afterInteractive dans Next.js ou un gestionnaire de balises chargé en premier sont tous deux des bugs.

Basique contre avancé

Google propose deux façons d’implémenter le mode. En mode basique, les balises Google ne se chargent pas du tout tant que le consentement n’est pas accordé ; un visiteur qui refuse n’envoie rien à Google. En mode avancé, les balises se chargent immédiatement mais dans un état restreint : avant le consentement, et après un refus, elles envoient des pings sans cookie ni identifiant, que Google utilise pour modéliser les conversions qu’il ne peut pas observer. Après consentement, elles se comportent normalement.

Les deux sont conformes tant que les valeurs par défaut sont « denied » avant la première balise. La différence, c’est la mesure. Le mode basique vous donne un récit propre pour un délégué à la protection des données : rien ne part chez Google sans consentement, point. Le mode avancé donne à votre équipe marketing des conversions modélisées pour les 30 à 40 pour cent de visiteurs européens qui disent non, au prix d’expliquer les pings sans cookie dans votre politique de confidentialité. La plupart des sites qui font du Google Ads choisissent l’avancé ; la plupart des sites qui ne font que des statistiques choisissent le basique. CookieCrumbs prend en charge les deux et utilise le basique par défaut.

Le changement du 15 juin 2026

Depuis le 15 juin 2026, Google utilise ad_storage comme signal de contrôle pour les données Google Ads. Avant cette date, une bannière qui ne mappait que analytics_storage sur une catégorie « statistiques » et laissait les signaux ads dans leur état par défaut pouvait encore voir arriver des conversions Ads ; depuis, non. Conséquence pratique : la catégorie Marketing de votre bannière doit piloter ensemble ad_storage, ad_user_data et ad_personalization, et Statistiques doit piloter analytics_storage. Un mappage qui traite les quatre comme un seul bloc est légal mais gaspilleur ; un mappage qui oublie ad_storage perd la mesure pour laquelle vous avez tout mis en place.

CookieCrumbs mappe automatiquement les catégories sur les signaux et livre le même mappage dans son modèle Google Tag Manager, si bien que les déclencheurs de votre conteneur tirent sur le bon signal sans écouteur écrit à la main. Si vous maintenez votre propre mappage, vérifiez-le avec le tableau du guide Consent Mode.

Bien le mettre en place

1. Le runtime d’abord. Le runtime de consentement est le premier script du head, avant gtag.js, avant GTM, avant tout.
2. Valeurs par défaut refusées selon la région. EEE, Royaume-Uni et Suisse reçoivent « denied » ; ailleurs, suivez la règle locale (les États américains sont en opt-out).
3. Catégories mappées sur les signaux. Statistiques → analytics_storage. Marketing → ad_storage, ad_user_data, ad_personalization. Préférences → functionality_storage, personalization_storage.
4. Mise à jour à chaque décision, y compris les retraits et les changements ultérieurs depuis la bannière rouverte.
5. Vérifiez dans Tag Assistant. Chargez la page consentement refusé, ouvrez Tag Assistant et lisez l’état de consentement sur la première balise. Il doit indiquer « denied » pour les quatre signaux ads et analytics avant tout clic.

Trois erreurs qui font perdre des données

• GTM se charge en premier. Le conteneur tire ses balises sans état de consentement, Google traite cela comme accordé, et votre première page vue est une infraction. Placez le runtime au-dessus de GTM.
• Marketing ne pilote pas ad_storage. Depuis juin 2026, cela signifie aucune conversion Ads pour personne. Vérifiez le mappage.
• Mode avancé sans la ligne dans la politique de confidentialité. Les pings sans cookie restent un transfert vers Google. Dites-le dans la politique, ou utilisez le mode basique.

Une dernière chose qui n’est pas une erreur mais une limite : Consent Mode n’est pas l’IAB TCF et ne fait pas de vous une CMP certifiée Google. Pour AdSense, Ad Manager et AdMob dans l’EEE, il vous en faut une ; pour Google Ads et GA4, il vous faut Consent Mode v2, ce dont parle cette page.

Sources

1. Simo Ahava, « Consent Mode v2 for Google tags », 2024
2. Cookie Information, « Basic vs. Advanced Consent Mode v2 »
3. Cookie Script, « Basic vs Advanced Google Consent Mode v2 »
4. Veille réglementaire CookieCrumbs, « Google Consent Mode change: ad_storage became the controlling signal for Google Ads data », juin 2026
5. Docs CookieCrumbs, guide Google Consent Mode v2

Rédigé par l’équipe CookieCrumbs, publié le 5 septembre 2026. Chaque fait porte sa date ; si l’un d’eux a évolué, dites-le-nous et nous corrigerons.