Architecture multi-agents en pratique : modèles de conception et mise en production (guide 2026)

Pourquoi un agent unique ne scale pas en production

Un agent LLM isolé peut bien se comporter en démo : un prompt système, une liste d'outils, un fil de conversation. Sous charge réelle, il devient le goulot d'étranglement. Le benchmark interne Agent Bake-Off de Google a montré que les équipes multi-agents terminent des workflows complexes en 10 minutes contre 60 minutes pour un agent unique — un gain de vitesse de 6×. Par ailleurs, l'étude AdaptOrch a constaté que la topologie d'orchestration expliquait 12 à 23 % de variance supplémentaire sur le succès des tâches par rapport au changement de modèle sous-jacent — l'architecture l'emporte sur le choix de modèle.

Avant de choisir un framework, cartographiez les limites structurelles qui imposent un découpage MAS.

1. 01

   Saturation de la fenêtre de contexte : recherche, code, journaux et sorties d'outils s'accumulent dans un seul fil. La qualité de récupération chute ; l'agent oublie les contraintes posées dix tours plus tôt.

2. 02

   Prompting touche-à-tout : une seule persona ne peut pas exceller simultanément en tuning SQL, revue juridique et rédaction UI. L'interférence d'instructions augmente le taux d'hallucinations.

3. 03

   Pas de vraie concurrence : les appels d'outils séquentiels se bloquent mutuellement. Les sous-tâches indépendantes (scraper trois sites, lancer trois suites de tests) gaspillent du temps mur.

4. 04

   Point de défaillance unique : un mauvais résultat d'outil ou une boucle incontrôlée tue toute la session. Aucun domaine d'isolation pour les nouvelles tentatives ou les rollbacks.

5. 05

   Attribution de coûts opaque : la finance ne peut pas dire quelle étape a consommé les tokens. Sans budget par agent, un chercheur verbeux épuise le plafond mensuel.

Six modèles de conception d'orchestration

Les modèles sont composables. Une stack support client peut utiliser un superviseur qui lance des chercheurs en parallèle, puis enchaîne la synthèse vers un rédacteur via un pipeline. Choisissez le minimum de modèles correspondant à la structure de dépendances.

1. Pipeline séquentiel

Les étapes s'exécutent dans un ordre fixe : ingestion → analyse → brouillon → revue. L'état transite par un nœud de graphe partagé. Idéal lorsque chaque étape dépend de la sortie précédente (ETL, génération de rapports). LangGraph modélise cela comme un StateGraph linéaire avec des réducteurs d'état typés.

2. Fan-out / Fan-in parallèle

L'orchestrateur lance N branches indépendantes, puis agrège les résultats. L'API Send de LangGraph dispatche des nœuds workers dynamiques depuis une étape map ; un nœud réducteur fusionne les sorties. À utiliser pour la recherche multi-sources, le vote d'ensemble ou la revue de code par shard.

from langgraph.types import Send

def fan_out(state):
    return [Send("research_worker", {"query": q}) for q in state["queries"]]

def fan_in(state):
    return {"report": synthesize(state["worker_results"])}

3. Superviseur-worker hiérarchique

Un superviseur classifie l'intention et route vers des spécialistes (codeur, DBA, relecteur). Ajoutez une voie rapide par mots-clés : correspondance regex ou embedding sur les intentions à haute confiance pour éviter l'appel LLM de routage, économisant latence et tokens sur les requêtes type FAQ.

4. Essaim (style AutoGen)

Les agents transfèrent le contrôle de conversation via des outils handoff. Microsoft AutoGen excelle ici : adapté au brainstorming ouvert où le prochain locuteur émerge. Plus difficile à auditer qu'un graphe fixe.

5. Tableau noir (Blackboard)

Les agents lisent et écrivent un magasin d'artefacts partagé plutôt que de s'envoyer des messages directs. Un planificateur publie les objectifs ; les spécialistes ajoutent des sections. Convient à l'édition collaborative de documents et aux bases de connaissances partagées avec résolution de conflits au niveau du store.

6. Hybride

Les systèmes réels combinent les modèles : superviseur hiérarchique → fan-out parallèle pour la recherche → pipeline séquentiel pour l'emballage final. Dessinez explicitement quels segments sont sync vs async avant d'écrire le code.

MCP + A2A : la double couche protocolaire

