Du poids mort au majordome : installer Hermes Agent sur la Citadelle

Suite de Le Réveil de la bête. Là-bas, je laissais un bloc mort dans mon compose.yml : un service Hermes que je n’arrivais même pas à démarrer, et une phrase que j’avais écrite un peu vite — « le poids mort d’Hermes ». Voici la suite, et elle ne se passe pas comme prévu.

21 h 38, « hello there »

Le 10 septembre au soir, j’écris deux mots à un truc qui n’existe pas encore vraiment : hello there. Pas de plan, pas de configuration, juste l’envie de voir ce que ça répond.

Deux jours plus tard, l’agent tourne sur la Citadelle, il répond sur Telegram, il a accès à mon serveur, à ma mémoire et à 62 compétences. La ligne morte du compose.yml, elle, n’existe plus : je l’ai retirée.

Pas de conteneur, installation directe

Mon réflexe, c’était le conteneur : un service de plus dans le compose, et on n’en parle plus. Sauf que le conteneur ne s’est jamais lancé.

Alors j’ai fait l’inverse : installation directe sur le système, à la racine. Et ça a fonctionné tout de suite. Avec un avantage que je n’avais pas anticipé et qui compte pour un agent : il a accès à tous les fichiers de la machine, sans volume à monter ni chemin à traduire. Un agent qui doit lire une configuration, un journal ou un projet n’a pas besoin d’un mur entre lui et le disque.

En prime, sur une tour qui fait déjà tourner un proxy, une base, un serveur de code et une synchro de notes, ça évite un conteneur de plus pour un programme qui parle à un modèle distant.

L’installation

L’installation, c’est vingt minutes et zéro surprise : l’installeur officiel monte tout, puis deux commandes pour choisir le modèle et vérifier l’état de la maison.

hermes setup     # assistant de configuration
hermes model     # choix du modèle et du fournisseur
hermes doctor    # état des lieux

Le modèle, c’est du deepseek-flash : rapide et bon marché, largement suffisant pour un agent qui passe sa journée à lire des fichiers et à taper des commandes. Le cadre est agnostique, je peux changer de fournisseur sans réinstaller.

Le premier mur arrive avec le gateway, la partie qui branche l’agent sur une messagerie. Je veux qu’il réponde sur Telegram, c’est là que je suis.

✗   Start failed — user systemd not reachable:
    loginctl enable-linger was denied: Failed to connect to system scope bus
    systemctl --user cannot reach the user D-Bus session in this shell.

Traduction : sur cette machine je travaille en SSH sur un compte sans session graphique ni bus utilisateur, donc systemctl --user ne peut rien piloter.

Deux erreurs, deux causes

Une fois ce point réglé, le gateway a redémarré en boucle : entre 19 h 46 et 20 h 00, quarante démarrages à vingt secondes d’intervalle.

Pour comprendre, je n’ai pas fait d’archéologie. J’ai collé les erreurs à mon agent, et je l’ai couplé avec une session d’un agent OpenCode en parallèle, sur le même problème. À deux, ils ont identifié deux causes bien distinctes :

Deux problèmes qui n’avaient rien à voir l’un avec l’autre, et qui se manifestaient de la même façon : un service qui tombe. C’est exactement le genre de diagnostic où je serais resté bloqué une soirée sur le mauvais problème.

Depuis, une seule instance, sous contrôle d’un superviseur, et il n’a plus bougé.

L’interface web en dix minutes

Il existe une interface web pour cet agent, maintenue à part du projet principal. Je l’ai trouvée sur GitHub, et je ne l’ai pas installée moi-même.

J’ai ouvert une conversation vide de tout contexte, je lui ai donné le lien du dépôt et j’ai dit : configure ça correctement sur mon installation. Dix minutes plus tard, c’était impeccable, en service, accessible depuis le navigateur.

C’est probablement le passage le plus déroutant de ces deux jours : un outil qui lit son propre dépôt et qui s’installe.

