Blog Mesure, data & conformité
Le mode Consentement de Google, sans le jargon
Le mode Consentement n'est ni un bandeau ni une base légale : c'est le protocole par lequel votre CMP dit aux balises Google ce qu'elles ont le droit de faire.
Par Florent Bronchain 1 604 mots · environ 8 min
Sommaire
Le nom induit en erreur. Le mode Consentement ne recueille aucun consentement : il le transmet. C’est un protocole entre l’outil qui a posé la question à l’utilisateur et les balises Google qui doivent en tenir compte.
Cette distinction n’est pas un détail de vocabulaire. Elle explique pourquoi l’activer sans plateforme de consentement ne sert à rien, et pourquoi une CMP installée sans lui laisse les balises Google dans l’ignorance du choix de l’utilisateur.
Les signaux
Le protocole repose sur des signaux nommés, chacun valant accordé ou refusé. La documentation de Google en recense sept.
| Signal | Ce qu’il autorise |
|---|---|
ad_storage | Le stockage lié à la publicité, cookies compris |
ad_user_data | L’envoi de données utilisateur à Google à des fins publicitaires |
ad_personalization | La personnalisation des annonces, dont le remarketing |
analytics_storage | Le stockage lié à la mesure d’audience |
functionality_storage | Le stockage nécessaire au fonctionnement du site |
personalization_storage | Le stockage lié à la personnalisation du contenu |
security_storage | Le stockage lié à la sécurité et à la lutte contre la fraude |
Les deux premiers de la liste publicitaire, ad_user_data et
ad_personalization, ont été ajoutés en novembre 2023 ;
ad_storage et analytics_storage existaient
auparavant. C’est cet ajout que l’on désigne couramment par
« consent mode v2 ».
La distinction entre les trois signaux publicitaires est réelle et souvent aplatie par les configurations par défaut : un utilisateur peut accepter la mesure sans accepter la personnalisation. Une CMP qui mappe ses finalités grossièrement fait perdre cette nuance — et avec elle, une partie du signal publicitaire pourtant consenti.
default et update : l’ordre décide de tout
Le protocole se joue en deux temps.
Le default est l’état posé avant toute interaction, dès le chargement de la page. Pour un visiteur européen, il vaut normalement refusé sur tout ce qui n’est pas essentiel.
L’update est la mise à jour envoyée dès que l’utilisateur a fait son choix. Elle remplace l’état par défaut pour la suite de la session.
Tout l’enjeu tient dans le fait que le default doit arriver avant la première balise. S’il arrive après, la balise a déjà décidé avec l’état par défaut du navigateur, et le traceur est déjà déposé. Dans Tag Manager, c’est le rôle du déclencheur d’initialisation dédié.
L’erreur qui annule tout le dispositif
Un default posé après le chargement des balises produit un site qui paraît conforme — le bandeau est là, les signaux circulent — tout en déposant des traceurs avant le choix. C’est la configuration fautive la plus répandue, et elle ne se voit que dans l’inspecteur réseau.
Version de base ou version avancée
C’est la seule vraie décision d’architecture du sujet, et elle mérite d’être prise en connaissance de cause.
Dans la version de base, les balises Google ne se chargent pas tant que l’utilisateur n’a pas interagi avec le bandeau. Aucune donnée ne part avant ce moment — pas même l’état de consentement. Si l’utilisateur refuse, Google ne reçoit rien du tout.
Dans la version avancée, les balises se chargent dès l’ouverture de la page, avec l’état par défaut. Tant que le consentement est refusé, elles envoient des signaux sans cookies : pas d’identifiant, pas de stockage sur le terminal, mais une information minimale que Google utilise pour la modélisation.
| Version de base | Version avancée | |
|---|---|---|
| Avant l’interaction | Rien n’est envoyé | Signaux sans cookies |
| Après refus | Rien n’est envoyé | Signaux sans cookies, pas de stockage |
| Modélisation | Modèle général | Modèle propre à l’annonceur |
| Complexité | Faible | Plus élevée |
La version avancée récupère davantage de signal, au prix d’un envoi qui a lieu même en cas de refus. Ce choix ne se tranche pas sur le seul critère de la performance : il engage une appréciation qui relève de votre responsable de la conformité, pas de l’équipe acquisition seule.
La modélisation, et ce qu’elle n’est pas
Le refus est une contrainte durable — aucune évolution des navigateurs ne l’a levée. Quand une partie des utilisateurs refuse, Google peut estimer les conversions manquantes à partir du comportement observé chez ceux qui ont accepté. C’est la modélisation.
Trois points à retenir. Elle produit une estimation, pas une mesure : un chiffre modélisé ne se réconcilie pas ligne à ligne avec un export de commandes. Elle exige d’atteindre un seuil de collecte, que Google ne publie pas précisément — en dessous, rien n’est modélisé et les conversions manquantes restent manquantes. Et elle ne restitue rien à l’identique : elle comble un volume, pas des individus, ce qui la rend inutilisable pour du remarketing.
Un site à faible trafic peut donc implémenter la version avancée sans jamais bénéficier de la modélisation. C’est un scénario fréquent, et rarement annoncé.
Où ça se configure
Trois cas, du plus courant au plus rare.
Par la CMP. Les plateformes certifiées émettent les signaux automatiquement dès lors que le mapping entre leurs finalités et les signaux Google est correctement paramétré. C’est le chemin normal, et la vérification porte sur ce mapping.
Par Tag Manager. Les réglages de consentement de chaque balise permettent de déclarer les signaux exigés. L’outil retient alors l’exécution jusqu’à obtention.
Par le code. Un appel direct à la fonction de configuration de la balise Google, pour les cas où l’on gère son propre bandeau. Le plus souple et le plus facile à casser.
Ce que voient GA4 et Google Ads quand le consentement manque
Les deux plateformes ne réagissent pas de la même façon, et confondre leurs comportements mène à des diagnostics faux.
Dans Google Analytics
4, l’absence de analytics_storage empêche l’écriture de
l’identifiant qui permet de reconnaître un visiteur d’une page à l’autre.
Les sessions se fragmentent, le nombre d’utilisateurs monte
artificiellement, et les rapports de parcours perdent leur sens. En
version avancée et au-delà d’un certain volume, une modélisation
comportementale comble une partie du trou — les rapports concernés le
signalent explicitement.
Dans Google Ads, c’est la conversion qui manque : le clic est enregistré, l’achat ne lui est jamais rattaché. L’effet ne se limite pas au rapport, puisque les stratégies d’enchères automatiques apprennent sur ces conversions. Une configuration de consentement défaillante ne fausse donc pas seulement la mesure : elle dégrade progressivement la diffusion.
C’est la raison pour laquelle ce chantier ne se traite pas comme un sujet de conformité isolé. Il a un coût d’acquisition direct, et c’est généralement l’argument qui débloque le temps de développement nécessaire.
La mise en œuvre, dans l’ordre
Six étapes, dont l’ordre n’est pas négociable.
- Inventorier ce qui dépose des traceurs, et rattacher chaque script à une finalité.
- Choisir entre version de base et version avancée, avec la personne responsable de la conformité.
- Poser le default avant tout le reste, sur le déclencheur d’initialisation.
- Mapper les finalités de la CMP vers les sept signaux, sans les écraser.
- Conditionner les balises Google aux signaux qu’elles exigent, et bloquer les scripts non Google par la CMP.
- Recetter les trois scénarios : avant choix, après refus, après acceptation.
Sauter la première étape est l’erreur d’organisation la plus courante : on configure un protocole avant de savoir ce qu’il doit gouverner.
Ce que ça ne fait pas
- Ça ne remplace pas une CMP. Le protocole transporte un choix ; il ne le recueille pas, ne l’affiche pas, ne le conserve pas.
- Ça ne fabrique pas de consentement. Un default à « accordé » sur du trafic européen n’est pas une configuration : c’est une déclaration inexacte.
- Ça ne restaure pas les conversions perdues. La modélisation estime un volume, sous conditions.
- Ça ne dispense pas du blocage. Les scripts non Google — pixel Meta, outils tiers — ne comprennent pas ces signaux et doivent être bloqués par la CMP.
Vérifier que ça marche
Trois vérifications suffisent, et elles se font sur le site réel.
Dans le mode aperçu de Tag Manager, l’état de consentement est affiché à chaque étape. On y voit le default, puis l’update, avec l’horodatage : c’est là qu’un default trop tardif se repère.
Dans l’inspecteur réseau, les requêtes envoyées aux
serveurs Google portent des paramètres qui encodent l’état de
consentement transmis — notamment gcs et gcd.
Leur présence prouve que le signal circule ; leur absence prouve le
contraire, quoi qu’affiche l’interface de la CMP.
Dans les rapports, enfin, en comparant un refus et une acceptation. Mais c’est la vérification la plus lente et la moins précise : elle confirme, elle ne diagnostique pas.
Server-side et mode Consentement
Déplacer la collecte vers un conteneur serveur ne modifie pas le protocole. L’état de consentement continue d’être décidé dans le navigateur, transmis avec les événements, et doit être respecté par le serveur au moment de relayer vers les plateformes.
L’idée qu’un serveur intermédiaire permettrait de s’affranchir des signaux est doublement fausse : les plateformes de destination attendent ces signaux, et l’obligation de consentement porte sur le terminal de l’utilisateur, pas sur le lieu d’exécution du script.
Les erreurs fréquentes
Un mapping approximatif. Trois finalités de la CMP écrasées sur un seul signal Google, et l’on perd le consentement publicitaire de visiteurs qui l’avaient pourtant donné.
Un default trop tardif. Décrit plus haut ; c’est la faute la plus répandue et la plus coûteuse.
Une version avancée choisie par défaut. Souvent activée parce qu’elle « récupère plus de données », sans que la question ait été posée à qui de droit.
Aucune recette du refus. On teste l’acceptation, jamais le refus. C’est pourtant le seul scénario où une erreur de configuration a des conséquences.
Comment choisir
Trois questions, dans cet ordre. Votre trafic atteint-il un volume tel que la modélisation ait une chance de s’activer ? Votre responsable de la conformité a-t-il validé l’envoi de signaux avant l’interaction ? Et votre plan de marquage indique-t-il, pour chaque événement, le signal qu’il exige ?
Si l’une des trois réponses manque, la version de base est le point de départ raisonnable : moins de signal, mais un dispositif que l’on peut expliquer entièrement — ce qui, sur ce sujet, vaut mieux qu’un dispositif que l’on subit.