J'ai failli installer OpenClaw. J'ai pris Hermes. Voici pourquoi.

Il y a six mois, ma routine du soir ressemblait à ça : ouvrir un terminal, CTRL+R, taper un bout de commande, prier pour que l’historique la retrouve. systemctl status quelque-chose. docker ps. df -h. Les mêmes gestes, tous les soirs. Pas compliqués. Pas longs. Juste… là. Tous les soirs.

Aujourd’hui, j’ouvre Telegram. J’écris « vérifie les disques et le status des conteneurs ». Je verrouille mon téléphone. Deux minutes plus tard : « Tout est OK. 67% d’espace disque, 8 conteneurs actifs, 0 en erreur. »

C’est pas de la flemme. C’est une réalisation un peu gênante : 90% de ce que je fais sur un ordinateur, c’est de la tuyauterie entre une intention et un résultat. Je sais que ma VM a besoin d’un update. Je sais qu’il faut que je commit ce fichier. Je sais que ce service tourne bizarrement. L’information existe. L’action est triviale. Mais c’est moi qui fais la jonction. À chaque fois.

Un agent IA, dans ce contexte, c’est pas un assistant. C’est une interface — une couche entre ton intention et le monde. Et si t’es comme moi, un mec qui passe sa vie sur un terminal mais qui rêve que le terminal se passe de lui, cette couche change tout.

Cet article n’est pas un benchmark. C’est mon retour après des mois à faire tourner un agent IA 24/7, le comparer à l’alternative la plus populaire du moment, et comprendre ce qui marche vraiment.

OpenClaw vs Hermes : deux paris opposés

Si tu suis un peu la tech en 2026, t’as forcément entendu parler de ces deux projets. OpenClaw (anciennement Moltbot, puis Clawdbot) et Hermes Agent (par Nous Research, les créateurs des modèles Hermes/Nomos). Deux frameworks open source. Même surface apparente. Deux philosophies radicalement opposées.

OpenClaw : le couteau suisse

OpenClaw est un monstre. 345 000 étoiles GitHub. 24 plateformes de messagerie supportées (Telegram, Discord, WhatsApp, Signal, Slack, iMessage…). Un marketplace, ClawHub, avec plus de 13 000 skills communautaires. Une interface web de contrôle. Des apps iOS et Android. Un écosystème qui donne le vertige.

Le pari architectural : le problème difficile, c’est le routing et le contrôle. Le gateway est le composant central — un processus Node.js persistant qui gère les permissions, les canaux, l’approbation des commandes, le dispatch des skills. Le modèle IA derrière est interchangeable.

C’est l’approche « plateforme » : tu installes des skills écrites par d’autres, tu configures des canaux, tu relies des services. Le gateway orchestre. Toi, tu supervisionnes.

Ça marche. Des milliers de gens utilisent OpenClaw tous les jours. Mais en mars 2026, le vernis a craqué.

Le problème que personne n’a vu venir

Mars 2026. En quatre jours, OpenClaw reçoit 9 CVEs — des failles de sécurité documentées. Dont une classée CVSS 9.9, le niveau juste en dessous de « catastrophe nucléaire ». Un audit de ClawHub est lancé : sur 2 857 skills scannées, 341 sont malveillantes. Soit 12% du marketplace.

12%.

Ça veut dire qu’environ une skill sur huit que tu pouvais installer depuis la plateforme officielle était conçue pour compromettre ta machine. Exfiltrer des données. Ouvrir des backdoors. Lire tes fichiers.

Pendant le même mois, 135 000 instances OpenClaw étaient exposées publiquement sur Internet, dans 82 pays. Des gens avaient donné les clés de leur machine à un agent, et cet agent exécutait potentiellement du code non vérifié téléchargé depuis un marketplace infesté.

Je ne dis pas qu’OpenClaw est un mauvais projet. Je dis que quand ton outil a un accès shell complet à ta machine et que la surface d’attaque c’est « des skills écrites par des inconnus et installées sans revue de code », t’es plus dans l’automatisation. T’es dans la roulette russe.

Hermes : l’assistant qui écrit son propre manuel

Hermes fait le pari inverse. Le problème difficile, c’est pas le routing. C’est la mémoire et l’apprentissage.

Dans OpenClaw, tu écris ou tu télécharges des skills. Dans Hermes, l’agent écrit ses propres skills à partir de son expérience.

Exemple concret : la première fois que je lui demande de vérifier l’état de mes conteneurs, il tâtonne. Il essaie docker ps, il lit la sortie, il me fait un résumé. La troisième fois, il a mémorisé la procédure exacte, le format que j’aime, les conteneurs qui m’intéressent. La dixième fois, il a généré une skill autonome. Il n’a plus besoin que je lui explique.

La différence fondamentale : OpenClaw, c’est l’assistant qui suit le manuel que tu lui donnes. Hermes, c’est l’assistant qui écrit son manuel après chaque tâche — et qui s’en sert pour être meilleur la prochaine fois.

