Deux Gmails, un seul Hermes : les comptes des connectors ont enfin un nom


Neuf heures du matin : vous demandez à Hermes dans le chat si quelque chose d’important est arrivé dans votre boîte aujourd’hui. Il ouvre la boîte perso créée pour un projet de week-end, et la réponse du client qui dort dans votre boîte pro passe inaperçue. Vous précisez donc « je parlais de celle du boulot » — et tout ce qu’il peut répondre, c’est « Gmail est connecté », parce que c’est honnêtement tout ce qu’il sait.

Le modèle n’était pas à la masse. Hermes ne connaissait autrefois qu’un seul login connecté par app, sans nom et sans second compte au choix.

Une app, un seul compte

Hermes atteint les apps externes via des connectors : le gateway les héberge comme des tools nommés par exemple connectors__gmail__SEND_EMAIL, que vous trouvez avec tool_search et appelez avec tool_call. Dans ce modèle, l’ancien build supposait un compte par app, et les conséquences étaient concrètes :

  • Un second login Gmail n’avait aucun nom utilisable par le modèle, qui prenait donc le compte le plus récent ;
  • reconnect gmail consultait le flag « connected » du connector entier. Avec un compte sain et un compte expiré, il annonçait connecté et ne réparait rien ;
  • Une carte de connexion Gmail déjà ouverte était réutilisée pour n’importe quelle autre demande de connexion Gmail ;
  • Les résultats ne disaient jamais sous quel compte un appel avait tourné.

Pour une personne sur une seule machine, c’est juste agaçant. Dès que le même gateway sert plusieurs personnes, cela devient un problème de contrôle d’accès — le mur sur lequel la communauté est tombée dans l’issue #15602, en branchant un même gateway Hermes sur le Gmail de deux personnes à la fois.

Les comptes ont un nom : l’alias

Le nouveau build donne à chaque compte un nom court, appelé alias dans le format d’échange : 1 à 32 lettres minuscules, chiffres ou tirets, commençant par une lettre ou un chiffre. Un compte sans alias s’affiche avec le label fourni par l’app elle-même.

La règle est simple : dès qu’une app a deux comptes actifs, le gateway ajoute un champ connector_alias au schema du tool de ce connector, avec la liste des noms acceptés. Le modèle en passe un dans l’appel :

tool_call  connectors__gmail__SEND_EMAIL
           {"connector_alias": "work", ...}

Le résultat renvoie account, et le label live du tool s’affiche sous la forme Gmail · send email (work). Un coup d’œil suffit pour savoir quelle identité a envoyé le mail.

Outre le nom, plusieurs choses ont changé :

  • Les objets target de manage_connections acceptent alias (quel compte) et to (le nouveau nom), plus une nouvelle action rename. Un appel avec alias porte sur cette seule target ; les targets MCP refusent les deux champs ;
  • connect avec un nom demande ce compte précis au gateway : il en ajoute un nouveau, ou répond connected quand un compte actif porte déjà ce nom ;
  • reconnect avec un nom lit la ligne propre à ce compte plutôt que le flag global du connector, et répare donc celui qui est cassé pendant que le compte sain continue de tourner. Si cette ligne est illisible, le tool remonte l’erreur au lieu de créer discrètement un nouveau compte ;
  • status liste les comptes de chaque connector avec alias, label, status et active.

Le CLI : hermes connectors

Une nouvelle commande couvre l’affichage, la connexion, le renommage et la suppression :

hermes connectors list
hermes connectors accounts
hermes connectors accounts gmail --all
hermes connectors connect gmail --alias home
hermes connectors rename gmail work --to office
hermes connectors disconnect gmail --alias home --yes
Sous-commande Ce qu’elle fait
list (alias ls) Tous les connectors et s’ils sont connectés
accounts [app] [--all] Comptes connectés ; les lignes retirées sont repliées sauf si vous passez --all
connect <app> [--alias NAME] [--reconnect] [--force] Connecte un nouveau compte ; --reconnect répare un compte cassé ; --force reconnecte un compte sain
rename <app> <name-or-label> --to <new> Renomme un compte
disconnect <app> [--alias NAME] [--yes] Supprime un compte ; sur un stdin non interactif, --yes est obligatoire

