Votre dashboard Meta genere par IA ment avec aplomb

Ça prend une vingtaine de minutes aujourd'hui. Vous connectez Claude à votre compte publicitaire Meta via un serveur MCP, vous lui demandez de vous construire un dashboard de reporting, et il en sort quelque chose de réellement beau : des graphiques propres, un narrateur sûr de lui qui explique pourquoi le ROAS a baissé mardi, un retour blended de 4,2 qui se recalcule chaque matin tout seul. On dirait que le futur de l'analytics a débarqué sur votre laptop en un week-end.

Il n'y a qu'un seul problème, et il n'est pas mineur. Le chiffre n'a jamais été réel. Et maintenant il se met à jour automatiquement, emballé dans une interface si soignée que le remettre en doute revient à douter d'une calculatrice.

Ceci n'est pas un plaidoyer contre le fait de construire avec l'IA. Je ship avec Claude Code tous les jours, et un LLM branché sur une API est l'un des outils à plus fort levier qu'un marketeur ait eus depuis dix ans. C'est un plaidoyer sur l'endroit où vous le pointez. Il y a exactement un endroit dans votre stack où vous ne laissez pas un modèle autocompléter la réponse : le chiffre dont dépendent vos décisions de budget. Branchez un agent sur la Marketing API de Meta et demandez-lui de « construire un dashboard », et vous n'avez pas mesuré votre publicité. Vous avez automatisé l'argumentaire de vente de la plateforme, vous lui avez donné une bibliothèque de graphiques, et vous avez supprimé la dernière friction qui aurait pu vous faire douter.

Voici ce qui est au menu. D'abord, ce qui se passe réellement, mécaniquement, quand vous branchez l'API Meta sur un LLM. Ensuite, pourquoi le chiffre qu'il renvoie était empoisonné avant même que l'agent y touche. Puis la partie dont presque personne ne parle : les deux biais cognitifs bien documentés qui rendent un dashboard généré par IA plus dangereux que le tableur bordélique qu'il remplace. Et enfin, comment bien faire, parce que la réponse n'est pas « arrêtez l'IA », c'est « ancrez la donnée d'abord, affichez-la en dernier ».

Ce que vous avez réellement construit en connectant Claude à Meta

Le Model Context Protocol, qu'Anthropic a introduit en novembre 2024, est une vraie bonne idée. C'est un standard ouvert pour laisser un assistant IA atteindre les systèmes où vivent vos données, décrit, à juste titre, comme un « port USB-C pour l'IA ». Des serveurs MCP construits par la communauté, qui enveloppent la Marketing API de Meta, existent désormais, et ils font exactement ce qu'on espère : un agent peut tirer la dépense, les impressions, les clics et les conversions attribuées en langage naturel, puis les assembler dans la vue que vous demandez.

Restez une seconde sur le mécanisme, parce que le mécanisme est toute l'histoire. L'agent n'audite pas Meta. Il en est incapable. Il n'a aucune source de vérité indépendante contre laquelle auditer. Il appelle l'endpoint Insights, reçoit un payload JSON de chiffres, et restitue fidèlement ces chiffres dans le dashboard que vous avez réclamé. Le LLM est un afficheur parfait et obéissant de tout ce qu'on lui donne. Sa fluidité, la chose qui rend le résultat intelligent en apparence, s'applique entièrement à la présentation, pas à la vérification.

Donc la qualité de votre dashboard est plafonnée, exactement, à la qualité du chiffre qui sort de l'API. L'agent ne peut pas relever ce plafond. Il peut seulement rendre tout ce qui se trouve en dessous plus autoritaire. Garbage in, garbage out est une vieille idée. Ce qui est nouveau, c'est garbage in, garbage out à l'échelle, sur un planning, avec un narrateur qui explique le garbage d'une voix calme et compétente.

Le chiffre que renvoie l'API n'a jamais été neutre

Maintenant la partie inconfortable. Les conversions que renvoie la Marketing API de Meta ne sont pas un décompte neutre de ce qui s'est passé. Ce sont le décompte par Meta des conversions que Meta crédite aux publicités Meta, généré par l'entreprise même qui vous vend les publicités, avec les règles d'attribution que cette entreprise préfère. Trois faits structurels rendent ça pire qu'il n'y paraît.

