Loi 25 · Meta Pixel

Meta Pixel et Loi 25 au Québec

Le Pixel signale à Meta ce que font vos visiteurs, et alimente des audiences publicitaires. Ce guide montre ce qui se vérifie depuis un navigateur, et ce qui n’en est pas détectable.

Mis à jour le 26 août 2026 Lecture : 12 minutes

Sommaire
  1. Ce que fait le Pixel
  2. Les événements
  3. Audiences et remarketing
  4. Ce qui passe par le serveur
  5. Détecter un pixel
  6. Les points à vérifier
  7. Navigateur et serveur
  8. Questions fréquentes

Ce que fait
le Pixel

Anciennement Pixel Facebook, il porte aujourd’hui le nom de Pixel Meta. Le code n’a pas changé de nature : c’est un script qui signale à Meta ce que fait un visiteur sur votre site.

Un signal, pas une mesure

La différence avec un outil d’analyse est importante. Google Analytics sert d’abord à vous informer. Le Pixel, lui, sert à alimenter une plateforme publicitaire : il transmet à Meta des événements qui serviront à optimiser des campagnes et à constituer des audiences.

Techniquement, le site charge fbevents.js depuis connect.facebook.net, puis appelle la fonction fbq(). Chaque appel produit une requête vers facebook.com/tr, avec l’identifiant du pixel et le nom de l’événement.

Le code de base déclenche à lui seul un événement PageView, au chargement. C’est le comportement par défaut : installer le pixel, c’est déjà envoyer quelque chose.

Les témoins qu’il pose

  • _fbp : un identifiant attribué au navigateur, déposé par votre domaine, qui permet de reconnaître le visiteur d’une session à l’autre.
  • _fbc : présent lorsque la personne arrive par une publicité, il conserve l’identifiant du clic et relie la visite à la campagne.

Ces témoins sont de première partie. Cela ne change pas leur finalité : ils servent à rattacher un comportement à une personne, dans un système qui connaît déjà cette personne par ailleurs.

C’est la particularité du Pixel par rapport à un outil de mesure : Meta dispose d’un profil correspondant à la plupart des visiteurs. Le rapprochement ne se fait pas avec un identifiant anonyme, mais avec un compte.

Les événements,
et ce qu’ils disent

Meta propose une liste d’événements standards. Leur nom seul décrit déjà finement le comportement d’une personne.

Un événement part avec des paramètres : la valeur d’un achat, la devise, l’identifiant du produit, le contenu consulté. Ce n’est pas un compteur, c’est une description.

Sur une boutique, la suite ViewContentAddToCartPurchase reconstitue un parcours d’achat complet, montant compris, rattaché à un navigateur, et souvent à un compte.

Les événements personnalisés vont plus loin encore, puisque leur contenu est libre. C’est là qu’on retrouve, parfois sans intention, des informations qui n’ont rien à faire dans une requête publicitaire.

  1. 01PageViewPage consultée
  2. 02ViewContentProduit vu
  3. 03SearchRecherche
  4. 04AddToCartAjout au panier
  5. 05InitiateCheckoutCaisse entamée
  6. 06AddPaymentInfoPaiement saisi
  7. 07PurchaseAchat, avec montant
  8. 08LeadFormulaire envoyé
  9. 09CompleteRegistrationCompte créé
  10. 10ContactPrise de contact
  11. 11ScheduleRendez-vous
  12. 12SubscribeAbonnement

Audiences et remarketing

C’est la finalité réelle du Pixel, et celle qui est le moins souvent annoncée aux visiteurs.

Du site à la publicité

Les événements reçus permettent de construire des audiences personnalisées : les personnes ayant vu un produit, abandonné un panier, visité une page précise dans les trente derniers jours. Ces audiences deviennent des cibles publicitaires sur Facebook et Instagram.

Meta en dérive aussi des audiences similaires : d’autres personnes, qui ressemblent aux vôtres. Vos visiteurs servent alors de modèle pour en atteindre d’autres, ce qui dépasse largement la mesure de fréquentation.

Ce que dit la loi

Le consentement doit être demandé pour chacune des fins poursuivies, présenté de façon claire et distincte. Mesurer la fréquentation d’un site et constituer des audiences publicitaires sont deux fins différentes : elles ne peuvent pas être obtenues par le même « J’accepte » global.

La correspondance avancée

Le Pixel peut transmettre, en plus des événements, des données identifiantes du visiteur : adresse courriel, numéro de téléphone, nom, ville. Elles sont transformées en empreintes avant l’envoi, ce qui empêche de les lire mais permet parfaitement de les rapprocher d’un compte existant.

