Mon homelab tourne tout seul depuis des années : k3s, Home Assistant, Uptime Kuma, OneDev pour mes dépôts git. Les services, je sais les faire tourner. Ce qui me manquait, c’est un cerveau. Pas un chatbot dans un onglet, mais un agent avec accès à mes machines, mes dépôts et mes canaux de communication. Quelqu’un qui exécute des tâches pendant que je fais autre chose.

J’ai installé Hermes Agent, le framework open-source de Nous Research, sur une VM dédiée de mon homelab en avril dernier. Je vais te raconter le parcours dans l’ordre où je l’ai vécu : les besoins au fur et à mesure, et comment chacun a trouvé sa réponse.

L’installation

J’ai créé une VM Debian pour l’occasion : 2 vCPU, 4 Go de RAM, 40 Go de disque. Rien d’énorme.

L’installation tient en une commande :

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

Le script installe Python, crée un environnement virtuel et déploie le CLI. Une vingtaine de minutes plus tard, Hermes était prêt.

Première étape : brancher un modèle

La première commande que j’ai lancée sur Hermes n’a pas été un test de chat. C’était la configuration du modèle. Hermes est agnostique : il accepte à peu près n’importe quel provider (OpenRouter, Anthropic, OpenAI, DeepSeek, xAI, des modèles locaux…). Le choix se fait avec hermes model ou directement dans ~/.hermes/config.yaml.

J’ai testé plusieurs combinaisons. Mon critère, c’était le rapport qualité/prix pour des tâches longues. Un agent qui collecte, analyse, rédige et pousse du code consomme beaucoup de tokens. Avec les modèles premium, la facture grimpe vite.

Ma config actuelle :

model:
  provider: opencode-go
  default: deepseek-v4-flash
fallback_providers:
  - provider: opencode-zen
    model: deepseek-v4-flash-free
  - provider: opencode-zen
    model: nemotron-3-ultra-free
auxiliary:
  vision:
    provider: opencode-go
    model: mimo-v2.5

Je tourne sur DeepSeek-V4-Flash, un modèle de la famille DeepSeek, servi par le provider opencode-go. Trois raisons à ce choix :

  • Le prix. Les modèles Flash de DeepSeek sont parmi les moins chers du marché pour leur niveau de qualité. Pour un agent qui tourne en continu, ça change tout.
  • La vitesse. L’inférence est rapide, ce qui compte pour les pipelines automatisés.
  • Les fallbacks. Si le provider principal est indisponible ou échoue, Hermes bascule automatiquement sur les suivants : une version gratuite du même modèle, puis un modèle open-source de secours. Je n’ai jamais de panne sèche.

Pour la vision, c’est un modèle séparé : mimo-v2.5, toujours via opencode-go. Quand je colle une capture d’écran à Hermes, c’est lui qui l’analyse. Le raisonnement reste sur le modèle principal, la vision a son propre moteur, et les deux vivent dans la même config.

Utilisation dans le terminal

Une fois le modèle branché, j’ai utilisé Hermes en ligne de commande pendant un moment. L’agent répondait dans le terminal, avec les mains sur la machine : il pouvait exécuter des commandes système, lire ma config, répondre en français. J’avais un cerveau sur mon homelab, accessible en ligne de commande.

Hermes Agent dans le terminal : les outils, les skills et le profil en un coup d’œil

C’est là que j’ai eu mon premier déclic. Je lui ai demandé, dans le terminal, de me résumer l’état de mon cluster k3s. Il s’est connecté sur la machine, a lancé kubectl get pods, et m’a répondu avec le détail des pods. Pas une réponse générique : un vrai état du cluster, lu en direct.

Besoin suivant : le joindre depuis mon téléphone

Un agent qui ne vit que dans le terminal, c’est limitant. Je voulais lancer des tâches depuis mon téléphone, où que je sois. Hermes a un gateway qui connecte l’agent à des plateformes de messagerie. J’ai commencé par Telegram.

Ça marchait, mais je me suis vite rendu compte que c’était limitant. Un fil de discussion unique, des échanges qui se mélangent, pas de séparation par sujet. Je suis passé sur Discord, sur mon serveur : des canaux dédiés, un fil par domaine d’activité. L’agent est présent dans les canaux, répond aux messages, et garde les mêmes outils que dans le terminal : fichiers, shell, git, cron. Je lui demande de regarder un log, de corriger un script, de préparer une publication, et il le fait, puis répond dans le canal.

La configuration du gateway est simple : un token par plateforme, une ligne dans la config. Le passage de Telegram à Discord m’a pris quelques minutes, et a transformé l’usage. Au lieu d’un fil unique où tout se mélange, j’ai un canal pour le blog, un pour les dépôts, un pour les alertes. La différence est nette au quotidien.

