Choisir le backend terminal Hermes : local, Docker ou SSH pour une routine solo

Tu installes Hermes Agent. Tu lances un premier chat. Tout fonctionne. Puis tu lui demandes de modifier un fichier de config, de lancer un script ou d’installer un package. Et là, une question que la doc pose mais que personne ne formule à voix haute : est-ce que tu fais confiance à ton agent pour toucher à ta machine ?

La réponse n’est pas binaire. Elle dépend de ce que tu lui demandes, de ce que tu es prêt à perdre et du niveau de séparation que tu veux entre ton environnement de travail et l’agent qui exécute. Hermes Agent propose trois backends terminal pour ça : local, Docker et SSH. Chacun répond à un niveau de confiance différent. Le bon choix n’est pas le plus sécurisé dans l’absolu. C’est celui qui correspond à ta routine solo sans te ralentir.

La menace silencieuse : un agent qui exécute sans séparation

Par défaut, Hermes Agent utilise le backend local. Le terminal intégré exécute les commandes directement sur ta machine, dans le répertoire de travail que tu lui donnes. C’est pratique. C’est aussi le mode où l’agent a le plus de permissions.

Communauté Kavyro

Le vrai sujet n’est pas d’ajouter un agent de plus.

Si tu veux construire un système d’agents utile, il te faut surtout une structure claire, de bons arbitrages et des retours terrain. C’est exactement ce qu’on partage dans Kavyro.

Cas concrets
Arbitrages utiles
Questions réelles
Accès gratuit

Rejoindre la communauté

Tu arrives avec ton sujet, tu repars avec plus de clarté.

Le risque n’est pas que l’agent devienne malveillant. Le risque est qu’une instruction ambiguë, une erreur de chemin ou un script mal cadré touche un fichier que tu n’avais pas prévu de modifier. Si tu travailles dans un dépôt git avec des branches propres, le risque est faible. Si tu travailles dans un répertoire partagé avec des fichiers de prod, des clés SSH ou des configurations sensibles, le backend local devient un pari.

La documentation Hermes Agent ne cache pas cette réalité. Elle documente les backends alternatifs précisément pour ça : donner un moyen de séparer l’exécution de l’agent de ton environnement principal.

Backend local : le plus direct, le moins protégé

Le backend local est le mode par défaut. Tu lances Hermes, le terminal s’exécute là où tu es. Pas de conteneur à démarrer, pas de serveur à configurer, pas de latence réseau. Pour du développement, des tests rapides ou des tâches que tu surveilles en direct, c’est le chemin le plus court.

La configuration tient en trois lignes dans ~/.hermes/config.yaml :

terminal:
  backend: local
  cwd: "."
  timeout: 180

Le répertoire de travail (cwd) détermine ce que l’agent peut voir et toucher. Si tu le pointes vers un dossier de projet isolé, tu limites déjà la surface d’exposition. Si tu le laisses sur . dans ton home, l’agent voit tout.

Quand le backend local est le bon choix : tu testes un skill, tu développes une automatisation, tu travailles dans un dépôt git où un git checkout annule n’importe quelle bêtise. Quand il ne l’est pas : tu exécutes des commandes système qui touchent à des fichiers hors du dépôt, tu n’as pas de backup récent, ou tu partages ta machine avec d’autres projets sensibles.

Backend Docker : isolation légère, persistance de session

Le backend Docker de Hermes Agent n’est pas un conteneur jetable par commande. La documentation le décrit comme un conteneur unique, longue durée, partagé pendant toute la durée du processus Hermes. Concrètement, au premier appel terminal, Hermes lance docker run -d ... sleep 2h et route chaque commande suivante via docker exec dans ce même conteneur.

Ce détail change tout pour une routine solo. Tu peux installer un package une fois, il reste disponible. Tu changes de répertoire, les appels suivants le voient. Les fichiers écrits dans /workspace persistent d’un appel à l’autre, y compris à travers les sous-agents lancés via delegate_task. Le conteneur s’arrête et se supprime quand tu fermes Hermes.

La configuration est simple :

terminal:
  backend: docker
  docker_image: python:3.11-slim

L’isolation est réelle mais pas absolue. Le conteneur tourne sur ta machine, avec les ressources que tu lui alloues. Si tu actives container_persistent: true, les packages installés et les fichiers survivent même entre deux sessions Hermes. C’est utile pour une config stable, mais ça veut aussi dire qu’une erreur dans une session précédente peut persister dans la suivante.

Quand Docker est le bon choix : tu veux une isolation sans gérer un serveur distant, tu as besoin de reproductibilité (même image, mêmes packages), tu délègues des tâches à des sous-agents et tu veux que leur environnement soit cohérent. Quand il ne l’est pas : tu n’as pas Docker installé, ou tu as besoin d’une séparation physique plus forte.

Backend SSH : séparation physique, l’agent ne touche pas son propre code

Le backend SSH est le seul des trois qui déplace l’exécution hors de ta machine. La documentation Hermes le recommande pour la sécurité, avec une raison précise : l’agent ne peut pas modifier son propre code.

La configuration demande un serveur accessible en SSH :

terminal:
  backend: ssh

Avec les credentials dans ~/.hermes/.env :

TERMINAL_SSH_HOST=mon-serveur.example.com
TERMINAL_SSH_USER=monuser
TERMINAL_SSH_KEY=~/.ssh/id_rsa

L’avantage est clair : même si l’agent exécute une commande destructive, il touche le serveur distant, pas ta machine de travail. Ton code Hermes, tes skills, ta configuration restent intacts. Tu peux aussi donner à l’agent un environnement limité sur le serveur distant, avec un utilisateur dédié et des permissions restreintes.

La contrepartie est opérationnelle. Tu as besoin d’un serveur qui tourne, d’une connexion SSH stable, et d’une latence réseau que tu acceptes. Pour une routine solo, ça peut sembler lourd. Mais si tu exécutes des tâches non supervisées, des crons ou des workflows qui touchent à des données sensibles, cette couche de séparation vaut le coût de configuration.

La documentation ne promet pas une sécurité complète. Elle présente SSH comme une option de séparation. Les contrôles d’accès, la configuration réseau et les permissions du serveur distant restent sous ta responsabilité.

Tests : quel backend pour quel usage

Le choix dépend de trois critères simples : la confiance que tu as dans la tâche, le niveau d’isolation dont tu as besoin et la complexité que tu es prêt à gérer.

Critère	Local	Docker	SSH
Isolation	Aucune	Conteneur	Machine distante
Configuration	Zéro	Docker installé	Serveur SSH + clés
Persistance	Fichiers locaux	Session Hermes (ou permanente si activé)	Serveur distant
Latence	Nulle	Faible	Réseau
Risque si erreur	Ta machine	Le conteneur	Le serveur distant
Usage typique	Dev, tests surveillés	Tâches isolées, sous-agents	Tâches non supervisées, crons

Pour une tâche de développement que tu surveilles en direct, le backend local suffit. Pour une tâche que tu délègues à un sous-agent et que tu ne veux pas voir toucher à tes fichiers, Docker donne une isolation propre sans serveur externe. Pour un cron qui tourne la nuit sur des données sensibles, SSH ajoute une séparation physique.

Décision : choisis l’environnement avant les tâches système

Le piège classique est de commencer en local, de prendre l’habitude, puis de se rendre compte après une erreur qu’il fallait isoler depuis le début. Le bon moment pour choisir le backend, c’est avant la première tâche système, pas après.

Si tu débutes avec Hermes Agent, commence par le backend local sur un dépôt git propre. Tu verras ce que l’agent fait, tu pourras annuler, et tu apprendras à cadrer tes instructions sans la friction d’un conteneur ou d’un serveur.

Dès que tu passes à des tâches non supervisées, passe sur Docker. L’isolation est légère à mettre en place, la persistance de session est documentée, et tu gardes le contrôle sans gérer un serveur.

Si tu exécutes des crons, des workflows qui touchent à des données clients ou des tâches où une erreur coûte cher, configure SSH. La séparation physique n’est pas un luxe. C’est une assurance que ton agent ne modifiera jamais son propre code ni tes fichiers de configuration principaux.

Le backend terminal n’est pas un détail d’installation. C’est la première décision de confiance que tu prends avec ton agent. Une fois que tu as choisi, tu peux passer aux tâches concrètes : installer un skill, créer un cron, déléguer une veille. Mais l’ordre compte. L’environnement d’abord, les automatisations ensuite.

Si tu veux poser ces bases proprement et comprendre comment enchaîner sur des automatisations utiles, la formation Hermes Agent couvre l’installation, le premier agent et les crons, avec une communauté française pour les retours terrain. Tu peux faire une demande d’accès directement sur la page de la formation.