L’orchestre des agents de code — comment faire vraiment fonctionner le codage multi-agents

• La transition est en cours en 2026, passant d’un mode de collaboration avec un seul assistant IA dans une boucle synchrone à un modèle d’orchestrateur où plusieurs agents fonctionnent de manière asynchrone, chacun avec sa propre fenêtre de contexte et sa propre portée de fichiers
• Trois grands patterns — les subagents (Subagents), les équipes d’agents (Agent Teams) et la délégation hiérarchique — constituent l’architecture de base du codage multi-agents, avec des effets respectifs en matière de parallélisme, de spécialisation, d’isolation et d’apprentissage composé
• Les listes de tâches partagées et la messagerie peer-to-peer sont les principaux mécanismes de coordination des équipes d’agents, permettant la levée automatique des dépendances et l’évitement des goulots d’étranglement
• En 2026, l’écosystème des outils se divise en trois couches : les subagents in-process (Tier 1), les orchestrateurs locaux (Tier 2) et les agents asynchrones cloud (Tier 3), la plupart des développeurs combinant les trois selon les usages
• Le goulot d’étranglement s’est déplacé de la génération de code vers la vérification (Verification), et les points de contrôle qualité via l’approbation des plans, les hooks et AGENTS.md, ainsi que la revue humaine, sont devenus les éléments clés de la fiabilité des systèmes multi-agents

---

La transition actuelle : du chef d’orchestre à l’orchestrateur

• Il y a encore 6 mois, la plupart des développeurs travaillaient de façon synchrone avec un seul assistant IA, et une seule fenêtre de contexte fixait la limite supérieure du travail possible
• Aujourd’hui, les développeurs les plus productifs passent à une coordination asynchrone de plusieurs agents, chacun disposant de sa propre fenêtre de contexte, de sa propre portée de fichiers et de son propre domaine de responsabilité
• Modèle Conductor : guider un agent unique en temps réel de manière synchrone ; Claude Code CLI et le mode agent dans l’éditeur Cursor en sont les outils représentatifs
• Modèle Orchestrator : coordonner de façon asynchrone plusieurs agents, chacun avec sa propre fenêtre de contexte ; Agent Teams, Conductor, Codex et Copilot Coding Agent en sont les outils représentatifs
• En tant qu’orchestrateur, de nouvelles compétences sont nécessaires : rédiger des spécifications claires, découper le travail et vérifier les livrables

Les 8 niveaux du codage assisté par IA

• [Orchestration]
  • L8 — Construire son propre orchestrateur : implémenter soi-même la couche de coordination en codant directement la création, le routage et la gestion des agents
  • L7 — 10 agents ou plus, gestion manuelle : « Aïe, c’est devenu le chaos. » Le mauvais contexte est transmis au mauvais agent, et la question « Que se passe-t-il si Claude Code exécute Claude Code ? » commence à se poser
  • L6 — Multiplexage d’agents : lassé d’attendre, on lance les agents un par un en plus, puis on passe d’un flux à l’autre sans pouvoir s’arrêter
• [Agent-first]
  • L5 — Agent d’abord, IDE ensuite : la conversation avec l’agent devient l’espace de travail principal, l’IDE servant surtout à vérifier le code
  • L4 — La conversation prend le dessus, le diff disparaît : on ne relit plus chaque diff, on observe le comportement de l’agent et on se concentre sur l’orientation à donner
• [Ère de l’IDE]
  • L3 — Mode YOLO : l’agent s’exécute librement dans l’IDE, la confiance augmente
  • L2 — Agent dans l’IDE, approbation manuelle des permissions : chaque modification de fichier est autorisée manuellement, avec un contrôle entièrement manuel
  • L1 — Pas d’IA : workflow de développement traditionnel
• Selon le framework en 8 niveaux d’usage des outils IA résumé par Steve Yegge, la plupart des développeurs restent au niveau 3 à 4
• La couche d’orchestration commence au niveau 6 et exige un ensemble de compétences fondamentalement différent de celui nécessaire pour monter jusqu’au niveau 5
• Ce contenu traite des niveaux 5 à 8

Les limites d’un agent unique

