Vous est-il déjà arrivé de fixer une page de résultats GitHub à la recherche de plugins Hermes, en vous demandant lequel de ces dépôts qui se ressemblent tous est réellement maintenu — et ce que le code fera sur votre machine une fois installé ? Cette hésitation est légitime : un plugin Hermes est du Python qui s’exécute à l’intérieur du processus de l’agent, si bien qu’en installer un revient moins à ajouter une dépendance qu’à remettre la clé de votre maison à un inconnu.

La PR #69446, fusionnée le 9 septembre, vise exactement cette douleur : Hermes embarque désormais un catalog de plugins soumis à un examen humain qui règle découverte et confiance au même endroit. Finie la chasse sur GitHub : vous lancez hermes plugins search contre un index officiel et curaté. Fini le pari sur un README : chaque entrée du catalog est épinglée sur un commit exact et doit déclarer ses capacités d’emblée — vous savez donc ce que vous installez avant de l’installer.

Ce qu’est le catalog de plugins

D’abord, une distinction : il s’agit ici de plugins natifs in-process — les extensions qui s’exécutent dans Hermes, enregistrent leurs propres tools et hooks et se gèrent via plugins.entries. C’est une autre couche que le catalog de serveurs MCP, qui connecte des services externes par Model Context Protocol. Le catalog MCP répond à « comment joindre des services externes ? », le catalog de plugins à « comment étendre Hermes lui-même ? ».

Concrètement, le catalog est un ensemble de fichiers YAML dans le répertoire plugin-catalog/ du dépôt — un fichier par entrée de plugin :

name: hermes-telegram-business   # clé unique du catalog ; installation par ce nom
repo: https://github.com/NousResearch/hermes-telegram-business
sha: e905f3bc5eeaa5a9dab9bc5155601b3ebec75757  # SHA complet de 40 caractères
description: One-line description
maintainer: NousResearch
tier: official          # official ou community
platforms: []           # vide = toutes les plateformes
capabilities:           # ce que ce plugin prétend enregistrer
  provides_tools: []
  provides_hooks: []
  provides_middleware: []
  requires_env: []

Le catalog démarre avec 7 entrées initiales : 3 officielles (plugin-llm-example, plugin-llm-async-example, hermes-telegram-business) et 4 communautaires (hermes-plugin-chrome-profiles par @anpicasso, hermes-snapcompact, jackal-verified, herdr-auto-reconcile). Les entrées officielles proviennent des dépôts de NousResearch ; les communautaires, de mainteneurs indépendants — chrome-profiles bascule les tools du navigateur entre des profiles Chrome/Edge locaux et distants via CDP, et snapcompact archive l’historique de conversation en trames bitmap denses que les modèles de vision relisent pour environ un tiers du coût en tokens.

Rechercher, installer, lister : les trois commandes qui comptent

Tout tourne autour de hermes plugins. À noter : la fonctionnalité a atterri sur main le 9 septembre et ne figure encore dans aucune release — la dernière release officielle, v0.21.1 (7 septembre), lui est antérieure. Pour l’utiliser dès aujourd’hui, il vous faut un build qui contient la fusion.

Recherche dans tout le catalog — sans argument, tout est listé ; un mot-clé matche noms, descriptions et tools déclarés :

hermes plugins search
hermes plugins search telegram      # matche le nom/description/tools mentionnant telegram
hermes plugins search --json        # lisible par machine, pour les scripts

Installation — par nom nu du catalog, par URL Git ou par le raccourci owner/repo :

hermes plugins install hermes-telegram-business   # entrée du catalog : installe le SHA épinglé et vérifié
hermes plugins install anpicasso/hermes-plugin-chrome-profiles  # owner/repo = source personnalisée (non vérifiée)
hermes plugins install https://github.com/xxx/my-plugin          # URL Git complète

Cette distinction de source est le cœur du modèle de confiance. Un nom nu qui correspond au catalog installe le commit exact qui a été audité, affiche le tier et l’épingle ([official] pinned @ e905f3bc), montre le résumé des capacités et consigne la provenance dans un fichier .hermes-catalog.json accolé au plugin. Une URL Git ou un raccourci owner/repo affiche un avertissement jaune « source personnalisée (non vérifiée) » — dans ce cas, vous êtes seul face à votre code. Dans les deux cas, la question vous est posée d’activer ou non le plugin sur-le-champ ; installé ne signifie pas activé, et l’invite d’activation montre ce que le plugin souhaite enregistrer.