La correspondance avancée automatique lit ces valeurs dans les champs de formulaire de la page. Elle peut donc s’activer sans qu’on ait écrit une ligne de code, et transmettre le contenu d’un formulaire de contact.

Recommandation Repère

Vérifier si la correspondance avancée automatique est active avant tout le reste. C’est le réglage qui transforme un pixel publicitaire en canal de transmission de renseignements personnels, et il est activé par défaut dans plusieurs intégrations.

Formulaires de contact et Loi 25 →

Ce qui passe
par le serveur

C’est la limite honnête de toute vérification faite depuis un navigateur, y compris la nôtre. Elle mérite d’être dite clairement.

L’API de conversions

Meta propose une seconde voie : au lieu que le navigateur du visiteur envoie l’événement, c’est votre serveur qui le transmet directement à Meta. Cette voie s’appelle l’API de conversions, et elle est aujourd’hui largement déployée : les plateformes de commerce l’intègrent souvent d’un simple réglage.

Les deux voies coexistent la plupart du temps. Un identifiant d’événement commun permet à Meta de reconnaître qu’un achat signalé deux fois n’est arrivé qu’une seule fois.

La limite à connaître

Une vérification effectuée depuis le navigateur ne permet pas nécessairement de détecter ce qui est transmis côté serveur. Un site peut ne montrer aucune requête vers Meta et continuer d’envoyer des événements par son serveur.

Autrement dit : l’absence de pixel visible dans la page n’est pas la preuve qu’aucune donnée ne part vers Meta. C’est une information capitale pour interpréter correctement un rapport de scan, le nôtre comme n’importe quel autre.

Ce que ça change

Le passage par le serveur ne modifie pas les obligations. Les renseignements transmis restent des renseignements personnels, la finalité publicitaire reste la même, et le consentement attendu reste le même. Ce qui change, c’est la visibilité : le visiteur ne peut plus le constater, et vous non plus depuis l’extérieur.

Un point technique mérite attention : l’état du consentement doit voyager jusqu’au serveur. Une bannière qui bloque correctement le pixel du navigateur, mais dont le choix n’est jamais transmis au traitement serveur, laisse partir les événements comme si rien n’avait été refusé.

Recommandation Repère

Sur une boutique où l’API de conversions est active, vérifier que le refus exprimé dans la bannière atteint bien le traitement serveur. C’est le point aveugle le plus courant, et il ne se voit dans aucun outil public.

Détecter un pixel
sur votre site

Pour la partie navigateur, la vérification est simple. Trois signes, et une lecture de l’onglet Réseau.

  1. Le script

    Cherchez connect.facebook.net ou fbevents.js dans le code source de la page.

  2. Le témoin

    Un témoin _fbp dans le stockage du navigateur signale que le pixel s’est exécuté.

  3. L’envoi

    Dans l’onglet Réseau, filtrez sur facebook : une requête vers /tr est un événement parti.

Comme pour la mesure d’audience, faites la lecture trois fois : avant tout clic, après acceptation, après refus. La requête /tr porte le nom de l’événement dans ses paramètres, ce qui permet de voir exactement ce qui est signalé.

Un pixel oublié se reconnaît à sa solitude : il envoie un PageView et rien d’autre, parce que plus personne ne configure d’événements depuis l’arrêt des campagnes. Il continue pourtant d’alimenter une audience.

Rappel utile : cette vérification décrit la voie navigateur. Elle ne dit rien de ce que votre serveur transmet par ailleurs.

Les points
à vérifier

Neuf contrôles propres au Pixel Meta. Les cinq premiers se lisent depuis l’extérieur ; les autres demandent un accès au gestionnaire d’événements.

  1. Présence du pixelLe script fbevents.js chargé, et l’identifiant du pixel.
  2. Envoi avant le choixUne requête vers /tr avant toute interaction du visiteur.
  3. Témoins déposés_fbp et _fbc présents avant le consentement.
  4. Comportement après refusCe qui continue de partir une fois le refus enregistré.
  5. Événements déclenchésLesquels partent, et ce que contiennent leurs paramètres.
  6. Correspondance avancéeSi des données identifiantes accompagnent les événements.
  7. API de conversionsSi des événements sont aussi transmis par le serveur.
  8. Transmission du refus au serveurSi le choix du visiteur atteint le traitement côté serveur.
  9. Finalité annoncéeLa publicité et le remarketing nommés dans la politique et la bannière.

Cinq de ces neuf points se lisent sans aucun accès.

Le pixel oublié après une campagne est le cas le plus courant.

Les deux points serveur ne se voient d’aucun outil public.

