Donneespersonnelles.fr

Plateforme de veille en conformite numerique

Vendredi 16 octobre 2026
Marketing Digital

Meta CAPI : documenter les événements envoyés

Meta Conversions API : documentez chaque événement, réduisez les paramètres et vérifiez que les choix commandent aussi les envois serveur.

Avec Meta Conversions API, un événement peut partir de votre serveur alors que le pixel du navigateur reste bloqué. Il faut donc contrôler l’éligibilité de l’envoi, ses champs et les reprises différées dans le circuit serveur lui-même. CAPI n’est ni une exemption de consentement ni un dispositif d’anonymisation. La première ressource à établir est un dictionnaire d’événements validé par le marketing, le développeur et la personne chargée du RGPD.

Ce dictionnaire précise ce que vous transmettez à Meta et pourquoi. Il ne consiste pas à recopier toutes les possibilités offertes par le SDK, l’outil qui aide les développeurs à intégrer l’API.

Commencer par la collecte initiale et la finalité

Distinguez trois opérations : enregistrer une commande pour la traiter, mesurer l’effet d’une campagne publicitaire et rapprocher des informations sur un client. Le contrat nécessaire à la livraison ne justifie pas automatiquement les deux dernières. Les Art. 5(1)(b) et (c) et 6(1) du RGPD exigent une finalité, des données nécessaires et un fondement pour le traitement concerné. Texte du RGPD.

Examinez ensuite l’origine des informations. Si le dispositif lit ou inscrit des informations dans le terminal, l’article 82 de la loi Informatique et Libertés doit être analysé, avec ses exceptions limitées. Le dernier trajet serveur vers serveur n’efface pas les conditions de la collecte précédente. Inversement, toute opération serveur n’est pas, par sa seule existence, une lecture du terminal. Loi Informatique et Libertés, Art. 82.

Pour un suivi publicitaire reposant sur le consentement, la décision de refus ou de retrait doit atteindre le connecteur serveur. Une bannière visuellement correcte ne démontre pas cette liaison. Le guide des cookies et du consentement permet de traiter le choix présenté au visiteur avant de discuter des paramètres techniques.

Lire les champs comme des décisions de collecte

L’objet Event du SDK officiel distingue notamment le nom et l’heure de l’événement, son URL source, son identifiant, les données utilisateur et les données complémentaires. Ces rubriques permettent de situer les informations ; leur présence dans le code n’autorise pas leur emploi dans votre campagne. SDK officiel Meta, Event.

Les données utilisateur peuvent comprendre des coordonnées et des identifiants, mais aussi l’adresse IP, les caractéristiques du navigateur ou des identifiants liés aux cookies fbc et fbp. Identifiez leur origine réelle au lieu de considérer ce bloc comme une enveloppe technique neutre. SDK officiel, UserData.

Enfin, CustomData accueille notamment une valeur, une devise, des informations sur les produits ou une chaîne de recherche. Le caractère « complémentaire » de ces données ne diminue pas leur portée juridique. Une recherche libre ou un nom de produit peut révéler une information que l’entreprise ne souhaite pas transmettre à une plateforme publicitaire. SDK officiel, CustomData.

Le dictionnaire doit ainsi relier chaque champ à son origine, à son utilité et à sa règle d’exclusion. Une copie intégrale du formulaire de commande ou du dossier CRM est un mauvais point de départ : elle embarque des informations sans rapport avec la mesure décidée.

Un dictionnaire renseigné pour un événement d’achat

Prenons une spécification fictive pour un commerce de matériel de randonnée. Il veut mesurer les achats en ligne attribuables à ses campagnes. L’équipe exclut les commentaires de livraison, les demandes au service client et les informations de santé éventuellement saisies librement. Le scénario suppose un consentement valable couvrant le suivi publicitaire envisagé ; il ne prétend pas qu’un achat emporte cet accord.

La fiche suivante est un exemple de décision interne, et non une requête complète prête à envoyer : les exigences de l’API et de l’intégration utilisée restent à appliquer par le développeur.

