Hermes Agent vs Goose : CLI de bureau ou runtime serveur ?

Deux agents bien nommés qui visent des machines différentes

Si vous avez tapé « hermes agent vs goose » dans un moteur de recherche, vous comparez deux des agents IA open source les plus étoilés de 2026, mais ils visent des machines différentes. Goose est l'agent bureau et CLI de Block, écrit en Rust et sous licence Apache 2.0, avec plus de 44 000 étoiles GitHub et désormais gouverné par l'Agentic AI Foundation au sein de la Linux Foundation. Hermes Agent est le runtime serveur Python de Nous Research, sous licence MIT, qui a franchi les 175 000 étoiles en moins de quatre mois après sa sortie en février 2026. L'un est un assistant bureau soigné, piloté par des recettes YAML portables. L'autre est un daemon toujours allumé, orienté messagerie, à mémoire persistante.

Cette distinction façonne presque tout ce qui suit : comment on installe chaque projet, où il vit, comment il se souvient de vous, comment on l'étend et quel lecteur va cliquer « retour » sur Google après avoir atterri sur le mauvais. Ce billet passe en revue ce que chaque projet est vraiment, la frontière honnête de décision entre eux et le montage hybride qui fait tourner les deux à la fois.

Ce qu'est vraiment Goose

Goose est un agent IA on-machine de Block (anciennement Square). Vous l'installez en application bureau native ou en CLI, écrit en Rust pour la portabilité et la vitesse, et l'agent tourne dans une session que vous ouvrez sur votre portable. Pointez-le sur un fournisseur de modèle - Anthropic, OpenAI, Google, Ollama, OpenRouter, Azure, Bedrock ou tout endpoint compatible OpenAI - et lancez une tâche. Il livre plus de 15 fournisseurs pris en charge d'origine.

L'opinion la plus forte de Goose, c'est la recette : un fichier YAML avec un nom, un prompt, une liste d'extensions, des entrées structurées et des sous-recettes optionnelles. Les recettes sont la raison pour laquelle le même binaire gère revue de PR, triage de tickets, réparation de suites de tests et des dizaines d'autres missions. Une recette peut dire « lance la suite de tests, collecte les échecs, corrige chaque test cassé, relance pour confirmer, puis crée un commit », et n'importe quel collègue peut la versionner dans un repo et l'exécuter. Block rapporte que cette abstraction est ce qui a permis à Goose de passer à 60 % des ~12 000 employés de l'entreprise en ingénierie, vente, design, produit et customer success.

L'extensibilité est l'autre pilier. Goose fut un adoptant précoce de MCP et compte déjà plus de 70 extensions documentées, ce qui signifie que chaque nouvelle capacité - un lecteur de base, un tableau Jira, une requête de monitoring - est un serveur MCP écrit une fois qui se branche ensuite dans chaque recette. Goose peut aussi lancer des sous-agents indépendants en parallèle pour garder la conversation principale propre.

Ce qu'il n'a pas d'origine, c'est une identité persistante et transversale de vous. La mémoire dans Goose est cantonnée à la session et à ce que la recette du jour décide de retenir. Si vous voulez un agent qui sache ce que vous lui avez dit il y a deux semaines sans reconstruire une recette pour aller rechercher ce contexte, ce n'est pas la forme du produit.

Ce qu'est vraiment Hermes Agent

Hermes Agent est un runtime serveur Python, pas une application bureau. Une commande installe, une autre démarre, et un processus long apparaît sur votre hôte - un VPS à 5 dollars, un Raspberry Pi, un NAS, un serveur maison. Vous lui parlez d'où c'est le plus pratique : Telegram, WhatsApp, Discord, Slack, Signal, Matrix, Mattermost, e-mail, SMS ou une CLI locale - une vingtaine de canaux desservis par une seule passerelle.

Il y a un seul agent, volontairement. Sa force vient de trois couches d'état livrées d'origine :

