La plupart des échecs de Consent Mode sont des lacunes de configuration plutôt que des problèmes techniques complexes. Ils sont faciles à créer lors de l’implémentation, difficiles à détecter sans tests délibérés, et dommageables parce qu’ils corrompent silencieusement les données plutôt que de produire des erreurs visibles. Ces dix erreurs sont classées approximativement par fréquence d’apparition dans la pratique et par impact.
1. État de consentement par défaut manquant
L’erreur la plus courante. Si la commande consent('default', ...) ne se déclenche pas avant le chargement des tags de mesure, les tags supposent que le consentement est accordé. Chaque événement se déclenche comme si l’utilisateur avait consenti, peu importe ce que montre la bannière du CMP.
Pourquoi cela se produit : La commande par défaut est placée dans le mauvais déclencheur GTM (en utilisant Initialization - All Pages au lieu de Consent Initialization - All Pages), ou elle est placée après l’appel de configuration gtag dans le code inline.
Détection : Vérifiez le paramètre gcs au chargement initial de la page avant d’interagir avec la bannière. Si vous voyez G111 au lieu de G100, les valeurs par défaut ne sont pas définies. Si gcs est complètement absent, l’API de consentement n’est pas chargée.
Impact : Vous collectez techniquement des données sans consentement approprié pour les utilisateurs de l’EEE/Royaume-Uni. Les contrôles de conformité de Google finiront par le détecter, et les données des périodes non conformes sont irrécupérables.
2. Envoi uniquement des paramètres v1
Implémentations qui définissent ad_storage et analytics_storage mais omettent ad_user_data et ad_personalization. Cela se produit typiquement avec des configurations CMP plus anciennes créées avant novembre 2023.
Pourquoi cela se produit : Le template CMP a été configuré pour Consent Mode v1 et n’a pas été mis à jour. Le CMP déclenche une mise à jour du consentement, mais n’inclut que deux des quatre paramètres requis.
Détection : Dans le paramètre gcd, deux positions montrent q (mis à jour vers accordé) après que l’utilisateur accepte, mais les deux autres montrent l (refusé par défaut, aucune mise à jour). Dans Google Tag Assistant, seuls ad_storage et analytics_storage apparaissent dans l’onglet Consentement.
Impact : Le suivi des conversions semble fonctionner, ce qui explique pourquoi cette erreur persiste sans être détectée. Mais les données Enhanced Conversions sont silencieusement abandonnées (parce que ad_user_data est refusé), et les audiences de remarketing cessent de se construire (parce que ad_personalization est refusé). Vous découvrez le problème des semaines plus tard dans les diagnostics Enhanced Conversions ou lorsque les tailles d’audiences de remarketing stagnent.
3. Signaux de consentement n’atteignant pas les conteneurs server-side
Le conteneur web encode le consentement dans les paramètres de requête HTTP gcs et gcd. Si votre configuration server-side supprime ou ne transmet pas ces paramètres, les tags server-side se déclenchent sans conscience du consentement.
Pourquoi cela se produit : Des proxies intermédiaires, CDN ou équilibreurs de charge modifient la requête avant qu’elle n’atteigne le conteneur serveur. Ou le conteneur serveur a le mauvais Client qui revendique les requêtes, et les paramètres de consentement ne sont pas analysés.
Détection : En mode Preview de GTM server-side, vérifiez les données d’événement de la requête entrante pour les champs gcs et gcd. S’ils sont manquants, le consentement n’atteint pas le serveur.
Impact : Les tags Google continueront de fonctionner (ils lisent les paramètres encodés depuis le Client GA4), mais votre position de conformité est brisée pour les fournisseurs non-Google. Les tags Meta CAPI, TikTok Events API et LinkedIn CAPI se déclenchent sans vérifications de consentement, envoyant potentiellement des données personnelles à des tiers contre la volonté de l’utilisateur.
4. Consentement spécifique à la région non configuré
Définir le consentement à denied globalement (y compris pour le trafic US) ou à granted globalement (y compris pour le trafic EEE). Les deux sont incorrects.
Pourquoi cela se produit : L’implémentation utilise une seule commande de consentement par défaut sans le paramètre region. Les équipes définissent soit tout sur refusé (sûr mais avec perte de données), soit sur accordé (dangereux).
Détection : Vérifiez l’état du consentement pour les requêtes provenant de différentes régions. Si le trafic US montre G100 au chargement initial, les valeurs par défaut sont trop restrictives. Si le trafic EEE montre G111 avant l’interaction avec la bannière, les valeurs par défaut sont trop permissives.
Impact : Refus global : vous perdez 100 % des données de mesure des visiteurs non-EEE jusqu’à ce qu’ils consentent explicitement, même si le consentement n’est pas légalement requis dans ces régions. Accord global : vous violez le RGPD pour chaque visiteur EEE et faites face à un risque d’application.
Correction : Utilisez des valeurs par défaut spécifiques à la région. Refusé pour l’EEE/GB, accordé pour les US (avec des mécanismes d’opt-out appropriés), et une valeur par défaut raisonnée pour le reste du monde.
5. CMP chargé sans wait_for_update
Les tags évaluent l’état du consentement avant que le CMP ait eu la chance d’appeler consent('update', ...). La condition de course dépend du timing, ce qui la rend intermittente et difficile à reproduire.
Pourquoi cela se produit : Le paramètre wait_for_update est omis de la commande de consentement par défaut. La plupart des CMP se chargent de manière asynchrone et ont besoin de 100 à 500 ms pour s’initialiser et vérifier les préférences de consentement stockées.
Détection : Échecs de consentement intermittents où certains chargements de page montrent un consentement correct et d’autres non. Les utilisateurs avec des connexions plus lentes sont plus affectés. Le paramètre gcd peut montrer l (aucune mise à jour) sur certains chargements de page et q (mis à jour) sur d’autres pour le même utilisateur consenti.
Impact : Mesure incohérente. Certains chargements de page capturent des données complètes, d’autres ne capturent que des pings sans cookies (mode Advanced) ou rien (mode Basic). L’incohérence rend le problème difficile à quantifier.
6. Bannière de cookies sans câblage de l’API Consent Mode
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. C’est une conformité visuelle sans conformité technique.
Pourquoi cela se produit : Le CMP a été installé pour satisfaire une exigence légale de checkbox, pas pour une intégration technique avec la stack de mesure de Google. Le CMP gère les cookies et affiche une bannière mais ne s’intègre pas avec l’API Consent Mode.
Détection : Après avoir cliqué sur Accepter, le paramètre gcd montre toujours l (refusé par défaut, aucune mise à jour reçue). La mise à jour du consentement ne se déclenche jamais, donc les tags Google continuent de fonctionner en mode refusé de façon permanente.
Impact : Vous ne collectez aucune donnée utilisable des utilisateurs EEE/Royaume-Uni (mode Basic) ou seulement des pings sans cookies (mode Advanced), même après qu’ils ont explicitement accordé leur consentement. La bannière donne l’impression d’un système fonctionnel tandis que la mesure est fondamentalement cassée.
7. Implémentations de tags dupliquées
Les tags Google existent à la fois dans l’en-tête HTML du site (codé en dur) et à l’intérieur de GTM. Les tags dans l’en-tête ne reçoivent pas les signaux de consentement de l’intégration Consent Mode de GTM.
Pourquoi cela se produit : Un développeur a ajouté gtag.js directement dans la section <head> du site. Plus tard, une équipe marketing a implémenté GTM avec Consent Mode. Les tags inline originaux n’ont jamais été supprimés.
Détection : Plusieurs requêtes /g/collect pour le même événement. Un ensemble respecte le consentement (depuis GTM), l’autre se déclenche inconditionnellement (depuis le tag inline). Vérifiez l’onglet réseau pour les ID de mesure dupliqués.
Impact : Lacune de conformité (les tags inline ignorent le consentement) plus des données dupliquées dans votre propriété GA4. Les événements dupliqués gonflent les comptages de sessions, les pages vues et potentiellement les conversions.
8. Conditions de déclencheur sensibles à la casse dans GTM server-side
Si vous avez nommé votre Client GA4 ga4 mais qu’une condition de déclencheur vérifie GA4, rien ne se déclenche. Les conditions de déclencheur GTM server-side sont sensibles à la casse.
Pourquoi cela se produit : Erreur humaine lors de la configuration du conteneur serveur. Le nom du Client est défini dans une casse, les conditions de déclencheur référencent une casse différente.
Détection : Les tags ne se déclenchent pas du tout en mode Preview GTM server-side. Les événements arrivent au conteneur serveur mais aucun tag ne répond.
Impact : Cela casse l’intégralité de votre configuration server-side, pas seulement le consentement. Aucun tag server-side ne se déclenche, ce qui signifie aucune mesure server-side, aucun événement CAPI, rien.
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é. Sans ad_user_data défini sur granted, Google abandonne ces données côté serveur.
Pourquoi cela se produit : Enhanced Conversions a été implémenté et testé en mode preview, où les états de consentement peuvent ne pas refléter le comportement réel des utilisateurs. L’implémentation fonctionne en test parce que le mode preview est par défaut en consentement complet.
Détection : Les diagnostics Enhanced Conversions dans Google Ads ne montrent aucune donnée correspondante, ou les taux de correspondance sont bien inférieurs aux attentes. Le paramètre gcd montre ad_user_data comme l (refusé) même après que le consentement est accordé, indiquant que le CMP n’envoie pas la mise à jour du paramètre v2.
Impact : Enhanced Conversions fournit 5 à 15 % de conversions attribuées en plus grâce à la correspondance d’identité. Avec ad_user_data refusé, l’ensemble de ce pipeline de correspondance est désactivé. L’optimisation de vos Google Ads fonctionne avec moins de données de conversion, entraînant de moins bonnes performances d’enchères.
10. Ne pas tester sur tous les états de consentement
Tester uniquement le flux “consentement accordé”. Tout fonctionne quand vous acceptez tous les cookies. La question est de savoir ce qui se passe quand vous refusez, quand vous consentez partiellement, et quand vous révoquez un consentement précédemment accordé.
Pourquoi cela se produit : Les processus QA se concentrent sur les chemins heureux. L’état de refus de consentement est traité comme un cas limite plutôt que comme l’expérience par défaut d’une portion significative des utilisateurs.
Ce qu’il faut tester :
- Consentement complet : les quatre paramètres accordés
- Refus complet : les quatre paramètres refusés
- Consentement partiel : analytics accordé, publicité refusée
- Révocation du consentement : l’utilisateur passe de accordé à refusé en cours de session
- Visite de retour : l’utilisateur revient avec une préférence de consentement précédemment stockée
Chaque état doit produire le comportement attendu à la fois dans le conteneur web et le conteneur server-side. Vérifiez en utilisant les paramètres réseau, pas les interfaces du CMP.
La plupart de ces erreurs produisent des données qui semblent plausibles — les sessions apparaissent dans GA4, les conversions s’affichent dans Google Ads, les tableaux de bord ont l’air normaux. Les erreurs sont silencieuses : elles suppriment des signaux, abandonnent des données ou créent des lacunes de conformité sans erreurs visibles. Une détection fiable nécessite une vérification systématique de ce que le navigateur envoie réellement, pas ce que l’interface utilisateur rapporte.