Premièrement, la fenêtre d'attribution. Si votre requête API ne précise pas action_attribution_windows, l'endpoint Insights retombe par défaut sur une fenêtre de 7 jours après clic (le chiffre de conversion phare de la plateforme combine 7 jours après clic et 1 jour après vue). Ce seul réglage par défaut décide quelles ventes sont créditées à Meta. Un achat survenu six jours après qu'une personne a cliqué sur une publicité, puis vous a retrouvé via Google et le SMS d'un ami, est compté, en totalité, comme une conversion Meta. Votre agent ne sait pas qu'il faut questionner la fenêtre. Il rapporte simplement le chiffre que la fenêtre a produit.

Deuxièmement, une part croissante de ces conversions est modélisée, pas observée. Depuis l'effondrement post-ATT du tracking déterministe, les plateformes estiment statistiquement les conversions qu'elles ne voient plus une à une. Google documente ouvertement cela sous le nom de « conversions modélisées », et Meta applique la même logique via son stack de mesure post-ATT. Donc une partie de la « donnée » sur laquelle repose votre dashboard n'est pas de la donnée. C'est l'estimation machine, par la plateforme, de ce qu'elle pense qu'il s'est probablement passé, présentée à votre agent comme un entier dur.

Troisièmement, chaque plateforme se fait ça à elle-même, en isolation, et c'est pourquoi les chiffres ne se recoupent pas entre canaux. Un même acheteur touché par Meta, Google et TikTok à l'intérieur de leurs fenêtres respectives est compté une fois par chacune. Aucune plateforme ne déduplique contre les autres, parce qu'aucune plateforme ne voit les autres. Additionnez les conversions que vos trois dashboards de plateforme revendiquent, et le total dépassera le nombre de ventes que votre banque a réellement vues. L'arithmétique n'est pas subtile, elle est structurelle.

À quel point est-ce faux ? La meilleure preuve dont on dispose est expérimentale. Gordon, Zettelmeyer, Bhargava et Chapsky ont mené quinze grandes expériences randomisées chez Facebook, 500 millions d'observations utilisateur-expérience sur 1,6 milliard d'impressions, et comparé la logique observationnelle de la plateforme au vrai lift randomisé. Pour les achats, l'estimation observationnelle se trompait d'environ un facteur trois. Dans une campagne, la comparaison naïve exposés contre non-exposés affichait un lift de 316 % là où le vrai lift randomisé était de 73 %, plus de quatre fois trop élevé. Dans une autre, la méthode observationnelle rapportait un lift de 1 306 % contre un vrai lift de 2,4 %. Et l'erreur n'était même pas fiablement dans le même sens, ce qui veut dire qu'on ne peut pas la corriger avec une décote mentale. C'est ce chiffre qui circule dans le tuyau jusqu'à votre agent.

Lewis et Rao ont posé le problème plus profond, proprement : dans vingt-cinq grandes expériences publicitaires de terrain, les ventes individuelles étaient si volatiles par rapport à la dépense pub que même des expériences avec des millions de sujets laissaient l'intervalle de confiance sur le ROI large de plus de 100 points de pourcentage. Si une expérience contrôlée qui coûte de l'argent réel ne parvient souvent pas à distinguer une excellente campagne d'une campagne qui perd de l'argent, un dashboard observationnel, qui lit le chiffre auto-noté de la plateforme, n'a aucune chance. C'est l'écart entre le ROAS rapporté et le ROAS réel, et le Conversions API ne le comble pas. Un front-end IA ne le comble pas non plus. Il le repeint.

Pourquoi le dashboard IA est pire que le tableur qu'il remplace

Voici l'affirmation qui compte, et elle est contre-intuitive : faire passer ce chiffre par un LLM ne préserve pas seulement l'erreur. Ça vous rend plus susceptible d'agir dessus. Deux des résultats les plus répliqués de l'étude du jugement humain expliquent pourquoi.

Le premier est l'automation bias. Skitka, Mosier et Burdick l'ont défini précisément comme la tendance à utiliser l'automatisation comme un substitut heuristique à la recherche et au traitement vigilants de l'information. En clair : quand une machine nous tend une réponse, on arrête de chercher. On s'en remet à elle. Ce n'est pas un travers de gens négligents. Goddard, Roudsari et Wyatt ont confirmé, dans une revue systématique, que l'automation bias est réel, mesuré et récurrent même chez des cliniciens formés utilisant des systèmes d'aide à la décision, des gens dans un domaine à fort enjeu qui avaient toutes les raisons de rester sceptiques et qui se sont quand même remis à des conseils automatisés erronés. Parasuraman et Riley avaient nommé ce mode de défaillance « misuse », la sur-confiance dans l'automatisation, il y a presque trente ans. Un agent conversationnel qui produit un dashboard fini, c'est l'automation bias servi sous sa forme la plus séduisante.

