
Pourquoi j'ai regardé Hermes pour le support
Je construis des intégrations chez eesel, ce qui veut dire que je passe une bonne partie de ma semaine dans des API de helpdesk, à déterminer ce qu'une IA peut et ne peut pas toucher. eesel fait tourner de l'IA sur des files de support réelles depuis des années, et la leçon que je réapprends sans cesse est banale mais coûteuse : le modèle est rarement le problème. C'est la plomberie autour. Qui peut lui parler, ce dont il se souvient, ce qu'il a le droit d'envoyer et comment vous savez qu'il est prêt.
Alors quand Hermes Agent revenait sans cesse dans des conversations du type « puis-je simplement l'utiliser pour le support ? », j'ai lu sa documentation de bout en bout avec ce prisme. C'est un logiciel sérieux, avec 251 479 étoiles GitHub et une nouvelle version du 24 septembre. La question n'est pas de savoir s'il est bon. C'est de savoir s'il est conçu pour une file de support.
L'attrait est réel, et je le comprends. Un client qui a quitté eesel a dit ceci au fondateur en partant :
"But long term we will just build our own, which is so possible now with AI."
Un client mid-market qui a résilié, dans une réponse au fondateur d'eesel
C'est exactement la pensée derrière la plupart des recherches sur Hermes pour le support. C'est une pensée légitime. Cet article explique ce que « construire le nôtre » implique réellement avec Hermes.
Ce qu'est vraiment Hermes Agent
Hermes Agent est l'agent IA open source et auto-hébergé de Nous Research, publié sous licence MIT. Il tourne sur votre machine ou votre serveur, garde une mémoire entre les sessions, écrit ses propres skills à partir de l'expérience et peut être joint depuis des applications de chat via une passerelle. Nous le décrit comme un agent qui "lives wherever you put it", d'un petit VPS à un cluster de GPU (documentation).

Le point important pour les équipes de support : c'est un agent généraliste conçu pour son opérateur. Ce n'est pas un produit de helpdesk et il ne prétend pas en être un. J'ai cherché "helpdesk" et "support ticket" dans tout l'export de documentation de 240 pages et j'ai obtenu zéro résultat. Les mentions les plus proches sont un exemple en passant de "customer-support bot" sur la page des distributions de profils et "a support triage channel" sur la page Slack.
Ce n'est pas un reproche. Un agent généraliste est utile précisément parce qu'il n'est pas enfermé dans une seule tâche, et c'est pourquoi il figure dans les tours d'horizon des agents IA open source à côté d'OpenClaw. Mon avis plus complet sur le produit se trouve dans le test de Hermes Agent.
Deux façons de pointer Hermes vers le support
Toute configuration de Hermes pour le support que j'ai vue relève de l'une de deux formes, et elles portent des risques très différents.