Besoin suivant : qu’il se souvienne de moi

Avec les autres agents, le problème est toujours le même : il faut réexpliquer le contexte à chaque session. Qui je suis, comment fonctionne mon blog, où sont mes dépôts, quelles sont mes conventions. Dix minutes de mise en contexte à chaque fois, et encore, ça ne rentre jamais vraiment.

Avec Hermes, ce besoin a disparu. La mémoire persistante fait que l’agent retient mes préférences et les détails de mon environnement entre les sessions. Il sait que mon blog est en Hugo, que mon serveur git est OneDev, que je préfère les réponses en français. D’un jour à l’autre, je ne répète plus rien : il reprend là où on s’était arrêtés.

Besoin suivant : qu’il apprenne de ses réussites

La mémoire, c’est du passif. Pour l’actif, il y a les skills : des procédures réutilisables que l’agent sauvegarde après avoir réussi une tâche, et qu’il recharge dans les sessions suivantes.

J’en ai aujourd’hui 79 installés. Certains viennent de la communauté, mais les plus précieux sont ceux que j’ai écrits pour mes propres tâches : le déploiement de mon blog Hugo, la gestion de mes issues OneDev. Sur les tâches répétitives, la différence est nette : la qualité monte, les erreurs diminuent, et l’agent va droit au but au lieu de redécouvrir la méthode à chaque fois.

Un conseil appris à mes dépens : trop de skills, c’est du bruit. Je charge ceux dont j’ai besoin pour la tâche, pas tous en permanence.

La config est sauvegardée sur git

Quelque chose que je fais pour tout service que je monte chez moi : la configuration doit survivre à la machine. Le dossier ~/.hermes de la VM est un dépôt git, poussé sur mon serveur OneDev (hermes-home.git). Config, skills, scripts, tout est versionné.

Concrètement, si la VM meurt, je reclone et je repars. Pas de reconfiguration à refaire, pas de skills perdus. C’est le même réflexe que pour mes autres services : tout ce qui se reconfigure, se documente, se versionne. Une VM, ça se recrée ; une config, ça ne se réinvente pas.

Besoin suivant : que ça tourne tout seul

Dernier besoin, le plus important : que tout ça s’exécute sans moi. Le gateway inclut un planificateur de jobs, et j’ai monté mes premières automations :

  • 5h00 : veille IA quotidienne. L’agent collecte les actualités IA de la veille, les score, rédige un article TLDR et le publie sur mon blog Hugo. Je me réveille avec l’article en ligne. Je détaillerai ce pipeline dans un prochain article.
  • Toutes les 6h : alerte prix. Surveillance du prix d’une clim réversible que je convoite.
  • Toutes les 2h : veille Leboncoin. Un œil sur les Mac Mini M2 d’occasion.

Les jobs vivent dans ~/.hermes/cron/jobs.json, et chaque exécution laisse une trace consultable. Le soir, je consulte le récapitulatif. Le matin, le travail est fait.

Ce que la doc ne dit pas

Quelques pièges rencontrés en vrai :

  • La mémoire, ça se taille. L’espace est limité : il faut faire le tri entre ce qui dure (préférences, conventions) et le bruit du moment. Je la nettoie régulièrement.
  • Les secrets restent dans .env. Le fichier de config ne contient que les réglages. Clés API, tokens, tout ce qui est sensible va dans ~/.hermes/.env. Règle d’or : jamais de secret dans un fichier versionné.
  • Le gateway, ça se surveille. C’est un service comme un autre : je regarde les logs, je vérifie qu’il répond. Un agent qui tourne en silence peut échouer en silence.

Le bilan

Hermes Agent tourne sur ma VM depuis avril. Concrètement :

  • Le blog publie tous les jours, sans que j’y touche. Avant, publier un article de veille me prenait une trentaine de minutes.
  • Mes dépôts ont des issues gérées par l’agent, avec des statuts, des commentaires, des branches propres.
  • Je pilote depuis mon téléphone, via Discord, des machines qui tournent à la maison.

Le coût, c’est le prix des appels API au modèle, de l’ordre de quelques centimes par jour pour mon usage. Et une VM de 4 Go qui me sert à ça. Pas d’abonnement, pas de données chez un tiers.

Et la suite

Dans le prochain article, je détaille le pipeline qui m’a fait gagner le plus de temps : la veille IA quotidienne automatisée, de la collecte des sources jusqu’à la publication sur le blog, avec les étapes de scoring et de validation qui rendent le résultat publiable sans relecture.

En attendant, si tu as un homelab qui tourne, essaie Hermes. L’installation prend vingt minutes, et le premier « je l’ai fait depuis mon téléphone » arrive plus vite qu’on ne croit.