Hermes Agent vs OpenClaw en 2026: analyse approfondie du runtime, de la mémoire et de la conception des agents

Name

Soren Atelier

Mis à jour le 15/04/2026

Si vous ne voulez que la réponse courte, la voici : Hermes Agent n'est pas simplement un autre CLI agentique, et OpenClaw n'est pas juste un autre shell open source pour bots. Les deux projets appartiennent à la grande catégorie des « assistants IA personnels », mais ils cherchent à maîtriser des frontières système différentes. Hermes se rapproche d'un runtime d'agent intégré qui accumule des capacités sur plusieurs surfaces. OpenClaw se rapproche d'un plan de contrôle d'assistant centré sur une gateway, où les canaux, le routage, les sessions et la livraison constituent le cœur du produit.

C'est précisément ce qui rend cette comparaison pertinente aujourd'hui. Le marché des agents ne consiste plus seulement à savoir qui peut montrer la démo de tool call la plus spectaculaire. Il s'agit de comprendre quels postulats de runtime tiennent encore sous la pression opérationnelle réelle, sous des contraintes de facturation concrètes et face à des changements de stratégie produit.

Réponse rapide : faut-il regarder Hermes Agent ou OpenClaw ?

Si vous ne lisez qu'une seule section, lisez celle-ci.

Si vous voulez d'abord un contexte plus large, Best Vibe Coding Tools in 2026 est le bon panorama du marché. Si votre vrai travail se fait dans des notebooks de données plutôt que dans des stacks d'agents généralistes, Jupyter AI RunCell est la lecture la plus pertinente ensuite.

Pourquoi cette comparaison compte beaucoup plus maintenant

Hermes Agent attire l'attention parce que le dépôt avance vite. Au 15 avril 2026, le dépôt officiel NousResearch/hermes-agent affiche environ 87.5k étoiles et 11.9k forks, avec v0.9.0 publié le 13 avril 2026. Rien que cela suffirait déjà à le rendre notable.

Mais Hermes ne monte pas dans le vide. OpenClaw a lui aussi été au centre de plusieurs évolutions qui ont changé la manière d'évaluer les frameworks d'assistant.

Le premier changement est organisationnel. Le 14 février 2026, Peter Steinberger a publié un billet indiquant qu'il rejoignait OpenAI et qu'OpenClaw passerait sous une structure de fondation tout en restant ouvert et indépendant. Cela a immédiatement replacé OpenClaw dans un récit plus large sur la manière dont les laboratoires de pointe envisagent les agents personnels, et pas seulement les API de modèles.

Le deuxième changement est économique et opérationnel. La documentation d'aide actuelle d'Anthropic indique que les abonnements Claude payants sont conçus pour les applications Anthropic natives, y compris Claude sur le web, desktop, mobile et Claude Code. Le même article d'aide précise que la voie recommandée pour les outils tiers est l'accès via clé API ou via un fournisseur cloud pris en charge, et Anthropic se réserve le droit de faire passer une partie de l'utilisation tierce par Extra Usage plutôt que par les limites incluses dans l'abonnement.

Ce changement compte parce que beaucoup d'utilisateurs d'OpenClaw considéraient les abonnements Claude comme un chemin pratique pour des workflows d'agents tiers. En avril 2026, la propre documentation d'OpenClaw sur Anthropic et OAuth reflétait à quel point ce chemin était devenu instable. OpenClaw présente désormais les clés API Anthropic comme la voie la plus claire et la plus prévisible en production, tout en notant aussi que le personnel d'Anthropic a ensuite indiqué que l'usage de type Claude CLI via OpenClaw était à nouveau autorisé. Le résultat n'est pas un récit propre de « bannissement ». La conclusion la plus juste est qu'utiliser Claude via des outils d'agents tiers est devenu nettement moins prévisible, à la fois sur le plan opérationnel et économique.

C'est exactement le genre de moment où les utilisateurs commencent à regarder ailleurs, non pas parce qu'un projet meurt du jour au lendemain, mais parce que les hypothèses qui le sous-tendent deviennent moins stables.

Ce qu'est réellement Hermes Agent

La manière la plus utile de comprendre Hermes Agent n'est pas comme une interface, ni comme un bot. C'est un runtime d'agent basé sur Python, dont les différentes interfaces reposent toutes sur la même boucle centrale.

Cela compte, parce que cela explique pourquoi Hermes paraît inhabituellement cohérent sur des surfaces que d'autres projets traitent souvent comme des produits séparés :

• le CLI
• la gateway de messagerie
• l'intégration ACP pour éditeurs
• la mémoire et le rappel
• les skills
• les automatisations de type cron

Hermes n'est pas juste une application terminal à laquelle on aurait ensuite ajouté une gateway. Il essaie d'être un seul système d'agent avec plusieurs points d'entrée.