• Surcharge de contexte : un agent unique est limité dans la quantité d’informations qu’il peut contenir, et une codebase de grande taille dépasse la capacité d’une seule fenêtre de contexte
• Absence de spécialisation : un agent qui gère à la fois la couche data, l’API, l’UI et les tests n’est qu’un généraliste ; un agent dédié uniquement à la couche data écrira un code DB bien meilleur
• Absence de coordination : même en ajoutant des agents auxiliaires, ils ne peuvent ni communiquer entre eux, ni partager des tâches, ni résoudre des dépendances ; plus on augmente le nombre d’agents sans primitives de coordination, plus la gestion devient difficile
• Les subagents résolvent les deux premiers problèmes, tandis que les équipes d’agents résolvent les trois

Pourquoi le multi-agents

• Parallélisme (débit x3) : les agents frontend, backend et test travaillent simultanément
• Spécialisation (contexte ciblé) : chaque agent ne connaît que les fichiers dont il a la charge ; un agent qui ne connaît que db.js écrira un meilleur code DB qu’un agent traitant toute la codebase
• Isolation (exécution sûre) : les Git worktrees fournissent à chaque agent un répertoire de travail indépendant, sans conflit de fusion
• Apprentissage composé : les fichiers AGENTS.md accumulent les patterns et points d’attention d’une session à l’autre, de sorte que chaque session améliore la suivante
• Trois agents focalisés obtiennent de manière constante de meilleurs résultats qu’un seul agent généraliste travaillant trois fois plus longtemps

Pattern 1 : les subagents — délégation ciblée

• Utiliser l’outil Task pour créer des agents enfants spécialisés depuis l’orchestrateur parent ; c’est le pattern multi-agents le plus simple, à essayer en premier
• Exemple concret : si l’on demande à Claude Code de « construire Link Shelf, un gestionnaire de signets avec Express et SQLite », l’orchestrateur parent le décompose en trois briefs pour subagents
  • Subagent couche data : construire db.js, puis rédiger le rapport DATA.md
  • Subagent logique métier : construire validation.js, puis rédiger le rapport LOGIC.md
  • Subagent routes API : lire DATA.md et LOGIC.md, puis construire server.js
• Les deux premiers subagents s’exécutent indépendamment en parallèle, le troisième ne démarre qu’une fois les deux rapports terminés ; le parent gère manuellement le graphe de dépendances
• Limites des subagents : le parent doit gérer manuellement le graphe de dépendances, il n’existe ni messagerie peer-to-peer ni liste de tâches partagée entre agents ; si la portée des fichiers est mal gérée, des conflits peuvent survenir
• Environ 220 000 tokens au total, pour un coût globalement neutre

• Subagents hiérarchiques (des équipes d’équipes)

  • Au lieu de créer directement 6 subagents, l’orchestrateur crée 2 responsables de fonctionnalité, chacun générant ensuite 2 à 3 spécialistes de son côté
  • L’orchestrateur parent ne gère que deux agents, ce qui maintient un contexte propre ; le responsable de fonctionnalité A reçoit le brief « construire la fonctionnalité de recherche » et le décompose lui-même
  • Le principe est identique au fonctionnement d’une véritable organisation d’ingénierie : un VP n’assigne pas directement des tâches à chaque ingénieur, il passe par les tech leads

Motif 2 : les équipes d’agents — le vrai parallélisme

• Fonction expérimentale de Claude Code, activable avec la commande export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
• Architecture à 3 couches :
  • Team Lead : décomposition du travail, création de la liste de tâches, synthèse des résultats
  • Liste de tâches partagée : suivi des statuts (pending, in_progress, completed, blocked), des dépendances et verrouillage de fichiers
  • Coéquipiers : chacun exécute sa propre instance indépendante de Claude Code, dispose de sa propre fenêtre de contexte et fonctionne dans des panneaux tmux divisés
• Les coéquipiers choisissent de manière autonome leurs tâches dans la liste partagée et communiquent directement via une messagerie peer-to-peer sans passer par le lead
• Lorsqu’un coéquipier marque une tâche comme terminée, les tâches bloquées qui en dépendaient sont automatiquement débloquées
• Ctrl+T permet d’activer ou désactiver l’overlay visuel de la liste de tâches

