Orca : dix agents en parallèle, un worktree chacun, et le mode yolo par défaut

Le dépôt Orca a été créé le 17 mars 2026. Le 28 août, l'API GitHub renvoie 55 724 étoiles et 3 801 forks, la dernière version publiée porte le numéro 1.4.190 et date de deux jours¹. Entre les deux, cinq mois et un rythme de publication quotidien.

Ce que le produit fait tient en une phrase de sa documentation : « Every task gets its own git worktree, its own agent terminal, and its own browser tab »². Une tâche, un worktree, un agent, un onglet. Répétez dix fois et vous avez la flotte.

Une catégorie qui ne sait pas encore comment elle s'appelle

La description du dépôt annonce un ADE, pour Agent Development Environment¹. Le README, lui, ouvre sur « The AI Orchestrator for 100x builders ». Le pied de page du site dit « The worktree IDE for AI coding agents ». La documentation, plus sobrement, parle d'« a desktop IDE for running multiple AI coding agents side by side »². Les sujets déclarés sur GitHub portent à la fois ade et agent-ide.

Quatre formulations pour un même produit, chez le même éditeur, le même jour. Le sigle ADE circule assez pour qu'on le retienne, mais il désigne pour l'instant une intuition plutôt qu'une catégorie établie : l'unité de travail devient la tentative complète, là où l'IDE tient le fichier ouvert. Un worktree, une branche, un agent, un diff à juger.

L'éditeur consacre une section entière à ce que le produit refuse d'être, et elle se lit utilement avant toute démonstration² :

• « Not a model. » Vous branchez les agents auxquels vous êtes déjà abonné.
• « Not a git replacement. » Chaque worktree est un worktree git ordinaire ; on peut y entrer en ligne de commande et travailler sans l'application.
• « Not a hosted VPS product. » L'exécution reste sur le poste par défaut, et le calcul distant passe par des machines que vous contrôlez.

Le worktree comme unité de travail

Le cœur du produit est un modèle git, pas une couche d'IA. Chaque dépôt a une référence de base, généralement origin/main. Chaque worktree a sa référence de départ, sa branche, ses fichiers sur disque et ses terminaux d'agent. Supprimer le worktree supprime le répertoire et la branche, après confirmation³.

Le cycle de vie que documente l'éditeur suit la tâche, pas le fichier : créer (nom, référence de départ, lien optionnel vers un ticket GitHub, Linear, Jira ou GitLab), travailler (terminaux, éditeur, navigateur, tous cantonnés à ce worktree), relire (diff contre la référence de départ, annotations sur les lignes, attribution des changements produits par l'IA), livrer (commit, push, ouverture de PR, attente des checks), archiver³.

Le README résume l'usage qui a fait la réputation de l'outil : « Fan one prompt across five agents, each in its own isolated git worktree — compare the results and merge the winner »¹. Le même énoncé de problème, cinq tentatives concurrentes, un arbitrage humain à l'arrivée.

Deux détails d'ingénierie méritent l'attention de ceux qui ont déjà essayé de multiplier les checkouts à la main. Un worktree neuf est une copie propre : les dépendances, caches et secrets locaux qui vivent dans des chemins ignorés par git n'y sont pas. Orca comble le trou par trois mécanismes complémentaires : des chemins partagés déclarés par dépôt, une liste worktree.sharedDirectories versionnée dans un fichier orca.yaml à la racine, et un .worktreeinclude qui copie (plutôt que lie) des fichiers comme .env dans chaque worktree³. Sur macOS, le partage passe par le clonage APFS quand c'est possible, ce qui ne facture au disque que le différentiel.

Le reste de l'application accompagne ce modèle : terminaux à rendu WebGL avec historique persistant, navigateur Chromium par worktree, un mode Design qui envoie le HTML, le CSS et une capture recadrée d'un élément d'interface directement dans le prompt de l'agent, suivi de la consommation et des plafonds de Claude et Codex, bascule de compte sans reconnexion, application mobile de supervision, exécution à distance en SSH ou sur un serveur Orca auto-hébergé¹.

Le prix affiché est zéro. Le coût ne l'est pas

