Référencement SEO

Pixel Meta et Conversion API : comment ça fonctionne

Vous lancez Facebook Ads ou Instagram Ads et votre agence (ou un forum) vous dit qu'il faut « installer le pixel ET la Conversion API ».

16 mars 2026 · 11 min de lecture
Pixel Meta et Conversion API : comment ça fonctionne

Vous lancez Facebook Ads ou Instagram Ads et votre agence (ou un forum) vous dit qu’il faut « installer le pixel ET la Conversion API ». Deux noms pour ce qui semble faire la même chose. La confusion est normale : ce sont deux méthodes complémentaires, pas concurrentes.

La réponse courte : Le pixel Meta (anciennement Facebook Pixel), c’est un script JavaScript dans votre site qui envoie les actions utilisateurs (page vue, achat, formulaire soumis) vers Facebook. La Conversion API, c’est le même suivi, mais envoyé depuis votre serveur directement aux serveurs de Meta, sans passer par le navigateur. Les deux ensemble forment la configuration recommandée en 2026 : elle couvre ce que le pixel seul ne capte plus depuis iOS 14.5 et les blocages navigateur.

Ce qu’il faut comprendre

Depuis 2021, Apple a lancé l’App Tracking Transparency (ATT) avec iOS 14.5 : qui impose une pop-up explicite pour autoriser le tracking. La majorité des utilisateurs refusent. Safari, Firefox et Brave bloquent aussi, par défaut, une partie des scripts publicitaires tiers (dont le pixel Meta).

Résultat : un pixel classique ne capte plus toutes les conversions. Sur une PME typique, ça se traduit par :

  • Pas de signal quand un utilisateur iOS clique sur une pub Instagram puis achète quelques heures plus tard
  • Tracking incomplet pour les utilisateurs Safari sur desktop
  • Pertes de conversions reconnues : l’algorithme Meta optimise alors à l’aveugle

La Conversion API (CAPI) contourne ce problème en envoyant les événements depuis votre serveur : côté backend : plutôt que depuis le navigateur. Le serveur n’est pas affecté par les bloqueurs, iOS ATT, ni les extensions de navigateur.

Sur les comptes Meta qu’on récupère en audit, la majorité n’ont que le pixel classique installé. Depuis iOS 14.5 et les restrictions des navigateurs, une part substantielle des conversions ne remonte plus jusqu’à Facebook. Le résultat est invisible dans les rapports : les chiffres existent toujours, ils sont juste partiels : mais bien réel dans le coût par acquisition qui grimpe lentement, mois après mois.

Notre position : la majorité des comptes Meta Ads qu’on récupère sont mal configurés sur le tracking : pas sur la créa, pas sur le ciblage, sur le tracking. Avant iOS 14, le pixel seul faisait le travail. Aujourd’hui, sans CAPI, on tend de la conjecture à l’algorithme à la place de données. Le pixel-only Meta tracking a perdu une fidélité de signal massive après 2021, et la majorité des PME continuent comme si rien n’avait changé. Tant que ce socle est cassé, optimiser le budget, la créa ou les audiences est un exercice de précision sur une mire qui bouge.

Pixel vs Conversion API : les 4 différences clés

Aspect Pixel Meta Conversion API
Où ça tourne Navigateur du visiteur Votre serveur
Bloqué par iOS ATT Oui Non
Bloqué par bloqueurs de pub Oui Non
Effort d’installation Simple (snippet JS + GTM) Modéré (API à appeler, clés)

Les deux ne se remplacent pas : ils se complètent. Avec les deux actifs, Meta utilise la déduplication (via un event_id unique) pour ne pas compter deux fois le même achat.

Concrètement, voici comment configurer

Étape 1 : Installer le pixel Meta

  1. Events Manager (Meta Business) → Connect Data Sources → Web → Create a pixel
  2. Copie le snippet JS dans le de votre site (plugin WordPress ou GTM)
  3. Configure les événements standard : PageView (automatique), Lead, Purchase, InitiateCheckout, etc.
  4. Teste avec l’extension Chrome Meta Pixel Helper

Étape 2 : Activer la Conversion API

Deux chemins :

A. Via une intégration partenaire (le plus simple) Shopify, WooCommerce, Wix, Squarespace ont une intégration CAPI native. Activation en 3 clics dans les réglages de la boutique. Events Manager → Partner Integrations → choisir sa plateforme.

B. Via Conversion API Gateway (Meta fournit un serveur hébergé) Meta héberge un proxy serveur qui reçoit les événements JavaScript du pixel et les réémet côté serveur. Gratuit, sans code à écrire. Events Manager → Conversions API → Gateway setup.

