# La Conversions API de Meta : ce que c’est, et ce qui a changé

La Conversions API (CAPI) envoie à Meta les événements de votre site depuis un serveur, en complément du pixel du navigateur. Elle ne remplace pas le pixel, elle le double, et les deux doivent être dédoublonnés. Pour la génération de leads, une seconde intégration renvoie les étapes du CRM. Ni l’une ni l’autre ne dispense du consentement.

Guide · Écrit par l’IA, relu par David Solito · Publiée le 7 novembre 2026 · 5 min de lecture

La Conversions API de Meta (CAPI) permet d’envoyer à Meta les actions réalisées sur votre site depuis un serveur, et non plus seulement depuis le navigateur du visiteur. Elle complète le pixel Meta : quand le navigateur bloque le pixel, l’événement envoyé par le serveur peut encore arriver.

Nous avions présenté la CAPI en juin 2024 comme « la quick win à activer ». [8](#source-8) L’idée reste juste, mais trois choses ont changé depuis : la façon de mesurer la qualité d’une installation, l’arrivée d’une intégration distincte pour les étapes du CRM, et la lecture qu’on peut faire du consentement. Cette note remplace l’article de 2024.

## Le pixel et l’API : deux transports pour les mêmes événements

Le pixel est un script chargé dans la page. Il voit ce que fait le visiteur et l’envoie à Meta depuis le navigateur. Il dépend donc du navigateur : un bloqueur de publicité, une restriction de Safari ou un script qui ne s’est pas chargé, et l’événement se perd.

La CAPI envoie le même type d’événement depuis votre serveur, ou depuis un serveur de tracking. Meta recommande d’utiliser les deux ensemble, ce qu’elle appelle une « configuration redondante ». [1](#source-1)

Cette redondance impose une règle : chaque événement envoyé deux fois doit pouvoir être reconnu comme le même. Meta propose pour cela l’identifiant d’événement : le pixel et le serveur envoient, pour un même formulaire, le même event_id et le même nom d’événement. Meta ne garde alors qu’une conversion. Le dédoublonnage ne fonctionne que si le second événement arrive dans les 48 heures qui suivent le premier. [1](#source-1) Sans lui, chaque formulaire compte double, et l’algorithme apprend sur des chiffres faux.

## La qualité de la correspondance

Un événement envoyé par le serveur n’est utile que si Meta peut le relier à une personne. Meta note cette capacité dans le gestionnaire d’événements, par un score de qualité de correspondance (Event Match Quality).

Peter Šutarík, consultant en tracking, classe en juin 2026 les paramètres selon leur poids : l’adresse e-mail hachée d’abord, puis le téléphone haché, les cookies _fbp et _fbc déposés par le pixel (le second contient l’identifiant du clic), l’adresse IP et le navigateur du visiteur, et un identifiant client interne haché. [4](#source-4) Selon lui, l’e-mail haché suffit souvent à faire passer le score de 4 à 7, et sans les cookies _fbp et _fbc, Meta ne peut pas relier l’événement du serveur à la visite. [4](#source-4)

Il cite aussi un cas où les conversions déclarées ont augmenté de 38 % et le coût par achat baissé d’un cinquième en trois semaines. [4](#source-4) C’est un cas de commerce en ligne, rapporté par celui qui a fait l’installation ; il montre l’ordre de grandeur possible, pas un résultat à attendre.

## Les leads : une seconde intégration, pour le CRM

Pour la génération de leads, l’événement utile n’est pas le formulaire, mais ce qu’il devient : le rendez-vous, la proposition, le contrat. Meta propose pour cela la Conversions API pour CRM, une intégration distincte de celle du site, avec ses propres paramètres, alimentée par le CRM et non par le serveur web. [2](#source-2)

Elle sert l’objectif « leads qualifiés » des publicités à formulaire instantané. Meta en donne les repères : environ 200 leads par mois, un envoi au moins quotidien, une étape visée atteinte dans les 28 jours et par 1 à 40 % des leads. [2](#source-2) Le seuil de 200 leads est une recommandation, pas une condition : aucune quantité minimale n’est exigée pour installer l’intégration. [3](#source-3) Meta annonce une baisse moyenne de 19 % du coût par lead qualifié, mesurée sur un test de 567 annonceurs en janvier 2025. [3](#source-3) C’est le chiffre du vendeur.

Pour les formulaires du site, Meta teste une option qui permettrait d’optimiser sur un événement plus tardif ; Jon Loomer la décrit en octobre 2026 et précise qu’elle n’a pas encore de documentation officielle. [6](#source-6) Le choix des étapes, les délais et l’identifiant à garder dans le CRM sont détaillés dans la note [Relier votre CRM à Google, Meta et LinkedIn](/fr/memory/conversions-hors-ligne/).

## Le consentement : le serveur ne change pas la règle

Envoyer un événement depuis un serveur ne le soustrait pas au consentement. Deux raisons l’expliquent.

D’abord, la plupart des installations partent toujours du navigateur : un script envoie l’événement au serveur, qui le transmet à Meta. Dans ses lignes directrices de 2024 sur l’article 5(3) de la directive ePrivacy, le Comité européen de la protection des données (EDPB) estime que le fait de faire envoyer par le navigateur des informations à un tiers, par exemple par un pixel, relève de cet article, et donc du consentement. [7](#source-7) Le même raisonnement vaut quand le navigateur envoie l’événement à un serveur intermédiaire : c’est notre lecture, aucune autorité ne l’a tranché pour la CAPI elle-même.

Ensuite, l’événement envoyé à Meta contient des données personnelles : e-mail haché, adresse IP, identifiant de clic. CookieBeam le formule simplement : si le visiteur a refusé le marketing, la conversion ne doit pas quitter votre serveur, qu’elle passe par le navigateur ou non. [5](#source-5)

Un piège est fréquent. Meta a ajouté à son pixel des commandes de consentement ; selon CookieBeam, elles ne s’appliquent pas à la CAPI, qui doit être réglée de son côté. [5](#source-5) Une installation où le pixel respecte le refus et où le serveur continue d’envoyer paraît conforme ; elle ne l’est pas. La note [Consent Mode](/fr/memory/consent-mode-v2/) traite du réglage côté Google.

## Ce qu’il faut vérifier sur une installation existante

Le dédoublonnage

Le même event_id part du pixel et du serveur pour chaque événement envoyé deux fois.

Les paramètres

E-mail et téléphone hachés quand ils existent, cookies _fbp et _fbc, IP et navigateur transmis par le serveur.

Le consentement

Un refus bloque aussi l’envoi par le serveur.

Les événements

Un formulaire envoyé ne s’appelle pas « achat », et le nom est le même des deux côtés.

Pour les leads

L’identifiant du lead Meta est gardé dans le CRM, et les étapes sont renvoyées au moins une fois par jour.

La note [Audit du tracking des leads](/fr/memory/audit-tracking/) reprend ces contrôles pour toutes les plateformes.

## Ce qu’il faut retenir

- La CAPI double le pixel, elle ne le remplace pas ; les deux doivent être dédoublonnés par un identifiant commun, dans les 48 heures.

- Sa valeur dépend des paramètres transmis : l’e-mail haché et les cookies du pixel comptent le plus.

- Pour les leads, la Conversions API pour CRM renvoie les étapes de vente ; 200 leads par mois sont conseillés, pas exigés.

- Le serveur ne dispense pas du consentement, et le réglage de consentement du pixel ne s’applique pas à l’API.

Pour mettre en place et vérifier cette mesure avec votre équipe, découvrez notre accompagnement en [mesure et tracking](/fr/mesure-et-tracking/).

Sources consultées le 13 octobre 2026.