Le second est l'illusion of explanatory depth, l'illusion de profondeur explicative. Rozenblit et Keil ont montré que les gens surestiment dramatiquement à quel point ils comprennent comment les choses fonctionnent, et surtout, que l'illusion est la plus forte pour la connaissance explicative et causale, exactement le type de connaissance qu'un narrateur IA simule quand il vous dit « le ROAS a chuté parce que votre audience de retargeting a saturé ». Lisez cette phrase et vous avez le sentiment de comprendre le mécanisme. Vous ne le comprenez pas. Personne n'a vérifié si la saturation du retargeting est ce qui s'est passé, ni même si les conversions sous-jacentes sont réelles. L'histoire causale fluide a fourni le sentiment de comprendre sans aucune de la substance.

Empilez les deux et vous obtenez le piège. L'illusion de profondeur explicative fabrique le sentiment que vous comprenez le chiffre. L'automation bias supprime l'impulsion de le vérifier. Le dashboard est désormais beau, conversationnel et auto-actualisé, et chacune de ces propriétés baisse votre garde au moment précis où le chiffre sous-jacent mérite le moins votre confiance. C'est l'esthétique de la rigueur sans la substance de la rigueur, et c'est la plus coûteuse, parce qu'elle vous coûte le doute qui vous protégeait.

Le vieux tableur était moche, et sa laideur était une fonctionnalité. À coller les chiffres à la main, vous voyiez les coutures. Vous vous souveniez que la colonne Meta et la colonne Shopify ne se réconciliaient jamais tout à fait. La friction maintenait en vie une petite voix de suspicion, saine. Toute la proposition de valeur du dashboard IA est de supprimer cette friction, et la friction était porteuse. Une IA n'a pas rendu votre dashboard plus juste. Elle a rendu votre chiffre faux plus rapide, plus joli, et bien plus difficile à mettre en doute.

Il y a une défaillance plus étroite et plus technique par-dessus la défaillance cognitive. Les LLM commettent encore des erreurs d'arithmétique et d'agrégation avec aplomb. Des travaux de benchmark récents sur le calcul en conditions réelles ont trouvé que, parmi les erreurs commises par les modèles, la grande majorité étaient des erreurs de calcul ou de précision et d'arrondi, et d'autres travaux de benchmark sur le raisonnement sur tableaux montrent que les modèles se dégradent et désalignent lignes et colonnes quand on leur demande de raisonner sur de la donnée structurée. Un agent qui écrit une nouvelle requête à chaque session produit aussi des chiffres non reproductibles : posez la même question lundi et jeudi, et le modèle peut définir la métrique différemment, choisir une autre fenêtre, ou agréger une autre colonne, sans aucune traçabilité ni piste d'audit pour vous dire quel run avait raison. Rien de tout cela n'est rédhibitoire pour l'outillage IA en général. C'est rédhibitoire pour laisser un agent posséder silencieusement la définition du chiffre par lequel vous pilotez la dépense.

Hors sol par construction

Il y a une expression utile pour ça : hors sol, littéralement cultivé sans racines dans la terre. C'est la description exacte d'un dashboard dont les chiffres ne remontent à rien d'extérieur à la plateforme qui les a produits. Un tel dashboard peut être parfaitement cohérent en interne, chaque graphique en accord avec chaque autre graphique, chaque total qui tombe juste, et rester entièrement faux, parce que la cohérence interne n'est pas la vérité. Une boucle fermée de chiffres auto-attribués, à fenêtre par défaut, en partie modélisés, sera toujours d'accord avec elle-même. C'est exactement ce qui la rend dangereuse.

Une mesure est ancrée quand ses chiffres sont reliés à quelque chose que la plateforme ne peut pas noter elle-même : le cash réellement arrivé en banque, les commandes réellement expédiées, les deals réellement signés dans votre CRM, et idéalement un test de holdout ou de geo-lift qui établit ce que la publicité a réellement causé. Rien de tout cela ne vit dans l'API Meta. Donc aucun agent lisant uniquement l'API Meta, aussi capable soit l'agent, ne peut produire un chiffre ancré. Le plafond est fixé par la source, et la source est hors sol par construction. C'est la même raison structurelle pour laquelle les neuf modèles d'attribution sont en désaccord entre eux, et la raison pour laquelle le ROAS rapporté par Meta est trompeur quelle que soit la façon dont vous le visualisez.

