🐋 Orca : un worktree par ticket, et vos agents autour

📚 Introduction

Depuis que je délègue une partie du code à des agents, le goulot d’étranglement s’est déplacé vers la gestion de l’état local. Un agent corrige un bug sur une branche, pendant ce temps j’ai une review à faire sur une autre, et un deuxième agent attend son tour parce que le dépôt n’a qu’un seul checkout. Résultat : des git stash en cascade, des terminaux qu’on ne sait plus rattacher à quelle tâche, et un onglet Linear ouvert à côté pour se souvenir de ce qu’on était censé faire.

Orca prend ce problème par le bon bout. L’idée tient en une phrase : chaque tâche vit dans son propre git worktree, avec ses agents, ses terminaux, son diff et son ticket attaché. Le reste de l’application est construit autour de cette unité.

Je l’utilise surtout avec Claude Code, dans la continuité de Laravel Boost. Voici une visite guidée, captures à l’appui, puis la façon dont Orca s’articule avec le harness engineering que je décrivais dans l’article précédent.

🐋 Qu’est-ce qu’Orca ?

Orca est une application desktop open source, sous licence MIT, développée par Stably AI. Elle se présente comme un « agent development environment » : un endroit unique pour lancer des agents de code CLI côte à côte, avec des terminaux, un éditeur, un diff, un navigateur et une CLI. Elle tourne sur macOS, Windows et Linux, et une app compagnon existe pour iOS et Android.

Orca n’embarque aucun modèle. Il orchestre les agents que vous avez déjà : Claude Code, Codex, Cursor CLI, Gemini, Copilot, OpenCode et Pi sont préconfigurés, et n’importe quel agent qui tourne dans un terminal fonctionne. On garde ses propres abonnements.

L’interface principale, capture officielle du README Orca.

La capture résume bien le produit :

• À gauche, la barre latérale : Tasks (les tickets), Automations, Orca Mobile, Search, puis la liste des workspaces. Chaque carte affiche le dépôt, la branche, les agents actifs, leur dernier message et l’état de la PR liée.
• Au centre, le workspace improve-readme avec deux agents ouverts dans le même worktree : Claude Code à gauche, Codex à droite, et un terminal en dessous qui installe les dépendances.
• À droite, l’explorateur de fichiers du worktree.
• En bas, la barre d’état avec la consommation Claude et Codex (fenêtre de 5 heures et hebdomadaire).
• En incrustation, l’app mobile, qui liste les machines appairées et les sessions à reprendre.

🔍 Pourquoi les worktrees changent tout ?

Parce qu’un worktree donne à chaque tâche son propre dossier sur disque, sur sa propre branche, tout en partageant le même .git. Deux agents lancés sur deux tâches distinctes peuvent modifier le même fichier en même temps sans conflit local.

La commande existe dans git depuis longtemps :

git worktree add ../mon-projet-fix-login -b fix/login origin/main
cd ../mon-projet-fix-login
# … travailler, commiter, pousser
git worktree remove ../mon-projet-fix-login

Rien de neuf, donc. Mais à la main c’est pénible : nommer le dossier, choisir la base, réinstaller les dépendances, se rappeler quel dossier sert à quoi, nettoyer derrière.

Orca automatise toute cette plomberie. La boîte de dialogue « Create Worktree » demande un nom de tâche, une ref de départ (origin/main par défaut, mais aussi une branche locale, un SHA ou une branche distante) et, éventuellement, un lien vers un ticket. Le git fetch et le git worktree add tournent en arrière-plan pendant qu’une ligne de progression s’affiche dans la barre latérale, et on choisit l’agent qui s’ouvre dans le premier onglet. À la suppression, le dossier et la branche partent ensemble. Si une branche locale contient des commits non fusionnés, Orca la garde et le signale.

Le point qui m’a convaincu, ce sont les dépendances. Recréer un node_modules ou un vendor par worktree, c’est vite plusieurs minutes et plusieurs gigas. Orca propose de lier ces dossiers ignorés par git via un orca.yaml à la racine du dépôt :

# orca.yaml
worktree:
  sharedDirectories:
    - node_modules
    - .cache

