Faire passer une architecture multi-agents en production

La plupart des systèmes multi-agents impressionnent en démo et déçoivent en production. Le modèle est rarement en cause. Ce qui casse, c’est tout ce qu’il y a autour.

Le piège de la démo

Une démo optimise le cas idéal : une question bien posée, un contexte propre, un utilisateur à la fois. La production ne ressemble pas à ça.

Un exemple qu’on a vécu : un agent de support interne qui répond aux questions RH en s’appuyant sur une recherche documentaire. En démo, impeccable. Trois semaines après la mise en prod, l’outil de recherche s’est mis à répondre en huit secondes au lieu de 300 ms. L’agent n’y a vu aucun problème : il a attendu, réessayé, relancé. Résultat, des réponses en 45 secondes et une facture API qui triple. Personne n’avait testé un outil lent. On avait testé un outil qui marche et un outil qui échoue, jamais un outil qui rame.

Un agent qui ne sait pas échouer proprement n’est pas prêt pour la production.

C’est ça, le piège : les entrées ambiguës et les outils dégradés causent plus d’incidents que le modèle lui-même.

Trois décisions qui comptent

Rendre chaque étape observable

Tracez tout : appels d’outils, décisions de routage, tokens consommés, latence par étape. Concrètement, chaque exécution porte un identifiant, chaque étape émet un span, et on peut rejouer le fil complet d’une conversation qui a mal tourné. Le jour où quelqu’un demande « pourquoi l’agent a répondu ça mardi à 14h07 », vous avez la réponse en deux minutes au lieu d’y passer l’après-midi.

Borner l’autonomie

Un budget et un timeout explicites valent mieux qu’un prompt qui demande gentiment de ne pas dépasser. Sur nos projets, ça donne : douze étapes maximum par exécution, un plafond de coût par conversation, cinq secondes de timeout par appel d’outil, et une validation humaine pour toute action irréversible comme envoyer un mail ou écrire en base. Un agent qui atteint une limite s’arrête et le dit. Il ne continue pas en espérant que ça passe.

Isoler l’état

Presque tous les bugs non reproductibles que j’ai croisés venaient d’une mémoire partagée entre agents. Deux agents qui écrivent dans le même historique de conversation, et un troisième qui lit un état à moitié mis à jour : bonne chance pour rejouer ça. La règle qu’on s’impose : chaque agent reçoit son contexte en entrée et rend un résultat en sortie. Ce qui doit être partagé passe par un store versionné, jamais par un objet muté en place.

Notre stack du moment

Elle changera, mais voilà ce qu’on déploie aujourd’hui :

• Modèles : Claude via l’API Anthropic pour le raisonnement et l’orchestration, un modèle plus petit et moins cher pour la classification et le routage.
• Orchestration : du code. Une machine à états maison en TypeScript, lisible ligne par ligne. Un switch explicite bat un framework magique le jour où ça casse à 3h du matin.
• Outils : MCP pour exposer les outils internes, avec un serveur par domaine métier plutôt qu’un serveur fourre-tout.
• RAG : Postgres avec pgvector. Une base vectorielle dédiée ne se justifie pas en dessous de quelques millions de documents.
• Observabilité : OpenTelemetry pour les traces, Langfuse pour le suivi LLM, Grafana pour les dashboards.
• Évals : un jeu de scénarios rejoué à chaque déploiement, y compris les cas où un outil répond lentement ou pas du tout. C’est ce jeu de tests qui aurait attrapé l’histoire des huit secondes.

Ce qu’il faut retenir

Un système d’agents utile, c’est un système qu’on peut mesurer et réparer sans tout casser. C’est moins spectaculaire qu’une démo, mais c’est ce qui sépare un prototype d’un produit. Et si vous ne devez retenir qu’une chose : instrumentez d’abord, le reste en découle.