Voyez ce que vous avez installé :

hermes plugins list
hermes plugins list --plain          # texte brut compact au lieu d'un tableau Rich
hermes plugins show hermes-telegram-business   # détails d'un plugin

Le modèle de confiance : pourquoi le catalog justifie sa place

La crédibilité du catalog n’est pas un badge — c’est une chaîne de mécanismes imposés, documentée dans le README du catalog :

• Admission par examen humain. Une entrée n’arrive que par une PR sur le dépôt hermes-agent, relue et fusionnée par un maintainer. Pas de registre en libre-service, pas d’ingestion automatisée.
• Épinglage sur un commit exact, obligatoire. Chaque entrée exige un SHA complet de 40 caractères. Les branches, les tags et les SHA courts sont rejetés. L’installation extrait ce commit exact — jamais le dernier HEAD — si bien que ce que dit le catalog et ce que vous exécutez sont le même code.
• Deux semaines de maturation pour chaque épingle. Une version épinglée doit être âgée d’au moins deux semaines au moment de l’épinglage, en écho à la politique de supply chain appliquée aux autres dépendances épinglées — le temps que la communauté repère une release compromise avant que Hermes n’en propage le pointeur.
• Chaque mise à jour d’épingle est une nouvelle PR. Modifier le SHA d’une entrée, c’est une PR neuve, relue de zéro, dont le diff (ancien SHA → nouveau SHA) constitue la surface de revue. Chaque mouvement de pointeur passe sous les yeux d’un humain qui examine la plage de commits en amont.
• Les capacités déclarées doivent correspondre à la réalité. hermes plugins validate charge le plugin dans un sous-processus jetable et compare les provides_tools/provides_hooks déclarés à ce que register(ctx) enregistre réellement. Toute divergence fait échouer l’entrée — l’ajout silencieux de capacités non déclarées est traité comme un problème de sécurité. La CI d’admission exécute ce contrôle sur chaque entrée modifiée.
• Retrait = liste noire. Quand une entrée est retirée pour des raisons de sécurité ou de politique, elle atterrit dans removed.yaml, et toute installation correspondant à son nom ou à son dépôt est refusée sur toutes les surfaces (CLI, dashboard, desktop). La CLI dispose d’une porte de sortie explicite --allow-removed qui imprime un avertissement rouge ; les autres surfaces n’en ont pas.

Le catalog solde également un pan d’histoire : l’index communautaire provisoire des plugins pointait vers une URL de dépôt canonique qui n’a jamais réellement existé et ne disposait d’aucun contrôle d’admission. Ce changement supprime entièrement cet index et regroupe tout dans le catalog du dépôt.

Valider, mettre à jour et gérer au quotidien

Une fois les plugins installés, les commandes habituelles du cycle de vie s’appliquent :

hermes plugins update hermes-telegram-business   # les entrées du catalog se ré-épinglent sur le SHA vérifié
hermes plugins disable hermes-telegram-business  # désactive sans supprimer
hermes plugins enable hermes-telegram-business   # ré-active
hermes plugins remove hermes-telegram-business   # désinstalle (alias : rm, uninstall)
hermes plugins capabilities                      # capacités déclarées vs accordées, par plugin

Vous écrivez un plugin et souhaitez le voir référencé ? hermes plugins validate <plugin-dir> est exactement le même contrôle qu’exécute la CI d’admission — réussissez-le en local avant d’ouvrir la PR, et hermes plugins doctor va plus loin en vérifiant les contrats d’exécution réels. Les clients rafraîchissent le catalog à partir du JSON du site de documentation (/docs/api/plugin-catalog.json) au plus toutes les 6 heures et retombent sur la copie du dépôt hors ligne : une coupure réseau ne bloque donc jamais une installation.

Un dernier rappel sur le plancher de sécurité : les plugins s’exécutent dans le processus Hermes, le catalog réduit donc le risque — il ne le ramène pas à zéro. Après toute installation, un coup d’œil périodique à hermes plugins capabilities vaut la peine pour voir ce que chaque plugin détient réellement. Pour le mécanisme plugin lui-même — configuration et écriture de vos propres plugins — notre guide du plugin pip model-provider fait le tour de la question ; combiné au catalog de serveurs MCP, les canaux officiels couvrent désormais l’essentiel de ce que vous bricoleriez sinon à la main.