Quand les agents IA se parlent entre eux : la startup Band lance un 'orchestrateur universel

Les surcouches à base d'agents pour moderniser les services d'entreprise existants

Les infrastructures d'entreprise reposent depuis des années sur des API REST et des microservices, des systèmes stables, bien rodés, mais conçus bien avant l'émergence des agents autonomes. Dans un article technique publié en collaboration entre des ingénieurs de Cisco et d'AWS, les auteurs présentent une approche baptisée "agentic overlays" : des couches d'enveloppe légères qui transforment des services REST existants en agents capables de participer au protocole A2A (Agent-to-Agent), le standard de communication inter-agents en train de s'imposer dans l'industrie. L'idée centrale est de ne rien réécrire : aucune duplication du code métier, aucune infrastructure parallèle à opérer, aucune migration forcée. Ces overlays exposent également les API REST comme outils compatibles avec le Model Context Protocol (MCP), permettant ainsi aux agents d'orchestration modernes de les invoquer directement. L'enjeu est considérable pour les entreprises qui ont déjà déployé des agents maison, souvent construits comme de simples endpoints REST avec de la logique agent embarquée. Ces agents ne sont pas nativement A2A : ils ne savent pas se découvrir mutuellement via des métadonnées (un "agent card"), négocier des capacités, ni échanger des messages structurés en JSON-RPC pour coordonner des tâches complexes. Sans solution de transition, les entreprises se retrouvent face à un choix coûteux : maintenir deux mondes en parallèle (l'ancien en REST, le nouveau en A2A) ou tout réécrire. Les overlays proposés permettent d'éviter ce dilemme en réduisant ce que les auteurs appellent l'"agent sprawl", la prolifération incontrôlée d'agents disparates dans l'infrastructure. Cette approche s'inscrit dans un contexte d'accélération rapide des standards d'interopérabilité entre agents. Le protocole A2A, porté notamment par Google, vise à établir un langage commun pour que des agents d'éditeurs différents puissent collaborer, déléguer des sous-tâches et composer des workflows multi-étapes, là où REST se contentait d'exécutions isolées et déterministes. L'adoption a jusqu'ici été freinée par la complexité opérationnelle d'introduire ces nouvelles infrastructures sans perturber les systèmes en production. En proposant des architectures de référence et du code d'exemple, les auteurs cherchent à abaisser cette barrière d'entrée et à accélérer la migration progressive des parcs applicatifs existants vers un monde d'agents interopérables, sans rupture brutale.

Les services financiers face aux exigences de données pour l'IA à base d'agents

Plus de la moitié des équipes de services financiers ont déjà déployé ou prévoient de déployer une IA agentique, selon Gartner. Ces systèmes, capables de planifier et d'exécuter des tâches de manière autonome plutôt que de simplement générer des réponses, suscitent un intérêt croissant dans le secteur bancaire et assurantiel. Mais selon Steve Mayzak, directeur général mondial du Search AI chez Elastic, leur succès dépend moins de la sophistication des algorithmes que de la qualité des données sous-jacentes. "Tout commence par les données", résume-t-il. Une étude Forrester révèle pourtant que 57 % des organisations financières sont encore en train de développer les capacités internes nécessaires pour exploiter pleinement ces technologies agentiques. L'enjeu est considérable : une IA agentique amplifie autant les forces que les failles de son infrastructure data. Dans un secteur aussi réglementé, les exigences vont bien au-delà de la simple performance. Les entreprises doivent pouvoir tracer et justifier chaque décision prise par le modèle, données d'entrée comprises. "Il ne suffit pas d'expliquer d'où viennent les données et ce qu'elles sont devenues. Il faut une manière auditable et gouvernable d'expliquer quelle information le modèle a retenue et pourquoi elle était pertinente pour l'étape suivante", insiste Mayzak. Les hallucinations, les réponses incohérentes et les décisions difficiles à retracer minent la confiance des régulateurs, des clients et des équipes internes. Pour les transactions, les signaux de risque, les politiques internes ou l'historique client, la donnée doit être indexée, centralisée et accessible, pas enfouie dans des silos séparés. Le défi est structurel autant que technique. Les données financières existent sous des formats hétérogènes, accumulés sur des décennies d'histoire bancaire, mélangeant données structurées (tableurs, bases transactionnelles) et non structurées (notes de conseillers, échanges clients, documents contractuels). Or le langage naturel est, par nature, bien plus ambigu que les données tabulaires, ce qui rend leur nettoyage et leur organisation particulièrement complexes. Mayzak illustre la difficulté : "Il existe de nombreuses façons de décrire comment exécuter un ordre de bourse dans une banque. Dans un monde piloté par des agents IA, ces descriptions doivent être déterministes, donner le même résultat à chaque fois. Pourtant, on construit sur des modèles puissants mais non déterministes. C'est incroyablement délicat, mais pas impossible." Les prochaines années verront les acteurs financiers investir massivement dans la gouvernance des données, condition sine qua non pour transformer l'IA agentique d'outil prometteur en avantage compétitif réel.