Ça paraît abstrait. En pratique, c’est un écart qui se creuse de jour en jour. Plus tu utilises Hermes, plus il devient spécifique à ton environnement, tes habitudes, tes préférences. Au bout de quelques semaines, l’agent n’est plus le même que celui que tu as installé.

Il a appris.

Pourquoi Telegram plutôt qu’un terminal

C’est la question qu’on me pose le plus : pourquoi ne pas utiliser le terminal directement ?

Deux raisons. Une pratique, une philosophique.

La raison pratique : mon téléphone est toujours sur moi. Mon terminal, je l’ouvre quand je bosse. Si j’ai besoin de quelque chose en dehors de mes heures de dev — un rappel, une vérification, une recherche rapide — Telegram est là. L’agent aussi. La conversation est asynchrone : j’envoie un message, je passe à autre chose, je reviens quand c’est prêt.

La raison philosophique : quand l’agent est dans un terminal, il reste un outil de dev. Quand il est dans Telegram, il devient une présence — comme un collègue silencieux qui répond quand t’as besoin, et qui se tait le reste du temps. La différence d’usage est massive. Ce n’est plus « je lance l’agent ». C’est « l’agent est là. »

Et accessoirement, pouvoir dicter un message en marchant et recevoir une réponse en vocal, ça change le rapport au temps. Tu consommes l’information quand tu veux, pas quand t’es devant un écran.

Le setup : zéro cloud, zéro abonnement, zéro complexité

J’insiste sur ce point parce que la plupart des tutoriels te vendent un cluster Kubernetes ou une facture AWS.

Mon setup tient en une phrase : une VM Debian sur un serveur allumé 24/7 à côté de mon bureau.

Coût marginal : zéro. La machine tournait déjà. J’y ai alloué 4 Go de RAM et 2 vCPU à la VM. C’est largement suffisant pour faire tourner Hermes, son gateway Telegram, et quelques traitements annexes.

Si t’as pas de serveur à la maison, les alternatives sont triviales :

• Un VPS à 5€/mois chez Hetzner, OVH ou Netcup. Une Debian minimale, le script d’installation, c’est plié.
• Un Raspberry Pi 5 sous ton bureau. 8 Go de RAM, un SSD USB, et t’as un agent silencieux qui tourne H24 pour 60€ de matos.

Le point important, c’est pas le hardware. C’est l’architecture : l’agent tourne en permanence. C’est pas un outil que tu lances quand t’en as besoin. C’est un processus qui vit avec toi, qui accumule du contexte, qui apprend tes habitudes. Une présence continue, pas un exécutable à la demande.

La sécurité : le sujet que tout le monde évite

Quand tu donnes un accès shell à un agent IA, tu réfléchis à la sécurité ou t’es inconscient. Et malheureusement, la plupart des gens sont dans la deuxième catégorie.

OpenRouter : pratique, mais opaque

OpenRouter est le provider le plus pratique pour démarrer : 200+ modèles, un seul compte, pas besoin de gérer 15 clés API. Mais derrière la simplicité, y a une réalité gênante : tu ne sais pas toujours où passent tes prompts.

Certains modèles disponibles sur OpenRouter sont routés vers des fournisseurs chinois (DeepSeek, MiniMax, Qwen, Kimi…). Ces fournisseurs ont des politiques de logging opaques. Tes prompts — qui contiennent peut-être des noms de fichiers, des structures de projet, des extraits de code sensibles — transitent par des serveurs dont tu ne connais ni la localisation ni les conditions d’utilisation.

C’est pas de la paranoïa. C’est le minimum syndical quand tu connectes un agent à ta vie numérique.

Mes règles personnelles :

• Spending limit stricte sur toutes les clés API. Même si la clé fuit, les dégâts sont plafonnés.
• Jamais de données sensibles dans les prompts. Pas de tokens, pas de mots de passe, pas de secrets d’infrastructure.
• Pour le code critique ou les données perso, modèle local. Ollama, llama.cpp, vLLM — tout tourne sur ta machine, zéro donnée qui sort.

Hermes supporte les modèles locaux nativement. Tu peux avoir un agent qui tourne entièrement hors ligne si tu veux.

Le piège du marketplace

Je l’ai dit plus haut, mais ça mérite d’être répété : un marketplace de skills pour un agent qui a accès à ton shell, c’est une bombe à retardement.

Avec Hermes, les skills sont générées par l’agent à partir de son expérience avec toi. Elles ne viennent pas d’un dépôt tiers. Elles ne sont pas écrites par un inconnu. Elles sont auditées automatiquement avant d’être ajoutées à la librairie. Et comme elles sont en Markdown, tu peux les lire, les modifier, les supprimer — comme n’importe quel fichier.

Ce n’est pas la solution parfaite. Mais c’est un modèle de confiance différent : au lieu de faire confiance à un marketplace, tu fais confiance à un agent qui apprend de toi, dans ton environnement, et dont chaque skill est transparente.

