Cette obligation d'outillage n'est pas gratuite : elle découle du cadre RGPD et DMA du ciblage publicitaire, qui impose de recueillir et respecter le choix utilisateur avant les traitements publicitaires qui nécessitent ce consentement.
Pourquoi votre CMP actuelle ne suffit peut-être pas à mesurer correctement
Sur les sites des éditeurs de CMP, on vous vend un bandeau : ses couleurs, ses textes, son taux d’acceptation. Le bandeau est la partie visible. La partie qui compte est invisible : à chaque choix d’un visiteur, la CMP doit produire et transmettre quatre signaux aux balises Google, ad_storage, analytics_storage, ad_user_data, ad_personalization.
C’est un routeur de signaux. Si le routage fonctionne, votre mesure vit selon les choix de vos visiteurs.
S’il échoue, vous tombez dans l’un des angles morts des deux régimes du Consent Mode v2 : un bandeau qui s’affiche, mais des signaux incomplets ou mal transmis. Le sujet dépasse alors la conformité : la mesure publicitaire devient moins fiable.
Choisir une CMP au design du bandeau, c’est choisir un routeur à la couleur du boîtier.
Quels critères pour choisir une CMP compatible Consent Mode v2 ?
La certification Google et les quatre critères qui comptent
Quatre critères de choix, dans cet ordre :
- La compatibilité Google. Google maintient un programme de CMP compatibles avec Consent Mode. Toutes les CMP de la liste ne se valent pas forcément en profondeur d’intégration technique ; c’est un point à contrôler au cas par cas sur la fiche de chaque partenaire, pas à supposer. Hors de cette liste, le câblage des quatre signaux vous revient, faisable, mais plus exposé aux erreurs. Je ne vous citerai pas de noms d’outils : la liste évolue, elle se consulte au moment où vous choisissez.
- La gestion de l’ordre de chargement. Les états par défaut doivent être posés avant le déclenchement des balises concernées. Une plateforme qui initialise trop tard laisse une fenêtre où les tags peuvent partir avec un état de consentement absent ou erroné.
- La granularité des catégories. Vos finalités de collecte (mesure, marketing, préférences utilisateur) doivent se mapper proprement sur les quatre signaux ; une solution qui ne connaît que « accepter/refuser tout » mappe au marteau et vous prive de toute lecture fine du comportement des visiteurs selon la catégorie consentie.
- Le support du régime choisi. Basic ou advanced, la décision se prend à la page consent mode ; l’outil doit simplement savoir exécuter les deux, pour ne pas décider à votre place.
Le faux critère : le « taux d’acceptation garanti ». Les bannières qui maximisent l’acceptation par la manipulation (bouton refuser introuvable, dark patterns) sont exactement ce que sanctionne le cadre RGPD et DMA du ciblage publicitaire, posé en amont de tout choix d’outil. Soyons clairs : optimiser l’UX de la bannière est légitime ; piéger le refus ne l’est pas, et le gain de mesure ne doit pas se faire contre le contrôle des utilisateurs sur leurs données personnelles.
Votre CMP envoie-t-elle aussi le protocole IAB TCF ?
Deux couches coexistent souvent dans ces outils : les quatre signaux Consent Mode (ad_storage, analytics_storage, ad_user_data, ad_personalization) et le protocole IAB TCF. Ce ne sont pas cinq signaux : c’est un routage de signaux d’un côté, et un protocole d’acceptation de l’écosystème publicitaire de l’autre.
Le TCF n’est pas une exigence universelle pour tous les annonceurs. Il concerne surtout les éditeurs et environnements publicitaires qui doivent respecter ce protocole en plus du Consent Mode. Si votre site est dans ce cas, contrôlez la version active du TCF et sa prise en charge par votre solution au moment du projet, en complément de la compatibilité Consent Mode.
La configuration : quatre points de contrôle, un protocole
Une CMP compatible mais mal branchée ne suffit pas : ce sont vos signaux qui conditionnent une partie du suivi des conversions Google Ads en aval. Quatre points de vigilance comptent, dont un souvent oublié : la propagation cross-domaine.
L’ordre, le mappage, le double parcours
- L’ordre : défauts posés, puis tags concernés. Toute inversion peut ouvrir une fenêtre avec un état de consentement absent ou faux.
- Le mappage : chaque catégorie de votre bandeau pointe vers les bons signaux ; le classique silencieux est la CMP restée sur des paramètres hérités, qui transmet une partie seulement des signaux attendus.
- Le double parcours : tout tester en accepté ET en refusé. C’est sur le chemin du refus que se joue la modélisation des conversions par Google, sans signal de refus propre, rien à modéliser.
Beaucoup d’implémentations cassées le sont sur un seul des deux chemins, et le refus est souvent moins testé que l’acceptation.
- Poser les défauts avant tout tag. La CMP initialise Consent Mode avec les valeurs par défaut (denied) avant le déclenchement de la moindre balise GTM.
- Mapper chaque catégorie vers les quatre signaux. Vérifier que ad_storage, analytics_storage, ad_user_data et ad_personalization ont chacun une correspondance explicite dans la configuration CMP, pas un fallback groupé.
- Observer les signaux en transit, pas le tableau de bord. Ouvrir les DevTools, onglet réseau, filtrer sur « consent » : les quatre signaux doivent apparaître sur le parcours accepté ET sur le parcours refusé.
- Rejouer la recette à chaque changement. Migration CMP, mise à jour GTM, refonte du site : les quatre points de contrôle se rejouent à chaque modification.
Pour le câblage des déclencheurs dans Google Tag Manager, et notamment l’ordre de chargement du déclencheur Consent Initialization qui synchronise votre plateforme de gestion du consentement avec le Google consent mode, la mécanique est documentée sur la page tags, déclencheurs et variables GTM.
Le consentement se propage-t-il entre vos sous-domaines et vos iframes ?
Si votre site web couvre plusieurs sous-domaines (blog.exemple.com, app.exemple.com) ou intègre des iframes tierces (widget de prise de rendez-vous, lecteur vidéo), le consentement doit se propager, sans quoi le bandeau réapparaît à chaque changement de domaine et les signaux sont perdus pour chaque sous-contexte.
Ce cas ne concerne pas tous les sites. Mais dès qu’une URL change de sous-domaine ou charge un widget tiers, il est à vérifier. Le test en trois étapes :
- Consentir sur le domaine principal. Accepter l’ensemble des cookies sur votre domaine racine, consentement enregistré.
- Naviguer vers un sous-domaine. Accéder à une page sur blog.exemple.com ou app.exemple.com en restant dans la même session navigateur.
- Vérifier l’absence de bandeau et la conservation des signaux. Il ne doit pas réapparaître. Dans les DevTools, les quatre signaux doivent transiter avec l’état accepté, pas de retour aux défauts « denied ».
Les iframes tierces peuvent exiger une configuration dédiée dans la CMP, distincte de la propagation cross-domaine. Un widget intégré qui n’a pas reçu l’instruction de consentement peut charger avec sa propre logique de cookies, même si une décision existe sur le domaine principal. Chaque widget sensible doit donc être vérifié séparément.
CMP et server-side tagging : une configuration supplémentaire à ne pas oublier
Ce point ne concerne que les implémentations avec un serveur de tagging intermédiaire (sGTM). Pour les sites full client-side GTM, il est hors sujet. C’est aussi l’un des rares cas où le choix d’outils de gestion du consentement croise la performance web : décharger la fonction de mesure côté serveur allège le navigateur, à condition que l’intégration du routage des signaux suive.
Si vous utilisez le server-side tagging, vérifiez que les signaux Consent Mode remontent bien du navigateur vers le serveur puis vers Google. Le serveur doit recevoir l’état du consentement depuis le client et le transmettre dans ses propres requêtes vers les endpoints Google. Une CMP correctement câblée en client-side peut être incomplète côté server-side : les données semblent remonter, mais les signaux de consentement sont absents des requêtes sortantes.
Symptôme : vos rapports de conversions remplissent, mais les paramètres gcs/gcd sont absents ou figés dans les requêtes server-side vers doubleclick.net. La correction est dans la configuration du conteneur serveur, pas dans l’intégration de la CMP elle-même.
La CMP gratuite laissée par défaut : les pannes de mesure peu visibles
Une CMP gratuite installée à l’origine pour un site de moindre envergure, mise en place une fois puis rarement remise à jour, c’est le terrain le plus fréquent des implémentations défaillantes que je rencontre, indépendamment de la qualité d’intégration technique de l’outil lui-même.
Certaines CMP gratuites dont l’interface ne propose pas de mappage granulaire des catégories restent en paramètres hérités sans que personne ne le détecte. Le symptôme est trompeur : le bandeau s’affiche, le tableau de bord est au vert, mais les paramètres gcs/gcd dans les requêtes réseau révèlent un état figé ou un signal manquant.
L’intégration technique n’est pas un argument automatique pour migrer vers une offre payante. Certaines CMP gratuites sont certifiées et correctement paramétrées, avec une gestion des préférences et des informations de consentement aussi granulaire que sur une offre premium. Le critère reste le test du double parcours, pas le prix de l’outil ni le prix affiché sur la page tarifs. Avant toute migration, faites le test ; la moitié des migrations que je vois répondent à un problème de configuration, pas d’outil.
Lire les paramètres gcs et gcd pour confirmer l’état réel
Observer les signaux en transit dans les DevTools reste le moyen le plus fiable de valider l’implémentation et le comportement réel de la CMP. Voici comment aller plus loin en lisant les paramètres gcs et gcd qui apparaissent dans les requêtes sortantes vers les endpoints Google.
Filtrez l’onglet Réseau sur « collect » ou « event » pour isoler les requêtes vers google-analytics.com ou doubleclick.net. Dans les paramètres de la requête, repérez gcs et gcd. Ces deux paramètres encodent l’état de consentement des utilisateurs réellement transmis à Google, pas l’état tel que votre CMP le croit, l’état tel qu’il arrive à destination.
| Paramètre | Parcours accepté | Parcours refusé | Ce que révèle son absence |
|---|---|---|---|
| gcs | Valeur cohérente avec un accord | Valeur cohérente avec un refus | Le signal ne remonte pas à Google, câblage défaillant |
| gcd | Présent, valeur variable | Présent, valeur variable | Consent Details absent, mappage incomplet |
Sur beaucoup d’implémentations, une valeur gcs cohérente apparaît sur le parcours accepté et une autre sur le parcours refusé. Si la valeur reste figée, ou si gcs est absent alors qu’il doit être transmis, la CMP route peut-être ses signaux côté navigateur sans qu’ils atteignent les endpoints Google. C’est la distinction que le tableau de bord CMP montre rarement.
Quand un fallback de consentement disparaît
Le risque d’une CMP mal branchée est parfois masqué par des réglages secondaires dans GA4, GTM ou d’autres outils de mesure. Quand un fallback disparaît ou change de comportement, le défaut devient visible d’un coup : baisse des conversions observées, modélisation instable, signaux incohérents entre accepté et refusé.
Conséquence concrète : si votre mesure baisse sans explication côté campagnes, la CMP fait partie des premiers points à contrôler. Le problème n’est pas forcément l’outil choisi ; c’est souvent le routage réel des signaux.
Rien à reconfigurer si le câblage est déjà correct. Ce type de changement ne crée pas toujours une nouvelle exigence technique ; il révèle surtout les implémentations qui tenaient grâce à un filet de sécurité involontaire. Le cadre des deux régimes Consent Mode v2 reste la bonne grille de lecture.
Les critères de cette page sont structurels ; les écrans et libellés de votre CMP, eux, auront peut-être changé la semaine prochaine.
- Une CMP est un routeur de signaux : son critère critique est la transmission réelle des quatre signaux Consent Mode v2 (ad_storage, analytics_storage, ad_user_data, ad_personalization).
- Choisir une CMP compatible Google réduit le risque de câblage raté ; la configuration reste à valider par observation directe des signaux.
- Les points de contrôle de configuration : l’ordre de chargement, le mappage des catégories, l’absence de test sur le parcours refus, la propagation cross-domaine et les iframes.
- Une CMP compatible mal branchée reste insuffisante. La recette de validation se rejoue à chaque changement de CMP, de GTM ou de site.
Que faire selon votre situation
Si vous choisissez : liste de partenaires compatibles, quatre critères, dans cet ordre.
Si vous avez déjà une CMP : ne changez rien avant d’avoir fait le test du double parcours. La moitié des migrations de CMP que je vois répondent à un problème qui était de configuration, pas d’outil, et vos campagnes n’ont rien à gagner à changer d’outil pendant que le défaut reste dans le câblage.
Le bandeau est la partie visible. Le routeur est la partie qui compte, un maillon de la mesure et du tracking Google Ads, pas un sujet à part. Le vôtre route-t-il ?
