Orca CLI : un pipeline d'agents, des tâches aux workspaces

Comment une tâche devient le travail d'un agent dédié

Ce qui m'intéresse ici n'est pas l'interface d'Orca elle-même, mais l'association d'Orca CLI et des automations : une carte déplacée dans Select for development peut devenir l'entrée d'une exécution d'agent dédiée. La présentation officielle et la référence d'Orca CLI décrivent des opérations sur les worktrees, les terminaux, les fichiers, les diff, un navigateur intégré et des rapports de progression. Une documentation distincte sur les scheduled automations confirme le lancement de tâches pour un dépôt ou un workspace existant.

J'ai téléchargé Orca et l'ai essayé pendant quelques heures. Je n'ai pas eu envie de transférer immédiatement tout mon flux de travail, mais le scénario d'un kanban Markdown montre bien pourquoi une CLI au-dessus de l'environnement de développement peut être utile. Orca ne devient pas un écran de plus avec un agent, mais une couche d'exécution entre une tâche et un dépôt.

Le pipeline proposé ressemble à ceci :

• une tâche apparaît dans un kanban Obsidian et change de statut ;
• un workspace isolé avec sa propre branche est créé pour elle ;
• un mini-agent effectue le travail et prépare un changelog ;
• le statut et le résultat reviennent dans le fichier Markdown ;
• la fusion et le déploiement restent des étapes distinctes.

Une réserve essentielle s'impose : les ressources officielles d'Orca confirment la prise en charge de worktrees isolés, d'automatisations et d'artefacts Markdown, mais pas d'intégration Obsidian prête à l'emploi. Au 24 août 2026, la documentation réunie ne décrit pas cette connexion. La surveillance des changements du kanban et la mise à jour du vault doivent donc être organisées comme une couche externe, et non considérées comme une fonction intégrée.

Pourquoi le kanban fichier compte plus que l'interface

Cette approche peut réellement transformer le travail sur plusieurs projets, sans le rendre magiquement autonome. Un simple fichier Markdown devient une file de tâches, tandis que les workspaces isolés limitent le risque de mélanger contextes, branches et modifications inachevées entre agents parallèles.

Je commencerais par vérifier l'idempotence : un événement répété créera-t-il un second workspace pour la même carte ? Viennent ensuite la reprise après l'échec d'un agent, les conflits de branches, la synchronisation des statuts et le critère de finalisation. Sans cela, un pipeline élégant produit vite non pas du code, mais une collection de worktrees oubliés.

Ce n'est pas une révolution de la productivité personnelle, mais une orchestration pragmatique d'éléments familiers : Git, Markdown, planifications et agents. La question la plus intéressante reste ouverte : combien de temps ce control plane fondé sur des fichiers peut-il rester simple lorsque les tâches et les dépôts deviennent vraiment nombreux ?

Nous avons déjà analysé comment des agents Claude Code parallèles vérifient les PR et détectent des conditions de concurrence dans les workflows. Cette approche complète les workspaces isolés, où chaque agent a besoin d'un environnement distinct pour sa tâche.