Rubrique Choix dans la spécification Élément exclu ou condition
Événement Achat confirmé, nommé Purchase Le début du paiement ne doit pas devenir un achat confirmé
Instant Heure réelle de l’achat enregistrée par le système de commande Ne pas remplacer l’heure d’origine par celle d’une nouvelle tentative
Référence technique Identifiant de cet événement, partagé entre les voies retenues Ni courriel ni identifiant permettant directement d’ouvrir le dossier client
Valeur et devise Montant de la commande, avec règle de calcul explicitée, et EUR Pas de commentaire expliquant la situation du client
Page source Adresse utile de confirmation, débarrassée des paramètres confidentiels Aucun jeton de consultation, courriel ou texte libre dans l’URL
Données utilisateur Liste limitée approuvée pour le rapprochement décidé Aucun enrichissement automatique avec les champs supplémentaires du CRM
Décision d’envoi Accord pertinent et état actuel du choix contrôlés avant transmission Refus, retrait ou absence de preuve : événement publicitaire non envoyé

Pour rendre la rubrique « données utilisateur » réellement exploitable, l’équipe doit nommer les champs retenus avant activation. Dans cet exemple, elle envisage uniquement le courriel nécessaire au rapprochement, traité dans le format technique requis, et écarte le téléphone et la date de naissance. Ce choix demande une justification de nécessité et une information adaptée ; il n’est pas présenté comme le minimum universel exigé par Meta. Si l’intégration choisie exige d’autres informations, la fiche revient en discussion : le développeur ne les ajoute pas silencieusement.

L’exemple distingue aussi l’identifiant d’événement du courriel utilisé pour le rapprochement. Ils ne remplissent pas le même rôle. Remplacer un courriel par son empreinte ne rend pas l’opération anonyme lorsque cette empreinte sert précisément à retrouver une correspondance. Le RGPD reste applicable ; réduire l’exposition en clair ne dispense pas de la base légale.

La responsable marketing approuve le besoin ; le développeur décrit les champs réellement produits ; le DPO ou le référent examine la licéité, la minimisation et l’information. Une rubrique encore inconnue reste un point non résolu, sans être remplacée par « aucune donnée personnelle ».

Contrôler aussi les données cachées dans les valeurs

Un champ apparemment anodin peut contenir une information sensible. Une référence de produit, le titre d’une page ou une demande au service client peut révéler la santé d’une personne. Lorsque des données de l’Art. 9(1) sont concernées, une simple base de l’Art. 6 ne suffit pas : il faut aussi une exception pertinente de l’Art. 9(2). Cela ne signifie pas qu’il serait opportun ou autorisé contractuellement de les adresser à Meta.

Dans la spécification retenue, les textes libres sont donc exclus. Les références de catalogue sont examinées avant leur ajout. Si l’entreprise ne peut expliquer ce qu’un paramètre révèle, elle suspend ce paramètre ou l’événement concerné le temps de résoudre le problème. Elle ne se contente pas de renommer le champ.

Contrôlez les paramètres UTM et les données présentes dans les liens, puis les transformations du connecteur. Une URL nettoyée côté navigateur peut être remplacée côté serveur par une autre URL issue du dossier de commande. Le dictionnaire doit décrire la valeur à la sortie finale.

Refus, retrait et file d’attente : décider au bon moment

La règle doit être exécutée au point qui décide l’envoi à Meta. Transmettre le choix au serveur est nécessaire, mais insuffisant si le traitement différé conserve uniquement un ancien état « accordé ».

Une séquence illustre cette difficulté : un achat éligible entre dans une file à 10 h ; le client retire son accord à 10 h 05 ; la tâche d’envoi reprend à 10 h 10. Dans le dispositif fondé sur le consentement décrit ici, le retrait doit empêcher cette transmission encore non réalisée. Le traitement antérieur licite ne devient pas rétroactivement illicite, mais cette règle ne permet pas de poursuivre indéfiniment les transmissions. RGPD, Art. 7(3).

