Hermes Agent vs OpenClaw : deux paris architecturaux

Deux projets, même niche

Les deux occupent la même niche : un agent persistant, self-hosted, model-agnostic, branché sur les applications de messagerie courantes (Telegram, Discord, Slack, WhatsApp, etc.), capable d'exécuter des outils sur la machine hôte et de conserver un état d'une session à l'autre. Tous deux sous licence MIT, tous deux populaires, tous deux en évolution quasi-quotidienne. Hermes propose d'ailleurs une migration automatique depuis un setup OpenClaw existant — la concurrence est explicite.

Quelques repères au moment de la rédaction :

Au-delà des chiffres, ce qui sépare réellement les deux projets, c'est leur centre de gravité. Le reste — mémoire, skills, sécurité, identité — découle de ce choix initial.

Un control plane, ou une boucle d'agent

Les deux projets ne sont pas des variations sur le même thème : ce sont deux architectures aux priorités opposées, et c'est le point à intérioriser avant de regarder le reste.

OpenClaw est un Gateway qui héberge un agent. Un daemon Node.js long-running concentre l'ensemble des responsabilités : bridges vers les messageries (Baileys pour WhatsApp, grammY pour Telegram, etc.), command queue, session manager, exécution des outils, authentification, sandboxing, hooks, scheduler cron. Le runtime d'agent embarqué est un module parmi d'autres dans cette machinerie, exposé par WebSocket. Tout transite donc par le Gateway, qui fonctionne en single-writer par session. À la lecture du code, cette architecture donne un contrôle fin sur le routage et l'isolation, au prix d'une complexité concentrée dans le control plane.

Hermes est un agent qui expose des interfaces. La classe AIAgent constitue le moteur d'orchestration synchrone, et les autres composants gravitent autour : le gateway de messagerie n'est qu'un adaptateur, le cron n'est qu'un déclencheur, l'ACP (Agent Communication Protocol pour les éditeurs) n'est qu'une surface. Le même AIAgent alimente CLI, gateway, cron et batch. La complexité réside dans la boucle d'agent elle-même — son cycle « do, learn, improve » est le sujet du projet, pas une fonctionnalité parmi d'autres.

gateway qui héberge un agent · agent qui expose ses interfaces

Le reste se déduit de là. OpenClaw est plus riche en profondeur de surface : système de Nodes pour piloter caméras, écrans et GPS de devices physiques (sans équivalent côté Hermes), Heartbeat actif dans la session principale, sandboxing Docker granulaire. Hermes est plus riche en mécanismes d'apprentissage : self-evaluation checkpoints, auto-création de skills, projet d'évolution offline. Côté nombre de plateformes de messagerie couvertes, Hermes communique sur 20+ surfaces, OpenClaw sur une demi-douzaine de canaux principaux. Aucune des deux n'est intrinsèquement supérieure — elles résolvent des problèmes différents avec les mêmes briques.

Deux philosophies orthogonales

C'est là que les choix divergent le plus, et c'est ce qui détermine concrètement le comportement de l'agent session après session. Les deux empilent des couches, mais avec des priorités d'optimisation opposées.

OpenClaw — le workspace markdown comme source de vérité

L'agent OpenClaw vit dans un workspace : un répertoire markdown versionnable (git-backable), avec un ensemble de fichiers attendus à des emplacements précis.

L'ensemble de ces fichiers est relu au démarrage de chaque session, tronqué à bootstrapMaxChars (20 000 par défaut) pour préserver le budget de prompt. Le MEMORY.md n'est chargé qu'en session privée principale — jamais en contexte de groupe, par choix de cloisonnement. Les logs memory/YYYY-MM-DD.md du jour courant et de la veille sont également injectés.

Par-dessus, un slot mémoire pluggable héberge un seul provider à la fois. L'issue #60572 du repo propose de le rendre multi-slot, débat en cours dans la communauté. Les providers disponibles :