Mémoire centrale dans des fichiers (MEMORY.md, USER.md) injectés dans le system prompt au début de la session.
Recherche de session portée par SQLite FTS5, pour que l'agent se souvienne de ce que vous avez dit mardi dernier sans que vous ayez à recoller quoi que ce soit.
Skills, des fichiers markdown simples compatibles avec le standard ouvert agentskills.io, que l'agent charge et écrit lui-même après les tâches qu'il veut savoir refaire.

Autour de ce cœur, une ceinture d'outils : recherche web, extraction de page, automatisation navigateur (naviguer, cliquer, saisir, capturer), vision, génération d'images, synthèse vocale et des dizaines d'autres. Hermes parle à n'importe quel modèle compatible OpenAI, donc Nous Portal, les 200+ modèles d'OpenRouter, NVIDIA NIM, Hugging Face ou votre propre endpoint marchent. Le runtime est MIT et le coût marginal est dominé par la facture du fournisseur de modèle.

La frontière de décision

Un cadrage utile : Goose est l'agent que vous pilotez au clavier. Hermes est l'agent auquel vous envoyez des messages depuis votre téléphone.

Question	Goose	Hermes Agent
Où vit l'agent	Sur votre portable (app bureau ou CLI)	Sur un serveur (VPS, Pi, NAS, machine maison)
Forme de la session	Vous ouvrez une tâche, elle tourne, elle sort	Daemon long, toujours allumé
Interface principale	Terminal ou UI bureau native	Telegram, WhatsApp, Discord, Signal, +17
Mémoire entre sessions	Pilotée par recette, non intégrée	Fichiers de mémoire centrale, recherche FTS5, skills
Mécanisme d'extension	Serveurs MCP, référencés depuis les recettes YAML	Serveurs MCP et skills markdown que l'agent écrit lui-même
Multi-tenant / équipes	Recettes partageables ; un binaire par utilisateur	Daemon mono-utilisateur par installation
Langage	Rust	Python
Licence	Apache 2.0	MIT
Meilleur pour	Code, tâches type CI, workflows partageables	Assistance personnelle, mémoire, brouillons sur plusieurs jours
Étoiles GitHub (2026)	44 000+	175 000+

Le signal que vous avez pris le mauvais est en général bruyant. Si vous essayez d'avoir « un agent sur Telegram qui me connaît et rédige mon e-mail à 8h alors que mon portable est fermé », Goose est la mauvaise forme : pas de serveur long, pas de pont de messagerie, pas d'identité persistante. Si vous essayez de faire tourner un flux « relis ce PR, patche, retest, commit » dans le CI et partagé avec l'équipe, Hermes est la mauvaise forme : un daemon personnel orienté messagerie n'est pas ce qu'un agent de build demande.

Quand Goose l'emporte

Goose est la bonne réponse quand :

Le travail de l'agent, c'est du code que vous pilotez depuis un terminal. Lire, éditer, exécuter, tester des fichiers sur la machine où vous êtes déjà assis.
Vous voulez des workflows portables et relisibles. Une recette YAML versionnée dans un repo est l'artefact - votre collègue clone, lance goose run et obtient le même comportement.
Vous êtes dans une équipe ou une entreprise et vous voulez que des dizaines de missions partagent un binaire et une surface d'extensions. Les 60 % d'adoption chez Block sont la forme de ce cas.
Vous voulez la liberté maximale de modèle sur le bureau, sans serveur. Anthropic, OpenAI, Google, Ollama, OpenRouter, Bedrock, Azure - tous marchent, et avec Ollama le mode totalement hors-ligne est réel.
Vous voulez des sous-agents en parallèle pour que la conversation principale reste lisible pendant que des tâches d'arrière-plan tournent.

C'est la catégorie agent on-machine. Goose y croise Aider, Cursor et Claude Code et OpenClaw. Sa signature, c'est le format de recettes - une abstraction sobre et bien tournée qui généralise aussi hors du code.

Quand Hermes l'emporte

Hermes est la bonne réponse quand :

