Hermes vs OpenClaw (2026) : installer l'opérateur ou la passerelle ?

En 2026, deux noms reviennent souvent dans le même fil de discussion outils agents : Hermes et OpenClaw. Le premier est arrivé avec Everything Claude Code (ECC) v2 ; les mainteneurs parlent d’une coque opérateur (operator shell). Le second est déjà, pour beaucoup, la passerelle IA personnelle 7×24 sur un Mac cloud. Les deux peuvent apparaître dans Telegram ou la CLI, mais ils ne visent pas la même classe de problèmes.

Cet article suit un plan net : d’abord Hermes et OpenClaw expliqués chacun en profondeur, puis tableau comparatif et liste de décision pour répondre au titre — installez-vous l’« opérateur » ou la « passerelle » ? Peuvent-ils cohabiter sur la même machine ? Si vous avez lu nos notes ECC vaut-il le coup et jumeau numérique OpenClaw, ce texte est la carte de répartition entre les deux, sans répéter les runbooks d’installation.

1. Qu’est-ce que Hermes ? (coque opérateur + workflows ECC)

1.1 Origine et ligne produit

ECC est une couche open source de performance et d’orchestration pour Claude Code, Cursor, Codex, OpenCode et autres Agent Harness. Les mainteneurs le définissent comme un harness-native operator system : il ne remplace pas les modèles, il équipe les agents de skills, hooks, règles, scans sécurité et optimisation mémoire. Depuis v2.0.0-rc, la ligne opérateur Hermes publique se superpose à cette couche.

Selon le dépôt ECC : « Hermes is the operator shell. ECC is the reusable system behind it. » (Hermes est la coque opérateur, ECC le système réutilisable derrière.) En pratique, Hermes est un front opérateur unifié reliant chat, tâches planifiées et état workspace aux skills, hooks et MCP d’ECC.

Comparer ECC à « un panneau de chat de plus dans l’IDE » rate l’essentiel : Hermes insiste sur le terminal-native — contenu, outreach, recherche, ops commerciales, rapprochements financiers et workflows d’ingénierie dans une même interface opérateur. ECC fournit skills et conventions réutilisables entre harness.

1.2 Architecture : entrée → Hermes → ECC → monde extérieur

La doc publique esquisse cette topologie (conceptuelle) :

Telegram / CLI / TUI → Hermes → skills ECC + hooks + MCP + paquets de workflow générés → Google Drive / GitHub / automatisation navigateur / APIs de recherche / outils média.

Contrairement au seul chat IDE, Hermes centre l’opérateur au poste : une interface pour des classes de tâches parallèles, pendant qu’ECC tient les briques répétables. L’ingénierie peut rester dans Claude Code ou Cursor ; les règles ECC jouent le rôle de porte qualité commune.

1.3 Contenu du workspace public

Le guide Hermes décrit une surface minimale reproductible (sans clés privées ni exports personnels), notamment :

• ~/.hermes/config.yaml : routage modèle, enregistrement MCP, chargement plugins.
• ~/.hermes/skills/ecc-imports/ : skills ECC importés pour appels natifs Hermes.
• skills/hermes-generated/ : motifs opérateur distillés de sessions répétées.
• ~/.hermes/cron/jobs.json : tâches planifiées avec prompt et channel explicites.
• ~/.hermes/workspace/ : artefacts mémoire structurés business, ops, contenu.

v2.0-rc étend des skills operator lane (notes de release : voix de marque, facturation client, Google Workspace, flux projet — liste complète dans le dépôt). L’idée : transformer « réapprendre à l’IA comment faire l’ops » en paquets installables.

Les équipes qui passent des prompts ad hoc à des compétences opérateur versionnées gagnent surtout en prévisibilité : la même checklist du matin déclenche les mêmes hooks le lundi et le vendredi, au lieu de dériver selon le contexte de chat de la veille.

1.4 Scénarios typiques : forces de Hermes

1. SOP d’ingénierie : dans Claude Code « plan → edits multi-fichiers → tests → quality-gate » ; hooks ECC écrivent la mémoire de session, agents reviewer en parallèle — sujet de l’article ECC ; Hermes relie ces capacités à une entrée opérateur.
2. Rythme ops : cron pour readiness, tri boîte mail, accountability contenu — idéal pour « chaque matin la même checklist ».
3. Orchestration multi-outils : MCP vers GitHub, APIs recherche, automatisation navigateur ; moins de copier-coller entre cinq SaaS.