Premier mécanisme important : le runner est le centre

Si l'on réduit Hermes à une seule décision de conception, c'est celle-ci : le runner est le centre du système.

La boucle de conversation gère la construction du prompt, la sélection du provider, le dispatch des outils, la compression, les retries et la persistance comme un seul problème cohérent de runtime. Cela a une conséquence architecturale importante. Hermes peut conserver une vision stable de ce qu'est une session, de ce qu'est la mémoire, de ce que sont les outils, et de la manière dont un tour passe de l'entrée à l'appel modèle, puis à l'exécution et à la persistance.

C'est une des raisons pour lesquelles Hermes se distingue de nombreux dépôts « agent » qui sont en réalité des collections de surfaces vaguement liées.

La mémoire dans Hermes n'est pas une fonctionnalité secondaire

Hermes parle beaucoup de mémoire et d'auto-amélioration, mais le point important n'est pas le langage marketing. Le point important est que la mémoire est traitée comme une primitive de runtime.

En pratique, cela signifie que la mémoire intervient dans :

• l'injection de contexte au moment du prompt
• le préchargement avant un tour
• la synchronisation après un tour
• les schémas d'outils sensibles à la mémoire
• les observations de délégation
• les hooks de pré-compression

C'est bien plus profond qu'une simple fonction « enregistrer quelques faits sur l'utilisateur ». Dans Hermes, la mémoire participe à la façon dont le runtime décide ce que le modèle voit et ce que le système conserve.

Ce que signifie réellement « self-improving »

Ce point mérite d'être clarifié, car il est facile de le surinterpréter.

Hermes ne semble pas faire de mises à jour de poids en ligne en direct à l'intérieur d'une session utilisateur. Il ne se réentraîne pas secrètement à chaque conversation.

Ce qu'il fait à la place est beaucoup plus concret :

• il stocke et rappelle du contexte utile
• il accumule des skills procéduraux réutilisables
• il peut orienter des travaux ultérieurs via ces skills
• il peut générer des trajectoires utiles pour l'entraînement et l'évaluation ultérieurs

C'est déjà très significatif. Mais cela relève du runtime learning et de l'accumulation de workflow, pas d'une auto-formation magique en temps réel.

Hermes est optimisé autour du chemin critique

Une autre raison pour laquelle Hermes se démarque est qu'il semble conçu par des personnes qui s'intéressent au comportement runtime, pas seulement au nombre de fonctionnalités.

Deux motifs comptent :

D'abord, le system prompt est structuré pour favoriser la stabilité du cache. L'identité, la mémoire, les skills, les fichiers de contexte et les instructions spécifiques au modèle sont empilés de manière à conserver un préfixe coûteux aussi stable que possible.

Ensuite, la récupération de contexte mémoire et dialectique peut être préchargée au lieu de bloquer systématiquement le tour actif. C'est un signal architectural discret mais important. Hermes ne se demande pas seulement « le modèle peut-il faire cela ? », mais aussi « où faut-il exécuter le travail de contexte coûteux pour que le chemin de réponse reste utilisable ? »

C'est le genre de choix qu'on voit généralement seulement lorsqu'une équipe traite un agent comme une infrastructure.

Hermes traite les outils comme un runtime gouverné

Beaucoup de projets d'agents deviennent difficiles à maîtriser quand le nombre d'outils augmente. Les schémas dérivent, les surfaces divergent, les collisions s'accumulent et l'exécution devient pénible à raisonner.

Hermes essaie d'éviter cela en traitant les outils comme une partie d'un runtime gouverné :

• il existe un registre central
• les outils s'enregistrent sur des schémas et des handlers partagés
• la disponibilité est vérifiée à un seul endroit
• les collisions sont gérées explicitement

L'exécution n'est pas non plus naïvement parallèle. Les lots sûrs peuvent s'exécuter en concurrence, tandis que les opérations destructrices ou qui se chevauchent basculent vers des chemins séquentiels. Ce compromis a de l'importance. Il conserve certains gains de latence sans prétendre que le parallélisme est toujours sûr.

Le point sous-estimé : Hermes est aussi un substrat de recherche

C'est probablement la partie la moins visible du projet de l'extérieur, et l'une des plus importantes.

Hermes n'est pas seulement un runtime d'assistant destiné aux utilisateurs finaux. Sa documentation officielle pour les développeurs relie explicitement son framework d'environnements à des workflows d'entraînement et d'évaluation de type Atropos RL. Les trois usages annoncés sont :

• l'entraînement RL
• les benchmarks
• la génération de données SFT à partir de rollouts d'agents

