Pourquoi découper une tâche complexe en plusieurs agents spécialisés bat presque toujours le « un gros prompt ». Fan-out parallèle, pipelines, vérification adverse, panels de juges, boucles jusqu'à épuisement — avec schémas, code, arbitrages de coût, et un cas réel.
Quand une tâche est simple — résumer un texte, classer un e-mail, extraire un champ — un seul appel à un modèle suffit. Mais dès que le travail devient complexe, ouvert et composé de sous-problèmes hétérogènes, le réflexe du « un gros prompt qui fait tout » se heurte à trois murs : la fenêtre de contexte sature, le modèle mélange des objectifs contradictoires, et il n'existe aucun garde-fou interne pour repérer ses propres erreurs.
L'orchestration multi-agents répond à cela en décomposant le problème en rôles : des agents spécialisés travaillent en parallèle ou en chaîne, un orchestrateur assemble leurs sorties, et — c'est le point critique — d'autres agents vérifient le travail de façon adverse avant qu'il ne soit publié. C'est la même logique qu'une équipe humaine : on ne demande pas à une seule personne d'être à la fois chercheur, rédacteur, relecteur et directeur de la publication.
Un agent, ici, c'est un appel à un modèle de langage à qui l'on confie un rôle précis, ses propres instructions, et éventuellement des outils. Un workflow multi-agents est simplement un programme qui orchestre plusieurs de ces appels — qui décide lesquels lancer, dans quel ordre, et comment combiner leurs réponses. Le code que vous écrivez n'est pas « intelligent » : il joue le rôle de chef d'orchestre.
Avant de multiplier les agents, il faut savoir qu'on n'en a pas toujours besoin. Il existe une échelle de complexité, et chaque marche coûte plus cher en tokens et en latence que la précédente. La règle d'or : commencer au niveau le plus simple qui résout le problème.
| Niveau | Quand l'utiliser | Qui pilote la boucle |
|---|---|---|
| Appel unique | Classification, résumé, extraction, Q&R — une entrée, une sortie | Personne, il n'y a pas de boucle |
| Workflow | Pipeline multi-étapes dont la logique est connue d'avance et déterministe | Votre code — vous enchaînez les appels |
| Agent (outils) | Trajectoire ouverte : le modèle décide quels outils appeler et dans quel ordre | Le modèle, dans une boucle d'appels d'outils que vous hébergez |
| Multi-agents | Plusieurs trajectoires parallèles, ou besoin de vérification croisée indépendante | Un orchestrateur (votre code ou un agent coordinateur) |
La distinction workflow vs agent est centrale. Un workflow a une structure figée : « recherche → rédaction → vérification → publication ». Votre code connaît les étapes ; le modèle ne fait que remplir chaque case. Un agent, au contraire, décide lui-même de sa trajectoire — il choisit ses outils, itère, et s'arrête quand il juge avoir fini. Les deux se combinent : la plupart des systèmes multi-agents robustes sont des workflows déterministes dont certaines étapes sont elles-mêmes des agents.
Avant de construire un agent (et a fortiori plusieurs), vérifiez : la tâche est-elle vraiment complexe et difficile à spécifier d'avance ? La valeur du résultat justifie-t-elle un coût et une latence plus élevés ? Le modèle est-il capable de la traiter ? Et le coût d'une erreur est-il rattrapable (tests, relecture, rollback) ? Si une réponse est « non », restez sur un workflow ou un appel unique.
Presque tous les systèmes multi-agents se ramènent à cinq motifs de base, que l'on compose. Voici chacun avec son schéma, son cas d'usage, et le code conceptuel qui l'implémente.
L'orchestrateur découpe une question large en N sous-questions indépendantes et lance N agents en parallèle, chacun avec sa propre fenêtre de contexte. Au lieu de payer la latence cumulée de N recherches séquentielles, on paie celle de la plus lente. C'est le pattern qui transforme une recherche de plusieurs minutes en une recherche de quelques secondes.
# Pseudo-code — fan-out parallèle puis synthèse async def recherche_eventail(sujet): sous_themes = await orchestrateur("Découpe ce sujet en 3-6 axes indépendants", sujet) # Lance tous les agents en parallèle — un contexte frais chacun rapports = await gather(*[ agent_recherche(theme, modele="claude-sonnet-4-6") # modèle rapide pour le fan-out for theme in sous_themes ]) # Fan-in : un agent plus capable synthétise return await agent_synthese(rapports, modele="claude-opus-4-8")
Affectez un modèle rapide et économique (Sonnet 4.6, voire Haiku 4.5) aux agents de fan-out, qui font un travail cadré et répétitif, et réservez le modèle le plus capable (Opus 4.8) à l'orchestrateur et à la synthèse, là où le jugement compte. On parle de « routage par capacité » : la bonne marche pour chaque sous-tâche.
Ici les agents sont en série : la sortie de l'un devient l'entrée du suivant. Chaque étape a une responsabilité unique et un format de sortie bien défini. C'est le motif des lignes de production : extraction → enrichissement → mise en forme → contrôle qualité.
Le pipeline brille quand chaque étape a besoin d'instructions très différentes. Le séparer en agents distincts évite que les consignes de l'étape 1 « polluent » le raisonnement de l'étape 3, et permet de remplacer ou tester une étape isolément sans toucher au reste.
C'est le pattern le plus sous-utilisé et le plus rentable. Après qu'un agent a produit un résultat, un second agent au rôle explicitement contradictoire est chargé de le démolir : trouver les failles, les hypothèses non vérifiées, les chiffres inventés. Le point clé est qu'il raisonne dans une fenêtre de contexte fraîche — il ne voit pas (ou peu) le raisonnement de l'auteur, donc il n'hérite pas de ses angles morts.
# Pseudo-code — war room : auteur puis vérification adverse analyse = await agent_auteur(donnees) # Le vérificateur reçoit la sortie, PAS le raisonnement de l'auteur critique = await agent_adverse( sortie=analyse.conclusion, role="Tu es un risk manager hostile. Liste les failles, " "les chiffres non sourcés et les biais. Sois impitoyable.", outils=[verifier_chiffre, chercher_source] ) if critique.failles_bloquantes: analyse = await agent_auteur(donnees, retour=critique) # une passe de correction
Si vous demandez au même agent, dans le même contexte, de vérifier son propre travail, il a déjà « décidé » que sa conclusion était bonne — il va surtout la justifier. Un agent neuf, sans accès au raisonnement initial, attaque le résultat sans complaisance. C'est la différence entre se relire soi-même et faire relire par un collègue qui n'a rien vu.
Quand il existe plusieurs réponses candidates — soit parce que plusieurs agents ont travaillé en parallèle, soit parce qu'on a généré plusieurs variantes — un panel de juges les note indépendamment selon une grille (rubrique) explicite. On agrège ensuite par vote majoritaire, par score moyen, ou en gardant la meilleure. Des juges indépendants réduisent le bruit d'un juge unique et rendent la décision auditable.
| Stratégie d'agrégation | Quand l'utiliser |
|---|---|
| Vote majoritaire | Réponses discrètes (classification, oui/non, choix d'un candidat) |
| Score moyen sur rubrique | Sorties à évaluer sur plusieurs critères pondérés |
| « Best-of-N » | Génération créative : on garde la meilleure variante selon les juges |
Un agent « critique de complétude » relit le résultat et répond à une seule question : « reste-t-il quelque chose d'important à couvrir ? ». Tant que la réponse est oui, l'orchestrateur relance le générateur sur ce qui manque. La boucle s'arrête lorsque le critique ne trouve plus rien — d'où « jusqu'à épuisement ». Un compteur d'itérations maximum évite les boucles infinies.
# Pseudo-code — boucle pilotée par un critique de complétude resultat = await agent_generateur(tache) for i in range(MAX_ITER): # garde-fou anti-boucle infinie verdict = await agent_critique( resultat, rubrique="Liste UNIQUEMENT les manques importants. " "Si rien ne manque, réponds {complet: true}." ) if verdict.complet: break resultat = await agent_generateur(tache, a_combler=verdict.manques)
Un critique de complétude efficace ne réécrit jamais le travail : il liste seulement ce qui manque, dans un format structuré que l'orchestrateur peut lire. Mélanger « critiquer » et « réécrire » dans le même agent brouille les deux et rend la boucle instable. Une responsabilité, une sortie.
Ces patterns ne sont pas théoriques : c'est exactement ainsi que ce site sélectionne et valide ses idées de trading. Le pipeline du scanner combine fan-out parallèle, pipeline en étapes, war room de vérification et critique de complétude. Voici la trajectoire d'un setup, du screening brut à la publication.
Chaque agent a un rôle si étroit qu'on peut le tester seul. L'anti-dilution, par exemple, est un vérificateur dédié : il lit les documents réglementaires et ne renvoie qu'un verdict structuré (« risque toxique : oui/non, sources »). Si un setup passe le scoring mais échoue à la war room, il est bloquant — il ne sera jamais publié, peu importe son score. C'est la vérification adverse qui empêche un beau graphique de masquer un risque caché.
Les agents ne « devinent » pas les chiffres : ils interrogent une passerelle d'outils via le protocole MCP (Model Context Protocol). MCP est un standard ouvert qui expose des serveurs d'outils — données de marché, screeners, métriques de risque — que le modèle découvre et appelle au besoin. Un chiffre non vérifiable par un outil est traité comme suspect par la war room. C'est ce qui distingue une analyse sourcée d'une hallucination bien tournée.
Le piège du débutant est d'écrire un prompt géant qui décrit tout. À l'inverse, chaque agent multi-agents doit avoir des instructions courtes et mono-rôle. Décrivez surtout quand l'agent doit agir et avec quel objectif, pas seulement ce qu'il fait. Les modèles récents suivent les consignes de façon très littérale : un prompt avec « TU DOIS ABSOLUMENT… » provoque du sur-déclenchement. Préférez « Utilise tel outil lorsque… ».
Le ciment d'un workflow multi-agents, c'est le format de sortie. Si chaque agent renvoie du texte libre, l'orchestrateur doit le re-parser à chaque fois — fragile. En contraignant la sortie à un schéma JSON, l'orchestrateur lit directement des champs typés. C'est ce qui rend la boucle « critique → générateur » fiable : le verdict du critique est un objet, pas une dissertation.
# Schéma de sortie du critique de complétude (JSON Schema) { "type": "object", "properties": { "complet": { "type": "boolean" }, "manques": { "type": "array", "items": { "type": "string" } # un manque par entrée }, "severite": { "type": "string", "enum": ["basse", "moyenne", "haute"] } }, "required": ["complet", "manques"], "additionalProperties": false }
Côté API, on obtient cette garantie en passant un schéma de sortie à la requête plutôt qu'en espérant que le modèle « pense » à renvoyer du JSON. La sortie est alors validée automatiquement contre le schéma. Conceptuellement :
# Pseudo-code — sortie contrainte par un schéma + routage par modèle verdict = client.messages.create( model="claude-opus-4-8", # jugement = modèle capable output_config={"format": {"type": "json_schema", "schema": SCHEMA_CRITIQUE}}, messages=[{"role": "user", "content": rapport}], ) # verdict suit le schéma — l'orchestrateur lit verdict["complet"] sans re-parsing fragile
Le principal échec d'un système multi-agents naïf, c'est de tout entasser dans une seule fenêtre. Les contre-mesures :
Ce site est lui-même piloté par Claude Code, l'outil agentique en ligne de commande d'Anthropic (disponible aussi en desktop, sur le web et en extensions d'IDE). Claude Code sait lancer des sous-agents, se connecter à des serveurs MCP, exécuter des hooks et des commandes personnalisées (les « skills ») — c'est-à-dire exactement la boîte à outils nécessaire pour composer dynamiquement les workflows décrits ici. La war room du scanner, par exemple, est un panel de sous-agents au rôle adverse, coordonné par un agent orchestrateur.
L'orchestration multi-agents n'est pas gratuite. Chaque agent supplémentaire est un appel facturé, et chaque étape en série rallonge la latence. Voici la grille de décision honnête.
| Dimension | Effet du multi-agents | Atténuation |
|---|---|---|
| Coût (tokens) | ↑ N appels au lieu d'un — peut être plusieurs fois plus cher | Routage par modèle (Haiku/Sonnet pour le fan-out), cache de préfixe |
| Latence — parallèle | ↓ Le fan-out réduit la latence : on attend le plus lent, pas la somme | Maximiser ce qui peut tourner en parallèle |
| Latence — série | ↑ Un pipeline en 5 étapes = 5 allers-retours cumulés | Fusionner les étapes peu coûteuses ; ne sérialiser que le nécessaire |
| Complexité | ↑ Plus de pièces = plus de modes de panne (timeout, sortie mal formée) | Sorties structurées + garde-fous d'itération + journalisation |
| Qualité | ↑↑ La vérification adverse rattrape des erreurs qu'un seul agent ne voit pas | C'est le gain principal — à réserver aux sorties à fort enjeu |
Sur une tâche simple et bien spécifiée (classer, résumer, extraire), un appel unique est presque toujours plus rapide, moins cher et tout aussi bon. Multiplier les agents y ajoute du coût et des points de panne sans gain de qualité. De même, si le coût d'une erreur est nul ou trivialement corrigeable, la war room ne se justifie pas. Le multi-agents se mérite : il faut un vrai problème de complexité, de parallélisme, ou de vérification croisée.
Illustration conceptuelle : quatre recherches puis une synthèse. En séquentiel, les latences s'additionnent ; en fan-out parallèle, on n'attend que la recherche la plus lente avant la synthèse.
1. Pourquoi un agent vérificateur doit-il raisonner dans un contexte « frais » ?
Parce qu'un agent qui voit le raisonnement de l'auteur hérite de ses
biais et tend à justifier la conclusion plutôt qu'à la remettre en cause. Une fenêtre fraîche permet
une critique réellement adverse.
2. Quand le fan-out parallèle réduit-il la latence, et quand ne le fait-il pas ?
Il la réduit quand les sous-tâches sont indépendantes (on attend la plus
lente). Il n'aide pas si chaque étape dépend de la précédente — c'est alors un pipeline en série, par
définition séquentiel.
3. Pourquoi imposer un schéma de sortie aux agents ?
Pour que l'orchestrateur lise des champs typés au lieu de re-parser du
texte libre. C'est ce qui rend les boucles (critique → générateur) et les panels de juges fiables et
automatisables.
4. Citez un cas où il ne faut PAS utiliser le multi-agents.
Une tâche simple et bien spécifiée (classification, résumé court) dont
l'erreur est sans conséquence : un appel unique est plus rapide, moins cher, et aussi bon.
Ce guide est pédagogique et technique. Le pipeline du scanner DailyTickers décrit ici sélectionne des idées de trading à titre informatif — ceci n'est pas un conseil financier. Les exemples de code sont conceptuels et destinés à illustrer les patterns d'orchestration ; adaptez-les à votre stack et à la documentation officielle de votre fournisseur de modèle avant tout usage en production. Les performances passées ne préjugent pas des résultats futurs.