Facturation : la voie Hermes/ECC ressemble à inférence par tâche + I/O outils (agents multi-tours), alignée avec la « taxe d’inférence » dans loi τ et latence agent. Les lourds xcodebuild vont sur un runner Mac cloud, pas seulement sur l’opérateur portable.

1.5 Ce que Hermes n’est pas

• Pas un manuel produit « jumeau numérique » autonome — c’est le récit OpenClaw.
• Ne garantit pas de répondre 7×24 à toutes les IM après installation ; le cron planifie, mais passerelle durable, identité channels, launchd sont le cœur d’OpenClaw.
• Ne remplace pas le harness nu : sans skills/règles ECC, le front Hermes tourne à vide.
• Migration : HERMES-OPENCLAW-MIGRATION.md montre une proximité d’écosystème, mais pas le même binaire.

1.6 Démarrage (chemin court)

Ordre public conseillé : ecc migrate audit sur anciens workspaces → installer ECC et valider les tests → Hermes pointé vers skills ECC importés → enregistrer MCP utiles → quelques jobs cron. Lire le README ECC ; ECC_HOOK_PROFILE=minimal limite le coût des hooks au premier bring-up.

Erreur fréquente le premier week-end : activer trop de cron et de MCP avant qu’un seul workflow d’ingénierie soit vert de bout en bout. Mieux vaut valider un chemin (ex. « PR avec tests »), puis ajouter les lanes ops. La couche opérateur reste auditable quand OpenClaw arrive à côté.

Si vous avez déjà des règles ECC dans le dépôt, voyez Hermes comme entrée supplémentaire qui déclenche les mêmes quality gates, pas comme substitut au review humain. La qualité vient du harness et du CI ; Hermes réduit les changements de contexte entre terminal, chat et outils externes.

2. Qu’est-ce qu’OpenClaw ? (passerelle durable + jumeau personnel)

2.1 Positionnement : de l’onglet navigateur au « le processus reste »

OpenClaw traite d’autres douleurs : identité fixe, mémoire sur disque, Telegram/Slack/… comme entrées, hébergé sur une machine toujours joignable — pas un onglet qui meurt à la fermeture du portable. Notre article jumeau numérique résume en « IA personnelle 7×24 » ; ici la définition technique : Gateway + Workspace + Channels, plus macOS comme socle durable.

2.2 Trois couches (ici « passerelle » = le processus)

• Gateway (défaut :18789) : auth, routage, appels modèle, files ; souvent via launchd avec redémarrage auto. C’est le « passerelle » du titre — entrée unique du trafic externe.
• Workspace : skills, index de dialogue, règles, snapshots sous ~/workspace ; sauvegarder avant upgrade.
• Channels : Telegram, Slack, mail, nœud mobile — une identité de jumeau, pas un bot étranger par application.

2.3 Pourquoi souvent un Mac cloud

La passerelle exige processus stables, trousseau, toolchain Apple optionnelle, IP de sortie fixe. Les clients Hashvps déploient souvent un M4 bare metal au Canada pour OpenClaw ; APIs nord-américaines et jobs Xcode dans la même région réduisent la taxe de latence. Installation : install CI sans tête ; exploitation : passerelle SSH et dashboard.

En cas de limites API ou d’alertes certificats, vérifier si le jumeau parle depuis une IP NAT changeante. Une IP native par machine réduit ce bruit par rapport aux pools d’egress partagés.

2.4 Scénarios typiques : forces d’OpenClaw

• Telegram : lancer scripts, lire statuts, relayer alertes.
• En déplacement : nœud mobile et dashboard bureau partagent la même mémoire jumeau.
• « Assistant personnel » avec machine dédiée au mois, pas seulement une session IDE ponctuelle.

Facturation : souvent taxe de présence (7×24 + polling channels) plus API d’inférence, pas seulement les tokens d’une session de code.

En exploitation, un gateway diffère d’une session IDE aussi en incident : après patch macOS ou upgrade Node, vérifiez label launchd, port 18789, bearer token et snapshot workspace, pas seulement « le chat répond ». Notre article install sans tête décrit des sondes ; l’article passerelle SSH couvre le dashboard. Les deux complètent cette note d’architecture.

Pour les équipes soumises à conformité, compte aussi où le jumeau journalise et quels channels voient des données sensibles. OpenClaw centralise dans workspace et logs gateway ; Hermes répartit l’état entre ~/.hermes et .ecc projet. Les deux exigent une politique de rétention, mais les interfaces diffèrent.

2.5 Ce qu’OpenClaw n’est pas

