C’est quoi le Consent Mode V2 ?

Depuis mars 2024, le paysage du marketing digital européen a franchi un point de non-retour. L’implémentation du Consent Mode V2 (Mode de consentement) de Google est une condition sine qua non pour maintenir l’efficacité de vos investissements en SEA (Search Engine Advertising).

Chez BM Pix’Art, nous accompagnons les annonceurs dans cette transition critique.

Depuis l’entrée en vigueur du Digital Markets Act (DMA), la gestion du consentement est passée d’une simple bannière de cookies à une infrastructure de transmission de données complexe. Pour les annonceurs, l’enjeu est double : respecter la vie privée sans sacrifier la puissance des algorithmes de Google.

Chez BM Pix’Art, nous ne nous contentons pas de « poser une bannière ». Nous architecturons votre tracking pour qu’il survive à la réglementation en vigueur.

1. L’architecture réglementaire : DMA vs RGPD

Le RGPD et le DMA sont les deux lames d’un même ciseau mais elles ne sont pas destinées à couper les mêmes éléments.

RGPD ►protection de l’individu

Le Règlement Général sur la Protection des Données régit la relation entre votre site et l’internaute.

Son focus est la vie privée. Vous collectez une donnée, vous devez justifier d’une base légale (le consentement) et offrir la transparence (droit à l’effacement).

Si vous ne respectez pas le RGPD, vous êtes responsable devant la CNIL.

DMA ► régulation des « gatekeepers »

Le Digital Markets Act régit la relation entre l’Union Européenne et les géants du web (Google, Meta, Amazon).

L’objectif est d’empêcher ces « contrôleurs d’accès » d’abuser de leur position dominante.

L’UE impose désormais à Google une obligation de preuve : il ne peut plus simplement « supposer » que la donnée reçue est consentie. Il doit pouvoir démontrer techniquement que chaque signal publicitaire est adossé à un choix explicite de l’utilisateur.

2. Le Consent Mode V2, le protocole de preuve

Le Consent Mode V2 n’est pas un outil de conformité RGPD en soi (votre CMP s’en charge), c’est un protocole de transmission de preuve pour le DMA. Il agit comme un tampon sur chaque paquet de données envoyé à Google.

Les deux nouveaux signaux critiques

Contrairement à la V1 qui se contentait de dire si on pouvait stocker un cookie (ad_storage), la V2 transmet deux autorisations distinctes réclamées par le DMA :

• ad_user_data (le signal d’exportation) : ce paramètre indique à Google s’il a le droit de recevoir les données de l’utilisateur dans ses services publicitaires. Sans ce signal réglé sur granted, aucune donnée de conversion ne sera traitée par les serveurs Google Ads en Europe.

• ad_personalization (le signal d’exploitation) : il définit si Google peut croiser ces données pour le profilage. C’est le signal essentiel pour le Remarketing et la création d’audiences similaires. Sans lui, vos listes d’audiences resteront vides, rendant vos campagnes de retargeting inopérantes.

Le mécanisme du messager

Dans une configuration en consentement strict (Mode Basic), le messager est muet tant que l’utilisateur n’a pas validé la bannière. Une fois le clic effectué, le Consent Mode V2 « étiquette » les balises Google (Ads, GA4, Floodlight) avec l’état de ces deux signaux.

Si l’utilisateur refuse, le message n’est jamais envoyé. Si l’utilisateur accepte, le message part avec les flags ad_user_data=granted et ad_personalization=granted, débloquant instantanément l’usage des algorithmes de smart bidding.

Pour comprendre comment Google vérifie la validité de votre tracking, il faut plonger dans le paramètre GCD (Google Consent Default). C’est le « mouchard » technique glissé dans l’URL de chaque requête réseau (pings).

Contrairement au paramètre GCS qui indique l’état actuel du consentement (Accepté ou Refusé), le GCD raconte toute l’histoire : comment on est arrivé à cet état et si votre configuration respecte la chronologie imposée par le DMA.

Le décodage du signal GCD

Le paramètre GCD se présente sous la forme d’une chaîne de caractères cryptique, par exemple : 11p1p1p1p5.

Chaque lettre et chiffre a une signification précise sur l’origine du signal. L’ordre des lettres n’est pas aléatoire. Dans une chaîne type 11p1p1p1p5, chaque position après le premier « 1 » correspond à une clé spécifique :

Position A : ad_storage

Position B : analytics_storage

Position C : ad_user_data

Position D : ad_personalization

La structure type : 

