Plongée en profondeur dans Hermes Agent 2026 : L'agent IA qui s'améliore tout seul et se souvient vraiment de toi

Tu as probablement vu Hermes Agent dans les tendances de GitHub — plus de 73 000 étoiles, et ça monte vite. Développé par Nous Research (le labo derrière les familles de modèles Hermes et Nomos), c'est un agent IA open-source qui tourne sur ton propre matériel. Pas un simple wrapper de chatbot. Pas un plugin d'IDE. Un agent complètement autonome avec de la mémoire, un planificateur de tâches, la capacité d'utiliser des outils, et une boucle d'apprentissage qui s'améliore au fil du temps.

Ce n'est pas un résumé de communiqué de presse. C'est une plongée pratique et détaillée : ce que Hermes fait réellement, comment le configurer, ce qui fonctionne bien, ce qui ne fonctionne pas, et si ça vaut le coup que tu y consacres du temps. Chaque fonctionnalité décrite ici est accompagnée d'un scénario d'utilisation réel que tu peux essayer dès aujourd'hui.

Ce qu'est réellement Hermes Agent

Hermes Agent est un agent IA auto-hébergé qui tourne sur ton serveur (ou ton portable, ou un VPS à 5$) et te parle via un terminal, Telegram, Discord, Slack, WhatsApp, Signal — plus de 15 plateformes depuis un unique processus de gateway. Il utilise le LLM que tu lui indiques : OpenAI, Anthropic, DeepSeek, Nous Portal, OpenRouter avec plus de 200 modèles, ou ton propre endpoint local.

L'argument qui le différencie d'un "énième framework d'agent" : il dispose d'une boucle d'apprentissage fermée. Il se souvient des choses d'une session à l'autre, crée des compétences réutilisables à partir de tâches complexes, améliore ces compétences à l'usage, et construit un profil de qui tu es au fil du temps. La plupart des agents repartent de zéro à chaque conversation. Hermes accumule du contexte.

Il est sous licence MIT, ce qui est important si tu comptes développer par-dessus.

Chiffres clés :

+73 600 étoiles GitHub (en avril 2026)
647 skills répartis dans 4 registres (79 intégrés, 47 optionnels, 521 contribués par la communauté)
Plus de 15 plateformes de messagerie supportées depuis une seule gateway
6 backends de terminal : local, Docker, SSH, Daytona, Singularity, Modal
Exigence de contexte minimum : 64K tokens (les modèles en dessous sont rejetés au démarrage)

Installation : 60 secondes, sans blague

# Installation en une seule ligne — Linux, macOS, WSL2, et même Android via Termux
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

# Recharge ton shell
source ~/.bashrc  # ou : source ~/.zshrc

# Commence à discuter
hermes

L'installeur s'occupe de tout : Python 3.11 (via uv, sans sudo), Node.js v22, ripgrep, ffmpeg. Le seul prérequis est git.

Après l'installation, tu as un ensemble de commandes CLI qui couvrent la plupart de la configuration :

hermes model    # Choisis ton fournisseur de LLM de manière interactive
hermes tools    # Active/désactive des groupes d'outils
hermes setup    # Assistant de configuration complet (fait tout d'un coup)
hermes gateway  # Démarre la gateway de messagerie
hermes doctor   # Diagnostique les problèmes
hermes update   # Mets à jour vers la dernière version

Ça marche aussi sur Android. Termux a un chemin d'installation dédié avec un extra .[termux] spécial qui évite les dépendances vocales incompatibles avec Android. Tu peux littéralement faire tourner un agent IA depuis ton téléphone.

Choisir un fournisseur de modèles

Hermes ne t'enferme chez aucun fournisseur. Lance hermes model et choisis dans la liste :

Fournisseur	Description	Méthode d'auth
Nous Portal	Abonnement, zéro configuration	Connexion OAuth
OpenAI Codex	OAuth ChatGPT, modèles Codex	Auth via Device code
Anthropic	Modèles Claude en direct	Auth Claude Code ou clé API
OpenRouter	+200 modèles, multi-fournisseurs	Clé API
DeepSeek	API directe	Clé API
GitHub Copilot	GPT-5.x, Claude, Gemini via Copilot	OAuth
Hugging Face	+20 modèles open	HF_TOKEN
Custom Endpoint	VLLM, SGLang, Ollama, tout ce qui est compatible OpenAI	URL de base + clé