Le pattern le plus intéressant : le pre-compaction memory flush. Quand la session approche de la limite de contexte, un silent agentic turn se déclenche, qui rappelle au modèle d'écrire les notes durables dans memory/YYYY-MM-DD.md avant que l'auto-compaction ne réécrive l'historique. Le modèle répond NO_REPLY (sentinelle filtrée du payload sortant), et cette turn n'est jamais visible côté utilisateur.

Hermes — la mémoire à trois niveaux (plus une quatrième cachée)

Hermes décrit officiellement sa mémoire comme trois couches, mais il s'agit en réalité de trois mécanismes orthogonaux avec des fréquences de mise à jour différentes — la simplification pédagogique en cache le vrai dimensionnement.

Tier 1 — la mémoire gelée (~/.hermes/MEMORY.md + USER.md). Deux petits fichiers markdown, plafonnés respectivement à environ 2 200 et 1 375 caractères (chiffres communiqués par Akshay Pachaar à partir de l'observation du code). MEMORY.md stocke les faits, USER.md le modèle de l'utilisateur. Les deux sont curés par l'agent lui-même.

C'est le frozen-snapshot pattern. Conséquence opérationnelle : une modification de la mémoire en cours de session ne prend effet qu'au prochain démarrage — il ne s'agit pas d'un bug mais d'un choix délibéré, pour préserver le prompt caching. Sans cette stabilité, le cache est invalidé à chaque turn et le coût d'inférence augmente d'un ordre de grandeur (≈90% des tokens en cache hit représentent autant d'économies).

Tier 2 — la SessionDB (~/.hermes/state.db). Une base SQLite en mode WAL avec index plein-texte FTS5. Chaque tour de conversation passé y est stocké. L'agent l'interroge à la demande via l'outil session_search, et un résumeur LLM condense les résultats avant réinjection dans la boucle de raisonnement. C'est la mémoire épisodique : « qu'a-t-on fait la dernière fois ».

Tier 3 — provider de mémoire enfichable. Il s'agit d'un swap-in, pas d'une couche supplémentaire : un seul provider est actif à la fois, via une interface MemoryProvider. Les options sont Honcho (modélisation utilisateur profonde), mem0 ou supermemory (rappel vectoriel). Ou rien si fichiers + FTS5 suffisent.

Tier 4 — les skills comme mémoire procédurale. Couche que Hermes ne nomme pas comme telle, mais qui en est mécaniquement une : ~/.hermes/skills/ stocke des SKILL.md qui encodent des procédures, pas des faits. C'est la grande spécificité du projet, détaillée en section suivante.

deux régimes d'inférence : invalidation cache vs cache hit

Ce que cela change concrètement

L'asymétrie d'optimisation est nette, en tout cas à la lecture du code et des choix de plafonds. OpenClaw semble optimiser pour la lisibilité humaine et l'auditabilité : workspace en clair, git diff sur la mémoire, possibilité d'édition manuelle. Hermes semble optimiser pour le coût et la prévisibilité d'inférence : prompt cache-stable, mémoire active minimale, retrieval on-demand pour le reste. Aucun des deux projets ne formule ce trade-off en ces termes dans sa doc — c'est mon interprétation, à challenger.

Ni l'un ni l'autre n'est strictement supérieur. C'est un compromis : ce que Hermes gagne en cache hit ratio, OpenClaw le gagne en transparence et en capacité d'intervention manuelle.

Runbooks humains, ou procédures auto-générées

Les deux projets respectent le format ouvert agentskills.io (SKILL.md avec frontmatter YAML), donc côté schéma l'interopérabilité est possible. C'est dans la provenance des skills que tout se joue.

