Les étoiles ne mesurent rien : onze orchestrateurs d'agents, testés

Par Andriy Andrunevchyn, CTO chez Software Service & Innovation

5 août 2026. J'ai installé et utilisé moi-même les onze outils, en juillet et en août. Les nombres d'étoiles, les licences, les versions et les dates de commit proviennent de l'API GitHub, relevés le 3 août 2026. Les chiffres d'entreprise et de financement viennent de la presse. Tout le reste a été pris sur un écran en fonctionnement, et là où il s'agit d'une impression et non d'une mesure, je le dis.

Depuis que la plupart d'entre nous écrivons du logiciel, la réponse à « où travaillez-vous » était un IDE. Quel que soit le langage, une seule fenêtre contenait tout le projet.

Voici le mien, avec tout encore en place.

Les premières versions étaient des plugins. Vous gardiez votre IDE et vous y installiez l'assistant.

Puis les éditeurs eux-mêmes ont été reconstruits autour de l'assistant. Cursor est un fork de VS Code, l'éditeur sur lequel presque toute l'industrie s'était alignée, avec le modèle déplacé en son centre. Les développeurs ont changé d'outil, ce que presque rien n'avait réussi à obtenir face à VS Code, et Cursor a atteint 500 millions de dollars de revenu annuel plus vite qu'aucune entreprise de logiciel avant lui. La leçon que le marché en a tirée, c'est que le produit était l'assistant, pas l'éditeur.

JetBrains est arrivé à la même conclusion et est allé plus loin. En mars, il a sorti Air, qu'il ne qualifie même pas d'IDE. C'est un Agentic Development Environment, construit autour de l'agent plutôt qu'autour d'un éditeur de texte, avec la place pour plusieurs agents côte à côte. Il tourne sur les restes de Fleet, l'éditeur que JetBrains avait tué trois mois plus tôt après avoir décidé qu'il ne battrait pas VS Code.

Puis les CLI. Les fournisseurs de LLM publient leurs propres outils en ligne de commande, et les nouvelles fonctions y arrivent en premier. Un plugin n'expose que ce que le fournisseur lui ouvre et suit son propre calendrier de mises à jour, donc il traîne derrière. Les développeurs sont passés au terminal.

À mesure que la journée basculait dans le terminal, chacun a réorganisé sa fenêtre en conséquence. La mienne a fini en deux moitiés égales : l'éditeur d'un côté, l'agent de l'autre.

Chaque étape est allée dans le même sens : plus de temps avec le modèle, moins avec l'IDE.

Puis j'ai buté sur la limite de cette disposition. Un terminal fait tourner une conversation contre une copie de travail. Dès qu'un modèle devient assez bon pour travailler sur deux modules à la fois, la ressource rare n'est plus le modèle. C'est que je n'ai qu'un exemplaire de chaque chose. Démarrer une deuxième tâche voulait dire remiser mes modifications, cloner le dépôt une fois de plus, ou attendre la fin de la première.

Je suis donc parti chercher un outil qui parte du principe que c'est le modèle qui travaille : plusieurs agents à la fois, chacun dans son propre worktree git, et les diffs quelque part où je puisse les lire. À côté, quelque chose de léger pour ouvrir le projet. Sur tout ce qui est neuf, l'ambition va plus loin : confier une tâche à une chaîne d'agents et récupérer une fonctionnalité finie.

Le terrain, et d'où je parle

Il existe une liste maintenue par la communauté des outils qui prétendent faire cela, awesome-agent-orchestrators. Elle comptait 153 dépôts quand je l'ai cataloguée, et la forme de ces 153 mérite d'être connue avant d'accepter une recommandation de qui que ce soit, moi compris.

Soixante-treize pour cent ont été créés en 2026 et trois seulement sont antérieurs à 2025 : le dépôt médian a donc environ cinq mois. Onze pour cent sont déjà à l'abandon ou retirés : quatorze se sont tus, trois sont archivés.

J'en ai installé et utilisé onze : ceux dont je me servais déjà, plus ceux qui revenaient assez souvent pour mériter une heure. Ce n'est pas un échantillon, et mon travail est presque entièrement du brownfield. Si vous faites du greenfield, vous les classerez peut-être dans l'ordre inverse.

