Je ne vais pas mentir, j’adore l’agent Hermes de Nous Research, mais passer mes journées sur le terminal brut pour gérer un agent autonome, ça va un moment. J’avais besoin d’une vraie interface visuelle pour suivre ses réflexions, gérer sa mémoire et garder un œil sur ce qu’il fabrique en local sur ma machine.
Après avoir testé à peu près toutes les configurations possibles ces dernières semaines — du dashboard officiel aux intégrations Docker plus poussées —, voici un retour complet sur ce qui fonctionne, comment tout configurer sans se prendre la tête, et comment régler les inévitables conflits de ports.
Le Dashboard Officiel (L’outil d’administration)
Si vous voulez juste configurer l’agent et surveiller ses tâches de fond, le dashboard natif fait parfaitement le travail. Pour le lancer, c’est super simple. On ouvre le terminal et on tape :
hermes
# Puis dans une autre fenêtre :
hermes dashboardÇa ouvre directement un panneau d’administration local dans le navigateur (par défaut sur le port 9119).
Ce que j’en pense : C’est parfait pour la gestion globale. Il y a plus de 150 paramètres de configuration sous forme de formulaires clairs, une gestion centralisée des clés API, les logs des sessions et même un planificateur de cron-jobs. C’est idéal pour régler les rouages internes de l’agent, mais pour discuter de manière fluide, l’interface de chat (qui passe par un terminal embarqué) reste un peu basique à mon goût.
Le setup ultime : Connecter Open WebUI (Style ChatGPT)
Pour avoir une vraie expérience de chat multi-tours tout en laissant l’agent exécuter des scripts et manipuler des fichiers en arrière-plan, c’est l’intégration avec Open WebUI qu’il faut viser. (C’est de loin ma configuration préférée).
Voici comment j’ai relié les deux en local :
Étape A : Activer la passerelle API d’Hermes
Il faut forcer Hermes à se comporter comme un serveur d’API OpenAI. Dans le terminal :
# 1. On active le serveur API interne
hermes config set API_SERVER_ENABLED true
# 2. On définit une clé de sécurité locale
hermes config set API_SERVER_KEY ma-cle-securisee-locale
# 3. On lance la passerelle (elle écoute sur le port 8642 par défaut)
hermes gateway(Vérifiez bien que le terminal affiche bien une ligne du style [API Server] API server listening on http://127.0.0.1:8642 avant de continuer).
Étape B : Lancer Open WebUI via Docker
C’est souvent là que les gens se perdent avec le réseau Docker. Pour que le conteneur puisse discuter avec l’agent qui tourne directement sur votre système hôte, il faut utiliser ce script précis :
docker run -d -p 3000:8080 \
-e OPENAI_API_BASE_URL=http://host.docker.internal:8642/v1 \
-e OPENAI_API_KEY=ma-cle-securisee-locale \
-e ENABLE_OLLAMA_API=false \
--add-host=host.docker.internal:host-gateway \
-v open-webui:/app/backend/data \
--name open-webui \
--restart always \
ghcr.io/open-webui/open-webui:mainNote : Désactiver l’API Ollama interne d’Open WebUI (ENABLE_OLLAMA_API=false) évite de polluer l’interface. On veut qu’elle se concentre uniquement sur le contrôleur Hermes.
Ensuite, rendez-vous sur http://localhost:3000, créez votre compte local, et sélectionnez le modèle hermes-agent dans le menu déroulant en haut. Ce qui est bluffant, c’est que l’on voit l’exécution des outils de l’agent s’afficher en temps réel directement dans les bulles de discussion pendant qu’il travaille.
Les alternatives de la communauté (et l’application Desktop)
Si Docker vous donne des boutons, il y a d’autres options très cool développées par la communauté :
- Hermes WebUI (par nesquena) : Une interface ultra légère en trois colonnes, codée en pur JavaScript et Python. Pas de Webpack ou de package manager lourd. C’est parfait si vous voulez suivre précisément la consommation de tokens et inspecter les fichiers du workspace en direct.
- Hermes HUD (par joeynyc) : Conçu comme un “moniteur de conscience”. C’est une interface de tracking très visuelle qui montre les différentes branches d’exécution et les outils que l’agent décide d’appeler en tâche de fond.
- L’application Desktop Native : Si vous voulez zapper les configurations réseau et Docker, l’équipe propose une application de bureau classique (macOS, Windows, Linux). Elle embarque le moteur Web UI et se connecte automatiquement à votre configuration locale existante (dans
~/.hermes).
Faire tourner le tout 100% en local avec Ollama (Zéro coût, vie privée garantie)
Pour éviter de payer des API cloud, j’ai tout basculé sur Ollama en local. Hermes 3 a besoin d’un excellent support du “function calling” pour contrôler votre machine, et les versions officielles d’Hermes 3 sur Ollama gèrent ça à merveille.
- Installer Ollama via leur site officiel (ou un simple
curl -fsSL https://ollama.com | shsur macOS/Linux). - Télécharger le modèle adapté à votre config. Pour ma part, n’ayant pas un monstre de guerre, j’utilise la version 8B :
bash ollama run hermes3:8b
(Si vous avez un Mac Studio costaud ou une grosse carte GPU, la versionhermes3:70best évidemment incroyable). Une fois le téléchargement fini, faites/exit. - Pointer Hermes vers Ollama :
bash hermes config set LLM_API_BASE_URL http://localhost:11434/v1 hermes config set LLM_MODEL_NAME hermes3:8b hermes config set LLM_API_KEY "ollama"
Pour tester si la boucle autonome fonctionne, lancez l’agent avec hermes et demandez-lui simplement : “Crée un dossier nommé ‘hermes-test’ dans mon répertoire actuel, mets un fichier texte vide dedans, et liste le contenu pour vérifier.” Vous allez voir l’agent générer l’appel d’outil, créer physiquement le dossier sur votre disque dur et vous confirmer le résultat. C’est assez magique.
Guide de survie des conflits de ports
On finit par le sujet qui fâche : les erreurs de type “Port already in use”.
Pour rappel, Hermes utilise deux ports par défaut :
- Port 9119 : Le Dashboard d’administration.
- Port 8642 : Le serveur API gateway.
Option A : Tuer le processus fantôme
Il arrive souvent qu’une instance précédente d’Hermes tourne encore en tâche de fond.
- Sur macOS / Linux :
bash # On cherche le PID qui bloque le port 8642 (ou 9119) lsof -i :8642 # On le tue proprement (remplacez <PID> par le numéro trouvé) kill -9 <PID_NUMBER> - Sur Windows (PowerShell) :
powershell netstat -ano | findstr :8642 taskkill /F /PID <PID_NUMBER>
Option B : Changer les ports par défaut
Si un autre outil de votre système a absolument besoin de ces ports, ne forcez pas. Modifiez simplement la configuration d’Hermes :
# On déplace l'API gateway sur le port 8888
hermes config set API_SERVER_PORT 8888
hermes gateway
# Et pour le dashboard, on peut forcer un port au lancement
hermes dashboard --port 9999(Si vous changez le port de l’API pour 8888, n’oubliez pas d’ajuster l’adresse dans votre configuration Docker d’Open WebUI : http://host.docker.internal:8888/v1).
Bref, une fois qu’on a compris comment s’articulent la passerelle API et l’interface, on se retrouve avec un copilote local d’une efficacité redoutable, sans qu’aucune donnée ne sorte de notre machine. Si vous bloquez sur une étape de la configuration Docker ou sur les appels d’outils, n’hésitez pas à demander !