Herdr, Hermes et un VPS : mes agents continuent sans mon Mac

▶️ Voir la vidéo complète

Je travaille souvent sur plusieurs produits en parallèle. Chaque projet finit par avoir ses terminaux, ses branches, ses tests et plusieurs sessions Claude Code ou Codex. Tant que tout tient dans deux onglets, ça va. Dès que les agents se multiplient, je perds du temps à retrouver celui qui attend une réponse, celui qui a terminé et celui qui tourne encore.

J’ai donc séparé deux problèmes que je mélangeais jusque-là : organiser les sessions et faire tourner le travail sur une machine qui reste disponible. Herdr répond au premier. Un VPS répond au second. Hermes me donne un accès à distance pour demander un état, prendre une décision et reprendre la main quand c’est nécessaire.

Pourquoi les splits de terminal ne suffisent plus

Ghostty, tmux et les terminaux à panneaux restent utiles. Je les utilise encore. Le problème apparaît quand l’écran devient une pile de contextes difficiles à relire.

Avec plusieurs projets en cours, il faut pouvoir répondre vite à quatre questions :

• quel agent travaille sur quel dépôt et quelle branche ;
• quelle session attend une décision humaine ;
• quels tests ont réellement réussi ;
• où retrouver la conversation et le diff sans reconstruire le contexte.

Un panneau supplémentaire affiche un processus. Il ne transforme pas automatiquement une flotte de terminaux en système lisible.

Herdr organise les sessions sans remplacer les agents

Herdr est un runtime de terminaux conçu pour le travail multi-agent. Il organise les sessions en trois niveaux : workspace, tab et pane. Dans mon usage, un workspace correspond à un projet ou à un objectif, un tab regroupe une partie du travail et chaque pane contient un vrai terminal.

Claude Code, Codex et les shells continuent d’exécuter les tâches. Herdr ne les remplace pas. Il fournit le cockpit qui permet de voir les sessions, de passer de l’une à l’autre et de repérer celles qui semblent travailler, attendre ou avoir terminé.

Un statut done n’est pas une preuve de qualité. Je vérifie toujours le diff, les tests et le résultat fonctionnel. Le cockpit réduit le temps de recherche ; il ne remplace pas la revue.

La machine d’exécution change tout

Un agent lancé sur mon Mac s’exécute sur mon Mac, même s’il appelle un modèle distant. Si la machine se met en veille, son travail local est suspendu. Si elle s’éteint, le processus s’arrête. Une session persistante comme tmux aide à survivre à la fermeture du client, mais elle ne fait pas travailler un ordinateur endormi.

Le passage sur un VPS déplace les dépôts, les agents, les tests et le serveur de sessions vers une machine distante qui reste disponible. Mon Mac devient un client. Je peux me déconnecter puis retrouver les mêmes sessions plus tard, depuis une autre machine autorisée.

Ce déplacement impose aussi des contraintes : les dépendances doivent être installées sur le VPS, les secrets doivent être limités au strict nécessaire et les fichiers locaux ne se synchronisent pas tout seuls.

Mon workflow avec Herdr, Hermes et le VPS

Je garde un déroulé simple :

1. Je définis deux tâches indépendantes avec leurs critères d’acceptation.
2. Je crée des branches ou des worktrees séparés si les agents écrivent en parallèle.
3. Je lance Claude Code et Codex dans des panes identifiables.
4. Je vérifie l’état avant de quitter la machine : session, branche, sortie courante et tests attendus.
5. À distance, je demande à Hermes l’état des sessions et leur dernière sortie utile.
6. Si un agent pose une question de produit, j’arrête la boucle et je décide.
7. À mon retour, je rouvre le même cockpit, puis je lis les diffs et je relance les tests.

Le téléphone ne devient pas un IDE. Telegram et Hermes servent à obtenir un état ou à donner une décision courte. Pour lire du code, reprendre une conversation ou corriger une implémentation, je reviens dans le terminal.

Ce que ce setup prouve, et ce qu’il ne prouve pas

La démonstration montre qu’un processus distant peut continuer après la déconnexion du laptop et que je peux retrouver ses sessions. Elle ne prouve pas qu’un agent restera productif toute la nuit.

Un agent peut s’arrêter parce que :

• sa tâche est terminée ;
• une question demande une décision humaine ;
• un quota ou un budget est atteint ;
• un test échoue sans correction sûre ;
• le VPS manque de RAM, de CPU ou d’espace disque ;
• une dépendance ou un service externe devient indisponible.

La disponibilité de la machine n’est donc qu’une condition. L’autonomie utile vient aussi de tâches bornées, de critères d’acceptation, de tests, de permissions minimales et d’une règle claire pour demander de l’aide.

Les garde-fous que je conserve

Je ne donne pas à un agent distant un accès illimité sous prétexte qu’il doit travailler sans moi. Je sépare les worktrees, je limite les credentials, je ne merge pas automatiquement les changements sensibles et je garde le déploiement sous validation humaine.

Avant de laisser une tâche tourner, je vérifie :

• le périmètre exact du dépôt et de la branche ;
• les commandes de test attendues ;
• les actions interdites, notamment merge et déploiement ;
• la manière de signaler un blocage ;
• le chemin de retour si le résultat est mauvais.

Ce setup m’apporte surtout de la continuité. Je retrouve les agents, leurs conversations et les preuves à contrôler sans demander à une nouvelle session de reconstituer le travail.

▶️ Voir le setup Herdr + Hermes + VPS en vidéo

Pour recevoir mes workflows IA et développement agentique : The Agentic Dev.