Architecturer un système multi-agents : orchestrateur et sous-agents

À la fin de ce tuto, tu sauras découper une tâche trop large entre plusieurs agents spécialisés et les faire collaborer — avec un orchestrateur minimal en Python, les patterns d'orchestration éprouvés, et la maîtrise des deux risques qui font dérailler les systèmes multi-agents. Prérequis : avoir fait le tuto « Construire un agent autonome ».

Durée : 35 min.

Pourquoi plusieurs agents

Quand une tâche devient trop large pour un seul agent — trop d'outils, trop d'étapes, trop de domaines —, on la découpe. Un agent unique avec 30 outils se disperse et choisit mal. En découpant, chaque agent a un périmètre clair, peu d'outils, un prompt focalisé. Avantages : meilleure qualité par tâche, débogage plus simple (on isole l'agent fautif), évolutivité (on remplace un sous-agent sans toucher au reste).

Mais attention : le multi-agents multiplie le coût et la complexité. Ne l'introduis que lorsqu'un seul agent sature réellement, jamais par principe.

Le pattern de référence : orchestrateur / sous-agents

Le plus répandu, et le plus robuste :

              ┌─> Sous-agent Recherche
Orchestrateur ┼─> Sous-agent Analyse
              └─> Sous-agent Rédaction

• L'orchestrateur reçoit l'objectif, le découpe en sous-tâches, délègue à l'agent compétent, puis assemble les résultats.
• Chaque sous-agent est un expert d'un domaine, avec ses propres outils.

L'orchestrateur ne fait pas le travail : il coordonne. C'est un chef de projet, pas un exécutant.

Un orchestrateur minimal en Python

L'astuce conceptuelle : un sous-agent est juste un outil de l'orchestrateur. On réutilise la boucle agentique du tuto précédent, où les « outils » sont en fait des appels à d'autres agents.

from openai import OpenAI
client = OpenAI()

# --- Sous-agents : chacun est un agent spécialisé (ici simplifié à un appel ciblé) ---
def sous_agent(role: str, instruction: str, tache: str) -> str:
    r = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": instruction},
            {"role": "user", "content": tache},
        ],
    )
    return r.choices[0].message.content

def agent_recherche(tache):  return sous_agent("recherche",
    "Tu es un chercheur. Rassemble les faits clés, en bullet points sourcés.", tache)
def agent_redaction(tache):  return sous_agent("rédaction",
    "Tu es un rédacteur. Produis un texte clair à partir des faits fournis.", tache)

# --- L'orchestrateur délègue puis assemble ---
def orchestrateur(objectif: str) -> str:
    # 1. Déléguer la collecte
    faits = agent_recherche(f"Trouve les faits pour : {objectif}")
    # 2. Déléguer la rédaction, en passant le résultat précédent
    texte = agent_redaction(f"Objectif : {objectif}\n\nFaits à utiliser :\n{faits}")
    return texte

print(orchestrateur("Un court résumé de l'état du RAG en 2026"))

Dans un système réel, l'orchestrateur est lui-même un agent (avec la boucle du tuto précédent) qui décide quel sous-agent appeler et quand s'arrêter, au lieu d'un enchaînement codé en dur. Mais ce squelette montre le principe : déléguer, puis assembler.

Les autres patterns utiles

• Séquentiel (pipeline) : chaque agent traite puis passe au suivant (rédaction → relecture → mise en forme). Simple et prévisible — c'est ce que fait l'exemple ci-dessus.
• Débat / critique : un agent produit, un autre critique, on itère. Améliore la qualité au prix de plus d'appels.
• Parallèle : plusieurs agents traitent des morceaux indépendants en même temps, puis on agrège (idéal quand les sous-tâches ne dépendent pas l'une de l'autre).

La communication entre agents

Les agents échangent par messages structurés, pas par conversation libre. Impose un format clair (souvent du JSON) pour ce qu'un agent transmet au suivant : objectif, contraintes, résultat. Une communication floue propage l'ambiguïté et fait exploser les erreurs.

# Au lieu de passer un blob de texte, passe une structure explicite
handoff = {
    "objectif": objectif,
    "faits_valides": faits,
    "incertitudes": ["date à confirmer"],  # remonter le doute, pas le masquer
}

Les deux risques majeurs

1. Le coût. Chaque agent est un ou plusieurs appels LLM. Un système à 5 agents qui itèrent peut multiplier la facture par 10 face à un appel simple. Mesure (cf. le tuto tokens), et n'ajoute un agent que s'il apporte une vraie valeur.

2. La propagation d'erreurs. Si le sous-agent de recherche renvoie une info fausse, l'agent de rédaction la reprendra comme vérité. Prévois des points de vérification, et fais remonter les incertitudes plutôt que de les masquer (le champ incertitudes ci-dessus).

Commencer simple

Ne démarre pas avec une armée d'agents. Fais fonctionner un agent, constate où il sature, et n'introduis un second agent que pour résoudre une limite précise. La complexité multi-agents se justifie par un besoin mesuré, jamais par l'envie d'une belle architecture.

À retenir

Plusieurs agents spécialisés surpassent souvent un agent surchargé. Le pattern de référence est l'orchestrateur qui délègue à des sous-agents experts puis assemble (un sous-agent n'est qu'un outil de l'orchestrateur) ; existent aussi le pipeline, le débat et le parallèle. Fais communiquer les agents par messages structurés. Surveille de près le coût et la propagation d'erreurs — et n'ajoute un agent que lorsqu'un seul ne suffit plus, jamais avant.