Le développeur prévoit donc un contrôle actualisé ou un mécanisme équivalent qui neutralise les événements devenus inéligibles. Une reprise après panne, un import manuel ou un ancien connecteur doit respecter la même décision. S’il n’est pas possible de propager le retrait avec fiabilité, désactivez l’envoi concerné jusqu’à correction et contrôle du circuit.

Ne confondez pas cette suspension avec le paramètre opt_out. Dans le SDK officiel cité, celui-ci limite l’usage d’optimisation publicitaire tout en conservant l’attribution. Il ne constitue donc pas, à lui seul, un blocage de la transmission ni une réponse complète à un refus de ce traitement.

Déduplication et contrôle de réception

Le SDK décrit l’utilisation de event_id avec event_name pour rapprocher les événements navigateur et serveur. La déduplication évite un double comptage ; elle ne rend pas licites deux envois qui ne devaient pas avoir lieu. Définissez une référence cohérente par événement et examinez séparément l’autorisation de chaque voie.

Le SDK prévoit également test_event_code pour vérifier la réception dans l’outil d’événements de test. Utilisez un jeu fictif adapté et protégez les accès de l’équipe. Un retour de réception est une observation technique, pas un avis de conformité. SDK officiel, EventRequest.

La réception à organiser doit couvrir un événement autorisé, un refus, un retrait avant reprise et les deux voies lorsqu’un pixel est conservé. Pour chaque situation, comparez la fiche approuvée, le contenu réellement transmis et les traces de traitement. Ne déduisez pas l’absence d’envoi serveur du seul panneau réseau du navigateur.

Si le paramétrage passe par GTM, l’audit du modèle de balise complète cette lecture. Pour les résultats commerciaux importés depuis le CRM, examinez également l’éligibilité des conversions hors ligne.

Garder une preuve utile sans dupliquer les dossiers clients

Conservez la version du dictionnaire, les décisions sur les champs, le responsable du flux et les observations nécessaires à sa réception. Fixez aussi la durée et les accès des journaux techniques. Garder toutes les requêtes contenant les identifiants dans un fichier de diagnostic crée une autre copie à protéger.

Avant activation, le dossier doit également couvrir les rôles des intervenants, les conditions contractuelles réellement applicables, l’information des personnes et l’encadrement des transferts éventuels. Le présent dictionnaire ne remplace pas cet examen et ne certifie aucun contrat Meta particulier. Si un point matériel reste inconnu, documentez-le et résolvez-le avant d’ouvrir le flux correspondant.

Ce qu’il faut retenir

  • Chaque champ doit avoir une origine, une utilité et une règle d’exclusion.
  • Le consentement doit commander les envois serveur et leurs reprises.
  • Hachage, déduplication et réception technique répondent à des questions différentes de la licéité.
  • Le dictionnaire décrit les valeurs effectivement envoyées, pas les seules intentions du marketing.

FAQ

Peut-on envoyer l’événement sans courriel ?

Le besoin dépend de l’intégration et du rapprochement retenus. Ne collectez pas davantage par réflexe : faites préciser les exigences techniques et retenez une combinaison justifiée et licite. Si elle n’est pas disponible, renoncez au flux concerné.

Faut-il réexpédier tous les anciens événements après une panne ?

Non. Réexaminez leur éligibilité, les retraits intervenus et les contraintes techniques applicables. Une file d’attente ne constitue ni une nouvelle autorisation ni une durée de conservation illimitée.

Supprimer le pixel suffit-il à arrêter CAPI ?

Non si un connecteur serveur indépendant continue d’envoyer. Identifiez ses déclencheurs, ses tâches différées et ses imports, puis contrôlez chacun des circuits actifs.

Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.

Thiébaut Devergranne est docteur en droit et fondateur de donneespersonnelles.fr. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données personnelles.

Thiébaut Devergranne
Docteur en droit des nouvelles technologies (Paris II)

Docteur en droit, Thiébaut Devergranne travaille en droit des nouvelles technologies et en protection des données personnelles depuis plus de 20 ans. Il a accompagné des centaines d'organisations dans leur mise en conformité RGPD et est le fondateur de Legiscope, logiciel de conformité RGPD.

En savoir plus sur l'auteur →