Chaque segment correspond à une finalité (ad_storage, analytics_storage, etc.) et utilise un code pour décrire son statut.

Code	Signification technique	Interprétation Google
p	Denied par défaut	État initial « Privacy-First » respecté.
q	Denied par une mise à jour	L’utilisateur a explicitement refusé après coup.
t	Granted par défaut	Danger : consentement forcé avant l’interaction (non conforme).
r	Granted par une mise à jour	Idéal : l’utilisateur a cliqué sur « Accepter ».
l	Denied (Valeur manquante)	Problème de configuration dans GTM.

Statique vs Dynamique

Google utilise le GCD pour différencier une implémentation « propre » d’une manipulation des signaux.

1. Le consentement statique (default)

C’est l’état défini dans votre code avant même que la bannière ne s’affiche.

• En mode strict, vous devez envoyer un signal default à denied.

• Si Google reçoit une conversion avec un signal montrant qu’il n’y a jamais eu de default mais directement un update à granted, il peut invalider la donnée car elle ne prouve pas que l’utilisateur a eu le choix.

2. Le consentement dynamique (update)

C’est l’ordre envoyé par votre CMP (Cookiebot, Axeptio, Didomi) dès que l’internaute interagit.

Le signal GCD passe alors de la lettre p (denied par défaut) à la lettre r (granted par mise à jour). Cette transition p -> r est la preuve technique que vous êtes en conformité avec le DMA.

Pourquoi le signal GCD est-il votre « score de santé » ?

Si vous trichez en forçant le consentement par défaut (t), ou si vous ne gérez pas correctement la mise à jour des signaux, Google peut appliquer des sanctions algorithmiques :

• Filtrage des données : vos conversions ne remontent plus dans Google Ads car le signal de preuve est jugé « non fiable ».

• Modélisation dégradée : l’IA de Google ne peut pas combler les trous de données si elle détecte une incohérence dans la chronologie du GCD.

• Suspension de compte : à terme, pour les très gros comptes (gatekeepers), le non-respect de cette preuve de consentement dynamique peut mener à des audits de conformité forcés.

L’analyse de l’expert :

Un signal GCD qui finit par 5 ou 1 indique souvent une version spécifique de l’API.

Ce qu’il faut retenir, c’est que Google « voit » si vous avez injecté le consentement de force ou si vous avez réellement attendu le clic. En mode strict, si votre GCD ne contient pas de « p » (denied) au chargement, vous n’êtes pas conforme, même si aucun cookie n’est déposé.

3. Basic vs Advanced, l’rbitrage stratégique

Fonctionnalité	Mode Basic (Strict)	Mode Advanced
Chargement des balises	Bloqué tant qu’il n’y a pas d’accord.	Chargement immédiat (pings sans cookies).
Conformité	Alignement total CNIL / RGPD.	Zone grise (collecte d’IP/User-Agent).
Modélisation	Basée sur les utilisateurs consentis uniquement.	IA de Google comble les « trous » (up-lift de +15%).
Risque	Perte de volume de données (jusqu’à 40%).	Risque juridique sur l’anonymisation réelle.

L’avis de l’expert :

Si vous optez pour le mode Basic, votre priorité absolue est d’optimiser le taux d’acceptation de votre bannière (UX/UI) pour minimiser la perte de signal.

4. Sécurité : hachage SHA-256

Pour compenser la perte de cookies en mode strict, on utilise les enhanced conversions. Mais attention : envoyer un email en clair est une faute grave !!!

La science du hachage

Nous utilisons l’algorithme SHA-256 pour transformer une donnée identifiable (PII) en une empreinte numérique unique et irréversible.

Mathématiquement, si x est l’adresse email, nous transmettons H(x) :

H(« user@email.com ») = e3b0c442…

Google compare cette empreinte avec sa propre base de données. Si l’utilisateur est connecté à son compte Google, la conversion est attribuée même sans cookie.

5. Le tracking server-side

Pour une protection des données sans faille, le server-side (GTM-SS) est la solution ultime. Au lieu que le navigateur de l’utilisateur envoie des données directement à Google, il les envoie à votre serveur.

Les avantages du GTM-SS avec hachage :

• Anonymisation de l’IP ► Votre serveur supprime l’adresse IP avant de transférer les données à Google.

• Contrôle Granulaire ► Vous décidez exactement quel paramètre est transmis.

• Durée de vie des cookies ► En passant par un sous-domaine de premier niveau (track.votre-site.com), vous contournez les restrictions ITP d’Apple/Safari.