L'agent est pour vous, pas pour un repo ou une équipe. Un assistant d'écriture quotidien, un compagnon de journaling à long cours, un CRM personnel qui vit dans Telegram.
Vous voulez la mémoire et la messagerie d'origine. Pas de recette pour « souviens-toi que j'utilise pnpm », pas d'adaptateur de messagerie à écrire à la main.
L'agent doit être éveillé pendant que vous dormez ou que votre portable est fermé. Un runtime serveur est allumé 24/7 par définition.
Vous voulez qu'il vous retrouve là où vous êtes déjà. Messages vocaux sur Telegram, un DM Slack, un SMS - pas une fenêtre de terminal à ouvrir.
Vous voulez qu'il s'améliore tout seul. Hermes écrit et corrige ses propres fichiers de skills en travaillant, donc l'agent du mois prochain est un peu meilleur que celui d'aujourd'hui.

C'est la catégorie agent personnel. Nous avons comparé Hermes aux gros assistants seulement chat dans Hermes Agent vs ChatGPT, Claude et Gemini, aux outils de workflow dans Hermes Agent vs n8n et aux frameworks Python dans Hermes Agent vs Agno.

Démarrez avec Hermify si vous voulez un Hermes Agent géré sur Telegram en moins d'une minute, sans VPS à opérer.

L'hybride honnête

Les deux projets ne s'excluent pas, et le montage le plus intéressant fait tourner les deux.

Goose vit dans votre boucle de dev. Sur votre portable, un dossier de recettes gère revues de PR, refactors, migrations, réparations de suites de tests - les tâches qui tombent naturellement dans « ouvre une session, fais tourner jusqu'au bout, ferme ». Les recettes vont dans le repo comme n'importe quel autre code.
Hermes porte la relation ambiante. Sur un serveur auquel vous parlez depuis Telegram toute la journée, Hermes rédige vos e-mails, résume vos lectures, suit vos projets et se rappelle du client à qui vous aviez promis quelque chose il y a deux vendredis.

Le pont entre les deux, c'est MCP. Hermes parle l'API compatible OpenAI et peut s'exposer en serveur MCP, donc une recette Goose peut appeler la mémoire d'Hermes comme un outil (« quel était le budget déclaré du client pour ce projet ? »). À l'inverse, une skill Hermes peut lancer goose run recette.yaml quand la tâche est naturellement du code. En pratique : Hermes détient l'état de la relation (qui vous êtes, ce qui vous importe, qui sont vos contacts) et Goose détient les missions structurées (celles que vous coderiez volontiers en YAML si vous deviez).

Coût, hébergement et lock-in

Les deux projets sont open source et auto-hébergeables. Aucun ne vous enferme chez un fournisseur.

Goose tourne sur votre machine locale, donc le coût de runtime, c'est votre portable plus la facture du fournisseur de modèle. Avec Ollama, le hors-ligne est gratuit. Les recettes sont du YAML portable, sans runtime qui vit dans le cloud de quelqu'un d'autre.

Hermes tourne sur un serveur, donc vous payez le serveur (un VPS à 5 dollars suffit en usage personnel) et le fournisseur de modèle. Si vous préférez ne pas gérer le serveur, une installation gérée s'occupe du VPS, des mises à jour et des ponts de messagerie et garde les fichiers de mémoire dans votre compte. Nous avons couvert le choix self-hosted vs géré dans un autre article.

Comment choisir

Une règle courte de décision :

Si votre problème est « je veux un agent code, test, refactor, format CI, piloté depuis mon portable avec des workflows YAML relisibles » - choisissez Goose.
Si votre problème est « je veux un agent toujours allumé qui me connaît, vit sur Telegram ou Slack et se souvient de moi sur plusieurs semaines » - choisissez Hermes.
Si vous voulez l'agent code sur le portable et l'agent personnel ambiant sur le téléphone - lancez les deux, et laissez MCP les faire dialoguer quand une tâche traverse la frontière.

Forcer l'un à jouer le rôle de l'autre, c'est le mode d'échec. Goose n'est pas un daemon personnel natif messagerie ; faire semblant, c'est reconstruire les morceaux d'Hermes que vous auriez eus gratis. Hermes n'est pas un runner de CI code-first ; faire semblant, c'est réécrire un format de recettes que Goose livre déjà. Une fois qu'on accepte qu'ils visent des machines différentes, le choix devient facile et le montage à deux commence à paraître évident.