Hermes Agent orchestrateur : 7 problèmes concrets et leurs solutions

Les deux dernières semaines de mai, j'ai animé quatre sessions de formations IA pour des profils entrepreneurs à Ashiya. Des freelances, des fondateurs de startup, des consultants indépendants. Des gens curieux, motivés, qui cherchent des outils concrets pour travailler autrement.

Un sujet est revenu systématiquement : Hermes Agent. Pas parce que je leur en avais parlé, mais parce qu'ils l'avaient repéré eux-mêmes — sur GitHub, sur LinkedIn, dans des newsletters tech. 100 000 étoiles GitHub en deux mois, présenté partout comme "l'agent qui apprend et s'améliore tout seul". Forcément, ça intrigue.

La question qu'ils posaient tous, avec des variantes : "C'est vraiment aussi simple que ça en a l'air ?"

Je n'avais pas encore de réponse honnête à leur donner. J'avais déjà installé Hermes sur un VPS connecté à LINE — un usage basique d'intermédiaire de messagerie, qui fonctionnait bien pour ce que je lui demandais. Mais j'avais envie d'aller plus loin.

Du coup, j'ai décidé de pousser l'expérience sérieusement.

Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.

L'ambition : un orchestrateur de développement

L'idée était la suivante : positionner Hermes comme cerveau central de mon workflow de développement. Pas juste un chatbot ou un assistant de messagerie — un orchestrateur réel qui reçoit des tâches, les découpe, délègue à des workers spécialisés, et suit l'avancement. Pour le développement pur, j'avais prévu de coupler Hermes à des agents opencode — un outil d'IA dédié au code, capable de lire des contextes entiers, d'écrire des fichiers, de faire des PR.

Sur le papier, l'architecture ressemblait à ça :

Hermes (orchestrateur)
    │
    ├── Kanban board (gestion des tâches)
    │       ├── Tâche 1 → Worker opencode #1
    │       ├── Tâche 2 → Worker opencode #2
    │       └── Tâche N → Worker opencode #N
    │
    └── Mémoire persistante + auto-amélioration GEPA

En théorie, c'est exactement ce pour quoi Hermes a été conçu. En pratique, j'ai découvert un terrain miné.

Surprise n°1 : "Mais comment je lui parle ?"

Première réaction de beaucoup de nouveaux utilisateurs — y compris des gens techniquement compétents : "J'ai installé Hermes, maintenant comment je l'utilise ?"

On cherche une interface. Un dashboard. Une WebUI. On ne trouve rien d'officiel. Un projet communautaire existe (hermes-webui) mais il n'est pas nécessaire. La réponse est plus simple — et moins intuitive pour quelqu'un habitué aux outils modernes :

hermes chat

C'est tout. Hermes vit dans le terminal. Si vous ne passez pas vos journées dans un shell, les cinq premières minutes créent déjà de la friction. Pas de support Windows natif non plus — il faut passer par WSL2. C'est un choix architectural assumé par Nous Research, mais c'est un point d'entrée qui filtre naturellement une partie du public.

Surprise n°2 : l'agent qui fonce tête baissée

Une fois dans le terminal, on découvite un comportement qui revient régulièrement dans les retours de la communauté : Hermes démarre l'exécution sans phase d'analyse préalable.

Vous lui donnez une tâche complexe — "refactorise ce module en suivant le pattern CQRS" — et il commence à écrire du code immédiatement. Sans lister les fichiers impactés. Sans proposer une approche. Sans valider sa compréhension du contexte.

Ce comportement n'est pas un bug. C'est une absence de contrainte. La boucle de base de Hermes est optimisée pour l'action, pas pour la réflexion préalable. Pour le corriger, il faut modifier SOUL.md — le fichier d'identité de l'agent, injecté en tête du system prompt à chaque tour.

SOUL.md est l'endroit où vous définissez qui est votre agent, comment il communique, et surtout ce qu'il ne doit jamais faire. Une règle efficace ressemble à ça :

## Defaults
Avant toute action de développement, lister explicitement :
1. Les fichiers qui seront modifiés
2. L'approche proposée
3. Les risques identifiés
Ne jamais écrire de code avant validation de ces trois points.

La distinction importante : SOUL.md accueille le comportement durable de l'agent, tandis qu'AGENTS.md reçoit les règles spécifiques au projet (chemins, ports, commandes). Mélanger les deux crée de la confusion dès que vous changez de projet.

