Consent Mode v2 : implémentation, enforcement et les dix erreurs qui corrompent vos données

Le 21 juillet 2025, Google a appuyé sur un interrupteur. Les comptes qui n’avaient pas implémenté Consent Mode v2 pour le trafic EEE/Royaume-Uni ont vu le suivi des conversions, le remarketing et les rapports démographiques désactivés automatiquement. Aucun email d’avertissement. Aucun délai de grâce. Les rapports des sites affectés ont montré des chutes de métriques de 90 à 95% du jour au lendemain, et les données des périodes non conformes sont définitivement perdues, sans possibilité de remplissage rétroactif.

Si vous lisez ceci, soit vous avez été touché et devez corriger les choses, soit vous voulez vous assurer de ne pas être touché à l’avenir. Dans les deux cas, les détails d’implémentation comptent plus qu’on ne le pense. La plupart des échecs de Consent Mode se résument à des lacunes de configuration faciles à manquer et douloureuses à découvrir.

Consent Mode v1, lancé en 2020, avait deux paramètres : ad_storage (contrôle les cookies publicitaires) et analytics_storage (contrôle les cookies analytics). Ce sont des qualificateurs amont qui déterminent quels identifiants sont envoyés avec les pings de mesure.

V2, publié en novembre 2023, a ajouté deux nouveaux paramètres qui servent un objectif différent :

ad_user_data : indique aux services Google si les données personnelles peuvent être utilisées à des fins publicitaires. Lorsque refusé, le user_id et les données hachées d’Enhanced Conversions sont supprimés.
ad_personalization : indique aux services Google si le remarketing est autorisé. Lorsque refusé, la constitution d’audiences de remarketing s’arrête complètement.

Les paramètres d’origine contrôlent quelles données quittent le navigateur. Les nouveaux paramètres sont des instructions en aval qui contrôlent comment les serveurs de Google traitent les données qu’ils reçoivent. Vous pouvez accorder ad_storage (les cookies sont définis, les pings se déclenchent normalement) tout en refusant ad_user_data (Google reçoit le ping mais n’utilisera pas les données personnelles pour le ciblage publicitaire).

Google a rendu v2 obligatoire pour le trafic EEE/Royaume-Uni avant le 6 mars 2024. Le moteur juridique est le Digital Markets Act de l’UE, qui désigne Google comme un « gatekeeper » avec la responsabilité directe d’obtenir le consentement des utilisateurs. Cette obligation se répercute sur l’implémentation des tags de chaque annonceur.

Mode Basic versus Advanced

Ce choix détermine la quantité de données que vous collectez lorsque les utilisateurs refusent le consentement, et il a un impact direct sur la qualité de votre modélisation.

Le mode Basic bloque tous les tags Google jusqu’à ce que le consentement soit accordé. Quand un utilisateur refuse, rien ne se déclenche : aucun ping, aucun signal sans cookie, rien. Google peut toujours modéliser les conversions pour votre compte, mais il utilise un modèle sectoriel général plutôt qu’un modèle entraîné sur vos propres patterns de trafic.

Le mode Advanced charge les tags immédiatement, quel que soit l’état du consentement. Lorsque le consentement est refusé, les tags envoient des pings anonymes sans cookie (aucun cookie défini, aucun identifiant attaché). Quand le consentement est ensuite accordé, la mesure complète s’active. Ces pings sans cookie permettent à Google de construire un modèle de conversion spécifique à l’annonceur, entraîné sur vos véritables patterns de trafic. Les annonceurs constatent généralement 15 à 25% de conversions reportées en plus grâce à cette seule modélisation.

Le piège : la modélisation a des seuils de trafic minimum que la plupart des petits sites n’atteignent jamais.

Plateforme	Exigence minimum
Google Ads	700+ clics publicitaires sur 7 jours par pays et domaine
Modélisation comportementale GA4	1 000+ événements quotidiens avec analytics_storage refusé pendant 7 jours consécutifs ET 1 000+ utilisateurs quotidiens avec analytics_storage accordé pendant 7 des 28 derniers jours