Et aussi : Z.AI/GLM, Kimi/Moonshot, MiniMax, Alibaba Cloud/DashScope, Arcee AI, et plus encore.

La règle des 64K : Hermes requiert au moins 64 000 tokens de contexte. Les modèles avec moins sont rejetés au démarrage. C'est logique — les workflows d'appel d'outils en plusieurs étapes consomment rapidement le contexte, et une petite fenêtre signifie que l'agent perd le fil de ce qu'il fait au milieu d'une tâche. Si tu utilises un modèle local, configure --ctx-size 65536 ou plus.

Change de fournisseur à tout moment avec hermes model. Pas de changement de code, pas de dépendance.

Le système de mémoire : petit, limité et intentionnel

C'est là que Hermes se différencie de la plupart des frameworks d'agents. Au lieu de tout déverser dans une base de données vectorielle, Hermes utilise deux tout petits fichiers, limités en nombre de caractères :

Fichier	Objectif	Limite
`MEMORY.md`	Notes de l'agent — faits sur l'environnement, conventions, leçons apprises	2 200 car. (~800 tokens)
`USER.md`	Profil utilisateur — tes préférences, ton style de communication	1 375 car. (~500 tokens)

Les deux se trouvent dans ~/.hermes/memories/ et sont injectés dans le system prompt sous forme de snapshot figé (frozen snapshot) au début de la session.

Comment la mémoire fonctionne en pratique :

══════════════════════════════════════════════
MEMORY (your personal notes) [67% — 1,474/2,200 chars]
══════════════════════════════════════════════
Le projet de l'utilisateur est un service web Rust dans ~/code/myapi utilisant Axum + SQLx
§Cette machine tourne sous Ubuntu 22.04, avec Docker et Podman installés
§L'utilisateur préfère les réponses concises, n'aime pas les explications verbeuses

L'agent gère sa propre mémoire via trois actions :

add — Stocker un nouveau fait
replace — Mettre à jour une entrée existante (par correspondance de sous-chaîne)
remove — Supprimer quelque chose qui n'est plus pertinent

Le piège du frozen snapshot : Quand Hermes écrit dans la mémoire pendant une session, les changements sont sauvegardés sur le disque immédiatement — mais ils n'apparaîtront dans le system prompt qu'au début de la session suivante. C'est intentionnel (ça préserve le prefix cache du LLM pour les performances), mais ça veut dire que l'agent peut "oublier" quelque chose qu'il vient d'apprendre si tu continues à parler dans la même session.

Quand la mémoire est pleine, l'agent reçoit une erreur avec les entrées actuelles et les stats d'utilisation, puis il doit consolider ou remplacer des entrées pour faire de la place. C'est comme un humain avec un carnet de seulement 15 lignes — tu apprends à être sélectif sur ce que tu notes.

Quoi sauvegarder vs. quoi ignorer :

✅ Sauvegarder : Préférences utilisateur, faits sur l'environnement, conventions de projet, corrections, modèles de workflow
❌ Ignorer : Infos triviales, faits faciles à rechercher, gros blocs de code, données temporaires spécifiques à la session

Cette approche limitée est rafraîchissante. La plupart des systèmes de mémoire d'agent n'ont pas de limites (et se remplissent de bruit) ou utilisent la recherche vectorielle (qui hallucine sur la pertinence). Hermes impose de la discipline.

Skills : la mémoire procédurale que l'agent crée lui-même

Les skills sont la réponse de Hermes à la question "comment s'améliorer sur des tâches récurrentes ?". Quand l'agent termine une tâche complexe, il peut créer un skill — essentiellement un fichier SKILL.md avec des instructions pour la prochaine fois. Les skills s'auto-améliorent à l'usage.

L'écosystème est étonnamment vaste : 647 skills répartis sur 4 registres. Ceux qui sont intégrés couvrent :

Agents de codage : délégation à Claude Code, Codex, OpenCode
Outils créatifs : art ASCII, art génératif p5.js, animations mathématiques Manim, schémas Excalidraw, diagrammes d'architecture
Intégrations de plateformes : Apple Notes, Apple Reminders, FindMy, iMessage
Trucs amusants : configuration de serveur de modpack Minecraft, joueur de Pokémon (oui, il joue à Pokémon de manière autonome via une émulation headless)
Design : 54 templates de design system de qualité production, extraits de vrais sites web (Stripe, Linear, Vercel, Notion, Airbnb…)

