HERMES Agent : Déploiement souverain et sécurisé sur VPS

Projets · Agents IA · Sécurité

Déploiement sécurisé de Hermes Agent sur un VPS — premier volet de notre série sur les agents IA souverains. Une question de fond pour toute structure qui adopte l'IA : qui contrôle cet assistant ? Ses données, ses actions, sa mémoire — chez qui vivent-elles vraiment ?

Depuis deux ans, nous avons pris une habitude : ouvrir un onglet, taper une question, lire une réponse. L'intelligence artificielle, pour la plupart d'entre nous, vit dans le navigateur de quelqu'un d'autre.

Une nouvelle génération d'outils change discrètement cette logique. Ce ne sont plus des chatbots que l'on visite, mais des agents qui résident quelque part — idéalement, sur une machine que l'on contrôle. Ils se souviennent d'une conversation à l'autre, exécutent des tâches, et restent joignables depuis vos applications de messagerie habituelles.

Cet article raconte comment nous avons déployé Hermes Agent, un framework open source, sur un simple serveur privé virtuel (VPS), avec la sécurité comme fil conducteur du début à la fin.

Hermes Agent, qu'est-ce que c'est ?

Hermes Agent est un framework d'agent autonome, publié en open source (licence MIT) par le laboratoire Nous Research. Il s'inscrit dans une vague récente d'outils du même genre, qui partagent une promesse commune : faire passer l'IA du statut de « répondeur » à celui d'« acteur ».

Concrètement, ce n'est ni un assistant de codage greffé à un éditeur, ni une surcouche autour d'une seule API. C'est un logiciel qui vit sur un serveur, conserve une mémoire entre les sessions, et devient plus utile à mesure qu'on l'utilise.

La distinction qui éclaire tout : le framework et le modèle

Quand on parle de « Hermes », on désigne en réalité deux choses différentes. Et les confondre, c'est passer à côté de l'essentiel.

Le framework est la voiture : le châssis, le tableau de bord, les commandes. Il gère la mémoire de l'agent, ses canaux de communication, ses outils et ses garde-fous. Il est stable et ne change pas selon les jours.

Le modèle est le moteur : l'intelligence proprement dite. Et il est interchangeable. On peut faire tourner le même framework avec un modèle dans le nuage (comme Claude, via une API) ou avec un modèle qui s'exécute entièrement sur votre serveur. C'est cette modularité qui rend Hermes intéressant : vous choisissez le compromis entre puissance, coût et confidentialité, sans changer d'outil.

Pourquoi Hermes, et en quoi diffère-t-il des outils voisins ?

Hermes n'est pas seul sur ce terrain. D'autres frameworks d'agents open source ont ouvert la voie. La catégorie est jeune, et elle mûrit vite.

Ce qui distingue Hermes, c'est une obsession affichée pour deux qualités historiquement difficiles à obtenir d'un agent : la fiabilité et la mémoire persistante. Là où beaucoup d'agents oublient tout entre deux tâches, Hermes est conçu pour se souvenir et reprendre là où il s'était arrêté. Et point décisif pour une PME : il tourne même sur une machine modeste dès lors que le modèle est appelé via une API, sans carte graphique coûteuse.

La sécurité d'abord : penser en architecte, pas en bricoleur

C'est ici que se joue la vraie différence entre une démo et un déploiement responsable. Donner à un agent la capacité d'agir sur un serveur, c'est lui confier des clés. La question n'est pas si on les confie, mais combien, et dans quelle pièce.

Le moindre privilège. L'agent ne reçoit que les capacités dont il a strictement besoin. Nous avons désactivé l'automatisation de navigateur et le contrôle de bureau — inutiles sur un serveur sans écran. Chaque permission accordée est une permission réfléchie.

L'isolation, ou la maîtrise du rayon d'impact. Sans précaution, l'agent agit directement sur l'ensemble du serveur. Avec une isolation par conteneur Docker, il travaille dans un bac à sable jetable : une salle blanche dont il ne peut pas sortir.

L'analogie tient en une image : préféreriez-vous qu'un stagiaire encore en formation travaille en libre accès dans tous vos bureaux, ou dans une salle dédiée dont la porte est fermée ? L'isolation ne supprime pas le risque — elle en limite l'étendue.

Aucun secret en clair. Les clés d'accès ne figurent jamais dans un fichier de configuration lisible, ni dans une conversation, ni dans un dépôt de code. Elles vivent dans des variables d'environnement, à part. Un secret exposé, même une seconde, doit être considéré comme compromis et renouvelé immédiatement.

Le déploiement, en quatre temps

La méthode officielle de Hermes en conteneur Docker suit une logique propre et reproductible. Nous l'avons abordée comme une checklist, en validant chaque étape avant la suivante.

1. L'image. On récupère l'image Docker officielle de Hermes. C'est un colis prêt à l'emploi qui contient tout ce dont l'agent a besoin pour fonctionner.

2. La configuration. Un assistant guidé pose les bonnes questions : quel modèle, quels outils, quels canaux. La clé API est saisie directement dans le terminal du serveur — jamais affichée, jamais copiée ailleurs.

3. Le test. Règle d'or que nous ne négocions jamais : on vérifie que l'agent répond en ligne de commande avant de l'ouvrir au monde. Si l'agent dit bonjour correctement ici, la fondation est saine.

4. Le gateway permanent. On lance enfin le conteneur en arrière-plan, avec redémarrage automatique. L'agent survit désormais à un redémarrage du serveur sans la moindre intervention.

Un détail qui change tout : toute la mémoire, la configuration et les sessions de l'agent vivent dans un volume persistant, séparé du logiciel lui-même. On peut mettre à jour l'image sans rien perdre — et ce volume est sauvegardé vers un dépôt Git privé.

Ce que ça change concrètement

Au terme de ce déploiement, l'agent est disponible en permanence, hébergé sur une infrastructure que nous maîtrisons, dont nous contrôlons les permissions, la mémoire et les canaux d'accès.

Soyons précis, car c'est une question d'honnêteté intellectuelle : tant que le modèle est appelé via une API dans le nuage, le raisonnement, lui, sort de votre serveur. La souveraineté n'est jamais absolue par défaut — elle est un curseur que vous réglez. Ce que l'auto-hébergement vous rend, c'est le contrôle de tout le reste : l'infrastructure, les données mémorisées, les actions autorisées, et la possibilité, demain, de remplacer le moteur dans le nuage par un modèle 100 % local pour les usages les plus sensibles.

Pour une PME, une TPE ou une collectivité, c'est exactement le bon point de départ : comprendre l'architecture, garder la main, et faire évoluer le niveau de confidentialité au rythme de ses besoins réels.