meta-capiconsent-mode

Meta CAPI et consentement en UE : ce qui part, ce qui reste

Le Consent Mode de Google ne couvre pas Meta. Pixel et CAPI exigent le consentement en Europe : ce qui part, ce qui se perd et l'architecture propre.

Le Consent Mode de Google ne protège pas le pixel Meta ni la Conversions API : ils ne lisent pas son signal par défaut, et chaque envoi sans consentement reste un traceur soumis à la directive ePrivacy. En Europe, Meta n’offre aucun mode « limité » équivalent à celui des États américains, donc le consentement doit être obtenu avant pixel et CAPI. Ce qu’on perd quand il arrive tard est réel, mais ça ne justifie pas de partir sans lui.

Consent Mode v2 informe les balises Google (Google Ads, GA4 via gtag) de l’état du consentement et ajuste leur comportement. Le pixel Meta et le tag CAPI dans GTM ne suivent pas ce mécanisme sans configuration explicite. Un conteneur peut donc être « conforme Google » et envoyer des événements Meta dès le chargement de la page.

Outils Meta (Pixel / CAPI) GTM Server-Side Consent Mode v2 Axeptio Didomi

La conséquence concrète : le gating doit être fait pour chaque balise Meta, côté web comme côté serveur, à partir du flag marketing de la CMP.

Ce que Meta exige en Europe

Deux points de la documentation Meta sont à lire ensemble.

Limited Data Use ne s’applique pas à l’UE. Meta documente le LDU pour certains États américains (Californie, Colorado, Connecticut et d’autres) et, pour les listes clients, pour la seule Californie. Aucune mention de l’Union européenne sur cette page. Activer le LDU ne règle donc rien pour un visiteur français.

Les conditions Business Tools imposent le consentement. Dans la version entrée en vigueur le 3 novembre 2025, l’annonceur doit s’assurer, de manière vérifiable, que les utilisateurs donnent les consentements nécessaires avant l’usage des outils, y compris dans l’UE. Il doit aussi disposer d’une base légale et afficher un avis clair sur chaque page où les pixels sont présents. La clause vise les outils Business en général et ne cite pas nommément la CAPI ; le raisonnement vaut pourtant pour les deux flux, puisque les deux transmettent des données de l’utilisateur.

Le paramétrage « traitement des données » de Meta n’est donc pas une alternative au consentement. Les options de traitement indiquent à Meta qu’un événement doit suivre des règles régionales précises, comme le LDU aux États-Unis. Les activer côté UE ne modifie ni la base légale du traitement ni l’obligation de recueillir le consentement. Ce réglage relève de la configuration technique : il se documente dans le registre, mais il ne remplace aucune étape de la CMP.

La question à poser est simple : quel consentement est recueilli avant le premier envoi, et qui le vérifie ?

Ce qu’on perd quand le consentement arrive tard

Trois éléments disparaissent ou s’affaiblissent quand le consentement est pris après le premier événement :

  • fbclid : le paramètre d’URL que Meta ajoute aux clics publicitaires. Si la page ne le capte pas à l’arrivée, il n’est plus disponible pour l’événement suivant.
  • _fbc et _fbp : les cookies first-party de Meta. Un _fbc créé à partir d’un fbclid ne doit être posé qu’après consentement, à mon sens, car c’est un traceur. Le prix est une perte de rattachement pour les premiers événements.
  • Event Match Quality (EMQ) : moins d’identifiants reçus, donc un score plus faible. Le problème est structurel : une CAPI sans consentement ne peut pas compenser par des identifiants sans créer un autre problème.

Ce compromis est réel, mais il est tolérable. Une EMQ plus basse coûte de la performance d’optimisation ; un envoi non consenti expose à une sanction.

Ce qui reste légal sans consentement côté Meta

Je ne connais aucun cas où un envoi à Meta à des fins publicitaires, identifiant un utilisateur ou lié à son navigateur, serait légal sans consentement. La dérogation CNIL pour la mesure d’audience vise une mesure interne et strictement limitée ; elle ne couvre pas, à ma lecture, un envoi vers une régie. Je ne trouve pas non plus de décision qui l’étende à la CAPI. Ce point reste à confirmer avec le DPO ou un juriste, car je n’ai pas vérifié le texte à jour des lignes directrices CNIL.

Architecture propre : CMP, signal, pixel et CAPI conditionnés

Mon schéma de référence, pour un site avec consentement :

  1. La CMP émet un consentement granulaire, au minimum séparant marketing et analytics.
  2. Le signal est poussé dans le dataLayer et lu par GTM web et par le conteneur serveur.
  3. Le pixel n’est chargé que si le flag marketing est accordé.
  4. Le tag CAPI dans le conteneur serveur est conditionné par le même flag. Sans consentement, je ne transmets rien, y compris des hachages.
  5. Le même event_id est généré côté navigateur, envoyé au pixel et transmis à la CAPI, pour la déduplication.
  6. Les email et téléphone sont hachés en SHA-256 après normalisation (minuscules, espaces retirés), jamais en clair.

Ce schéma s’inscrit dans une mise en place server-side plus large. Si le tag serveur ne lit pas le flag de la CMP, la conformité repose sur le seul pixel, ce qui n’est pas une architecture.

Pour le détail technique du mapping d’événements, voir le guide server-side Meta CAPI et le glossaire Meta CAPI.

Erreurs classiques relevées en audit

  • CAPI qui part sans consentement : le pixel est bloqué par la CMP, mais le tag serveur n’en tient pas compte. C’est l’erreur la plus grave, et elle passe souvent inaperçue car le pixel semble correct.
  • EMQ gonflé par des données non consenties : les emails hachés arrivent dans le même payload que des événements sans consentement, et le score donne une fausse impression de qualité.
  • Incohérence pixel et CAPI : le pixel respecte la CMP, la CAPI non. Les deux flux ne racontent plus la même histoire dans Events Manager.
  • event_id différents entre pixel et CAPI : la déduplication échoue, les conversions sont comptées deux fois. L’étape correspondante est dans la procédure de mise en place du GTM server-side.

Ces points se vérifient en quelques minutes : navigation privée, refus de tous les cookies, puis contrôle de l’onglet Réseau et du Test Events Meta.

FAQ

Le Consent Mode v2 suffit-il pour Meta ? Non. Il ne couvre que les balises Google. Meta exige un gating explicite de son pixel et de sa CAPI.

Peut-on envoyer la CAPI sans consentement en mode anonymisé ? Je ne le recommande pas. Même sans identifiants, un événement lié au site et au navigateur peut être un traitement soumis à consentement. Le point est à valider par un juriste.

Le Limited Data Use protège-t-il les utilisateurs européens ? Non. La documentation Meta le limite aux États américains indiqués. Il ne remplace pas le consentement en UE.

Sources

Ron Kopelman

Besoin d'aide sur ce sujet ?

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