+180 XP

Systèmes multi-agents : orchestrateur, workers et handoffs

Demandez à un seul agent IA de « me rédiger un rapport de recherche concurrentielle sur les 3 principaux constructeurs de véhicules électriques » et regardez-le patauger. Il cherche sur Tesla, oublie de comparer les prix, commence à rédiger avant d'avoir les données et se retrouve à court de contexte à mi-parcours. Le problème, c'est un agent unique qui essaie de garder tout le travail en tête.

Maintenant, découpez le travail. Un agent planifie. Trois agents cherchent chacun sur une entreprise en même temps. Un agent rédige le rapport final. D'un coup, le problème difficile devient un ensemble de problèmes faciles.

Voilà ce qu'est un système multi-agents : plusieurs agents IA, chacun avec une mission étroite, coordonnés pour accomplir une tâche plus large.

Pourquoi découper le travail ?

Un agent unique a de vraies limites :

  • Limite de contexte. Chaque agent a une quantité maximale de texte qu'il peut prendre en compte d'un coup (sa « context window »). Entassez la recherche brute sur trois entreprises dans un seul agent et il commence à perdre des détails.
  • Focus. Un agent à qui on confie une mission claire (« trouver les prix de Rivian ») s'en sort mieux qu'un agent qui jongle avec cinq missions.
  • Vitesse. Trois agents de recherche qui tournent en même temps (en parallèle) terminent environ trois fois plus vite qu'un seul agent qui les enchaîne.

Définition rapide : un agent désigne ici un LLM (large language model, l'IA derrière des outils comme ChatGPT ou Claude) capable d'agir en boucle, d'appeler des outils comme la recherche web, puis de décider de la suite en fonction des résultats.

Le pattern orchestrateur-workers

La structure la plus fiable pour le travail multi-agents ressemble à une petite entreprise :

  • Orchestrateur (le manager) : découpe la tâche en morceaux, les assigne et assemble les résultats. Il ne fait pas le travail de détail lui-même.
  • Workers (les spécialistes) : chacun reçoit une mission claire, l'exécute et renvoie le résultat.

Voici notre rapport de recherche sous forme d'organigramme :

                 ┌─────────────────┐
                 │  ORCHESTRATEUR  │  planifie + délègue
                 └────────┬────────┘
          ┌───────────────┼───────────────┐
          ▼               ▼               ▼
   ┌────────────┐  ┌────────────┐  ┌────────────┐
   │ Chercheur  │  │ Chercheur  │  │ Chercheur  │   exécutés en parallèle
   │  (Tesla)   │  │  (Rivian)  │  │   (BYD)    │
   └──────┬─────┘  └──────┬─────┘  └──────┬─────┘
          └───────────────┼───────────────┘
                          ▼
                 ┌─────────────────┐
                 │    RÉDACTEUR    │  produit le rapport final
                 └─────────────────┘

Regardez la forme : tout passe par l'orchestrateur. Les workers ne discutent pas entre eux. Ils font remonter. C'est le choix de conception le plus important de la leçon, et on y reviendra.

Ce que reçoit concrètement chaque agent

Tout se joue dans les instructions. Chaque worker reçoit un prompt serré.

Prompt de l'orchestrateur (simplifié) :

Tu es un responsable de recherche. Découpe la demande de l'utilisateur en une tâche de recherche par entreprise. Envoie chaque tâche à un chercheur. Quand tous les résultats sont revenus, envoie-les au rédacteur. Ne fais ni recherche ni rédaction toi-même.

Prompt du chercheur :

Tu étudies exactement une entreprise. Trouve : les prix actuels, les chiffres de ventes 2025 et un mouvement stratégique clé. Renvoie un court résumé à puces avec les sources. Ne compare pas aux autres entreprises.

Prompt du rédacteur :

Tu reçois des résumés de recherche sur plusieurs entreprises. Rédige un rapport comparatif de 500 mots avec une recommandation. Utilise uniquement la recherche fournie.

La mission de chaque agent est assez petite pour tenir en trois phrases. C'est le signe d'un bon découpage.

Handoffs : passer le relais proprement

Un handoff, c'est le moment où un agent passe le contrôle (et l'information) à un autre. Réussissez les handoffs et le système ronronne. Ratez-les et l'information fuit ou disparaît.