Une déclaration avant les conclusions. Presque toutes les comparaisons publiées sur ces outils ont été écrites par quelqu'un qui en vend un. Nimbalyst se classe quatrième, AgentsRoom ouvre sur « transparence totale : c'est nous », et la recherche la plus soignée du domaine vient du PDG d'une entreprise d'orchestration, qui le dit en tête de chaque page. Je ne vends pas d'orchestrateur, personne ici ne me finance, et je n'ai rien payé pour aucun des onze, y compris celui qui a une offre payante, que je fais tourner depuis des mois sur son plan gratuit.

Deux conceptions

Ils se présentent comme des produits différents : un IDE, un tableau kanban, une entreprise, un centre de contrôle. Faites-les tourner et les noms diffèrent plus que les produits. Ce qui les sépare, c'est la façon dont une tâche va de la phrase que vous tapez à la pull request que vous ouvrez, et il n'y a que deux réponses.

Voici les séquences telles que je les pratique, pas telles que les outils les annoncent.

Type 1. Une tâche, un worktree.

1. Créer un worktree dans l'outil.
2. Écrire la spec.
3. L'agent renvoie un plan. Le lire avant que quoi que ce soit ne s'exécute.
4. Le laisser aller jusqu'au bout, sans valider chaque modification.
5. Lire le diff.
6. Ouvrir une pull request.
7. Supprimer le worktree.

Les étapes 2 à 4 se déroulent dans le CLI de code et ressemblent exactement à ce qu'elles sont dans un terminal : plan mode, auto mode, shift+tab pour passer de l'un à l'autre. L'outil fournit les étapes 1, 5 et 7, et vous permet d'en mener plusieurs de front. C'est la disposition de la dernière capture d'écran, multipliée.

Cela convient à une tâche assez petite pour être spécifiée entièrement avant de commencer. Pour une grosse fonctionnalité, découpez-la en specs plus petites, faites tourner chacune dans son propre worktree issu d'une même branche de fonctionnalité, puis refusionnez-les vous-même. Rien de ce que j'ai vu dans ces outils ne fait cette étape à votre place.

Type 2. Configurer la chaîne, confier la tâche.

1. Configurer la séquence d'agents. Une fois, pas à chaque tâche.
2. Écrire la spec et le contexte dont la chaîne aura besoin.
3. La chaîne planifie, exécute et vérifie sans vous.
4. Build, tests et lint servent de barrières. Ils doivent passer avant que le travail n'avance.
5. Relire le brouillon. L'accepter, ou le renvoyer.
6. La boucle tourne jusqu'à ce que le résultat corresponde à la spec.
7. Ouvrir une pull request.

Vous intervenez à l'étape 2 et à l'étape 5. Le reste tourne tout seul.

Deux choses doivent être vraies avant de commencer. La spec doit être complète, parce que la chaîne ne peut pas s'arrêter pour vous poser une question. Et la fonctionnalité doit être descriptible dès le départ, sans qu'il faille d'abord aller enquêter sur des dépendances existantes ou des services externes.

Manquez l'une des deux et vous vous en apercevrez tard, parce qu'une spec incomplète n'échoue pas vite : la chaîne va jusqu'au bout et vous la facture en entier. Ivy Tendril a produit seize pull requests fusionnées pour environ 56 dollars et 600 000 tokens, sur les quatorze plans fusionnés qui portaient une donnée de coût, de 1,58 à 9,52 dollars le plan, une exécution à 10,98 dollars à elle seule. C'est l'extrémité bon marché du Type 2, et Dorothy comme Agent Teams consomment davantage.

Là où une erreur coûte cher, santé, finance ou tout ce qui a un auditeur, surveillez le volume plutôt que le taux de défauts. Les barrières contrôlent chaque changement plus sévèrement que ne le fait la relecture d'un diff de Type 1. Ce qu'elles ne peuvent pas vous dire, c'est si le travail devait exister, et l'outil de Type 2 que je place le plus haut n'arrêtait pas d'en générer davantage. Quelqu'un doit toujours être capable de dire pourquoi chaque changement est dans la base de code.

Classement par étoiles GitHub

Les onze, un par un

Type 1