Surprise n°3 : le kanban qui ne se met pas à jour tout seul

Hermes intègre un kanban multi-agents — un board de tâches où chaque worker agent peut prendre, traiter et clore des tickets. En théorie, c'est la fondation d'une vraie orchestration de travail.

En pratique, j'ai constaté que l'agent n'alimente pas le kanban spontanément. Il faut le spécifier explicitement. Et le CLI du kanban n'est pas invoqué automatiquement — il faut le préciser dans les règles du profil :

hermes kanban        # Vue du board
hermes kanban list   # Liste les tâches en cours

Plus problématique : j'ai créé un lot de 10 tâches d'un coup dans le kanban. Résultat : Hermes les a toutes lancées simultanément. Mon PC a commencé à ramer sérieusement — CPU à fond, RAM saturée, appels API en avalanche.

La cause était dans la configuration par défaut :

kanban:
  max_in_progress_per_profile: null  # ← illimité
  auto_decompose: true
  auto_decompose_per_tick: 3         # ← 3 sous-tâches créées et lancées par tick

La valeur null pour max_in_progress_per_profile signifie "aucune limite". Avec auto_decompose_per_tick: 3, le dispatcher peut créer et démarrer trois sous-tâches à chaque cycle. Résultat : un lot de 10 tâches devient rapidement 30+ workers actifs en parallèle.

La correction :

kanban:
  max_in_progress_per_profile: 2
  auto_decompose_per_tick: 1
  task:
    max_runtime_seconds: 300   # filet de sécurité contre les workers bloqués

Surprise n°4 : opencode introuvable

Pour coupler Hermes à opencode, j'avais installé opencode normalement sur mon système. Hermes, lui, ne le trouvait pas. Erreur classique : command not found.

Le problème vient du fait que les sous-processus Hermes héritent d'un environnement minimal — le PATH de votre shell n'est pas transmis automatiquement. Tout ce qui n'est pas dans /usr/bin ou /usr/local/bin devient invisible.

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

terminal:
  env_passthrough:
    - PATH

Ce problème touche en réalité tout binaire non standard : git, bun, node, npm, des outils installés via nvm ou pyenv... Si votre workflow repose sur des outils installés dans votre HOME, vous rencontrerez ce problème.

Note v0.15.1 (mai 2026) : ce correctif a partiellement été intégré pour les environnements Docker — les binaires npx, npm, node sont désormais résolus contre /usr/local/bin dans les containers. Sur les installations natives, la configuration manuelle reste nécessaire.

Surprise n°5 : les workers qui disparaissent sans signer

Une fois le parallélisme maîtrisé, j'ai rencontré un problème plus subtil : des tâches qui restaient bloquées indéfiniment dans le kanban, sans avancer, sans message d'erreur clair.

Dans les logs, la cause : protocol_violation.