Deux choses circulent dans un handoff :

  1. La tâche : quoi faire ensuite.
  2. Le contexte : l'information nécessaire pour le faire.

L'erreur courante consiste à transmettre trop ou trop peu. Si l'orchestrateur transmet à chaque chercheur l'intégralité de l'historique de conversation, vous gaspillez du contexte et vous embrouillez le worker. S'il ne transmet rien, le worker devine.

La solution : transmettre uniquement ce dont l'agent suivant a besoin. Le rédacteur a besoin des trois résumés de recherche, pas des notes de planification internes de l'orchestrateur.

Voici une esquisse neutre de la boucle d'orchestration en Python. C'est du pseudo-code, mais la forme est réelle :

python
def run_report(user_request):
    # 1. L'orchestrateur planifie : une tâche par entreprise
    companies = orchestrator.plan(user_request)  # -> ["Tesla", "Rivian", "BYD"]

    # 2. Les workers tournent en parallèle, chacun avec une tâche étroite
    results = run_in_parallel([
        researcher.run(f"Research {c}: pricing, 2025 sales, one strategic move")
        for c in companies
    ])

    # 3. Handoff : ne transmettre QUE les résumés au rédacteur
    report = writer.run(
        task="Write a 500-word comparison with a recommendation",
        context=results
    )
    return report

Chaque appel .run() est lui-même un agent qui exécute sa propre boucle d'appels d'outils (chercher sur le web, lire les résultats, décider, recommencer) avant de renvoyer. L'orchestrateur ne se soucie pas de *comment* un chercheur trouve les prix. Il veut juste qu'un résumé propre revienne.

Tous les grands fournisseurs proposent un outillage pour exactement ce pattern : l'OpenAI Agents SDK intègre des « handoffs », le Claude Agent SDK gère les subagents, et l'ADK de Google (Agent Development Kit) propose des types d'agents séquentiels et parallèles. L'idée de fond se transpose partout. Voir les blocs d'approfondissement par fournisseur pour la syntaxe exacte.

Pour une explication écrite claire de ces patterns, le guide Building Effective Agents d'Anthropic est gratuit, honnête vis-à-vis des autres fournisseurs, et vaut 15 minutes.

How to Build Multi-Agent Systems

Watch on YouTube

Le mode de défaillance : laisser les agents discuter librement

Voici l'idée tentante : et si on supprimait l'orchestrateur pour laisser tous les agents se parler entre eux ? Le chercheur Tesla discute avec le chercheur Rivian, le rédacteur intervient avec des questions, tout le monde collabore.

En pratique, ce « free-for-all » (parfois appelé montage multi-agents entièrement connecté ou conversationnel) s'effondre vite. Les modes de défaillance sont constants :

Boucles de bavardage. Deux agents se bloquent à force de politesse. « Dois-je inclure les prix ? » « Oui, et dois-je inclure les ventes ? » « Bonne idée, et est-ce que tu devrais aussi… ? » Ils brûlent des tokens et de l'argent en tournant en rond. (Un token est un fragment de texte traité par le modèle ; vous payez au token.)

Explosion du contexte. Quand chaque agent voit les messages de tous les autres, la conversation partagée enfle. Chaque agent lit alors cinq fois plus de texte que nécessaire, ralentit, coûte plus cher et perd le fil.

Pas de source de vérité unique. Si trois agents modifient tous le rapport, à qui appartient la version finale ? Les modifications contradictoires s'accumulent et personne n'est responsable.

Erreurs intraçables. Quand quelque chose dérape dans un free-for-all, vous ne pouvez pas dire quel agent en est la cause. Avec un orchestrateur, vous inspectez chaque handoff et voyez exactement où le chiffre de prix a dérapé.

La règle empirique pour 2026 : privilégiez la structure à la conversation. Que l'orchestrateur soit le seul à parler à tout le monde. Les workers restent dans leur couloir. Vous perdez un peu de « créativité » et gagnez beaucoup en fiabilité, en maîtrise des coûts et en débogabilité.