Superset. Mon outil quotidien, et la raison pour laquelle la disposition de ces captures d'écran a tenu aussi longtemps. Nouvelle tâche, nouveau worktree, suppression depuis l'interface quand vous avez fini. Rien de complexe, démarrage très rapide. L'offre gratuite a tout ce dont j'ai besoin, ce qui compte parce que c'est le seul outil que j'aie trouvé à se faire encore payer : 20 dollars par mois pour des fonctions d'équipe dont je ne me sers pas. L'équipe publie des mises à jour tous les jours. L'interface mériterait encore du travail : quelques bugs, des ratés de temps en temps. Si vous n'avez besoin de rien de sophistiqué, c'est celui-là.

Sous Elastic License 2.0 depuis le 4 février 2026, date à laquelle il a quitté Apache-2.0. macOS et Linux, même si les téléchargements Linux représentent environ un pour cent de ceux de macOS.

Agent Orchestrator. Très proche de Superset, avec une interface un peu meilleure et un vrai tableau de bord de l'état des sessions. Une chose ne marche pas : vous pouvez ajouter un projet ou tout un espace de travail, mais une session ne peut être créée que sur un projet, et une fois un espace de travail ajouté vous ne pouvez plus atteindre les projets qu'il contient. Bonne idée, implémentation contre-intuitive. Apache-2.0, gratuit, les trois plateformes, toujours en pré-1.0.

Parallel Code. Assez semblable à Superset et Agent Orchestrator. Interface simple et pratique, bonne pour l'usage quotidien. Les projets à gauche, une tâche chacun, et il compte les fusions plutôt que les tokens. MIT, gratuit, macOS et Linux, maintenu par une seule personne qui fait aussi tourner Super Productivity depuis 2017.

Emdash. Un outil net et basique pour travailler avec l'IA sur de nombreux projets. Bon point de départ. Il n'invente presque aucun vocabulaire et fait tourner l'interface propre de l'agent de code au lieu de la remplacer. Apache-2.0, YC W26, et créé en août 2025, ce qui en fait un ancien dans ce domaine.

Synara. Interface parfaite, expérience désastreuse. Le plus bel outil de la sélection et l'un des plus difficiles à manœuvrer. De belles icônes porteuses d'un sens qu'elles n'établissent jamais, des indications rédigées dans des termes que le produit ne définit pas, une configuration par défaut bizarre. Il a bien des espaces de travail qui regroupent les projets, ce qui est utile, et ce qu'Agent Orchestrator promet sans savoir le livrer.

Je lui redonnerais quand même sa chance après une période d'adaptation. MIT, v0.6.5, ouvertement précoce.

Vibe Kanban. L'un des outils les plus populaires du domaine, et sa moitié cloud est désormais éteinte. Les fonctions de base sont plus ou moins les mêmes que celles de Superset ; tout le reste est désactivé. Ouvrez un projet cloud et vous obtenez un bouton d'export et un lien vers l'annonce de fermeture.

Bloop a fermé le 10 avril : « l'immense majorité sont des utilisateurs gratuits et nous n'avons pas trouvé de modèle économique qui nous enthousiasme. » Le billet disait que le projet survivrait, maintenu par la communauté. Ce n'est pas le cas. Il n'y a plus eu de commit depuis le 25 avril. Les deux derniers sont un changement de numéro de version et une bannière de fin de vie dans le README, face à 27 633 étoiles et 535 tickets ouverts. Le blog d'un concurrent explique actuellement à ses lecteurs que les pull requests de la communauté sont encore intégrées. Elles ne le sont pas.

Le logiciel tourne toujours en local. Ce n'est pas le produit qui s'est arrêté, c'est l'entreprise.

C'est pour cela que je pense à le faire revivre. Le support coûte bien moins cher ici qu'aux États-Unis, et un projet qui ne peut pas faire vivre un mainteneur américain peut faire vivre un mainteneur ukrainien. Des milliers d'utilisateurs quotidiens et 27 000 étoiles n'ont pas suffi à Bloop. Pour une seule personne en Ukraine, cela pourrait suffire. J'y ai pensé. Je ne l'ai pas fait.

Type 2

Ivy Tendril. Le plus prometteur de tous. Plus avancé que Superset, moins compliqué que Dorothy, et le flux est clair : vous créez un plan, il devient un job, le job produit un brouillon, vous vérifiez le brouillon, vous appliquez les changements qu'il propose, vous relisez une fois de plus, puis vous ouvrez une pull request. Il ne m'a presque pas fallu de temps pour comprendre comment cela devait se passer.

