Emdash : orchestrer plusieurs agents de codage dans des worktrees Git isolés

Un worktree par tâche, pas un terminal par tâche

Le problème visé est précis : quand on demande à un agent de corriger un bug, on hésite souvent entre plusieurs approches, et les tester l'une après l'autre coûte du temps de relecture. Emdash répond en donnant à chaque tâche son propre worktree Git et sa propre branche. Le README le formule ainsi : chaque tâche tourne dans son worktree, ce qui permet d'explorer plusieurs correctifs ou fonctionnalités en parallèle, de relire les diffs, puis de fusionner ce qui fonctionne. Le public visé n'est donc pas le débutant qui découvre les agents de codage, mais celui qui en utilise déjà un en ligne de commande et bute sur la sérialisation des essais. L'application est un client de bureau, pas une bibliothèque à importer : elle s'installe comme un logiciel classique et pilote des CLI déjà présentes sur la machine.

Ce qu'Emdash ajoute réellement autour des CLI

Emdash ne fournit pas de modèle. Il détecte les CLI de fournisseurs déjà installées et s'appuie dessus : le README cite Claude Code, Codex, Cursor, OpenCode, Amp, Devin, Qwen Code, Droid et GitHub Copilot. La mécanique d'intégration repose sur des hooks de cycle de vie. Pour les agents qui les supportent, Emdash installe des entrées marquées dans la configuration utilisateur de l'agent. Ces hooks servent à suivre le statut, à remonter des notifications et à reprendre des sessions, et le README précise qu'ils ne font rien lorsque l'agent tourne en dehors d'une session Emdash. C'est le point d'architecture le plus intéressant du projet, et aussi le plus intrusif : l'application écrit dans des fichiers de configuration que vous ne contrôlez peut-être pas. Autour de cela, l'état de l'application vit dans une base SQLite locale, et les projets distants passent par SSH/SFTP avec authentification par agent SSH, clé ou mot de passe, les identifiants étant stockés dans le trousseau du système d'exploitation.

Installation et premiers réglages

Sur macOS, le README donne la commande Homebrew : `brew install --cask emdash`. Des images disque sont aussi publiées pour Apple Silicon et Intel. Windows dispose d'un installateur MSI et d'une version portable en `.exe`. Linux est couvert en x64 et ARM64 avec AppImage, DEB et RPM. Le projet publie des versions canari fréquentes en plus des versions stables, la dernière stable listée étant v1.2.4. Côté configuration, le seul réglage explicitement documenté dans le README concerne la télémétrie, désactivable dans les paramètres ou au lancement avec `TELEMETRY_ENABLED=false`. Le reste, notamment la connexion aux machines distantes et le choix des fournisseurs, renvoie aux pages de documentation du site. C'est une limite du matériau fourni : le README ne détaille pas les clés de configuration des projets distants ni le format exact des entrées de hooks, seulement leur existence et leur portée.

Le point de confidentialité que le README assume à moitié

Le README affirme qu'Emdash est local-first : l'état de l'application reste dans une base SQLite locale et rien du code ou des conversations n'est envoyé aux serveurs d'Emdash. C'est vrai pour l'application elle-même, mais la phrase suivante change tout : les CLI d'agents peuvent transmettre code, prompts et contexte à leurs propres fournisseurs, selon leur propre politique. Autrement dit, la promesse de confidentialité s'arrête à la frontière du processus de l'agent. Pour un dépôt sous contrainte réglementaire, ce n'est pas Emdash qu'il faut auditer en premier, c'est le fournisseur de l'agent choisi. Le projet ne prétend pas le contraire, mais un lecteur pressé pourrait confondre local-first et aucune sortie de données. La télémétrie, elle, est optionnelle et désactivable, ce qui est cohérent avec la position annoncée.

Là où l'outil ne convient pas

Trois cas de figure posent problème. D'abord, l'absence de CLI d'agent installée : Emdash détecte, il ne fournit pas. Sur une machine neuve, l'application n'a rien à piloter tant que vous n'avez pas installé un des fournisseurs listés. Ensuite, l'écriture dans la configuration utilisateur des agents pour les hooks. Si votre équipe gère ces fichiers par un mécanisme de dotfiles versionné ou par une politique centralisée, l'ajout d'entrées marquées par une application de bureau peut entrer en conflit avec cette gestion, même si le README indique que ces hooks sont inertes hors session Emdash. Enfin, le modèle du worktree par tâche a un coût : chaque worktree est une copie de travail supplémentaire, et lancer plusieurs agents en parallèle multiplie les processus et la consommation de ressources. Le README ne publie aucune mesure à ce sujet, et je n'en inventerai pas. Pour un petit dépôt et une seule piste à explorer, lancer l'agent directement dans son terminal reste plus simple qu'une application de bureau avec sa base SQLite et ses hooks.

Face à un simple script de worktrees

L'alternative la plus directe n'est pas un autre produit, c'est ce que fait déjà un développeur méthodique : `git worktree add` dans une boucle, un terminal par worktree, et un agent lancé dans chacun. Cette approche donne exactement la même isolation par branche, sans couche supplémentaire. La différence tient à ce qu'Emdash ajoute par-dessus : la détection automatique des CLI installées, le suivi du statut via hooks, la reprise de sessions, l'envoi de tickets depuis Linear, GitHub, Jira, GitLab, Asana, Featurebase, Monday.com, Forgejo ou Plain, et la relecture des diffs, la création de pull requests, l'inspection des checks CI et la fusion depuis une seule interface. Un script de worktrees ne fait rien de tout cela, et c'est précisément le travail d'intégration qui justifie l'application. À l'inverse, si vous n'utilisez ni Linear, ni Jira, ni GitHub Issues comme point d'entrée des tâches, une partie de la valeur disparaît.

Licence, mises à jour et coût de suivi

Le projet est sous Apache-2.0. Cette licence permet l'usage commercial, la modification et la redistribution, avec conservation des mentions de copyright et du texte de licence, et elle inclut une concession de brevet. Elle n'impose pas de publier vos modifications. Je ne donne pas de conseil juridique : pour un usage en entreprise, faites relire le fichier LICENSE.md du dépôt. Le rythme de publication est soutenu, avec des versions canari quasi quotidiennes et des versions stables plus espacées. Ce rythme a une conséquence pratique : si vous suivez le canal stable, vous accumulez du retard sur les corrections ; si vous suivez le canal canari, vous acceptez des builds non validés. Le README ne décrit aucune politique de support ni de fenêtre de compatibilité pour les versions anciennes. Les hooks installés dans la configuration des agents constituent le principal coût caché : après une mise à jour d'un agent, leur format peut changer, et c'est Emdash qui doit suivre.

Conclusion éditoriale

Emdash convient aux développeurs qui font déjà tourner un agent de codage en ligne de commande et veulent paralléliser plusieurs pistes sans empiler les terminaux. Ceux qui cherchent une barrière de sécurité entre l'agent et leur code doivent d'abord lire la page Providers sur les hooks installés dans la configuration utilisateur, puis vérifier si leur agent figure dans la liste détectée automatiquement. À tester en priorité : la création d'un worktree par tâche et l'inspection des hooks avant d'ouvrir un dépôt sensible.

Sources officielles

1. generalaction/emdash on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases