Imaginez une machine qui porte plusieurs profiles : le vôtre, un partagé avec l’équipe, et un profile de démo pour les clients. Quelqu’un installe un plugin communautaire — une petite chose qui branche un système de tickets sur le chat. Dès qu’il est importé, ce plugin vit dans le même processus Python que chaque session, chaque identifiant de provider et chaque clé d’API en mémoire. Un auteur de plugin bien intentionné peut malgré tout livrer une variable globale, un monkeypatch ou un thread qui ne s’arrête jamais, et tout cela peut atteindre des choses qu’il n’aurait jamais dû toucher.

Hermes vous donne désormais un interrupteur pour ça : faire sortir les plugins tiers du processus principal. La configuration tient en une ligne, plugins.isolation: host, et le plugin lui-même ne change pas du tout.

Le défaut n’a pas changé ; le nouveau mode, c’est un host par profile

Soyons précis, car rien ne change tant que vous ne le demandez pas. Le défaut reste in_process : les plugins sont importés dans le processus Hermes, exactement comme avant. Seul un host explicite modifie le comportement.

plugins:
  isolation: host        # défaut : in_process
  host:
    launcher: []         # préfixe argv optionnel pour le host, par ex. un sandbox runner

Avec host, chaque profile obtient un processus Python distinct, démarré à la demande — le plugin host —, qui n’importe que les plugins installés par l’utilisateur de ce profile et dialogue avec Hermes via un pipe privé. Les plugins fournis (bundled) ne sont pas concernés et continuent de tourner in-process.

Un détail de conception est facile à manquer et compte beaucoup : le processus host démarre avec uniquement l’environnement et les secrets de ce profile. Un plugin voyait auparavant les identifiants que portait le processus ; il ne voit plus que ceux de son propre profile. Dans un déploiement multi-tenant, c’est le sens concret de « le code du plugin d’un locataire ne partage jamais la mémoire avec les données d’un autre ».

Les plugins ne changent pas : le même ctx, sérialisé à travers le pipe

Le point pénible de la plupart des histoires d’isolation, c’est qu’il faut réécrire du code. Ici, non.

À l’intérieur du host, un plugin reçoit le même ctx que toujours. Les tools, les hooks, les commandes slash, les commandes CLI, les skills et les objets provider (génération d’images et de vidéos, recherche web, navigateur, TTS/STT, mémoire, moteurs de contexte, cron) s’enregistrent exactement comme avant. Hermes enregistre de son côté des proxies correspondants qui appellent le host au besoin — la doc appelle l’objet remis aux plugins RemotePluginContext.

Il est aussi réentrant : pendant qu’il traite un appel d’outil, un plugin peut rappeler Hermes via ctx.dispatch_tool, ctx.get_config ou ctx.llm — et Hermes l’attend, comme si le plugin était encore local. Pour les auteurs de plugins, c’est une isolation pour ainsi dire gratuite.

Il y a un prix, et il est publié plutôt que découvert. Une poignée de surfaces ont réellement besoin de code in-process, et sous host ces plugins sont refusés avec une raison claire au lieu de perdre discrètement des fonctionnalités. La liste documentée : les adaptateurs de plateforme du gateway (register_platform), les transports d’approbation, les gestionnaires Telegram et d’autres plateformes, les profiles de model provider qui construisent leur propre client SDK (create_client), les endpoints de dashboard en streaming, et les plugins qui appliquent un monkeypatch aux modules Hermes. Lancez ceux-là avec isolation: in_process.

Les plantages restent dans le host

Le premier bénéfice de l’isolation n’est pas la sécurité, c’est la stabilité. Sous host :

• le module d’un plugin n’entre jamais dans le processus Hermes, il ne peut donc pas lire en mémoire les données d’un autre profile ni patcher les entrailles de Hermes ;
• un plugin qui plante ou se termine tue son host, pas Hermes. L’appel en cours renvoie une erreur d’outil, puis Hermes redémarre le host et recharge ses plugins (avec des retries bornés) pendant que toutes les autres sessions continuent de tourner.

Si vous avez déjà installé un plugin et vu tout le gateway tomber avec lui, cette section est pour vous.

L’activer, le vérifier, l’épingler

Activez-le avec le bloc de configuration ci-dessus. Deux commandes vous disent la vérité immédiatement :

# Vérifie si un plugin peut tourner en mode host ; explique tout refus
hermes plugins validate <dir>

# Voir où tourne un plugin précis
hermes plugins show <name>

host.launcher existe pour les configurations plus strictes : il prend un préfixe argv qui enveloppe le processus host dans votre propre sandbox runner. La doc recommande aussi de faire tourner le terminal de l’agent sur un backend isolé (Docker, SSH, etc.) — isoler le plugin alors que le terminal de l’agent peut toujours lire les fichiers de l’opérateur ne vous donne que la moitié de l’isolation.

Vient ensuite le problème le plus pratique dans les déploiements partagés : plugins.isolation est une config de profile ordinaire, donc quiconque peut modifier le config.yaml d’un profile peut la désactiver. Quand les profiles appartiennent justement aux personnes que vous isolez les unes des autres, épinglez plutôt la valeur dans le managed scope — un /etc/hermes/config.yaml appartenant à root, que chaque profile lit. La valeur managée l’emporte sur la config propre à chaque profile, et hermes config set refuse de la changer :

# /etc/hermes/config.yaml (propriété de root ; lu par chaque profile de la machine)
plugins:
  isolation: host
  host:
    launcher: [...]

Quelle part du catalogue est prête

L’inquiétude évidente : si j’active ça, mes plugins installés continueront-ils de fonctionner ?

La doc donne le chiffre au moment de la rédaction : 299 des 348 entrées du catalogue de plugins tournent dans le host sans modification. C’est là la vraie valeur de la liste des non pris en charge ci-dessus — elle transforme « est-ce que ça va casser ? » en une courte liste vérifiable, plutôt qu’en une expérience menée sur votre propre machine.

Quand vous pourrez l’avoir

La fonctionnalité a été fusionnée sur la branche main le 3 octobre 2026. La dernière release est la v0.21.5 (tag v2026.9.24), donc elle ne vit pour l’instant que sur main et n’est encore dans aucune release taggée. Les installations qui suivent main la récupèrent à leur prochain hermes update ; les utilisateurs de releases l’auront au prochain tag.

Pour le système de plugins au sens large — sources d’installation, allow-list d’activation, répertoires de sous-catégories — voyez le guide du catalogue de plugins. Les retraits du catalogue et les règles de chaîne d’approvisionnement sont traités dans l’article sur le gate CI du catalogue, et si votre douleur est « je dois redémarrer avant qu’un changement de plugin prenne effet », le guide du rewire de plugins à la volée correspond mieux.

La version courte

Installer un plugin signifiait autrefois inviter le code de quelqu’un d’autre dans votre processus. Désormais vous pouvez le garder dehors, et le plugin ne voit même pas la différence. Sur un portable mono-utilisateur, vous ne toucherez probablement jamais cette ligne. Sur une machine qui porte plusieurs personnes ou locataires, elle appartient à la catégorie des interrupteurs que l’on regrette de ne pas avoir activés avant l’incident, pas après.

Si vous exploitez un déploiement partagé, faites deux choses : lancez hermes plugins validate sur tout ce que vous avez installé, puis écrivez plugins.isolation: host dans le managed scope plutôt que de laisser chaque profile décider.