Avec un taux de consentement de 50%, il faut environ 2 000 visiteurs quotidiens pour être éligible à la modélisation GA4. Si votre site n’atteint pas ces seuils, l’avantage de modélisation du mode Advanced disparaît en grande partie, bien que vous conserviez le bénéfice des pings sans cookie pour les données de tendance agrégées.

Réussir l’implémentation

Trois éléments doivent fonctionner ensemble : les états de consentement par défaut, l’intégration CMP, et (si vous l’utilisez) la configuration GTM côté serveur.

États de consentement par défaut

La commande par défaut doit se déclencher avant le chargement de tout tag de mesure. Dans GTM, cela signifie utiliser le déclencheur Consent Initialization - All Pages, qui se déclenche avant Initialization - All Pages et bien avant All Pages.

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

Le paramètre wait_for_update donne à votre CMP le temps de se charger et de mettre à jour le consentement avant que les tags n’évaluent leur état de consentement. Sans lui, les tags voient l’état par défaut (refusé) et peuvent se comporter comme si le consentement n’avait jamais été accordé, même après que le CMP ait envoyé une mise à jour quelques millisecondes plus tard. 500ms est une valeur par défaut sûre.

Intégration CMP

Votre plateforme de gestion du consentement (CMP) capture les choix des utilisateurs et doit les communiquer aux tags Google via l’API Consent Mode. Quand un utilisateur clique sur « Accepter », le CMP doit déclencher :

gtag('consent', 'update', {
  'ad_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted',
  'analytics_storage': 'granted'
});

La plupart des CMP certifiés (Cookiebot, OneTrust, Didomi, CookieYes, Axeptio) gèrent cela automatiquement lorsqu’ils sont correctement configurés. La vérification clé est que les quatre paramètres v2 apparaissent dans l’appel de mise à jour. Beaucoup d’anciennes configurations CMP n’envoient que les deux paramètres v1.

Google exige des éditeurs utilisant AdSense, Ad Manager ou AdMob qu’ils utilisent une CMP certifiée Google intégrée au TCF v2.2 pour les annonces personnalisées dans l’EEE/Royaume-Uni.

Consentement GTM côté serveur

Les implémentations côté serveur cassent souvent ici. GTM côté serveur n’a pas de Consent Mode intégré. Le consentement doit être configuré dans le conteneur web en premier. Le conteneur web encode l’état du consentement dans les paramètres gcs et gcd des requêtes HTTP qu’il envoie à votre conteneur serveur.

Le Client GA4 dans votre conteneur serveur lit ces paramètres automatiquement. Les tags de produits Google (GA4, Google Ads) dans le conteneur serveur ajustent ensuite leur comportement en fonction de l’état de consentement décodé. Mais les tags de fournisseurs non-Google (Meta CAPI, TikTok Events API, LinkedIn CAPI) n’ont aucune connaissance de ces signaux de consentement. Vous devez construire manuellement des conditions de déclenchement basées sur le consentement pour chaque tag de fournisseur non-Google.

Les dix erreurs qui cassent vos données

Elles sont classées approximativement par fréquence d’apparition et par l’ampleur des dégâts qu’elles causent.

1. État de consentement par défaut manquant

C’est l’erreur la plus courante. Si la commande consent('default', ...) ne se déclenche pas avant le chargement des tags de mesure, les tags considèrent que le consentement est accordé. Vous collectez techniquement des données sans consentement approprié pour les utilisateurs EEE/Royaume-Uni, et les vérifications de conformité de Google finiront par le détecter.

2. Envoi des paramètres v1 uniquement

Les implémentations qui définissent ad_storage et analytics_storage mais omettent ad_user_data et ad_personalization amènent Google à supposer l’absence de consentement pour l’utilisation des données publicitaires. Votre suivi de conversions semble fonctionner, mais les données Enhanced Conversions sont silencieusement ignorées et les audiences de remarketing cessent de se constituer.

