Hermes Agent et alternatives à OpenClaw : quel agent choisir ?

Pour choisir entre Hermes Agent et les autres alternatives à OpenClaw, partez du problème à résoudre : installation, maintenance, permissions ou hébergement. Ces 7 projets ne répondent pas au même besoin : NanoClaw privilégie le cloisonnement, ZeroClaw simplifie l'environnement d'exécution et OpenHands s'adresse aux équipes d'ingénierie. NemoClaw peut, lui, modifier la manière dont OpenClaw s'exécute sans le remplacer.

Informations vérifiées dans les dépôts et la documentation des projets le 11 novembre 2026. Ce comparatif repose sur leur documentation, sans test avec connexion à un compte ni audit de sécurité. Les dates ci-dessous correspondent à la dernière version publiée dans chaque dépôt ; les fonctionnalités décrites suivent la documentation actuelle du code source, qui peut être en avance sur la version distribuée.

Si la migration n'est pas encore décidée, commencez par le test d'OpenClaw : il vous aidera à distinguer une fonctionnalité manquante d'un choix de déploiement que vous pourriez modifier.

Hermes Agent et les alternatives à OpenClaw en un coup d'œil

Partez de l'usage à conserver. Un assistant de messagerie, un assistant de bureau et un centre de pilotage pour l'ingénierie répondent à des besoins distincts, même si tous peuvent exécuter des commandes.

Lisez surtout ce second tableau avant d'autoriser l'accès à des fichiers ou à des comptes. Un bac à sable limite ce que le code peut atteindre pendant son exécution. Une demande d'approbation détermine si une action peut démarrer.

L'historique des tags NemoClaw contient la note de version actuelle du produit. La page GitHub Releases affiche, elle, une préversion de la chaîne d'outils CI datée du 1 octobre 2026. Il ne s'agit pas de la version actuelle de l'application.

Ces projets sont des logiciels libres : le coût de fonctionnement vient du modèle et de la machine, sans frais de licence logicielle. Le détail des coûts d'OpenClaw explique cette distinction.

Quatre recommandations rapides

Le déploiement le plus léger : ZeroClaw. Choisissez son binaire précompilé unique si vous voulez éliminer les dépendances d'exécution. Ce jugement porte sur le conditionnement du logiciel, sans classement fondé sur des mesures de RAM ; un modèle local ou un navigateur peut toujours représenter l'essentiel des besoins de la machine.

Le meilleur choix de sécurité selon l'architecture de cloisonnement documentée : NanoClaw. Pour remplacer un assistant personnel de messagerie, son isolation par conteneur et sa passerelle d'identifiants externe offrent ici les arguments les plus solides par défaut. Cette recommandation reste limitée à la conception : elle ne prouve pas que NanoClaw comporte moins de vulnérabilités que tous ses concurrents.

L'option locale la plus accessible sans savoir développer : Goose. Son application de bureau native évite de faire du terminal votre interface quotidienne. Modifiez son mode d'approbation avant de lui confier du travail ; une prise en main facile ne signifie pas des accès restreints.

Le choix pour une équipe d'ingénierie : OpenHands. Son centre de pilotage convient au travail sur les dépôts et aux automatisations utilisant différents backends. Pour une équipe opérationnelle non technique qui ne peut pas s'auto-héberger, consultez plutôt la section sur les services hébergés ci-dessous.

Quel outil éliminera votre principal point de blocage ?

Hermes Agent : garder l'assistant personnel, changer son socle

Hermes Agent est l'agent personnel de Nous Research, conçu pour la mémoire persistante, les compétences réutilisables et les tâches planifiées. Il convient à qui veut un assistant capable de retenir ses préférences et de poursuivre des tâches d'une conversation à l'autre, sans repartir de zéro à chaque échange. Un fondateur travaillant seul pourrait l'utiliser pour des notes de recherche récurrentes, tout en conservant les consignes qui les rendent utiles. Choisissez-le pour cette continuité ; ne comptez pas sur lui pour supprimer vos responsabilités d'hébergement.