Construisez le front-end avec l'IA. Ne le laissez juste pas choisir le chiffre.

Donc la solution n'est pas de ranger les jouets. La solution est de changer ce que l'agent lit. Un dashboard n'est jamais plus honnête que la couche en dessous, et tout le problème ci-dessus vient d'un seul choix de conception : pointer l'agent droit sur l'API auto-notée de la plateforme. Pointez-le sur une couche de mesure qui a déjà réconcilié les revendications de la plateforme avec votre vrai revenu, et le même dashboard propulsé par MCP, rendu par IA, auto-actualisé, devient un actif au lieu d'un passif. Le rendu n'a jamais été la partie dure. La vérité-terrain, si.

C'est précisément la couture dans laquelle Metrikia est conçu pour s'asseoir. Metrikia prend les conversions que les plateformes revendiquent et les réconcilie avec le revenu réellement arrivé dans votre CRM, déduplique la même vente revendiquée par Meta, Google et TikTok, tient la fenêtre d'attribution honnête au lieu d'accepter le réglage par défaut de chaque plateforme, et vous donne la structure de holdout pour tester si la dépense a causé le résultat plutôt que de simplement l'avoir précédé. C'est la couche de vérification que les plateformes ne construiront jamais, parce que leur intérêt est de continuer à noter leur propre copie. Construisez le front-end que vous voulez par-dessus, avec Claude, avec un serveur MCP, avec ce qui sortira le trimestre prochain. Laissez-le juste lire un chiffre qui a déjà touché le sol.

Les plateformes optimisent vers leur propre tableau de score. Votre travail est d'en tenir un indépendant, et ensuite, bien sûr, de le rendre magnifique.

Comment câbler un dashboard IA sur la vérité-terrain

Si vous allez construire ça, l'ordre des opérations est toute la leçon. Ancrez d'abord, affichez en dernier.

1. Réconciliez au cash avant de visualiser quoi que ce soit. L'ancre est le revenu réellement arrivé : votre CRM, votre processeur de paiement, votre banque. Chaque chiffre de plateforme est une revendication à vérifier contre cette ancre, pas un fait à mettre en graphique.
2. Dédupliquez entre canaux. Avant d'additionner quoi que ce soit, ramenez la même conversion revendiquée par plusieurs plateformes à un seul événement réel, sinon votre total blended est gonflé par construction.
3. Fixez la fenêtre d'attribution délibérément, une fois. Ne laissez pas chaque API vous tendre son propre défaut. Choisissez une fenêtre, appliquez-la de façon cohérente sur tous les canaux, et notez celle que vous avez choisie, pour que le chiffre de lundi et celui de jeudi veuillent dire la même chose.
4. Validez par une expérience les arbitrages qui coûtent de l'argent réel. Avant de réallouer un budget sérieux sur la foi d'un graphique, confirmez la revendication causale avec un holdout ou un geo-lift. Un dashboard peut classer des canaux. Seule une expérience peut vous dire que l'un d'eux a causé la vente.
5. Et alors, seulement alors, laissez l'IA le rendre. Une fois le chiffre dessous réconcilié, dédupliqué, fenêtré, et là où ça compte validé causalement, un front-end LLM est réellement excellent sur le dernier kilomètre : résumer, faire remonter les anomalies, répondre aux questions de suivi en langage naturel. C'est le bon job pour l'agent. Choisir le chiffre ne l'a jamais été.

La différence entre un dashboard IA dangereux et un excellent ne tient pas au modèle, au prompt, ni au serveur MCP. Elle tient à ce que la donnée ait eu des racines avant que l'agent ne trace le premier graphique.

Questions fréquentes

Je peux juste dire à Claude de se méfier des chiffres ? Non, parce que le scepticisme n'a rien à lire. L'agent n'a aucune source indépendante contre laquelle vérifier le chiffre Meta. Lui demander d'« être critique » produit un langage à sonorité critique, pas un chiffre corrigé. Le scepticisme sans seconde source de vérité est du théâtre. La solution est de lui donner une source réconciliée, pas une meilleure personnalité.