Les skills suivent le standard ouvert agentskills.io, ils sont donc portables et partageables par la communauté.

Scénario réel : Tu demandes à Hermes de configurer une stack Docker Compose pour une application Postgres + Redis + Node. Il le fait, puis crée un skill nommé "docker-compose-setup" avec le template, les pièges courants et les conventions de port qu'il a découverts. La prochaine fois que tu demanderas une stack similaire, il chargera le skill et fera le travail en deux fois moins d'étapes.

Outils : 47 intégrés, organisés par catégorie

Hermes est livré avec un large registre d'outils. Tu actives/désactives des groupes avec hermes tools :

Catégorie	Exemples	Pour quoi faire
Web	`web_search`, `web_extract`	Chercher et scraper le web
Terminal & Fichiers	`terminal`, `process`, `read_file`, `patch`	Lancer des commandes, éditer des fichiers
Navigateur	`browser_navigate`, `browser_snapshot`, `browser_vision`	Automatisation complète du navigateur
Média	`vision_analyze`, `image_generate`, `text_to_speech`	Analyse d'image, génération, TTS
Orchestration d'agent	`todo`, `execute_code`, `delegate_task`	Planification, sous-agents, exécution de code
Mémoire & rappel	`memory`, `session_search`	Mémoire persistante, recherche inter-sessions
Automatisation	`cronjob`, `send_message`	Tâches planifiées, envoi de messages sortants

Activation/désactivation rapide :

# Démarrer avec seulement les outils web et terminal
hermes chat --toolsets "web,terminal"

# Ou configurer de manière interactive
hermes tools

Backends de terminal : exécuter n'importe où, en toute sécurité

C'est l'une des fonctionnalités pratiques les plus solides de Hermes. Tu peux choisir où les commandes terminal de l'agent s'exécutent réellement :

Backend	Cas d'usage
`local`	Défaut — s'exécute sur ta machine
`docker`	Conteneurs isolés — sûr pour les tâches non fiables
`ssh`	Serveur distant — l'agent ne peut pas toucher à son propre code
`daytona`	Sandbox dans le cloud — persistant, hiberne quand inactif
`modal`	Serverless — scalable, paiement à l'usage
`singularity`	Conteneurs HPC — calcul sur cluster sans root

# ~/.hermes/config.yaml
terminal:
  backend: docker
  docker_image: python:3.11-slim
  container_persistent: true  # les paquets survivent entre les sessions
  container_cpu: 1
  container_memory: 5120      # 5GB

Le backend SSH est le juste milieu en matière de sécurité : l'agent travaille sur une machine distante et ne peut littéralement pas modifier son propre code ou sa configuration. Les backends de conteneur (Docker, Singularity, Modal) ajoutent un durcissement supplémentaire : système de fichiers racine en lecture seule, toutes les capacités Linux abandonnées, pas d'escalade de privilèges, limites de PID, isolation complète des namespaces.

Conseil pratique : Si tu fais tourner Hermes sur un VPS et que tu lui donnes de vraies tâches, commence avec le backend docker. Si tu as confiance dans les tâches mais que tu veux une séparation, utilise ssh. N'utilise local que pour le développement ou pour des tâches que tu exécuterais toi-même.

Cron : automatisation planifiée intégrée

Hermes a un planificateur cron intégré. Pas besoin d'outils externes. Crée des jobs en langage naturel ou avec des expressions cron, et les résultats sont livrés sur n'importe quelle plateforme de messagerie.

# Depuis le chat
/cron add "toutes les 6h" "Vérifie les dépôts GitHub tendance en Python et résume les 5 premières nouveautés. Si rien d'intéressant, réponds avec [SILENT]." --name "GitHub watcher" --deliver telegram

# Depuis la CLI
hermes cron create "0 9 * * 1" \
  "Génère un rapport hebdomadaire des meilleures actualités IA, des dépôts ML tendance et des posts HN les plus discutés." \
  --name "Weekly AI digest" \
  --deliver telegram