• Hachage côté serveur ► Le hachage des données sensibles se fait dans un environnement sécurisé, pas dans le navigateur du client où il pourrait être intercepté.

6. Comprendre le seuils de données dans GA4

C’est le point de friction majeur après l’installation du Consent Mode V2. Beaucoup d’annonceurs s’inquiètent de voir des données disparaître de leurs rapports GA4.

Pourquoi vos rapports semblent incomplets ?
Pour éviter qu’un administrateur de site ne puisse identifier un utilisateur individuel par recoupement (en isolant ceux qui ont refusé les cookies), Google applique des seuils de données (thresholding).

Si le volume de trafic est trop faible sur une période donnée, GA4 masque certaines lignes de données.

Solution :
Dans l’administration de GA4, passez l’identité de reporting en mode « Basé sur l’appareil » pour vérifier si les données brutes sont là, tout en sachant que le mode « Observé » est le seul qui utilise la modélisation comportementale liée au Consent Mode.

Configuration technique : le script « privacy-first »

Ce bloc de code doit impérativement être placé avant votre conteneur Google Tag Manager.

// Initialisation du dataLayer
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
// État de consentement par défaut (Strict)
gtag("consent", "default", {
ad_storage: "denied",
ad_user_data: "denied",
ad_personalization: "denied",
analytics_storage: "denied",
functionality_storage: "denied",
personalization_storage: "denied",
security_storage: "granted", // Essentiel pour la sécurité
wait_for_update: 2000,
});
// Activation des mesures de protection supplémentaires
gtag("set", "ads_data_redaction", true);
gtag("set", "url_passthrough", true);

Note sur ads_data_redaction : lorsqu’il est à true, les informations publicitaires sont supprimées des pings si le consentement ad_storage est refusé. C’est un gage de sécurité supplémentaire pour le mode Advanced.

Ma méthodologie pour tester le consentement strict via Chrome

Pour garantir à mes clients une étanchéité totale de leur collecte de données, je ne me fie jamais uniquement aux voyants verts des outils automatisés.

Voici le protocole de test rigoureux que j’applique via la Console Chrome pour vérifier qu’aucun cookie non essentiel n’est déposé avant le consentement explicite.

Étape 1 : préparation de l’environnement de test

Avant toute analyse, il est impératif de partir d’une « page blanche » pour éviter les faux positifs liés à d’anciennes sessions.

• Ouvrez votre site en navigation privée (Ctrl+Maj+N).

• Faites un clic droit > Inspecter pour ouvrir les outils de développement.

• Allez dans l’onglet Application (en haut de la console).

• Dans la barre latérale gauche, déroulez le menu Cookies et sélectionnez l’URL de votre site.

• Cliquez sur l’icône « sens interdit » (Clear All) pour supprimer tous les cookies présents.

Étape 2 : le test « zéro consentement »

Une fois le stockage vidé, rafraîchissez la page (F5) et restez sur la bannière de consentement sans cliquer sur aucun bouton.

• Observation attendue : la liste des cookies doit rester vide ou ne contenir que des cookies strictement nécessaires (identifiant de session, jeton de sécurité CSRF ou le cookie de la CMP elle-même qui mémorise l’état « non répondu »).

• Alerte expertise : si vous voyez apparaître des cookies nommés _ga (Google Analytics), _fbp (Meta Pixel) ou IDE (Doubleclick), votre configuration est défaillante. Le script se déclenche avant le choix de l’utilisateur, ce qui constitue une infraction directe au RGPD.

Étape 3 : vérification du « consentement strict »

Cliquez sur « Tout refuser » ou « Continuer sans accepter ».

La liste des cookies ne doit pas s’allonger.

Si vous avez implémenté le Consent Mode V2 en mode Advanced, vous verrez des requêtes réseau partir vers Google (onglet Network), mais elles ne doivent être associées à aucun cookie persistant dans l’onglet Application.

Étape 4 : validation de l’acceptation

Enfin, videz à nouveau vos cookies et cliquez cette fois sur « Tout accepter ».

Observation attendue : vous devriez voir apparaître instantanément la « forêt » de cookies marketing et analytics. C’est à ce moment précis, et pas avant, que la valeur gcs dans vos requêtes réseau doit passer de G100 (refus) à G111 (accord total pour Google Ads et Analytics).

Le conseil d’expert :

Cette manipulation manuelle est la seule preuve irréfutable de la bonne santé de votre setup. Un mauvais réglage de priorité dans Google Tag Manager peut faire charger vos scripts un quart de seconde avant la CMP, suffisant pour que le cookie soit déposé illégalement.