Hermes Agent sous Docker : installation et durcissement testés

« Hermes agent » et « hermes vs openclaw » reviennent régulièrement dans les recherches françaises, mais le nom est ambigu : plusieurs projets s’appellent Hermes. Un seul est comparé à OpenClaw dans les sources datées de 2026. Il est identifié ici, installé et durci sous Docker dans un labo isolé, en distinguant à chaque étape ce qui a réellement tourné de ce qui reste documenté.

Quel Hermes Agent, au juste ?

Le projet visé par ces recherches est Hermes Agent, développé par Nous Research et publié sous licence MIT dans le dépôt NousResearch/hermes-agent. Le dépôt affichait 242 851 étoiles et 49 953 forks le 7 septembre 2026, pour une création le 22 juillet 2025. Sa description tient en une phrase : « the agent that grows with you ». Un agent unique, qui crée et affine ses propres compétences à partir de l’expérience, à l’opposé d’une plateforme d’orchestration de plusieurs agents. Cette opposition de philosophie revient dans les comparatifs publiés en 2026 face à OpenClaw, et confirme qu’il s’agit bien du projet visé par les requêtes « hermes vs openclaw ».

Deux pièges de nommage à éviter. hermes-webui est un client web tiers non maintenu par Nous Research. « HermesHub » désigne un index communautaire de compétences, distinct du hub officiel intégré au CLI. Les deux se confondent facilement avec le projet principal dans les résultats de recherche. Hermes Agent rejoint par ailleurs la liste que notre panorama des agents de code en ligne de commande compare entre eux.

Installer Hermes Agent avec Docker

L’image officielle est nousresearch/hermes-agent. La documentation Docker décrit un assistant de configuration interactif puis un lancement en service :

mkdir -p ~/.hermes
docker run -it --rm -v ~/.hermes:/opt/data nousresearch/hermes-agent setup

docker run -d --name hermes --restart unless-stopped \
  -v ~/.hermes:/opt/data -p 8642:8642 \
  nousresearch/hermes-agent gateway run

Le labo plus bas ne reprend pas cet assistant interactif : il passe directement par un compose durci qui reproduit gateway run sur un réseau et des ports différents. Le port 8642 sert à la fois de point de santé et de passerelle compatible API OpenAI, le port 9119, optionnel, sert au tableau de bord web. Le volume monté sur /opt/data contient .env, config.yaml, SOUL.md, ainsi que les dossiers sessions/, memories/ et skills/. La documentation recommande 1 à 4 Go de mémoire et 1 à 2 cœurs selon l’usage.

J’ai épinglé la dernière version datée plutôt que latest. Les releases GitHub indiquent la v0.21.0 (tag v2026.8.31, « The Pantheon Release »), publiée le 31 août 2026, environ 5 800 commits et 760 contributeurs après la version précédente. Le tirage a pris 1 min 47 s sur cette machine pour 908 Mo compressés (3,93 Go une fois décompressés, architecture arm64). L’image v2026.4.30, 8,2 Go, situe une bascule d’architecture interne entre avril et mai 2026. Ce point de contrôle démarre encore sur tini, quand la version d’août utilise s6-overlay comme PID 1, avec abandon de privilèges vers un utilisateur hermes (UID 10000 par défaut). Curiosité notée en passant : le registre Docker Hub montre que le poids de l’image est passé d’environ 2,5 Go en avril à moins de 900 Mo depuis juillet 2026.

Durcir la configuration : réseau, ports, secrets

Le docker-compose.yml officiel déclare network_mode: host pour la passerelle comme pour le tableau de bord, pratique, mais sans aucune isolation réseau. Pour le labo, j’ai construit une version durcie : réseau dédié, ports publiés sur la boucle locale uniquement, secrets hors du fichier compose.

services:
  hermes:
    image: nousresearch/hermes-agent:v2026.8.31
    container_name: hermes-lab
    networks:
      - hermes_lab
    ports:
      - "127.0.0.1:8642:8642"
      - "127.0.0.1:9119:9119"
    volumes:
      - ./data:/opt/data
    env_file:
      - ./secrets/hermes.env     # cle de fournisseur eventuelle, hors du depot
    environment:
      - HERMES_UID=501
      - HERMES_GID=20
      - HERMES_DASHBOARD=1
      - HERMES_DASHBOARD_HOST=0.0.0.0
      - API_SERVER_HOST=0.0.0.0   # voir plus bas : sans cette ligne, /health
    deploy:                       #   reste injoignable meme port publie
      resources:
        limits:
          memory: 1g
          cpus: "1.0"
    command: ["gateway", "run"]

networks:
  hermes_lab:
    driver: bridge

Deux réglages du compose officiel se comportent autrement que ne le laisse attendre la documentation. Le premier tient au réseau. Marquer internal: true pour couper toute sortie Internet coupe aussi le port publié. Dans le labo, une requête lancée depuis l’intérieur du conteneur obtient un HTTP 200 sur /health. La même requête depuis la machine hôte, sur le port publié, ne reçoit aucune réponse. Une tentative de sortie vers example.com échoue sur une résolution DNS impossible. L’isolation tient donc, mais elle emporte avec elle l’usage local légitime du port. internal: true ne convient donc qu’à un labo entièrement hors ligne. Pour un usage réel avec un fournisseur de modèle distant, l’isolation passe par un réseau dédié classique et un pare-feu sortant, pas par ce réglage.

