Gérer plusieurs agents à la fois : Conductor, Orca, Zed, herdr

Ça a commencé sur un channel Discord qui parlait d’autre chose.

Rémi a posté un screenshot d’Orca. Trois worktrees en parallèle, un aperçu du navigateur sur la droite, les diffs annotés. Florian a répondu dans la minute, Theo juste après. Trois messages plus tard, on avait deux camps et une guerre civile.

D’un côté Theo, Florian et Rémi. Leur argument tient en une phrase : une interface graphique, c’est mieux à l’usage. On voit d’un coup d’œil ce que font les agents, sans apprendre un seul raccourci.

De l’autre Gauthier et moi, plus puristes du terminal. Parce que le terminal est déjà là, parce qu’il survit à une connexion SSH, et parce qu’on n’a pas très envie d’une application de plus qui tourne en fond.

En soi, personne n’a tort. C’est ce qui rend le sujet intéressant.

Derrière la simple question « quel outil », il y en a une importante : qu’est-ce qu’on fait quand cinq agents tournent sur trois projets différents et qu’on ne sait plus lequel attend une réponse ?

J’ai passé ces derniers mois à tester quatre réponses, et elles n’ont pas la même philosophie. Conductor et Orca sont des ADE, pensés pour ça dès le départ. Zed est un éditeur qui s’est mis à orchestrer des agents. herdr est un multiplexeur de terminal créé pour l’agentic. Trois points de départ, un même problème.

En bref

• Conductor, ADE : application Mac propriétaire, quatre agents, trois panneaux. Le plus simple à mettre en route.
• Orca, ADE : MIT, macOS, Windows et Linux, 25+ agents, Chromium embarqué et application mobile. Le plus complet.
• Zed, éditeur : GPL-3.0, macOS, Linux et Windows, debugger et git intégrés, vim-friendly. Le juste milieu.
• herdr, multiplexeur : Apache 2.0, un binaire dans le terminal que vous avez déjà, 20 agents détectés sans configuration. Le plus discret.

Pourquoi le problème n’existait pas il y a un an

Un agent, un terminal. C’était le modèle par défaut, et ça fonctionnait tant que l’agent rendait la main toutes les trente secondes.

Ce n’est plus le cas. Un agent qui part sur une tâche un peu large travaille plusieurs minutes sans rien demander. Alors forcément, vous ouvrez un deuxième onglet et vous lancez autre chose. Puis un troisième.

Et là le goulot d’étranglement se déplace. Ce n’est plus la vitesse à laquelle le code s’écrit, c’est votre attention. Vous passez votre temps à faire la tournée des onglets pour vérifier lequel est bloqué sur une question, lequel a fini, lequel tourne encore dans le vide.

Ajoutez le multi-projet et ça devient franchement galère. Perso, je travaille rarement sur un seul repo dans la journée.

C’est exactement le souci que ces quatre outils sont venus régler.

C’est quoi un ADE ?

Agentic Development Environment. Le terme s’est stabilisé courant 2026, quand il est devenu clair que les IDE et les CLI existants n’étaient pas taillés pour piloter plusieurs agents sur de vrais repos.

La définition qui me parle le plus vient d’Augment Code : là où un IDE est construit autour d’une personne qui édite un fichier, un ADE est construit autour de la livraison d’unités de travail prêtes à être relues, souvent produites par plusieurs agents en même temps.

Le twist est là. L’IDE suppose que vous tapez. L’ADE suppose que vous dirigez.

Conductor et Orca sont nés dans cette catégorie. Zed y arrive par l’autre bout, en partant d’un éditeur qui existait déjà. herdr, lui, est né pour les agents mais a pris la forme d’un multiplexeur. Peu importe : c’est le même problème qu’ils résolvent, et on peut les comparer.

En pratique, quel que soit l’outil, on retrouve à peu près les mêmes cinq briques.

Un worktree git isolé par tâche. Chaque agent travaille dans son propre répertoire, sur sa propre branche, avec l’historique git partagé. Plus de stash, plus de jonglage de branches, et surtout plus de deux agents qui écrivent dans le même fichier au même moment.

La détection d’état. L’outil regarde ce que fait le processus et vous dit s’il travaille, s’il est bloqué sur une question, ou s’il ne fait plus rien. C’est la brique la plus sous-estimée, et c’est celle qui change le plus votre journée.