3. Signaux de consentement n’atteignant pas les conteneurs côté serveur

Le conteneur web encode le consentement dans les paramètres des requêtes HTTP. Si votre configuration côté serveur supprime ou ne transmet pas ces paramètres, les tags côté serveur se déclenchent sans connaissance du consentement. Les tags Google fonctionneront (ils lisent les paramètres encodés), mais votre posture de conformité est cassée pour les fournisseurs non-Google.

4. Consentement spécifique par région non configuré

Définir le consentement comme denied globalement (y compris pour le trafic américain où l’opt-in n’est pas requis) signifie que vous perdez inutilement des données des visiteurs hors EEE. Définir le consentement comme granted globalement viole le RGPD pour les visiteurs de l’EEE. La solution est de définir des valeurs par défaut par région :

gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied',
  'region': ['EEA', 'GB']
});

gtag('consent', 'default', {
  'ad_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted',
  'analytics_storage': 'granted',
  'region': ['US']
});

Le paramètre de région le plus spécifique a toujours la priorité, donc US-CA prévaut sur un paramètre général US.

5. CMP chargé sans `wait_for_update`

Quand le CMP se charge de manière asynchrone (comme la plupart d’entre eux), une condition de concurrence peut se produire. Les tags évaluent l’état du consentement avant que le CMP n’ait eu le temps d’appeler consent('update', ...). Le paramètre wait_for_update dans la commande par défaut empêche cela en indiquant aux tags d’attendre le nombre de millisecondes spécifié avant d’évaluer.

C’est de la conformité visuelle sans conformité technique. La bannière s’affiche, l’utilisateur clique sur Accepter, un cookie stocke sa préférence, mais aucun appel gtag('consent', 'update', ...) ne se déclenche. Les tags Google ne savent jamais que le consentement a été accordé et continuent de fonctionner en mode refusé. Vérifiez la documentation de votre CMP pour confirmer qu’il s’intègre avec Consent Mode, pas uniquement avec le stockage de cookies.

7. Implémentations de tags en double

Les tags Google existent à la fois dans le header HTML du site et dans GTM. Les tags du header ne reçoivent pas les signaux de consentement de l’intégration Consent Mode de GTM. Ils se déclenchent inconditionnellement, créant une faille de conformité et potentiellement des données en double.

8. Conditions de déclenchement sensibles à la casse dans GTM côté serveur

Si vous avez nommé votre Client GA4 ga4 mais qu’une condition de déclenchement vérifie GA4, rien ne se déclenche. La condition Client Name dans les déclencheurs GTM côté serveur est sensible à la casse. Cela ne casse pas spécifiquement le consentement, mais cela casse entièrement votre configuration côté serveur.

9. Enhanced Conversions sans consentement `ad_user_data`

Enhanced Conversions envoie des données personnelles hachées (email, téléphone, adresse) à Google pour la correspondance d’identité. Si ad_user_data n’est pas défini sur granted, Google ignore ces données côté serveur, mais votre implémentation semble fonctionner correctement en mode aperçu. Vous ne découvrez le problème que des semaines plus tard quand les diagnostics Enhanced Conversions n’affichent aucune donnée.

10. Tests uniquement en état de consentement accordé

Tester uniquement le flux « consentement accordé ». Tout fonctionne quand vous acceptez tous les cookies. La question est ce qui se passe quand vous refusez, quand vous consentez partiellement, et quand vous révoquez un consentement précédemment accordé. Chaque état doit être vérifié.

Débogage avec les paramètres réseau

Une méthode de vérification fiable contourne entièrement l’interface de votre CMP et examine ce qui est réellement envoyé à Google.

Le paramètre `gcs`

Dans l’onglet Network de votre navigateur, filtrez les requêtes vers /g/collect ou google-analytics.com. Recherchez le paramètre &gcs=. Le format est G1xy où :