Pour qui : Ceux qui accordent de l'importance à la mémoire et aux procédures d'un assistant personnel.
Point fort : Des compétences acquises et une procédure d'import depuis OpenClaw documentée.
Responsable du projet et licence : Nous Research ; MIT.
Déploiement : Linux, macOS, Windows natif ou WSL2 ; backends d'exécution locaux et distants.

Le dépôt Hermes documente un outil officiel d'import des paramètres, souvenirs et compétences d'OpenClaw. Il permet de prévisualiser la migration ; le transfert des secrets exige une option explicite. C'est plus utile qu'une promesse générale de compatibilité : vous pouvez examiner ce qui sera transféré avant d'autoriser le nouvel agent à agir.

Sa documentation de sécurité distingue l'autorisation des utilisateurs de messagerie, la validation des commandes dangereuses et l'isolation par conteneur. Le backend d'exécution compte. Choisir un backend local ne revient pas à choisir Docker ; quant aux listes d'autorisation des plateformes, elles déterminent qui peut parler à l'agent, sans définir ce à quoi il peut accéder une fois l'utilisateur admis.

Pour un rapport hebdomadaire, importez d'abord les consignes et des données d'exemple. Laissez l'exécution planifiée désactivée tant que vous ne comprenez pas comment se manifestent les actions refusées. D'après la documentation, les commandes dangereuses sont refusées par défaut dans les contextes sans surveillance et cron : une tâche peut donc s'arrêter là où une session interactive demanderait une validation.

OpenClaw ou Hermes : quand la migration en vaut-elle la peine ?

Changez d'outil si la mémoire, les procédures réutilisables ou l'import résolvent un problème quotidien. Si le seul souci est un espace de travail trop vaste, corrigez son périmètre et celui de l'exécution avant de supposer qu'un autre agent fera mieux. Le comparatif détaillé entre Hermes Agent et OpenClaw approfondit ce choix précis.

NanoClaw : faire du conteneur le point de départ

NanoClaw est un assistant orienté messagerie qui exécute les agents dans des conteneurs Docker. Son code actuel est maintenu au sein de l'organisation nanocoai, vers laquelle redirige l'ancien dépôt qwibitai. Pour qui souhaite un assistant de chat travaillant dans un dossier volontairement limité, son architecture est plus facile à appréhender que l'accès à un poste de travail entier. La contrepartie tient à la maintenance : personnaliser l'outil implique souvent de modifier son propre fork.

Pour qui : Les utilisateurs d'agents personnels ou de groupes clairement séparés, avec un accès limité aux fichiers.
Point fort : Des montages explicites et une passerelle d'identifiants extérieure à l'agent.
Responsable du projet et licence : nanocoai et les contributeurs de NanoClaw ; MIT.
Déploiement : macOS ou Linux, ou Windows via WSL2, avec Docker.

Le dépôt actuel de NanoClaw décrit un hôte Node et le Claude Agent SDK comme fournisseur d'agent par défaut. Des compétences pour les canaux et les fournisseurs alternatifs permettent d'ajouter les éléments nécessaires. La dernière version portant un tag précède le README v2 actuel : suivez les instructions correspondant au code que vous installez, sans considérer chaque fonctionnalité du code source actuel comme une garantie de la version publiée.

Le modèle de sécurité de NanoClaw présente les conteneurs comme la principale frontière d'isolation. Les agents s'exécutent sans privilèges root et voient les répertoires montés. Les montages supplémentaires exigent une liste d'autorisation externe que les agents ne peuvent pas modifier. Les véritables identifiants d'API restent hors des conteneurs et sont injectés par la passerelle d'identifiants.

Pour préparer un assistant de reporting commercial, exposez donc un dossier d'export restreint plutôt que le répertoire personnel de l'utilisateur. Prévoyez des espaces de travail distincts pour les groupes dont les informations doivent rester séparées. Les sessions d'un même groupe d'agents partagent la mémoire de ce groupe : une nouvelle conversation ne crée pas automatiquement une nouvelle frontière de confidentialité.

Nanobot : choisir Python pour adapter son agent

