herdr : runtime de terminal pour agents de code

Contexte

Les agents de code en terminal se sont multipliés. Claude Code, Codex, Cursor et OpenCode proposent chacun leur interface en ligne de commande, et les développeurs gardent souvent plusieurs fenêtres ouvertes en même temps. Un agent modifie le frontend, un autre lance les tests, un troisième attend que vous validiez une permission. Avec autant de fenêtres, trois questions surgissent. Quel agent est bloqué ? Une coupure SSH tue-t-elle la tâche en cours ? Et quand on change de machine, comment retrouver la bonne session ?

La réponse classique s'appelle tmux, qui garde les sessions en vie. Mais tmux ignore ce qu'est un agent : il ne voit qu'un flux de caractères. herdr vise cette lacune. C'est un runtime de terminal en un seul fichier, écrit en Rust, qui se présente comme l'environnement dans lequel vivent les agents de code. Ce n'est pas un agent de plus et il ne remplace aucun agent existant. Il prend en charge le terminal où ils tournent et leur offre un foyer stable, observable, que d'autres programmes peuvent orchestrer.

Le projet est hébergé sur GitHub et dépasse les 45 000 étoiles, ce qui suggère un besoin très répandu. Dans le paysage des outils, il se place entre les agents en ligne de commande et le terminal du système d'exploitation. On peut le décrire comme un multiplexeur de terminal pensé pour les agents, avec une couche d'orchestration en plus.

Analyse approfondie

Que fait concrètement herdr pour les agents de code ? Ses capacités se répartissent en quatre blocs. Le premier est le détachement sans interruption. Quand vous fermez le client ou perdez la connexion SSH, un service en arrière-plan maintient les terminaux en marche. Si le serveur ou la machine entière redémarre, herdr restaure la disposition enregistrée et peut reprendre les sessions des agents pris en charge. Le projet est explicite sur la limite : les processus d'origine ne survivent pas. Ce qui revient, c'est la disposition et les sessions, pas les processus eux-mêmes. Le deuxième bloc réunit plusieurs machines dans une seule fenêtre. Le travail local et les hôtes ssh enregistrés cohabitent, et la liste des agents est fusionnée. Chaque machine se reconnecte de façon indépendante : un hôte qui tombe n'entraîne pas les autres. Le troisième est le marquage d'état. Chaque volet est étiqueté working, blocked ou idle. Quand un agent s'arrête pour attendre votre réponse, herdr le signale directement, sans que vous ayez à inspecter les fenêtres une à une. Le quatrième est l'interface agent-native. Les agents peuvent piloter herdr par la ligne de commande et une API socket. Ils créent des volets, envoient des prompts à d'autres agents et attendent qu'un autre soit réellement bloqué avant d'agir. Le travail multi-agents n'exige alors pas de cadre d'orchestration supplémentaire : le terminal devient lui-même le lieu de collaboration.

Côté compatibilité, Claude Code, Codex, Cursor, OpenCode et Grok fonctionnent directement. herdr ne possède que leur terminal et n'enveloppe rien. L'interaction suit les habitudes de tmux : touche préfixe, mais aussi clic, glisser et division de volets en actions de premier rang. Un système de plugins et une place de marché existent. Le produit tient en un binaire Rust, sans Electron, et s'exécute dans le terminal que vous utilisez déjà.

Impact sur l'industrie

La prise en main est courte. L'installation tient en un script curl, ou en brew install herdr, ou en mise use -g herdr. Windows dispose d'un script PowerShell, et des binaires précompilés figurent sur la page des versions. Une fois installé, on lance herdr dans son répertoire de travail, on démarre quelques agents, on divise les volets à volonté, puis on se détache avec ctrl+b q. Relancer herdr rétablit la connexion. Un cas typique : une machine de développement distante qui fait tourner plusieurs agents. Vous fermez l'ordinateur portable le soir, revenez le lendemain et vous reconnectez. La disposition et les sessions sont toujours là, et le volet qui attend votre réponse se repère aisément. Le site de documentation couvre le démarrage rapide, les concepts de base, les agents pris en charge, les raccourcis, la configuration, l'état des sessions, les connexions multi-machines, la persistance distante, les intégrations, les plugins et l'API socket. Un guide distinct explique comment ajouter la prise en charge de herdr à son propre agent.

Le dépôt contient aussi AGENTS.md et CONTRIBUTING.md, et demande aux agents IA qui y travaillent de les lire avant toute modification. Pour un projet dont les utilisateurs incluent des agents, ce choix est cohérent. Les contributeurs compilent avec cargo build --release, lancent les tests unitaires avec just test, et exécutent formatage, tests et contrôles de maintenance avec just check. Pour l'industrie, l'intérêt est que herdr traite le terminal comme une infrastructure de l'ère des agents. Les agents étaient des programmes isolés en ligne de commande. Ils tournent désormais longtemps, coopèrent et se répartissent sur plusieurs machines. Cela réclame une base qui sache qui travaille, qui est bloqué et qui peut être réveillé. Pour les équipes d'ingénierie, cela réduit le coût d'attention lié au pilotage de nombreux agents.

Perspectives

Plusieurs risques méritent l'attention. D'abord, restaurer ne veut pas dire que le processus a survécu. La reprise après un redémarrage dépend du support de chaque agent pour la récupération de session : mieux vaut ne pas la tenir pour acquise. Ensuite, l'API socket permet aux agents de créer des volets et de se donner des instructions. La frontière des permissions et la surface d'attaque relèvent de l'utilisateur, surtout entre plusieurs machines. Enfin, la détection de l'état de chaque agent exige des adaptateurs. Si un agent change de comportement après une mise à jour, l'adaptateur devra suivre.

Une réserve concerne la licence. La mention de licence dans le matériel source était tronquée : une équipe doit donc vérifier les conditions dans le dépôt avant d'adopter herdr.

Trois évolutions sont à surveiller. La place de marché de plugins deviendra-t-elle un véritable écosystème ? Jusqu'où s'étendra la liste des agents pris en charge ? Et le schéma où les agents s'attendent et se relancent mutuellement se stabilisera-t-il en flux de travail fiables dans des projets réels ? Les réponses diront si herdr reste un multiplexeur pratique ou devient une couche d'exécution standard pour le développement piloté par agents.