C'est aussi le seul outil qui filtre le travail par programme au lieu de vous demander de plisser les yeux sur un diff. Build, tests et lint doivent passer avant que quoi que ce soit n'avance, et les contrôles passent au vert juste à côté du bouton qui ouvre la pull request.

Et puis il y a Recommendations, qui propose des améliorations après chaque exécution. Cela a l'air utile, et ça l'est. C'est bien l'ennui. Acceptez-en une et elle crée un autre brouillon, une autre relecture, et d'autres recommandations. Des recommandations sur des recommandations. Deux ou trois tickets peuvent se transformer en un tas de pull requests contradictoires ; deux des miennes ont été fusionnées deux fois. À utiliser avec précaution, et vérifiez le plan avant qu'il ne s'exécute.

Sous licence FSL-1.1-ALv2, qui n'autorise pas les produits concurrents, sous un billet de lancement intitulé « Introducing Ivy Tendril: Open Source Coding Orchestration. »

Dorothy. Le plus de fonctions de toute la sélection, et il m'a assez impressionné pour que je le forke et que j'écrive son portage Linux, puisque l'amont ne fait que macOS. Puis vous découvrez le reste : treize sections de premier niveau, un Super Agent qui délègue à d'autres agents, neuf gabarits de rôles préconfigurés, cinq serveurs MCP, et un README de 34 000 octets qui documente le tout. C'est trop compliqué, et se servir d'outils pareils demande une vraie formation, ce qui peut être rédhibitoire.

Je l'ai fait tourner avec un agent sur une tâche et j'ai quand même heurté ce mur. La machinerie est à l'écran, que vous vous en serviez ou non.

Agent Teams. Interface surchargée, et vous travaillez avec une équipe plutôt qu'avec un projet, comme si vous dirigiez une agence. Le tableau de bord de l'équipe prend plus de place que la discussion de l'équipe, si bien que suivre les prompts et les résultats est plus difficile que ça ne devrait l'être. La configuration commence par la création d'une équipe de quatre agents suggérés, nommés lead, developer, reviewer, et ainsi de suite.

C'est le même cadrage anthropocentrique que Dorothy emploie pour ses gabarits de rôles et sur lequel Paperclip construit tout son produit, et je n'aime rien de tout cela. Les agents ne se comportent pas comme des personnes. Un mauvais nom crée une mauvaise attente sur ce qu'ils savent et ne savent pas faire, et cela vous vaut des résultats faux ou inattendus.

Je comprends bien pourquoi cela s'est répandu. Pour des vibe coders non techniques, une équipe de collègues nommés est bien plus facile à se représenter qu'une chaîne de prompts configurés, et c'est la métaphore dominante en ligne pour exactement cette raison. Elle n'en reste pas moins fausse. Sous licence AGPL-3.0.

Paperclip. L'outil le plus avancé de la sélection, et le plus gourmand en tokens. Il modélise une entreprise entière. Un Chief of Staff décide de quels ingénieurs vous avez besoin, les recrute, répartit le travail et rend compte à un conseil d'administration.

C'est la métaphore poussée le plus loin, et c'est là qu'elle me perd complètement. Vous ne recrutez personne. Vous décidez quel agent spécialisé prend en charge quelle étape d'un pipeline de développement, et déguiser cela en recrutement est puéril.

C'est l'outil le plus étoilé que j'aie essayé, et il y est arrivé vite : 30 000 étoiles en trois semaines pour un mainteneur pseudonyme, 75 473 aujourd'hui. Sa soumission sur Hacker News a récolté trois points et aucun commentaire.

Celui que je n'ai pas réussi à lancer

Buzz, de Block. Plein d'idées innovantes dedans. Mais l'accueil réclame une clé d'identité cryptographique, puis insiste pour que vous rejoigniez ou créiez une communauté, et en créer une ouvre un passage vers le navigateur d'où l'on ne revient jamais. J'ai renoncé après plusieurs tentatives pour raccorder la moitié web et la moitié bureau. Apache-2.0, lancé publiquement le 21 juillet, et ouvertement en préversion.

Pourquoi presque personne ne peut faire payer

J'ai vérifié les pages de tarifs des cinquante orchestrateurs de code de cette liste. Trois ont fait payer l'outil lui-même à un moment, et deux d'entre eux sont morts : 1code a été archivé en mars, l'offre payante de Vibe Kanban est partie avec Bloop en avril. Superset est le seul qui reste, et son offre gratuite suffit à un développeur seul, c'est-à-dire à qui se sert de ces outils.