• Pas le pack de règles IDE ECC avec 200+ skills et AgentShield prêts à l’emploi.
• Pas le seul outil pour « modifier 50 fichiers en parallèle + CI » — plutôt Hermes/ECC + runner.
• Pas de clés production haut privilège partagées avec l’agent IDE sans séparation — le rayon d’impact s’additionne.

3. Opérateur vs passerelle : un tableau

Après les deux chapitres, la matrice devient lisible :

Erreur fréquente : faire porter à OpenClaw une « PR à 50 fichiers » ; ou attendre d’Hermes sans ECC un secrétaire 7×24 à mémoire parfaite.

Le tableau reste conceptuel : semver, adaptateurs de channels et profils de hooks ECC évoluent plus vite qu’un article. Servez-vous-en pour discussions d’architecture et budgets séparés (inférence vs présence), pas comme checklist produit figée.

4. Installer l’opérateur ou la passerelle ?

4.1 Hermes / ECC seulement

Convient si plusieurs critères : agents quotidiens sur dépôt dans Claude Code/Cursor, review/TDD/AgentShield unifiés, ops surtout au terminal bureau, pas besoin d’un jumeau Telegram 7×24 — commencez par la couche opérateur, pas OpenClaw par mode.

4.2 OpenClaw seulement

Si channels, rappels personnels, automatisation légère et identité fixe sur Mac cloud priment, sans flux multi-agents IDE comme cœur — OpenClaw seul est plus propre.

4.3 Les deux : topologie recommandée

Beaucoup finissent en coexistence :

1. Droits séparés : clés API distinctes OpenClaw et Claude Code ; tokens dépôt prod seulement sur le runner.
2. Machines séparées (idéal) : un Mac cloud pour la passerelle ; un second ou autre utilisateur Unix pour le CI. Budget serré : même machine, répertoires et labels launchd isolés.
3. Rôles séparés : Hermes/ECC pour « comment écrire et relire » ; OpenClaw pour « comment rester en ligne et rappeler ».

La migration entre mondes est documentée : ECC décrit un passage de configs Hermes vers workspace OpenClaw quand une équipe passe de « opérateur d’abord » à « channels d’abord ». Prévoyez une fenêtre de bascule : deux bots Telegram ou deux gateways sur un hôte créent confusion et double facture API.

4.4 Liste de décision

5. Questions fréquentes

Q1. Hermes et OpenClaw sont-ils concurrents ?

Pas tout à fait. Hermes est la coque opérateur dans l’écosystème ECC, orientée harness et workflows réutilisables. OpenClaw est un produit passerelle personnelle autonome, orienté jumeau durable. La doc de migration ECC montre une composition plutôt qu’un choix binaire strict.

Q2. Les deux peuvent Telegram — quelle différence ?

OpenClaw fait des channels une priorité : identité, workspace et routage gateway tournent autour de l’IM. Hermes peut brancher TG, mais le cœur est opérateur terminal-native + skills ECC ; l’IM est une entrée parmi d’autres, pas toute la définition produit.

Q3. Hermes sans ECC ?

Sans ECC, le sens documenté de Hermes disparaît. En pratique : installer ECC → brancher Hermes selon HERMES-SETUP. Seulement des règles IDE ? Lire d’abord l’article ECC puis choisir la profondeur.

Q4. Lequel coûte plus ?

Selon l’usage. Agents de code intensifs : taxe d’inférence ECC. OpenClaw 7×24 : taxe de présence plus temps machine. Tenir des livres séparés (voir l’article τ avec trois blocs de facture).

Q5. Lien avec le Mac cloud Hashvps ?

La passerelle OpenClaw tourne souvent sur tout le Mac cloud ; les builds lourds Hermes/ECC sur le même runner ou un autre. Hashvps fournit macOS dédié et IP ; le choix entre ECC et OpenClaw reste votre décision d’architecture. Beaucoup démarrent avec un siège M4 pour la passerelle et n’ajoutent un second hôte que lorsque files runner et charge gateway se gênent.

Sur matériel partagé : utilisateurs Unix, labels launchd et clés API séparés sont obligatoires. Une seule clé haut privilège pour agent IDE, gateway et Git production agrandit le rayon d’impact sur les deux couches.

6. Conclusion

Hermes répond à qui opère le harness selon les SOP ; OpenClaw à qui veille 7×24 aux canaux. « Opérateur » et « passerelle » ne sont pas du marketing mais des couches. En 2026, route pragmatique : opérateur (ECC/Hermes) côté dev, passerelle (OpenClaw) côté présence, avec frontières de droits et de machines entre les deux.

Une phrase à retenir : ne faites pas faire au gateway le travail de l’opérateur, ni à l’opérateur de remplacer la présence du gateway.