L'application est publiée sous licence MIT et ne coûte rien : « Orca is free and open source under the MIT License »¹. Aucun siège, aucune marge sur les tokens. La FAQ entreprise pose le principe : « Agent traffic goes to the AI providers and CLIs your team already configures. Orca is the workspace and terminal interface around those tools, not a model provider inspecting your prompts or repository contents. »⁵ C'est une déclaration d'éditeur et elle s'instruit comme telle. Elle est cohérente avec l'architecture : Orca lance un processus dans un terminal et n'a pas de raison technique de s'insérer dans le flux.

Le coût se déplace ailleurs, et il faut le chiffrer avant de généraliser :

• Les abonnements. Cinq agents en parallèle ne sont pas gratuits parce que l'orchestrateur l'est. Et cinq sessions Claude Code sur un seul compte partagent le même plafond : la parallélisation le consomme cinq fois plus vite.
• Le disque. Dix checkouts d'un monorepo, ce sont dix arborescences. Le clonage APFS amortit sur macOS, pas ailleurs.
• La mémoire. Dix agents actifs sont dix processus, dans une application Electron qui n'est pas réputée légère.
• La machine. Déporter l'exécution en SSH ou sur un serveur auto-hébergé règle les trois points précédents et en ouvre un quatrième, celui de la facture d'infrastructure.

La page Enterprise ne publie aucune grille : elle renvoie vers un échange par courriel pour les sujets de déploiement et de sécurité⁵. Stably AI, l'éditeur, est une société de San Francisco passée par Y Combinator en promotion W22, qui publie par ailleurs une plateforme de tests end-to-end⁶. Orca ne gagne pas d'argent aujourd'hui. Une DSI qui bâtit un flux de production dessus fait bien de savoir que le modèle économique reste à écrire.

Le point qui doit remonter au RSSI

La documentation officielle l'écrit ainsi, et le passage se lit en réunion d'architecture sans paraphrase⁴ :

Orca pre-fills each supported CLI's permission-bypass flag for new launches — --dangerously-skip-permissions for Claude, --dangerously-bypass-approvals-and-sandbox for Codex, --yolo for Gemini / Cursor / Crush / Kimi / Rovo Dev / Hermes / GitHub Copilot / Command Code, plus the equivalent flag for every other agent that exposes one. The reasoning is that worktrees are disposable: an agent running in its own checkout can experiment without you re-confirming every shell command, and you can still cherry-pick or discard the diff before merging.

Le choix est assumé, documenté, et cohérent avec le produit : demander une confirmation par commande shell détruit l'intérêt d'une flotte. Le raisonnement repose sur une prémisse, « worktrees are disposable », et cette prémisse ne couvre que la moitié du risque.

Un worktree isole des fichiers versionnés. Il n'isole pas un système. L'agent tourne sous le compte de l'utilisateur, avec ses clés SSH, ses jetons cloud, son fichier ~/.aws, son accès réseau sortant, son trousseau et les autres dépôts présents sur le disque. Un script d'installation de dépendances, une commande suggérée par un README récupéré en ligne, un fichier de configuration empoisonné : la surface d'exécution n'a pas de frontière au bord du worktree. Le mode permissif n'est contenu que dans un conteneur, une micro-VM ou une machine dédiée dont la compromission est sans conséquence.

Le réglage inverse existe, et il est global. Settings → Agents → Agent Permissions bascule tous les agents non personnalisés entre Yolo et Manual ; un agent dont vous avez déjà surchargé les arguments de lancement est laissé tel quel, pour ne pas écraser une configuration explicite⁴. Trois postures se défendent, selon le contexte : mode Manual sur les postes, mode permissif accepté mais confiné à une machine distante jetable, ou permissif sur poste réservé à des dépôts sans secret ni accès de production. Ce qui ne se défend pas, c'est de déployer les valeurs par défaut sans que quiconque ait lu ce paragraphe de la documentation.

Le sujet dépasse Orca : tout agent de codage laissé sans anneau de contraintes pose la même question, et nous l'avons traitée pour elle-même dans la sécurité de l'agentic coding. Orca la rend visible en la portant dans un réglage par défaut.

Ce que ça change pour une équipe déjà sous Claude Code

Une équipe qui utilise déjà Claude Code au quotidien achète ici une multiplication, sur une capacité qu'elle possède. Et une multiplication déplace le goulot d'étranglement, elle ne le supprime pas.