Nanobot est le framework d'agent personnel Python de HKUDS, avec des interfaces navigateur, terminal et applications de chat. Il s'adresse aux profils techniques qui veulent examiner et étendre le système chargé des rapports, des fichiers et des tâches planifiées. Un petit projet d'automatisation interne peut commencer dans un répertoire d'essai, avec une tâche documentaire bien délimitée. Choisissez-le parce que Python et son workflow vous conviennent ; la concision du code ne prouve pas sa sécurité.

Pour qui : Un profil technique habitué à Python, qui maintient un agent personnel ou interne.
Point fort : Gestion des fichiers, mémoire et planification avec une interface navigateur.
Responsable du projet et licence : HKUDS et contributeurs ; MIT.
Déploiement : Python sur macOS, Linux ou Windows.

Le détail décisif se trouve dans la référence de configuration de Nanobot : les paramètres généraux par défaut indiquent que la restriction à l'espace de travail est désactivée et que le réglage du bac à sable shell est vide. Le projet sélectionné dans le navigateur et le mode d'accès comptent aussi. Examinez la configuration effective au lieu de supposer que l'ouverture d'un projet y enferme tous les outils.

En production, les responsables recommandent de combiner la restriction à l'espace de travail avec un bac à sable shell : Bubblewrap sur Linux ou Seatbelt sur macOS. Ces backends shell limitent l'accès au système de fichiers, sans restreindre le réseau. Sur Windows, la documentation indique que les commandes shell s'exécutent sans bac à sable au niveau de l'OS, avec un avertissement.

Un prototype destiné aux opérations financières exige donc de décider séparément quels fichiers sont lisibles et quels services sont joignables. Le droit de lire un rapport ne justifie pas de donner à l'agent les identifiants permettant de modifier le système comptable. Commencez avec des copies des données d'entrée et examinez le résultat avant de connecter des comptes professionnels.

ZeroClaw : alléger l'exécution, sans éluder les permissions

ZeroClaw est un environnement d'exécution d'agent personnel distribué sous la forme d'un binaire Rust unique. C'est ici le choix le plus adapté si votre problème vient de l'empilement des environnements de langage et des services autour de l'agent. Un utilisateur de homelab peut employer le binaire précompilé et garder une configuration explicite du fournisseur, des canaux et de l'espace de travail. Il faut toujours quelqu'un qui comprenne ces réglages.

Pour qui : Un utilisateur à l'aise techniquement qui veut simplifier le déploiement de l'environnement d'exécution.
Point fort : Un binaire natif précompilé, sans environnement Node ni Python.
Responsable du projet et licence : ZeroClaw Labs et communauté ; MIT OR Apache-2.0.
Déploiement : Linux, macOS et Windows, avec des guides pour d'autres plateformes.

Le dépôt ZeroClaw décrit une autonomie supervisée par défaut : les opérations à risque moyen exigent une approbation et celles à risque élevé sont bloquées. Il documente aussi un tableau de bord, des canaux de messagerie et des workflows déclenchés par des événements. L'outil peut donc remplacer un assistant toujours actif, au-delà d'une simple fenêtre de chat dans un terminal.

Lisez les règles de sélection du bac à sable avant de considérer votre installation comme isolée. Avec l'environnement natif, la sélection automatique peut aboutir à une absence de bac à sable au niveau de l'OS si les vérifications des backends disponibles échouent. La version Linux standard n'intègre pas tous les backends de bac à sable facultatifs cités dans la liste générale des fonctionnalités.

Ce point peut inverser la recommandation : si vous savez vérifier la frontière active, le conditionnement de ZeroClaw est séduisant. Si vous voulez un cloisonnement évident dès le départ, sans étudier la disponibilité des backends, NanoClaw constitue un choix plus clair pour un agent personnel.

NVIDIA NemoClaw : garder l'agent, changer son périmètre d'exécution

NVIDIA NemoClaw est une pile de référence pour exécuter les agents compatibles dans les bacs à sable NVIDIA OpenShell. C'est la piste à étudier si les fonctions de votre agent vous conviennent, mais que vous avez besoin d'une autre couche d'exécution et de politique réseau. OpenClaw reste son agent par défaut ; la documentation actuelle mentionne aussi Hermes et LangChain Deep Agents Code. Le présenter comme un simple remplaçant d'OpenClaw passe à côté de sa vocation.

