Mon collègue Hermes : un agent IA sur VPS

22 h 47, un message Telegram.

Mon téléphone vibre sur la table de nuit :

« Le build nightly de ce matin a échoué. Analyse des logs : la dépendance acme-lib, mise à jour hier, casse la construction de l’image de l’API. Le staging tourne toujours sur la version antérieure. Je peux figer la version ou redémarrer le staging : je le fais ? »

Ce n’est pas un ou une collègue. C’est mon agent IA sur VPS. Il s’appelle Hermes, il vit sur un petit serveur dans un datacenter européen et il ne dort jamais. Trois semaines qu’on travaille ensemble : il a pris des notes sur nos builds, il sait quels logs consulter et surtout, il a ce réflexe de demander avant d’agir.

Cet article raconte comment il est arrivé là et comment vous pouvez démarrer votre agent IA sur un VPS en dix minutes.

Et pour s’assurer de respecter ce délai, un dépôt GitHub vous accompagne pour bien démarrer.

Un agent IA qui vit sur un ordinateur portable est un agent fragile

Si vous avez déjà testé un assistant IA local, vous connaissez les symptômes. L’agent s’éteint quand vous fermez l’ordinateur, évidemment. Il repart plus ou moins de zéro à chaque session, sauf si vous recollez votre contexte à la main. Les routines restent manuelles (ex. vérifications matinales, récapitulatif hebdomadaire). Et pour l’interroger, il faut penser à ouvrir une application : l’agent ne vient jamais vers vous.

C’est donc un problème très vite pointé du doigt. Un ordinateur personnel est rarement allumé, presque jamais exposé à l’extérieur du foyer et son utilisateur ou utilisatrice passe ses journées à changer d’outil : console web, CLI, tableau de bord ou encore messagerie. Pour un agent autonome, c’est un très mauvais foyer : pas de temps de disponibilité, pas de joignabilité, pas de mémoire durable. L’ordinateur est l’endroit où l’on travaille et décide, mais ce n’est pas là qu’un processus vit.

Ce qu’il faut, c’est un foyer permanent, joignable par les canaux que vous utilisez déjà et capable de garder ce qu’il apprend. En un mot : un (petit) serveur.

Hermes, l’agent qui apprend en travaillant

Présentation rapide : Hermes Agent est un agent IA open source, sous licence MIT et développé par Nous Research. Il compte environ 252 000 étoiles sur GitHub. Trois caractéristiques font la différence au quotidien.

D’abord, la boucle d’apprentissage. Après une tâche un peu complexe, Hermes crée une skill (il s’agit généralement d’un fichier nommé SKILL.md). C’est une procédure qu’il a lui-même formalisée et qu’il améliore à chaque usage. Sa mémoire persiste entre les sessions par ce biais. De plus, il sait fouiller ses conversations passées pour retrouver ce qu’il avait établi. Ainsi, il ne repart pas de zéro chaque matin. Et c’est là tout l’intérêt.

Après trois semaines, il n’a plus besoin qu’on lui rappelle où sont les logs ni comment notre staging est organisé. L’agent l’a noté, vérifié et consigné dans une skill de deux lignes.

En second lieu, l’omniprésence. Une passerelle unique le rend joignable sur une trentaine de plateformes : Telegram, Signal, Slack, Discord, Matrix, Teams, e-mail et même SMS. Il est possible de lui parler via nos canaux de communication habituels, sans ouvrir de fenêtre supplémentaire. C’est un vrai avantage.

Enfin, la versatilité. Il est possible de changer le modèle en une commande (/model) : OpenRouter, OpenAI, Nous Portal ou votre propre endpoint. Des sous-agents peuvent travailler en parallèle et l’exécution être isolée dans un conteneur. Il n’y a aucun verrouillage.

Hermes peut d’ailleurs s’intégrer avec les AI Endpoints d’OVHcloud, pour rester dans un environnement maîtrisé. Pour un autre exemple d’agent connecté à ce service, lisez l’article sur Docker Agent avec AI Endpoints (en anglais).

Le détail qui change tout : un planificateur (scheduler) intégré qui comprend le langage naturel. « Chaque matin à 8 h, résume-moi la nuit » devient une tâche planifiée sans avoir à crontab -e, ni détourner sa pipeline CI.

Pourquoi un agent IA sur VPS, pas en SaaS

Un agent hébergé par un tiers peut avoir des fonctionnalités avancées, mais est situé dans une boîte noire : vous ne voyez pas où tournent vos outils, où dorment leur mémoire et leurs clés. Sur un VPS, l’équation s’inverse. La mémoire, les skills, l’historique : tout se trouve sur votre machine, dans un datacenter européen. Les clés API sont les vôtres. Le modèle est celui que vous choisissez, depuis l’endpoint que vous décidez. L’hébergeur ne dispose ni de vos conversations, ni de vos skills, ni de vos tokens.