Le vrai hack : Codex à 20€/mois

C’est le paragraphe que tu vas montrer à tes potes.

OpenAI propose Codex CLI, un abonnement à 20€/mois (ou 20$ selon la région) qui donne un accès quasi illimité à leurs meilleurs modèles. Pas du pay-per-token. Du forfait.

Tu peux utiliser ce forfait derrière Hermes comme provider. Résultat : un agent qui tourne 24/7 avec un modèle premium — le même que celui qui coûte 200 à 400€/mois en API classique — pour le prix d’un abonnement Netflix.

La configuration prend 30 secondes :

hermes login --provider openai-codex
hermes model  # sélectionne le provider Codex

C’est tout. Pas de clé API à générer. Pas de facturation à l’usage. Pas de surprise à 400 balles en fin de mois.

Si tu montes ton propre agent, fais ça. C’est le meilleur rapport qualité/prix qui existe aujourd’hui pour alimenter un agent IA personnel.

Ce que j’automatise vraiment

Assez de théorie. Voici ce que mon agent fait concrètement, sans bullshit.

Du code sans être devant un terminal

Je ne parle pas de « vibe coding » où tu génères une app sans rien comprendre. Je parle de délégation : je décris une feature, l’agent explore le codebase, propose une implémentation, je review, je valide ou je corrige. C’est du pair programming asynchrone.

L’agent a aussi le contexte de mon environnement — mes conventions de nommage, mes préférences de déploiement, mes choix d’architecture. Il ne repart pas de zéro à chaque session.

Des rappels et des notes

« Rappelle-moi d’appeler Mamadou demain 10h. » « Ajoute à ma liste de courses : bananes, skyr, thon. » « Qu’est-ce que j’avais noté sur le projet EVA la semaine dernière ? »

Pas besoin d’ouvrir une app de notes. Pas besoin de chercher dans 12 fichiers. L’agent a une mémoire persistante. Il sait.

Du contenu pour mon blog

Cet article, par exemple. J’ai brainstormé le plan avec l’agent, il a challengé mes angles, proposé des structures, vérifié les faits, relu le ton. J’ai écrit chaque mot. Mais le processus était 4x plus rapide parce que je n’étais pas seul face à une page blanche.

Des résumés vocaux

Je fais générer un résumé audio de mes notes de la journée. Je l’écoute en marchant, en cuisinant, en conduisant. C’est un TTS local qui tourne sur CPU (NeuTTS, ~200 Mo). Gratuit. Zero latence réseau. Et ça transforme des temps morts en temps utile.

Les petites décisions chiantes

« Est-ce que cette offre VPS est bonne par rapport au marché ? » « Vérifie la cohérence de cette config Ansible. » « J’ai combien de conteneurs qui tournent sans monitoring ? »

Des trucs que je pourrais faire moi-même en 5 minutes, mais que je ne fais jamais parce que c’est chiant. Maintenant, c’est fait.

10 minutes pour commencer

Si t’as un VPS, un serveur local ou un Raspberry Pi qui traîne, voici le chemin le plus court :

# 1. Installation (une commande)
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

# 2. Configuration guidée
hermes setup

# 3. Connecte Telegram (ou Discord, WhatsApp, Slack...)
hermes gateway setup telegram

# 4. Optionnel mais recommandé — le hack Codex
hermes login --provider openai-codex
hermes model  # choisis le provider Codex dans le menu

# 5. Lance le gateway
hermes gateway run

Envoie un message à ton bot Telegram. Il répond. C’est fini.

Pour que ça survive aux redémarrages :

hermes gateway install  # installe le service systemd
systemctl --user enable --now hermes-gateway

Ton agent tourne. 24/7. Prêt à apprendre.

Ce qui change vraiment

Le changement n’est pas technique. Il est mental.

Avant, j’exécutais des commandes. Maintenant, j’exprime des intentions. La différence est subtile mais fondamentale. Quand t’exécutes une commande, t’es dans le pas-à-pas. Quand t’exprimes une intention, t’es dans le résultat.

Et le plus surprenant, c’est que l’agent s’améliore tout seul. Pas au sens marketing du terme — au sens littéral. Les skills s’accumulent. La mémoire s’affine. Les réponses deviennent plus pertinentes. Au bout d’un mois, tu ne poses plus les mêmes questions qu’au début. Tu poses des questions plus complexes. Parce que les basiques, l’agent les gère sans toi.

C’est ça, le vrai shift. Pas « j’ai un assistant IA. » Plutôt « j’ai délégué la tuyauterie à un processus qui apprend à la faire mieux que moi. »

Et une fois que t’as goûté à ça, revenir à CTRL+R dans ton historique bash, c’est comme retourner au fax après avoir découvert l’email.

L’agent dont je parle dans cet article, c’est Hermes Agent, un projet open source de Nous Research. Si tu veux tester, l’install prend 5 minutes sur n’importe quelle machine Linux.