Ces dossiers sont symlinkés dans chaque nouveau worktree. Pour les fichiers qu’on veut au contraire copier (un .env typiquement), il existe un fichier .worktreeinclude qui liste des chemins littéraux.

🤖 Plusieurs agents par worktree, et un œil sur chacun

Le premier agent n’est pas seul. Dans Orca, une session correspond à un agent CLI dans un terminal, et un worktree peut en accueillir autant qu’on veut, en onglets ou en splits : Claude Code qui implémente, Codex qui écrit les tests à côté, un shell pour lancer le serveur. Tout ce petit monde partage la même branche. C’est à vous de répartir le travail pour qu’ils ne réécrivent pas le même fichier au même moment.

Avec dix sessions ouvertes, la question devient : qui attend quoi ? La barre latérale répond directement. Chaque workspace liste ses agents avec leur état et un aperçu de leur dernier message.

Deux agents dans le même workspace, chacun avec son état. Capture officielle.

Un fil « Agents » regroupe aussi les événements de tous les worktrees : agent qui a fini son tour, agent bloqué sur une question, worktree créé. Les agents en cours restent épinglés en haut, et un clic ramène sur le bon worktree et le bon panneau. Les notifications système continuent de signaler la fin d’un agent.

Pour ne pas saturer la machine, on peut mettre un worktree en veille depuis la barre latérale ; Orca garde les sessions de quoi les relancer. Une option expérimentale (désactivée par défaut) va plus loin et suspend automatiquement les terminaux d’agents inactifs depuis 30 minutes, puis les reprend à la réouverture du worktree.

🎫 Du ticket à la branche sans changer de fenêtre

C’est la partie qui simplifie le plus mon quotidien. Orca branche trois sources de tâches dans une même liste : GitHub (issues, PR et GitHub Projects), Linear et Jira, Cloud comme Server/Data Center.

Un tableau GitHub Projects ouvert dans Orca. Capture officielle.

Le flux est toujours le même. Je pars d’un ticket, je clique pour créer un worktree, et le composer se pré-remplit avec le nom de la tâche et le lien vers l’issue. Pour Linear, Orca reprend même le nom de branche suggéré par Linear plutôt qu’un slug du titre, ce qui garde la convention de l’équipe intacte. Le ticket reste affiché sur la carte du worktree : trois jours plus tard, je sais encore pourquoi cette branche existe.

Quelques détails qui comptent :

• Côté Jira, la recherche accepte du texte libre ou du JQL, et on peut changer le statut d’un ticket via ses transitions.
• Côté Linear, on édite statut, assignee, priorité et labels depuis Orca. Le passage automatique en « In Progress » à la création du worktree existe, mais il est opt-in par équipe.
• Quand on lance un agent depuis une issue Linear, les images de la description et des commentaires sont injectées dans le prompt. Pratique pour un bug UI avec capture d’écran.
• Les tableaux GitHub Projects s’affichent en kanban, et déplacer une carte met à jour le champ statut du projet.

🧰 Relire ce que l’agent a produit

Faire écrire du code à un agent est facile, le relire proprement beaucoup moins. Orca embarque un visualiseur de diff où l’on commente n’importe quelle ligne (touche c ou le + dans la gouttière), en Markdown.

Le diff « All Changes » d’un worktree, prêt à être annoté. Capture officielle.

Les commentaires s’accumulent, puis un bouton « Send to agent » les envoie tous d’un coup sous forme d’un seul prompt ancré sur les lignes. On choisit quel agent du worktree reçoit les notes, ou on en démarre un nouveau. L’agent fait une passe de correction au lieu de réagir commentaire par commentaire, et les commentaires restent épinglés pour vérifier le résultat.

Ensuite, tout se passe dans l’outil : commit, push, ouverture de la PR. Si GitHub Actions échoue, une pastille rouge apparaît sur le worktree avec les logs du job en ligne, et l’action « Fix broken checks » transmet les checks en échec à un agent.

