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

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

Demandez à un agent IA unique de « m'écrire 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 arrive à court de contexte à mi-parcours. Le problème, c'est un seul agent qui essaie de tenir tout le travail dans sa tête.

Maintenant, découpez le travail. Un agent planifie. Trois agents recherchent chacun 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.

C'est cela 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 des limites réelles :

• Limite de contexte. Chaque agent dispose d'une quantité maximale de texte qu'il peut considérer d'un coup (sa « context windowcontext windowLa context window est la quantité maximale de texte (mesurée en tokens) qu'un modèle de langage peut traiter en une seule fois, prompt d'entrée et sortie générée compris.Voir la définition complète → »). Entassez-y la recherche brute sur trois entreprises et il commence à perdre des détails.
• Focalisation. Un agent avec 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) finissent environ trois fois plus vite qu'un agent qui les enchaîne.

Définition rapide : un agent désigne ici un LLMLLMUn Large Language Model est un système d'IA entraîné sur d'énormes volumes de texte pour prédire et générer du langage, ce qui permet de rédiger, résumer ou répondre à des questions.Voir la définition complète → (large language modellarge language modelUn Large Language Model est un système d'IA entraîné sur d'énormes volumes de texte pour prédire et générer du langage, ce qui permet de rédiger, résumer ou répondre à des questions.Voir la définition complète →, l'IA derrière des outils comme ChatGPT ou Claude) capable d'agir en boucle, d'appeler des tools 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 attribue 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 :

                 ┌─────────────────┐
                 │   ORCHESTRATOR  │  plans + delegates
                 └────────┬────────┘
          ┌───────────────┼───────────────┐
          ▼               ▼               ▼
   ┌────────────┐  ┌────────────┐  ┌────────────┐
   │ Researcher │  │ Researcher │  │ Researcher │   run in parallel
   │  (Tesla)   │  │  (Rivian)  │  │   (BYD)    │
   └──────┬─────┘  └──────┬─────┘  └──────┬─────┘
          └───────────────┼───────────────┘
                          ▼
                 ┌─────────────────┐
                 │      WRITER     │  produces final report
                 └─────────────────┘

Observez 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 nous reviendrons sur ses raisons.

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é) :

> Vous êtes un research manager. Découpez la demande de l'utilisateur en une tâche de recherche par entreprise. Envoyez chaque tâche à un researcher. Quand tous les résultats reviennent, envoyez-les au writer. Ne faites ni recherche ni rédaction vous-même.

Prompt du researcher :

> Vous recherchez exactement une entreprise. Trouvez : les prix actuels, les chiffres de ventes 2025, et un mouvement stratégique clé. Renvoyez un résumé court en puces avec les sources. Ne comparez pas aux autres entreprises.

Prompt du writer :

> Vous recevez des résumés de recherche sur plusieurs entreprises. Rédigez un rapport comparatif de 500 mots avec une recommandation. Utilisez 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. Des handoffs réussis et le système ronronne. Ratés, 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 la faire.

L'erreur classique est d'en transmettre trop ou trop peu. Si l'orchestrateur transmet à chaque researcher tout l'historique de conversation, vous gaspillez du contexte et vous embrouillez le worker. S'il ne transmet rien, le worker devine.

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

Voici un croquis vendor-neutral de la boucle d'orchestration en Python. C'est du pseudo-code, mais la forme est réelle :

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 passer QUE les résumés au writer
    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 de tools (chercher sur le web, lire les résultats, décider, recommencer) avant de renvoyer. L'orchestrateur ne se soucie pas de *comment* un researcher trouve les prix. Il se soucie seulement qu'un résumé propre revienne.

Tous les grands fournisseurs livrent des outils pour exactement ce pattern : l'OpenAI Agents SDK intègre les « 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 présentation é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.

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

Voici l'idée tentante : et si on supprimait l'orchestrateur et qu'on laissait tous les agents se parler ? Le researcher Tesla discute avec le researcher Rivian, le writer intervient avec des questions, tout le monde collabore.