OpenClaw : les skills sont des runbooks rédigés à la main. La résolution suit une priorité workspace → managed → bundled. Le chargement est lazy : seule une métadonnée compacte (nom, description, chemin) est injectée dans le prompt — environ 97 caractères additionnés à la longueur des champs par skill. Le modèle est instruit à read la SKILL.md seulement quand la tâche correspond. L'écosystème communautaire est massif : un recensement publié par Data Science Collective en avril 2026 estimait à environ 44 000 le nombre de skills publiées, dont ~5 400 vérifiées dans awesome-openclaw-skills — chiffres communautaires à prendre comme ordre de grandeur, l'écosystème grandit trop vite pour qu'un compte exact ait du sens. Il s'agit d'une documentation paginée à la demande.

Hermes : les skills peuvent être auto-générées par l'agent lui-même, en plus d'être rédigées manuellement ou installées depuis le Skills Hub. C'est le mode auto-génératif qui constitue la véritable spécificité du projet :

Cette boucle justifie la formule marketing « the agent that grows with you ». Et l'effet est tangible — après quelques semaines d'usage, le répertoire skills/ accumule effectivement des procédures qu'aucun humain n'a rédigées.

Fait observé par la communauté : l'agent tend à l'auto-congratulation. Le même système qui auto-génère des skills peut écraser des customisations manuelles par des versions de moindre qualité, le modèle jugeant souvent avoir bien performé y compris quand ce n'est pas le cas. Les retours communautaires sur ce point sont nombreux et convergents (issues GitHub Hermes, threads royosherove, posts Akshay Pachaar), même si je n'ai pas vu de mesure quantitative publiée.

La parade officielle est hermes-agent-self-evolution, un repo companion qui implémente une pipeline DSPy + GEPA (Genetic-Pareto Prompt Evolution, dont le papier de référence est ICLR 2026 Oral) en offline. Au lieu de demander à l'agent une auto-évaluation, GEPA lit les execution traces pour identifier les causes d'échec, et propose des améliorations ciblées par recherche évolutionnaire. L'outil est efficace, mais constitue une couche supplémentaire à opérer.

Côté gestion : hermes curator pin <skill> protège une skill de l'archivage et de la suppression, tout en autorisant les patches. Recommandé sur les workflows critiques.

Les trois axes secondaires

Trois axes moins centraux que la mémoire et les skills, mais qui pèsent réellement dans le choix.

Identité

OpenClaw place SOUL.md dans le workspace. La personnalité de l'agent est attachée au projet qu'il habite. Le même OpenClaw lancé sur deux workspaces différents produit deux agents avec deux identités. C'est le modèle « agent comme habitant d'un répertoire ».

Hermes place SOUL.md dans HERMES_HOME (global à l'instance). La personnalité est une propriété de l'agent lui-même, pas du projet. C'est le modèle « un agent unique qui voyage avec son utilisateur ».

Ni l'un ni l'autre n'est intrinsèquement supérieur. Pour une logique de projets séparés, OpenClaw correspond mieux. Pour une logique d'assistant unique, Hermes correspond mieux.

Sécurité

OpenClaw — 7 couches, philosophie operator-driven. Auth Gateway → device pairing & trust → channel allowlists → tool policy (allow/deny global et par-agent) → exec approvals → sandbox Docker (off/non-main/all, workspace ro/rw/none) → send policy. Le system prompt inclut des guardrails advisory, mais l'enforcement réel passe par les couches techniques. La documentation est explicite : l'opérateur est attendu à durcir l'installation.

Hermes — 5 couches, philosophie safer-by-default. User authorization → dangerous-command approval → container isolation → MCP credential filtering → context-file scanning. Extensions associées : protections SSRF, blocklists de sites, filtrage des variables d'environnement, pairing user/messagerie, pre-execution scanning des commandes risquées. La posture par défaut est plus contrainte.

Le débat est philosophique. OpenClaw fait l'hypothèse d'un opérateur compétent et lui laisse le contrôle. Hermes fait l'hypothèse inverse : brider par défaut, laisser l'utilisateur desserrer ce qui le gêne. À mon avis, pour un déploiement sur serveur exposé, Hermes part avec une longueur d'avance. Pour un assistant personnel sur localhost, OpenClaw offre plus de souplesse.

Automation

OpenClaw distingue Heartbeat et Cron. Le Heartbeat est une turn périodique dans la session principale (30 min par défaut), avec un contrat de réponse explicite : HEARTBEAT_OK = rien à signaler (supprimé), tout autre texte = alerte délivrée. Adapté à un usage du type « passe en revue mon contexte et alerte uniquement si quelque chose mérite mon attention ». Le Cron est isolé (session fraîche par run, sans héritage de contexte), adapté à des jobs exacts (push GitHub à 23h, rapport quotidien à 8h).

Hermes dispose d'un Cron unique, mais avec entrée en langage naturel. L'utilisateur formule « tous les soirs à minuit, pousse les changements sur ce repo », et l'agent crée à la fois la skill et le cron job — pas de crontab à éditer. Les sessions cron sont self-contained (incapables de créer d'autres crons, garde-fou anti-runaway). Plus propre côté UX, plus pauvre côté primitives.

