Consent Mode v2 : le guide complet pour l'installer et l'implémenter

Ce guide est la page de référence de notre série sur le Consent Mode. Il couvre ce qu'est le Consent Mode v2 et pourquoi il est obligatoire, ses quatre paramètres, le choix entre basic et advanced, l'implémentation pas à pas avec ou sans Google Tag Manager, l'installation sur les principaux CMS, l'articulation avec GA4, les autres régies et le server-side, les erreurs les plus fréquentes, les messages de Tag Assistant et une checklist finale. Chaque section renvoie vers un article dédié quand vous voulez aller plus loin.

Qu'est-ce que le Consent Mode v2 de Google ?

Le Consent Mode est une fonctionnalité de Google qui ajuste le comportement des balises Google selon le consentement exprimé par le visiteur. Il fait le lien entre votre bandeau cookies conforme au RGPD, géré par votre plateforme de gestion du consentement (CMP), et les services Google que vous utilisez : Google Analytics 4, Google Ads, Floodlight et le Conversion Linker. Plutôt que de se charger ou non de façon binaire, les balises reçoivent des signaux qui leur indiquent si le stockage analytique et publicitaire est autorisé, et elles adaptent ce qu'elles écrivent et envoient.

Gardez un point en tête dès le départ : le Consent Mode v2 ne remplace pas la conformité RGPD. Votre bandeau doit toujours proposer un refus aussi simple que l'acceptation, des choix par catégorie et une preuve du consentement. Le Consent Mode se contente de transmettre le résultat de ce choix à Google. Un Consent Mode parfait derrière un bandeau qui pousse à accepter reste contraire aux conditions de validité du consentement RGPD.

Consent Mode v1 et v2 : ce qui a changé

Google a lancé la première version en 2020 avec deux paramètres, analytics_storage et ad_storage. Le Consent Mode v2 est arrivé en novembre 2023 avec deux changements :

• deux nouveaux paramètres, ad_user_data et ad_personalization, qui décrivent ce que Google peut faire des données plutôt que les cookies qu'il peut écrire ;
• une distinction formelle entre implémentation basic et implémentation advanced, aux conséquences différentes pour la modélisation.

Un site qui n'envoie que les deux paramètres de la v1 est considéré par Google comme ne fournissant pas le consentement nécessaire à l'usage publicitaire : les listes de remarketing et la personnalisation cessent de fonctionner pour le trafic EEE, même quand le visiteur a cliqué sur « Accepter ».

Le Consent Mode v2 est-il obligatoire ?

Juridiquement, aucune loi ne mentionne le Consent Mode. Contractuellement, oui pour la plupart des annonceurs. Google applique sa politique relative au consentement des utilisateurs de l'UE et, depuis que le Digital Markets Act l'a désigné contrôleur d'accès, il doit prouver qu'il dispose du consentement avant d'utiliser à des fins publicitaires les données personnelles des utilisateurs de l'EEE. Depuis mars 2024, il demande aux annonceurs de lui transmettre ce consentement via le Consent Mode v2 (ou via une chaîne IAB TCF v2.2, voir notre guide du TCF 2.2). Notre article sur le Digital Markets Act et les cookies explique comment ce règlement est arrivé jusqu'à vos balises.

Si votre site ne charge aucune balise Google, le Consent Mode ne vous concerne pas. Si vous utilisez seulement GA4 sans Google Ads, il n'est pas strictement exigé, mais sans lui GA4 ne reçoit jamais le refus et vous perdez la modélisation comportementale.

Ce que ça change pour vos campagnes

Sans signaux Consent Mode v2 valides, trois domaines en pâtissent :

• Google Ads : la modélisation des conversions ne fonctionne pas. Google ne peut ni estimer les conversions des utilisateurs qui refusent, ni alimenter correctement les enchères intelligentes.
• GA4 : les sessions, événements et parcours des visiteurs de l'EEE ne remontent plus correctement et vos rapports deviennent incomplets.
• Audiences de remarketing : ad_user_data et ad_personalization doivent être envoyés avec le statut granted pour que Google puisse utiliser les données à des fins publicitaires et de personnalisation. Sans eux, vos audiences fondent ou cessent de se remplir.