Derrière vos agents. Hermes lit les tickets, récupère les informations du compte et rédige des réponses. Un humain relit et envoie. C'est en gros de l'assistance aux agents construite à partir de pièces, et c'est là que Hermes s'en sort bien aujourd'hui.
Devant les clients. Les clients écrivent directement à Hermes sur WhatsApp, Telegram, par e-mail ou sur un chat web, et il répond tout seul. C'est le travail d'un agent de helpdesk IA, et c'est là que la conception vous résiste presque à chaque étape.
L'essentiel de ce qui suit explique pourquoi cette seconde forme est plus difficile qu'elle n'en a l'air, et ce qu'il faudrait construire pour la sécuriser.
Forme 1 : Hermes comme assistant de rédaction (ça marche)
Le meilleur exemple réel que j'ai trouvé est celui d'un propriétaire de petite entreprise qui branche Hermes sur Front :
"My current set up…Hermes agent logs into front with write only API token and reads whole context of customer thread. Then tries to look in our software for answers. (Unreliable right now). Then writes draft. This has been way harder than I expected. Been a side project for a while. Really focused on it right now. Goal - save CSR 80% of email writing time."
Remarquez la forme : lire, chercher, rédiger, s'arrêter. Pas d'envoi. Une autre réponse dans le même fil pointait vers la base de connaissances :
"yes this is close. easiest version is to have an FAQ document that it references. best way to build that is to point your agent at old emails"
Ma règle par-dessus : gardez l'envoi derrière un clic humain jusqu'à ce que les erreurs deviennent ennuyeuses. C'est un bon conseil pour toute IA sur une file, et il rejoint ce que j'ai appris à mes dépens sur les hallucinations de l'IA dans le support. La recherche d'abord, l'envoi en dernier.
Le même schéma apparaît pour le support interne. Un utilisateur de Hacker News a relié Hermes à BigQuery, Stripe et Amplitude pour que "nontechnical teammates can ask and answer their own data questions via Slack. It works great!" (brettcvz, Hacker News). Un autre rapporte qu'il "answers most of both my emails and slack messages" à partir d'un wiki rafraîchi par une tâche cron quotidienne (igorhvr, Hacker News). Si votre objectif est un chatbot de support interne pour vos propres équipes, Hermes est une construction raisonnable.
Comment fonctionne la connexion au helpdesk
C'est la partie pour laquelle je budgéterais le plus de temps. Hermes se connecte aux outils externes via des serveurs MCP, configurés sous mcp_servers dans config.yaml, avec un filtrage par serveur pour n'exposer que les outils voulus (documentation MCP). Nous fournit aussi un catalogue MCP sélectionné et relu par son équipe, de 68 serveurs.
Aucun de ces 68 n'est Zendesk, Freshdesk, Gorgias, HubSpot ou Help Scout (répertoire du catalogue). Vos options :
| Voie | De quoi il s'agit | Qui l'a relu |
|---|---|---|
| Serveur MCP du fournisseur | par ex. le serveur officiel de Front, traité dans mon article Claude pour Front | L'éditeur du helpdesk |
| Skill communautaire sur skills.sh | zendesk-automation (4,053 installations), Freshdesk (652), Gorgias (59), selon la recherche skills.sh | Personne chez Nous |
| Votre propre serveur MCP | Vous l'écrivez contre l'API du helpdesk | Vous |
Les skills communautaires sont du code tiers que Hermes peut installer depuis un registre public. Je lirais chaque ligne avant de donner à l'un d'eux un jeton d'API capable d'écrire dans les tickets clients. Si vous préférez partir d'un modèle existant, mon guide du MCP pour le support client explique ce qu'un serveur MCP de support devrait et ne devrait pas exposer.
Forme 2 : Hermes devant les clients (c'est là que ça casse)
C'est ici que lire la documentation en homme d'intégrations devient intéressant. La passerelle est impressionnante : Telegram, Discord, Slack, WhatsApp, Signal, SMS, e-mail, Microsoft Teams, LINE et plus, environ 29 plateformes dans le tableau comparatif (Messaging Gateway).

Les canaux ne sont pas le problème. Quatre choix de conception le sont, et chacun est un réglage par défaut judicieux pour un agent personnel qui devient une vraie lacune sur un canal de support public.

1. Il est conçu pour tenir les inconnus à distance
Les mots mêmes de la passerelle : "By default, the gateway denies all users who are not in an allowlist or paired via DM. This is the safe default for a bot with terminal access" (documentation). Les utilisateurs inconnus reçoivent un code d'appairage à usage unique que l'opérateur approuve à la main, et les codes expirent au bout d'une heure.
Ça marche pour une équipe de dix. Ça ne marche pas pour un flot de clients que vous n'avez jamais rencontrés. L'interrupteur pour ouvrir existe, mais la liste de contrôle de sécurité dit : "never use GATEWAY_ALLOW_ALL_USERS=true in production." Je prendrais cela au sérieux, car le point suivant explique pourquoi.
2. Les niveaux d'utilisateur limitent les commandes, pas les outils
Hermes a une séparation entre admin et utilisateur, mais aujourd'hui elle ne contrôle que les commandes slash. La documentation dit "Plain chat is not affected" et que l'accès aux outils s'appuiera sur la même séparation "as we add them" (documentation). Un utilisateur de chat ordinaire parle donc à un agent doté de tout l'ensemble d'outils de son profil.
Il y a un détail connexe dans les approbations. Sur les plateformes de messagerie, quand Hermes veut exécuter une commande risquée, il "sends the dangerous command details to the chat and waits for the user to reply" (documentation de sécurité). Sur un canal client, la personne dans ce chat est le client. C'est une inférence de ma part à partir du flux documenté, mais c'est le genre de chose que je voudrais voir écartée avant le lancement.
3. La mémoire est par profil, pas par client
La mémoire intégrée se compose de deux petits fichiers, MEMORY.md plafonné à 2 200 caractères et USER.md à 1 375, injectés dans le prompt système au début de la session (documentation de la mémoire). La documentation dit "Memory is scoped per profile by design."

Les transcriptions de chat sont isolées par utilisateur. La mémoire ne l'est pas. Si Hermes enregistre une note pendant le chat du client A, cette note est chargée dans la prochaine session du client B sur le même profil. La documentation ne le dit jamais ouvertement, mais cela découle de la portée de la mémoire, et c'est exactement le genre de fuite entre clients qui fait échouer les revues de confidentialité des données. Les correctifs documentés sont un profil distinct par utilisateur ou le module de mémoire Honcho, qui donne à "each user their own peer" (documentation Honcho).
4. L'analyse des injections de prompt couvre les fichiers, pas les chats
Hermes analyse les fichiers de contexte et les entrées de mémoire à la recherche de schémas d'injection, et la documentation est claire : "These patterns are heuristics, not semantic intent detection" (documentation de sécurité). Je n'ai trouvé aucune consigne pour se défendre contre l'injection dans les messages entrants des clients. La communauté l'a remarqué :
"If you re-use the Hermes agent, what are the cost and security implications? One Docker container per-customer sounds like it would be really expensive. Are they started on-demand, or run 24/7? What keeps users from using the agents for general purpose tasks, protects against prompt-injection, etc?"
Aucun de ces quatre points n'est un bug. Ce sont les bons réglages par défaut pour un agent qu'une personne exécute pour elle-même. Ils sont simplement l'inverse de ce dont a besoin un chatbot IA pour site web public.
Et un widget de chat pour le site ?
Il n'y en a pas. La voie « navigateur » de la documentation est un serveur d'API compatible OpenAI, et son propre avertissement dit qu'il "gives full access to hermes-agent's toolset, including terminal commands." Un chat sur le site impliquerait de construire une interface et un proxy verrouillé devant cette clé.
L'e-mail est mieux couvert. Hermes interroge une boîte IMAP toutes les 15 secondes et répond dans le même fil en texte brut, et il vérifie DMARC ou un SPF/DKIM aligné afin qu'un expéditeur falsifié ne puisse pas détourner une session (documentation e-mail). Par défaut, les expéditeurs inconnus sont ignorés en silence, ce qui est sûr et signifie aussi qu'un client qui lui écrit n'obtient rien en retour. Pour une vue plus large du travail par e-mail, voyez comment automatiser le support par e-mail.
Ce que Hermes ne sait pas faire : répéter sur vos anciens tickets
C'est la lacune qui m'importe le plus, car c'est l'étape qui m'a sauvé plus d'une fois. Hermes a de vraies fonctions de sécurité : exécution en bac à sable sur plusieurs backends de terminal, approbation des commandes avec un mode smart qui refuse automatiquement les commandes dangereuses, et une règle de refus par défaut pour les sessions cron et webhook sans surveillance (documentation de sécurité). Cela contient une mauvaise action.
Ce que Hermes n'a pas, c'est un moyen de vous montrer, avant la mise en ligne, comment il aurait répondu aux tickets du mois dernier. Pas de rejeu, pas d'essai à blanc noté. Dans le support, cette répétition est le moyen de trouver la réponse fausse et sûre d'elle avant qu'un client ne le fasse. Sans elle, votre premier vrai test, ce sont vos clients.
Vous pouvez bien sûr construire vous-même un banc d'évaluation. Récupérez quelques centaines d'anciens tickets, faites passer Hermes dessus dans un bac à sable et notez les brouillons par rapport à ce que votre équipe a réellement envoyé. C'est un bon projet de week-end pour un ingénieur, et un projet continu à chaque changement de vos règles.
Ce que coûte Hermes Agent pour une équipe de support
La licence est gratuite. L'exploiter ne l'est pas, et la facture a plus de couches que ce que l'on imagine.

L'argent se trouve dans Nous Portal. Il vend des forfaits de crédit prépayé, et chaque palier payant restitue 110 % de son prix en crédit utilisable (Nous Portal) :
| Palier | Prix | Crédits mensuels | Plafond de report | Ce que vous obtenez |
|---|---|---|---|---|
| Free | $0 | $0 | n/a | Modèles gratuits uniquement, pas d'outils hébergés |
| Plus | $20/mois | $22 | $10 | Plus de 200 modèles, outils hébergés, limites de débit élevées |
| Super | $100/mois | $110 | $50 | Comme Plus, solde plus important |
| Ultra | $200/mois | $220 | $100 | Comme Plus, le plus gros solde |

Quelques points à connaître avant de budgéter :
- Les modèles sont facturés au token. Le catalogue affiche les prix actuels par million de tokens, avec tous les modèles remisés d'au moins 20 % (modèles). Nouveauté depuis août, Nous Portal permet aussi de connecter une offre ChatGPT éligible pour l'inférence plutôt qu'un abonnement.
- Les outils hébergés sont facturés à l'usage. La recherche web, le navigateur, la voix et les outils d'image puisent dans le même solde, et les tarifs à l'usage ne figurent sur aucune page que j'ai pu lire.
- Hermes Cloud exige un minimum de 10 $ de crédit pour déployer et "scales to zero when idle" (Hermes Cloud). Les tarifs des instances sont derrière la connexion.
Par réponse, cela peut coûter peu. Un développeur qui fait tourner Hermes sur WhatsApp a estimé son coût à "~$0.005 per reply" (dandinu, Hacker News), mais sur une liaison WhatsApp non officielle rattachée à son numéro personnel, "a ban risk I accepted."
Le coût qui n'apparaît sur aucune facture, c'est la construction. Un consultant qui installe Hermes pour des petites entreprises a résumé ce qui les bloque :
"On top of that, you need API connections, OAuth, tools, permissions, gateways, sources, context, skills. SMB owners won't set that up alone."
Cette liste est le prix honnête de Hermes pour le support. Mon comparatif construire ou acheter chiffre ce temps d'ingénierie.
Faut-il mettre Hermes sur votre file de support ?
Voici comment je déciderais, selon ce que vous cherchez réellement à faire.
En bref : Hermes est un bon agent pour ceux qui l'exploiteront eux-mêmes. Le support client est le seul travail où « tourne comme son opérateur » joue contre vous, car les personnes qui lui parlent, ce n'est pas vous.
Quoi utiliser à la place pour une file réelle
Si vous avez regardé Hermes parce que vous vouliez « de l'IA sur ma file de support », l'outil pour ce travail est un outil construit autour de la file. C'est la lacune que comble eesel.
eesel est une plateforme de coéquipiers IA, et le coéquipier qui convient ici est son agent de helpdesk IA. Il rejoint votre helpdesk comme une application, il hérite donc des utilisateurs, des permissions et de l'historique de tickets de votre helpdesk au lieu que vous construisiez ces couches. Chacune des quatre lacunes ci-dessus a une réponse intégrée :

- Répétition avant la mise en ligne. eesel rejoue des centaines de vos anciens tickets et note ses réponses par rapport à ce que votre équipe a réellement envoyé, puis propose des modifications d'instructions. C'est l'essai à blanc que Hermes ne fournit pas, et c'est ainsi que je repère tôt la réponse fausse et sûre d'elle.
- Des connexions helpdesk qui existent déjà. Zendesk, Freshdesk, Gorgias, Front, Help Scout, HubSpot et le reste de la liste d'intégrations se connectent en quelques minutes, sans serveur MCP à écrire.
- Conçu pour les clients. Il répond à ce dont il est sûr et confie le reste à une personne avec un transfert vers un humain propre. Si vous n'avez pas de helpdesk, la bulle de chat s'installe sur votre site avec une seule balise script.
- Une trace de chaque réponse. Le journal d'activité montre chaque conversation que l'IA a touchée et renvoie vers le ticket, pour que vous puissiez l'entraîner sur votre base de connaissances et voir ce qui a changé.
Et si l'attrait de Hermes était le terminal, eesel l'a aussi. La CLI eesel (@eesel/cli) pilote le même coéquipier qui travaille votre file : eesel instructions lit et modifie ses règles permanentes, eesel approvals permet à un humain d'approuver ou de refuser les actions en attente, et eesel activity liste chaque exécution. Chaque commande affiche du JSON, les commandes d'écriture prennent en charge --dry-run, et l'authentification headless fonctionne via des variables d'environnement, si bien que des scripts et des agents de code comme Claude Code peuvent le piloter. Chaque espace de travail est aussi un serveur MCP. Mon article sur la CLI pour le support client va plus loin.
Si vous voulez d'abord voir le marché plus large, mon tour d'horizon des logiciels d'IA pour le service client est une bonne prochaine étape. Pour des remplacements directs, voyez ma liste des alternatives à Hermes Agent.
J'ai aussi écrit sur Grok Bot pour le support, ainsi qu'un avis distinct sur Meta Muse.
Essayez eesel sur votre file de support
Vous avez regardé Hermes parce que vous vouliez une IA qui travaille réellement vos tickets ? eesel fait ce travail sans le câblage : connectez Zendesk, Freshdesk ou Front en quelques minutes, laissez-le apprendre de votre centre d'aide et de vos réponses passées, et regardez-le répéter sur vos anciens tickets avant qu'il n'en réponde un en direct. Un ticket ou un chat compte pour un crédit, les forfaits démarrent à 299 $ pour 500 crédits, et le forfait gratuit comprend 100 crédits sans carte.

Gardez Hermes pour ce qu'il fait très bien, un agent que vous exploitez pour vous et votre équipe. Pour les clients, essayez eesel.