La raison est structurelle. Un orchestrateur ne possède rien de coûteux. Vous apportez votre propre clé, le fournisseur du modèle vous facture directement, et l'outil est une fenêtre sur un processus que vous payez déjà. Il y a du vrai travail dans cette fenêtre (worktrees, diffs, files d'attente, état des relectures), mais rien de tout cela ne coûte au fournisseur quoi que ce soit par token, et rien de tout cela n'est assez difficile à soi seul pour porter un abonnement. Le seul outil qui se fait encore payer y arrive en vendant des fonctions d'équipe à des équipes.

Bloop a dit le reste sans détour : ils n'ont pas trouvé de modèle économique qui les enthousiasme. C'est cette formule qui porte tout le poids. Une équipe financée par du capital-risque a besoin d'un résultat à l'échelle du capital-risque, et ces mêmes milliers d'utilisateurs quotidiens qui ennuyaient un propriétaire feraient vivre quelqu'un dont la base de coûts est plus basse. Ce n'est pas l'actif qui est cassé. C'est le seuil de rentabilité qui l'était.

Ce que je vous conseille

Le Type 2 convient au greenfield. Le Type 1 convient au brownfield.

La différence tient au contexte, pas à la capacité. Sur une base de code neuve, le contexte c'est vous : la structure est ce que vous décidez. Sur un système hérité, le contexte c'est des années de dépendances et d'intégrations accumulées, qu'aucun prompt de planification ne transporte, si bien que la chaîne planifie avec assurance à partir d'un modèle faux de votre système. Un outil de Type 1 qui lit mal votre base de code gâche un prompt et vous le voyez passer. Un outil de Type 2 traîne la mauvaise lecture à travers chaque étape et vous facture chacune d'elles.

Donc : en brownfield, prenez du Type 1. J'utilise Superset tous les jours ; Parallel Code et Agent Orchestrator en sont assez proches pour que je prenne l'un ou l'autre ; Emdash est le point de départ le plus facile. En greenfield, le Type 2 devient intéressant, et Ivy Tendril est le mieux construit d'entre eux.

Jugez ces outils sur la licence et la portabilité, pas sur la bonne santé apparente de l'éditeur. Avec onze pour cent d'attrition dans un domaine qui a cinq mois, « est-ce que ça existera l'an prochain » n'a pas de réponse. « Est-ce que je pourrai continuer à m'en servir après la mort de l'entreprise » en a une aujourd'hui. Vibe Kanban est la preuve que c'est bien là la question. Et lisez la licence vous-même, parce qu'Ivy Tendril qualifie la FSL d'« open source » et que Superset a été décrit comme étant en Apache-2.0 douze semaines après avoir cessé de l'être.

L'éditeur revient

Les agents modifient le code dans des worktrees, et les diffs se relisent dans l'orchestrateur. Ce qui reste à un éditeur local, c'est l'orientation : lire l'arborescence, ouvrir quelques fichiers, consulter un README. C'est un travail de visionneuse, et un IDE complet est un moyen lourd de le faire. Vous payez l'indexation et le démarrage pour un travail qui n'a besoin ni de l'un ni de l'autre.

Les orchestrateurs partent de ce principe. Superset propose de sortir vers VS Code, Cursor, Windsurf, JetBrains ou Xcode.

J'utilise donc Zed à la place. Écrit en Rust, plus rapide que VS Code, moins de mémoire. C'est une impression d'usage, pas un benchmark.

Puis j'ai regardé ce que Zed a publié cette année. Créé en février 2021, quatre ans et demi avant presque tout ce qui existe dans ce domaine. 87 944 étoiles, plus qu'aucun orchestrateur que j'aie testé. Il a atteint la 1.0, levé 44,5 millions de dollars, publie un protocole ouvert qui fait tourner nativement les agents d'Anthropic et d'OpenAI, et fait désormais travailler des agents en parallèle sur différentes parties d'une base de code.

Et il fait payer l'IA. L'éditeur est gratuit ; l'offre payante vend des modèles hébergés. Tous les orchestrateurs que j'ai essayés transmettent votre clé directement au fournisseur et n'en retirent rien. Dans une ruée vers l'or, l'argent sûr est dans les pelles, et Zed est le seul ici à en vendre.