Architecture des paramètres du Consent Mode v2

Le Consent Mode est le framework de Google permettant d’ajuster le comportement des balises en fonction des choix de consentement des utilisateurs. La version 2, publiée en novembre 2023 et imposée pour le trafic EEE/Royaume-Uni à partir de mars 2024, a étendu le système original à deux paramètres à quatre paramètres. La distinction entre les paramètres d’origine et les nouveaux est d’ordre architectural, pas simplement incrémentale, et la comprendre est essentielle tant pour l’implémentation que pour le débogage.

Les deux paramètres d’origine (v1)

Le Consent Mode v1, lancé en 2020, a introduit deux paramètres :

ad_storage contrôle si les cookies publicitaires (comme les cookies _gcl_* de Google Ads) peuvent être déposés dans le navigateur de l’utilisateur.
analytics_storage contrôle si les cookies analytiques (comme _ga et _gid de GA4) peuvent être déposés.

Ces paramètres sont des qualificatifs en amont. Ils déterminent quelles données quittent le navigateur. Lorsque analytics_storage est refusé, les balises GA4 ne poseront pas de cookies et enverront soit des pings sans cookie (en mode Advanced), soit ne se déclencheront pas du tout (en mode Basic). Lorsque ad_storage est refusé, les balises de conversion Google Ads ne poseront pas d’identifiants de clic.

Le modèle mental clé : les paramètres v1 bloquent le mécanisme de collecte côté navigateur. Ils contrôlent si des identifiants existent en premier lieu.

Les deux nouveaux paramètres (v2)

La version 2 a ajouté :

ad_user_data indique aux services Google si les données personnelles peuvent être utilisées à des fins publicitaires. Lorsqu’il est refusé, les valeurs user_id, les données hachées Enhanced Conversions (e-mail, téléphone, adresse) et autres signaux d’identification personnelle sont supprimés côté serveur.
ad_personalization indique aux services Google si le remarketing est autorisé. Lorsqu’il est refusé, les audiences de remarketing cessent de se constituer — aucun nouvel utilisateur n’entre dans les listes d’audience, et l’appartenance aux audiences existantes n’est pas actualisée.

Ces paramètres sont des instructions en aval. Ils ne modifient pas les données envoyées par le navigateur. Ils indiquent aux serveurs de Google comment traiter les données après leur réception. Il s’agit d’une surface de contrôle fondamentalement différente.

Amont vs aval : pourquoi cela importe

La séparation crée des combinaisons qui n’auraient pas de sens dans un système à deux paramètres :

`ad_storage`	`ad_user_data`	Ce qui se passe
granted	granted	Mesure publicitaire complète : cookies déposés, données personnelles utilisées pour le ciblage
granted	denied	Les cookies sont déposés, les pings se déclenchent normalement, mais Google supprime les données personnelles côté serveur. Le comptage des conversions fonctionne, mais les données Enhanced Conversions sont silencieusement ignorées
denied	granted	Aucun cookie publicitaire déposé, mais le signal de consentement indique que les données personnelles pourraient être utilisées. En pratique, les données personnelles disponibles sont limitées sans identifiants cookie
denied	denied	Pas de cookies, pas d’utilisation de données personnelles. Mesure publicitaire minimale

La deuxième ligne est le scénario qui piège la plupart des implémentations. Tout semble fonctionner — les balises de conversion se déclenchent, les données arrivent dans Google Ads — mais Enhanced Conversions échoue silencieusement parce que ad_user_data bloque le traitement des données personnelles hachées. On ne le découvre que plusieurs semaines plus tard lorsque les diagnostics Enhanced Conversions n’affichent aucune donnée correspondante.

De même, si ad_personalization est refusé alors que d’autres signaux sont accordés, vos audiences de remarketing cessent silencieusement de croître. La mesure des conversions continue normalement, mais vos campagnes de retargeting perdent progressivement en portée à mesure que les listes d’audience expirent sans nouvelles entrées.

Le déclencheur légal

Le passage de deux à quatre paramètres n’était pas une décision produit. Il a été dicté par le Digital Markets Act (DMA) de l’UE, qui désigne Google comme plateforme « contrôleur d’accès » avec une responsabilité réglementaire directe d’obtenir le consentement des utilisateurs avant de traiter des données personnelles à des fins publicitaires.

Le DMA exige que les contrôleurs d’accès démontrent que le consentement a été correctement obtenu et que le traitement des données respecte les finalités spécifiques pour lesquelles l’utilisateur a consenti. Deux paramètres binaires — cookies oui/non, analytique oui/non — ne pouvaient pas exprimer la granularité exigée par la réglementation. Les nouveaux paramètres correspondent à des finalités de traitement de données spécifiques :

ad_user_data correspond à la finalité du traitement des données personnelles à des fins publicitaires
ad_personalization correspond à la finalité de constitution de profils d’audience personnalisés

Cette obligation légale s’applique à l’implémentation des balises de chaque annonceur. Google ne recommande pas simplement le Consent Mode v2 — il l’exige. Les comptes sans implémentation conforme pour le trafic EEE/Royaume-Uni font l’objet d’une application automatisée : le suivi des conversions, le remarketing et les rapports démographiques sont désactivés.

Le flux de mise à jour du consentement

En pratique, les quatre paramètres sont définis ensemble. Une commande par défaut se déclenche avant le chargement de toute balise, réglant les quatre à denied pour les régions où le consentement est requis :

gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied'
});

Lorsque l’utilisateur accorde son consentement via la CMP, une commande de mise à jour règle les paramètres en fonction des finalités spécifiques acceptées :

gtag('consent', 'update', {
  'ad_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted',
  'analytics_storage': 'granted'
});

Une CMP granulaire peut accorder analytics_storage et ad_storage tout en refusant ad_personalization — autorisant la mesure tout en bloquant le remarketing. Les quatre paramètres donnent à la CMP suffisamment d’expressivité pour correspondre aux finalités TCF v2.2 et satisfaire l’exigence du DMA d’un consentement par finalité.

Ce que les paramètres ne contrôlent pas

Les paramètres du Consent Mode n’empêchent pas les données d’atteindre les serveurs de Google en mode Advanced. Les pings sans cookie se déclenchent toujours lorsque analytics_storage est refusé. Les paramètres contrôlent ce que Google fait avec les données, pas si elles sont transmises. Pour ce niveau de contrôle, il faut utiliser le mode Basic, qui bloque entièrement l’exécution des balises lorsque le consentement est refusé.

Les paramètres ne s’étendent pas non plus aux fournisseurs tiers. Meta, TikTok, LinkedIn et les autres balises tierces n’ont aucune connaissance des signaux du Consent Mode. Les implémentations côté serveur doivent gérer séparément l’application du consentement pour ces fournisseurs.