Le second surprend davantage. Même sur le réseau dédié non marqué internal, le port publié restait injoignable, connexion TCP acceptée, réponse HTTP vide. Une recherche dans le code installé donne l’explication exacte :

docker exec hermes-lab grep -r API_SERVER_HOST /opt/hermes/hermes_cli/security_audit_startup.py

host = extra.get("host") or os.environ.get("API_SERVER_HOST", "127.0.0.1")

Par défaut, la passerelle n’écoute que sur la boucle locale à l’intérieur du conteneur, indépendamment du réseau Docker choisi. D’où la ligne API_SERVER_HOST=0.0.0.0 dans le compose ci-dessus : elle ne change rien à l’exposition externe, puisque c’est le préfixe 127.0.0.1: du port publié qui la restreint déjà. Vérifié après correction : curl http://127.0.0.1:8642/health répond 200 depuis l’hôte, la même requête envoyée vers l’adresse réseau locale de la machine (192.168.x.x) ne reçoit aucune réponse. Quant au tableau de bord, il refuse carrément de démarrer sur une interface non locale sans fournisseur d’authentification configuré :

Refusing to bind dashboard to 0.0.0.0 — the auth gate engages on non-loopback
binds (0.0.0.0), but no auth providers are registered.
There is no unauthenticated public-dashboard option.

Comportement sain par défaut, avec un effet de bord visible dans les journaux. Laissé tel quel, sans authentification configurée, le service ne reste pas simplement désactivé, il échoue puis redémarre en boucle sous la supervision s6. Rien de grave, mais assez bruyant pour valoir la peine d’être su. Dernier point vérifié : la limite deploy.resources.limits du compose ci-dessus s’applique bel et bien hors mode Swarm avec Docker Compose v5.1.0. docker inspect confirme Memory=1073741824 et NanoCpus=1000000000 sur le conteneur lancé. D’anciennes versions de Compose ignoraient deploy: hors Swarm.

Ce qu’on observe au démarrage

Une fois la configuration corrigée, docker compose up -d puis un sondage de /health toutes les 0,3 seconde donnent un temps de démarrage d’environ 18,9 secondes à froid (dossier de données vide) et 16,6 secondes après un simple redémarrage. L’écart tient surtout à une phase de préchauffage interne, que les journaux nomment explicitement « turn-machinery warm-up » et qui ouvre la porte d’entrée après 20 secondes même si elle continue en arrière-plan. À l’intérieur, ps aux confirme que le superviseur reste root mais que le processus hermes gateway run tourne bien sous l’utilisateur non privilégié hermes. La bannière de démarrage affiche Hermes Agent v0.21.0 (2026.8.31), Python 3.13.5 et le SDK OpenAI 2.24.0.

Se connecter à un modèle

Le fichier .env généré au premier démarrage liste, entièrement en commentaires, une trentaine de fournisseurs (Fireworks, OpenRouter, NovitaAI, Gemini, z.ai, Kimi, MiniMax, OpenCode Zen…) et autant de clés d’outils (Firecrawl, Exa, Browserbase), aucune n’est active. « Ollama » n’y apparaît que sous la forme OLLAMA_API_KEY, le service cloud payant d’Ollama, et aucune entrée ne vise une instance locale. Le diagnostic intégré confirme l’état neutre de l’installation :

docker exec hermes-lab hermes doctor

✓ No active security advisories
✓ No suspicious MCP stdio commands
✓ Version files consistent (0.21.0)
◆ API Connectivity
  ⚠ OpenRouter API (not configured)
◆ Memory Provider
  ✓ Built-in memory active (no external provider configured — this is fine)

Seule valeur présente dans .env à l’issue du test : une API_SERVER_KEY générée automatiquement par le conteneur, pour protéger sa propre passerelle locale. Elle n’apparaît jamais en clair dans les journaux, n’a été saisie par personne, et n’a aucun rapport avec un compte chez un fournisseur de modèle.

Les compétences, et comment en vérifier une avant de l’installer

Les compétences (« skills ») vivent dans /opt/data/skills/ et suivent le standard ouvert Agent Skills détaillé dans notre guide du SKILL.md. hermes skills list comptait 53 compétences intégrées activées dans ce labo, aucune installée depuis le hub. L’installation se fait par registre : hermes skills install official/security/1password ou hermes skills install openai/skills/k8s, par exemple. Avant d’installer quoi que ce soit, deux commandes évitent d’avoir à faire confiance à l’aveugle :

hermes skills inspect openai/skills/k8s   # metadonnees, depot source, audit deja disponible
hermes skills audit                       # re-scanne toutes les skills installees depuis le hub

