Read English version · Voir la plateforme · Voir les solutions
3 agents en janvier, 40 en mai : une histoire qui se répète
Un ingénieur plateforme racontait récemment sur Reddit l'histoire de son équipe. Début janvier, ils avaient 3 agents en production : un assistant de code, un triage d'incidents, un helper de déploiement. Clean, maintenables, chacun savait ce qu'ils faisaient. Quatre mois plus tard, ils en avaient environ 40. Le mot clé est « environ » — personne n'avait le compte exact.
Entre-temps, chaque équipe avait sorti ses propres agents. Revues de PR, analyse de logs, résumés d'astreinte, monitoring de pipelines data, routing de tickets support, mise à jour de docs. Certains vivaient dans des configs Cursor individuelles, d'autres dans des sessions Claude Code, d'autres encore dans des workflows n8n montés un vendredi après-midi. Pas de registre. Pas d'ownership. Quand la personne qui l'avait monté partait en vacances, son agent tournait en roue libre — ou s'arrêtait silencieusement, et personne ne le remarquait avant que quelque chose casse.
Ce pattern a un nom : l'agent sprawl. La prolifération non gouvernée d'agents IA dans une organisation. Et ce n'est plus une hypothèse théorique.
Pourquoi ça explose maintenant
Trois dynamiques se combinent pour créer l'agent sprawl, et les trois ont accéléré ces six derniers mois.
Les agents sont une infrastructure invisible
Un microservice, même mal géré, vit dans un repo avec un Dockerfile et un pipeline CI. On peut le trouver. Un agent IA, lui, peut vivre dans la config d'un IDE, dans un workflow low-code, dans un prompt système enterré dans un bot Slack, ou dans un notebook. Il n'y a pas de docker ps pour les agents. Quand on essaie de faire l'inventaire, la moitié du parc est invisible.
Dataiku, dans son rapport 2026 sur le build vs buy, identifie précisément ce risque : « la multiplication d'agents redondants, non coordonnés, créant des vulnérabilités, des coûts cachés et des incohérences dans l'organisation ». Le CERT-FR, de son côté, a émis un avis officiel recommandant de ne pas déployer ces outils en production sans encadrement strict.
MCP démocratise l'intégration — et le risque
Le Model Context Protocol est une excellente idée sur le papier : un protocole standard pour que les agents accèdent aux outils. En pratique, chaque développeur branche ses agents sur ce qu'il veut via des serveurs MCP. Un agent d'une équipe a un accès read-write à la base de production. Celui d'une autre équipe peut pusher sur main sans review. Un troisième tire des données clients via un serveur MCP que personne n'a passé au crible sécurité.
Le tool poisoning — l'injection d'instructions malveillantes dans les métadonnées d'outils — devient un vecteur d'attaque réel. Des chercheurs ont détourné Gemini via une invitation calendar piégée. Une faille dans un navigateur agentique Microsoft a permis la prise de contrôle via path traversal. Chaque serveur MCP ajouté sans review élargit la surface.
L'effet microservices 2018
Ceux qui étaient là s'en souviennent. En 2018, tout le monde « cassait le monolithe » en microservices. Six mois plus tard, les boîtes se retrouvaient avec 200 services, pas de service mesh, pas de carte d'ownership, et un bad deploy qui cascadait sur 15 dépendances que personne ne connaissait. Il a fallu des années et des millions pour nettoyer.
On rejoue la même scène avec les agents. Sauf que cette fois-ci, c'est pire sur deux points : les agents prennent des décisions autonomes et agissent sur des systèmes de production, et leur non-déterminisme rend les incidents plus lents à reproduire.
Les 4 symptômes qui disent que vous y êtes déjà
Si un ou plusieurs de ces signaux vous parlent, l'agent sprawl a déjà commencé :
- Personne ne peut lister tous les agents actifs en moins de 10 minutes. Pas « pense pouvoir ». Peut, avec une requête, une source de vérité.
- Deux équipes ont construit le même agent sans le savoir. Classique sur les résumés de réunion, la qualification de leads, la synthèse de tickets.
- La facture LLM augmente plus vite que l'usage perçu. Symptôme très fréquent : plusieurs agents appellent les mêmes APIs, avec les mêmes inputs, sans cache partagé.
- Un agent a accès à une donnée que son propriétaire humain n'aurait pas. Credential sprawl. Le problème silencieux qui fait mal au premier audit.
Un rapport Gravitee 2026 avance une estimation : sur 3 millions d'agents IA en production dans les entreprises, moins de 48% sont activement monitorés. Autrement dit, environ 1,5 million tournent sans supervision. Une enquête OutSystems d'avril 2026 va plus loin : 94% des leaders IT disent que le sprawl augmente la complexité, la dette technique et le risque sécurité — et seulement 12% ont mis en place une plateforme centralisée pour le gérer.
Le coût réel : données, dollars, incidents
Amazon a vécu la version cauchemar du problème récemment : quatre incidents high-severity en une semaine sur le site retail, dont un meltdown du checkout de 6 heures. Cause racine : leurs propres agents prenaient des décisions basées sur des pages de wiki obsolètes. Un agent lit une doc périmée, fait un choix confidemment faux, et la cascade tombe sur des millions d'utilisateurs. Ils ont dû remettre des humains dans la boucle et convoquer une réunion d'urgence.
Si ça arrive à Amazon, avec leurs moyens en ingénierie plateforme, ça arrive partout. L'agent sprawl ne coûte pas seulement du compute inutile. Il coûte des incidents de production, parce que des systèmes autonomes continuent d'agir même quand leur contexte est faux.
Le deuxième coût est l'exposition de données. Les agents créent des flux de données émergents que personne n'a conçus. Un agent finance tire des données RH pour contextualiser un budget. Un agent sales lit les tickets support pour personnaliser un outreach. Ces flux traversent les frontières fonctionnelles sans review. Le RGPD n'aime pas ça. L'AI Act encore moins.
Ce qu'on fait chez Origin 137 pour que ça n'arrive pas
Le récit dominant en 2026 est qu'il faut une plateforme de gouvernance par-dessus vos agents. On n'est pas d'accord. La gouvernance n'est pas un outil qu'on ajoute après coup — c'est une propriété de l'architecture dès le premier agent.
Un registry dès le premier sub-process
Chez Origin 137, un processus n'est pas un agent monolithique. C'est un ensemble de sub-processes, chacun avec son owner, son trigger, son modèle, ses outils. Le registry n'est pas une fonctionnalité qu'on activera « plus tard ». C'est la structure de données elle-même. Quand vous déclarez un sub-process, il a forcément un nom, un owner, une description de ce qu'il fait et des outils qu'il peut appeler. Pas de registry = pas de sub-process qui tourne.
Ça paraît contraignant les deux premiers jours. Ensuite, c'est ce qui permet à 3 agents de devenir 40 sans que personne ne perde le compte.
L'allow-list d'outils comme défaut
Les recommandations de sécurité convergent toutes sur un point : la posture par défaut doit être deny, pas allow. Chaque sub-process dans Origin 137 a une allow-list explicite des outils qu'il peut appeler — pas « tout MCP branché sur ton compte », mais cette liste précise. Ajouter un outil se fait à la configuration, pas au runtime. Un agent qui trouve un outil auquel il n'a pas accès ne l'utilise pas — il ne contourne pas non plus.
Résultat concret : un sub-process de scoring de leads ne peut pas, par accident ou par prompt injection, envoyer un email. Même si le LLM « veut » le faire, l'outil n'est pas dans sa liste. Le prompt n'est pas un mécanisme de sécurité ; l'architecture l'est.
Observability partagée, pas par agent
L'autre réflexe classique — et piège — est de donner à chaque agent son propre monitoring. Vous vous retrouvez avec 40 dashboards. L'observabilité qu'on construit est partagée : chaque sub-process émet dans le même bus de traces, les mêmes métriques cost/latency/error. Vous pouvez demander « combien m'a coûté l'orchestrateur de qualification de leads cette semaine ? » et obtenir la réponse sans avoir à reconstituer 8 sources.
Quand un sub-process fail plus que la normale, c'est un signal, pas un mystère. Quand un nouveau sub-process apparaît, il apparaît dans la même vue que les autres. Le registry et l'observability sont les deux faces de la même pièce.
Par où commencer si vous y êtes déjà
Si vous lisez ça en pensant « trop tard, on en a déjà 20 », voilà un ordre de bataille qui marche :
- Inventaire en 48 heures. Une liste plate : nom de l'agent, owner humain, outils connectés, dernière exécution. Pas de tableau à 20 colonnes — si c'est trop lourd, personne ne le remplira.
- Couper les orphelins. Un agent sans owner identifié est un passif, pas un actif. Shutdown par défaut, réactivation si quelqu'un le réclame.
- Identifier les doublons. Les agents « résumé de réunion », « qualification lead », « extraction de doc » sont souvent triplés. On garde le meilleur, on tue les autres.
- Rationaliser les accès MCP. Une review par serveur MCP branché. Ceux qui n'ont pas passé la review sont coupés.
- Fixer un plafond. Chaque nouvel agent entre dans le registry avant d'être déployé. Période.
La vraie question n'est pas combien d'agents
Le bruit ambiant pousse à penser qu'avoir 40 agents est un signe de maturité IA. Ce n'est pas le cas. Ce qui compte, c'est de savoir ce que chaque agent fait, qui l'owne, et ce qu'il peut toucher. Une équipe avec 5 agents bien cadrés pilote mieux son risque que celle qui en a 40 sans inventaire.
Ce principe recoupe notre thèse produit : la valeur n'est pas dans les modèles, elle est dans la couche qui orchestre, observe et gouverne. C'est vrai pour 3 agents. Ça devient vital à 40.
L'agent sprawl n'est pas inévitable. C'est le résultat par défaut d'une adoption non architecturée. Il se choisit — ou il s'évite dès le premier agent.
Chez Origin 137, on aide les équipes à auditer leur parc d'agents avant qu'il ne double. Si vous êtes passés de 3 à 15 en quelques mois, et que le compte exact commence à devenir flou, c'est le bon moment pour en parler.