Installation et configuration de Hermes Agent Desktop

Vous voulez tester un agent IA open source sur les postes de votre équipe, mais vous ne savez pas si l'installation va déclencher une demi-journée de configuration et trois tickets de support. Hermes Agent Desktop, l'application de bureau de l'agent IA open source Hermes Agent édité par Nous Research, a justement été pensée pour limiter cette friction : un installateur récupère seul ses dépendances, et l'application partage la même configuration, les mêmes sessions et la même mémoire que la ligne de commande.

Ce tutoriel vous accompagne pas à pas, de l'installation sur macOS, Windows ou Linux jusqu'à la première conversation vérifiée, en passant par le choix entre un mode local (tout sur le poste) et un mode distant (un serveur partagé pour l'équipe). Comme c'est aussi une décision d'équipe, chaque étape garde un volet pour un tech lead : ce que l'agent apporte, ce qu'il faut prévoir avant de l'adopter, et qui gère les clés d'API.

Un avertissement avant de commencer : Hermes Agent évolue vite. Les versions et les noms de commandes cités ici (Python 3.11, Node.js v22, hermes desktop) sont ceux documentés par l'éditeur au moment de la rédaction. Avant un déploiement réel, revérifiez-les contre la documentation officielle, dont les liens sont rassemblés en fin d'article.

Prérequis : ce que vous devez avoir, ce que l'installateur gère

La bonne nouvelle pour un tech lead qui craint une longue liste de dépendances : sur les plateformes hors Windows (macOS, Linux), le seul prérequis strict est Git. L'installateur se charge ensuite de récupérer Python 3.11 (via uv), Node.js v22, ripgrep et ffmpeg. Vos développeurs n'ont donc pas à installer ces runtimes à la main, ce qui réduit nettement l'effort réel d'adoption.

Vérifiez d'abord que Git est présent :

git --version

Hermes Agent tourne sur macOS, Windows et Linux (WSL2 est supporté). Sur Linux, l'installateur a besoin de curl et de xz-utils, et l'application de bureau réclame en plus un compilateur C++. Sur Debian ou Ubuntu, ces deux dépendances s'installent ainsi :

sudo apt install curl xz-utils
sudo apt install build-essential

Côté équipe, deux questions méritent d'être tranchées avant la première installation. La première : l'agent tournera-t-il en local sur chaque poste, ou en mode distant sur un serveur partagé ? La seconde : quel fournisseur d'inférence, et qui en détient les clés ? Hermes Agent sait se connecter à plusieurs types de fournisseurs : un abonnement Nous Portal (configuration quasi nulle via OAuth), un endpoint compatible OpenAI (VLLM, SGLang, Ollama), une application locale comme LM Studio, ou des fournisseurs hébergés tiers. Choisir ce point en amont évite que chaque développeur improvise sa propre configuration de clés. Si vous outillez votre équipe autour de l'IA et des agents, c'est exactement le genre d'arbitrage qu'il vaut mieux poser une fois pour toutes.

Étape 1 : installer Hermes Agent

Deux chemins mènent à une installation fonctionnelle, selon le système et le contexte. Sur macOS et Windows, le plus direct reste l'installateur de bureau téléchargé depuis le site officiel : il installe à la fois la ligne de commande et l'application desktop. La documentation l'indique sans détour : téléchargez l'installateur Hermes Desktop depuis le site et exécutez-le.

Si vous préférez la ligne de commande, ou si vous installez sur Linux, WSL2 ou un serveur, un script unique fait le travail. Sur Linux, macOS et WSL2 :

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

Sur un serveur sans navigateur, une installation non interactive est documentée : il suffit de suffixer le script pour qu'il n'ouvre pas de navigateur.

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash -s -- --skip-browser

Sur Windows, en PowerShell, la commande équivalente est :

iex (irm https://hermes-agent.nousresearch.com/install.ps1)

Bon à savoir pour situer ce qui est posé sur le poste : le code utilisateur atterrit dans ~/.hermes/hermes-agent/, le binaire est un lien symbolique dans ~/.local/bin/hermes, et le répertoire de données vit dans ~/.hermes/. La variable $HERMES_HOME permet de surcharger cet emplacement, ce qui est utile si vous standardisez les chemins sur tous les postes de l'équipe.

Étape 2 : lancer l'application de bureau et vérifier l'installation

Le script vient de modifier votre PATH, mais le shell courant ne le sait pas encore. Rechargez-le, puis lancez la commande pour confirmer qu'elle répond :

source ~/.bashrc   # or: source ~/.zshrc
hermes

Si le terminal renvoie hermes: command not found, c'est presque toujours une affaire de PATH : le binaire se trouve sous ~/.local/bin/hermes. Rechargez le shell ou ajoutez ce dossier au PATH selon les options décrites dans la documentation d'installation.

Pour ouvrir l'application de bureau depuis la ligne de commande :

hermes desktop

Au premier lancement, l'application peut installer son runtime dans HERMES_HOME (~/.hermes, ou %LOCALAPPDATA%\hermes sur Windows), avec la même organisation de fichiers qu'une installation en ligne de commande. C'est normal : c'est ce qui permet à l'application de bureau et au terminal de partager exactement la même configuration. Si vous voulez fixer le répertoire de travail de l'agent, l'option --cwd est faite pour ça :

hermes desktop --cwd <path>

En cas de doute sur l'état de l'installation, deux commandes de diagnostic donnent une lecture rapide :

hermes doctor
hermes config check

Étape 3 : configurer le fournisseur d'inférence et le modèle

Au tout premier démarrage, l'application déroule un onboarding sur une interface unifiée. Vous y choisissez un fournisseur d'inférence et un modèle. Si vous voulez d'abord explorer l'application, l'option Choose provider later diffère ce choix et vous laisse entrer tout de suite.

La gestion fine des comptes et des clés se fait dans le panneau Providers des réglages : une interface dédiée où chaque fournisseur a son écran de connexion (comptes ou clés d'API) et où les identifiants sont stockés par fournisseur. C'est là qu'un tech lead voit l'intérêt de la gouvernance des clés : chaque fournisseur a son emplacement clair, plutôt qu'une clé éparpillée dans des variables d'environnement éparses. Le panneau expose tous les modèles que la commande hermes model connaît, sans présélection.

Tout cela a un équivalent en ligne de commande, pratique pour scripter une configuration reproductible sur plusieurs postes. Pour choisir un fournisseur et un modèle, ou lancer un assistant de configuration :

hermes model
hermes setup --portal
hermes setup

Pour renseigner une clé d'API ou fixer un modèle par défaut, la commande hermes config set écrit directement dans la configuration :

hermes config set OPENROUTER_API_KEY your_key
hermes config set model anthropic/claude-opus-4.6

Sous le capot, la configuration vit dans ~/.hermes/config.yaml et les secrets dans ~/.hermes/.env. Si vous voulez brancher un modèle local sans dépendre d'un fournisseur hébergé, passez par le fournisseur OpenAI-Compatible et renseignez l'URL de votre endpoint (par exemple un serveur Ollama ou llama.cpp exposant une API compatible OpenAI) ainsi que sa clé dans le panneau Providers. La documentation ne détaille pas de champ pas à pas pour Ollama dans l'interface graphique : on reste sur le fournisseur OpenAI-Compatible, sans inventer de réglage non documenté.

Étape 4 : choisir entre mode local et mode distant

C'est le point de décision le plus structurant, et il mérite qu'on s'y arrête. Par défaut, l'application démarre et gère son propre backend local : tout vit sur le poste, c'est le plus simple à mettre en route et c'est ce que vous voulez pour un développeur isolé qui teste l'outil. À l'autre bout, le mode distant connecte plusieurs applications de bureau à une seule instance Hermes hébergée sur un serveur partagé, ce qui mutualise le backend, les sessions et la gouvernance des clés. Le schéma ci-dessous résume les deux topologies avant de passer à la configuration du mode distant.

Pour un tech lead, la question se résume ainsi : mutualisez sur un serveur partagé dès que plusieurs personnes veulent partager le même backend et les mêmes sessions, ou pour centraliser la gouvernance des clés. Tant que chacun travaille de son côté, le mode local par poste suffit largement. Mettre en place le mode distant suppose un peu d'infrastructure : un serveur joignable, une authentification, et de quoi le maintenir dans la durée.

Côté serveur, préparez d'abord les identifiants du dashboard dans le fichier ~/.hermes/.env. Le secret de signature stable évite d'être déconnecté à chaque redémarrage du serveur :

cat >> ~/.hermes/.env <<'EOF'
HERMES_DASHBOARD_BASIC_AUTH_USERNAME=admin
HERMES_DASHBOARD_BASIC_AUTH_PASSWORD=choose-a-strong-password
# Recommended: a stable signing secret so sessions survive restarts.
HERMES_DASHBOARD_BASIC_AUTH_SECRET=$(openssl rand -base64 32)
EOF
chmod 600 ~/.hermes/.env

Démarrez ensuite le dashboard. Le fait de l'exposer sur une adresse non locale (0.0.0.0) active la barrière d'authentification, et le couple identifiant / mot de passe gère la connexion :

hermes dashboard --no-open --host 0.0.0.0 --port 9119

Côté application enfin, allez dans Settings > Gateway > Remote gateway. Renseignez l'URL distante au format http://<backend-host>:9119, connectez-vous via le formulaire identifiant / mot de passe (ou le bouton OAuth selon votre configuration), puis validez avec Save and reconnect. Si vous préférez fixer l'URL avant même de lancer l'application, la variable d'environnement HERMES_DESKTOP_REMOTE_URL fait le même travail.

Étape 5 : tester l'agent et confirmer que tout fonctionne

L'installation n'est pas finie tant que vous n'avez pas vu l'agent répondre. Lancez une première conversation dans le chat de l'application. En ligne de commande, deux interfaces existent : la commande seule pour le mode classique, ou le drapeau --tui pour l'interface terminal moderne, que la documentation recommande.

hermes
hermes --tui

Le conseil de la documentation est d'employer une consigne spécifique et facile à vérifier pour ce premier test, par exemple résumer un dépôt ou analyser un répertoire. Vous voyez immédiatement si l'agent fait ce qu'on attend de lui.

Si vous êtes en mode distant, vérifiez l'état du backend en interrogeant son endpoint de statut. La réponse vous dit notamment si l'authentification est requise et quels fournisseurs d'auth sont actifs :

curl -s http://<host>:9119/api/status | jq '.auth_required, .auth_providers'

Quand un démarrage échoue, les logs sont votre meilleur point d'entrée. L'application de bureau écrit dans HERMES_HOME/logs/desktop.log, et vous pouvez suivre ce flux en direct depuis la ligne de commande :

hermes logs gui -f

Deux commandes complètent le diagnostic : l'une pour un bilan général de l'installation, l'autre pour l'état de la gateway en mode distant.

hermes doctor
hermes gateway status

Si le premier lancement s'est mal passé et que vous voulez repartir propre, vous pouvez forcer un onboarding neuf, voire reconstruire l'environnement Python si le venv est cassé. Sur macOS et Linux :

rm "$HOME/.hermes/hermes-agent/.hermes-bootstrap-complete"
rm -rf "$HOME/.hermes/hermes-agent/venv"

Pour aller plus loin : usages en équipe et automatisation

Une fois l'installation validée, l'intérêt d'Hermes Agent se révèle surtout dans la durée. La configuration, les sessions et la mémoire étant partagées entre la ligne de commande, l'interface terminal et l'application de bureau (le même HERMES_HOME), vous reprenez une conversation là où vous l'aviez laissée, quelle que soit l'interface. La commande hermes sessions list liste les sessions, et le drapeau --continue reprend la dernière.

hermes sessions list
hermes --continue

L'agent peut aussi explorer et installer des skills (avec un scan de sécurité avant installation), se brancher à des serveurs MCP déclarés dans ~/.hermes/config.yaml, ou se connecter à une messagerie via une gateway. C'est ce socle qui ouvre la porte aux usages d'équipe : tâches planifiées, intégrations, partage de connaissances entre développeurs.

hermes skills browse
hermes gateway setup

Pour aller plus loin

• Hermes Agent : la techno open source que ce tutoriel couvre, ses usages et son intégration.
• Toutes nos technos : l'écosystème complet d'outils et frameworks que nous maîtrisons.
• Automatisation et IA : agents, process automatisés, IA générative au service de vos équipes.
• CTO on-demand : pilotage technique partagé, gouvernance des outils et des accès.
• Notre méthode : comment nous accompagnons nos clients de la décision jusqu'à la mise en production.

C'est précisément le terrain sur lequel notre équipe accompagne ses clients. Mettre un agent IA entre les mains d'une équipe, ce n'est pas que l'installer : c'est cadrer les cas d'usage, gouverner les clés et les accès, choisir entre local et serveur partagé, et intégrer l'outil dans une chaîne existante. Si vous voulez avancer sur l'automatisation et les agents IA avec un cadrage sérieux plutôt qu'à l'aveugle, l'accompagnement de Koul sur ces sujets part toujours d'un audit et d'une étude de cadrage, pour décider en connaissance de cause avant de déployer sur tous les postes.

Sources officielles

La documentation et le code source de Hermes Agent, à revérifier avant tout déploiement car l'outil évolue rapidement :

• Documentation officielle, guide d'installation (Nous Research)
• Documentation officielle, application de bureau (Nous Research)
• Documentation officielle, premiers pas (Nous Research)
• Dépôt GitHub officiel de Hermes Agent (licence MIT)