Une chose à ne pas faire pour autant : une interface d’administration qui donne accès à un agent ayant les droits de toucher au serveur ne se publie pas sur Internet sans authentification. Ça n’a rien à voir avec la confiance qu’on porte à l’outil.

Une recherche et une lecture auto-hébergées

Un agent sans accès au web est un agent bavard.

L’agent dispose de deux outils natifs pour ça : web_search pour chercher, web_extract pour lire une page. Je les ai branchés sur ma propre infrastructure, chacun sur son service.

Pour la recherche, un conteneur de plus dans le compose.yml : Degoog, un métamoteur auto-hébergé, exposé sur une API compatible SearXNG — le format que web_search parle nativement. Il arrive sans aucun moteur activé, et on installe ensuite ceux qu’on veut depuis son magasin d’extensions. Ma sélection :

Pour la lecture, pas de conteneur du tout : un petit plugin que j’ai posé dans le dossier de plugins de l’agent, qui récupère la page avec httpx et la découpe en texte exploitable avec trafilatura, sans navigateur sans tête. web_extract pointe dessus.

Recherche et lecture tapent donc l’une sur mon métamoteur, l’autre sur ma brique locale, sans navigateur headless : aucune clé d’API, aucun tiers dans la boucle.

J’avais d’abord visé Firecrawl, la solution dont tout le monde parle, avec ses workers, son service Playwright et sa base. Abandonnée pour une raison bête : la pile demande plus de 4 Go de RAM, la machine en a 3,8. Et un plugin local suffit à lire un article ou une documentation. C’est le même raisonnement que dans La friction salutaire : la contrainte matérielle tranche les débats d’architecture mieux que n’importe quel comparatif.

La persona, en trois lignes

J’ai trouvé un fichier d’âme sur internet, je l’ai adapté au français et à ma façon de travailler, et j’ai bien aimé le style.

Je conseille à tout le monde de faire ça : ça donne beaucoup plus de personnalité aux discussions. Une persona change la donne : l’agent tient une position, il te reprend quand tu t’apprêtes à faire une bêtise, il anticipe l’étape d’après au lieu d’attendre l’instruction.

La sauvegarde, et le seul vrai garde-fou

Chaque nuit, la configuration part vers un dépôt privé — sans les secrets, exclus par principe. Et avant chaque envoi, un script relit tout et refuse le push s’il trouve une clé ou un mot de passe. Un garde-fou qui bloque au lieu d’avertir.

Pour le reste, la règle est simple : ce qui se défait reste libre, ce qui ne se défait pas demande l’autorisation. Un fichier, un commit local, un conteneur qu’on recrée — vas-y. Un envoi vers l’extérieur, une suppression, une publication — tu demandes d’abord.

Bilan

Ce qui tourne aujourd’hui : installation directe sur le système, gateway Telegram stable, interface web en service, métamoteur auto-hébergé avec neuf moteurs, 62 compétences, une persona, des sauvegardes nocturnes. Ce qui reste : quatre avertissements au dernier état des lieux, rien de bloquant, hermes doctor ne ment pas.

Deux choses que je retiens. La première, c’est que ce système est plus modeste que celui que je faisais tourner sur mon laptop — et qu’il a un avantage qui écrase le reste : il vit sur le serveur, dans une machine isolée de ma machine de travail. Il tourne quand mon laptop est fermé, et si je casse quelque chose en bricolant, ça ne touche pas mon outil de production.

La seconde, c’est que je n’ai pas installé ce logiciel tout seul. J’ai passé deux jours à coller des erreurs dans une conversation, et la plupart du temps, ça a suffi. Sans fournisseur branché, un agent reste un binaire muet. Une fois le modèle en place, il devient le meilleur assistant d’installation de lui-même. Il reste une part de maîtrise en moins : je ne saurais pas réinstaller tout ça de mémoire.

Quant à la conclusion de mon article précédent — « le prochain chantier, c’est cet agent IA qui remplacera le poids mort d’Hermes » — elle a mal vieilli. Le fameux poids mort venait de ma façon de l’installer, rien d’autre.