Un pixel tourne-t-il encore sur votre site ?

Le scan Repère charge votre page sans rien accepter et vous dit quels pixels publicitaires se sont déclenchés.

Lancer le scan gratuit

Navigateur et serveur

La séparation est plus nette ici que sur n’importe quel autre sujet de ce guide. Nous préférons l’écrire que la laisser deviner.

Détectable depuis le navigateur

  • Le chargement de fbevents.js
  • L’identifiant du pixel utilisé
  • Les requêtes vers /tr et leur moment
  • Le nom des événements déclenchés
  • Les témoins _fbp et _fbc
  • Le comportement après acceptation et après refus
  • La mention de la publicité dans la politique

Invisible sans accès à vos outils

  • Les événements transmis par l’API de conversions
  • Le contenu réel des données de correspondance
  • Les audiences constituées à partir du site
  • Les audiences similaires qui en dérivent
  • La durée de conservation côté Meta
  • La transmission du refus au traitement serveur
  • Les intégrations activées dans la plateforme
  • L’encadrement du transfert hors Québec

Aucune analyse publique ne voit ce qui part d’un serveur. Le scan Repère décrit la voie navigateur, complètement et honnêtement ; la voie serveur demande d’ouvrir vos outils. Les obligations citées viennent des textes québécois, les recommandations sont signalées comme telles.

Questions fréquentes

Ce qu’on nous demande quand un pixel publicitaire est découvert sur un site.

Le Pixel Meta est-il interdit au Québec ?

Non. À notre connaissance, aucun texte québécois n’interdit un pixel publicitaire. Ce qui est encadré, c’est la collecte et la communication de renseignements personnels : information claire, consentement pour chaque finalité, encadrement du transfert hors Québec.

La question à se poser n’est donc pas « ai-je le droit ? » mais « le visiteur a-t-il été informé de cette finalité précise, et a-t-il pu s’y opposer ? »

J’ai arrêté mes campagnes : le pixel pose-t-il encore problème ?

S’il est resté dans les pages, il continue d’envoyer un PageView à chaque visite et d’alimenter les audiences associées au compte. L’arrêt des campagnes ne désactive pas le pixel.

C’est le cas le plus fréquent que nous rencontrons, et le plus simple à corriger : retirer le code ou la balise du conteneur suffit.

Un pixel installé par Google Tag Manager change-t-il quelque chose ?

Pas sur le fond : les événements partent de la même façon. Sur la forme, oui : le pixel n’apparaît plus dans le code de la page, ce qui le rend plus difficile à inventorier.

L’avantage du conteneur est qu’il permet de conditionner le déclenchement au consentement, à condition que la liaison avec la bannière soit réellement faite. Le guide Google Analytics détaille ce mécanisme.

La correspondance avancée est-elle activée sur mon site ?

Elle l’est plus souvent qu’on ne le croit : plusieurs intégrations de commerce et plusieurs extensions l’activent par défaut. Elle se vérifie dans le gestionnaire d’événements de Meta, ou en examinant les paramètres des requêtes envoyées.

Si elle est active, des données identifiantes de vos visiteurs partent vers Meta, même transformées en empreintes. C’est un traitement à annoncer et à encadrer, pas un détail de configuration.

Le scan peut-il détecter l’API de conversions ?

Non, et aucun outil public ne le peut. L’API de conversions transmet les événements de votre serveur vers Meta, sans passer par le navigateur du visiteur : rien n’en est observable de l’extérieur.

Nous le disons plutôt que de laisser croire à une vérification complète. Cette partie se contrôle dans votre gestionnaire d’événements Meta et dans la configuration de votre boutique.

Faut-il un consentement distinct pour la publicité et pour la mesure ?

Le consentement doit être demandé pour chacune des fins poursuivies. Mesurer la fréquentation et constituer des audiences publicitaires sont deux fins distinctes, poursuivies par des acteurs différents.

Une bannière qui ne propose qu’un « J’accepte » global couvre mal cette distinction. Séparer les deux catégories est la façon la plus simple d’y répondre. Le guide sur les cookies détaille la granularité attendue.

Sources officielles

Les obligations décrites dans ce guide viennent des organismes québécois responsables. Les recommandations techniques sont celles de Repère et sont signalées comme telles.

Ce guide décrit des pratiques de vérification web. Il ne remplace pas la lecture des textes officiels ni l’accompagnement d’un conseiller juridique pour une situation particulière.

Un pixel tourne-t-il
encore sur votre site ?

Le scan Repère identifie les pixels publicitaires déclenchés au chargement de vos pages.

Scanner mon site gratuitement