• Mécanismes clés des équipes d’agents

  • Liste de tâches partagée : quand l’agent backend marque l’API de recherche comme terminée, la tâche bloquée de rédaction des tests repasse automatiquement à l’état pending ; le verrouillage de fichiers empêche les modifications simultanées
  • Messagerie peer-to-peer : l’agent backend transmet directement à l’agent frontend le contrat d’API — "GET /search?q= returns [{id,title,url}]" ; cela évite que le lead devienne un goulot d’étranglement de coordination
  • Lorsqu’un coéquipier devient inactif, le lead en est automatiquement informé

• Recommandations clés pour les équipes d’agents

  • 3 à 5 coéquipiers constituent le point optimal ; le coût en tokens augmente linéairement avec la taille de l’équipe
  • Approbation du plan : quand un coéquipier rédige un plan avant l’implémentation, le lead peut le relire puis l’approuver ou le rejeter ; détecter les problèmes d’architecture avant même que le code existe coûte bien moins cher
  • Trois coéquipiers concentrés obtiennent de manière constante de meilleurs résultats que cinq coéquipiers dispersés

• Conseils de fiabilité pour les équipes d’agents

  • Garde-fous de boucle + étape de réflexion : définir un plafond MAX_ITERATIONS=8 pour tous les coéquipiers ; avant chaque nouvelle tentative, imposer un prompt de réflexion du type "Qu’est-ce qui a échoué ? Quel changement concret corrigerait cela ? Suis-je en train de répéter la même approche ?" → forte baisse des agents bloqués
  • Coéquipier @reviewer dédié : attribuer à Claude Opus 4.6 (lecture seule) le rôle de reviewer, avec usage exclusif des outils de lint, de test et de scan de sécurité, déclenché automatiquement à chaque événement TaskCompleted ; ratio d’un reviewer pour 3 à 4 builders ; le lead ne reçoit ainsi que du code déjà relu

Motif 3 : l’orchestration à l’échelle

• Lorsqu’il faut gérer 5, 10, 20 agents ou plus à travers plusieurs dépôts et fonctionnalités, il faut un outil d’orchestration dédié
• Tier 1 — sous-agents et équipes in-process : sous-agents et équipes d’agents Claude Code ; une seule session terminal, aucun outil supplémentaire requis ; c’est par là qu’il faut commencer
• Tier 2 — orchestrateurs locaux : exécution de plusieurs agents dans des worktrees indépendants, avec conservation d’un dashboard, de la revue de diff et du contrôle de fusion ; optimal pour 3 à 10 agents sur une base de code connue ; Conductor, Vibe Kanban, Gastown, OpenClaw + Antfarm, Claude Squad, Antigravity, Cursor Background Agents
• Tier 3 — agents cloud asynchrones : on assigne une tâche, on ferme son laptop et on attend la PR ; exécution sur des VM cloud ; Claude Code Web, GitHub Copilot Coding Agent, Jules by Google, Codex Web by OpenAI
• En 2026, la plupart des développeurs utiliseront les trois couches : Tier 1 (travail interactif), Tier 2 (sprints parallèles), Tier 3 (traitement nocturne du backlog)

Zoom sur les outils

• Conductor by Melty Labs

  • Le moyen le plus rapide de se lancer dans l’orchestration multi-agents sur Mac ; exécute plusieurs agents Claude Code et Codex en parallèle dans des git worktrees indépendants
  • Fournit un dashboard visuel et une UI de revue orientée diff ; seul le coût API est à votre charge (gratuit) ; macOS uniquement (Apple Silicon et Intel)
  • Idéal lorsqu’il faut développer en parallèle 3 à 8 fonctionnalités dans le même dépôt avec un besoin de supervision visuelle

• Claude Code Web

  • Accessible via claude.ai/code ; entièrement basé navigateur, sans terminal ; après connexion d’un dépôt GitHub et saisie de la description de tâche, l’exécution se fait sur une VM cloud gérée par Anthropic
  • Prend en charge le pilotage intermédiaire, la création automatique de PR et l’accès via l’app iOS
  • Les équipes (terminal) travaillent avec les agents, tandis que le Web (navigateur) permet de déléguer puis de s’absenter

