26 mai 2026
Construire un système multi-agents : ce que j'ai appris
Retour d'expérience honnête sur la construction d'un système multi-agents en production : l'orchestrateur compte, les contrats entre agents IA comptent encore plus, et la complexité d'état arrive plus vite que prévu.
Les démos vendent des agents. La production vous oblige à construire un système.
La plupart des tutoriels sur les agents IA racontent une histoire séduisante. On voit plusieurs rôles, chacun avec son outil, puis un résultat qui semble émerger naturellement d'une conversation bien orchestrée. En pratique, ce n'est pas ce que j'ai vécu. Quand on cherche à mettre un système multi-agents en production, on ne construit pas une troupe de personnages. On construit un système logiciel avec une vraie architecture IA, des transitions d'état, des contrats d'entrée-sortie, des garde-fous, et une responsabilité claire sur chaque action.
C'est probablement la leçon la plus importante que j'ai apprise. Le niveau de difficulté n'augmente pas seulement parce qu'il y a plusieurs agents IA. Il augmente parce qu'il faut maintenant faire coopérer plusieurs composants non déterministes à l'intérieur d'un workflow qui, lui, doit rester défendable. Dit autrement : l'intérêt d'un système multi-agents n'est pas d'ajouter de l'intelligence partout. C'est de découper correctement un problème pour que chaque partie ait un rôle borné, observable, et testable.
L'orchestrateur n'est pas une surcouche. C'est la pièce centrale.
Au début, j'avais tendance à penser que l'orchestrateur servait surtout à faire circuler le travail entre agents. C'est trop faible comme définition. Dans un vrai système multi-agents, l'orchestrateur décide quelles informations sont partagées, quelles étapes sont autorisées, à quel moment appeler un outil, quand relancer, quand arrêter, et quand demander un humain. C'est pour cela que LangGraph m'a semblé plus honnête que beaucoup d'abstractions plus haut niveau : il vous force à rendre explicite le graphe réel de votre orchestration au lieu de cacher la complexité derrière des rôles joliment nommés.
Sur le POC Mozza x Seyna, par exemple, le vrai sujet n'était pas d'avoir quatre agents pour le plaisir d'en avoir quatre. Le vrai sujet était de séparer des responsabilités qui ne devaient pas se contaminer : collecte du contexte, structuration du dossier, génération d'une sortie utile, puis validation ou arbitrage final. Dès que cette séparation est floue, l'orchestrateur devient un simple passe-plat et le système perd son intérêt. Dès qu'elle est claire, on peut enfin raisonner sur les handoffs, les outils, et les conditions d'échec.
Ce que les tutos disent trop peu : l'état partagé et les contrats sont le vrai travail
Le sujet le plus sous-estimé, de loin, est la gestion d'état. Dans un notebook ou une vidéo, un agent reçoit un prompt, appelle un outil, puis transmet un message propre au suivant. En production, l'état devient vite le centre du système : quels champs sont déjà fiables, quelles données sont provisoires, quelle décision a été prise, quelle tentative a déjà échoué, quel niveau de confiance on accepte, quelle trace on garde pour le replay. Sans discipline sur cet état, un système multi-agents dérive très vite vers quelque chose d'impossible à déboguer.
C'est pour cela que je crois de plus en plus aux contrats explicites entre agents IA. Chaque handoff doit ressembler à une interface, pas à une conversation poétique. Qu'est-ce qui entre ? Qu'est-ce qui doit sortir ? Quels champs sont obligatoires ? Quelles erreurs doivent être remontées plutôt que maquillées ? Quand on ne définit pas cela, chaque agent compense vaguement pour les faiblesses du précédent, et l'on se retrouve avec une architecture IA dont personne ne sait vraiment expliquer les invariants.
Déboguer une chaîne non déterministe demande plus d'ingénierie, pas plus de storytelling
Autre réalité qu'on découvre vite : le débogage change de nature. Quand un système classique casse, on remonte une trace, on isole une condition, puis on corrige. Quand un système multi-agents casse, on doit souvent comprendre une interaction entre prompt, outil, état, routing, timeouts, et sortie structurée. Le bug n'est pas toujours dans un agent isolé. Il est parfois dans le contrat entre deux agents, dans une donnée manquante, ou dans une décision d'orchestration prise trop tôt. Cela oblige à instrumenter sérieusement : logs par étape, snapshots d'état, causes d'arrêt explicites, et sorties structurées plutôt que texte libre dès que possible.
J'ai aussi appris qu'il fallait accepter une règle simple : si vous ne pouvez pas rejouer un chemin d'exécution et expliquer pourquoi l'orchestrateur a choisi telle branche, vous n'êtes pas prêt pour la production. Beaucoup d'équipes veulent ajouter des agents avant d'ajouter de l'observabilité. Je pense que c'est l'ordre inverse qu'il faut suivre. La capacité à inspecter et rejouer le système vaut plus qu'un agent supplémentaire censé rendre la démo plus impressionnante.
La bonne décision est souvent de ne pas ajouter un agent de plus
Le piège classique, ensuite, est l'inflation d'agents. Dès qu'un comportement semble un peu distinct, on est tenté de créer un nouvel acteur spécialisé. Parfois c'est la bonne décision. Souvent, c'est surtout une manière élégante de déplacer une complexité qu'on n'a pas encore clarifiée. Mon test est devenu assez brutal : si un nouvel agent n'apporte ni frontière de responsabilité nette, ni contrat simplifié, ni meilleur contrôle de la production, alors il ne mérite probablement pas d'exister. Un nœud de plus dans LangGraph n'est pas neutre. C'est plus d'état, plus de tests, plus de chemins d'échec, plus de maintenance.
Mon takeaway aujourd'hui est donc moins romantique que les discours habituels sur les agents IA. Oui, un système multi-agents peut être très puissant. Oui, il peut mieux refléter un vrai workflow qu'un agent unique. Mais il n'est utile que s'il reste lisible pour les humains qui doivent l'opérer. L'objectif n'est pas d'empiler des agents. L'objectif est de construire une orchestration suffisamment simple pour survivre à la production. Si vous ne savez pas encore pourquoi un agent supplémentaire existe, la meilleure architecture IA est probablement celle qui ne l'ajoute pas.