Cookies _fbp et _fbc : rôle, durée de vie et consentement

Que sont les cookies _fbp et _fbc ?

Lancez un audit de cookies sur un site qui fait de la publicité Meta et vous verrez presque toujours ces deux noms. Ils proviennent du Pixel Meta (anciennement Pixel Facebook), le script fbevents.js que les annonceurs installent pour mesurer les conversions et alimenter leurs audiences sur Facebook et Instagram. Leur rôle : relier ce qui se passe sur votre site à ce qui s'est passé sur les plateformes de Meta.

Description du cookie _fbp

D'après la documentation de Meta, lorsque le Pixel est installé et utilise des cookies propriétaires, il enregistre automatiquement un identifiant unique dans le cookie _fbp. Meta le présente comme un cookie qui identifie les navigateurs afin de fournir des services de publicité et d'analyse de site. Concrètement, il permet de reconnaître le même navigateur d'une visite à l'autre, même si l'internaute n'a jamais cliqué sur une annonce.

Description du cookie _fbc

_fbc n'apparaît que si le visiteur arrive depuis une publicité Meta. Au clic sur une annonce Facebook ou Instagram, Meta ajoute à l'URL de votre page d'atterrissage un paramètre fbclid (le ClickID). Le Pixel le lit et le stocke dans _fbc, ce qui permet d'attribuer à ce clic précis un achat ou une inscription réalisés plus tard.

Que contiennent réellement _fbp et _fbc ?

La documentation de l'API Conversions consacrée à fbp et fbc décrit le format exact des deux valeurs, construites sur le même modèle en quatre parties :

• _fbp : version.subdomainIndex.creationTime.randomnumber, par exemple fb.1.1596403881668.1116446470. Le nombre aléatoire est généré par le code de Meta pour garantir l'unicité de la valeur.
• _fbc : version.subdomainIndex.creationTime.fbclid, par exemple fb.1.1554763741205.IwAR2F4-.... La dernière partie est l'identifiant de clic copié depuis l'URL.
• version vaut toujours fb, subdomainIndex indique le niveau de domaine sur lequel le cookie est posé (com = 0, exemple.fr = 1, www.exemple.fr = 2) et creationTime est un horodatage UNIX en millisecondes.

Aucun nom ni adresse e-mail dans ces cookies. Pour autant, ils ne sont pas anonymes : un identifiant unique et persistant rattaché à un navigateur est un identifiant en ligne, donc une donnée personnelle au sens du RGPD dès lors qu'il permet d'individualiser une personne. C'est précisément sa fonction.

Quelle est la durée de vie de _fbp et _fbc ?

Meta indique dans ses informations sur les cookies des appareils Meta Quest que le cookie _fbp a une durée de vie de 90 jours. Pour _fbc, la documentation développeurs de Meta recommande une expiration de 90 jours lorsque vous créez vous-même le cookie à partir du paramètre fbclid. Les navigateurs peuvent raccourcir ces durées : Safari, par exemple, limite la durée de certains cookies déposés en JavaScript.

À titre de comparaison, la CNIL recommande de limiter à 13 mois la durée de vie des traceurs de mesure d'audience exemptés de consentement ; cette exemption ne concerne pas les cookies publicitaires comme _fbp, qui restent soumis au consentement quelle que soit leur durée. Pour approfondir, consultez notre article sur la règle des 13 mois de la CNIL.

Des cookies propriétaires, mais au service de Meta

On entend souvent que _fbp et _fbc seraient « sans risque » parce qu'ils sont propriétaires. Ils ne le sont qu'au sens technique : le script du Pixel s'exécute sur votre page et écrit les cookies sur votre domaine, si bien que le navigateur les considère comme les vôtres et que le blocage des cookies tiers ne les arrête pas. Les données, elles, partent chez Meta à chaque événement du Pixel et servent ses produits publicitaires.

Meta utilise par ailleurs ses propres cookies sur ses domaines (comme facebook.com), qui sont des cookies tiers du point de vue de votre site. Propriétaire ou tiers, cela change le comportement des navigateurs, pas l'analyse juridique : c'est la finalité qui compte, et ici la finalité est publicitaire.

Pourquoi _fbp et _fbc exigent un consentement préalable

L'article 82 de la loi Informatique et Libertés, qui transpose l'article 5(3) de la directive ePrivacy, n'autorise le dépôt ou la lecture d'informations sur le terminal de l'utilisateur qu'avec son consentement, sauf si le traceur est strictement nécessaire au service demandé. La CNIL le rappelle dans sa page « Cookies et traceurs : que dit la loi ? » : les cookies liés à la publicité personnalisée nécessitent une information et un consentement préalables, et l'utilisateur doit pouvoir refuser aussi simplement qu'il accepte.

La Cour de justice de l'Union européenne s'est d'ailleurs penchée sur les outils de Facebook. Dans l'arrêt Fashion ID (C-40/17) du 29 juillet 2019, elle a jugé que le site qui intègre un module Facebook est responsable conjoint de la collecte et de la transmission des données de ses visiteurs, et que c'est à l'éditeur du site, et non à Facebook, de recueillir le consentement en amont. Le même raisonnement vaut pour le Pixel : c'est vous qui choisissez de l'installer, c'est donc à vous de demander l'accord.