💬 57% des organisations financières encore en train de "construire les capacités" pour l'IA agentique, c'est beaucoup de retard pour un secteur qui prétend se transformer. L'enjeu soulevé par Mayzak est le bon : tu peux avoir le meilleur modèle du monde, si tes données transactionnelles sont éparpillées en silos depuis 30 ans, l'agent va amplifier le chaos, pas le résoudre. Et la vraie tension, celle qu'on évite de nommer, c'est qu'on veut des résultats déterministes avec des modèles qui ne le sont pas.

57% des entreprises ont vu leurs agents IA se tromper avec assurance, la solution est une couche de contexte pour agents, mais qui en dispose?

Un agent IA d'entreprise répond avec une confiance totale, mais le chiffre est faux. Personne ne s'en aperçoit avant qu'on ne remonte la source jusqu'à une définition de métrique obsolète ou un document que le système de récupération n'a jamais consulté. Le modèle n'a pas échoué : c'est le contexte qui lui a été fourni qui a fait défaut. Selon une enquête VB Pulse menée en juin 2026 auprès de 101 entreprises qualifiées de plus de 100 salariés, 57% d'entre elles ont retracé, au cours des six derniers mois, une réponse d'agent IA fausse mais formulée avec assurance jusqu'à un contexte métier manquant ou incohérent, et 31% affirment que le problème s'est reproduit plusieurs fois. La cause est simple à identifier : la récupération de documents (retrieval) reste la méthode par défaut pour fournir du contexte métier aux agents dans 38% des entreprises, presque deux fois plus que l'approche suivante. Or le choix du système de récupération privilégie la facilité d'ingestion et la simplicité opérationnelle, la précision de récupération arrivant loin derrière, un problème qui ne se révèle qu'une fois le système déjà en production. Il existe une solution connue: une couche de contexte gouvernée, que chaque agent consulte au lieu d'improviser. Cette couche est censée constituer un modèle partagé de ce que signifient réellement les données de l'entreprise, construit une fois pour toutes plutôt que redérivé par chaque agent. Mais 75% des entreprises n'en possèdent pas encore. Seules 25% des répondants en exploitent une en production, 34% sont en train d'en construire une, et 41% n'ont rien entamé. Fait notable, parmi les entreprises qui construisent ou exploitent déjà une couche de contexte gouvernée, 78% rapportent avoir déjà subi une réponse faussement assurée, contre seulement 20% chez celles qui n'ont aucun projet en ce sens. Autrement dit, ce sont surtout les entreprises déjà échaudées qui se mettent à construire le correctif, tandis que les autres ne perçoivent pas encore l'urgence. Tous les grands éditeurs de plateformes de données et d'IA développent désormais leur propre version de cette couche de contexte, sans converger vers une architecture commune. DataHub traite les métadonnées de catalogue et des années de comportement de requêtes analystes comme une base de connaissances vivante. Microsoft, avec Fabric IQ, construit une ontologie métier interrogeable par tout agent via le protocole MCP. Couchbase parie sur une mémoire d'agent proche de la base de données opérationnelle plutôt que sur une couche de recherche greffée après coup. Pinecone, avec Nexus, précompile la logique structurelle dans la couche de métadonnées avant l'exécution. Snowflake combine deux systèmes, Horizon Context pour les définitions gérées par le client et Cortex Sense pour le contexte inféré automatiquement. Oracle, avec Unified Memory Core, fusionne données vectorielles, graphes et relationnelles dans un seul moteur transactionnel afin d'éliminer toute couche de synchronisation susceptible de se périmer. Google et AWS misent tous deux sur des graphes de connaissances qui s'affinent à partir des journaux de requêtes et de l'usage réel des agents. Pour Michael Ni, vice-président et analyste principal chez Constellation Research, l'enjeu est clair: qui contrôle le contexte au moment de l'exécution contrôle la couche de décision de l'IA sur les données de l'entreprise, la mémoire vectorielle seule ne suffisant pas à garantir un sens métier fiable.