La revue de diff intégrée. Le travail d’un agent se juge sur son diff, pas sur son log. Les bons outils vous mettent le diff à côté de la conversation, et certains vous laissent annoter directement dedans.

La persistance de session. Vous fermez le capot, les agents continuent. Vous rouvrez, tout est là. Sans ça, le multi-agent ne tient pas une journée de travail normale.

Le pilotage à distance. SSH, application mobile, API. Parce qu’un agent qui tourne dix minutes, vous n’avez pas envie de rester devant.

Pourquoi ça vaut le coup de s’en servir ?

Le gain n’est pas la vitesse. Je le dis parce que c’est l’argument qu’on entend partout, et je le trouve faux. Theo en tirait la même conclusion après la Cité de l’IA : le vrai retour se joue sur la charge mentale et l’organisation, pas sur les minutes gagnées.

Le vrai gain, c’est de savoir lequel de vos six agents vous attend. Sans outil, la réponse coûte une tournée d’onglets toutes les deux minutes, et cette tournée casse votre concentration bien plus sûrement que l’attente elle-même.

Le second gain est plus technique : l’isolation par worktree supprime une classe entière de bugs. Deux agents qui touchent le même fichier en parallèle, ça produit des conflits que vous ne voyez qu’au moment du commit, et qui vous coûtent plus cher que ce que la parallélisation vous a fait gagner.

Le troisième, c’est la relecture. Un agent produit du code plus vite que vous ne le relisez. Un outil qui vous pose le diff sous le nez au bon moment déplace le goulot au bon endroit.

Quand ça ne marche pas

Il y a une contrepartie, et elle ne se voit pas directement.

Le plafond n’est pas technique, il est cognitif. Relire toute la journée du code que vous n’avez pas écrit fatigue plus que d’en écrire. L’ancienne façon de travailler ménageait des temps morts : pendant qu’on écrivait, on avançait sans avoir à juger. Ce répit a disparu. Ce qui reste, c’est de la décision en continu, et je sature bien avant la machine.

L’autre limite, c’est que « working » ressemble beaucoup à « ça avance ».

J’ai laissé tourner un agent qui code et un agent qui relit, en arrière-plan. Ils se sont renvoyé la balle pendant des heures sans que je m’en aperçoive. L’outil affichait working des deux côtés, ce qui était exact et parfaitement inutile : la détection d’état vous dit qu’un processus travaille, pas qu’il progresse. C’est la limite de la brique que je présentais plus haut comme la plus sous-estimée. Une boucle ne se voit qu’à la lecture du diff.

Et la consommation suit le nombre d’onglets. La configuration et les pratiques changent beaucoup les choses, mais le réflexe d’en ouvrir un de plus se paie.

Conductor, Orca, Zed, herdr : lequel choisir ?

Quatre outils, trois familles. Voilà comment ils se positionnent.

Outil	Licence	Compte requis	Plateformes	Forme	Agents
Conductor	propriétaire	oui	macOS	app native	Claude Code, Codex, Cursor, OpenCode
Orca	MIT	non	macOS, Windows, Linux, mobile	app desktop	25+ CLI
Zed	GPL-3.0	non	macOS, Linux, Windows	éditeur	agents ACP (Claude Agent, Codex…)
herdr	Apache 2.0	non	macOS, Linux, Windows (bêta)	binaire dans le terminal	20 détectés sans config

Conductor

Le plus simple des quatre, et c’est assumé. Conductor est une application Mac qui fait tourner Claude Code, Codex, Cursor et OpenCode en parallèle, chaque tâche recevant « son propre espace de travail, sa branche, ses fichiers, son terminal, son diff et son parcours de relecture ».

Trois panneaux : la liste des espaces de travail à gauche, la conversation au milieu, le diff et le terminal à droite. Vous ouvrez, vous comprenez.

En contrepartie c’est macOS uniquement, c’est propriétaire, et la liste d’agents est courte. L’usage local reste gratuit et vous apportez votre propre abonnement Claude ou Codex. Au-delà, la grille tarifaire démarre à 50 $ par mois pour le cloud et le multijoueur, puis 60 $ par utilisateur pour les équipes de plus de cinq.

