Une configuration incorrecte du Consent Mode v2 fait disparaître une part non négligeable des conversions dans Google Ads ou Analytics, même si les balises semblent déclenchées. Sur des boutiques françaises, la séquence CMP-GTM-balises rompt souvent à cause d’un chargement asynchrone ou d’un état de consentement par défaut mal géré. Beaucoup supposent que l’activation tardive du Consent Mode suffirait à « récupérer » les conversions rétroactivement, ce qui est faux : selon le timing, les événements sont ignorés ou dégradés sans alerte visible.
À la lecture, vous saurez diagnostiquer où les pertes de conversions se produisent, repérer les erreurs d’implémentation typiques, et appliquer les correctifs concrets pour réduire l’impact sur votre chiffre d’affaires — selon les contraintes CNIL et les spécificités du marché français.
Consent Mode v2 : ce qui change pour le tracking en France
Consent Mode v2 introduit deux nouveaux états de consentement : ad_user_data et ad_personalization, qui s’ajoutent aux paramètres existants analytics_storage et ad_storage. Une configuration correcte doit explicitement gérer ces quatre signaux. Beaucoup de configurations françaises laissent les nouveaux paramètres à leur valeur par défaut, ce qui bloque la collecte de conversions sur Google Ads et limite la modélisation côté Google Analytics 4.
La CNIL impose que le dépôt de cookies à des fins publicitaires ou de mesure non exemptée ne soit déclenché qu’après recueil d’un consentement explicite. Le Consent Mode ne remplace pas la CMP (Consent Management Platform), il se contente de relayer l’état de consentement à Google via GTM ou le gtag. Si la CMP ne transmet pas les états complets — notamment les deux nouveaux — le tag Google Ads ou GA4 considère l’utilisateur comme non consenti, même si le visiteur a accepté les cookies. Ce point est critique pour la conformité CNIL, car une erreur de mappage ou un oubli de paramètre se traduit par une perte sèche de conversions attribuées.
Le Consent Mode permet à Google d’adapter dynamiquement le comportement de ses tags : en mode denied, aucun cookie n’est déposé, les requêtes sont anonymisées, et la donnée de conversion n’alimente ni le reporting ni les algorithmes d’enchères. Si l’implémentation n’anticipe pas les quatre paramètres — par exemple, si le data layer ne pousse que ad_storage et analytics_storage —, la collecte se retrouve partiellement ou totalement bloquée.
Pour vérifier le bon fonctionnement, inspectez l’état des paramètres dans le Consent Debug Mode de Google Tag Manager ou via le Gestionnaire d’événements Google. Toute absence ou valeur denied inattendue sur ad_user_data ou ad_personalization indique un défaut qui coupe la chaîne de conversion.
Ordre de chargement CMP, GTM et balises : le vrai point de rupture
Le séquencement CMP, Consent Mode et GTM détermine si les conversions sont correctement attribuées. Le Consent Mode doit être initialisé avant tout déclenchement de balises ou d’appels de tags soumis au consentement. En France, la plupart des CMP (Consent Management Platform) injectent leur script en priorité, mais les erreurs d’implémentation surviennent quand GTM ou les tags analytics se chargent avant que le Consent Mode n’ait pris connaissance des choix de l’utilisateur.
Si le Consent Mode n’est pas prêt au moment où GTM initialise ses balises, les tags Google (par exemple gtag.js ou analytics.js) partent avec l’état par défaut, généralement denied pour la publicité et la mesure. Résultat : aucun cookie publicitaire ni de suivi de conversion n’est posé, même si l’utilisateur accepte ensuite. Le Consent Mode ne rétroagit pas sur les événements déjà envoyés. Les conversions générées durant cette fenêtre sont donc définitivement perdues pour les plateformes Google Ads, GA4 ou Floodlight.
Le schéma classique qui provoque ce bug :
- Le script GTM (ou Google Tag) est inséré en haut du
<head>, avant la CMP. - GTM déclenche les balises de mesure ou conversion dès le
Pageviewou un événement personnalisé. - La CMP s’affiche après, puis applique les choix de consentement. Mais les balises ont déjà tiré leur événement, sans le consentement effectif.
Un autre cas fréquent : la CMP ne relaie pas correctement les statuts de consentement au Consent Mode (par exemple, le mapping CMP → gtag('consent', ...) est absent ou mal ordonné). GTM croit que le consentement est « denied » ou reste en état indéfini, ce qui bloque ou anonymise les événements.
Pour diagnostiquer ces ruptures, ouvrez l’onglet Réseau de votre navigateur. Vérifiez l’ordre d’apparition des requêtes collect (GA4) ou ads/ (Google Ads), et comparez-le à l’instant où la CMP affiche le choix de consentement. Inspectez aussi les logs gtag('consent', ...) dans la console pour confirmer que le statut est défini avant l’appel des tags de conversion.
En France, la CNIL exige que le consentement soit recueilli avant tout dépôt de cookie non exempté. Si le Consent Mode est initialisé trop tard, la conformité est compromise et les données de conversion sont inexploitables.
États par défaut et comportements inattendus du Consent Mode v2
La plupart des implémentations françaises utilisent une CMP compatible TCF v2 qui initialise le Consent Mode via Google Tag Manager. Par défaut, si aucun état explicite n’est transmis avant le déclenchement des balises, Consent Mode v2 applique ses propres valeurs initiales. Les paramètres concernés incluent ad_storage, analytics_storage, functionality_storage et personalization_storage. Sans signal clair, ces valeurs sont généralement positionnées à 'denied', bloquant la collecte de données non exemptées.
Sur GTM, si l’événement consent n’est pas déclenché avant le déclenchement des balises Google Ads ou Google Analytics, les balises s’exécutent en mode « no consent ». Cela signifie qu’aucun cookie n’est déposé et que les requêtes envoyées à Google comportent un marquage d’absence de consentement. Même si l’utilisateur donne son accord plus tard, les événements critiques (ex : purchase) déjà déclenchés ne sont pas rejoués automatiquement.
Conséquence directe : les conversions réalisées avant expression du consentement ne sont pas attribuées, ni même modélisées, sauf dans certains cas très spécifiques où Google propose une modélisation partielle. Cette modélisation dépend de la configuration du compte, de la plateforme utilisée et de l’éligibilité au consent mode modeling, qui n’est pas systématique en France. Les conversions perdues ne sont pas visibles dans l’interface Google Ads ou Analytics : elles n’apparaissent tout simplement pas.
Pour vérifier si votre setup est touché, observez l’ordre d’exécution dans l’onglet « Réseau » de votre navigateur. Si une balise Google Analytics ou Ads s’exécute avec gcs=100 ou gcs=G100 dans la requête avant que l’utilisateur ait interagi avec la CMP, c’est le signe que le consentement n’a pas été transmis à temps.
Erreurs fréquentes d’implémentation et diagnostics pratiques
Le scénario le plus courant : la CMP ne pousse pas l’état de consentement dans le dataLayer avant le déclenchement des balises. Beaucoup de CMP en France insèrent l’objet de consentement via un événement personnalisé (consent_update, tarteaucitron.js ou autre) mais ce push arrive souvent après le chargement initial de GTM. Résultat : les balises conditionnées au consentement s’exécutent avec les états par défaut, souvent denied, ce qui bloque la collecte de conversions même après acceptation.
Vérifiez l’occurrence du push consentement dans le dataLayer : ouvrez l’onglet Réseau du navigateur, rechargez la page, et cherchez si l’événement de consentement est bien injecté avant l’événement gtm.js. Si ce n’est pas le cas, le tag manager ne reçoit pas le bon état au moment critique.
Deuxième point de rupture : des balises de conversion (Google Ads, GA4, Meta Pixel) déclenchées sur des événements comme purchase ou lead sans condition explicite sur l’état de consentement. Même si le Consent Mode v2 est activé, si la condition n’est pas présente dans le déclencheur, la balise part systématiquement, ce qui expose à la fois à des pertes de conversions (balise bloquée côté navigateur) et à des risques CNIL (absence de consentement effectif).
Avec plusieurs conteneurs GTM (par exemple, un pour le site, un pour un sous-domaine ou une webapp), la synchronisation de l’état de consentement est rarement fiable. Le push dans le dataLayer n’est pas partagé entre les contextes : chaque conteneur doit recevoir explicitement l’état actuel. Vérifiez que chaque conteneur reçoit bien l’événement de consentement : inspectez le dataLayer de chaque contexte et comparez l’état affiché.
Les scripts tiers (widgets de chat, modules de recommandation, plugins analytics) chargent parfois leurs propres balises avant la déclaration de consentement, ignorant l’état du Consent Mode. Surveillez le chargement de ces scripts dans l’onglet Réseau et vérifiez s’ils se déclenchent avant le push de consentement.
Contrôler et auditer la chaîne de consentement : méthodes concrètes
Commencez par observer le dataLayer dans votre navigateur (onglet Réseau ou Console). Vérifiez que chaque changement d’état de consentement — typiquement, l’action sur la bannière CMP — pousse bien un événement dans le dataLayer. Pour Google Consent Mode v2, l’événement attendu est souvent consent, mais vérifiez le nom exact utilisé par votre CMP et GTM. Analysez la structure de l’objet : les clés attendues incluent ad_storage, analytics_storage, et pour v2, ad_user_data et ad_personalization. Contrôlez que la valeur transmise correspond à l’action réelle de l’utilisateur (granted ou denied).
Pour auditer l’exécution des balises de conversion, activez l’aperçu (Preview) dans Google Tag Manager. Simulez différents états de consentement via la CMP et observez si les balises conversion (Google Ads, Meta, etc.) se déclenchent ou non. Vérifiez également dans le flux réseau que les appels aux endpoints d’Analytics ou d’Ads sont effectivement envoyés — absence de requête = conversion perdue. Sur Meta, la logique côté navigateur et côté serveur peut diverger selon le paramétrage du Consent Mode et du CAPI ; testez les deux flux.
En France, assurez-vous que la CMP figure bien sur la liste des solutions validées par la CNIL. Les exemptions de consentement pour la mesure d’audience ne s’appliquent que si la configuration respecte les critères précis de la CNIL, notamment l’anonymisation de l’IP et l’absence de reciblage publicitaire. Inspectez les paramètres transmis à Google Analytics : la présence de gtag('consent', ...) avec des valeurs denied ou granted doit correspondre à l’interface utilisateur de la CMP, sans délai ni état par défaut permissif.
Documentez chaque étape de la chaîne : état initial au chargement, push du consentement, déclenchement effectif des balises, et conformité des paramètres transmis. Toute incohérence entre l’intention utilisateur, l’état du dataLayer et les requêtes envoyées signale un point de rupture.
Limiter la perte de conversions : correctifs et bonnes pratiques
Pour éviter la perte de conversions liée à une intégration défaillante du Consent Mode v2, le séquençage du chargement CMP, Consent Mode et GTM doit être strict. Le script du CMP doit charger en premier, en mode blocking si possible, pour garantir que l’état de consentement soit disponible avant l’initialisation de Google Tag Manager. Chargez le script de Consent Mode immédiatement après, puis initialisez GTM seulement lorsque l’état de consentement est connu et transmis. Toute balise qui collecte des conversions (Google Ads, GA4, Meta, etc.) doit attendre ce signal.
En France, le comportement par défaut du Consent Mode v2 en l’absence de choix explicite reste souvent denied pour ad_storage et analytics_storage. Cela provoque la perte de conversions si l’utilisateur ne fait aucun choix. Pour limiter l’impact, configurez le CMP pour déclencher un rappel même en cas d’absence de réponse après un délai raisonnable (par exemple 30 secondes), et transmettez explicitement l’état au Consent Mode. Vérifiez que la transmission des événements update ou default vers le data layer ne dépend pas uniquement d’un clic, mais aussi d’un timeout.
Automatisez les tests suivants à chaque déploiement :
- État du consentement transmis à GTM à l’arrivée sur le site, sans interaction
- Comportement des balises de conversion lorsque l’utilisateur n’interagit pas avec la CMP
- Déclenchement effectif des conversions en mode
grantedaprès consentement, et absence endenied - Transmission correcte des signaux de consentement dans les outils de diagnostic Google (ex : DebugView GA4, Tag Assistant)
Inspectez le data layer pour chaque scénario. En cas de doute sur le nom exact des événements ou des variables, vérifiez la documentation officielle du CMP et du Consent Mode, ou inspectez le flux d’événements dans le navigateur.
Frequently asked questions
Comment vérifier si le Consent Mode v2 est bien initialisé avant GTM ?
Décrire comment inspecter le dataLayer pour repérer l’initialisation du Consent Mode avant tout déclenchement de balise, et recommander l’utilisation d’outils de debug comme Tag Assistant ou les DevTools pour tracer les pushs d’événements.
Peut-on récupérer les conversions perdues après une mauvaise configuration ?
Expliquer que les conversions non transmises à Google (Ads, Analytics) ne sont généralement pas récupérables rétroactivement, mais qu’un audit permet de limiter les pertes futures et d’optimiser la modélisation.
Not sure your tracking is telling you the truth?
Propulse Agency audits e-commerce tracking setups — server-side tagging, Meta CAPI, GA4 and consent — and fixes what is quietly costing you conversions.
Prioriser l’audit de l’exécution réelle du Consent Mode
Commencez par vérifier la séquence de chargement réelle : la CMP doit systématiquement définir les états de consentement avant que GTM ne charge la moindre balise. Contrôlez, dans le réseau, que la commande gtag('consent', ...) ou son équivalent est envoyée avant tout événement gtag('event', ...) ou déclenchement de balise Analytics/Ads.
Ne vous fiez pas à la documentation de la CMP ou aux promesses du fournisseur sur la compatibilité Consent Mode v2. Testez le comportement sur votre site avec des navigateurs propres et des statuts de consentement variés. De nombreux échecs proviennent d’un timing mal maîtrisé ou d’un état par défaut incorrect, rarement d’un défaut d’intégration de la bibliothèque elle-même.
Reviewed and updated by fodil on Jul 31, 2026.
