ServicesÀ proposNotesContact Me contacter →
EN FR
Note

Mécaniques d'implémentation de Consent Mode

L'implémentation technique de Consent Mode v2 : configuration des états par défaut, intégration CMP, ordre des déclencheurs GTM, et la condition de course wait_for_update.

Planté
ga4google adsanalyticsdata quality

Une implémentation correcte de Consent Mode nécessite trois composants en séquence : des états de consentement par défaut définis avant que les tags se chargent, une communication des choix de l’utilisateur par le CMP via l’API Consent Mode, et une gestion du timing pour éviter les conditions de course. La plupart des échecs d’implémentation remontent à l’un de ces trois composants mal configuré ou mal ordonné.

États de consentement par défaut

La commande de consentement par défaut doit se déclencher avant que les tags de mesure se chargent. Cela définit l’hypothèse de base pour les quatre paramètres de consentement jusqu’à ce que l’utilisateur fasse un choix.

Dans GTM, cela signifie utiliser le déclencheur Consent Initialization - All Pages. GTM a un ordre d’exécution des déclencheurs spécifique :

  1. Consent Initialization - All Pages — se déclenche en premier, avant tout autre chose
  2. Initialization - All Pages — se déclenche en deuxième, typiquement là où les tags de configuration GA4 se chargent
  3. All Pages — se déclenche en troisième, là où la plupart des tags d’événement s’exécutent

La commande de consentement par défaut appartient à l’étape 1. Si elle se déclenche à l’étape 2 ou 3 (une erreur courante), les tags de mesure dans les groupes de déclencheurs antérieurs se chargent avant que l’état de consentement soit établi. Ces tags supposent que le consentement est accordé — la valeur par défaut lorsqu’aucune commande de consentement n’a été traitée — et se déclenchent inconditionnellement.

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

Pour les sites avec un trafic mondial, les valeurs par défaut spécifiques à la région empêchent une perte de données inutile pour les visiteurs non-EEE tout en maintenant la conformité pour les utilisateurs EEE/Royaume-Uni :

// EEE et Royaume-Uni : refusé par défaut, opt-in requis
gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied',
  'region': ['EEA', 'GB'],
  'wait_for_update': 500
});


// US : accordé par défaut (modèle opt-out)
gtag('consent', 'default', {
  'ad_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted',
  'analytics_storage': 'granted',
  'region': ['US']
});

La spécificité des régions suit une règle du plus spécifique l’emporte. Un paramètre de région US-CA remplace un paramètre général US. Cela vous permet d’appliquer des valeurs par défaut plus strictes pour la Californie (CCPA) tout en maintenant un modèle opt-out plus permissif pour le reste des États-Unis.

Définir le consentement sur denied globalement — y compris pour le trafic US — signifie que vous perdez inutilement des données des visiteurs des régions où l’opt-in n’est pas requis. Le définir sur granted globalement viole le RGPD pour les visiteurs EEE. Les valeurs par défaut spécifiques à la région résolvent ces deux problèmes.

Le paramètre wait_for_update

Ce paramètre traite une condition de course qui casse silencieusement de nombreuses implémentations. La plupart des CMP se chargent de manière asynchrone. Le script CMP doit télécharger, s’initialiser, vérifier une préférence de consentement stockée, puis déclencher un appel de mise à jour du consentement. Cela prend du temps — typiquement de 100 à 500 millisecondes.

Sans wait_for_update, les tags évaluent leur état de consentement immédiatement après que la commande par défaut définit tout sur denied. Si le CMP n’a pas encore déclenché sa mise à jour (ce qui est probable, compte tenu du chargement asynchrone), les tags voient denied et se comportent en conséquence. En mode Basic, ils ne se déclenchent pas du tout. En mode Advanced, ils envoient des pings sans cookies. Même si le CMP déclenche sa mise à jour 200 ms plus tard, le mal est fait — l’évaluation initiale du tag a déjà eu lieu.

wait_for_update: 500 dit aux tags d’attendre jusqu’à 500 millisecondes après la commande par défaut avant d’évaluer l’état du consentement. Si le CMP déclenche une mise à jour dans cette fenêtre, les tags utilisent l’état mis à jour. Si le CMP ne répond pas dans les 500 ms (réseau lent, problèmes de chargement du CMP), les tags reviennent à l’état de refus par défaut.

