Monte une organisation de 48 agents IA sur Hermes : orchestrateur, kanban de délégation, cron autonome et les pièges réels (s6, conflits, environnement minimal).
Un seul agent IA, c'est déjà puissant. Mais quand tu lui demandes une tâche complexe (faire une veille, produire un rapport, lancer une campagne), il fait tout lui-même, en série, et finit par s'essouffler sur les gros sujets.
L'étape d'après, c'est l'orchestration multi-agents : un chef d'orchestre qui décompose un objectif en tâches, les distribue à des spécialistes, et coordonne le tout. Dans ce guide, je te montre comment j'ai monté une véritable organisation de 48 agents sur Hermes, avec un orchestrateur, des sous-équipes (marketing, dev, sales, R&D) et un tableau kanban partagé qui pilote la délégation.
Tu vas comprendre le système de profils de Hermes, comment exposer un orchestrateur dans une interface de chat, comment fonctionne le kanban de délégation, et comment automatiser tout ça avec un cron. Avec les vrais pièges techniques que j'ai dû résoudre : la limite du superviseur s6, les conflits de bot, et l'environnement minimal qui casse la délégation.
Si tu n'as pas encore Hermes installé sur ton VPS, commence par mon article précédent sur le déploiement Docker. Ici, on construit par-dessus.
Un profil Hermes, c'est une instance isolée de l'agent, avec sa propre configuration : son modèle, ses outils, son authentification, sa personnalité, ses sessions. Pense à ça comme à des employés différents dans une entreprise : chacun a son rôle, ses compétences et son bureau, mais ils partagent les mêmes locaux.
Tu listes tes profils avec :
docker exec -it hermes-api hermes profile listDans mon installation, ça affiche 48 profils organisés en hiérarchie :
Chaque profil tourne sur un modèle adapté à son rôle : les rôles de coordination utilisent un modèle de raisonnement avancé (type Claude Sonnet), les rôles d'exécution un modèle plus rapide et léger.
Pour voir le détail d'un profil :
docker exec hermes-api hermes profile show orchestratorTu obtiens son chemin, son modèle, le nombre de skills, l'état de sa gateway et la présence d'un fichier SOUL.md.
Le SOUL.md d'un profil définit sa personnalité et son comportement. Pour l'orchestrateur, c'est le document le plus important du système : il contient la carte de toute l'organisation et les règles de routage.
Voici un extrait du SOUL.md de mon orchestrateur :
You are the Orchestrator of an AI agent organization. You turn a high-level
objective into an explicit plan: decompose it into tasks, assign each to the
best-fit specialist (match by their role description), sequence dependencies,
and run it on the kanban.
You insert human-approval gates before any action that is irreversible, costly,
externally visible, or touches production. You do NOT do specialists' work
yourself.Ce fichier précise plusieurs choses fondamentales :
Point clé : deux profils peuvent tourner sur le même modèle mais avoir des SOUL.md différents, donc des comportements radicalement différents. Le SOUL est ce qui transforme un LLM générique en spécialiste.
Le kanban Hermes, c'est un tableau de tâches partagé entre tous les profils, stocké dans une base SQLite (kanban.db). C'est le moteur de toute l'organisation.
Le principe : l'orchestrateur reçoit un objectif, le décompose en tâches, les pose sur le board, et chaque tâche est exécutée par le bon profil dans un workspace isolé. Les tâches peuvent dépendre les unes des autres, être réclamées atomiquement, et passer par des étapes (triage, todo, en cours, done).
Tu listes les tâches du board avec :
docker exec hermes-api hermes kanban listDans mon système, après plusieurs runs, le board affichait des dizaines de tâches terminées par les bons agents :
✓ done researcher Cartographier les concepts du wiki
✓ done critic Verify swarm outputs
✓ done wikicurator Synthesize swarm outputs
✓ done mkt-x-analyst Collecte une veille X sourcée sur l'IA
✓ done cto Brief Technologie (ops, dev, doc technique)C'est la preuve que la délégation fonctionne : un objectif unique (par exemple "produire un rapport exécutif") a mobilisé tous les C-levels, chacun produisant son brief.
Le kanban est unique et partagé entre tous les profils et tous les conteneurs. Que tu crées une tâche depuis n'importe quel profil, elle s'affiche toujours sur le même board. Ce qui change selon la configuration, c'est qui décompose et exécute la tâche, pas où elle s'affiche.
Dans les réglages d'orchestration (accessibles via le dashboard), tu définis :
Tu veux pouvoir parler à ton orchestrateur en langage naturel, pas seulement via le kanban. Pour ça, il faut lancer son serveur API et le brancher dans Open WebUI.
Première découverte importante : dans Hermes, tu ne peux pas faire tourner deux gateways dans le même conteneur. L'image utilise un superviseur s6-overlay qui l'interdit. Si tu tentes de lancer une seconde gateway, tu obtiens :
ERROR gateway.run: Another gateway instance (PID 1) started during our
startup. Exiting to avoid double-running.La solution propre : un conteneur séparé pour l'orchestrateur. Il partage le même /root/.hermes (donc les mêmes profils, le même kanban, la même auth), mais tourne en isolation sur le profil orchestrator.
#!/bin/sh
umask 0000
hermes profile use orchestrator
exec hermes gateway run --no-superviseNote bien le hermes profile use orchestrator. J'ai d'abord essayé de passer le profil via une variable d'environnement HERMES_PROFILE, mais elle est ignorée par Hermes. La seule méthode fiable pour cibler un profil, c'est hermes profile use.
services:
hermes-orchestrator:
build: .
container_name: hermes-orchestrator
restart: unless-stopped
expose:
- "8642"
environment:
- DOCKER_HOST=tcp://docker-socket-proxy:2375
volumes:
- /home/user/hermes-proxy/auth:/root/.hermes
- /home/user/hermes-proxy/vault:/root/vault
networks:
- n8nnet
networks:
n8nnet:
external: true
name: mon-reseau-dockerLe DOCKER_HOST pointe vers un docker-socket-proxy. C'est une bonne pratique de sécurité : au lieu de monter le socket Docker brut (qui donne un accès root à l'hôte), on passe par un proxy qui filtre les commandes autorisées. L'orchestrateur en a besoin pour créer les conteneurs sandbox de ses sous-agents.
Une fois le conteneur lancé, vérifie qu'il expose bien le bon profil :
docker exec hermes-orchestrator python -c "import urllib.request; r=urllib.request.Request('http://localhost:8642/v1/models', headers={'Authorization':'Bearer TA_CLE_API'}); print(urllib.request.urlopen(r).read().decode())"Tu dois voir "id": "orchestrator". Ensuite, tu l'ajoutes dans Open WebUI comme une nouvelle connexion (http://hermes-orchestrator:8642/v1), et il apparaît dans le menu.
Voici l'erreur qui m'a fait tourner en rond le plus longtemps. Mon conteneur orchestrateur répondait en chat, mais dès qu'il tentait de déléguer, tout échouait :
ERROR tools.terminal_tool: Docker executable not found in PATH
WARNING agent.tool_executor: Tool web_search returned error: Feature
'search.firecrawl' unavailableLa cause : j'avais construit le conteneur orchestrateur avec un Dockerfile minimal, alors que pour déléguer il a besoin du même environnement complet que le conteneur principal. Il lui manquait le binaire Docker (pour créer les sandbox) et certaines dépendances Python (pour la recherche web).
La leçon : un agent qui orchestre a besoin de toutes les capacités d'exécution. Aligne le Dockerfile de ton orchestrateur sur celui de ton conteneur principal, avec le binaire Docker statique et les dépendances complètes :
RUN curl -fsSL https://download.docker.com/linux/static/stable/x86_64/docker-27.3.1.tgz \
| tar -xz -C /usr/local/bin --strip-components=1 docker/docker
RUN pip install --no-cache-dir pipx && \
pipx install hermes-agent && \
pipx inject hermes-agent aiohttp fastapi uvicorn ptyprocess "mcp>=1.27" httpx-sse langfuseAprès ce correctif, la délégation s'est débloquée. Les tâches swarm: ont commencé à apparaître sur le kanban, exécutées par researcher, wikicurator, seo-analyst et les autres.
Le vrai pouvoir d'une armée d'agents, c'est qu'elle travaille sans toi. Hermes a un système de cron natif pour planifier des tâches récurrentes.
Crée un job de veille quotidienne :
docker exec hermes-orchestrator hermes cron create \
--name "veille-dev-web" \
--profile orchestrator \
--deliver local \
"0 7 * * *" \
"Tâche autonome, n'attends aucune validation, ne demande aucune clarification, exécute directement. Recherche web sur les nouveautés du dev web et de l'IA. Écris une page datée dans /root/vault/wiki/. Mets à jour index.md et log.md."Plusieurs détails comptent ici :
À mes premiers essais, l'orchestrateur créait des tâches "Clarify the task request" et restait bloqué. La raison : en mode cron autonome, il n'y a personne pour répondre à ses demandes de clarification. Son SOUL.md lui dit d'insérer des gates humains, donc il s'arrête en attendant une réponse qui ne vient jamais.
La solution : une consigne qui coupe court à toute hésitation. Les phrases "n'attends aucune validation, ne demande aucune clarification, exécute directement" évitent qu'il se bloque. Avec des étapes numérotées explicites et un chemin de fichier précis, il sait exactement quoi faire.
Vérifie que ton scheduler tourne :
docker exec hermes-orchestrator hermes cron statusTu dois voir ✓ Gateway is running — cron jobs will fire automatically.
Pour tester sans attendre l'heure programmée :
docker exec hermes-orchestrator hermes cron run veille-dev-webAprès quelques minutes, une page fraîche apparaît dans le vault. La chaîne complète a fonctionné : cron → orchestrateur → recherche web → synthèse → écriture dans le vault.
À l'usage, tu as deux façons de faire travailler ton orchestrateur, avec des compromis différents :
| Mode | Description | Avantage | Inconvénient |
|---|---|---|---|
| Solo | L'orchestrateur fait tout lui-même | Rapide, fiable | Pas de division du travail |
| Délégation | Il répartit aux spécialistes | Travail riche et structuré | Plus lent, plus coûteux en quota |
Pour une veille simple, le mode solo suffit et il est plus robuste. Pour un livrable complexe (rapport multi-domaines, campagne), la délégation aux spécialistes donne un résultat bien plus riche, mais consomme nettement plus.
Attention au coût : une seule demande à l'orchestrateur peut déclencher une cascade d'appels de modèle (l'orchestrateur, puis chaque sous-agent, puis le critic). Surveille ta consommation, surtout sur les profils utilisant un modèle de raisonnement avancé.
Quand plusieurs conteneurs partagent le même /root/.hermes, certaines ressources entrent en conflit. Le cas le plus courant : le bot de messagerie.
Si deux conteneurs lisent le même token de bot (Telegram par exemple), ils se disputent la même connexion et tu obtiens :
Conflict: terminated by other getUpdates request; make sure that only one
bot instance is runningC'est une limite de la plateforme de messagerie, pas de Hermes : un bot ne peut avoir qu'une seule connexion active. Deux solutions propres :
Comme chaque profil lit son propre fichier .env, tu peux donner un token différent au profil orchestrator sans toucher au profil par défaut. La modification est chirurgicale : une seule ligne dans le .env du profil concerné.
Bonne pratique : si tu travailles à plusieurs sur le même système, mets-toi d'accord sur qui gère quoi (le bot, les crons partagés, les configs de profil). Sur une architecture partagée, deux personnes qui modifient la même config se neutralisent vite.
Voici les étapes essentielles pour monter ton orchestration multi-agents :
| Action | Commande clé |
|---|---|
| Lister les profils | hermes profile list |
| Voir un profil | hermes profile show orchestrator |
| Voir le kanban | hermes kanban list |
| Cibler un profil | hermes profile use orchestrator |
| Créer un cron | hermes cron create --name ... --profile ... |
| Tester un cron | hermes cron run [nom] |
| Vérifier le scheduler | hermes cron status |
Et les leçons techniques à retenir :
Tu as maintenant une organisation d'agents IA qui décompose tes objectifs, délègue à des spécialistes, et travaille en autonomie sur un planning. C'est un changement d'échelle par rapport à un agent unique : tu ne donnes plus des tâches, tu donnes des objectifs, et l'organisation s'occupe du reste.
La prochaine étape logique ? Affiner les descriptions de chaque profil pour améliorer le routage de l'orchestrateur, et créer des boards kanban dédiés par projet. Mais ça, c'est pour un prochain article.
À toi de bâtir ton armée !