Le scanner intégré classe chaque résultat en trois niveaux : dangerous bloque l’installation, warn/caution se contourne avec --force, advisory reste informatif. D’après la documentation officielle, le hub agrégeait 90 700 compétences réparties sur 11 registres au 26 août 2026, à ne pas confondre avec « HermesHub », l’index communautaire tiers évoqué plus haut.

MCP : brancher des outils, ou exposer Hermes comme serveur

hermes mcp catalog, exécuté dans le labo, affiche un catalogue déjà long de serveurs prêts à l’emploi (Airtable, Atlassian, Cloudflare, ClickUp, Buildkite…). hermes mcp list confirmait qu’aucun n’était configuré, comme attendu sur une installation neuve. L’ajout se fait avec un préréglage connu ou une entrée manuelle :

hermes mcp add codex --preset codex
hermes mcp add filesystem --command npx --args "-y @modelcontextprotocol/server-filesystem /projet"

Dans l’autre sens, hermes mcp serve expose une session Hermes comme serveur MCP à un client externe, Claude Code, par exemple, en pointant sa configuration vers la commande hermes mcp serve. Côté sécurité, la documentation précise trois choses. Les jetons OAuth distants sont mis en cache avec des permissions 0600. Le renouvellement passe par PKCE. Pour les serveurs en stdio, seules les variables d’environnement explicitement déclarées, plus une base minimale, sont transmises au sous-processus. De quoi limiter les fuites de secrets vers un serveur MCP tiers mal audité, un risque déjà documenté dans notre article sur les agents de code, sandbox et permissions.

Hermes Agent contre OpenClaw : une comparaison honnête

Les deux projets sont open source, s’installent sous Docker et prennent en charge skills et MCP, c’est leur philosophie qui diverge. OpenClaw structure une passerelle qui route et surveille plusieurs agents, connecteurs et canaux. Hermes Agent mise sur un agent unique qui accumule ses propres compétences au fil de l’usage. Notre article sur l’installation durcie d’OpenClaw détaille le même exercice côté OpenClaw, les deux se lisent en miroir.

Sur la sécurité, une note de recherche de la Cloud Security Alliance datée du 4 mai 2026 recense, sur la même période, neuf CVE pour OpenClaw dont une critique notée 9,9, contre deux pour le cœur de Hermes Agent. CVE-2026-7396 porte sur une traversée de chemin dans l’adaptateur WeCom (CVSS 4,0), CVE-2026-7397 sur un suivi de lien symbolique dans les outils fichiers (CVSS 4,8), toutes deux sur la version 0.8.0 et corrigées dès la 0.9.0. Une troisième CVE listée touche non pas l’agent mais hermes-webui, le client tiers déjà signalé plus haut. La page GitHub Security Advisories du dépôt ne référence quant à elle aucun avis publié au 7 septembre 2026 : ces CVE ont été déposées par des canaux externes, pas par Nous Research elle-même. Aucun recensement d’instances Hermes exposées comparable au chiffre vérifié pour OpenClaw (42 900 instances, 93 % sans authentification, SecurityScorecard 2026) n’a été publié à ce jour, ce qui ne prouve pas leur absence.

Un incident daté illustre pourquoi le cloisonnement réseau et l’absence de mode automatique comptent autant que le choix du projet. The Hacker News a documenté, le 24 juillet 2026, un cas où un attaquant disposant déjà d’un accès initial au réseau du ministère des Finances thaïlandais a installé Hermes Agent sur un serveur loué, puis activé son mode « YOLO », qui saute les confirmations avant les commandes risquées. L’agent a ensuite exploré le réseau sans supervision, trouvé des services Hadoop en identifiants par défaut et déployé un implant. Point souligné par la source elle-même : Hermes n’a pas provoqué l’intrusion, il en a automatisé la phase suivante. Le réseau dédié, les ports en boucle locale et l’absence de clé saisie dans ce labo visent exactement à empêcher cette phase-là.

Ce qu’il faut retenir

• Le « Hermes Agent » comparé à OpenClaw en 2026 est celui de Nous Research (NousResearch/hermes-agent, licence MIT), pas hermes-webui ni « HermesHub », deux projets tiers au nom proche.
• Dernière version datée testée : v0.21.0 (tag v2026.8.31, 31 août 2026), installée via Docker en 1 min 47 s (908 Mo compressés, 3,93 Go décompressés).
• Un réseau marqué internal: true coupe aussi le port publié, pas seulement la sortie Internet. Par défaut, la passerelle n’écoute que sur sa propre boucle locale (API_SERVER_HOST=127.0.0.1), à corriger explicitement même derrière un port déjà restreint à 127.0.0.1 côté hôte.
• Le tableau de bord refuse de s’exposer hors boucle locale sans authentification configurée. Sain par défaut, mais laissé ainsi il boucle en échec au lieu de rester simplement inactif.
• Démarrage mesuré à environ 17 à 19 secondes jusqu’à un /health réellement positif, sans aucune clé ni identifiant saisi de bout en bout.
• Sur la même période, la Cloud Security Alliance recense deux CVE mineures pour le cœur de Hermes Agent contre neuf pour OpenClaw, dont une critique. L’écart se lit avec prudence : aucun recensement d’exposition équivalent n’a été publié pour Hermes.