kengdevParlons de votre projet
Mis à jour le 2026-09-10
Un système multi-agent découpe un problème entre plusieurs agents qui ont chacun leur contexte, leurs outils et leur périmètre, sous la coordination d'un orchestrateur. On y vient quand un agent unique commence à confondre des tâches qui n'ont rien à voir, pas parce que l'architecture paraît plus élégante.
Reconnaître le moment où découper aide vraiment, et celui où ça ne fait qu'ajouter des pannes.
Deux agents coûtent plus du double d'un agent, en tokens comme en debug. Découpe seulement quand un seul bloque.
Un LLM n'est pas une architecture
Coller un LLM derrière une API ne fait pas un design multi-agent. Une architecture agentique digne du nom combine le raisonnement, les outils, la mémoire, des politiques de contrôle et de l'observabilité.
Six patterns reviennent dans les systèmes qui tiennent en production:
| Pattern | Rôle |
|---|---|
| Routeur d'intention | Il oriente chaque demande vers le bon spécialiste |
| Spécialiste domaine | Il traite un périmètre borné avec ses propres outils |
| Outil déterministe | Il fiabilise le calcul et les actions critiques |
| Mémoire d'état | Elle conserve l'avancement entre les étapes |
| Critique / réflexe | Il relit et corrige la sortie avant diffusion |
| Orchestrateur | Il séquence les agents et applique la policy |
On bascule en multi-agent quand les prompts deviennent monstrueux et que les outils se marchent dessus, pas pour le prestige LinkedIn.
En PME, stabilise d'abord un mono-agent avec son HITL (voir l'article comment créer un agent IA).
Isolate: subagents et contextes séparés
Un sous-agent travaille dans sa propre fenêtre de contexte. L'orchestrateur n'avale donc pas tout l'historique de recherche. C'est le levier « Isolate » du context engineering, appliqué à l'architecture.
Le découpage devient utile quand la recherche, la rédaction et l'exécution méritent chacune leur contexte, ou pour des jobs headless en CI qui enchaînent le plan, le patch et le test, à condition de prendre l'isolation et les secrets au sérieux.
Sans limite de hops, sans timeouts et sans circuit breakers, les agents se répondent en boucle et grillent les tokens.
Gouvernance multi-agent
Chaque agent a un owner, un budget de tokens, une allowlist d'outils (MCP) et ses métriques. L'orchestrateur applique une policy de délégation écrite.
Place le HITL aux frontières à risque, comme un envoi client ou une écriture financière, pas seulement « à la fin ».
Côté coût, un système multi-agent multiplie souvent les appels LLM. Budgète, mets du cache, et garde en tête que l'architecture n'autorise pas le gaspillage.
Feuille de route
La progression raisonnable tient en cinq étapes:
- Stabiliser un mono-agent utile
- Extraire un second spécialiste
- Ajouter un routeur
- Mesurer
- Orchestrer, seulement si nécessaire
Si vous voulez valider qu'un passage en multi-agent est justifié, on peut le cadrer en 20-40 minutes.
Questions fréquentes
Plus intelligent qu'un seul agent ?
Un système multi-agent n'est pas automatiquement plus intelligent. Il est plus modulaire, souvent plus cher, et il devient fragile quand il est mal conçu.
Combien d'agents au démarrage ?
Commence avec un agent, puis passe à deux. Démarrer avec six agents dès le premier jour est un anti-pattern.
Faut-il un framework multi-agent ?
Un framework ne se justifie que si un mono-agent et du code clair ne suffisent plus. Sans observabilité, il ajoute surtout de la magie opaque.
Lien MCP ?
Le MCP standardise les outils. Plus tu as d'agents, plus l'allowlist et les schémas comptent.
Lien context engineering ?
Isolate et Compress sont les deux leviers principaux du context engineering en multi-agent. L'article dédié les détaille.
Sources et repères
- Building effective agentsAnthropic
Documentation primaire à consulter pour les caractéristiques et évolutions du produit.