Le compte Conductor, lui, est obligatoire. L’application réutilise ensuite la session Claude Code ou Codex déjà présente sur la machine, mais vous passez d’abord par l’inscription. C’est le seul des quatre à l’exiger.

À prendre si vous êtes sur Mac, sur Claude Code, et que vous voulez que ça marche cet après-midi.

Orca

Le plus complet, et le camp d’en face chez nous. Orca est sous licence MIT, tourne sur macOS, Windows et Linux, embarque plus de vingt-cinq CLI d’agents en natif et accepte n’importe quel autre, et pose chaque tâche dans « son propre worktree git isolé ».

Ce qui fait la différence, ce sont les fonctionnalités que les autres n’ont pas. Une vraie fenêtre Chromium par worktree, dans laquelle vous cliquez sur un élément d’interface pour envoyer son HTML, son CSS et une capture recadrée directement à l’agent. L’éditeur de VS Code embarqué. L’annotation de diff en markdown. Les intégrations GitHub et Linear. Et une application compagnon iOS et Android pour surveiller l’état des agents depuis le canapé.

C’est l’outil qui va le plus loin dans l’idée de remplacer l’IDE plutôt que de se poser à côté. Si vous faites du front, le Design Mode vaut à elle seule le détour, et c’est précisément l’argument que Theo me sort à chaque fois.

Un paramètre à garder en tête quand même. Orca est développé par Stably AI, société passée par Y Combinator, et Conductor vient de Melty Labs, YC aussi. Les deux ADE de ce comparatif sortent donc du même incubateur. Le code d’Orca est sous MIT et le restera, mais je fais le pari qu’un modèle payant finira par apparaître au-dessus, sur le cloud, le remote managé ou les fonctionnalités d’équipe.

Si c’est ce point qui vous gêne, il existe une alternative moins connue : paseo, sous AGPL-3.0, repose sur un démon local et des clients desktop, mobile, web et CLI. Zéro télémétrie, aucune connexion obligatoire, et un déploiement Docker pour le poser sur votre propre serveur. C’est l’option auto-hébergée du lot.

Zed

Le juste milieu. Zed est un éditeur sous GPL-3.0 qui tourne sur macOS, Linux et Windows, écrit « de zéro en Rust pour exploiter vos cœurs CPU et votre GPU ». Ça se sent tout de suite : on sent que ça pousse, l’outil est un plaisir à utiliser.

Ce n’est pas un IDE, et c’est justement l’intérêt. Il a quand même un debugger, ce qui est rare à ce niveau de légèreté. DAP sous le capot, adaptateurs intégrés pour C, C++, Go, JavaScript, PHP, Python, Rust et TypeScript, extensions pour Java, Ruby et Swift. Il lit même les .vscode/launch.json déjà présents.

Le support git est vraiment bon, et c’est ce qui compte quand quatre agents poussent du code en parallèle. Panneau git, staging au hunk, diff en side-by-side ou inline, blame en ligne, résolution de conflits en un clic, gestion des worktrees. Vous relisez sans sortir de l’éditeur.

Côté agents, Parallel Agents est arrivé en avril 2026. Chaque tâche est un thread dans la fenêtre, avec son contexte et son historique, et la barre latérale affiche leur titre, leur état et quel agent les fait tourner. Les agents externes se branchent par le protocole ACP. Une différence à noter avec Conductor et Orca : chez eux une tâche égale un worktree, point. Chez Zed l’isolation est optionnelle et se décide thread par thread.

Et il est ✨ vim-friendly ✨ les motions, les text objects, les commandes ex et le visual block sont là, et ça suffit largement pour ne pas perdre ses réflexes.

À prendre si vous voulez piloter vos agents sans sortir le gros IDE, tout en gardant un debugger et un vrai git sous la main.

herdr

Le plus discret. herdr est un binaire ✨ Rust ✨ sous Apache 2.0 qui tourne dans le terminal que vous avez déjà. Pas d’Electron, pas de compte, pas de fenêtre supplémentaire.

Il reprend le modèle de tmux (onglets, panes, sessions persistantes) et lui ajoute la seule chose qui manquait : il reconnaît les agents qui tournent dans ses panes et affiche leur état, working, idle ou blocked. Une vingtaine d’agents sont détectés sans configuration.