Cela change la manière dont il faut lire le projet. Hermes ne cherche pas seulement à être un produit d'agent utilisable. Il cherche aussi à devenir un substrat utile pour l'expérimentation sur les agents, l'évaluation et la génération de données d'entraînement.

C'est l'une des raisons les plus fortes pour lesquelles le projet est devenu intéressant si vite.

Alors, en quoi est-ce différent d'OpenClaw ?

À première vue, Hermes Agent et OpenClaw peuvent tous deux ressembler à des stacks d'assistants personnels assez larges. Les deux s'intéressent aux surfaces de messagerie. Les deux s'intéressent aux sessions, aux outils et à des usages réels au-delà d'un simple onglet de navigateur.

Mais leur centre de gravité est différent.

OpenClaw se comprend plus facilement comme une architecture d'assistant centrée sur la gateway. Sa documentation met au premier plan le routage, les clés de session, le comportement des canaux, la livraison sur des plateformes réelles et le comportement de gateway. Même son histoire de tests reflète cela. La documentation officielle d'OpenClaw sur les tests met l'accent sur les suites unitaires, d'intégration, e2e, les smoke tests de gateway live, le comportement des canaux, les surfaces WebSocket et HTTP, ainsi que les évaluations de fiabilité de l'agent autour de la vraie pipeline d'assistant.

Hermes, à l'inverse, ressemble davantage à un runtime unifié qui expose aussi une gateway. Le runner, le système de prompts, le gestionnaire de mémoire, le registre d'outils, l'adaptateur ACP et les environnements de recherche pointent tous dans la même direction : Hermes veut maîtriser toute la frontière du runtime, pas seulement la couche de communication.

C'est la manière la plus claire de les comparer :

Cela ne veut pas dire que l'un est intrinsèquement meilleur. Cela veut dire qu'ils sont meilleurs pour des raisons différentes.

Qu'est-ce qui est vraiment innovant ici ?

L'erreur la plus facile dans une comparaison de ce type est de parler seulement de fonctionnalités.

La question la plus utile est plutôt de savoir sur quoi chaque projet innove réellement.

Pour Hermes, l'élément distinctif n'est pas une fonctionnalité d'interface en particulier. C'est la tentative de faire de l'agent lui-même la frontière cohérente du runtime :

• une seule boucle
• une seule histoire de mémoire
• un seul runtime d'outils
• plusieurs surfaces
• des usages de recherche et de produit réunis sous le même toit

Pour OpenClaw, le caractère distinctif est différent. C'est la manière dont le projet traite l'assistant comme quelque chose qui doit fonctionner de façon fiable sur des canaux réels, une logique de routage réelle, des surfaces de livraison réelles et des contraintes opérationnelles réelles.

C'est pourquoi il ne s'agit pas simplement d'une comparaison de listes de fonctionnalités. C'est une comparaison de philosophies de conception.

Les mauvaises lectures à éviter

Il y a quatre erreurs faciles à faire si l'on survole simplement les dépôts.

1. Hermes n'est qu'un autre CLI pour agent de code

Non. Le CLI n'est qu'un point d'entrée dans un runtime plus large.

2. Hermes apprend en mettant à jour ses poids en temps réel

Non. La boucle d'amélioration repose sur la mémoire, l'accumulation de skills et la génération de rollouts.

3. Hermes est simplement OpenClaw réécrit en Python

Non. Hermes a bien un chemin de migration depuis OpenClaw, mais son architecture runtime a un centre de gravité différent.

4. OpenClaw n'est qu'une enveloppe de bot

Non. La gateway, le routage des sessions, le modèle de canaux et la posture de test d'OpenClaw sont bien plus profonds que cela.

Ces corrections importent, car elles aident les lecteurs à comparer les systèmes au bon niveau.

Un choix plus utile si votre vrai workflow vit dans Jupyter

Il existe encore un angle pratique qu'il est facile de manquer.

Beaucoup de personnes qui comparent des frameworks d'agents larges comme Hermes Agent et OpenClaw ne cherchent pas réellement à construire un assistant généraliste. Elles cherchent à faire du vrai travail dans des notebooks : nettoyer des données, déboguer des cellules, comprendre des DataFrames, relancer des analyses et déterminer ce que les données disent vraiment.

C'est exactement là qu'un outil natif notebook peut compter davantage qu'un runtime d'agent généraliste.

Si votre environnement quotidien est Jupyter, RunCell (opens in a new tab) est un choix beaucoup plus direct. C'est un agent de data science conçu spécifiquement pour les environnements Jupyter, un contexte que la plupart des agents généralistes gèrent encore difficilement. Au lieu de traiter le notebook comme un artefact textuel externe, RunCell travaille à l'intérieur même du contexte notebook, ce qui le rend bien meilleur pour les boucles d'exécution spécifiques aux notebooks, le débogage avec état et l'analyse guidée par les données.

