Hermes Agent : quand sortir Hermes du terminal avec le gateway
Le gateway de messagerie ne change pas ce qu’Hermes sait faire.
Il change l’endroit depuis lequel tu peux le joindre.
Jusqu’ici, Hermes vivait surtout dans ton terminal, avec ton dossier courant et ton moment de travail. Avec le gateway, il devient joignable depuis un canal du quotidien.
C’est tout l’intérêt du sujet. Et aussi sa vraie contrainte.
La doc officielle le décrit comme un process de fond unique capable de connecter plusieurs plateformes de messagerie, de gérer des sessions, d’exécuter les tâches cron et d’acheminer les réponses dans les bons canaux. Les docs officielles documentent aussi des intégrations comme Telegram, Discord, Signal, Slack, WhatsApp, Email ou encore un accès navigateur.
Ce que tu auras à la fin
Une vision claire de ce que le gateway change vraiment, des cas où il vaut le coup, des contraintes qu’il ajoute, et de ce qu’il faut déjà avoir stabilisé avant de l’activer.
Ce que change vraiment un gateway de messagerie
Le gateway ne sert pas à faire plus joli.
Il sert à faire passer Hermes d’un outil qu’on lance depuis son shell à un agent qu’on peut joindre depuis un canal du quotidien.
La différence est énorme.
Dans le terminal, Hermes est lié au moment où tu es assis devant la machine. Tu l’ouvres depuis un dossier précis. Tu le vois travailler en direct. Tu maîtrises naturellement le contexte de départ, ne serait-ce que parce que tu es déjà dans ton environnement.
Dans une messagerie, Hermes devient consultable autrement. Tu peux le joindre depuis ton téléphone, depuis un salon précis, depuis un canal d’équipe, depuis un moment où tu n’es pas devant le shell. Tu changes donc moins ses muscles que son accessibilité.
C’est là que le sujet devient intéressant.
Le gateway ne rend pas Hermes “plus intelligent”. Il le rend plus présent.
Et ce n’est pas la même promesse.
La doc officielle distingue d’ailleurs clairement l’entrée terminal avec hermes et l’entrée messagerie avec le gateway. Le point de départ officiel est simple : hermes gateway setup pour configurer, puis hermes gateway start pour lancer le service. Une fois le gateway actif, la doc documente aussi des commandes de session, un home channel, et la gestion de plusieurs sessions selon les canaux.
Pourquoi ce sujet arrive seulement maintenant
Le point n’est pas de rejouer tout le plaidoyer de la branche avancée.
Il est plus simple : tant qu’Hermes reste dans ton terminal, beaucoup de défauts restent contenus. Dès qu’il devient joignable depuis une messagerie, ils voyagent avec lui.
Une config floue, des tools trop larges, un répertoire mal choisi, une sécurité molle, un usage mal cadré : tout ça devient plus gênant dès que le point d’entrée change.
La doc Hermes le traite d’ailleurs comme un vrai service, avec allowlists, DM pairing, commandes d’approbation, home channel, et un répertoire de travail dédié côté messagerie. Le working directory repose sur MESSAGING_CWD, ce qui oblige à choisir où l’agent travaille vraiment.
Autrement dit : le gateway ne répare rien. Il expose ce que tu as déjà construit.
Dans quels cas ça vaut vraiment le coup
Le gateway commence à être rentable quand Hermes doit devenir plus facile à consulter que piloter.
C’est souvent un bon choix dans trois cas.
D’abord, quand tu veux récupérer des retours courts sans rouvrir ton shell à chaque fois. Pas pour lancer une usine à gaz. Juste pour récupérer un état, un résumé, une sortie utile, au bon moment, dans le bon canal.
Ensuite, quand tu veux garder Hermes dans ton quotidien sans rester collé au terminal. Là, la messagerie joue son vrai rôle : elle devient un point de contact naturel.
Enfin, quand tu veux que certains résultats arrivent d’eux-mêmes dans un canal cadré. La notion de home channel existe précisément pour ça dans la doc officielle : c’est le point de réception des sorties planifiées et de certaines notifications proactives. Le gateway exécute aussi le scheduler cron, ce qui relie directement messagerie et planification.
En revanche, ce n’est pas forcément rentable si ton usage principal reste très interactif, très terminal, très lié à un repo précis, avec beaucoup d’aller-retour sur des fichiers, des patchs, des logs et des commandes que tu veux surveiller en direct. Dans ce cas, la messagerie peut vite devenir une vitre latérale utile de temps en temps, pas l’interface centrale.
Cas 1 : recevoir un retour utile hors du terminal
La situation de départ
Hermes tourne déjà correctement chez toi.
Tu as un usage simple mais réel : recevoir un état, un mini résumé, un retour de tâche, ou un rappel utile sans devoir retourner dans le shell juste pour ça.
Le problème n’est pas que le terminal soit mauvais.
Le problème, c’est qu’il n’est pas toujours là où tu es.
Ce qu’on gagne
Le gateway permet de récupérer ce genre de retour dans un canal plus naturel. Si tu définis un home channel, Hermes sait où envoyer les sorties des tâches planifiées et certaines notifications. La doc officielle présente justement cette logique pour recevoir les résultats cron et d’autres messages proactifs.
Concrètement, ça veut dire une chose simple : Hermes devient consultable sans cérémonie.
Tu n’as pas besoin de te reconnecter à ton contexte de dev juste pour lire une sortie courte.
Ce qu’il faut surveiller
Le gain n’existe que si les retours sont courts, utiles et attendus.
Si tu commences à tout faire remonter dans la messagerie, tu transformes un canal pratique en gouttière à logs. Et là, tu tues la valeur du gateway. Une messagerie n’est pas faite pour absorber sans tri toute la verbosité d’un agent.
Pourquoi ça reste une brique avancée
Parce que pour que ce cas soit propre, il faut déjà savoir ce que tu acceptes de faire sortir d’Hermes, dans quel canal, pour qui, et à quelle fréquence. Sinon tu branches un haut-parleur avant d’avoir décidé ce qu’il a le droit de dire.
Cas 2 : déclencher une petite interaction utile à distance
La situation de départ
Tu n’as pas besoin d’une console d’administration mobile.
Tu veux juste pouvoir poser une petite question, demander un état, lancer une vérification légère, ou récupérer un résultat cadré sans revenir à ton poste.
Ce qu’on gagne
Là, le gateway prend tout son sens. Les docs officielles montrent un ensemble de commandes de session partagées en messagerie, et même un mode /background pour lancer un travail séparé tout en gardant le chat principal réactif. Hermes renvoie ensuite le résultat dans le même canal une fois la tâche terminée.
Le vrai gain n’est pas de “piloter le monde depuis ton téléphone”.
Le vrai gain, c’est de ne plus réserver Hermes aux seuls moments où tu es assis devant le terminal.
Tu peux lui demander quelque chose de simple, utile, borné, et récupérer le résultat sans tout rouvrir.
Ce qu’il faut surveiller
Il faut que la demande reste petite.
Une messagerie est très bonne pour consulter, relancer, demander un état, lancer un petit job cadré. Elle est nettement moins bonne pour conduire des manipulations longues, ambiguës, ou très sensibles, surtout si elles demandent de suivre de près l’exécution.
Le gateway est donc très bon pour l’accès. Il n’est pas automatiquement le meilleur poste de pilotage.
Pourquoi ça reste une brique avancée
Parce qu’il faut déjà savoir faire la différence entre une interaction utile à distance et un mauvais réflexe de contrôle à distance permanent. Ce n’est pas la même chose.
Cas 3 : pourquoi ça peut vite devenir une mauvaise idée
La situation de départ
Tu branches Hermes dans une messagerie parce que “c’est pratique”, mais sans vrai cadre.
Tu laisses trop d’utilisateurs possibles. Tu gardes des toolsets trop larges. Tu laisses le répertoire de travail par défaut. Tu n’as pas vraiment pensé à ce que l’agent peut faire depuis ce nouveau point d’entrée.
Ce qu’on perd
Là, le gateway cesse d’être un confort et devient une surface d’exposition.
La doc officielle insiste justement sur plusieurs garde-fous : le gateway refuse par défaut les utilisateurs non autorisés, recommande les allowlists ou le DM pairing, documente les commandes d’approbation pour les opérations sensibles, conseille de définir MESSAGING_CWD, et documente l’usage de services et de logs dédiés.
Et il y a un autre détail important : côté messagerie, les toolsets disponibles peuvent rester très puissants, terminal compris. Donc non, un bot dans une messagerie n’est pas “forcément plus soft” qu’Hermes dans ton shell. Suivant ce que tu as laissé actif, il peut garder des dents bien réelles.
Pourquoi ça dérape vite
Parce qu’une messagerie donne une illusion de légèreté. On parle à une bulle de chat, donc on oublie facilement qu’il y a derrière un agent capable d’utiliser des outils et d’agir sur un environnement réel.
La jolie bulle n’adoucit pas le risque.
Elle le maquille.
Pourquoi ça reste une brique avancée
Parce qu’à ce niveau, la question n’est plus seulement “est-ce que ça marche ?”. La question devient “qui peut parler à l’agent, depuis où, avec quels droits, dans quel répertoire, avec quels outils, et sous quelle surveillance ?”
Ce que le gateway ajoute comme contraintes
Le gateway ajoute au moins quatre contraintes nettes.
La première, c’est l’exposition. Hermes n’est plus seulement accessible depuis le terminal local. Il devient joignable depuis un canal externe.
La deuxième, c’est la discipline d’autorisation. Il faut penser allowlists, pairing, approbations, et non pas se dire que le bot fera naturellement la différence tout seul.
La troisième, c’est la lourdeur potentielle. Dès qu’on ouvre un canal plus pratique, on a tendance à trop s’en servir, trop faire remonter d’informations, ou trop lui demander de petites choses pas vraiment utiles.
La quatrième, c’est le cadrage de l’environnement. La doc Hermes distingue bien le terminal lancé dans ton dossier courant et le gateway qui, par défaut, n’a pas ce même contexte de départ. Le working directory côté messagerie repose sur MESSAGING_CWD, ce qui oblige à réfléchir un minimum à l’endroit depuis lequel l’agent travaille vraiment.
Ce qu’il vaut mieux avoir déjà stabilisé avant
Avant de brancher un gateway, il vaut mieux avoir déjà clarifié quatre choses.
D’abord, le rôle du canal. Retour court, relance légère, notification utile, petite interaction cadrée. Pas “on verra bien”.
Ensuite, qui peut parler à l’agent, et avec quels droits. Les allowlists, le pairing et les approbations servent à ça, pas à faire joli.
Troisièmement, le répertoire de travail côté messagerie. MESSAGING_CWD ne doit pas être une variable laissée au hasard.
Enfin, le périmètre réel d’Hermes. Si tu n’assumerais pas déjà ces tools et ce niveau d’action dans ton terminal, ne les expose pas dans une messagerie.
Les erreurs fréquentes
L’erreur la plus classique, c’est de voir le gateway comme une démo sympa à montrer, au lieu de le traiter comme un changement d’interface sérieux.
La deuxième, c’est de croire qu’une messagerie est forcément un environnement plus inoffensif qu’un terminal.
La troisième, c’est d’ouvrir trop large : trop d’utilisateurs, trop de canaux, trop d’outils, trop de permissions.
La quatrième, c’est d’utiliser le gateway comme une télécommande brute pour tout faire, alors qu’il est souvent meilleur comme point de contact, de retour, de relance légère et de supervision simple.
La cinquième, c’est de vouloir y faire passer une mauvaise architecture. Si ton workflow devrait être tenu par Python, le gateway ne le rendra pas meilleur. Il te donnera juste une autre porte vers un workflow déjà mal réparti.
Ce que tu ne dois pas faire
- Ne branche pas le gateway pour “voir ce que ça donne” sur un Hermes déjà flou.
- Ne fais pas de la messagerie ton poste de pilotage principal pour des actions sensibles si tu n’as pas déjà un cadre sérieux.
- Ne transforme pas ton canal en flux de spam technique.
- Ne confonds pas accessibilité et autonomie.
- Ne crois pas qu’un bot dans Telegram, Discord ou Signal devient automatiquement un bon usage juste parce qu’il est plus proche de toi.
- Et surtout, ne donne pas à un agent joignable depuis une messagerie un périmètre que tu n’assumerais déjà pas dans ton terminal.
La suite logique
Le gateway n’est pas une couche “plus avancée” par prestige.
C’est juste le moment où Hermes devient joignable hors du shell.
Si c’est exactement ce qu’il te manquait, la brique est logique. Sinon, le terminal reste souvent le meilleur poste de pilotage.
Et une fois ce canal propre, la question suivante n’est plus “comment joindre Hermes ?” mais “quand doit-il agir ?” puis “quel Hermes doit porter quel rôle ?”. C’est là que cron puis les profiles prennent le relais.