Agent of Empires : orchestrer plusieurs agents de code dans des sessions tmux persistantes

Le problème : plusieurs agents, un seul terminal

Lancer un agent de code en ligne de commande est simple. En lancer quatre en parallèle sur des branches différentes ne l'est plus. Chaque processus occupe un terminal, la sortie se mélange, et fermer la fenêtre tue le travail en cours. Le README décrit AoE comme un gestionnaire de sessions pour agents de code sur Linux et macOS, dont le but est de faire tourner les agents en parallèle à travers des branches, de les surveiller depuis le TUI ou un navigateur, et de garder chacun dans une session persistante. Le public visé est donc celui qui utilise déjà des CLI d'agents au quotidien et qui a besoin de suivre leur état sans rester devant un écran unique. Le projet cite Claude Code, OpenCode, Mistral Vibe, Codex CLI, Gemini CLI, Pi.dev, Copilot CLI et Factory Droid Coding parmi les outils pris en charge, mais précise aussi que la liste courante dépend de la machine : `aoe agents` affiche ce qui est réellement disponible localement.

Une session tmux par agent, et rien de plus

Le mécanisme central tient en une phrase du README : chaque agent tourne dans sa propre session tmux, ce qui signifie que les agents continuent de fonctionner quand on ferme le TUI, qu'on coupe SSH ou que le terminal plante. Rouvrir `aoe` restitue l'état. Le raccourci à connaître est `Ctrl+b d`, qui détache la session et ramène au TUI. Ce choix a une conséquence importante : AoE n'est pas un runtime d'agents, c'est une couche d'orchestration posée au-dessus de tmux. On peut d'ailleurs attacher n'importe quelle session AoE directement avec `tmux attach`. La valeur ajoutée revendiquée par rapport à tmux seul est une détection d'état adaptée aux agents (running, waiting, idle, error), la gestion des worktrees git, le bac à sable Docker, un tableau de bord web, l'accès à distance depuis un téléphone et un lecteur de diffs. Le README positionne explicitement le projet comme un emballage autour du flux tmux existant, pas comme un remplacement.

Installation et premières commandes

tmux est un prérequis obligatoire, Docker est optionnel et sert au bac à sable. Le README donne quatre voies d'installation. Le script rapide s'exécute avec `curl -fsSL https://raw.githubusercontent.com/agent-of-empires/agent-of-empires/main/scripts/install.sh | bash`. Homebrew fournit `brew install aoe`, Nix permet `nix run github:agent-of-empires/agent-of-empires`, et la compilation depuis les sources passe par `git clone`, puis `cd agent-of-empires && cargo build --release`. Une fois installé, `aoe` lance le TUI, `aoe add --cmd claude` crée une session exécutant Claude Code, et `aoe serve` démarre le tableau de bord web. Dans le TUI, la touche `?` ouvre l'aide et la barre d'information inférieure affiche les raccourcis disponibles selon le contexte. Le README mentionne aussi que la construction avec la fonctionnalité web se fait via `cargo build --features web`, ce qui suggère que l'interface web n'est pas incluse par défaut dans un binaire compilé à la main.

Persistance, SSH et la question de Windows

La persistance est le point le plus solide du projet, et le README la traite sans ambiguïté dans sa FAQ. Fermer `aoe` ne supprime rien : les sessions tmux continuent en arrière-plan et ne disparaissent que sur suppression explicite. Le cas d'usage SSH est couvert directement, puisque la reconnexion consiste à relancer `aoe`. En revanche, Windows natif n'est pas pris en charge, uniquement via WSL2, parce qu'AoE dépend de tmux et de la gestion des processus POSIX. C'est une contrainte structurelle, pas un manque temporaire : elle découle de l'architecture choisie. Pour une équipe entièrement sous Windows sans WSL2, l'outil est simplement le mauvais choix, quelle que soit la qualité du reste.

Isolation par worktree et par conteneur : ce que le README ne tranche pas

Le README liste les worktrees git, les espaces de travail multi-dépôts et l'isolation par Docker, Podman ou Apple Containers parmi les fonctionnalités. Il mentionne également les profils, les hooks de dépôt et les commandes d'agent personnalisées. Ces éléments sont nommés, mais leur fonctionnement détaillé n'apparaît pas dans le matériel fourni : ni les clés de configuration, ni le format des hooks, ni la manière dont un worktree est créé ou nettoyé. Il faut donc se référer à la documentation du site et aux références CLI et HTTP API pour obtenir ces détails. Un point mérite l'attention : l'isolation par conteneur suppose que Docker, Podman ou Apple Containers soient déjà installés et fonctionnels. Ce n'est pas une fonctionnalité activée par défaut, et le README présente Docker comme optionnel. Une équipe qui compte sur le bac à sable pour contenir des agents exécutant du code non vérifié doit donc valider cette chaîne séparément.

Le rythme des versions et le coût de maintenance

Les versions récentes fournies montrent v1.15.3 le 2 septembre 2026, v1.15.2 le même jour, et v1.15.1 le 28 août 2026. Deux publications le même jour suggèrent des correctifs rapides plutôt qu'un cycle planifié, et le dernier push sur le dépôt date du 9 septembre 2026. Le projet n'est pas archivé. Pour un utilisateur, cela implique de suivre les versions de près si l'on dépend de fonctionnalités récentes, mais aussi que la surface de l'outil évolue vite : TUI, web, CLI et API HTTP sont quatre interfaces à maintenir. La licence est MIT, ce qui autorise la réutilisation et la modification, y compris dans un contexte commercial. Une nuance figure dans le README : le fichier `src/tui/hyperlink.rs` contient du code dérivé de herdr sous Apache License 2.0, et le fichier `THIRD_PARTY_NOTICES.md` en documente les termes. Si vous redistribuez un binaire, cette combinaison de licences mérite un examen attentif de votre côté.

Face à tmux seul, et face aux autres orchestrateurs

La comparaison la plus honnête est celle que le projet fait lui-même : tmux offre des sessions persistantes, AoE ajoute la détection d'état orientée agent, la gestion des worktrees, le bac à sable, le tableau de bord web et le lecteur de diffs. Si vous êtes déjà à l'aise avec tmux et que vous n'avez pas besoin de surveiller vos agents depuis un navigateur, l'écart de valeur se réduit à la détection d'état et aux worktrees. Le README indique par ailleurs que le projet s'inspire d'agent-deck, écrit en Go avec Bubble Tea. Les deux outils partagent donc la même intention, mais AoE est en Rust et met l'accent sur les surfaces web et mobile ainsi que sur l'isolation par conteneur, là où agent-deck se présente comme une application terminal. Le choix entre les deux dépend surtout de l'écosystème que vous acceptez de maintenir et de la nécessité ou non d'un accès depuis un téléphone.

Conclusion éditoriale

AoE convient à ceux qui font déjà tourner plusieurs agents en parallèle sur Linux ou macOS et qui veulent retrouver leurs sessions après une déconnexion SSH ou un crash de terminal, sans renoncer à tmux. Il ne convient pas à ceux qui travaillent sous Windows natif, ni à ceux qui refusent la dépendance à tmux, et l'isolation par conteneur n'a de sens que si Docker, Podman ou Apple Containers sont déjà en place. Avant d'adopter, lancez `aoe agents` pour vérifier quels outils sont détectés sur votre machine, puis `aoe add --cmd claude` sur un dépôt jetable pour confirmer le comportement des worktrees et des hooks.

Sources officielles

1. agent-of-empires/agent-of-empires on GitHub
2. License: MIT
3. Project website
4. README
5. Releases