• GitHub Copilot Coding Agent

  • À distinguer du mode agent Copilot dans l’IDE, qui est synchrone et interactif ; le Copilot Coding Agent de GitHub est entièrement asynchrone
  • On peut assigner n’importe quelle issue GitHub à @copilot ou le lancer depuis le panneau Agents → création d’une draft PR dans un environnement GitHub Actions
  • Exécute sa propre boucle de review avant le tagging ; des agents tiers comme Claude Code et Codex sont aussi accessibles depuis le même panneau ; déclenchement possible depuis Slack, Jira, Linear et Azure Boards

• Jules by Google

  • Agent de cloud coding asynchrone de Google, basé sur Gemini ; connexion d’un dépôt GitHub → description de tâche → génération du plan par Jules → exécution après approbation sur une VM cloud → retour d’une PR avec le raisonnement complet et les logs terminal
  • Propose un changelog audio, l’arrêt de tâches en cours et un Jules Tools CLI pour envoyer directement des issues GitHub
  • Lit automatiquement le AGENTS.md du dépôt sans configuration supplémentaire

• OpenAI Codex Web

  • Chaque tâche s’exécute dans un conteneur sandbox indépendant avec le dépôt GitHub préchargé
  • Dispose d’un écosystème de surfaces reliant Web, CLI (open source), app macOS, extension IDE et intégration GitHub à un compte ChatGPT
  • La fonction Verifiable Evidence renvoie, pour chaque tâche, des citations des logs terminal et des sorties de test, ce qui permet d’auditer l’historique d’exécution

• Cursor Cloud Agents + Glass

  • Permet de lancer des agents depuis le Web, l’app desktop, Slack, Linear, GitHub, l’API et une PWA (installation via cursor.com/agents)
  • Glass : nouvelle interface de Cursor, qui fait de la gestion des agents l’écran principal et relègue l’éditeur historique au rang d’outil secondaire accessible au besoin
  • Reflète une tendance où, dans tout l’écosystème, le control plane devient l’expérience principale et l’éditeur un simple instrument parmi d’autres

• Vibe Kanban

  • Résout le "doomscrolling gap" (les 2 à 5 minutes de vide pendant que l’agent travaille) ; après création d’une carte de tâche, un glisser-déposer vers "In Progress" crée pour chacun sa worktree et sa branche
  • Permet de relire les diff et d’envoyer des retours aux agents en cours d’exécution depuis le board ; prend en charge Claude Code, Codex, Gemini CLI, Amp, Cursor Agent CLI, etc. ; multiplateforme (Mac, Windows, Linux), gratuit, BYOK

Conseils pour passer à l’échelle

• Routage multi-modèles

  • Le modèle le plus coûteux n’est pas nécessaire pour toutes les tâches ; créez un fichier MODEL_ROUTING.md pour définir un routage par rôle :
    • Planification et architecture → modèles Gemini/Claude/OpenAI moins coûteux
    • Implémentation → Sonnet, Opus ou Codex
    • Revue → modèle de sécurité dédié

• Scripts de cycle de vie des worktrees

  • Automatisez les tâches répétitives avec trois alias shell :
    • agent-spin <feature> : crée une worktree + une branche + lance l’agent
    • agent-merge <feature> : rebase + revue + création de PR
    • agent-clean : supprime les worktrees terminées
  • Environ 12 lignes de bash ; Conductor s’en charge visuellement

• N’autoriser que des AGENTS.md rédigés par des humains

  • Une étude de Gloaguen et al. à l’ETH Zurich a montré que les fichiers AGENTS.md générés par des LLM n’apportent aucun bénéfice, provoquent en moyenne une baisse du taux de réussite d’environ 3 % et augmentent le coût d’inférence de plus de 20 %
  • Les fichiers de contexte rédigés par des développeurs apportent un gain de performance d’environ 4 %
  • Ne laissez jamais un agent écrire directement dans AGENTS.md ; le lead doit approuver chaque ligne
  • Restez concis avec des sections claires : STYLE, GOTCHAS, ARCH_DECISIONS, TEST_STRATEGY

Garde-fous qualité : faire confiance, mais vérifier