Il y a aussi un mode plus ambitieux, documenté dans la recette « parallel agents » : créer trois worktrees depuis la même base, donner le même prompt à Claude Code, Codex et Cursor CLI, comparer les trois diffs, garder le meilleur et supprimer les autres. Je ne le fais pas sur chaque ticket, ça coûte du quota. Sur un bug coriace, en revanche, voir où les agents divergent indique très vite où se trouve la vraie difficulté.

🛠️ Le reste de la boîte à outils

Orca ne se limite pas aux worktrees :

• Terminaux rendus en WebGL, splits illimités, scrollback restauré au redémarrage.
• Navigateur Chromium par worktree, avec un Design Mode : on clique sur un élément de la page et son HTML, son CSS et une capture recadrée partent dans le prompt de l’agent.
• Worktrees distants via SSH, pour faire tourner les agents sur une machine plus musclée, avec reconnexion automatique et redirection de ports.
• Suivi de l’usage Claude et Codex, avec les resets de rate limit et un changement de compte Codex sans se reconnecter.
• Automations : des prompts planifiés (hourly, daily, une expression cron…) confiés à claude ou codex sur un dépôt ou un workspace. Une commande --precheck peut sauter un run quand il n’y a rien à faire.
• App mobile (bêta) : elle affiche les worktrees, leurs agents et leur état, permet de répondre brièvement à un agent bloqué et envoie une notification quand un agent a fini. Ce n’est volontairement pas un éditeur, et l’app desktop doit rester joignable.

Reste la CLI, livrée avec l’app et activable dans Settings → General → Orca CLI. Les agents eux-mêmes peuvent s’en servir. Exemple, créer un worktree lié à une issue :

orca worktree create --repo id:<repoId> --name my-task --issue 123 --json
orca worktree ps --json

🔗 Et le harness engineering dans tout ça ?

Orca ne remplace pas votre harnais, il lui donne un endroit où tourner. Dans l’article sur le harness engineering, je partais de la formule Agent = Model + Harness : le harnais, c’est tout ce qui entoure le modèle (instructions, hooks, tests, CI) pour qu’il livre juste. Orca se place une couche au-dessus. Il lance les agents, mais c’est votre harnais qui décide de la qualité de ce qu’ils produisent. Bonne nouvelle : il le respecte, et il en comble plusieurs trous.

Le harnais voyage avec le dépôt. Orca lit les CLAUDE.md et AGENTS.md sans y toucher, et les affiche dans l’explorateur pour les éditer sur place. Surtout, les hooks déjà présents dans .claude/ ou .codex/ s’exécutent quand Orca lance un agent dans un de ses worktrees. Le hook qui refuse le « c’est fini » tant que la vérification est rouge marche donc à l’identique dans dix worktrees en parallèle. Rien à reconfigurer.

L’étape 0 devient automatique. Le harnais commence par un projet qui se lance en une commande. Orca permet de déclarer, dans Settings → Repository → Hooks, des commandes exécutées à la création de chaque worktree : installer les dépendances, restaurer le .env. Avec sharedDirectories et .worktreeinclude, chaque nouvel agent démarre sur un projet prêt à tester, au lieu de deviner comment l’installer.

Le harnais de comportement gagne un navigateur. C’était la case vide de la grille de Böckeler. Chaque worktree a son propre Chromium, et la CLI Orca permet à l’agent de le piloter lui-même :

orca goto --url http://localhost:3000 --worktree active --json
orca snapshot --worktree active --json
orca click --element @e3 --worktree active --json
orca console --limit 50 --worktree active --json

L’agent peut donc vérifier sa fonctionnalité comme un utilisateur, lire la console et les requêtes réseau, sans que deux worktrees se disputent le même onglet.

Le sensor CI revient dans la boucle. Un check GitHub Actions rouge s’affiche sur le worktree, et « Fix broken checks » renvoie les échecs à un agent. La CI reste le juge final ; Orca raccourcit juste le trajet entre son verdict et la correction.

La boucle de pilotage se lit mieux. Le panneau d’historique des sessions liste les transcripts laissés par les agents, avec recherche par branche, modèle ou contenu, et accès au log brut. C’est exactement ce dont on a besoin pour relire les deux ou trois sessions qui ont mal tourné. Une mise en garde, quand même : annoter un diff et renvoyer les notes corrige la tâche en cours, pas le harnais. Si vous écrivez trois fois le même commentaire, il a sa place dans l’AGENTS.md ou dans un contrôle qui casse.