Un dashboard MCP n'est-il pas correct si je comprends moi-même la donnée ? C'est mieux, mais comprendre la donnée ne change pas ce que renvoie l'API. Vous recevez toujours des conversions auto-attribuées, à fenêtre par défaut, en partie modélisées, et vous restez sujet à l'automation bias et à l'illusion de profondeur explicative, qui d'après la recherche opèrent aussi sur les experts. Comprendre les limites est nécessaire. Ce n'est pas suffisant. Le chiffre a toujours besoin d'être ancré.

Est-ce uniquement un problème Meta ? Non. La même logique s'applique à un MCP Google Ads, un MCP TikTok, ou tout autre connecteur de plateforme. Chaque plateforme renvoie ses propres chiffres auto-attribués sur ses propres fenêtres, et brancher un agent sur plusieurs d'entre elles à la fois rend le double-comptage cross-plateforme pire, pas meilleur, parce que désormais le total gonflé est assemblé automatiquement.

Donc je ne devrais jamais utiliser l'IA pour le reporting ? Au contraire. L'IA est excellente pour le reporting, une fois le chiffre ancré. L'argument porte sur la séquence, pas sur les outils : réconciliez, dédupliquez, fenêtrez et validez d'abord, puis laissez l'agent résumer et visualiser. Le danger est exclusivement dans le fait de laisser le modèle posséder la définition du chiffre par lequel vous pilotez la dépense.

Pourquoi un dashboard IA est-il plus dangereux qu'un manuel si la donnée est identique ? À cause de la façon dont vous y réagissez. La friction du tableur manuel maintenait votre doute en vie. Le dashboard IA supprime cette friction et ajoute un narrateur fluide, que l'automation bias et l'illusion de profondeur explicative transforment en fausse confiance. Même chiffre faux, probabilité bien plus élevée que vous agissiez dessus.

Combien ça coûte de bien faire versus le tuyau DIY ? Le tuyau DIY est quasi gratuit à construire et coûteux à croire, parce que le coût apparaît plus tard sous forme de budget mal alloué que vous ne voyez pas. Une couche de réconciliation a un vrai coût d'abonnement et vous évite de piloter six et sept chiffres de dépense par un nombre qui se trompait d'un facteur trois ou plus. Le cadrage honnête n'est pas pas cher contre cher. C'est un coût visible maintenant contre un coût invisible qui compose chaque mois.

Références

Anthropic. (2024, 25 novembre). Introducing the Model Context Protocol. https://www.anthropic.com/news/model-context-protocol

Goddard, K., Roudsari, A., & Wyatt, J. C. (2012). Automation bias: A systematic review of frequency, effect mediators, and mitigators. Journal of the American Medical Informatics Association, 19(1), 121-127. https://doi.org/10.1136/amiajnl-2011-000089

Gordon, B. R., Zettelmeyer, F., Bhargava, N., & Chapsky, D. (2019). A comparison of approaches to advertising measurement: Evidence from big field experiments at Facebook. Marketing Science, 38(2), 193-225. https://doi.org/10.1287/mksc.2018.1135

Lewis, R. A., & Rao, J. M. (2015). The unfavorable economics of measuring the returns to advertising. The Quarterly Journal of Economics, 130(4), 1941-1973. https://doi.org/10.1093/qje/qjv023

Meta. Marketing API: Insights et fenêtres d'attribution. https://developers.facebook.com/docs/marketing-api/insights/

Parasuraman, R., & Riley, V. (1997). Humans and automation: Use, misuse, disuse, abuse. Human Factors, 39(2), 230-253. https://doi.org/10.1518/001872097778543886

Rozenblit, L., & Keil, F. (2002). The misunderstood limits of folk science: An illusion of explanatory depth. Cognitive Science, 26(5), 521-562. https://doi.org/10.1207/s15516709cog2605_1

Skitka, L. J., Mosier, K. L., & Burdick, M. (1999). Does automation bias decision-making? International Journal of Human-Computer Studies, 51(5), 991-1006. https://doi.org/10.1006/ijhc.1999.0252

À propos de l'auteur

Baptiste Noel, cofondateur de Metrikia. MSc en neurosciences cliniques et MSc en haute performance.

Metrikia est la couche de vérification au-dessus de votre stack publicitaire. Branchez le front-end que vous voulez, avec un serveur MCP, avec Claude, avec ce qui sortira ensuite, mais pointez-le sur un chiffre déjà réconcilié contre votre vrai revenu, dédupliqué entre canaux, et là où ça compte validé par un holdout, pour que le dashboard auquel vous finissez par faire confiance soit un dashboard qui a touché le sol.