Pour qui : Un responsable d'infrastructure qui évalue les politiques encadrant un agent compatible.
Point fort : Gestion du cycle de vie des bacs à sable et des politiques réseau et d'inférence.
Responsable du projet et licence : NVIDIA ; Apache-2.0.
Déploiement : Linux ; macOS Apple Silicon et Windows WSL2 avec des limites documentées.

Ses prérequis de plateforme en font un choix d'exploitation plus engageant que l'installation d'un petit binaire. Le dépôt présente le projet comme une version alpha et indique que les responsables répondent dans la mesure de leurs moyens. La notoriété d'un fournisseur ne vaut pas contrat de support en production.

La référence des politiques réseau décrit une base fondée sur une liste d'autorisation et des décisions de l'opérateur pour les destinations non répertoriées. Les identifiants d'inférence gérée restent hors du bac à sable. Mais le niveau choisi modifie le périmètre : Personal autorise un accès réseau étendu et peut laisser sortir les données de l'espace de travail sans validation propre à chaque destination.

Pour un directeur technique, un pilote utile consiste en une intégration limitée aux points de terminaison explicitement nécessaires. Consignez le niveau choisi et les préréglages accordés avec le résultat. N'approuvez pas une configuration au seul motif que le mot « sandbox » figure sur son schéma d'architecture. L'explication d'OpenShell détaille la couche sous-jacente.

Goose : adopter le bureau, puis régler les autorisations

Goose est un agent généraliste doté d'applications de bureau natives, d'une interface en ligne de commande et d'une API. Le dépôt actuel appartient à la communauté Agentic AI Foundation au sein de la Linux Foundation ; les anciens liens vers le dépôt Block y redirigent. C'est mon choix d'interface locale pour qui veut de l'aide en recherche, en rédaction ou sur des fichiers sans passer sa vie dans un terminal. Le bureau simplifie l'interaction, mais n'isole pas les outils à lui seul.

Pour qui : Un utilisateur individuel qui souhaite une interface de bureau.
Point fort : Des outils et des approbations configurables dans une application native.
Responsable du projet et licence : Communauté AAIF Goose ; Apache-2.0.
Déploiement : macOS, Linux et Windows.

Le dépôt actuel de Goose documente son modèle de fournisseurs et d'extensions. Les extensions regroupent des outils qui permettent à l'agent d'agir sur des fichiers ou des services connectés. Chaque extension activée modifie les tâches qu'il peut tenter.

Deux déclarations des responsables déterminent si l'outil répond à votre raison de changer. Le guide des modes de permission indique qu'Autonomous est le mode par défaut. Et un correctif à l'annonce du bac à sable macOS précise que ce bac à sable expérimental a été retiré : le serveur qui exécute les outils fonctionne avec les permissions de l'utilisateur, sans bac à sable au niveau de l'OS.

Goose est donc un choix de confort d'utilisation, mais ne convient pas à qui change avant tout pour obtenir un cloisonnement.

1. 1

   Choisir une première tâche limitée

   Utilisez une copie de notes de réunion et demandez un brouillon de liste d'actions. Évitez de commencer par une modification sur un compte réel.

2. 2

   Modifier le mode par défaut

   Dans Settings → Chat → Default Mode, choisissez Manual Approval. Les sessions existantes conservent leur mode : vérifiez aussi celle que vous allez utiliser.

3. 3

   Examiner chaque outil activé

   Dans les permissions des outils de l'extension, sélectionnez Ask Before ou Never Allow selon le besoin. Examinez le brouillon et chaque action demandée avant d'élargir les accès.

Le guide des permissions des outils explique les réglages par outil. Ce sont des règles d'approbation ; elles ne créent pas de bac à sable au niveau de l'OS.

OpenHands : piloter les tâches d'ingénierie depuis un centre de contrôle

OpenHands est un système d'agents d'ingénierie dont le dépôt principal actuel présente Agent Canvas, un centre de pilotage pour les agents et les automatisations. Il convient aux équipes qui délèguent du travail sur les dépôts, le traitement des tickets ou des tâches d'ingénierie récurrentes via différents backends d'exécution. Un responsable de plateforme peut organiser ces travaux séparément de l'assistant personnel de bureau d'un salarié. Si votre besoin initial se limitait à un compagnon de messagerie privé, vous changez de catégorie.