La chose essentielle à comprendre : les tâches cron s'exécutent dans des sessions d'agent toutes neuves, sans aucune mémoire de ta conversation actuelle. Les prompts doivent être entièrement autonomes. C'est un piège courant — les gens écrivent un prompt cron du style "fais le truc dont on a parlé" et se demandent pourquoi l'agent n'a aucune idée de ce qu'ils veulent dire.

Le paramètre --script est le coup de génie. Tu peux attacher un script Python qui s'exécute avant chaque job. Sa sortie standard (stdout) devient du contexte pour l'agent :

# ~/.hermes/scripts/watch-site.py
import hashlib, json, os, urllib.request

URL = "https://example.com/pricing"
STATE_FILE = os.path.expanduser("~/.hermes/scripts/.watch-state.json")

content = urllib.request.urlopen(URL, timeout=30).read().decode()
current_hash = hashlib.sha256(content.encode()).hexdigest()

# Charger l'état précédent
prev_hash = None
if os.path.exists(STATE_FILE):
    with open(STATE_FILE) as f:
        prev_hash = json.load(f).get("hash")

# Sauvegarder l'état actuel
with open(STATE_FILE, "w") as f:
    json.dump({"hash": current_hash, "url": URL}, f)

if prev_hash and prev_hash != current_hash:
    print(f"CHANGEMENT DÉTECTÉ sur {URL}")
    print(f"Aperçu du contenu :\n{content[:2000]}")
else:
    print("NO_CHANGE")

/cron add "toutes les heures" "Si le script indique CHANGE DETECTED, résume ce qui a changé. Si NO_CHANGE, réponds avec [SILENT]." --script ~/.hermes/scripts/watch-site.py --name "Pricing monitor" --deliver telegram

L'astuce [SILENT] : quand la réponse de l'agent contient [SILENT], la livraison est annulée. Tu n'es notifié que lorsque quelque chose se passe vraiment. Pas de spam.

Gateway de messagerie : parle-lui depuis ton téléphone

hermes gateway setup  # interactif - choisit ta plateforme
hermes gateway        # démarre le processus de la gateway

Hermes supporte plus de 15 plateformes de messagerie depuis une seule gateway : Telegram, Discord, Slack, WhatsApp, Signal, Matrix, Mattermost, Email, SMS, DingTalk, Feishu, WeCom, BlueBubbles, Home Assistant, et Open WebUI.

Exemple de configuration pour Telegram (le plus courant) :

Crée un bot via @BotFather (/newbot)
Récupère ton ID utilisateur via @userinfobot
Lance hermes gateway setup, sélectionne Telegram, colle le token et ton ID utilisateur
Démarre la gateway : hermes gateway

C'est tout. Maintenant tu peux discuter avec ton agent depuis ton téléphone pendant qu'il travaille sur ton serveur.

Les mémos vocaux fonctionnent aussi — envoie un message vocal sur Telegram, Hermes le transcrit automatiquement avec faster-whisper (qui tourne en local, gratuitement) et répond au texte.

Astuce pour les discussions de groupe : Les bots Telegram ont le mode de confidentialité activé par défaut — le bot ne voit que les /commands et les réponses directes. Pour lui permettre de voir tous les messages dans un groupe, tu peux soit désactiver le mode de confidentialité dans BotFather, soit promouvoir le bot en admin.

Intégration MCP : étendre avec des outils externes

Hermes supporte le Model Context Protocol (MCP) — connecte-toi à n'importe quel serveur MCP pour ajouter des outils :

# ~/.hermes/config.yaml
mcp:
  servers:
    - name: "github"
      command: "npx"
      args: ["-y", "@modelcontextprotocol/server-github"]
      env:
        GITHUB_TOKEN: "ton-token"

Les outils MCP apparaissent à côté des outils intégrés. Tu peux filtrer les outils MCP que l'agent peut utiliser pour éviter la surcharge d'outils.

Sécurité : sept couches de profondeur

Hermes a un vrai modèle de défense en profondeur, pas juste un "on a ajouté une demande de validation" :

Autorisation utilisateur — des listes blanches (allowlists) contrôlent qui peut parler à l'agent
Validation des commandes dangereuses — intervention humaine (human-in-the-loop) pour les opérations destructrices (rm -rf, chmod 777, etc.)
Isolation par conteneur — Docker/Singularity/Modal avec des paramètres de sécurité renforcés
Filtrage des identifiants MCP — isolation des variables d'environnement pour les sous-processus MCP
Analyse des fichiers de contexte — détection d'injection de prompt dans les fichiers du projet
Isolation inter-sessions — les sessions ne peuvent pas accéder aux données des autres
Assainissement des entrées — les paramètres de répertoire de travail sont validés par rapport à une liste blanche