Il en va de même pour l’économie. Un VPS d’entrée de gamme avec 2 vCores, 4 Go de RAM, 40 Go NVMe, backup quotidien, trafic illimité coûte moins de 5 € HT par mois. La passerelle et ses sous-agents sont facilement hébergés dedans. Et si vous préférez déléguer l’exploitation, OVHcloud propose aussi Hermes en mode hébergement managé, crédits IA inclus. Pour un usage technique, le VPS reste la bonne solution : vous contrôlez l’environnement, séparez le test de la production, câblez l’agent dans ses chaînes existantes.

Et si Telegram ne passe pas dans votre organisation ? Le canal n’est qu’une ligne de configuration : la passerelle supporte une trentaine de plateformes. Pour un chiffrement de bout en bout par défaut, le guide Signal figure dans le dépôt, la mise en place étant toutefois un peu plus longue. Pour une souveraineté totale du canal, utilisez Matrix auto-hébergé sur le même VPS, ou SimpleX. Et si votre équipe IT impose ses outils : Slack, Teams, Mattermost et Google Chat fonctionnent aussi. Le canal importe pour le chiffrement. Le VPS pour la souveraineté.

Comment le mettre en service en dix minutes

Trois prérequis : un compte OVHcloud avec moyen de paiement par défaut (la commande via API l’exige), un token BotFather pour Telegram et une clé API de modèle. Puis :

Le script deploy.sh enchaîne cinq étapes : les prérequis système, l’installation officielle d’Hermes (environ cinq minutes), puis deux prompts interactifs pour le choix du modèle (hermes model) et l’appairage de Telegram (hermes gateway setup). Vient enfin la configuration de la passerelle. Pour une installation manuelle, le guide d’installation d’Hermes Agent détaille chaque étape.

Ouvrez Telegram, saluez votre bot : il est opérationnel et va le rester.

Les premiers jours, son travail ressemble surtout à de l’observation. Vous lui donnez du contexte : conventions, adresses utiles, ce qu’on appelle « production » et ce à quoi on ne touche jamais. L’agent intègre tout cela à sa mémoire. La semaine suivante, ses questions changent de nature : moins « où est-ce ? », plus « voilà ce que j’ai trouvé, veux-tu que j’agisse ? ». C’est la promesse d’Hermes.

Vous hésitez encore ? Le dépôt contient aussi un déploiement sur une instance Public Cloud, facturée à l’heure : on teste, on met en pause le soir (power_state=SHELVED, on ne paie plus que le stockage), on détruit quand le prototype a dit ce qu’il avait à dire. Une session de test ne coûte que quelques centimes. C’est d’ailleurs une instance Public Cloud qui a été utilisée pour écrire cet article.

Le rapport de 8 heures, l’incident de 14 heures

Le rapport matinal, d’abord. Une phrase, dite une fois : « Chaque jour à 8 heures, résume-moi les échecs de build et les incidents de la nuit et signale ce qui attend mon avis. » et le planificateur s’en occupe. Chaque matin, un résumé arrive dans le canal avec ce qui mérite vraiment votre attention. Quand la nuit a été tranquille, il le dit en une ligne, pas en vingt.

Le triage d’incident, ensuite. L’erreur tombe à 14 heures ? Elle est ajoutée au bot. Il lit le log correspondant, recoupe avec la dernière modification connue, propose une hypothèse et une action, puis attend votre confirmation. Le tout, dans le même fil de discussion, sans changer de fenêtre.

Ce que je ne lui confie pas

Il existe évidemment des limites à l’utilisation d’un tel outil : un agent doté d’un shell est une surface d’attaque et il faut le traiter comme tel.

• L’allowlist, pour commencer : le bot n’accepte les messages directs que des contacts listés.
• Le pare-feu, ensuite : seul le SSH est exposé, la passerelle ne fait que du trafic sortant.
• Les tokens du scope, enfin : Hermes a un droit de lecture sur le staging, pas de mot de passe root de la production. La passerelle prévoit même une sécurité optionnelle pour encadrer certaines actions avant leur exécution.

Ce qui doit être versionné, audité et partagé reste en Infrastructure as Code : le déploiement en production se passe dans un pipeline, pas dans un chat.

Hermes excelle en exploration, en diagnostic et en actions ponctuelles confirmées, mais pas en remplacement des pipelines.

Si l’action doit être reproductible demain par quelqu’un d’autre, elle est versionnée dans le code. Si elle doit être décidée maintenant, elle peut passer par l’agent.

Trois semaines plus tard

22 h 47. Le message arrive toujours. Ce qui a changé, c’est ce que je lui confie : les tâches routinières ont disparu de ma journée, mais les décisions sont restées humaines. Avec Hermes qui demande avant d’agir, c’est assez simple.

Un détail qui a compté au fil des semaines : quand mon ordinateur a changé, Hermes n’a pas bougé. Sa mémoire, ses skills, son historique restent sur le VPS, sauvegardées comme le reste de l’infrastructure. Le ou la collègue n’a jamais travaillé sur mon poste. Il ne reste plus qu’à prévoir de sauvegarder l’environnement de travail au cas où, avec VPS Backup par exemple. Pour installer votre propre agent IA sur VPS, consultez la documentation d’Hermes Agent.