La garbage collection se planifie. Les automations Orca lancent un prompt sur un dépôt ou un workspace selon un planning (daily, weekly, cron…), avec une commande --precheck qui saute le run quand il n’y a rien à faire. C’est le job de nettoyage que je décrivais : comparer la doc d’architecture au code, chercher le code mort, ouvrir une petite PR.

Un harnais se teste comme du code. Les worktrees parallèles s’y prêtent bien : la même tâche, un agent avec l’ancien AGENTS.md, un autre avec la nouvelle version, et on compare les diffs avant de généraliser la règle.

Reste un point où Orca va à l’encontre du harnais : les permissions. En lançant les agents sans confirmation par défaut (voir les précautions), il retire une couche de garde-fous. Vos hooks, vos tests et votre CI deviennent alors les seuls contrôles. C’est un argument de plus pour les avoir avant d’ouvrir le premier worktree.

🚀 Installation

Sur macOS, Homebrew suffit :

brew install --cask stablyai/orca/orca

Pour Windows et Linux, les binaires (.exe, AppImage, .deb, .rpm) sont sur la page Releases du dépôt GitHub. Au premier lancement, Orca propose d’importer ~/.claude, ~/.codex et les réglages Ghostty.

⚠️ Quelques précautions

• Les symlinks partagés restent partagés. Un node_modules commun à tous les worktrees, c’est rapide, mais deux branches qui ont besoin de versions de dépendances différentes vont se gêner. Dans ce cas, mieux vaut une installation par worktree.
• Les agents tournent sans garde-fou par défaut. Orca considère que le worktree sert de bac à sable et lance chaque agent avec son option d’autonomie complète : --dangerously-skip-permissions pour Claude Code, --dangerously-bypass-approvals-and-sandbox pour Codex, --yolo pour Gemini. Or un worktree isole les fichiers de travail, pas le reste de la machine : l’agent peut lire votre $HOME, lancer n’importe quelle commande et accéder au réseau sans rien demander. Pour retrouver les confirmations, ouvrez Settings → Agents, dépliez l’agent et modifiez ses arguments de lancement (le bouton Reset rétablit la valeur d’origine). Sur un dépôt sensible, faites-le avant le premier lancement.
• Deux agents dans le même worktree partagent les mêmes fichiers. Répartissez-leur des zones distinctes, ou ouvrez un second worktree.
• Plusieurs agents en parallèle consomment plusieurs fois le quota. Le suivi d’usage aide, mais c’est à vous de doser.
• Sous Linux, la CLI s’appelle orca-ide, pour éviter le conflit avec le lecteur d’écran GNOME Orca.
• Le projet bouge très vite. Le README le dit lui-même : la liste des fonctionnalités a toujours un temps de retard sur le changelog. Vérifiez la doc avant de vous appuyer sur un comportement précis.

🎉 Conclusion

Orca n’invente rien sur le fond : git worktree existe depuis des années, et les agents CLI tournent très bien dans un terminal classique. Son apport est d’avoir assemblé ces briques autour d’une unité simple, la tâche, qui réunit un ticket, une branche, un dossier, les agents qui y travaillent et un diff à relire.

Si vous faites déjà travailler un agent sur plus d’une tâche à la fois, ou si vous perdez du temps à jongler entre Linear, le terminal et l’éditeur, essayez-le sur une semaine. C’est gratuit et open source ; prenez juste deux minutes pour régler les arguments de lancement des agents avant de le lâcher sur un vrai projet.

Les captures d’écran proviennent du README et du site officiels d’Orca.

🔗 Liens utiles

• Site officiel d’Orca
• Documentation Orca
• Doc : le modèle de worktrees
• Doc : agents et sessions
• Doc : intégration Linear
• Doc : intégration Jira
• Doc : automations
• Doc : app mobile
• Dépôt GitHub stablyai/orca
• Documentation git worktree