L'intégration d'outils et la collaboration entre agents sont des problèmes distincts. Les stacks 2026 les traitent comme un gâteau protocolaire à deux niveaux : accès vertical aux outils en bas, délégation horizontale entre agents en haut.

Chaque agent publie une Agent Card — un document JSON décrivant les capacités, schémas d'entrée et URL de point de terminaison. Les pairs appellent discover_and_delegate pour router les sous-tâches sans listes d'agents codées en dur.

{
  "name": "sql-analyst-agent",
  "description": "Analyse Postgres en lecture seule et plans d'exécution",
  "url": "https://agents.internal/a2a/sql-analyst",
  "capabilities": ["query", "explain", "schema-introspect"],
  "input_schema": {
    "type": "object",
    "properties": { "question": { "type": "string" } }
  }
}

async def discover_and_delegate(task: str, registry: AgentRegistry):
    card = await registry.find_best_match(task)
    if not card:
        raise NoAgentError(task)
    payload = {"task": task, "caller": "supervisor-01"}
    return await a2a_client.send(card.url, payload)

MCP gère tools/list à l'intérieur de chaque agent ; A2A gère quel agent possède la tâche. Consultez notre guide protocole MCP pour la couche verticale en détail.

Observabilité : traces MAST, OpenTelemetry et LLM-as-Judge

On ne corrige pas ce qu'on ne peut pas attribuer. L'étude MAST a analysé 1 642 traces d'exécution multi-agents et constaté que les modes d'échec se regroupent de façon prévisible — la plupart relèvent de la conception, pas du QI du modèle.

Répartition des échecs MAST

• 41,77 % — défauts de conception système (mauvaise topologie, contrats de passation manquants)
• 36,94 % — désalignement inter-agents (objectifs ambigus, hypothèses conflictuelles)
• 21,30 % — lacunes de vérification (pas d'agent vérificateur, pas de validation de schéma)

Les équipes investissent massivement dans les modèles mais sous-investissent dans la télémétrie : les répondants MAST ont consacré 57 % du temps d'ingénierie au durcissement production contre seulement 8 % à l'observabilité — un déséquilibre qui répète les mêmes échecs en production.

Stack d'instrumentation

Encapsulez chaque invocation agent dans des spans OpenTelemetry : agent_id, parent_span, tool_name, token_in/out, latency_ms. Exportez vers votre APM existant. Définissez CORE_METRICS comme tableau de bord minimum :

Ajoutez LLM-as-Judge sur un échantillon de traces : un agent évaluateur séparé note l'alignement objectif et la cohérence factuelle. Utilisez-le hors ligne pour les tests de régression, pas inline sur chaque requête (coût).

Arbre de décision architecture

Avant de choisir un framework ou de dessiner la topologie, utilisez cet arbre pour positionner rapidement le bon modèle. Il n'existe pas de réponse unique, mais poser les questions dans le bon ordre évite 80 % de la sur-ingénierie.

Votre tâche a-t-elle des étapes linéaires strictement dépendantes ?
├─ Oui → Les sous-tâches peuvent-elles s'exécuter en parallèle ?
│        ├─ Non → 【Pipeline séquentiel】
│        └─ Oui → 【Fan-out parallèle + pipeline séquentiel hybride】
│
└─ Non → Un agent a-t-il l'autorité de décision ?
         ├─ Oui → L'échelle exige-t-elle des sous-équipes ?
         │        ├─ Non → 【Superviseur-worker hiérarchique】
         │        └─ Oui → 【Hiérarchique (superviseurs de superviseurs)】
         │
         └─ Non → La tâche est-elle asynchrone longue durée ?
                  ├─ Oui → 【Architecture tableau noir】
                  └─ Non → Nombre d'agents ≤ 5 ?
                           ├─ Oui → 【Essaim (définir des règles d'arrêt)】
                           └─ Non → 【Recomposer en mode hiérarchique】

1. ?

   Les sous-tâches sont-elles indépendantes ? Oui → Fan-out parallèle. Non → continuer.

2. ?

   L'ordre est-il strict ? Oui → Pipeline séquentiel. Non → continuer.

3. ?

   Besoin de dialogue émergent ? Oui → Essaim / AutoGen. Non → Superviseur-worker.

4. ?

   Besoin de reprise crash-safe ? Oui → LangGraph + PostgresSaver. Non → Voie rapide CrewAI.

5. ?

   Découverte d'agents inter-équipes ? Oui → Publier Agent Cards + A2A. Outils seulement → MCP par agent.