C. Manuel (pour dev sur-mesure) Appels HTTP POST vers https://graph.facebook.com/v18.0/{pixel_id}/events avec payload JSON. Nécessite un développeur ; documentation complète côté Meta.

Étape 3 : Vérifier la déduplication

Events Manager → Overview → vérifier que le score « Event Match Quality » est à 7/10 ou plus, et que le pourcentage « Deduplicated events » est > 80 %. Si c’est 0 %, les pixel et CAPI envoient des événements avec des IDs différents : la déduplication ne fonctionne pas.

Ce qui ne marche plus en 2026 sans CAPI

  • Le remarketing sur audiences iOS. Sans CAPI, les utilisateurs iOS qui visitent votre site ne sont pas reconnus quand ils rouvrent Facebook ou Instagram.
  • L’attribution multi-touch. Si un utilisateur voit une pub, reçoit un courriel, puis revient directement : le pixel seul perd la trace d’une part importante de ce parcours.
  • L’optimisation algorithmique serrée. Meta a besoin d’un volume de conversions hebdomadaire par ad set pour optimiser correctement. Sans CAPI, ce seuil est rarement atteint pour une PME.

Cas limites : quand la configuration semble propre mais ne l’est pas

Trois patterns d’échec qu’on rencontre régulièrement en audit, qui ne sont presque jamais flaggés par les outils de vérification automatiques.

Cas 1 : Échec de déduplication par mismatch d’event_id

Le pixel envoie un événement Purchase côté navigateur avec event_id = "abc-123". Au même moment, le serveur envoie le même Purchase à la CAPI avec event_id = "Purchase_1714234567". Les deux IDs sont différents : Meta n’a aucun moyen de savoir que c’est le même événement. La déduplication échoue silencieusement, les conversions sont comptées en double, l’algorithme apprend sur des données gonflées.

Symptôme : dans Events Manager → Overview, le pourcentage « Deduplicated events » est à 0 % alors que les deux sources sont actives. Le score Event Match Quality peut paraître normal.

Fix : générer un seul event_id côté serveur (UUID v4 ou hash de la transaction + horodatage), le passer au pixel via Data Layer et à l’appel CAPI dans le même flux. Une seule source de vérité par événement.

Cas 2 : Données utilisateur hashées au mauvais format

La CAPI accepte des données utilisateur (email, téléphone) mais exige un format strict : SHA-256, en minuscules, sans espaces. Une erreur fréquente : envoyer SHA256("Info@Exemple.CA") au lieu de SHA256("info@exemple.ca"). Meta ne peut pas matcher le hash avec son index : l’utilisateur n’est pas reconnu, le Match Quality chute, et les rapports montrent des conversions « non attribuées ».

Pour les téléphones, c’est pire : il faut le format E.164 sans espaces, sans tirets, sans parenthèses. (XXX) XXX-XXXX doit devenir +1XXXXXXXXXX avant le hash.

Fix : une fonction de normalisation appliquée systématiquement avant chaque hash (voir code ci-dessous). Tester avec les outils de vérification CAPI de Meta : un hash valide n’est pas un hash correct.

Cas 3 : Endpoint serveur mis en cache par un CDN

Si l’endpoint qui appelle la CAPI (par exemple /wp-json/votre-namespace/capi-event) tombe par erreur sous une règle de cache CDN agressive (LiteSpeed Cache, Cloudflare full-page cache mal configuré), le serveur peut retourner une réponse mise en cache au lieu d’exécuter l’appel. Les événements sont perdus, sans erreur visible.

Fix : exclure explicitement les routes CAPI du cache au niveau du CDN et au niveau du plugin de cache WordPress. Vérifier régulièrement les en-têtes de réponse : un cf-cache-status: HIT sur un endpoint d’événement est un signal d’alarme immédiat.

Code réel : payload CAPI côté serveur

Exemple d’appel CAPI minimal en PHP (extrait d’un endpoint REST WordPress), avec génération propre d’event_id et hashing conforme.

<?php
// Normalisation + hashing SHA-256 conforme aux exigences Meta
function rn_hash_capi($value) {
    if (empty($value)) return null;
    $clean = strtolower(trim((string) $value));
    return hash('sha256', $clean);
}

// Téléphone : format E.164 avant hash
function rn_normalize_phone($phone) {
    $digits = preg_replace('/\D+/', '', (string) $phone);
    if (strlen($digits) === 10) $digits = '1' . $digits; // CA/US
    return $digits ? '+' . $digits : null;
}