Ce que ça signifie concrètement : le worker agent a terminé son travail et a quitté proprement (exit code 0) — mais sans appeler kanban_complete ni kanban_block. Du point de vue du dispatcher, la tâche est toujours "en cours". Elle ne sera jamais marquée terminée. Et dans certains cas (issue #28712), le dispatcher peut même relancer le worker indéfiniment, créant une boucle silencieuse.

La cause principale : le modèle génère une réponse textuelle et quitte, au lieu d'utiliser la surface outil kanban. Cela arrive notamment quand le budget d'itérations est épuisé.

La solution est une règle à ajouter dans chaque profil worker :

Règle kanban obligatoire : toute session doit se terminer par un appel explicite
à kanban_complete ou kanban_block. Une fin sans cet appel est une violation
de protocole qui bloque les tâches en aval.

Surprise n°6 : la base de données qui se corrompt

Après plusieurs sessions intensives — création rapide de tâches, redémarrages forcés du gateway, workers crashés sous OOM — j'ai trouvé ce message dans les logs :

torn-extend detected on ~/.hermes/kanban.db

Le kanban utilisait SQLite. La base était corrompue. Et sqlite3 n'était pas disponible sur ma machine pour réparer directement.

Ce n'est pas un cas isolé. Les issues GitHub documentent plusieurs scénarios de corruption :
- Création de ~10 tâches en succession rapide
- Redémarrages fréquents du gateway via SIGTERM
- Accès concurrent de plusieurs gateways sur le même fichier
- Boucle de spawn-crash rapide (moins de 2 secondes par crash) qui corrompt le B-tree avant que le circuit-breaker n'ait le temps de se déclencher

La bonne pratique, que j'aurais dû mettre en place dès le départ :

# Sauvegarde horaire — à mettre dans votre crontab
0 * * * * cp ~/.hermes/kanban.db ~/.hermes/kanban.db.bak.$(date +%Y%m%d%H)

En cas de corruption avec sqlite3 disponible :

sqlite3 kanban.db '.dump' > /tmp/kanban_dump.sql
sqlite3 kanban.db.new < /tmp/kanban_dump.sql
mv kanban.db kanban.db.corrupt.bak
mv kanban.db.new kanban.db

Point d'attention : il existe une RFC ouverte (#23717) pour remplacer SQLite par un backend pluggable (PostgreSQL, MySQL). Dans une architecture multi-agents avec accès concurrent, SQLite atteint ses limites structurelles.

Surprise n°7 : vos données dans le mauvais profil

Hermes gère des profils — des environnements isolés, chacun avec sa propre mémoire, ses sessions et ses skills. J'avais configuré un profil dédié agent-svelte5-main pour mon projet principal. Mais dans les logs, ce message est apparu :

[HERMES_HOME fallback] HERMES_HOME is unset but active profile is 'agent-svelte5-main'.
Falling back to /home/mathieu/.hermes — not 'agent-svelte5-main'.

Ce qui se passe techniquement (issue #18594) : le CLI launcher définit HERMES_HOME pour lui-même en mode profil, mais les sous-processus qu'il spawne démarrent avec un environnement minimal. Ils ne voient pas HERMES_HOME. La fonction get_hermes_home() retourne silencieusement ~/.hermes — le profil par défaut.

En pratique : vos memories, sessions et données d'exécution s'écrivent dans le mauvais profil. Un incident documenté (1er mai 2026) montre un cron job qui a contaminé le profil par défaut avec des données appartenant à un profil utilisateur nommé.

Workaround en attendant le fix :

export HERMES_HOME=~/.hermes/profiles/agent-svelte5-main
hermes ...

La consommation de tokens : l'addition invisible

Un dernier point sur lequel la communauté met régulièrement en garde. Hermes consomme des tokens à un rythme qui peut surprendre si on ne surveille pas.

Une analyse de l'issue #4379 révèle que ~73% de chaque appel LLM est du surcoût fixe — avant que l'agent ait fait quoi que ce soit :

Les gateways de messagerie (Telegram, Discord, LINE) ajoutent un surcoût de 15-20K tokens par requête — deux à trois fois plus que le mode CLI. Un cas documenté dans la communauté : 4 millions de tokens consommés en deux heures sur un debug Telegram mal configuré.

Hermes intègre un système de compression en deux couches (50% et 85% du context window), mais configurer un plafond explicite reste prudent :

context:
  max_tokens: 32000

Ce que j'aurais aimé savoir avant

Hermes est un outil sérieux, techniquement ambitieux, avec une communauté active qui pousse 200+ PR par semaine. Ce n'est pas du vaporware. La boucle d'auto-amélioration GEPA fonctionne réellement — les agents avec 20+ skills auto-générés complètent les tâches similaires 40% plus vite que les instances fraîches.

Mais c'est aussi un outil jeune (v0.15 au moment où j'écris), avec des angles morts qui peuvent coûter cher en temps et en ressources si on ne les connaît pas à l'avance.

Pour résumer les points de vigilance :

Est-ce que je recommande Hermes pour des entrepreneurs non techniques qui veulent un "agent qui tourne tout seul" ? Honnêtement, pas encore. Il faut être à l'aise avec un terminal, comprendre les fichiers de configuration YAML, et accepter de débugguer des comportements inattendus.

Pour des développeurs ou des profils techniques qui veulent construire une vraie infrastructure d'agents autonomes ? Oui — avec les précautions ci-dessus, c'est une fondation solide.

Et pour mes formations, j'ai maintenant une réponse honnête à la question que mes participants me posaient : "C'est puissant, mais ce n'est pas simple. Voici exactement pourquoi."

Qui suis je ?

Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.

J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.

Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.

L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.

La technologie, les méthodes, le management sont le cœur de mes compétences.

Vous pouvez me faire confiance sur ces points là.

Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr

Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100% IA.