Pour qui : Les équipes d'ingénierie qui délèguent du code et des automatisations.
Point fort : Un centre de pilotage couvrant les backends locaux, distants et cloud.
Responsable du projet et licence : Contributeurs du projet OpenHands ; MIT pour le dépôt comparé.
Déploiement : Sur l'hôte local ou via Docker, sur macOS, Linux et Windows.

Le dépôt OpenHands est particulièrement explicite sur les choix de lancement. L'installation directe exécute le serveur d'agent sur la machine avec un accès complet au système de fichiers. Les lancements Docker offrent un autre périmètre, dont une option attribuant à chaque conversation son propre conteneur.

Les conteneurs par conversation n'isolent pas les services Canvas et d'automatisation qui les entourent. Ils ne séparent pas non plus les fichiers si les conversations montent délibérément le même espace de travail de l'hôte. Pour travailler en parallèle sur des dépôts, des espaces de travail distincts sont donc une exigence opérationnelle, pas un simple choix d'organisation.

Dans une équipe, désignez un responsable des accès aux backends et des points de terminaison exposés avant d'ajouter des collègues. Limitez la première tâche à une copie de dépôt et à un résultat vérifiable. La réussite suppose qu'un responsable puisse examiner la modification et restaurer l'espace de travail ; l'agent ne peut pas se contenter d'annoncer qu'il a terminé.

Permissions et bacs à sable : deux problèmes différents

L'approbation répond à la question « cette action peut-elle s'exécuter ? ». Le bac à sable répond à « à quoi pourra-t-elle accéder une fois lancée ? ». Un agent capable d'écrire des fichiers ou d'exécuter un shell exige une réponse aux deux questions.

Imaginez une armoire de matériel fermée à clé. La clé détermine qui peut l'ouvrir ; son contenu détermine ce qui devient accessible une fois la porte ouverte. Un bouton d'approbation sur un hôte sans restrictions ne réduit pas le contenu de l'armoire.

Avant de migrer, notez les dossiers lisibles, les dossiers modifiables, les services joignables et les identifiants nécessaires à une tâche réelle. Comparez ensuite l'installation envisagée à cette liste. Le guide des agents IA open source élargit la perspective si vos exigences dépassent cette sélection d'assistants personnels.

Des agents hébergés pour éviter l'auto-hébergement

Optez pour un workflow hébergé si le problème est l'exploitation de la machine. Un logiciel open source plus léger laisse toujours à quelqu'un la responsabilité des mises à jour, de la disponibilité et de la remise en service.

Runable : recherche et livrables en service hébergé

Runable convient aux personnes qui veulent mener des recherches, produire des documents ou des présentations, ou créer un site web, plutôt que maintenir un environnement local d'agent. Ses propres pages décrivent aussi des workflows d'assistant personnel via des canaux de communication. Pour un fondateur qui demande une note de recherche et une présentation, cela recoupe une partie significative du travail d'un assistant OpenClaw.

Tarifs : Offre d'entrée gratuite avec 1,500 crédits quotidiens sur la page des tarifs de Runable, consultée le 11 novembre 2026. Les chiffres des offres payantes ne s'affichaient pas de façon fiable lors de la lecture de la page publique : confirmez le montant et la période de facturation avant de vous abonner.

Choisissez-le pour le livrable. Ne présumez pas qu'un agent hébergé conserve l'accès à votre système de fichiers local, vos compétences existantes ou votre configuration exacte de messagerie. Validez précisément le service connecté et le résultat dont vous avez besoin.

Viktor : travailler depuis les conversations de l'équipe

Viktor s'adresse aux équipes opérationnelles qui veulent obtenir des rapports et agir sur leurs outils connectés depuis Slack, Microsoft Teams ou l'e-mail. Son site décrit des approbations d'outils choisies par l'administrateur. Un rapport d'équipe récurrent constitue donc un point de départ plus naturel que d'imposer à chaque salarié la maintenance d'une installation d'agent distincte.

