18 mai 2026
MCP, LangGraph, agents : ce que les vrais projets enseignent
Ce que les systèmes à base d'agents apprennent en production sur MCP, LangGraph, la coordination multi-agent et les garde-fous qui évitent de transformer une démo en incident.
La démo agentique impressionne vite. La production la calme tout aussi vite.
Les démos d'agents sont flatteuses parce qu'elles montrent la meilleure trajectoire possible : un objectif clair, des outils propres, aucun timeout, aucune permission bizarre, et juste assez de contexte pour que le raisonnement paraisse fluide. En production, le décor change. Les entrées sont incomplètes, les outils répondent lentement, les schémas changent, et l'utilisateur ne formule pas son besoin comme dans votre scénario de démonstration.
C'est là que le fossé apparaît. Un agent qui semble autonome sur scène passe en réalité son temps à arbitrer entre informations manquantes, appels qui échouent et décisions trop risquées pour être prises sans validation. La question n'est donc pas "peut-il enchaîner cinq actions tout seul ?" La vraie question est : reste-t-il utile, traçable et sûr quand tout n'est pas aligné ?
MCP n'est pas de la magie. C'est un contrat utile entre le modèle et le monde extérieur.
En pratique, MCP sert surtout à standardiser la manière dont un modèle découvre et appelle des outils, reçoit des ressources et garde une forme de contexte structurée. C'est précieux, parce que cela évite de recoder une intégration différente pour chaque client ou chaque surface d'exécution. Sur un vrai projet, cela simplifie l'exposition d'un catalogue d'outils, le transport des paramètres, et la discipline autour de ce que le modèle peut voir ou faire.
Mais MCP ne supprime pas les contraintes réelles. Il ne corrige ni une API lente, ni des permissions mal définies, ni un outil dont les erreurs sont opaques. Il rend l'interface plus propre ; il ne rend pas le système plus intelligent par défaut. Si vos outils sont fragiles, votre agent restera fragile, simplement avec un protocole plus net autour de cette fragilité.
LangGraph aide quand le workflow est réellement branché. Il gêne quand on dessine trop tôt.
LangGraph devient utile quand vous avez un enchaînement d'étapes qui mérite d'être explicite : qualification, collecte de contexte, appel d'outil, validation, puis sortie. Dans ce cas, le graphe rend les transitions visibles, facilite les checkpoints, et force l'équipe à nommer les états plutôt qu'à cacher toute la logique dans un prompt géant ou une boucle opaque.
Le problème commence quand le graphe devient un organigramme spéculatif. Beaucoup d'équipes modélisent dix branches avant d'avoir compris les trois cas dominants. Résultat : un système verbeux, plus long à débugger, plus pénible à faire évoluer, et souvent contourné par des exceptions ad hoc. Si la logique réelle tient encore dans une boucle agent + outils + validation, le graphe peut devenir une dette de maintenance avant d'être un avantage.
Le multi-agent coûte plus cher qu'il n'y paraît
Les architectures multi-agents vendent une promesse élégante : un agent planifie, un autre recherche, un troisième exécute, un quatrième contrôle. Sur le papier, la séparation des rôles semble rationnelle. En production, elle ajoute surtout de la latence, des appels supplémentaires, des coûts plus difficiles à prévoir, et une nouvelle surface d'erreur entre chaque handoff.
Le coût caché n'est pas seulement financier. C'est aussi le débogage. Quand la sortie finale est mauvaise, quel agent a dérivé ? Le planificateur a-t-il mal découpé la tâche, l'exécuteur a-t-il mal utilisé l'outil, ou le relecteur a-t-il validé un résultat déjà faux ? Plus vous multipliez les acteurs, plus vous créez de propagation d'erreurs et moins la causalité reste lisible.
Trois leçons reviennent sur presque tous les déploiements
Première leçon : l'observabilité n'est pas optionnelle. Il faut tracer les appels d'outil, les décisions de branchement, la latence, les refus, les escalades et les versions de prompt ou de modèle. Sans cela, vous pilotez un système agentique comme une boîte noire et chaque incident devient une enquête lente. Deuxième leçon : un mode dégradé explicite vaut mieux qu'une boucle de retries. Quand un outil échoue, il est souvent préférable de réduire l'ambition, demander une validation humaine, ou rendre la main proprement plutôt que d'insister cinq fois en silence.
Troisième leçon : les checkpoints humains restent rentables. Pas partout, pas à chaque étape, mais aux endroits où le coût d'une erreur est élevé ou où l'information manque. Un humain qui valide une action sensible ou arbitre un cas ambigu coûte souvent moins cher qu'une chaîne entièrement automatique qui rate discrètement pendant des semaines.
Par où commencer si vous voulez construire quelque chose de défendable
Le meilleur point de départ n'est généralement pas un essaim d'agents. C'est une boucle simple : une tâche étroite, un agent principal, quelques outils fiables, et une sortie que quelqu'un sait évaluer rapidement. Instrumentez avant d'optimiser. Ajoutez des logs, une eval de base, et une vue claire sur les échecs avant d'ajouter des rôles, des branches ou des sous-agents.
Ensuite seulement, complexifiez quand les données vous y obligent. Si vos evals montrent qu'un checkpoint dédié améliore vraiment la qualité, ajoutez-le. Si un graphe explicite réduit les erreurs sur un workflow stable, gardez-le. Si vous n'avez pas encore de couverture d'eval, de traces propres et de baseline simple, vous n'avez probablement pas besoin de plus d'agents. Vous avez besoin de plus de rigueur.