Le rapport DORA 2025 avait posé le mécanisme sous le nom d'effet miroir : quand le code sort en trois heures et que la revue en prend trois jours, l'accélération de la production allonge la file d'attente devant les relecteurs. Cinq worktrees en parallèle produisent cinq diffs à juger. Si la capacité de revue de l'équipe n'a pas bougé, le débit non plus : seul le stock d'en-cours a grossi.

D'où l'ordre des questions, différent de celui de la démonstration produit. Avant de savoir si l'outil sait faire tourner dix agents, il faut savoir si l'équipe sait en juger dix sorties. C'est le passage du créateur au vérificateur que nous avons décrit dans la revue de code à l'ère de l'IA, et il se prépare avec des tests, une CI qui tranche sans arbitrage humain, et une stratégie de branches qui supporte des intégrations fréquentes. Un outil qui multiplie les branches éphémères sur une base de code sans filet automatisé amplifie un désordre existant.

Deux fonctions méritent d'être testées en premier, parce qu'elles agissent sur ce goulot. Les annotations de diff, qui renvoient les commentaires de revue directement à l'agent qui a produit le code, et le mode Design, qui remplace un aller-retour de description d'un bug d'interface par l'envoi de l'élément lui-même¹. L'une et l'autre raccourcissent la boucle de correction, pas la boucle de production.

Six mois d'existence, une dizaine de concurrents

Orca n'est pas seul, et son avance ne repose sur aucun verrou. Conductor, Superset, Herdr, Vibe Kanban, Sculptor, Crystal, cmux, Emdash : la même idée (un agent, un worktree ou un conteneur, un tableau pour suivre) a produit une dizaine d'implémentations depuis le début de l'année, dont plusieurs financées par le même accélérateur.

Le sort de Vibe Kanban donne la mesure du risque. Le 10 avril 2026, Bloop, la société éditrice, annonçait sa fermeture : « Today we're shutting down bloop, the company behind Vibe Kanban [...] the vast majority are free users and we couldn't find a business model that we could get excited about »⁷. Le projet continue en communautaire sous Apache 2.0, les services distants ont été coupés après trente jours et l'architecture est repassée entièrement locale. L'éditeur revendiquait pourtant, à raison, avoir livré le premier le support multi-agents, le commentaire de diff et la prévisualisation en direct.

C'est la position d'Orca aujourd'hui : en avance sur les fonctions, sans revenu, sur une catégorie où le coût de changement est proche de zéro. La licence MIT et le modèle bring your own subscription protègent l'utilisateur : un projet abandonné reste forkable, et les worktrees sont du git ordinaire qui survit à la disparition de l'application. La protection s'arrête à l'utilisateur, elle ne couvre pas l'éditeur. L'autre issue est que l'orchestration de worktrees parallèles devienne une fonction native des éditeurs installés, auquel cas la question ne sera plus quel produit choisir mais s'il fallait en choisir un.

Le tri, en cinq points

Ce qu'une équipe doit trancher avant d'aller plus loin, dans l'ordre :

• Le mode de permission, avant la première installation, et le lieu d'exécution qui va avec : poste, machine distante jetable, conteneur.
• La capacité de revue : combien de diffs par jour l'équipe absorbe réellement aujourd'hui, tests et CI compris.
• Le partage des plafonds : combien de sessions simultanées un abonnement soutient avant de bloquer tout le monde.
• Ce qui entre dans les worktrees : la liste .worktreeinclude copie des fichiers ignorés par git, .env en tête. Une copie de secrets par worktree se décide en connaissance de cause.
• Le plan B : ce que devient le flux de travail si le projet s'arrête. La réponse est plutôt rassurante ici, git reste git, mais elle mérite d'être écrite avant plutôt qu'après.

L'outil est gratuit, actif, et clair sur son périmètre. Il déplace la contrainte de la production vers le jugement, dans le sens de la marche de toute la software factory. Son réglage par défaut, lui, suppose une hypothèse de sécurité que la plupart des postes d'entreprise ne vérifient pas. Elle se corrige en deux clics, à condition de savoir qu'elle existe.

Questions fréquentes

