Mode de consentement et CMP

En vertu du GDPR et de l'ePrivacy, vous devez généralement obtenir un consentement explicite avant de définir des cookies non essentiels ou de partager des données à des fins publicitaires. Mais bloquer toutes les balises lorsque le consentement est refusé signifie perdre entièrement la mesure.

Le mode de consentement de Google fait le lien : les balises lisent les choix de consentement de l'utilisateur et adaptent leur comportement, en envoyant soit les données complètes, soit des signaux respectueux de la vie privée, soit aucune donnée.

La version 2 du mode de consentement définit quatre états essentiels. Deux existaient déjà : analytics_storage et ad_storage. Deux ont été ajoutés dans la version 2 : ad_user_data et ad_personalization.

Chacun peut être « granted » ou « denied ». ad_user_data détermine si les données utilisateur peuvent être envoyées à Google pour les annonces ; ad_personalization détermine si elles peuvent être utilisées pour la publicité personnalisée et le remarketing.

Le flux comporte deux étapes. D'abord, une commande par défaut s'exécute avant le déclenchement de toute balise, et définit généralement tout sur « refusé » pour les utilisateurs de l'UE. Ensuite, après que l'utilisateur a cliqué sur la bannière, une commande de mise à jour reflète son choix réel.

Il est essentiel de définir la valeur par défaut avant le chargement des balises ; sinon, celles-ci peuvent se déclencher avec un suivi complet avant le recueil du consentement, ce qui constitue une violation.

Le Mode Consentement basique bloque complètement les balises Google jusqu'à l'obtention du consentement ; aucun signal n'est envoyé auparavant. Le Mode Consentement avancé charge immédiatement les balises mais, lorsque le consentement est refusé, envoie des signaux sans cookies : des signaux anonymes dépourvus d'identifiants.

Le mode avancé alimente la modélisation des conversions de Google, qui estime les conversions que vous ne pouvez pas observer directement. Il permet généralement de récupérer davantage de données, mais soulève davantage de questions de conformité.

En mode avancé, lorsque le consentement est refusé, Google reçoit tout de même un signal minimal sans cookies : un horodatage, l'URL de la page, l'état du consentement lui-même et un identifiant aléatoire qui n'est pas stocké.

Ces signaux ne contiennent aucune donnée personnelle et ne définissent aucun cookie, ce qui permet de les justifier. Ils fournissent aux modèles de Google suffisamment de signaux agrégés pour estimer les conversions non observées.

Une plateforme de gestion du consentement (CMP) est l'outil qui affiche la bannière, enregistre les choix de l'utilisateur, conserve la preuve de son consentement et transmet ce choix à vos balises.

Parmi les exemples figurent Cookiebot, OneTrust, Usercentrics et Didomi. La CMP est la référence faisant foi pour le consentement ; le Mode Consentement indique comment les balises de Google y réagissent.

Pour le Mode Consentement v2, Google exige une CMP certifiée pour des produits comme le remarketing Google Ads et le trafic de l'EEE. Une CMP certifiée intègre correctement les signaux de la version 2 et figure sur la liste approuvée par Google.

La CMP doit transmettre les quatre paramètres de consentement et s'intégrer au cadre de transparence et de consentement de l'IAB (TCF) lorsque cela s'applique. L'utilisation d'une bannière non certifiée ou créée maison risque d'entraîner la désactivation de certaines fonctionnalités.

Le cadre de transparence et de consentement de l'IAB est une norme du secteur qui encode le consentement dans une « chaîne TC », un jeton compact indiquant les finalités et les fournisseurs autorisés par l'utilisateur.

Les partenaires de la technologie publicitaire lisent la chaîne TC pour savoir s'ils peuvent traiter les données. De nombreuses CMP la génèrent automatiquement ; c'est un dispositif complexe, si bien que les sites plus petits utilisent souvent une configuration plus légère certifiée par Google, sans TCF complet.

Le schéma d'intégration est le suivant : la CMP se charge en premier et définit la valeur par défaut du Mode Consentement sur « refusé ». Lorsque l'utilisateur fait son choix, la CMP déclenche la mise à jour du consentement et génère un événement dataLayer.

Vos balises GTM réagissent alors automatiquement au Mode Consentement grâce aux vérifications de consentement intégrées, ou utilisent des déclencheurs conditionnés par l'événement de consentement. L'ordre est important : la CMP avant GTM, la valeur par défaut avant la mise à jour.

Le consentement accompagne l'événement jusqu'à votre serveur de balises. Chaque balise côté serveur peut vérifier l'état du consentement dans la charge utile avant de transmettre l'événement à une destination.

Ainsi, même après le navigateur, un signal ad_user_data refusé doit empêcher la balise Meta CAPI ou Google Ads d'effectuer un envoi. L'application du consentement doit exister à la fois côté client et côté serveur.

Lorsqu'ils sont correctement mis en œuvre, le Mode Consentement et une CMP certifiée vous permettent de respecter les choix des utilisateurs tout en continuant à mesurer les résultats grâce à la modélisation, sans définir de cookies non autorisés. Mal mis en œuvre, ils deviennent un simple paravent pour un suivi illégal.

Effectuez régulièrement un audit : vérifiez que les valeurs par défaut sont « refusé », que les bannières proposent véritablement une option de refus, que la preuve du consentement est enregistrée et qu'aucune balise permettant l'identification ne se déclenche avant le consentement.

Évaluez votre compréhension du Mode Consentement et des CMP.

Le Mode Consentement v2 utilise quatre signaux (analytics_storage, ad_storage, ad_user_data, ad_personalization), réglés sur « accordé » ou « refusé », selon un flux qui commence par un refus par défaut, suivi d'une mise à jour. Le mode avancé envoie des signaux sans cookies en cas de refus afin d'alimenter la modélisation.

Une CMP certifiée par Google est la référence faisant foi : elle affiche la bannière, enregistre le consentement et transmet ces signaux ainsi que la chaîne TC de l'IAB. Appliquez le consentement à la fois côté client et côté serveur, et vérifiez lors des audits que les valeurs par défaut sont « refusé » avant le déclenchement de toute balise.