Orchestration multi-agents : patterns et pièges à éviter

Un seul agent LLM ne suffit pas toujours. Parfois il faut plusieurs agents qui collaborent. Voici les patterns que j’ai testés et ce qui fonctionne vraiment.

Pourquoi plusieurs agents ?

Trois raisons légitimes d’architecturer plusieurs agents :

La complexité de la tâche dépasse la fenêtre de contexte. Un agent unique qui doit à la fois comprendre une demande, chercher dans une base de données, générer un document et l’envoyer par email — le contexte devient ingérable.

La spécialisation améliore la qualité. Un agent spécialisé dans la classification, un autre dans la génération — chacun avec un prompt système optimisé pour sa tâche — donne souvent de meilleurs résultats qu’un agent généraliste.

La parallélisation accélère le traitement. Certaines sous-tâches peuvent tourner en parallèle si elles sont indépendantes.

Les patterns qui fonctionnent

Pattern 1 : Routeur + Spécialistes

Un agent de routage analyse la requête entrante et la dirige vers l’agent spécialisé approprié. Simple, efficace, facile à déboguer.

Requête → Agent Routeur → Agent Spécialiste A
                        → Agent Spécialiste B
                        → Agent Spécialiste C

Le routeur doit être simple et précis. Son seul job : classifier, pas répondre. Plus il est simple, plus il est fiable.

Pattern 2 : Pipeline séquentiel

Les agents se passent le résultat en chaîne, chacun enrichissant ou transformant le travail du précédent.

Requête → Agent 1 (extraction) → Agent 2 (analyse) → Agent 3 (formatage) → Réponse

Attention : chaque étape amplifie les erreurs. Si l’Agent 1 extrait mal, l’Agent 2 analyse du mauvais contenu, l’Agent 3 formate n’importe quoi. Validez chaque sortie entre les étapes.

Pattern 3 : Agent superviseur

Un agent superviseur décompose une tâche complexe, délègue aux sous-agents, agrège les résultats et produit la réponse finale.

C’est le pattern le plus puissant mais aussi le plus fragile. Le superviseur doit être excellent pour décomposer les tâches et interpréter les résultats des sous-agents.

Les pièges classiques

Enchaîner des agents sans valider les sorties intermédiaires. Si l’Agent 1 retourne un JSON malformé et que l’Agent 2 l’ingère sans validation, vous déboguerez l’Agent 2 pendant des heures alors que le problème est dans l’Agent 1.

Trop d’agents pour une tâche simple. J’ai vu des architectures avec 7 agents pour ce qu’un seul agent bien prompté aurait géré. La complexité a un coût : latence, coût, surface de debug.

Pas de gestion des timeouts. Un agent qui ne répond pas doit déclencher un timeout et un fallback. Sans ça, un bug dans un agent peut bloquer tout le pipeline indéfiniment.

Pas de traçabilité. En production, vous devez savoir quel agent a pris quelle décision à chaque étape. Loggez tout : inputs, outputs, temps de réponse, tokens utilisés.

Ma règle d’or

Commencez avec un seul agent. Ajoutez un deuxième seulement si vous pouvez clairement articuler pourquoi un seul ne suffit pas. Et ainsi de suite.

La complexité d’une architecture multi-agents est réelle — en développement, en maintenance, en débogage. Elle doit être justifiée par un gain concret, pas par une intuition sur ce qui “devrait mieux marcher”.