Orca remplace-t-il Claude Code ou Codex ?
Non, il les fait tourner. Orca n'embarque aucun modèle et lance les agents CLI auxquels vous êtes déjà abonné, une trentaine étant préconfigurés dans le sélecteur. La règle générale est plus large : tout agent qui tourne dans un terminal tourne dans Orca.

Orca est-il vraiment gratuit ?
L'application l'est, sous licence MIT, sans siège ni marge sur les tokens. Les coûts réels sont ailleurs : les abonnements aux agents, le disque des checkouts multiples, la mémoire des agents simultanés et, si vous déportez l'exécution, la machine distante. La page Enterprise ne publie aucun tarif.

Le mode « yolo » est-il activé par défaut ?
Oui, et la documentation le dit : Orca préremplit le drapeau de contournement des permissions de chaque agent pris en charge, au motif que les worktrees sont jetables. Le réglage Settings → Agents → Agent Permissions bascule tous les agents non personnalisés en mode Manual.

Un worktree suffit-il à isoler un agent autonome ?
Non. Un worktree isole des fichiers versionnés, pas un système : l'agent conserve le compte utilisateur, les clés SSH, les jetons cloud et l'accès réseau de son opérateur. L'isolation réelle demande un conteneur, une micro-VM ou une machine dédiée.

Peut-on faire tourner plusieurs comptes Claude en même temps ?
Orca documente la bascule de compte sans reconnexion et le suivi des plafonds pour Claude et Codex. Un point reste hors de portée de l'outil : plusieurs sessions sur un même compte partagent le même plafond d'usage, que la parallélisation consomme d'autant plus vite.

Que se passe-t-il si le projet s'arrête ?
Les worktrees sont des worktrees git ordinaires et les branches sont des branches : le travail survit à l'application. La licence MIT autorise le fork. Le précédent de Vibe Kanban, fermé par son éditeur en avril 2026 puis repris en communautaire, montre que le scénario est réel dans cette catégorie.

---

Sources

1. GitHub, dépôt stablyai/orca — README (positionnement, liste des agents pris en charge, fonctions, installation, licence MIT) et métadonnées de l'API relevées le 28 août 2026 : dépôt créé le 17 mars 2026, 55 724 étoiles, 3 801 forks, version 1.4.190 publiée le 26 août 2026, sujets déclarés ade et agent-ide. Source primaire, éditeur. github.com
2. Orca Docs, « What is Orca? » — pitch officiel, unité de travail (worktree, terminal, onglet de navigateur), cas d'usage revendiqués et section « What Orca is not » (pas un modèle, pas un remplaçant de git, pas un produit VPS hébergé). Consulté le 28 août 2026. Source primaire, éditeur. onorca.dev
3. Orca Docs, « Worktrees » — modèle git (référence de base, référence de départ, branche par worktree), cycle de vie créer / travailler / relire / livrer / archiver, chemins partagés, worktree.sharedDirectories dans orca.yaml, .worktreeinclude, clonage APFS sur macOS. Consulté le 28 août 2026. Source primaire, éditeur. onorca.dev
4. Orca Docs, « Supported agents » — section « Permissions default » : préremplissage des drapeaux de contournement de permissions par agent, justification par le caractère jetable des worktrees, réglage global Settings → Agents → Agent Permissions entre Yolo et Manual, et exemption des agents dont les arguments de lancement ont été surchargés. Consulté le 28 août 2026. Source primaire, éditeur. onorca.dev
5. Orca, page Enterprise — positionnement local-first, FAQ sur le stockage du code et le trafic des agents, absence de grille tarifaire publique, contact par courriel pour les sujets de déploiement et de sécurité, mention de copyright « © 2026 Lovecast Inc. ». Consulté le 28 août 2026. Source primaire, éditeur. onorca.dev
6. Y Combinator, fiche de Stably AI — promotion Winter 2022, San Francisco, fondateurs et description de l'activité. Consulté le 28 août 2026. Source primaire, accélérateur. ycombinator.com
7. Louis Knight-Webb, « Goodbye bloop », blog Vibe Kanban, 10 avril 2026 — fermeture de Bloop, société éditrice de Vibe Kanban, absence de modèle économique malgré l'usage, poursuite du projet en open source communautaire sous Apache 2.0, coupure des services distants après trente jours et bascule vers une architecture entièrement locale. Source primaire, éditeur. vibekanban.com