Ce que cela implique concrètement :

• aucun cookie _fbp ou _fbc, ni aucune requête vers Meta, avant que le visiteur ait cliqué sur « Accepter » ou activé la catégorie publicité ;
• un bouton « Tout refuser » aussi visible que « Tout accepter », la poursuite de la navigation ne valant pas consentement ;
• un retrait du consentement qui stoppe le Pixel dès les pages suivantes ;
• une preuve du consentement recueilli, à présenter en cas de contrôle.

Pour la conformité du Pixel dans son ensemble (Advanced Matching, transferts de données, Limited Data Use), lisez notre guide de mise en conformité du Meta Pixel au RGPD.

_fbp, _fbc, fbclid et l'API Conversions

L'API Conversions (CAPI) permet à votre serveur d'envoyer directement des événements à Meta. Pour rapprocher ces événements serveur d'un navigateur et d'un clic publicitaire, Meta attend deux paramètres, fbp et fbc, au même format que les cookies. La plupart des intégrations lisent simplement les cookies _fbp et _fbc dans la requête entrante et les transmettent. En l'absence de cookie _fbc, Meta explique que l'on peut reconstruire la valeur fbc à partir du paramètre fbclid présent dans l'URL.

C'est là que beaucoup de configurations dérapent. Passer côté serveur ne fait pas sortir le suivi du champ de la loi :

• si votre serveur ou votre tag manager crée son propre cookie _fbc à partir du fbclid, il s'agit toujours d'un dépôt sur le terminal, soumis au consentement ;
• transmettre fbp, fbc, l'adresse IP et le user agent à Meta est un transfert de données personnelles à des fins publicitaires, qui requiert une base légale, en pratique le consentement ;
• les événements serveur doivent donc suivre le même choix que le Pixel navigateur, sans quoi vous suivez par la porte de derrière ceux qui ont refusé.

Notre article sur le server-side tagging et le consentement détaille comment transmettre ce signal au serveur.

Comment bloquer _fbp et _fbc jusqu'au consentement

La seule méthode fiable consiste à empêcher le code de base du Pixel de s'exécuter avant l'accord du visiteur. Voici une marche à suivre :

1. Recensez tous les endroits où le Pixel est chargé : code du thème, module Shopify, PrestaShop ou WordPress, Google Tag Manager, intégration d'un partenaire. Une double installation est la cause la plus fréquente d'un _fbp déposé avant consentement.
2. Conditionnez le code de base à la catégorie publicité de votre bandeau, pour que fbevents.js ne soit injecté qu'après acceptation. Avec FlowConsent, c'est le blocage préalable des scripts qui s'en charge, sans passer par Google Tag Manager.
3. Si le snippet doit rester dans la page, le guide RGPD de Meta propose d'appeler fbq('consent', 'revoke') avant init, puis fbq('consent', 'grant') une fois l'accord donné. Meta présente cette API comme une mise en pause de l'envoi des événements ; elle ne précise pas qu'elle empêche l'écriture des cookies. Ne rien charger avant le consentement reste donc la solution la plus sûre.
4. Alignez l'API Conversions sur la même décision et ne transmettez ni fbp ni fbc pour les visiteurs qui ont refusé.
5. Gérez le retrait : quand le consentement est retiré, cessez de charger le Pixel et supprimez de préférence les cookies _fbp et _fbc existants, ce qui est possible puisqu'ils sont sur votre domaine.
6. Documentez le tout dans votre politique de cookies et conservez la preuve des consentements.

Comment vérifier que le blocage fonctionne

1. Ouvrez votre site en navigation privée, sans toucher au bandeau.
2. Dans les outils de développement de Chrome, onglet Application > Cookies, vérifiez l'absence de _fbp et de _fbc.
3. Dans l'onglet Réseau, filtrez sur facebook : ni fbevents.js ni requête vers facebook.com/tr ne doivent apparaître.
4. Ajoutez ?fbclid=test123 à l'URL et rechargez : toujours aucun _fbc avant consentement.
5. Cliquez sur Accepter : _fbp doit apparaître, ainsi que _fbc si l'URL contient un fbclid.
6. Recommencez en cliquant sur Refuser : rien ne doit être déposé, même après plusieurs pages.

Refaites ce test après chaque mise à jour de thème ou ajout de module. Un audit de cookies régulier permet de repérer un Pixel qui se serait réinstallé discrètement.

Conclusion

_fbp et _fbc sont discrets, mais ils constituent le socle de l'attribution chez Meta : un identifiant de navigateur et un identifiant de clic, conservés environ 90 jours et transmis à Meta. Être propriétaire ne les dispense pas du consentement, pas plus que le passage à l'API Conversions. Bloquez le Pixel jusqu'à l'accord du visiteur, répercutez ce choix côté serveur et testez régulièrement. Pour savoir si _fbp ou _fbc est déposé avant consentement sur votre site, lancez un scan gratuit : FlowConsent détecte automatiquement les cookies, bloque les scripts jusqu'au consentement et conserve la preuve des consentements pendant 13 mois.