Nous détaillons les effets sur les enchères, l'attribution et la taille des audiences dans notre article sur l'impact du Consent Mode v2 sur les campagnes Google Ads. Les restrictions des navigateurs, comme l'Intelligent Tracking Prevention de Safari, réduisent encore la portée des cookies, ce qui rend le Consent Mode et sa modélisation d'autant plus importants.

Les symptômes d'une mauvaise implémentation

Quelques signes doivent vous alerter : une baisse des conversions mesurées sur le trafic EEE dans Google Ads, des avertissements dans l'onglet Diagnostics de vos actions de conversion, une modélisation absente dans GA4, des listes de remarketing qui ne grossissent plus ou des messages de Tag Assistant signalant des signaux de consentement manquants.

Les quatre paramètres du Consent Mode v2

Chaque paramètre prend la valeur granted ou denied :

• analytics_storage : stockage des cookies de mesure d'audience (durée de visite, pages vues, type d'appareil). Il existait dans la v1.
• ad_storage : stockage des cookies publicitaires. Il existait aussi dans la v1.
• ad_user_data : consentement à l'envoi de données utilisateur à Google à des fins publicitaires. Nouveau dans la v2.
• ad_personalization : consentement à la personnalisation des annonces, remarketing compris. Nouveau dans la v2.

La distinction compte. analytics_storage et ad_storage encadrent la collecte (quels cookies peuvent être écrits), tandis que ad_user_data et ad_personalization encadrent l'usage (ce que Google peut faire des données). C'est ce qui rend la v2 plus granulaire que la v1.

Chaque paramètre correspond à l'une des catégories de cookies RGPD affichées dans votre bandeau : mesure d'audience pour analytics_storage, marketing pour les trois signaux publicitaires. Trois autres types de stockage existent (functionality_storage, personalization_storage et security_storage), mais les balises Google ne les lisent pas : ils ne servent que si vous les utilisez vous-même dans des déclencheurs GTM.

À quoi ressemblent les signaux dans une requête

Vous pouvez lire l'état du consentement directement dans les requêtes envoyées à Google. Le paramètre gcs porte l'état des stockages : G100 signifie que les deux sont refusés, G111 que les deux sont acceptés, G110 et G101 que seul le stockage publicitaire ou seul le stockage analytique est accepté. Le paramètre gcd, ajouté avec la v2, encode les quatre signaux et indique si chacun vient d'un état par défaut ou d'une mise à jour. Si vous voyez gcs=G111 sur une page où le visiteur a refusé, une balise a échappé à votre bandeau.

Consent Mode basic ou advanced : lequel choisir ?

Cette distinction détermine ce que vous mesurez réellement quand un visiteur refuse.

Le mode basic

Les balises Google ne se chargent pas tant que le visiteur n'a pas consenti. S'il refuse, rien du tout n'est envoyé à Google. C'est l'approche la plus stricte pour la vie privée, mais vous perdez tout signal des utilisateurs qui refusent. Google ne peut appliquer qu'un modèle général construit à partir des données consenties, moins précis.

Le mode advanced

Les balises Google se chargent avant l'interaction avec le bandeau, avec tous les paramètres à denied. Tant que le consentement n'est pas donné, elles n'écrivent aucun cookie et n'envoient que des pings sans cookies contenant des informations non identifiantes comme l'horodatage, le type de navigateur, le référent et l'état du consentement. Google s'en sert pour modéliser conversions et comportements avec une bien meilleure précision, même avec un fort taux de refus.

Le mode advanced est-il compatible avec le RGPD ?