En pratique, ce « free-for-all » (parfois appelé configuration multi-agents entièrement connectée ou conversationnelle) se dégrade vite. Les modes de défaillance sont constants :

Boucles de bavardage. Deux agents se figent dans la politesse. « Dois-je inclure les prix ? » « Oui, et dois-je inclure les ventes ? » « Bonne idée, et devrais-tu aussi… ? » Ils brbrLe pourcentage de visiteurs qui repartent après avoir vu une seule page, souvent le signe d'une pertinence insuffisante, d'un décalage d'intention ou d'une expérience utilisateur faible.Voir la définition complète →ûlent des tokenstokensUn token est l'unité de base de texte que traitent les modèles de langage : le plus souvent un fragment de mot, un mot entier ou un signe de ponctuation, plutôt qu'un simple caractère.Voir la définition complète → et de l'argent en tournant en rond. (Un tokentokenUn token est l'unité de base de texte que traitent les modèles de langage : le plus souvent un fragment de mot, un mot entier ou un signe de ponctuation, plutôt qu'un simple caractère.Voir la définition complète → est un fragment de texte traité par le modèle ; vous payez au tokentokenUn token est l'unité de base de texte que traitent les modèles de langage : le plus souvent un fragment de mot, un mot entier ou un signe de ponctuation, plutôt qu'un simple caractère.Voir la définition complète →.)

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 unique de vérité. Si trois agents éditent le rapport, qui possède la version finale ? Les modifications contradictoires s'accumulent et personne n'est responsable.

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

La règle pratique pour 2026 : préférez la structure à la conversation. Laissez l'orchestrateur être le seul à parler à tout le monde. Les workers restent dans leur couloir. Vous perdez un peu de « crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éativité » et gagnez beaucoup en fiabilité, en mamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète →îtrise des coûts et en débogage.

Quand *faut-il* laisser les agents converser ? Rarement, et seulement pour des tâches vraiment ouvertes (un brainstorm, un débat) où vous cherchez des idées divergentes et où vous fixez une limite ferme au nombre de tours. Pour l'exécution de tâches, l'orchestrateur gagne.

Concevoir votre propre système multi-agents

Vous n'avez pas besoin de cinq agents pour démarrer. Utilisez cette checklist.

1. Un seul agent peut-il faire l'affaire ?

Si un agent unique traite la tâche de façon fiable, arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êtez-vous là. Le multi-agents ajoute du coût et des pièces mobiles. Ne découpez que lorsque vous butez sur une limite réelle : trop de contexte, trop de compétences distinctes, ou un besoin de vitesse en parallèle.

2. Découpez selon des 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 l'un de l'autre, ils devraient probablement n'être qu'un seul agent.

3. Choisissez la forme

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

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

Pour chaque agent, répondez : quelle est votre mission unique ? Quelles informations recevez-vous ? Que renvoyez-vous exactement ? Si vous ne pouvez pas répondre en une phrase à chaque fois, le découpage est trop flou.

5. Ajoutez une condition d'arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êt

Plafonnez toujours la boucle. « Essayez 3 fois au maximum, puis renvoyez ce que vous avez. » Sans limites, les agents peuvent tourner indéfiniment. Cette seule ligne évite les histoires d'horreur de coûts qui s'emballent.

Un point rapide sur le coût

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

Points clés à retenir

• Découpez les tâches difficiles en missions étroites. Un orchestrateur planifie et délègue ; chaque worker possède un morceau 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 configurations 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 writer 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 à l'infini en brbrLe pourcentage de visiteurs qui repartent après avoir vu une seule page, souvent le signe d'une pertinence insuffisante, d'un décalage d'intention ou d'une expérience utilisateur faible.Voir la définition complète →ûlant votre budget.
• Commencez avec un agent, découpez seulement quand vous butez sur une limite réelle. Plus d'agents signifie plus de coût et plus de pièces mobiles : méritez la complexité.