tmux, cmux, herdr : orchestrer des agents, pas des shells

Avec trois ou quatre sessions de coding agents en parallèle, mon tmux local était devenu un tableau de bord aveugle : des panes indistinguables, aucun moyen de savoir qui attendait une validation, qui tournait, qui avait fini depuis dix minutes. tmux multiplexe des shells. Il ne sait pas — et n’a jamais prétendu savoir — qu’un pane contient un agent avec un état.

C’est le vrai changement de besoin : on ne multiplexe plus des terminaux, on orchestre un troupeau de sessions. Et une génération d’outils est née exactement là-dessus.

Avant d’en changer, j’ai d’ailleurs essayé de l’apprendre à tmux. Un hook branché sur les événements de Claude Code pousse l’état de l’agent dans la status bar : ● quand un tour est en cours, une cloche quand il attend mon feu vert, ✓ quand il a fini, ✗ quand il a planté — et le marqueur s’efface quand je redonne le focus à la fenêtre. Ça marche, c’est toujours dans mes dotfiles. Mais ça ne couvre que l’agent qui expose des hooks, ça se rebranche outil par outil, et ça ne donne que la moitié lecture du problème : l’état remonte, rien ne se pilote. Ce bricolage m’a surtout confirmé que le besoin était réel — et qu’il méritait mieux qu’un hook.

tmux garde les serveurs, sans débat

Sur les serveurs, rien ne déloge tmux : binaire présent partout, persistance des sessions à travers les déconnexions SSH, zéro dépendance. Mes serveurs restent en tmux et ça ne changera pas. Le piège serait d’en conclure qu’il doit aussi rester en local par cohérence — c’est une cohérence qui ne rapporte rien.

herdr en local : adopté en quelques jours

herdr est un multiplexeur pensé pour les agents : il expose l’état sémantique de chaque session (actif, bloqué, terminé), se pilote par CLI et socket JSON, et se customise par config et plugins (150+ plugins communautaires recensés via un tag GitHub, d’après herdr.dev en juillet 2026). Il tourne côté terminal comme tmux — Linux/macOS stables, Windows en bêta — pas comme une app desktop.

Je l’utilise depuis quelques jours seulement, en v0.7.3 — et c’est déjà mon quotidien. La bascule s’est jouée sur un point : l’agent lui-même peut piloter le multiplexeur. Un skill Claude Code contrôle mes panes, tabs et workspaces herdr ; l’agent n’est plus un locataire d’un pane, il est citoyen de l’outil. Ce n’est reproductible en tmux qu’à coups de scripts send-keys fragiles.

Deux pièges vérifiés en v0.7.3, pour être honnête : herdr server reload-config ne valide qu’à moitié (une action inconnue dans un binding est ignorée silencieusement — « applied » ne prouve rien), et les noms de touches symboliques sont des positions QWERTY — sur un clavier AZERTY, ça fait des bindings morts sans aucun message. J’ai perdu du temps sur les deux.

cmux : le clé en main macOS

Je n’ai pas utilisé cmux — ce paragraphe est du positionnement, pas une review. C’est l’outil qui concentre la hype YouTube du moment : app macOS native basée sur Ghostty, open source (GPL-3.0, ~22k stars en juillet 2026), notifications agent-aware, navigateur scriptable intégré, le tout sans config. Les retours plus mesurés le résument bien : un tmux clé en main, opinionated. Si tu es sur macOS et que tu veux que ça marche tout de suite sans rien régler, c’est probablement le bon défaut. Si tu vis en SSH ou que tu veux modeler l’outil — keybindings, plugins, pilotage par l’agent — c’est herdr.

Un outil par contexte

La question « qu’est-ce qui remplace tmux ? » n’est pas celle à se poser. tmux n’est pas remplacé, il est recentré sur ce qu’il fait mieux que tout le monde : les serveurs. En local, là où vivent les agents, le poste revient à un outil qui comprend ce qu’il héberge — herdr si tu veux le customiser et rester cross-platform, cmux si tu veux du macOS clé en main.

Le seul mauvais choix : garder tmux partout par habitude et scroller manuellement quatre panes pour savoir si un agent attend ton feu vert depuis vingt minutes.