Modes de validation :

# ~/.hermes/config.yaml
approvals:
  mode: manual   # manual | smart | off
  timeout: 60    # secondes avant refus automatique

manual (défaut) : Demande toujours avant les commandes dangereuses
smart : Utilise un LLM auxiliaire pour évaluer le risque — approuve automatiquement le risque faible, refuse automatiquement le dangereux, et demande ton avis en cas d'incertitude
off / --yolo : Court-circuite toutes les vérifications. À n'utiliser qu'en CI/CD ou dans des conteneurs jetables.

Le timeout est sécurisé par défaut (fail-closed) : si tu ne réponds pas dans les 60 secondes, la commande est refusée. Pas approuvée. C'est le bon comportement par défaut.

Sous-agents : déléguer et paralléliser

Hermes peut créer des sous-agents isolés pour des flux de travail parallèles :

❯ Fais des recherches sur ces trois sujets simultanément :
  1. Les derniers benchmarks des runtimes async de Rust
  2. Les nouvelles fonctionnalités de PostgreSQL 17
  3. Les meilleures pratiques pour le caching de LLM en production

Chaque sous-agent a sa propre session, ses propres outils et son propre contexte. Les résultats remontent au parent. C'est utile pour les tâches qui sont naturellement parallèles — recherche, traitement par lots, opérations sur plusieurs dépôts.

Tu peux aussi utiliser execute_code pour écrire des scripts Python qui appellent des outils via RPC, ce qui permet de réduire des pipelines en plusieurs étapes à des tours de parole qui ne coûtent aucun token de contexte.

Les vrais inconvénients (la partie honnête)

Tout article qui ne dit que du bien est inutile. Voici ce qui fait vraiment mal :

1. La mémoire est minuscule et demande une gestion active

2 200 caractères pour la mémoire de l'agent. 1 375 pour le profil utilisateur. Ça fait environ 20 courtes entrées au total. Pour un assistant personnel censé "grandir avec toi", atteindre le plafond est frustrant de rapidité. Tu verras l'agent passer des tours de parole à consolider et remplacer des entrées de mémoire au lieu de faire du vrai travail. L'approche limitée est philosophiquement juste, mais en pratique, ça veut dire que l'agent oublie des choses que tu aurais aimé qu'il retienne.

2. Le "Frozen Snapshot" crée un "décalage de mémoire"

Les changements de mémoire pendant une session ne prennent effet qu'à la session suivante. Ça veut dire que si tu dis à l'agent "souviens-toi que je suis passé à PostgreSQL 17", il l'écrit sur le disque — mais si tu lui poses une question sur ta configuration de base de données plus tard dans la même conversation, le system prompt affichera toujours l'ancienne information. L'agent peut vérifier l'état actuel via les réponses des outils, mais il ne pense pas toujours à le faire. Ça mène à des moments déroutants où l'agent semble avoir oublié ce que tu viens de lui dire.

3. Les prompts pour Cron doivent être entièrement autonomes

Chaque tâche cron s'exécute dans une session vierge. Pas de mémoire, pas d'historique de conversation, pas de contexte des exécutions précédentes. Ça veut dire que tes prompts cron doivent tout détailler absolument — quoi faire, comment le faire, quel format de sortie utiliser, où le livrer. Écrire de bons prompts cron est une compétence en soi, et les premières tentatives produisent généralement des résultats inutiles parce que les gens ne sont pas assez précis.

4. Le contexte minimum de 64K exclut les petits modèles locaux

Si tu veux tourner entièrement en local avec un modèle 7B ou 13B, tu n'auras probablement pas de chance, à moins d'avoir la RAM nécessaire pour un contexte de 64K. C'est une décision d'ingénierie raisonnable (petit contexte = boucles d'agent qui cassent), mais ça veut dire que Hermes ne "tourne pas vraiment sur n'importe quoi" — il tourne sur n'importe quoi capable de servir un modèle avec 64K de contexte.

Hermes Agent Review 2026 : L'agent IA qui s'améliore et se souvient vraiment de toi