500 ms est une valeur par défaut sûre pour la plupart des CMP sur des connexions raisonnables. Certaines implémentations utilisent 300 ms pour des pages plus rapides ou 1 000 ms pour des sites avec des configurations CMP lourdes. Le compromis est la performance du chargement de page : pendant la période d’attente, les tags sont bloqués de se déclencher même si l’état du consentement est en réalité connu.

Intégration CMP

La plateforme de gestion du consentement capture les choix des utilisateurs (Accepter, Rejeter, préférences granulaires) et doit les communiquer aux tags Google via l’API Consent Mode. Lorsqu’un utilisateur clique sur Accepter :

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

La vérification critique : les quatre paramètres v2 doivent apparaître dans l’appel de mise à jour. De nombreuses configurations CMP plus anciennes — mises en place avant novembre 2023 quand v2 a été lancée — n’envoient que les deux paramètres v1 (ad_storage et analytics_storage). Lorsque ad_user_data et ad_personalization sont absents de la mise à jour, Google suppose qu’ils restent refusés. C’est l’un des modes d’échec les plus courants : le suivi des conversions semble fonctionner, mais les données Enhanced Conversions sont silencieusement abandonnées et les audiences de remarketing cessent de se construire.

CMP certifiés

Google exige que les éditeurs utilisant AdSense, Ad Manager ou AdMob utilisent un CMP certifié par Google intégré avec TCF v2.2 pour les annonces personnalisées dans l’EEE/Royaume-Uni. Les principaux CMP certifiés incluent Cookiebot, OneTrust, Didomi, CookieYes et Axeptio.

Les CMP certifiés gèrent l’appel gtag('consent', 'update', ...) automatiquement lorsqu’ils sont correctement configurés. Mais “correctement configuré” est la phrase opérante. Lacunes de configuration courantes :

  • CMP installé mais intégration Consent Mode non activée (c’est souvent un toggle séparé)
  • CMP configuré uniquement pour les paramètres v1 (un template ou une version plus ancienne)
  • CMP stocke le consentement dans des cookies mais ne déclenche pas l’appel de mise à jour gtag (conformité visuelle sans conformité technique)
  • CMP déclenche la mise à jour mais avec un mappage de paramètres incorrect (par exemple, mapper le but TCF 1 à analytics_storage mais pas à ad_user_data)

Vérification

La façon la plus fiable de vérifier l’intégration CMP n’est pas via le panneau d’administration du CMP — c’est en inspectant ce qui est réellement envoyé. Utilisez les paramètres réseau gcs et gcd pour confirmer que les quatre paramètres sont correctement définis dans les états par défaut et de mise à jour. L’extension Chrome Consent Mode Inspector fournit une visibilité en temps réel sans avoir à fouiller dans les requêtes réseau.

Implémentations hors GTM

Si vous implémentez Consent Mode en dehors de GTM (directement dans le code du site ou via un autre gestionnaire de tags), les mêmes principes s’appliquent mais le mécanisme d’ordre des déclencheurs diffère :

  1. L’appel gtag('consent', 'default', ...) doit s’exécuter avant l’appel gtag('js', ...) qui initialise les tags Google
  2. Votre callback CMP doit appeler gtag('consent', 'update', ...) quand l’utilisateur fait un choix
  3. La bibliothèque gtag elle-même doit être chargée (la commande consent se met en file d’attente si gtag n’est pas encore chargé, ce qui est acceptable)
<!-- 1. Définir les valeurs par défaut EN PREMIER -->
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('consent', 'default', {
    'ad_storage': 'denied',
    'ad_user_data': 'denied',
    'ad_personalization': 'denied',
    'analytics_storage': 'denied',
    'wait_for_update': 500
  });
</script>


<!-- 2. Charger gtag.js -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXX"></script>
<script>
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXXX');
</script>


<!-- 3. Le CMP déclenche la mise à jour au choix de l'utilisateur (géré par le script CMP) -->

La garantie d’ordre vient du placement des scripts dans le HTML plutôt que du système de déclencheurs de GTM. La commande par défaut est synchrone et inline, elle s’exécute donc toujours avant que le script gtag.js asynchrone se charge.