Tarifs : Offre d'entrée gratuite comprenant jusqu'à $100 de crédits sur la page des tarifs de Viktor, consultée le 11 novembre 2026. La page présentait différentes configurations Team payantes : vérifiez le montant choisi au paiement, sans considérer un prix affiché comme un tarif de départ universel.

La limite essentielle est le contexte partagé. La FAQ publique de Viktor indique que l'espace de travail partage une instance et un contexte, et déconseille les informations personnelles sensibles dans les messages privés. Un espace hébergé ne constitue pas automatiquement un ensemble d'assistants personnels privés. Choisissez-le pour du travail d'équipe partagé ; écartez-le si vous exigez une séparation stricte de la mémoire par utilisateur.

Comment cette sélection a été établie

Le comparatif repose sur quatre critères : le projet conserve-t-il l'usage recherché, qui le maintient, quels accès sa configuration documentée accorde-t-elle, et existe-t-il un dépôt actif avec un historique de versions ? Les sept projets demandés disposaient de sources officielles actuelles ; aucun n'a donc été remplacé.

La vérification a porté sur la propriété des dépôts, les licences, les plateformes, les listes de versions et les pages de sécurité ou de configuration citées. Une date de publication renseigne sur la maintenance, sans mesurer la fiabilité. La documentation du code source actuel peut décrire des fonctionnalités postérieures à une version, notamment lorsque le README le précise : fixez la version retenue avant de transformer ce comparatif en plan d'installation.

Aucun compte n'a été utilisé et aucun agent n'a été déployé. Les recommandations sont des appréciations fondées sur les périmètres documentés, sans mesure des performances ni classement des vulnérabilités.

Les choix à écarter selon votre besoin

Écartez Goose si vous changez pour obtenir un cloisonnement intégré au niveau de l'OS. Son confort sur le bureau est utile, mais ses responsables indiquent explicitement que le serveur d'outils fonctionne sans bac à sable.

Écartez NemoClaw si vous voulez cesser d'exploiter de l'infrastructure. Il modifie l'exécution des agents compatibles et ajoute des mécanismes de gestion du cycle de vie. Il reste aussi en version alpha.

Écartez une configuration de Nanobot ou de ZeroClaw que vous n'avez pas examinée si vous exigez une isolation garantie du shell. Tous deux documentent des réglages ou des mécanismes de repli qui rendent l'installation effective décisive.

Écartez OpenHands pour remplacer un simple assistant personnel de chat. La complexité de son centre de pilotage d'ingénierie se justifie uniquement si vous avez besoin de ces fonctions.

Pour passer à l'action dès lundi, voyez petit : choisissez le projet qui élimine votre principal blocage, copiez une donnée d'entrée peu sensible dans un espace dédié et exigez un résultat vérifiable. N'élargissez les accès que lorsque ce workflow le nécessite.

Consultez la carte des outils IA pour dirigeants pour situer l'agent choisi dans l'ensemble de votre workflow.

Questions fréquentes

Quelle est la meilleure alternative à OpenClaw ?

NanoClaw est ici le choix le plus solide pour un agent personnel de messagerie dont le cloisonnement est au cœur de la conception. Hermes Agent convient à la mémoire persistante et aux compétences, ZeroClaw à un déploiement simplifié et OpenHands au travail d'ingénierie. Choisissez l'usage et le périmètre d'exécution avant le nom.

Existe-t-il des alternatives plus sûres à OpenClaw ?

Plusieurs projets documentent des mécanismes de cloisonnement et de permission qui méritent d'être évalués, sans que cela établisse un classement universel de sécurité. Comparez l'environnement d'exécution réel, les montages de fichiers, les identifiants, la politique réseau et les approbations par défaut. Les conteneurs de NanoClaw et les politiques OpenShell de NemoClaw répondent à des besoins de déploiement différents.

Y a-t-il une alternative plus simple à OpenClaw ?

Goose est le choix de bureau local si vous voulez une interface graphique et savez gérer les permissions des outils. Si vous ne voulez entretenir aucun serveur, Runable convient à la recherche et aux livrables hébergés, tandis que Viktor s'adresse aux tâches partagées en entreprise. Confirmez le workflow et le périmètre des données avant de migrer.