x = consentement ad_storage (1 = accordé, 0 = refusé)
y = consentement analytics_storage (1 = accordé, 0 = refusé)

G100 signifie les deux refusés (possible uniquement en mode Advanced, puisque le mode Basic n’enverrait aucun ping). G111 signifie les deux accordés.

Le paramètre `gcd`

C’est le paramètre spécifique à v2 encodant les quatre signaux de consentement. Chaque signal reçoit une lettre indiquant le parcours de consentement :

l = refusé par défaut, aucune mise à jour reçue
q = refusé par défaut, puis mis à jour vers accordé
t = accordé par défaut, aucune mise à jour reçue
p et r = autres états intermédiaires

Sur une page correctement configurée en mode Advanced avant que l’utilisateur n’interagisse avec la bannière, vous ne devriez voir que les valeurs p, q ou r. Si vous voyez t (accordé par défaut sans mise à jour), vos valeurs par défaut ne sont pas définies sur refusé pour cette région.

Outils utiles

L’extension Chrome Consent Mode Inspector fournit un affichage en temps réel de l’état du consentement et un historique de suivi sans fouiller dans les requêtes réseau. Dans le mode Preview de Google Tag Assistant, l’onglet Consent affiche l’état du consentement pour chaque événement. Vérifiez que ad_user_data et ad_personalization sont listés pour confirmer que v2 est actif. Si seuls ad_storage et analytics_storage apparaissent, vous êtes toujours sur v1.

Consent Mode n’est pas légalement requis pour le trafic exclusivement américain. Mais deux situations le rendent pratiquement nécessaire :

Si vous utilisez Enhanced Conversions ou partagez des données de conversion GA4 avec Google Ads, le paramètre ad_user_data doit être implémenté. Google l’exige indépendamment de la géographie quand des données personnelles sont impliquées.

Si vous utilisez le remarketing, le paramètre ad_personalization est requis.

Au-delà de ces exigences, le cas pratique se renforce. Huit États américains imposent désormais la reconnaissance du signal Global Privacy Control (GPC), et une enquête conjointe de la Californie, du Colorado et du Connecticut a produit des règlements à sept chiffres pour non-conformité. Les réglementations californiennes de 2026 ajoutent des évaluations de risques obligatoires et des interdictions élargies des dark patterns (les boutons de consentement asymétriques sont explicitement visés).

Google prend en charge le Restricted Data Processing (RDP) pour la conformité CCPA et l’IAB Privacy Multi-State Privacy Agreement via les chaînes GPP. La configuration recommandée utilise des valeurs par défaut par région : refusé pour l’EEE/GB, accordé avec mécanismes d’opt-out pour US-CA, et accordé pour le reste du monde.

Alors que les lois sur la vie privée des États américains continuent de s’étendre (20 États disposent désormais de lois complètes sur la vie privée, avec d’autres entrant en vigueur courant 2026), implémenter Consent Mode maintenant construit l’infrastructure de conformité dont vous aurez besoin de toute façon.

Ce que décembre 2025 a discrètement changé

En décembre 2025, Google a ajouté des contrôles de transmission de données aux paramètres Google Tag. Simo Ahava a décrit cela comme « essentiellement un contrôle de type Basic Consent Mode par-dessus une configuration Advanced Consent Mode ». Cela signifie que Google ajoute une couche supplémentaire d’enforcement du consentement côté serveur par-dessus ce que votre implémentation côté client envoie. La direction est claire : les contrôles de consentement vont devenir plus stricts, pas plus souples.

Si votre implémentation fonctionne correctement aujourd’hui, maintenez-la. Si ce n’est pas le cas, la fenêtre pour la corriger sans perte de données permanente s’est déjà fermée une fois. La prochaine vague d’enforcement ne viendra pas non plus avec un préavis. Pour une vision plus large de pourquoi le tracking côté serveur est désormais incontournable, la pression de conformité décrite ici n’est qu’une partie du tableau.