Consent Mode META avec OneTrust, Cookiebot, Didomi et Axeptio : la procédure
Le Consent Mode de Meta (fbq consent) est différent du Consent Mode Google. Voici comment l'implémenter via GTM avec chaque CMP majeure.
Quand on parle de Consent Mode, on pense d’abord à celui de Google — le gtag('consent', ...) qui pilote Ads, GA4 et Floodlight. Mais Meta a son propre mécanisme : fbq('consent', 'grant' | 'revoke'). Et il fonctionne sur une logique différente, indépendante du Consent Mode v2 Google.
Sur la plupart des sites que j’audite, ce point est mal géré : soit le Meta Pixel tire avant consentement (et perd les fbp cookies), soit il est complètement bloqué (et l’attribution Meta s’effondre). La bonne implémentation, via GTM et la CMP, prend une à deux heures par CMP. Voici la procédure complète pour les quatre CMP majeures du marché FR.
- Le Consent Mode Meta est distinct du Consent Mode Google v2 — il faut le configurer en plus.
- Le principe : initialiser le Pixel avec
fbq(‘consent’, ‘revoke’)par défaut, puis basculer en‘grant’via l’event CMP. - Chaque CMP expose ses propres événements et variables (
OneTrustGroupsUpdated,CookiebotOnAccept, etc.). - Si Meta CAPI est en place côté server-side, la logique de consentement doit aussi y être propagée (via
x-ga-gcsou équivalent).
Pourquoi Meta a son propre Consent Mode
Le Consent Mode v2 de Google contrôle 4 signaux (ad_storage, analytics_storage, ad_user_data, ad_personalization). Meta n’écoute aucun de ces signaux. Il a son propre flag, géré via la commande fbq('consent', ...), qui n’accepte que deux valeurs : grant ou revoke.
Conséquences pratiques :
- Si vous n’envoyez rien : le Pixel se comporte par défaut, mais sans signal de consentement explicite, vous êtes en zone grise RGPD.
- Si vous envoyez
revokeau chargement et que l’utilisateur accepte : il faut basculer engrantau moment du consentement, sinon les événements de conversion ne remontent pas correctement. - Si vous bloquez complètement le Pixel jusqu’à consentement : vous perdez le cookie
fbp/fbcinitial et le matching des conversions ultérieures dégrade fortement.
La bonne pratique est de charger le Pixel avec revoke par défaut, puis basculer en grant dès que la CMP signale l’acceptation marketing. C’est exactement ce que fait l’implémentation correcte.
Prérequis communs
Avant d’attaquer la CMP, vérifier que les fondamentaux sont en place :
- Compte GTM actif avec accès admin
- Container GTM déployé sur le site, prêt à être modifié
- Meta Pixel déjà implémenté via GTM (variable constante pour le Pixel ID, balise Meta Pixel utilisant la variable)
- CMP en place et fonctionnelle (test : accepter / refuser → la bannière disparaît)
Étape 1 — Modifier la balise Meta Pixel pour démarrer en revoke
Le Pixel doit s’initialiser en mode revoke AVANT toute autre commande fbq. Deux approches selon la balise utilisée :
Avec la balise communauté Meta Pixel
Dans les paramètres avancés de la balise, configurer Consent sur Revoked par défaut.
Avec une balise HTML personnalisée
Injecter fbq('consent', 'revoke') avant l’initialisation du Pixel :
<script>
!function(f,b,e,v,n,t,s){if(f.fbq)return;n=f.fbq=function(){n.callMethod?
n.callMethod.apply(n,arguments):n.queue.push(arguments)};
if(!f._fbq)f._fbq=n;n.push=n;n.loaded=!0;n.version='2.0';
n.queue=[];t=b.createElement(e);t.async=!0;
t.src=v;s=b.getElementsByTagName(e)[0];
s.parentNode.insertBefore(t,s)}(window,document,'script',
'https://connect.facebook.net/en_US/fbevents.js');
fbq('consent', 'revoke'); // <-- AVANT init
fbq('init', '{{Meta Pixel ID}}');
fbq('track', 'PageView');
</script>
L’ordre est critique. consent doit précéder init, sinon le PageView part avec un cookie fbp créé sans signal de consentement.
Étape 2 — Créer la variable de consentement selon la CMP
Variable JavaScript personnalisée GTM qui retourne true si l’utilisateur a accepté le marketing/publicité, false sinon.
OneTrust
OneTrust expose une variable globale OnetrustActiveGroups contenant les IDs des catégories acceptées. Le groupe C0004 correspond généralement à “Targeting Cookies” (publicité/marketing), mais vérifier la configuration de la propriété.
function() {
if (typeof OnetrustActiveGroups === 'undefined') return false;
return OnetrustActiveGroups.indexOf('C0004') !== -1; // C0004 = marketing
}
Cookiebot
Cookiebot expose Cookiebot.consent.marketing (boolean).
function() {
if (typeof Cookiebot === 'undefined' || !Cookiebot.consent) return false;
return Cookiebot.consent.marketing === true;
}
Didomi
Didomi expose une API getUserConsentStatusForPurpose.
function() {
if (typeof Didomi === 'undefined') return false;
return Didomi.getUserConsentStatusForPurpose('advertising') === true;
}
Axeptio
Axeptio expose des callbacks via _axcb.push. La variable peut s’appuyer sur un dataLayer event poussé au moment du choix.
function() {
// À pousser dans le dataLayer via _axcb.push((sdk) => { sdk.on('cookies:complete', ...) })
var dl = window.dataLayer || [];
for (var i = dl.length - 1; i >= 0; i--) {
if (dl[i].axeptio_marketing !== undefined) return dl[i].axeptio_marketing === true;
}
return false;
}
Étape 3 — Créer la balise de mise à jour du consentement
Balise HTML personnalisée nommée par exemple Meta - Update Consent Status, qui exécute fbq('consent', 'grant') ou 'revoke') selon la variable.
<script>
(function() {
var hasConsent = {{JS - Meta Marketing Consent}};
if (typeof fbq !== 'undefined') {
fbq('consent', hasConsent ? 'grant' : 'revoke');
}
})();
</script>
Étape 4 — Configurer les déclencheurs CMP
Chaque CMP émet ses propres événements quand l’utilisateur fait son choix. Créer un déclencheur GTM par événement.
| CMP | Événement à écouter | Type de déclencheur GTM |
|---|---|---|
| OneTrust | OneTrustGroupsUpdated | Custom Event |
| Cookiebot | CookiebotOnAccept et CookiebotOnDecline | Custom Event (2 triggers) |
| Didomi | consent.changed (via API push dans dataLayer) | Custom Event |
| Axeptio | axeptio_marketing_updated (à pousser via callback) | Custom Event |
Associer la balise Meta - Update Consent Status à ces déclencheurs. À chaque fois que l’utilisateur modifie son choix, le Pixel met à jour son état.
Étape 5 — Conditionner les conversions sur le consentement
Pour les événements de conversion (Purchase, Lead, AddToCart, etc.), ajouter un filtre dans le code de la balise pour ne pas tracker sans consentement :
<script>
(function() {
if (!{{JS - Meta Marketing Consent}}) return;
fbq('track', 'Purchase', {
value: {{DL - Purchase Value}},
currency: 'EUR'
});
})();
</script>
Cette double-protection évite que des hits partent même brièvement avant la mise à jour consent.
Étape 6 — Tester et déboguer
Test fonctionnel en mode preview
- Activer le mode aperçu GTM
- Ouvrir le site en navigation privée
- Vérifier dans la console : la première commande
fbqdoit êtrefbq('consent', 'revoke') - Refuser la bannière : confirmer que rien ne part vers Meta
- Recharger, accepter : confirmer le passage à
fbq('consent', 'grant')puis les events de conversion
Validation via Facebook Pixel Helper
L’extension Chrome Facebook Pixel Helper montre en temps réel les events envoyés et leur état de consentement. C’est l’outil de référence pour valider.
Problèmes fréquents
| Symptôme | Cause probable |
|---|---|
| Le Pixel envoie avant consentement | fbq('consent', 'revoke') pas appelé avant init |
| Pas de conversion après acceptation | La balise Update Consent ne fire pas au bon event CMP |
| Inversion grant/revoke | Variable de consentement mal configurée (mauvais groupe OneTrust, mauvais purpose Didomi) |
Cookie fbp manquant | Le Pixel a été complètement bloqué au lieu d’être initialisé en revoke |
Synchroniser avec Meta CAPI server-side
Si vous avez un container server-side avec une intégration Meta Conversions API, la logique de consentement doit aussi y être propagée. L’approche standard est d’utiliser le paramètre x-ga-gcs (forwardé par Google Consent Mode) ou un paramètre custom dans les events.
Sans ça, vous pouvez avoir le browser Pixel correctement bloqué pour un utilisateur, et la CAPI qui continue d’envoyer la conversion server-side — risque de double-comptage et de fuite RGPD.
Cohérence Google + Meta Consent Mode
Travailler ces deux Consent Modes en parallèle nécessite de bien séparer les variables, balises et triggers. Ne pas réutiliser la variable Google Consent Mode pour Meta — les sémantiques sont différentes. Sur cette logique, voir aussi :
- Consent Mode v2 Google : Basic vs Advanced — pour le pendant Google
- Audit de conformité Consent Mode — pour vérifier que tout fonctionne ensemble
- Migration entre CMP — pour gérer les bascules d’une CMP à l’autre
- 67% des implémentations Consent Mode v2 sont non conformes — checklist d’audit et décodage du paramètre
gcs=
En synthèse
Le Consent Mode META se résume à : fbq('consent', 'revoke') au chargement, puis bascule en 'grant' via les events de la CMP. La logique est la même partout, ce qui change c’est l’API de chaque CMP pour récupérer le statut. Compter 1 à 2 heures d’implémentation par CMP, plus la validation en Pixel Helper. C’est typiquement l’une des actions à fort impact qu’un audit tracking identifie et chiffre.
Sources
- Meta for Developers — Pixel consent commands — documentation officielle Meta sur
fbq('consent', ...) - CNIL — Cookies et autres traceurs — cadre légal applicable en France