Imaginez : votre équipe exploite en interne une passerelle d’inférence partagée, qui sert vos propres modèles fine-tunés ainsi que quelques modèles tiers via un proxy. À chaque mise en production d’un nouveau modèle, vous devez modifier à la main le config.yaml de Hermes — endpoint, clé API, noms de modèles, champ par champ — puis chaque collègue répète le même rituel sur sa propre machine. Ne serait-il pas génial d’empaqueter « comment parler aux modèles de notre entreprise » dans un seul paquet, que n’importe qui pourrait simplement pip install puis utiliser ? La PR #85504, fusionnée le 13 août, transforme ce rêve en réalité : les fournisseurs de modèle peuvent désormais être de simples paquets Python qui s’enregistrent eux-mêmes via des entry points. Une fois installés, Hermes les découvre au démarrage et leurs modèles apparaissent dans le registre des modèles, exactement comme ceux des fournisseurs intégrés.

Le mécanisme : un seul entry point pour l’enregistrement

Un fournisseur (provider) est la couche d’adaptation de Hermes pour « comment joindre un service de modèles » : il connaît la forme de l’endpoint, l’emplacement de la clé API et la manière d’envoyer les requêtes. Auparavant, les fournisseurs ne pouvaient être enregistrés que via les plugins fichiers ou l’ensemble intégré. La PR #85504 ajoute une « étape 0 » au flux de découverte dans providers/__init__.py : scanner les entry points de chaque distribution Python installée et repérer quiconque se déclare fournisseur.

La configuration est minime : dans le pyproject.toml de votre paquet, déclarez un entry point pointant vers une fonction d’enregistrement sans argument :

[project.entry-points."hermes_agent.plugins"]
acme-inference = "acme_hermes_plugin:register"

La fonction register() construit un ProviderProfile et appelle register_provider() :

# acme_hermes_plugin.py
from providers import register_provider
from providers.base import ProviderProfile

def register():
    register_provider(
        ProviderProfile(
            name="acme-inference",
            display_name="Acme Inference",
            base_url="https://inference.internal.acme.com/v1",
            env_vars=("ACME_API_KEY",),
            auth_type="api_key",
        )
    )

Les champs du ProviderProfile sont exactement ce que « se connecter à un service de modèles » exige : nom, nom d’affichage, endpoint par défaut, variable d’environnement qui contient la clé API, type d’authentification, plus des options facultatives comme une liste de modèles de repli (fallback_models). Les plugins fournisseurs de type répertoire décrits dans la documentation officielle ($HERMES_HOME/plugins/model-providers/<name>/__init__.py) utilisent la même API — le mécanisme d’entry point remplace simplement « déposer un répertoire » par « pip install » ; le code d’enregistrement, lui, est identique.

Outre la forme appelable module:func, l’entry point peut aussi être un simple nom de module (acme-inference = "acme_hermes_plugin") — Hermes importe le module et s’appuie sur son appel register_provider au niveau du module, reprenant le contrat __init__.py des plugins fichiers. Une fois installé et activé via la porte décrite ci-dessous, Hermes l’invoque au démarrage et vos modèles apparaissent dans le sélecteur hermes model et partout où les fournisseurs sont listés.

La porte critique : installé ≠ activé

C’est la règle la plus importante de tout le mécanisme, alors lisez-la deux fois : installer un paquet avec pip ne signifie pas qu’il se charge. Le scan des entry points partage les mêmes commutateurs que le gestionnaire de plugins général — la allow-list plugins.enabled et la deny-list plugins.disabled :

plugins:
  enabled:
    - acme-inference   # seuls les entry points listés ici sont chargés
  disabled:
    - some-other-plugin  # la deny-list gagne toujours

Si le nom de votre paquet ne figure pas dans plugins.enabled, Hermes ne l’importe même pas — un paquet pip n’est jamais exécuté simplement parce qu’il est installé. C’est important pour la sécurité : n’importe quel paquet que vous pip install pourrait déclarer silencieusement un entry point hermes_agent.plugins, mais seul celui que vous avez explicitement mis sur la allow-list a réellement un effet.

Les détails de sécurité à connaître

Au-delà de la porte de la allow-list, la conception ajoute plusieurs couches de protection :

• Une voie réservée aux fournisseurs : le groupe d’entry points hermes_agent.plugins est partagé avec les plugins généraux (plugins d’interface, plugins d’outils, etc.). La différence : les fonctions d’enregistrement des plugins généraux prennent un argument (register(ctx)), tandis que les hooks d’enregistrement des fournisseurs sont sans argument par contrat. Le scanner ignore toute fonction appelable qui exige des arguments, de sorte que les plugins généraux ne sont jamais confondus avec des fournisseurs — et vous n’avez pas non plus un déluge d’avertissements TypeError.
• Un paquet défectueux ne peut pas faire tomber Hermes : si l’entry point d’un paquet tiers échoue à se charger, l’échec est avalé entrée par entrée et journalisé comme un avertissement ; la découverte des fournisseurs continue. Un mauvais paquet n’empêchera pas Hermes de démarrer.
• Les fournisseurs intégrés gagnent toujours les collisions de noms : le scan des entry points s’exécute en premier dans l’ordre de découverte, et register_provider() suit la règle du dernier écrit gagnant (last-writer-wins) — un paquet pip ne peut donc jamais masquer un fournisseur fourni avec Hermes ni un fournisseur sous $HERMES_HOME. Il peut enregistrer un nom entièrement nouveau, mais il ne peut pas détourner un nom propriétaire existant.

Quand cela vaut la peine

• Partager une intégration de modèles au sein d’une équipe : empaquetez votre passerelle interne en paquet pip ; vos collègues lancent pip install plus une ligne de allow-list et c’est terminé — plus de modification d’endpoint machine par machine.
• Modèles privés / auto-hébergés : fine-tunes internes, clusters vLLM auto-hébergés — empaquetez le fournisseur, versionnez-le avec pip, mettez-le à jour avec pip install -U.
• Publier pour le monde entier : si votre intégration de fournisseur a une valeur générale, publiez-la sur PyPI — n’importe qui peut l’installer et l’activer avec une configuration d’une ligne.

Si vous étendez déjà les outils de Hermes avec MCP (voir notre guide de configuration MCP et des variables de contexte), les plugins fournisseurs complètent l’autre moitié du tableau : MCP gère les outils, les fournisseurs gèrent les modèles — deux intégrations déclaratives, l’une via le protocole MCP, l’autre via les entry points. Toute la surface CLI des plugins est décrite sur la page de commande hermes plugins ; et un rappel — dans les configurations multi-profils, plugins.enabled se configure profil par profil (voir le guide des profils multi-instances), alors ne supposez pas qu’une allow-list définie dans un profil s’applique partout.

En une ligne : les plugins fournisseurs transforment « brancher un nouveau service de modèles », qui relevait de la modification manuelle de la configuration, en « pip install + une ligne de allow-list » — la friction se situe dans la sécurité (la allow-list est explicite), le confort dans l’ingénierie (empaqueté, partageable, versionné).