Quand *faut-il* laisser les agents converser ? Rarement, et seulement pour des tâches réellement ouvertes (un brainstorm, un débat) où vous cherchez des idées divergentes et où vous avez une limite stricte du nombre de tours. Pour accomplir une tâche, l'orchestrateur gagne.

Vérification des acquis

1. Quelle est la meilleure définition d'un système multi-agents selon la leçon ?

2. Dans le pattern orchestrateur-workers, quel est le rôle principal de l'orchestrateur ?

3. Pourquoi faire tourner trois agents de recherche en parallèle est-il important pour une tâche comme un rapport concurrentiel ?

CHOIX MULTIPLES

4. Sélectionnez TOUTES les bonnes réponses sur la façon dont le découpage entre plusieurs agents aide à dépasser les limites d'un agent unique.

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les bonnes réponses décrivant ce qu'est un « agent » au sens de cette leçon.

Sélectionnez toutes les réponses correctes.

Concevoir votre propre système multi-agents

Pas besoin de cinq agents pour démarrer. Utilisez cette checklist.

1. Un seul agent peut-il le faire suffisamment bien ?

Si un agent unique traite la tâche de façon fiable, arrêtez-vous là. Le multi-agents ajoute du coût et des pièces mobiles. Ne découpez que quand vous atteignez une vraie limite : trop de contexte, trop de compétences distinctes, ou un besoin de vitesse en parallèle.

2. Découpez par missions claires et séparables

Les bons découpages ont des frontières nettes. « Rechercher une entreprise » est séparable. « Rendre le rapport bon » ne l'est pas. Si deux workers ont sans cesse besoin des informations de l'autre, ils devraient sans doute n'être qu'un seul agent.

3. Choisissez la forme

  • Séquentielle (A puis B puis C) : bien pour les pipelines du type recherche → rédaction → relecture.
  • Parallèle (A, B, C en même temps, puis fusion) : bien pour des blocs indépendants comme nos trois chercheurs.
  • Orchestrateur-workers : un manager coordonne les deux formes ci-dessus. C'est votre option par défaut.

4. Écrivez des prompts étroits et des handoffs explicites

Pour chaque agent, répondez : quelle est ta mission unique ? Quelles informations reçois-tu ? Que renvoies-tu exactement ? Si vous ne pouvez pas répondre en une phrase à chaque question, le découpage est trop flou.

5. Ajoutez une condition d'arrêt

Plafonnez toujours la boucle. « Essaie au maximum 3 fois, puis renvoie ce que tu as. » Sans limites, les agents peuvent tourner indéfiniment. Cette seule ligne évite les histoires d'horreur de coûts qui dérapent.

Petit point de réalité sur le coût

Les systèmes multi-agents lancent plus d'appels modèle, donc ils coûtent plus cher par tâche qu'un agent unique. C'est l'arbitrage contre la fiabilité et la vitesse. Pour notre rapport VE, trois chercheurs en parallèle plus un rédacteur plus un orchestrateur, cela peut faire cinq à huit appels modèle au lieu d'un. Ça vaut le coup pour un rapport auquel vous faites réellement confiance. Pas pour « résume cet e-mail ».

Points clés

  • Découpez les tâches difficiles en missions étroites. Un orchestrateur planifie et délègue ; chaque worker possède une pièce clairement séparable. Si vous ne pouvez pas décrire la mission d'un agent en une phrase, le découpage est mauvais.
  • Faites tout passer par l'orchestrateur. Ne laissez pas les workers se parler librement. Les montages free-for-all provoquent des boucles de bavardage, un contexte qui enfle et des erreurs intraçables.
  • Concevez les handoffs pour ne transmettre que ce dont l'agent suivant a besoin. Le rédacteur reçoit les résumés de recherche, pas les notes de planification de l'orchestrateur.
  • Ajoutez toujours une condition d'arrêt. Plafonnez les tentatives et les tours pour qu'aucun agent ne tourne indéfiniment en brûlant votre budget.
  • Commencez avec un agent, découpez seulement quand vous atteignez une vraie limite. Plus d'agents signifie plus de coût et plus de pièces mobiles : méritez la complexité.

Articles liés

Les articles récents du blog qui s'appuient sur cette leçon.