Le mode basic suffit pour répondre aux exigences de Google et garder le remarketing pour les utilisateurs qui consentent. Le mode advanced donne des données plus fiables, ce qui compte si vous investissez beaucoup dans Google Ads, mais il pose une question juridique : le ping sans cookies envoie quand même une requête à Google avec l'adresse IP et le user agent du visiteur, ce qui peut être vu comme un traitement de données personnelles sans consentement. Les autorités européennes, CNIL comprise, n'ont pas publié de position spécifique au Consent Mode : faites valider ce choix par votre DPO ou votre service juridique. Notre comparatif Consent Mode basic ou advanced approfondit cet arbitrage.

La modélisation des conversions et ses seuils

La modélisation ne démarre pas automatiquement. Dans Google Ads, Google indique un minimum d'environ 700 clics publicitaires sur 7 jours par pays et par groupe de domaines. Dans GA4, la modélisation comportementale exige au moins 1 000 événements par jour avec analytics_storage refusé pendant au moins 7 jours, et au moins 1 000 utilisateurs quotidiens avec analytics_storage accepté pendant au moins 7 des 28 jours précédents. En dessous, les trous restent vides. Le moyen le plus fiable de récupérer des données reste d'améliorer votre taux de consentement avec un bandeau clair et honnête.

Comment installer le Consent Mode v2 : l'implémentation pas à pas

Étape 1 : lister vos balises et choisir une CMP compatible v2

Avant de configurer quoi que ce soit, regardez ce que votre site charge vraiment. Vérifiez en 30 secondes quels cookies et quelles balises Google votre site dépose avant consentement avec le scanner de cookies gratuit. Le résultat vous dit si GA4, Google Ads, Floodlight ou des pixels tiers se déclenchent avant le bandeau.