Que veut-on faire grandir ?

Le débat « lequel est meilleur » est aussi mal posé que MCP vs CLI. Les deux projets résolvent des problèmes différents avec les mêmes briques, et c'est l'objet de croissance qui doit guider le choix : on accumule de l'infrastructure, ou on accumule des capacités.

Infrastructure d'agent, ou capacités de l'agent ?

Déployer OpenClaw là où les workflows sont assez répétitifs pour gagner à être observés et durcis automatiquement revient à rédiger à la main ce que Hermes auto-générerait. À l'inverse, déployer Hermes là où la transparence de la mémoire, son édition manuelle et la traçabilité git priment revient à subir le frozen-snapshot et à perdre la lisibilité du workspace markdown.

Quelques signaux orientent sans ambiguïté. Exposition serveur multi-utilisateurs, surface d'attaque large, besoin de prévisibilité tour-à-tour → la posture safer-by-default et le cache-stability de Hermes paient. Mémoire auditée, intégration à des devices physiques (caméras, écrans, GPS) via le Node system, présence proactive dans un thread principal via Heartbeat, édition manuelle des procédures → la profondeur de surface d'OpenClaw n'a pas d'équivalent. Quand la décision reste indécise, le critère qui tranche est presque toujours le même : préfère-t-on que ce soit l'opérateur qui durcit, ou l'agent qui s'auto-corrige ?

Si tu dois décider demain

Provenance des chiffres et claims

• Étoiles GitHub, versions, dates de release — relevées sur les repos publics, mai 2026. Ces chiffres bougent vite ; à recouper avant toute décision argumentée.
• ~44 000 skills OpenClaw, ~5 400 vérifiées — recensement Data Science Collective, avril 2026. Métrique d'écosystème, à prendre comme ordre de grandeur (l'inventaire change quotidiennement).
• Plafonds mémoire Hermes (~2 200 / 1 375 chars) — chiffres communiqués par Akshay Pachaar à partir de la lecture du code source. Vérifiables dans le repo public.
• bootstrapMaxChars 20 000 OpenClaw — défaut dans la config officielle, modifiable.
• Pipeline DSPy + GEPA — repo companion hermes-agent-self-evolution. Le papier GEPA (Genetic-Pareto Prompt Evolution) a été présenté en oral ICLR 2026.
• Failure mode d'auto-congratulation — observation communautaire récurrente (issues Hermes, deep-dive royosherove, posts Akshay Pachaar), pas de mesure quantitative publiée à ma connaissance.
• Issue OpenClaw #60572 — débat actif sur le passage à un slot mémoire multi-provider.

Méthodologie : les deux projets évoluent quasi-quotidiennement. Tout ce qui est marqué comme « inférence » dans cet article est ouvert à révision si un mainteneur précise ou contredit une lecture. Les claims marqués « fait » s'appuient sur le code ou la doc à la date de rédaction.