Quelques détails à connaître avant de les taper :

  • connect affiche le lien de login et attend que le compte se stabilise ou que le délai expire. Ctrl-C ferme le connect en cours et sort en 130, pour que le connect suivant de la même app ne soit pas bloqué ;
  • Un nom qui casse le format, ou qu’un autre compte vivant de la même app porte déjà, est refusé avant qu’aucune requête ne parte ;
  • Avec plus d’un compte sur une app, une commande sans --alias échoue et liste les noms parmi lesquels choisir.

L’overlay /connectors dans le TUI

Tapez /connectors dans l’interface terminal et un overlay flottant s’ouvre, avec une ligne par compte indiquant app, nom et statut :

  • r renomme sur place — Entrée valide, Échap annule ;
  • a ajoute un compte : choisissez l’app, tapez un nom, ouvrez le lien. L’overlay attend que le compte se stabilise, que le lien expire ou que le gateway refuse ;
  • c reconnecte le compte sélectionné. Il ne supprime jamais rien, un compte sain répond aussitôt connected, et une ligne sans nom vous demande d’en donner un d’abord ;
  • x supprime le compte sélectionné après le prompt de confirmation partagé du TUI ;
  • Tab affiche ou replie les comptes retirés, qui ne peuvent pas être reconnectés tant qu’ils sont repliés.

Une règle prudente s’applique de bout en bout : tant qu’une question ou une confirmation de l’agent est ouverte, l’overlay cesse de lire les touches, pour qu’une réponse à un prompt ne puisse pas supprimer un compte par accident.

L’app de bureau

Sous Capabilities → Connectors, chaque app liste désormais tous ses comptes, avec les actions nommer, renommer, ajouter, reconnecter et supprimer ; la suppression passe par une confirmation. Quand l’agent nomme un nouveau compte, le chat indique le nom choisi — par exemple « Hermes a nommé ce compte Gmail work. Renommez-le quand vous voulez. » C’est l’agent qui choisit le nom ; aucun prompt de nom à remplir.

Réserves

  • La connexion au Nous Portal est obligatoire. Les connectors sont des tools hébergés, donc hermes login passe en premier ; sans cela, la commande vous invite à vous connecter au lieu d’échouer avec un message obscur.
  • Le renommage attend le Portal. Tant que le Portal ne livre pas la route de rename, rename répond « This Nous Portal cannot rename connector accounts yet. » et l’éditeur de bureau affiche ce refus puis restaure l’ancien nom. Tout le reste fonctionne.
  • La suppression d’un compte reste à votre main. Le CLI vous demande de confirmer, le bureau vous demande de cliquer. Aucun flux automatique ne supprime un compte à votre place.
  • Status : ce travail (PRs #135097 / #135151 / #135173) a été mergé sur main le 2026-10-11. La release taguée actuelle, v0.21.6 du 8 octobre, ne le contient pas encore — il arrivera avec la prochaine release.
  • Les connectors n’existent que pour les comptes Nous connectés, ce qui explique que hermes connectors list puisse répondre « Connectors are not available. Sign in with hermes login first. »

Pour finir

« Prends celle du boulot » est désormais une consigne que l’agent peut réellement exécuter : le compte porte un nom, le modèle l’indique dans l’appel, le résultat dit quelle identité a tourné, et une réparation ne touche que le compte cassé. Nommer vous coûte une commande et vous offre une traçabilité sur chaque action sortante — ce qui compte bien plus que le confort quand une machine détient à la fois vos logins pro et perso.

Si la couche connectors est nouvelle pour vous, commencez par comment fonctionne la recherche de tools, puis voyez d’où viennent les tools hébergées dans le catalogue MCP distant officiel. Vous installez Hermes pour la première fois ? Le guide d’installation est le point de départ.