Votre CMP (si le terme est nouveau, voir ce qu'est une CMP et comment elle fonctionne) affiche ensuite le bandeau, recueille le choix et le transmet aux balises Google. Google liste les CMP avec lesquelles il travaille dans son programme CMP Partner ; quel que soit l'outil choisi, vérifiez qu'il envoie bien les quatre paramètres, pas seulement les deux de la v1. Si votre CMP ne gère pas la v2, vous devrez implémenter les signaux vous-même dans GTM, ce qui est plus fragile. Notre guide pour choisir une plateforme de gestion du consentement liste les critères à vérifier.

Étape 2 : définir l'état par défaut avant toute balise Google

Avant toute interaction avec le bandeau, les quatre paramètres doivent valoir denied pour les visiteurs de l'EEE. Cette commande doit s'exécuter avant chaque balise Google, idéalement en tout premier script du <head>, au-dessus du snippet Google Tag Manager :

gtag('consent', 'default', { 'ad_storage': 'denied', 'analytics_storage': 'denied', 'ad_user_data': 'denied', 'ad_personalization': 'denied', 'wait_for_update': 500 });

wait_for_update demande aux balises Google d'attendre jusqu'à 500 ms que la CMP pousse un choix enregistré lors d'une visite précédente. Un visiteur qui revient et qui avait déjà accepté est ainsi mesuré correctement dès le premier hit.

Si votre audience est mondiale et que vous ne voulez les valeurs restrictives qu'en Europe, la commande par défaut accepte un paramètre region avec une liste de codes pays. Attention : un visiteur mal géolocalisé reçoit alors la valeur permissive, c'est pourquoi beaucoup de sites européens gardent denied partout.

Étape 3 : mettre à jour le consentement après le choix du visiteur

Quand le visiteur accepte, refuse ou personnalise, la CMP appelle gtag('consent', 'update', {...}) avec les valeurs qui correspondent aux catégories acceptées. S'il accepte la mesure d'audience mais refuse la publicité, vous obtenez analytics_storage: 'granted' et les trois autres paramètres restent à denied.

Le Consent Mode ne stocke rien lui-même. Votre CMP doit conserver le choix (cookie ou stockage local) et renvoyer les bons états à chaque chargement de page. Sinon, Google reçoit des signaux incohérents, ce qui fausse la modélisation. Conserver ce choix est aussi ce qui vous permet de présenter à la CNIL la preuve du consentement qu'elle attend.

Étape 4 : activer les fonctions complémentaires

• url_passthrough fait passer les identifiants de clic publicitaire (GCLID, DCLID) dans les URL internes tant que ad_storage est refusé, ce qui préserve l'attribution si le visiteur accepte plus tard.
• ads_data_redaction, combiné à un ad_storage refusé, retire les identifiants de clic publicitaire des pings envoyés à Google.

Étape 5 : configurer le consentement sur vos balises GTM

Dans Google Tag Manager, les balises Google (GA4, Google Ads, Floodlight) intègrent des vérifications de consentement : elles lisent seules les signaux du Consent Mode, sans rien à configurer. Les balises non Google (Meta Pixel, LinkedIn, Hotjar, HTML personnalisé) ne le font pas : dans Paramètres avancés > Paramètres de consentement, sélectionnez Exiger un consentement supplémentaire pour le déclenchement de la balise et ajoutez le signal concerné, par exemple ad_storage pour un pixel publicitaire. Si vous définissez l'état par défaut dans GTM plutôt que dans la page, utilisez le déclencheur Consent Initialization - All Pages pour qu'il passe avant toutes les autres balises.

Notre guide Google Tag Manager et Consent Mode détaille cette configuration, y compris l'écran de vue d'ensemble du consentement et les modèles de la galerie.

Étape 6 : vérifier

1. Ouvrez GTM en mode Aperçu : Tag Assistant s'ouvre sur votre site. Sélectionnez une balise Google, puis l'onglet Consent. La colonne par défaut doit afficher denied pour les quatre signaux, puis passer à granted après un clic sur accepter.
2. Dans l'onglet réseau de votre navigateur, filtrez sur collect et lisez les paramètres gcs et gcd avant et après votre choix.
3. Dans GA4, allez dans Administration > Flux de données, ouvrez votre flux web et vérifiez que les signaux de consentement sont détectés.
4. Dans Google Ads, ouvrez l'onglet Diagnostics de vos actions de conversion pour confirmer l'état du Consent Mode.
5. Testez le parcours complet : refus, acceptation partielle, acceptation totale, puis un nouveau chargement de page. Dans chaque cas, les balises doivent se comporter comme prévu. Pour un plan de test complet (console, Tag Assistant, lecture des paramètres gcs et gcd, cookies et chaque scénario de consentement), lisez notre guide pour vérifier le Consent Mode v2.

Installer le Consent Mode v2 sur Squarespace, WordPress, Shopify et les autres CMS

Le principe ne change jamais, mais l'endroit où vous insérez l'état par défaut, si. La règle est la même partout : le snippet de la CMP et ses valeurs par défaut doivent être au-dessus de toute balise Google, et l'intégration Google native de la plateforme ne doit pas injecter une balise avant eux.

• Squarespace : le champ Google Analytics intégré charge GA4 très tôt. Notre guide Squarespace et Google Consent Mode v2 montre où placer l'injection de code et quoi retirer.
• WordPress et WooCommerce : Site Kit, les extensions d'analytics et l'extension de la CMP peuvent toutes envoyer des états de consentement. N'en gardez qu'une source, comme l'explique notre guide des cookies et du consentement sur WordPress.
• Shopify : Shopify dispose de sa propre Customer Privacy API, sur laquelle s'appuie l'application Google & YouTube. Notre guide de conformité des cookies Shopify explique comment elle se connecte à un bandeau tiers. Pour la configuration du Consent Mode elle-même, notre guide Consent Mode v2 sur Shopify explique comment choisir entre la Customer Privacy API et une CMP dans theme.liquid.
• Webflow, Wix et Next.js : consultez le guide du consentement sur Webflow, le guide Wix et le guide Next.js, chacun avec le point d'injection qui s'exécute en premier.

Consent Mode et Google Analytics 4

GA4 est la balise Google que la plupart des sites chargent, et celle où les erreurs de Consent Mode se voient le plus. Avec analytics_storage refusé, GA4 n'écrit ni _ga ni _ga_<id-du-conteneur> ; notre article sur les cookies _ga, _gid et _gat explique ce que chacun stocke et pour combien de temps.

Le Consent Mode ne règle pas la question plus large de la licéité de GA4 en Europe (transferts de données, adresses IP, durées de conservation) : elle est traitée dans notre guide Google Analytics est-il conforme au RGPD ?. Google Signals ajoute une couche, puisqu'il relie les données GA4 aux comptes Google connectés et dépend d'ad_personalization ; voir notre guide Google Signals et RGPD. Si vous voulez mesurer sans consentement du tout, les alternatives sont dans notre guide de l'analytics sans cookies.

Au-delà de Google : les signaux de consentement de Microsoft, Amazon et Meta

Le Consent Mode ne gouverne que les balises Google. Les autres régies ont construit leurs propres mécanismes, et votre CMP doit aussi les alimenter :

• Microsoft Advertising lit un signal de consentement dans sa balise UET, proche dans l'esprit de celui de Google. Notre guide du Consent Mode de Microsoft UET montre les commandes à envoyer et comment les tester.
• Amazon Ads a introduit l'Amazon Consent Signal ; voir notre guide de l'Amazon Consent Signal (ACS).
• Les pixels Meta, TikTok et LinkedIn n'ont pas d'équivalent du Consent Mode qui dispenserait de les bloquer. Ils ne doivent pas se charger avant le consentement ; notre guide Meta Pixel et RGPD explique comment les retenir.

Consent Mode et server-side tagging

Passer GA4 ou Google Ads dans un conteneur GTM côté serveur ne supprime pas le besoin de consentement. L'état du consentement voyage avec chaque événement jusqu'à votre conteneur serveur, et les balises serveur doivent le respecter de la même façon. Un conteneur serveur qui supprime les paramètres de consentement, ou qui dépose des cookies first-party pour tous les visiteurs, casse la chaîne. Notre article sur le server-side tagging et le consentement détaille ce qui change et ce qui ne change pas.

Le Consent Mode a-t-il un effet sur le SEO ou la vitesse ?

Le Consent Mode lui-même n'a aucun effet sur le classement. Le script qui le porte, si : une CMP lourde chargée de façon synchrone peut retarder l'affichage et dégrader les Core Web Vitals. La commande par défaut en ligne pèse quelques centaines d'octets ; c'est la façon de charger le bandeau qui compte. Notre article sur l'impact d'une CMP sur les Core Web Vitals donne les mesures.

Les erreurs fréquentes d'implémentation du Consent Mode v2

• Pas d'état par défaut. Sans valeur par défaut explicite, les balises Google se comportent comme si le consentement était accordé. Définissez toujours les quatre paramètres à denied avant GTM.
• Oublier les deux paramètres de la v2. Beaucoup de configurations envoient ad_storage et analytics_storage mais pas ad_user_data ni ad_personalization. Le remarketing et la personnalisation cessent alors de fonctionner, même après acceptation.
• Mauvais ordre d'exécution. Si une balise Google se charge avant l'état par défaut, elle utilise des valeurs implicites qui ne correspondent pas forcément à votre politique. Une CMP qui envoie ses signaux après le chargement des balises produit le même résultat.
• Une intégration native qui charge Google en premier. Le champ Google Analytics d'un CMS, ou une extension, peut injecter GA4 au-dessus de votre CMP. Retirez-le et chargez GA4 via GTM ou la CMP.
• Pas de persistance entre les pages. Si la CMP ne renvoie pas le choix enregistré à chaque page, Google reçoit des signaux contradictoires.
• Le mode advanced avec une CMP qui bloque les balises Google. Si la CMP empêche les balises Google de se charger avant consentement, aucun ping sans cookies ne part et la modélisation avancée ne démarre jamais.
• Confondre Consent Mode et blocage des scripts. Chaque traceur non Google doit être bloqué séparément.
• Des implémentations en double. Si votre CMP, une extension et du code maison envoient tous des états de consentement, les signaux contradictoires provoquent des erreurs. Gardez une seule source.
• Un Consent Mode qui marche derrière un bandeau non conforme. Refus simple, granularité et preuve du consentement restent obligatoires. Évitez les dark patterns que la CNIL interdit.

Dépannage : 5 messages fréquents dans Tag Assistant

« No consent default found »

La commande par défaut manque ou se déclenche après les balises Google. Elle doit passer en premier. Si vous la définissez dans GTM, utilisez le déclencheur Consent Initialization - All Pages, pas le déclencheur standard All Pages.

« ad_user_data or ad_personalization not set »

Votre CMP n'envoie que les paramètres de la v1. Mettez à jour sa configuration ou passez à une CMP qui envoie nativement les quatre signaux.

« Consent state is always granted »

Votre état par défaut vaut granted au lieu de denied pour les visiteurs de l'EEE. Les balises se déclenchent avant toute interaction avec le bandeau, ce qui n'est pas conforme au RGPD. Passez les quatre paramètres à denied par défaut.

Les conversions tombent à zéro

Vérifiez dans Tag Assistant que l'état passe bien de denied à granted après un clic sur accepter. Assurez-vous aussi que vos balises de conversion ne sont pas réglées pour se déclencher uniquement sur Consent Initialization.

Modélisation inactive ou données insuffisantes

Vous êtes probablement sous les seuils de volume décrits plus haut. Deux leviers : un bandeau plus clair qui augmente le taux de consentement, ou le passage au mode advanced après validation juridique.

Checklist d'implémentation du Consent Mode v2

• Scanner votre site pour lister les balises Google et tierces qu'il charge.
• Vérifier que votre CMP gère nativement le Consent Mode v2 et envoie les quatre paramètres.
• Définir l'état par défaut à denied pour les quatre paramètres, avant GTM, en haut du <head>.
• Retirer toute intégration Google native qui charge une balise avant les valeurs par défaut.
• Vérifier que la CMP appelle gtag('consent', 'update') après chaque choix et renvoie le choix enregistré à chaque page.
• Choisir entre basic et advanced après avis de votre DPO ou de votre service juridique.
• Activer url_passthrough (et ads_data_redaction si vous voulez retirer les identifiants de clic des pings).
• Ajouter une vérification de consentement supplémentaire à chaque balise non Google dans GTM.
• Alimenter les signaux de consentement Microsoft UET et Amazon si vous y faites de la publicité.
• Valider l'ordre des événements default et update dans Tag Assistant et dans les paramètres gcs et gcd.
• Confirmer dans GA4 (Administration > Flux de données) et dans Google Ads (Diagnostics des conversions) que les signaux sont détectés.
• Tester le refus, l'acceptation partielle et l'acceptation totale.

Comment FlowConsent gère le Consent Mode v2

FlowConsent implémente le Consent Mode v2 nativement, sans modèle ni extension supplémentaire. Votre snippet d'intégration commence par un script en ligne qui enregistre les quatre valeurs denied par défaut, wait_for_update: 500, url_passthrough et ads_data_redaction avant le chargement de toute balise Google, puis le bandeau envoie gtag('consent', 'update', …) dès que le visiteur choisit. En cas de refus, les balises Google restent en mode sans cookies et envoient des pings gcs=G100, que le scan de conformité reconnaît comme conformes. Si une balise Google passe avant les valeurs par défaut, le bandeau affiche une erreur dans la console qui la nomme pour que vous puissiez la retirer. Avec GTM, le snippet se place au-dessus du conteneur, jamais à l'intérieur. Les détails sont dans la documentation Google Consent Mode et le guide d'installation avec Google Tag Manager. FlowConsent est gratuit jusqu'à 25 000 sessions par mois, hébergé en Europe, et s'installe en une dizaine de minutes.