C'est aussi là que le produit se distingue réellement de nombreux agents généralistes :

• il est natif de Jupyter plutôt que natif du terminal
• il est fort sur les tâches notebook qui exigent de comprendre les cellules, les variables, les sorties et les DataFrames
• il est particulièrement utile quand le vrai travail n'est pas de « lancer des outils indéfiniment », mais de « raisonner correctement à partir des données et de l'état du notebook »

Donc, si votre question intérieure n'est pas « quelle runtime d'agent open source dois-je choisir ? », mais plutôt « qu'est-ce qui m'aide vraiment dans un notebook aujourd'hui ? », RunCell est probablement l'option la plus intéressante à essayer en premier.

Si vous voulez une perspective plus spécifique aux notebooks, AI Agent Turns Jupyter Notebook Into a Data Science Co-Pilot est la suite de lecture la plus pertinente. Si vous voulez le contexte plus large du marché des outils de codage, Best AI Coding Tools in 2026 et Best Vibe Coding Tools in 2026 sont les guides compagnons les plus solides.

Guides associés

• Best AI Coding Tools in 2026
• Best Vibe Coding Tools in 2026
• Codex vs Claude Code
• Parallel Code Agents
• Jupyter AI RunCell
• OpenClaw Discord Setup

Sources

• Dépôt officiel de Hermes Agent: https://github.com/NousResearch/hermes-agent (opens in a new tab)
• Documentation d'architecture de Hermes Agent: https://hermes-agent.nousresearch.com/docs/developer-guide/architecture (opens in a new tab)
• Documentation des environnements de Hermes Agent: https://hermes-agent.nousresearch.com/docs/developer-guide/environments/ (opens in a new tab)
• Dépôt officiel d'OpenClaw: https://github.com/openclaw/openclaw (opens in a new tab)
• Billet de Peter Steinberger sur son arrivée chez OpenAI: https://steipete.me/posts/2026/openclaw (opens in a new tab)
• Documentation OpenClaw sur le routage des canaux: https://docs.openclaw.ai/channels/channel-routing (opens in a new tab)
• Documentation OpenClaw sur le provider Anthropic: https://docs.openclaw.ai/providers/anthropic (opens in a new tab)
• Documentation OpenClaw sur OAuth: https://docs.openclaw.ai/concepts/oauth (opens in a new tab)
• Documentation OpenClaw sur les tests: https://docs.openclaw.ai/help/testing (opens in a new tab)
• Article d'aide Anthropic sur la connexion au compte: https://support.claude.com/en/articles/13189465-logging-in-to-your-claude-account (opens in a new tab)
• Article d'aide Anthropic sur Claude Code avec les offres Pro ou Max: https://support.claude.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan (opens in a new tab)
• Article TechCrunch sur la suspension temporaire de Peter Steinberger: https://techcrunch.com/2026/04/10/anthropic-temporarily-banned-openclaws-creator-from-accessing-claude/ (opens in a new tab)

FAQ

Qu'est-ce que Hermes Agent ?

Hermes Agent est un runtime d'agent intégré créé par Nous Research. Il combine un runner partagé avec de la mémoire, des outils, la messagerie, l'intégration ACP, des skills et de l'automatisation sur plusieurs surfaces.

Qu'est-ce qu'OpenClaw ?

OpenClaw est une plateforme d'assistant personnel dont l'architecture est centrée sur une gateway longue durée, le routage des sessions, le comportement des canaux et la livraison sur des surfaces de communication réelles.

Hermes Agent est-il un remplacement direct d'OpenClaw ?

Pas exactement. Hermes et OpenClaw se recoupent suffisamment pour être comparés, mais ils optimisent des frontières système différentes. Hermes est davantage centré runtime, tandis qu'OpenClaw est davantage centré gateway.

Pourquoi cette comparaison compte-t-elle en 2026 ?

Elle compte parce qu'OpenClaw a connu des changements de créateur et d'écosystème, et Anthropic a rendu l'usage de Claude via des outils tiers plus incertain sur le plan économique et opérationnel. Cela pousse davantage d'utilisateurs à réévaluer les stacks d'agents alternatifs.

Hermes Agent est-il vraiment « self-improving » ?

Dans un sens pratique, oui, mais pas via des mises à jour de poids en direct. Sa boucle d'amélioration repose sur la mémoire, des skills réutilisables, du contexte accumulé et la génération de rollouts pour un entraînement et une évaluation ultérieurs.

Quand RunCell est-il un meilleur choix que Hermes Agent ou OpenClaw ?

RunCell est le meilleur choix lorsque votre vrai travail se déroule dans des notebooks Jupyter. Il est conçu pour l'exécution native notebook, le débogage avec état, l'analyse consciente des DataFrames et les workflows de data science.