• Trois garde-fous qualité

  • Validation du plan : un coéquipier rédige un plan avant de commencer à coder → le lead le relit, l’approuve ou le rejette → implémentation ; corriger un mauvais plan coûte bien moins cher que corriger un mauvais code
  • Hooks : contrôles automatisés sur les événements du cycle de vie ; le hook TeammateIdle vérifie que tous les tests passent avant qu’un agent n’arrête de travailler ; le hook TaskCompleted lance le lint et les tests avant de marquer une tâche comme terminée ; si un hook échoue, l’agent continue à travailler jusqu’à réussir
  • Apprentissage cumulatif via AGENTS.md : capture les patterns découverts, les points d’attention et les préférences de style ; tous les agents le lisent au début de la session et il est enrichi à chaque session

• Le goulot d’étranglement se déplace vers la vérification

  • Les agents peuvent produire des résultats impressionnants à une vitesse étonnante ; la difficulté est d’être sûr que ces résultats sont corrects
  • Le fait que des tests passent avant un changement ne garantit pas qu’ils détecteront les régressions causées par ce changement
  • Les agents peuvent écrire des tests techniquement valides mais qui passent à côté de cas importants
  • En raison des limites de fenêtre de contexte, des agents travaillant sur de grandes bases de code peuvent manquer des contraintes importantes situées hors de leur vue actuelle
  • Un environnement instable, simple edge case agaçant pour un développeur seul, devient un bloqueur systémique quand 40 agents se heurtent simultanément au même test instable
  • Tant que l’infrastructure de vérification n’a pas rattrapé les capacités de génération, la revue humaine n’est pas un coût optionnel mais un système de sécurité

Ralph Loop et les agents auto-améliorants

• Le pattern Ralph Loop

  • Popularisé par Geoffrey Huntley et Ryan Carson ; le pattern derrière le « shipping pendant qu’on dort » ; l’outil indépendant de Carson, ralph (snarktank/ralph), implémente la boucle centrale, tandis que le projet Antfarm ajoute une orchestration multi-agents au-dessus d’OpenClaw
  • Cycle en 5 étapes : Pick (sélection de la tâche suivante dans tasks.json) → Implement (effectuer les changements) → Validate (lancer tests, types et lint) → Commit (committer si les vérifications passent et mettre à jour l’état de la tâche) → Reset (réinitialiser le contexte de l’agent avant de passer à la tâche suivante)
  • Idée clé : réinitialiser à chaque itération évite l’accumulation de confusion ; des tâches petites et bien délimitées produisent moins d’hallucinations et un code plus propre qu’un unique prompt géant
  • Mesures de sécurité : renvoyer les erreurs comme feedback pour permettre les nouvelles tentatives automatiques, mais arrêter et réassigner après plus de 3 blocages ; toujours travailler sur une feature branch ; fixer des plafonds d’itérations, de temps et de tokens ; l’agent crée la PR → revue humaine avant fusion
  • Conserver 4 canaux mémoire entre les réinitialisations de contexte : l’historique des commits git, le journal d’avancement, le fichier d’état des tâches (tasks.json) et AGENTS.md comme mémoire sémantique de long terme

• Rendre les agents plus intelligents au fil du temps

  • Auto-réflexion via REFLECTION.md : après chaque tâche, imposer l’écriture de « ce qui a surpris, un pattern à ajouter à AGENTS.md, une amélioration de prompt » ; le lead relit et fusionne les apprentissages approuvés
  • Budget de tokens et critères d’arrêt : définir un plafond par agent (ex. front-end 180 000 tokens, back-end 280 000 tokens) ; pause automatique à 85 % du budget et alerte au lead ; mettre fin après plus de 3 blocages sur la même erreur et réassigner à un nouvel agent
  • Beads / mémoire persistante : le pattern « beads » de Gastown — un enregistrement immuable, basé sur git, de toutes les décisions et résultats avec provenance complète ; les agents consultent les beads passées via un graphe de tâches et un data plane interrogeable en SQL ; non pas un simple RAG vectoriel, mais une mémoire institutionnelle structurée et interrogeable

La discipline qui fait fonctionner tout cela

