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.

L’essentiel
  • 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-gcs ou équivalent).

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 revoke au chargement et que l’utilisateur accepte : il faut basculer en grant au 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/fbc initial 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 à écouterType de déclencheur GTM
OneTrustOneTrustGroupsUpdatedCustom Event
CookiebotCookiebotOnAccept et CookiebotOnDeclineCustom Event (2 triggers)
Didomiconsent.changed (via API push dans dataLayer)Custom Event
Axeptioaxeptio_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 fbq doit être fbq('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ômeCause probable
Le Pixel envoie avant consentementfbq('consent', 'revoke') pas appelé avant init
Pas de conversion après acceptationLa balise Update Consent ne fire pas au bon event CMP
Inversion grant/revokeVariable de consentement mal configurée (mauvais groupe OneTrust, mauvais purpose Didomi)
Cookie fbp manquantLe 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.

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 :

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

Besoin d'aide sur ce sujet ?

Je peux vous accompagner sur la mise en place ou l'optimisation de votre tracking.

Sans surprise : forfaits affichés en clair, devis validé avant kick-off, pas d'avenant.