Installer Hermes Agent sur un VPS : guide complet

Installer Hermes Agent sur un VPS prend vingt minutes : une commande d'installation, une clé API de modèle, une passerelle de messagerie. Le durcissement, lui, prend une demi-journée de plus — et c'est l'étape que la plupart des tutoriels omettent alors qu'elle est la seule qui sépare un jouet d'un outil professionnel.

Ce guide couvre l'ensemble : dimensionnement, installation, sécurisation, passerelle d'équipe et exploitation. Il suppose un minimum d'aisance avec un terminal Linux. Pour les commandes et clés de configuration exactes, référez-vous toujours à la documentation officielle du projet, qui évolue vite.

Prérequis et dimensionnement du serveur

Bonne nouvelle : Hermes Agent est léger tant que le modèle de langage tourne ailleurs. L'agent orchestre, il ne calcule pas.

Usage	CPU / RAM	Disque	Coût mensuel indicatif
Individuel	2 vCPU / 4 Go	40 Go	5 à 12 €
Équipe de 5 à 15	4 vCPU / 8 Go	80 Go	20 à 40 €
Modèle exécuté en local	GPU dédié	200 Go et plus	300 € et plus

Trois recommandations avant de commander la machine :

• Un hébergeur européen. Cela ne coûte pas plus cher et simplifie considérablement le volet réglementaire, comme détaillé dans notre article sur la sécurité et le RGPD de Hermes Agent.
• Une distribution Linux à support long. Vous n'avez aucune envie de gérer une migration de système en plus des montées de version de l'agent.
• Des sauvegardes automatiques activées dès le départ. Le répertoire de données devient un actif en quelques semaines.

Côté accès, prévoyez une connexion administrateur par clé uniquement, sans mot de passe, et restreinte par adresse IP si votre situation le permet.

L'installation en trois étapes

Étape 1 — Installer le runtime

Le projet fournit un script d'installation officiel, valable sur Linux, macOS et WSL :

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

Avant de l'exécuter, prenez trente secondes pour deux réflexes de bon sens : téléchargez le script et lisez-le avant de le passer au shell, et créez un utilisateur système dédié à l'agent plutôt que d'installer sous le compte administrateur. Un agent qui tourne sous un compte à privilèges est un incident en puissance.

Étape 2 — Connecter un modèle

Le runtime propose un assistant de configuration pour choisir le fournisseur et renseigner la clé API. Les options couvrent Nous Portal, les passerelles multi-fournisseurs, les grandes API du marché et tout endpoint compatible avec le protocole OpenAI, ce qui inclut les modèles que vous exécutez vous-même.

Pour démarrer, une passerelle multi-fournisseurs est le choix le plus souple : une seule clé, de nombreux modèles, un changement possible en une ligne. Prenez un modèle de milieu de gamme comme référence, mesurez la qualité sur vos cas réels pendant deux semaines, puis ajustez. La documentation d'intégration d'OpenRouter décrit la marche à suivre pour ce type de configuration.

Posez immédiatement un plafond de dépense mensuel avec alerte chez le fournisseur. Avant le premier utilisateur, pas après la première facture.

Étape 3 — Choisir les outils accessibles

C'est l'étape la plus importante, et la plus expédiée. Chaque outil activé élargit ce que l'agent peut faire — et ce qu'un contenu malveillant peut lui faire faire.

Démarrez avec le minimum : lecture de fichiers dans un répertoire dédié, recherche web, et rien d'autre. L'exécution de code, l'écriture, l'envoi d'emails et les connexions métier s'ajoutent ensuite, une par une, quand un cas d'usage réel les justifie.

Durcir l'installation avant d'ouvrir à l'équipe

Un agent joignable par plusieurs personnes n'a plus rien d'une installation personnelle. Voici l'ordre dans lequel nous procédons.

Isoler l'exécution du code

Le code généré par l'agent ne doit jamais s'exécuter directement sur l'hôte. Activez un backend d'exécution conteneurisé : c'est la mesure au meilleur rapport effort/protection, et plusieurs des vulnérabilités publiées sur le projet portaient précisément sur cette brique.

Restreindre l'écriture

L'agent doit disposer d'une racine d'écriture explicite — un répertoire dédié, hors des chemins système. Le projet expose une variable d'environnement pour cela (HERMES_WRITE_SAFE_ROOT). Sans cette restriction, un enchaînement malheureux peut atteindre des fichiers de configuration.

Protéger les secrets

Les clés API vivent dans un fichier d'environnement en permissions restreintes, lisible par le seul utilisateur de l'agent. Utilisez des clés dédiées à l'agent, à portée minimale, et prévoyez une rotation. Jamais une clé partagée avec vos applications de production.

Fermer par défaut les accès utilisateurs

Sur les passerelles de messagerie, configurez des listes blanches d'utilisateurs et de canaux, avec refus par défaut. Ajoutez un quota de messages par utilisateur et par heure : cela protège le budget et limite les tentatives répétées d'injection d'instructions.