• Le goulot d’étranglement humain n’était pas un bug, mais une fonctionnalité

  • Quand on écrit du code à vitesse humaine, on ressent la douleur tôt ; tests qui échouent, remarques en code review, duplications découvertes — la douleur est immédiate, donc on corrige en avançant
  • Dans une armée d’agents orchestrés, il n’y a pas de goulot d’étranglement naturel ; de petites erreurs (odeurs de code, duplication, abstractions inutiles) s’amplifient de façon cumulative à une vitesse impossible à rattraper
  • Comme on est sorti de la boucle, on ne ressent la douleur que lorsque l’architecture ne permet plus d’ajouter de nouvelles fonctionnalités
  • Toutes les barrières qualité (validation du plan, hooks, budget de tokens, revue humaine) existent pour cette raison : sans elles, le codage par agents vous conduit vous-même dans une impasse

• Déléguer les tâches, garder le jugement

  • À confier aux agents : tâches bien délimitées avec critères de réussite/échec clairs, boilerplate, migrations, scaffolding de tests, exploration d’approches que vous n’avez pas le temps d’essayer vous-même
  • À garder pour soi : architecture et design d’API (les agents ont appris beaucoup de mauvaises architectures dans leurs données d’entraînement et peuvent plaquer des patterns enterprise sur une startup), la décision de ce qu’il ne faut pas construire (dire non est une capacité qu’un agent n’a pas), revue des sorties des agents avec le contexte du système complet
  • Si vous perdez la compréhension de votre propre système, vous perdez la capacité de le corriger, de l’étendre et de détecter ses dysfonctionnements

• La spec est le levier

  • Quand on orchestre 50 agents en parallèle, une pensée floue ne ralentit pas simplement la vitesse : elle est amplifiée à l’échelle de dizaines d’exécutions parallèles
  • La différence entre une sortie moyenne et une sortie remarquable dépend presque entièrement de la qualité de la spec
  • Une spec floue amplifie les erreurs dans toute la flotte ; une spec précise, avec architecture claire, frontières d’intégration, edge cases et invariants, s’amplifie en implémentations précises à l’échelle de l’ensemble
  • Le travail mécanique consistant à taper du code est en train d’être automatisé ; le travail cognitif de compréhension du système est amplifié à l’échelle d’une flotte complète de travailleurs autonomes

Le modèle de l’usine

• Il ne s’agit plus simplement d’écrire du code, mais de construire une usine qui fabrique du logiciel
• Chaîne de production en 6 étapes : Plan (rédiger une spec avec critères d’acceptation) → Spawn (créer l’équipe et attribuer les agents) → Monitor (vérifier l’avancement toutes les 5 à 10 minutes et lever les bloqueurs, sans survol constant) → Verify (lancer les tests et faire la code review ; la vérification est le goulot d’étranglement) → Integrate (fusionner les branches et résoudre les conflits) → Retro (mettre à jour AGENTS.md avec de nouveaux patterns ; apprentissage cumulatif)
• Conseils pratiques :
  • Définir une limite de WIP : ne pas lancer plus d’agents que ce que vous pouvez relire de manière utile ; 3 à 5 est le point optimal
  • Définir des critères d’arrêt : stopper et réassigner après plus de 3 blocages sur la même erreur
  • Check-ins asynchrones : vérifier l’avancement toutes les 5 à 10 minutes ; laisser les agents travailler de manière autonome
  • Un seul owner par fichier : éviter que deux agents modifient le même fichier ; les conflits tuent la vitesse

5 patterns à adopter dès aujourd’hui

1. Décomposer en sous-agents : créez des agents enfants ciblés avec un brief précis et la propriété de fichiers via l’outil Task ; aucune configuration nécessaire ; démarrage immédiat aujourd’hui
2. Parallélisme avec une équipe d’agents : activez CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 ; créez un lead + 3 coéquipiers ; coordonnez-vous avec une liste de tâches partagée
3. Isolation avec les worktrees Git : donnez à chaque agent son propre worktree ; aucun conflit de fusion ; Conductor s’en charge automatiquement
4. Garde-fous qualité pour la confiance : exigez une approbation du plan pour les changements risqués ; ajoutez des hooks qui lancent les tests à la fin des tâches ; ne faites pas confiance aux sorties des agents sans validation
5. Apprentissage cumulatif avec AGENTS.md : documentez les patterns, points d’attention et préférences de style ; chaque session lit et met à jour le fichier ; la connaissance se renforce de façon cumulative