💬 57% des entreprises se sont fait avoir par un agent qui répond faux avec un aplomb total, et 75% n'ont toujours pas la couche de contexte qui corrigerait ça. Le vrai enseignement du papier, c'est que ce sont surtout les boîtes déjà brûlées qui se mettent à la construire, les autres n'ont pas encore compris l'urgence. Microsoft, Snowflake, Oracle, chacun bâtit sa version maison sans converger vers un standard commun, et aucun acteur européen n'est dans la partie sur un sujet qui va peser lourd sur qui contrôle la donnée métier des agents IA.

Les startups numériques natives abandonnent les bases de données rigides pour des stacks à base d'agents

Trois startups spécialisées dans l'intelligence artificielle agentique ont choisi la même solution technique face à un problème d'infrastructure devenu critique : Huntr, Modelence et Tavily ont toutes bâti leur socle de données sur MongoDB Atlas, plateforme unifiée intégrant recherche vectorielle native, recherche hybride et mise à l'échelle automatique gérée. Modelence, créateur d'un framework open source pour développer des applications web agent-native, a ainsi pu lever 3 millions de dollars en financement d'amorçage et lancer une plateforme capable de générer des applications complètes, API et bases de données incluses, en quelques minutes seulement. Selon Aram Shatakhtsyan, cofondateur et directeur général de Modelence, le modèle de documents de MongoDB s'aligne naturellement sur la façon dont les agents IA traitent et génèrent des données, permettant aux schémas d'évoluer sans migrations manuelles, tout en conservant une couche de schéma typé qui améliore la fiabilité du code généré. L'intégration avec TypeScript renforce cette cohérence en offrant une source unique de vérité entre la logique applicative et la base de données. Tavily, de son côté, exploite MongoDB pour son API de recherche conçue spécifiquement pour les agents IA, qui les connecte à des informations web en temps réel plutôt qu'à des données d'entraînement figées ; Tomer Weiss, responsable de l'équipe data de l'entreprise, explique que la flexibilité du schéma permet de suivre le cycle de vie complet de chaque document consulté, incluant sa date de récupération, son degré d'obsolescence et sa popularité. Ce choix technique répond à un phénomène que l'industrie commence à nommer "architectural drag", soit le décalage croissant entre ce que les modèles et agents d'IA sont capables de produire et ce que les infrastructures traditionnelles peuvent réellement supporter. Les bases de données relationnelles classiques, conçues avec des schémas rigides, imposent des mises à jour manuelles à chaque fois qu'un agent introduit une nouvelle forme de données, tandis que le recours à des bases vectorielles séparées ajoute de la latence et des problèmes de synchronisation. Pour des systèmes qui doivent gérer sans intervention humaine des schémas variables, des embeddings vectoriels, de la récupération en temps réel et un usage multi-tenant à grande échelle, cette rigidité devient un frein direct à la mise en production. L'enjeu dépasse la simple performance technique : il conditionne la vitesse à laquelle les startups peuvent itérer et la fiabilité de leurs produits face aux utilisateurs. Ces trois cas illustrent une tendance de fond dans l'écosystème des startups qui construisent des produits IA dits "agent-native" : plutôt que d'assembler plusieurs briques technologiques distinctes pour le stockage, la recherche vectorielle et la recherche classique, elles privilégient une plateforme unique capable de tout gérer nativement. Cette convergence réduit les points de défaillance et simplifie l'architecture des agents autonomes, un facteur jugé de plus en plus déterminant à mesure que ces systèmes gagnent en complexité et en autonomie décisionnelle. Le pari de MongoDB, qui investit depuis plusieurs années dans les capacités vectorielles et l'autoscaling de sa plateforme Atlas, semble ainsi trouver un écho concret chez les jeunes entreprises qui construisent l'infrastructure des futurs agents IA.