La moitié de vos dashboards sont morts. Et leur remplaçant ne demande pas la permission.

Quand une org audite ses dashboards, la moitié sont cassés — et personne ne l’avait remarqué. Pendant ce temps, un agent IA chez Meta est passé de prototype à outil quotidien de 77 % des data scientists en six mois. Le remplacement du dashboard ne sera pas un meilleur dashboard.

Quand personne ne regarde

L’expérience est devenue un classique du data engineering : vous auditez les dashboards d’une grande organisation, et la moitié sont morts. Cassés, obsolètes, ou simplement ignorés [1]. Le plus frappant ? Personne ne s’en était aperçu. Le conseil habituel — “résiste aux demandes de dashboard, concentre-toi sur les métriques durables” — rate quelque chose de plus profond.

Le vrai signal, ce n’est pas que les dashboards pourrissent. C’est qu’ils sont un marqueur d’attention organisationnelle. Chaque dashboard abandonné raconte l’histoire d’une initiative qui a perdu son sponsor, d’une équipe qui a pivoté, d’une question qui n’intéresse plus personne [1]. Le problème n’est pas la maintenance — c’est que le modèle même du dashboard, passif et en attente d’un regard humain, ne colle plus à la façon dont les organisations consomment la donnée.

L’agent qui a remplacé le data scientist de garde

Chez Meta, un data scientist a utilisé un agent de codage interne pour prototyper un outil capable d’exécuter des requêtes SQL de façon autonome, en s’appuyant sur l’historique de requêtes de ses collègues [2]. Le premier test grandeur nature : diagnostiquer une chute de métrique. L’agent a identifié les bonnes tables, lancé plusieurs requêtes de diagnostic et remonté la root cause — un changement de code récent.

Le prototype a quitté le devserver pour la production. Alpha, beta, itérations rapides, bouche-à-oreille. Six mois plus tard, 77 % des data scientists et data engineers de Meta l’utilisent chaque semaine, ainsi que cinq fois plus d’utilisateurs non-data [2]. La différence avec un dashboard ? L’agent ne vous montre pas un graphique en espérant que vous posiez la bonne question. Il investigue activement, raisonne sur les résultats, et décide de l’étape suivante.

L’iceberg sous le prototype

Mais construire un agent et le mettre en production sont deux exercices radicalement différents. En 2015, Google publiait son papier iconique sur la dette technique cachée du machine learning — un minuscule carré “ML Code” entouré de blocs d’infrastructure massifs. On vit exactement le même phénomène avec les agents [3].

Sept blocs d’infrastructure invisibles entourent chaque agent en production : les intégrations (chaque équipe câble ses propres connexions), le “context lake” (comment livrer le bon contexte à l’exécution), l’observabilité, la gouvernance, le human-in-the-loop, les évaluations pour systèmes non-déterministes, et le registre d’agents [3]. Quand 200 ingénieurs sur 30 équipes ont chacun leurs agents, avec chacun leurs tokens GitLab, leurs credentials Snowflake et leurs service accounts Kubernetes, c’est des centaines de points d’intégration gérés individuellement.

« Building an agent is easy. But in production, the agent code is the smallest part of the system. »

MCP passe à l’échelle

Pour adresser au moins une partie de ce problème, le protocole MCP (Model Context Protocol) prépare sa prochaine version majeure. Annoncée au MCP Dev Summit à New York, elle a été développée en collaboration avec Google et Microsoft pour permettre des serveurs stateless déployables à la demande [4]. Au menu : une capacité “task” pour les workflows autonomes longue durée, des triggers côté serveur, le retry, l’expiration, le streaming natif et les skills réutilisables.

Les SDKs MCP sont téléchargés 110 millions de fois par mois [4]. Mais comme le souligne l’article sur la dette agentique, MCP donne aux agents un moyen standard d’appeler un outil — il ne gère ni les credentials de cet appel, ni le périmètre des données renvoyées, ni ce qui se passe quand l’API change [3]. Le protocole avance. L’infrastructure autour reste à construire.

Le chaînon manquant : le contexte

Et si le problème de fond n’était pas le protocole mais la donnée elle-même ? L’ETL a résolu le transport des données il y a longtemps. Mais le transport sans sens ne suffit plus, surtout quand le consommateur n’est plus un dashboard mais un agent autonome qui prend des décisions à grande échelle [5].

Le framework ECL (Extract, Contextualize, Link) propose un recentrage : l’extraction reste nécessaire, mais le cœur du travail migre de la transformation vers la contextualisation. Donner du sens sémantique aux données et relier les entités entre systèmes [5]. Le “Context Store” n’attend pas une invention — il attend que la communauté data reconnaisse que l’infrastructure qu’elle sait déjà construire a un nouveau consommateur urgent.

Et qui possède les données ?

Pendant que l’industrie construit cette infrastructure, une question éthique s’invite. GitHub a discrètement mis à jour ses conditions d’utilisation : les interactions avec Copilot des utilisateurs Free, Pro et Pro+ serviront désormais à entraîner ses modèles IA [6]. Seuls les comptes Enterprise et Business sont exclus. Le changement ne concerne pas le code source des repos mais les prompts, suggestions acceptées ou rejetées, et le contexte des interactions.

La boucle est bouclée : les développeurs utilisent des agents pour coder, ces interactions alimentent les modèles qui propulsent les agents, et l’infrastructure autour — celle qui donne du sens au contexte, qui gouverne les accès, qui trace les décisions — reste le parent pauvre de l’équation.

Le mot de la fin

Le dashboard était un miroir passif. L’agent est un collègue actif. Mais un collègue sans bureau, sans badge d’accès standardisé, et sans mémoire partagée. La vraie question n’est plus “faut-il adopter les agents ?” — c’est “a-t-on l’infrastructure pour les accueillir à grande échelle ?”

Sources

Pour aller plus loin

Coding Agents are Effective Long-Context Processors — Une recherche montrant que les agents de codage surpassent les LLMs en traitement direct de contextes longs
How Datadog Redefined Data Replication — Comment Datadog a repensé la réplication de données à grande échelle
Synchronizing the Senses: Powering Multimodal Intelligence for Video Search — Netflix combine vision, texte et audio pour la recherche vidéo multimodale

Cet article a été rédigé en m’appuyant sur une IA pour m’aider à synthétiser et structurer ma veille. Les idées, le choix des sources et la relecture restent les miens.

Cet article a été rédigé en m'appuyant sur une IA pour m'aider à synthétiser et structurer ma veille. Les idées, le choix des sources et la relecture restent les miens.