Deux détails qui comptent. Le serveur tourne en arrière-plan et restaure les layouts après un redémarrage machine, avec detach, replay de l’historique de pane et reprise native de session. Et l’API CLI et socket est pensée pour que les agents s’en servent eux-mêmes : un agent peut ouvrir un pane, coordonner une tâche, attendre un vrai blocage plutôt que d’envoyer des touches à l’aveugle.

Il est aussi mouse-first, ce qui est inhabituel pour un multiplexeur : on clique sur les panes, on tire les bordures, on découpe au clic droit. (Je trouve ça aberrant, mais en fait c’est très pratique pour les non-habitués au terminal.)

Au 14 août 2026, le site annonce 28 687 étoiles GitHub, 427 203 installations et 614 plugins communautaires.

Et quand on change de client toutes les six semaines ?

En régie, le contexte change plus souvent qu’ailleurs. Machine du client, VPN, politique d’installation, plusieurs repos qui n’ont ni les mêmes conventions ni la même stack.

Ça pousse mécaniquement vers les outils qui demandent le moins de droits et le moins de configuration. Un binaire qui s’installe dans votre $HOME et qui fonctionne à travers SSH passe partout. Une application desktop signée, avec sa fenêtre Chromium embarquée, passe beaucoup moins bien sur un poste géré par une DSI.

C’est peut-être un détail pour vous, mais pour nous ça veut dire beaucoup dans le choix d’un outil.

Au final

Perso, j’utilise herdr, et de façon assez simple : cinq à six workspaces ouverts en local, un par projet, et plusieurs worktrees dans chacun. Dans chaque workspace, le même découpage en onglets. Un onglet Agents où tournent les sessions Claude Code, un onglet Server avec l’application qui tourne, un onglet Editor avec nvim prêt à dégainer. Et le même setup sur un VPS distant pour certains projets.

Le travail se découpe toujours de la même façon. Une passe de spécification d’abord, seul avec un agent, jusqu’à ce que le besoin soit clair. Ensuite je découpe en tâches parallélisables, en général une par fonctionnalité, parfois plusieurs à l’intérieur d’une même fonctionnalité quand elle s’y prête. Chaque tâche part dans son worktree avec son agent, et un dernier agent passe derrière en relecture.

C’est là que l’onglet Agents se remplit : plusieurs panes côte à côte, une par worktree du projet, toutes sur le même repo. Le multi-projet vient en plus, pas à la place.

Ce qui m’a convaincu, c’est qu’il a remplacé Zellij sans que j’aie à réapprendre quoi que ce soit. Même modèle mental, mêmes gestes, avec la couche multi-agent en plus. Je n’ai pas changé d’outil, j’ai changé de version de mon outil.

Maintenant, honnêteté oblige : Orca et Zed sont deux super outils. Zed est mon éditeur GUI par défaut, et j’ai pris beaucoup de plaisir à tester Orca, que je trouve vraiment complet.

Mais je me trouve toujours plus efficace quand je reste dans mon terminal.

Donc si je devais orienter quelqu’un, voici ce que je conseille selon votre profil :

• Pour la team terminal first : herdr toujours par défaut + Zed si vous voulez un debugger et un vrai git sans sortir le gros IDE.
• Pour ceux qui veulent un outil all-in-one : Orca, il a tout ce qu’il vous faut et plus encore. Dur pour moi de recommander Conductor qui me semble moins bon en tout points.

Perso, j’utilise Zed de plus en plus souvent à la place de ma suite JetBrains, avec herdr ouvert en permanence en dessous.

La guerre civile n’est pas tranchée chez nous, et je ne crois pas qu’elle le sera. Ce qui a changé, c’est que plus personne ne fait la tournée des onglets.

Sources

• What Is an Agentic Development Environment?, Augment Code
• Conductor Docs, Melty Labs
• Conductor Pricing, Melty Labs, consulté le 15 août 2026
• Orca, Stably AI, licence MIT
• Stably AI (Orca), annuaire Y Combinator
• Zed et zed-industries/zed, licence GPL-3.0-or-later
• Introducing Parallel Agents in Zed, blog Zed, avril 2026
• Parallel Agents, Debugger, Git et Vim Mode, documentation Zed
• getpaseo/paseo, licence AGPL-3.0
• herdr.dev et la documentation herdr, licence Apache 2.0