Trois façons d’aborder l’orchestration multi-agents
Il est sans équivoque que les agents IA ont commencé à modifier très concrètement le travail de développement. Ils accélèrent l’exploration d’une base de code, facilitent l’écriture, la relecture, les tests ou la documentation, et déplacent une partie du travail vers le pilotage et l’arbitrage.
La nouvelle tendance, l’orchestration multi-agents, se résume ainsi : au lieu de tout faire porter à un seul ou quelques agents pilotés manuellement, on répartit le travail entre plusieurs agents spécialisés, coordonnés entre eux. Très vite, l’idée n’est plus d’avoir “un meilleur copilote”, mais plutôt une équipe coordonnée : un agent sécurité, un agent architecture, un agent tests, un agent documentation, chacun mobilisé au bon moment.
L’objectif n’est plus simplement d’utiliser Claude Code comme un assistant conversationnel, mais de construire un petit système de travail où plusieurs agents coopèrent, se répartissent les tâches, se relaient, et parfois avancent en parallèle.
Pour comprendre à quoi cela ressemble concrètement, regardons trois projets qui incarnent trois visions assez différentes de cette orchestration : wshobson/agents, Oh My Claude Code (OMC) et Gas Town.
Pourquoi l’orchestration multi-agents devient un vrai sujet
Claude Code permet déjà de faire collaborer plusieurs sessions autour de listes de tâches, de branches Git et de fichiers partagés. Tant que vous pilotez quelques agents à la main, cela reste gérable.
Mais dès que les besoins se diversifient — code, sécurité, infra, data, documentation, produit — les vraies questions commencent :
- Quel agent fait quoi ?
- Comment éviter les collisions dans la base de code ?
- Où conserver l’état, les décisions et les consignes sans recharger tout le contexte à chaque interaction ?
- Comment paralléliser sans perdre en cohérence ?
- Comment garder une traçabilité de ce qui a été fait ?
C’est là qu’interviennent les architectures d’orchestration multi-agents. Elles ajoutent au-dessus de Claude Code une couche d’organisation : des rôles, des workflows, des conventions de communication, et parfois des artefacts externes — Git, fichiers de config, issues, bases de données — pour structurer la collaboration.
Autrement dit : on passe d’un assistant intelligent à un système coordonné de travail.
wshobson/agents : une boîte à outils d’agents spécialisés
La première approche ressemble à un atelier bien équipé.
Avec wshobson/agents, l’idée n’est pas d’imposer une orchestration unique, mais de proposer un écosystème de plugins, de skills et d’agents spécialisés que l’on peut brancher sur Claude Code selon ses besoins.
On y trouve des agents orientés sécurité, SQL, tests, performance, documentation, full-stack, infra, ML ou encore business. Plutôt qu’un gros framework monolithique, le projet mise sur une logique de composabilité : vous piochez les briques qui vous intéressent et vous assemblez votre propre environnement.
C’est ce point qui fait sa force.
Vous n’installez pas “le multi-agents” comme un bloc opaque. Vous composez progressivement une chaîne de travail adaptée à votre stack. Par exemple, un orchestrateur peut lancer une revue de code en faisant intervenir :
- un agent sécurité,
- un agent performance,
- un agent architecture,
- puis un agent documentation.
Chaque agent intervient sur une facette bien définie du problème, sans que tout repose sur une seule session généraliste.
Cette approche parlera immédiatement aux équipes qui aiment construire leur environnement de développement à la carte, comme elles le feraient avec leurs dotfiles, leurs scripts internes ou leurs pipelines maison. wshobson/agents, c’est avant tout une logique de modularité et de contrôle.
Oh My Claude Code : l’orchestration pensée pour la DX
Oh My Claude Code (OMC) part d’un constat différent : l’orchestration multi-agents est puissante, mais elle peut vite devenir pénible à configurer et à opérer au quotidien.
Là où wshobson/agents ressemble à une caisse à outils, OMC se positionne davantage comme une couche d’automatisation orientée expérience développeur. L’ambition n’est pas seulement d’ajouter des agents, mais de rendre leur usage simple, rapide et agréable.
Concrètement, OMC met l’accent sur :
- une configuration guidée,
- des profils de projet,
- plusieurs modes d’exécution,
- le suivi en temps réel,
- et des intégrations avec les outils de communication d’équipe.
L’idée clé est de réduire le coût cognitif de l’orchestration.
Vous exprimez un objectif, vous lancez un run, et OMC s’occupe d’une partie de la mécanique : quels agents appeler, comment découper le travail, ce qui peut être parallélisé, et comment remonter l’avancement vers les canaux que l’équipe utilise déjà — par exemple Discord ou Telegram.
Un autre point intéressant est le soin apporté à l’onboarding. OMC ne se contente pas d’exécuter des agents : il aide à générer ou mettre à jour les fichiers de configuration du projet, à définir les modes d’exécution (séquentiel, parallèle, swarm), et à installer une forme de HUD ou de suivi de statut.
Le résultat, c’est qu’on peut passer assez vite de “j’utilise Claude Code seul” à “je pilote une petite équipe d’agents” sans avoir à comprendre immédiatement toute la plomberie interne.
Pour les équipes qui veulent profiter du multi-agents sans transformer leur environnement de dev en chantier d’architecture, OMC représente une approche particulièrement pragmatique.
Gas Town : une vision industrielle de l’orchestration
Avec Gas Town, on change encore de registre.
Ici, l’objectif n’est plus seulement de mieux répartir quelques tâches entre agents spécialisés, mais de concevoir un véritable environnement de production multi-agents autour de Claude Code.
Le projet introduit une structure plus ambitieuse, avec des concepts comme :
- la Town, qui centralise la configuration globale ;
- les rigs, qui correspondent aux dépôts ou projets ;
- des flottes d’agents capables de travailler en parallèle sur des branches, des tâches ou des patrouilles de code.
Cette fois, les agents ne sont pas seulement définis comme des personas ou des assistants spécialisés, mais comme de vrais rôles opérationnels dans une organisation :
- un Mayor pour coordonner, découper et superviser ;
- des Polecats pour exécuter rapidement des tâches bien bornées ;
- d’autres rôles pour l’audit, la surveillance ou la maintenance du système.
La différence majeure, c’est que l’état du système n’est pas porté uniquement par le contexte conversationnel. Il vit aussi dans des artefacts externes : Git, issues, beads, éléments de suivi. Cette persistance permet à la fois la parallélisation, la supervision humaine et la traçabilité.
Gas Town pousse donc l’idée plus loin : les agents ne viennent pas simplement assister un développeur ; ils s’inscrivent dans une chaîne de production organisée, avec ses conventions, ses responsabilités, ses contrôles et ses preuves de travail.
C’est une approche très “infra”, presque “ops”, du multi-agents. On n’ajoute plus quelques assistants à un flux existant : on construit une usine d’agents.
Trois visions complémentaires de l’orchestration
Si l’on met de côté les détails d’implémentation, ces trois projets dessinent en réalité trois façons de penser l’orchestration autour de Claude Code.
- La logique modulaire : avec wshobson/agents, vous assemblez vous-même votre écosystème d’agents et d’orchestrateurs. C’est la voie du contrôle, de la personnalisation et de la composabilité.
- La logique orientée expérience : avec OMC, l’orchestration devient un service qui absorbe une partie de la complexité technique. C’est la voie de la simplicité d’usage, de l’adoption rapide et du confort opérationnel.
- La logique infrastructurelle : avec Gas Town, les agents deviennent une couche structurante du processus de développement lui-même. C’est la voie de la persistance, de la traçabilité, du parallélisme massif et de l’industrialisation.
Ces approches ne s’excluent pas. Au contraire, elles peuvent très bien se compléter.
On peut, par exemple, reprendre :
- la composabilité de wshobson/agents,
- les choix DX d’OMC,
- et les concepts de persistance et de rôles de Gas Town,
pour concevoir une orchestration adaptée à sa propre stack, à son monorepo ou à ses contraintes d’équipe.
Comment transposer ces idées dans votre stack
La vraie question n’est pas seulement “quel outil choisir ?”, mais par où commencer.
Une trajectoire réaliste pourrait ressembler à ceci :
Commencer simple. Montez une première boîte à outils d’agents spécialisés dans Claude Code pour couvrir les besoins qui reviennent le plus souvent : revue de code, sécurité, tests, documentation.
Ajouter une couche d’orchestration légère. Introduisez ensuite une logique à la OMC pour paralléliser certaines tâches, standardiser quelques modes d’exécution et mieux partager l’avancement avec l’équipe.
Tester un modèle plus structuré. Enfin, sur un projet pilote, expérimentez une approche plus proche de Gas Town : agents par rôle, branches dédiées, artefacts de suivi, supervision humaine et workflow plus industrialisé.
Le bon niveau d’orchestration dépendra toujours de votre contexte : taille de l’équipe, criticité du code, fréquence des refontes, besoin de traçabilité, maturité infra.
Mais une chose devient claire : à mesure que ces pratiques se stabilisent, l’orchestration multi-agents cesse d’être un gadget impressionnant pour devenir une nouvelle manière d’organiser le travail de développement autour de Claude Code.
Ce qu’il faut retenir
L’intérêt du multi-agents n’est pas d’ajouter “plus d’IA” pour le principe. Il est de mieux répartir le travail, de préserver le contexte, de paralléliser ce qui peut l’être, et de rendre les contributions plus lisibles, plus spécialisées et plus traçables.
- wshobson/agents montre ce que peut apporter une approche modulaire.
- OMC montre comment rendre l’orchestration accessible et confortable.
- Gas Town montre jusqu’où on peut pousser la logique d’industrialisation.
Entre ces trois visions, il y a déjà de quoi réfléchir sérieusement à la manière dont vous voulez faire évoluer votre propre environnement avec Claude Code.