function rn_send_capi_event($order) {
    $pixel_id     = 'YOUR_PIXEL_ID';
    $access_token = getenv('META_CAPI_TOKEN'); // jamais en dur
    $event_id     = wp_generate_uuid4();        // une seule source de vérité

    $email = rn_hash_capi($order['email']);
    $phone = rn_hash_capi(rn_normalize_phone($order['phone']));

    $payload = [
        'data' => [[
            'event_name'     => 'Purchase',
            'event_time'     => time(),
            'event_id'       => $event_id, // partagé avec le pixel via Data Layer
            'action_source'  => 'website',
            'event_source_url' => $order['source_url'],
            'user_data' => [
                'em' => [$email],
                'ph' => [$phone],
                'client_ip_address' => $_SERVER['REMOTE_ADDR'] ?? '',
                'client_user_agent' => $_SERVER['HTTP_USER_AGENT'] ?? '',
                'fbp' => $order['fbp'] ?? null, // cookie pixel _fbp
                'fbc' => $order['fbc'] ?? null, // cookie pixel _fbc
            ],
            'custom_data' => [
                'currency' => 'CAD',
                'value'    => (float) $order['total'],
            ],
        ]],
    ];

    $response = wp_remote_post(
        "https://graph.facebook.com/v18.0/{$pixel_id}/events?access_token={$access_token}",
        [
            'timeout' => 5,
            'headers' => ['Content-Type' => 'application/json'],
            'body'    => wp_json_encode($payload),
        ]
    );

    return ! is_wp_error($response);
}

Trois points non négociables dans ce snippet :

  1. event_id est généré une fois côté serveur et partagé avec le pixel via Data Layer : c’est ce qui permet la déduplication (Cas 1).
  2. rn_hash_capi() applique strtolower + trim avant SHA-256 : sans ça, Match Quality s’effondre (Cas 2).
  3. Le token CAPI vit dans une variable d’environnement, jamais committé au dépôt. Une rotation est nécessaire dès qu’un développeur quitte l’équipe.

Loi 25 et CAPI : le hashing n’est pas une exemption

C’est une confusion fréquente : « les données sont hashées, donc anonymisées, donc Loi 25 ne s’applique pas. » Faux.

Sous la Loi 25 (et le Règlement européen équivalent qui sert souvent de référence à la CAI), un hash n’est pas une anonymisation : c’est une pseudonymisation. Le hash reste réversible par recoupement (un email courant comme info@exemple.ca peut être devinné par dictionnaire en quelques secondes), et la finalité du transfert vers Meta reste l’identification d’un individu pour lui montrer une publicité ciblée. La donnée est donc encore une « renseignement personnel » au sens de la loi.

Conséquences pratiques pour une PME québécoise qui active la CAPI :

  • Consentement préalable obligatoire : la bannière de consentement doit explicitement mentionner que des données utilisateur (courriel, téléphone) seront transmises à Meta à des fins publicitaires, avant le premier appel CAPI.
  • Politique de confidentialité mise à jour : mention explicite de Meta comme destinataire de données personnelles, finalité, durée de conservation, mécanismes de retrait.
  • Consent Mode v2 côté pixel + flag côté CAPI : quand le consentement est refusé, le pixel doit être désactivé et l’appel CAPI ne doit pas partir. Avoir un pixel respectueux du consentement et un serveur qui envoie quand même les événements vers Meta est une non-conformité claire.
  • Position de la CAI sur le hashing : la Commission d’accès à l’information considère qu’un transfert de données pseudonymisées vers un tiers étranger (Meta hébergé hors Canada) reste soumis à l’article 17 de la Loi 25 sur la communication hors Québec. Une évaluation des facteurs relatifs à la vie privée (EFVP) peut être exigée pour les organismes publics et est recommandée pour les PME qui traitent des volumes significatifs.

À éviter

  • Installer le pixel mais pas la CAPI. C’était suffisant en 2019. En 2026, c’est laisser une part substantielle des conversions dans l’ombre.
  • Mettre les deux actifs sans déduplication. Les achats sont comptés en double, les chiffres gonflés, et l’algorithme apprend sur des données fausses. Toujours configurer event_id identique entre pixel et CAPI (voir Cas 1).
  • Activer la CAPI sans bannière de consentement Loi 25. Le hashing n’est pas une exemption : voir la section dédiée.
  • Oublier de passer les paramètres utilisateur avancés. La CAPI permet d’envoyer email, téléphone, nom hashés → Meta peut alors matcher les conversions à des comptes utilisateur. Sans ces paramètres, le Match Quality chute et la CAPI perd une part importante de sa valeur. Et attention au format : voir Cas 2.

Sources

Voir aussi

Vous voulez améliorer votre visibilité en ligne ?

Un audit gratuit de votre site — sans engagement, sous 48 h.

Obtenir mon audit gratuit →