Multi-Agent : les patterns qui arrivent vraiment en production

Chaque démo d'agent impressionne. Très peu survivent au contact avec la production. Après avoir livré des systèmes multi-agents pour des clients chez XAI.ma et construit le studio de rédaction multi-agents derrière Waraqa, j'ai une opinion assez ferme sur les patterns qui sont réels et ceux qui sont du théâtre. Voici le guide de terrain que j'aurais aimé qu'on me donne.

Le point de départ honnête : la plupart du travail est un seul agent

Avant d'architecturer une meute, vérifiez si le problème n'est pas en réalité un seul agent bien prompté avec un bon usage d'outils. Une énorme fraction des systèmes « multi-agents » est un seul agent qui fait plusieurs étapes — et forcer un second agent ajoute de la latence, du coût et de la non-déterminisme sans aucun bénéfice. La règle d'or : ajoutez un agent quand un rôle, un savoir ou une frontière de permissions différent existe réellement, pas quand le marketing y gagnerait.

Les patterns qui arrivent en production

Orchestrateur–workers

Un orchestrateur décompose la tâche, la répartit entre des workers spécialisés et assemble le résultat. C'est le cheval de trait — il se mappe sur la plupart des processus métier réels, il est facile à raisonner et il dégrade avec grâce.

class Orchestrator:
    def run(self, task):
        plan = self.planner.plan(task)           # décomposer la tâche en sous-tâches
        results = [
            self.pool.submit(w, s)               # répartir vers les workers spécialisés
            for s, w in plan.specialists
        ]
        return self.assembler.join(plan, results)

Le pattern orchestrateur–workers arrive en production parce que la logique d'orchestration est déterministe. Le LLM décide quoi faire ; une machine à états fixe décide qui le fait et dans quel ordre. Quand vous gardez le flux déterministe et laissez les modèles remplir les feuilles, le débogage devient gérable.

Superviseur

Un agent superviseur observe les workers, décide quand escalader et peut faire la main entre spécialistes. Ce pattern justifie sa complexité quand le travail est vraiment ouvert — un flux de tri du support, par exemple, où le premier agent doit décider si le problème est de facturation, technique ou produit. Le superviseur est la couche de risque : il exige la plus forte évaluation, car une mauvaise escalade est une interaction ratée.

Pipeline

Le pipeline (agent un → agent deux → agent trois) est celui qui séduit et celui dont il faut se méfier. Il est rapide et lisible, mais les erreurs se cumulent : une erreur en début de chaîne est amplifiée en aval, et les agents ne peuvent ni récupérer ni revenir en arrière. Les pipelines arrivent bien en production quand chaque étape a une porte de validation — on vérifie, et seulement ensuite on transmet. Sans ces portes, vous avez construit une machine à erreurs composées.

Maillage : le pattern des démos

Les maillages entièrement bidirectionnels — chaque agent parle à chaque agent — sont le domaine des démos et le cimetière des produits. L'explosion combinatoire des interactions les rend inobservables et non testables. Je n'ai jamais eu besoin d'un vrai maillage en production. Si votre conception en exige un, il vous manque probablement un orchestrateur.

Des outils, pas de l'ambiance

Les agents ne valent que ce que valent les outils qu'ils tiennent. La couche d'outils est là où doit aller le vrai budget d'ingénierie :

• Chaque outil a un schéma et un contrat. L'agent appelle une fonction ; la fonction renvoie des données structurées. Pas de canaux secondaires en texte libre.
• Les outils imposent des contraintes. Un outil de recherche renvoie des résultats avec leurs sources ; un outil d'écriture valide avant de commiter. L'outil est le point d'application de la sécurité, pas le prompt.
• Les échecs sont de première classe. Les outils renvoient les erreurs comme des données, et les agents sont entraînés (et testés) sur la conduite à tenir quand un outil échoue.

L'appel d'outils est aussi la partie qui bénéficie de la standardisation. MCP (Model Context Protocol) offre une façon uniforme d'exposer outils et contexte à différents agents et modèles — la couche de protocole qui transforme une intégration sur mesure en plateforme répétable.

L'observabilité n'est pas optionnelle

Dès que deux appels LLM collaborent, vous avez un système distribué — et un système distribué sans tracing est intraçable. Chaque exécution d'agent en production a une trace : le plan, chaque appel d'outil avec ses entrées et sorties, l'utilisation de tokens, la latence par saut, et l'assemblage final. Quand un client dit « ça a donné une mauvaise réponse », la trace est la première chose que vous ouvrez.

Journaliser chaque étape est aussi le harnais d'évaluation le moins cher que vous construirez jamais. Les traces de production deviennent le jeu de test de la version suivante — et elles attrapent des régressions qu'aucun benchmark synthétique ne détectera.

L'habitude de l'évaluation

Évaluez le système, pas les agents. Un seul agent peut être excellent pendant que le système échoue sur le routage, les contrats d'outils ou l'assemblage. J'évalue sur des résultats de bout en bout avec un jeu doré étiqueté, et je garde le format de sortie du pipeline constant pour que les régressions soient visibles. La discipline qui consiste à garder le contrat de sortie stable est ce qui vous permet d'itérer sur l'interne sans casser les consommateurs.

Discipline de coût et de latence

Les agents multiplient le coût et la latence comme ils multiplient la complexité, et la composition est facile à rater. Une seule requête qui se déploie en trois agents et quinze appels d'outils peut consommer un ordre de grandeur de tokens de plus qu'une réponse monolithique — et prendre cinq secondes au lieu d'une. Les systèmes d'agents en production ont besoin d'un budget explicite comme tout autre système distribué.

Trois pratiques qui gardent la facture honnête :

• Routez avant d'appeler. Un classifieur bon marché qui décide « ça nécessite la meute ou un agent unique » réserve la meute au travail qui en a réellement besoin. La plupart des requêtes ne devraient pas déclencher une meute.
• Plafonnez le fan-out. Fixez une limite stricte sur les appels d'outils parallèles et les tentatives, et faites dégrader l'orchestration : si le plan exige vingt étapes, exécutez les cinq premières et remontez le travail partiel plutôt que de brûler le budget en silence.
• Tracez la dépense. L'utilisation de tokens et la latence par saut sont des métriques de première classe dans chaque trace de production. Si une trace ne peut pas vous dire quel saut a coûté 1 $, le système est ingouvernable.

La vérité inconfortable : le changement au meilleur ROI sur la plupart des systèmes d'agents est moins d'agents. Retirer un saut réduit le coût, la latence et la surface d'échec en même temps — l'optimisation rare qui gagne sur tous les axes.

Quand ne pas construire d'agents

Si la tâche est déterministe, scriptez-la. Si la tâche est une Q&R unique et bien cadrée, un pipeline RAG battra un agent en latence, coût et prévisibilité. Les agents gagnent leur complexité sur les tâches ouvertes et multi-étapes — recherche, tri, production de documents — là où un pipeline fixe aurait besoin d'une branche différente pour chaque cas réel.

Voilà la conclusion honnête : les agents sont un outil pour gérer la complexité irréductible, pas une façon de rendre les choses simples à la mode. Construisez l'orchestrateur, verrouillez le pipeline, tracez tout, évaluez de bout en bout. Si vous faites pareil, comparons nos notes.