Journaliser

Activez la journalisation complète des actions et des outils appelés, et conservez ces journaux hors du répertoire de travail de l'agent. Sans eux, un incident est indémontrable.

Brancher une passerelle de messagerie

C'est ce qui transforme une installation technique en outil d'équipe. L'agent devient joignable là où les gens travaillent déjà : Slack, Telegram, Discord, WhatsApp, Signal.

Le point technique important : ces passerelles fonctionnent en connexion sortante. L'agent se connecte au service, pas l'inverse. Concrètement, cela signifie pas d'URL publique, pas de reverse proxy, pas de certificat, pas de port entrant. Votre pare-feu peut rester fermé.

Pour un usage professionnel, Slack est généralement le meilleur choix : l'outil est déjà en place, les canaux structurent naturellement les périmètres, et la configuration accepte plusieurs espaces de travail depuis une même passerelle. Trois réglages à ne pas oublier :

• Liste blanche de canaux : l'agent ne répond que là où vous l'avez décidé.
• Liste blanche d'utilisateurs : un canal ouvert ne doit pas donner accès à tout le monde.
• Quota par personne : la protection la plus simple contre les dérives d'usage et de coût.

Exploiter au quotidien

Une fois en service, quatre routines suffisent à garder l'installation saine.

Sauvegarder le répertoire de données. Mémoires, skills et historiques vivent dans ~/.hermes/. Une sauvegarde quotidienne chiffrée, testée au moins une fois, protège plusieurs mois de contexte métier accumulé.

Suivre la consommation. Un coup d'œil hebdomadaire au tableau de bord du fournisseur. Une hausse inexpliquée signale presque toujours une tâche planifiée qui s'emballe.

Auditer les tâches planifiées. Une fois par mois. C'est la première source de dépense invisible, comme détaillé dans notre analyse du coût réel de Hermes Agent.

Gérer les versions. Le projet publie fréquemment. Épinglez une version connue, testez les montées sur une instance séparée, appliquez les correctifs de sécurité sans attendre, et suivez les avis publiés sur le dépôt officiel.

Les erreurs les plus fréquentes

Installer sous le compte administrateur. Le raccourci du premier soir, celui qu'on ne corrige jamais. Créez un utilisateur dédié dès le départ, c'est deux minutes.

Activer tous les outils d'emblée. « Pour voir ce que ça donne ». Ce que ça donne, c'est un agent dont personne ne sait ce qu'il peut atteindre.

Ouvrir la passerelle sans liste blanche. Sur un espace de travail Slack, cela revient à donner l'agent à toute personne pouvant écrire dans un canal.

Oublier le plafond de dépense. Il se pose en trente secondes, avant le premier utilisateur.

Ne pas sauvegarder. Le jour où le VPS tombe, vous perdez la mémoire accumulée, c'est-à-dire précisément ce qui rendait l'agent utile.

Questions fréquentes

Peut-on installer Hermes Agent sur un poste Windows ?

Oui, un script d'installation PowerShell existe, et WSL fonctionne également. Pour un usage individuel de découverte, c'est parfaitement adapté. Pour un usage d'équipe, revenez à un serveur : une installation par poste disperse les clés, empêche de partager la mémoire et rend les mises à jour ingérables.

Faut-il un nom de domaine ?

Non, si vous passez par une messagerie. Un nom de domaine ne devient nécessaire que pour exposer une interface web, ce qui ajoute une surface d'attaque dont vous n'avez généralement pas besoin.

Comment migrer une installation vers un autre serveur ?

Installez le runtime sur la nouvelle machine, arrêtez l'ancienne instance, copiez le répertoire de données, vérifiez les permissions, redémarrez. La mémoire, les skills et les historiques suivent. C'est l'un des avantages concrets d'un stockage local et documenté.

Peut-on faire tourner plusieurs agents sur le même serveur ?

Techniquement oui, avec des utilisateurs système et des répertoires de données distincts. C'est utile quand deux services ont des périmètres de données réellement différents. Attention toutefois : deux agents, c'est deux configurations à durcir et à maintenir. Ne le faites pas sans raison.

Que faire si l'agent se comporte de façon incohérente ?

Trois vérifications dans l'ordre : la mémoire, qui contient peut-être une information erronée enregistrée par mégarde ; les skills créées automatiquement, dont l'une peut coder une procédure fausse ; et les journaux, pour identifier quel outil a été appelé et avec quel résultat. Dans la grande majorité des cas, le problème est un apprentissage parasite, pas le modèle.

Pour aller plus loin

• Hermes Agent expliqué : fonctionnement, mémoire, skills et limites
• Déployer Hermes Agent en entreprise : architecture, gouvernance et plan en 4 semaines
• Sécurité et RGPD de Hermes Agent : la checklist complète de durcissement
• Serveurs d'inférence LLM open source : pour un modèle exécuté en local
• Développement et intégration IA : faire installer et connecter l'agent à vos outils