Un cran au-delà d’orchestrateur-ouvriers : là-bas, les ouvriers étaient de simples appels LLM. Dans un système multi-agents, chaque participant est un agent complet — sa propre boucle, ses propres outils, son propre contexte — et un agent chef les coordonne vers un objectif.

L’analogie

Une équipe projet, pas un contremaître avec des manœuvres. Le chef de projet briefe un chercheur, un constructeur et un inspecteur. Chacun travaille en autonomie pendant des heures, avec son propre équipement, et remet ses conclusions — pas ses brouillons. Le chef ne voit jamais comment le chercheur a cherché ; il voit ce qui a été trouvé.

Le principe

flowchart TB
    L["agent chef — porte l'objectif, briefe & fusionne"] --> R["agent recherche + ses outils"]
    L --> C["agent code + ses outils"]
    L --> V["agent revue + ses outils"]
    R -->|trouvailles| L
    C -->|diff & tests| L
    V -->|verdict| L
  • Chaque sous-agent fait tourner sa propre boucle d’agent dans un contexte neuf — il peut prendre des dizaines de tours sans polluer personne.
  • La communication se fait aux frontières : un brief entre, un résumé sort. Le contexte du chef ne contient que des conclusions.
  • La spécialisation est réelle : chaque agent ne reçoit que les outils et consignes de son rôle — le relecteur peut lire mais pas modifier.

Un exemple concret

« Audite cette base de code pour les failles de sécurité » :

chef    → briefe 3 agents :
  agent A → parcourt les dépendances, vérifie les CVE connues (40 tours)
  agent B → fouille le code d'auth et de gestion des entrées   (60 tours)
  agent C → essaie d'exploiter réellement les trouvailles A+B  (30 tours)
chef    → fusionne : 2 failles confirmées, 5 fausses alertes écartées

Un seul agent qui ferait tout ça en série exploserait son contexte bien avant la fin ; trois agents restent chacun petits.

Quand l’utiliser

  • La tâche est trop grande pour un seul contexte, même avec de la mémoire — gros audits, migrations, balayages de recherche.
  • Les sous-tâches exigent des spécialistes vraiment différents (outils, permissions, consignes).
  • Une séparation adversariale aide : un agent produit, un autre vérifie indépendamment.

Quand l’éviter

  • La plupart des tâches. C’est le pattern le plus hypé et le plus sur-appliqué. Un bon agent bien outillé bat cinq agents médiocres qui se coordonnent.
  • Des sous-tâches qui ont sans cesse besoin de l’état intermédiaire des autres — les murs de briefing deviennent le goulot.
  • Les budgets serrés : chaque agent multiplie les coûts en tokens.

Le piège classique

Confondre conversation et progrès. Des agents qui « discutent » joyeusement entre eux brûlent des milliers de tokens à produire de la politesse, pas du travail. Structurez la collaboration comme une vraie équipe : briefs clairs, livrables définis, et un chef qui tranche — pas un chat de groupe.