Compétences de l'assistant Hermes pour des environnements de production réels

L’assistant IA Hermes, officiellement documenté sous le nom de Hermes Agent, n’est pas positionné comme un simple wrapper de chat.

Pour l’installation, la configuration du fournisseur, le sandboxing des outils et la configuration de la passerelle, consultez le guide de l’assistant IA Hermes. Les interfaces CLI quotidiennes (hermes profile, hermes skills, hermes cron et commandes associées) sont résumées dans la fiche de référence de la CLI de l’Agent Hermes. Cet article se concentre sur l’architecture des compétences et des profils qui détermine le comportement de Hermes une fois qu’il est en cours d’exécution. Pour des conseils concrets sur la rédaction des fichiers SKILL.md — champs de frontmatter, structure des répertoires, secrets par rapport à config.yaml, et compétences qui disparaissent des commandes slash — consultez Rédaction de compétences pour l’Agent Hermes — Structure et meilleures pratiques de SKILL.md.

La documentation officielle et le dépôt décrivent un agent capable de s’améliorer, doté d’une boucle d’apprentissage intégrée qui crée des compétences à partir de l’expérience, les améliore pendant l’utilisation, persiste la connaissance entre les sessions et s’exécute sur n’importe quoi, d’un VPS à bas coût aux sandboxes cloud.

En avril 2026, le dépôt public GitHub affiche environ 94,6k étoiles, 13,2k forks et une dernière version tagguée v0.10.0 le 16 avril 2026. C’est suffisamment d’activité pour qualifier le projet de rapide, bien adopté et encore jeune sur le plan opérationnel.

Cette double nature est importante pour la conception en production. Hermes est assez mature pour supporter un travail réel, mais assez dynamique qu’une configuration désordonnée vieillira mal. L’article ci-dessous traite de la configuration et des compétences comme une question d’architecture opérationnelle, et non comme une liste de fonctionnalités.

Pourquoi Hermes a besoin d’une architecture centrée sur les profils

Les compétences de Hermes sont des documents de connaissances sur demande. Elles utilisent une divulgation progressive pour que l’agent puisse voir d’abord un index de compétences compact et ne charger le contenu complet des compétences que lorsqu’il est nécessaire, ce qui maintient l’utilisation des tokens sous contrôle même lorsque de nombreuses compétences sont installées. Chaque compétence installée devient une commande slash dans la CLI et dans les interfaces de messagerie, et la documentation positionne explicitement les compétences comme le mécanisme d’extension préféré lorsqu’une capacité peut être exprimée avec des instructions, des commandes shell et des outils existants plutôt qu’avec du code d’agent personnalisé.

La complication en production est que Hermes traite les compétences comme un état vivant, et non comme des packages figés. Les compétences intégrées, les compétences installées via le hub et les compétences créées par l’agent résident toutes sous ~/.hermes/skills/, et la documentation indique que l’agent peut modifier ou supprimer des compétences. Le même système expose des actions de création, de patch, d’édition, de suppression et de fichiers de support pour la gestion des compétences. C’est puissant, mais cela signifie aussi qu’un agent “tout-faire” surdimensionné a tendance à devenir un tiroir à procédures en désordre.

Les profils sont la réponse. Les profils Hermes sont des environnements entièrement isolés, chacun avec son propre config.yaml, .env, SOUL.md, mémoires, sessions, compétences, jobs cron et base de données d’état. La CLI transforme également un profil en son propre alias de commande, de sorte qu’un profil nommé coder devient coder chat, coder setup, coder gateway start, et ainsi de suite. En pratique, cela fait des profils l’unité réelle de propriété en production, et non la compétence individuelle.

La base de production

La forme de base est étonnamment épurée. Hermes stocke le comportement non confidentiel dans ~/.hermes/config.yaml, les secrets dans ~/.hermes/.env, l’identité dans SOUL.md, les faits persistants dans memories/, les connaissances procédurales dans skills/, les jobs planifiés dans cron/, les sessions dans sessions/ et les journaux dans logs/. La commande hermes config set achemine les clés API vers .env et tout le reste vers config.yaml, et l’ordre de priorité documenté est d’abord les drapeaux CLI, puis config.yaml, puis .env, puis les valeurs par défaut intégrées. C’est aussi la réponse la plus propre à la FAQ de production sur la manière de séparer les secrets et la configuration.

Une disposition multi-profil pratique se termine généralement par quelque chose comme ceci, avec un profil par responsabilité plutôt qu’un profil par humain :

~/.hermes/profiles/
  eng/
  research/
  ops/
  execops/
  ml/

Ce modèle correspond à la manière dont les profils Hermes sont documentés : chaque profil est un environnement isolé, et les profils peuvent être clonés à partir d’une configuration de base lorsque des valeurs par défaut communes sont utiles. La documentation note également que les profils ne partagent pas la mémoire ou les sessions, et que les compétences mises à jour peuvent être synchronisées entre les profils lorsque l’installation principale est mise à jour.

La prochaine limite de production est l’exécution. Hermes prend en charge six backends terminaux - local, Docker, SSH, Modal, Daytona et Singularity - et la documentation de sécurité décrit un modèle de défense en profondeur qui inclut l’approbation des commandes dangereuses, l’isolation des conteneurs, le filtrage des identifiants MCP, l’analyse des fichiers de contexte, l’isolation inter-sessions et la sanitisation des entrées. En d’autres termes, la décision “profil d’abord” répond à la question de qui possède l’état, et la décision du backend répond à la question de savoir où le travail risqué est autorisé à se produire.

L’automatisation repose sur cette base. Les jobs cron Hermes peuvent attacher zéro, un ou plusieurs compétences, et ils s’exécutent dans des sessions d’agent fraîches plutôt que d’hériter du chat actuel. La passerelle de messagerie est également le processus en arrière-plan qui gère les sessions, exécute cron et achemine les résultats vers des plateformes comme Telegram, Discord, Slack, WhatsApp, Email, Matrix et autres. Le guide officiel MCP ajoute une règle de production supplémentaire qu’il est facile de passer sous silence : le meilleur modèle n’est pas de connecter tout, mais d’exposer la surface utile la plus petite. Pour l’exécution multi-agent de style file d’attente sur des modèles auto-hébergés, utilisez Kanban dans l’Agent Hermes pour les flux de travail LLM auto-hébergés comme guide compagnon. Si votre disposition de production place Hermes sur une machine sans interface graphique et que les opérateurs se connectent depuis des clients de bureau, utilisez Configuration du serveur sans interface et du bureau distant de l’Agent Hermes pour la topologie réseau et de service.

Le profil d’ingénierie logicielle

La persona la plus évidente de Hermes est l’ingénieur logiciel qui souhaite que l’agent se comporte moins comme une fenêtre de chat et plus comme un opérateur de dépôt reproductible. Ce profil s’intéresse généralement à l’authentification du dépôt, au tri des problèmes, à la création de PR, à la revue de code, au débogage et à l’exécution soutenue par un plan. Dans les catalogues Hermes, le pack de compétences intégré de base est inhabituellement cohérent pour ce travail : github-auth, github-issues, github-pr-workflow, github-code-review, code-review, plan, writing-plans, systematic-debugging et test-driven-development. Si la délégation est importante, Hermes fournit également des compétences d’agent autonomes intégrées telles que codex, claude-code, opencode et hermes-agent-spawning.

Ce qui rend ce pack utile n’est pas une compétence individuelle. C’est la manière dont les compétences codent la procédure de développement. github-pr-workflow couvre le cycle de vie complet des PR, github-issues formalise les opérations sur les problèmes, github-code-review et code-review font de la revue une étape distincte plutôt qu’une pensée après coup, et systematic-debugging empêche l’agent de sauter directement vers des correctifs prématurés. Cela répond également à la question pratique de quelles compétences d’assistant IA sont les plus importantes pour les flux de travail de codage. Les compétences à plus haute valeur sont généralement celles qui verrouillent l’hygiène du dépôt et la discipline de revue, et non celles qui promettent plus de génération de code brute.

La délégation de Hermes renforce ce profil davantage. La plateforme peut générer des agents enfants isolés avec leur propre conversation, session terminale et ensemble d’outils, et seul le résumé final est retourné au parent. Pour les bases de code, c’est un ajustement plus propre que de bourrer chaque diff intermédiaire, trace de pile et note de revue dans une seule conversation. En termes de production, le profil d’ingénierie bénéficie de jeux de compétences restreints, d’un backend sandboxé tel que Docker ou SSH, et d’une utilisation généreuse de la délégation lorsque le bruit contextuel commence à dominer.

Le profil de recherche et de connaissances

Le profil de recherche est là où Hermes commence à se distinguer des assistants ordinaires. Les catalogues intégrés incluent déjà arxiv, duckduckgo-search, blogwatcher, llm-wiki, ocr-and-documents, obsidian, domain-intel et ml-paper-writing, tandis que le catalogue officiel optionnel ajoute qmd, parallel-cli, scrapling et un niveau de recherche plus large pour des domaines spécialisés. Cette pile couvre la recherche de papiers, la surveillance des sources, le OCR, les systèmes de notes locaux, la reconnaissance de domaine, la rédaction et la récupération hybride sans tout forcer dans un seul modèle RAG.

Ce profil est également l’endroit le plus clair pour répondre à la question mémoire versus compétences. La documentation de Hermes définit la mémoire comme des faits sur les utilisateurs, les projets et les préférences, tandis que les compétences stockent les procédures pour savoir comment faire les choses. Le travail de recherche a besoin des deux. La mémoire retient ce que l’assistant a déjà appris sur le domaine et les préférences du lecteur ; les compétences codent des procédures reproductibles telles que “scanner arXiv, résumer les nouveaux papiers et écrire des notes dans Obsidian”. Cette distinction est importante car les systèmes de recherche en production échouent lorsque tout est traité comme une mémoire ou tout est traité comme un flux de travail. Hermes donne à ces préoccupations des domiciles séparés. Pour l’image technique complète du fonctionnement de la mémoire — l’architecture à deux fichiers, les limites de caractères, le préfixe caching et les huit options de fournisseur externes — consultez Système de mémoire de l’Agent Hermes.

Le profil de recherche bénéficie également de manière disproportionnée de cron. Les jobs cron Hermes peuvent explicitement charger des compétences avant l’exécution, et les guides d’automatisation insistent sur le fait que les invites planifiées doivent être entièrement autonomes car elles s’exécutent dans des sessions fraîches. Un pipeline récurrent combinant blogwatcher, arxiv, obsidian ou llm-wiki est donc plus fiable qu’un job vague “vérifier ce qui a changé aujourd’hui”. En d’autres termes, les profils de recherche fonctionnent mieux lorsque la découverte de sources, la rédaction de notes et le stockage à long terme sont chacun représentés par une compétence nommée plutôt que cachés dans une longue invite en langage naturel.

Le profil d’automatisation et d’opérations

Le profil des opérations est moins glamour et souvent plus valuable. C’est l’utilisateur qui souhaite que Hermes réagisse aux événements, inspecte les systèmes, exécute des vérifications scriptées, achemine la sortie vers un canal et fasse tout cela sans transformer l’hôte en une responsabilité. Hermes possède les bons blocs de construction pour ce style de travail : webhook-subscriptions intégré pour l’activation pilotée par événements, native-mcp et mcporter intégrés pour les outils basés sur MCP, et des compétences officielles optionnelles telles que docker-management, fastmcp, cli et 1password lorsque le flux de travail s’étend aux conteneurs, aux serveurs MCP personnalisés ou à l’injection de secrets.

La raison pour laquelle ce pack fonctionne est que chaque compétence possède une frontière. webhook-subscriptions gère l’ingress des systèmes externes. docker-management transforme les corvées de conteneur en une procédure nommée plutôt qu’en un jeu de shell libre. fastmcp est utile lorsque Hermes doit devenir l’orchestrateur autour de nouveaux outils MCP, et 1password garde la gestion des secrets explicite plutôt que cachée dans l’historique du shell ou les fichiers markdown. Les conseils officiels MCP renforcent le même instinct de production : connecter la bonne chose avec la surface utile la plus petite. Lorsque ce profil d’opérations est consommé via des interfaces de chat mobiles, les détails d’implémentation sont couverts dans Contrôle vocal de Hermes depuis votre téléphone.

Ce profil est également l’endroit le plus propre pour répondre à la question de savoir comment les flux de travail IA planifiés restent fiables. La documentation cron de Hermes indique que les jobs s’exécutent dans des sessions fraîches, peuvent attacher une ou plusieurs compétences, et doivent utiliser des invites autonomes. Le guide de dépannage cron ajoute que le déclenchement automatique dépend du ticketer de la passerelle plutôt que d’une session de chat CLI ordinaire. Ainsi, le modèle fiable est simple même si l’implémentation ne l’est pas : compétences explicites, cible de livraison explicite, invite autonome, backend isolé et une passerelle qui est réellement en cours d’exécution.

Le profil des opérations exécutives

Il existe une persona Hermes plus silencieuse mais très réelle qui ressemble à un chef de staff, un responsable des opérations ou un fondateur surchargé. Les compétences pertinentes sont moins flashy et plus orientées bureau : google-workspace, notion, linear, nano-pdf, powerpoint, et la compétence email intégrée himalaya, plus des compétences officielles optionnelles telles que agentmail, telephony et one-three-one-rule. Ce mélange donne à Hermes l’accès à la boîte de réception, au calendrier, aux documents, aux tâches, aux présentations, au nettoyage PDF, à un cadre de communication structuré et même aux flux de travail de téléphone et SMS lorsque cela compte vraiment.

Le flux ici est plus important que le catalogue. google-workspace ancre l’exécution quotidienne. Notion et Linear empêchent l’assistant de devenir le système de tâches de référence. one-three-one-rule est surprenamment utile car le support décisionnel est souvent la chose la plus difficile à standardiser, et cette compétence donne à Hermes une procédure nommée pour les propositions plutôt qu’un comportement générique “résumez ceci”. nano-pdf et powerpoint sont ce genre de multiplicateurs opérationnels qui semblent petits jusqu’à ce qu’une équipe commence à toucher des présentations et des PDFs tous les jours.

Les fonctionnalités de messagerie et vocale de Hermes rendent ce profil plus pratique qu’il n’y paraît. La passerelle peut exposer l’agent via Slack, Telegram, Discord, WhatsApp, Email, Matrix et plusieurs autres canaux, et la pile vocale prend en charge l’entrée micro, les réponses vocales dans la messagerie et les conversations vocales Discord en direct. La documentation note également qu’une seule instance Hermes peut servir plusieurs utilisateurs via des listes d’autorisation et l’appariement de DM, tandis que les jetons de bot restent exclusifs à un seul profil. C’est pourquoi un déploiement lourd de communication bénéficie généralement d’au moins un profil dédié au lieu de partager la même identité de bot avec l’ingénierie ou les opérations.

Le profil de plateforme ML et données

Hermes est construit par un laboratoire de recherche, et cette lignée se voit. Les catalogues incluent jupyter-live-kernel pour le travail de style notebook avec état, huggingface-hub pour les opérations de modèles et de jeux de données, evaluating-llms-harness et weights-and-biases pour l’évaluation et le suivi des expériences, qdrant-vector-search pour le stockage RAG en production, et un grand niveau MLOps intégré et optionnel avec des compétences telles que axolotl, fine-tuning-with-trl, modal-serverless-gpu, lambda-labs-gpu-cloud, flash-attention, tensorrt-llm, pinecone, qdrant et nemo-curator.

Ce qui est notable ici n’est pas seulement la largeur. C’est que les compétences courent toute la pile, de l’itération de notebook à la curation de données, l’évaluation, la recherche vectorielle, le fine-tuning et l’optimisation d’inférence. Pour un utilisateur de plateforme ML, Hermes cesse de ressembler à un assistant et commence à ressembler à un plan de contrôle capable de transporter des procédures à travers le cycle de vie. jupyter-live-kernel gère l’exploration itérative, evaluating-llms-harness et weights-and-biases formalisent la mesure, et les compétences de calcul et d’optimisation optionnelles permettent à Hermes de parler de manière cohérente à la fois de l’expérimentation et du déploiement.

C’est aussi le profil où la retenue compte le plus. Parce que le catalogue MLOps optionnel est si vaste, une configuration Hermes en production pour le travail ML bénéficie généralement d’être opiniâtre sur la portée. Un profil d’ingénierie de plateforme qui possède l’évaluation et le déploiement n’a pas besoin de chaque framework d’entraînement installé. Un profil de recherche qui possède des papiers et des systèmes de notes n’a pas besoin de chaque compétence de base de données vectorielle. Hermes peut transporter d’immenses inventaires de compétences, mais l’utilité en production vient toujours de rétrécir la surface active.

Où les compétences deviennent des responsabilités

La partie la plus forte du système de compétences de Hermes est aussi l’endroit où les configurations de production échouent. Hermes peut parcourir et installer des compétences depuis son catalogue intégré, le catalogue officiel optionnel, skills.sh de Vercel, les points de terminaison de compétences bien connus, les dépôts GitHub directs et les sources communautaires de style marketplace. Le modèle de sécurité distingue entre les sources builtin, official, trusted et community, exécute des scans de sécurité pour les compétences installées via le hub, et permet --force uniquement pour les blocs de politique non dangereux. Un verdict de scan dangereux reste bloqué. Hermes expose également des métadonnées en amont telles que l’URL du dépôt, les installations hebdomadaires et les signaux d’audit pendant l’inspection. C’est un modèle de confiance solide, mais ce n’est pas un substitut au goût.

Il y a aussi une limite à ce qu’on doit demander à une compétence. La documentation de Hermes est explicite sur le fait que les compétences sont le choix préféré lorsque le travail peut être exprimé comme des instructions plus commandes shell plus outils existants, tandis que les plugins sont l’abstraction plus honnête pour les outils personnalisés, les hooks et le comportement du cycle de vie. Le guide des plugins montre même comment un plugin peut regrouper sa propre compétence. En production, cela signifie que les compétences sont mieux traitées comme des procédures réutilisables, et non comme un substitut forcé pour un design d’outil ou de plugin approprié.

La communauté et le support semblent sains, mais ils n’effacent pas la vitesse de changement. La documentation de Hermes dirige les utilisateurs vers Discord, GitHub Discussions, Issues et le Skills Hub, et le dépôt public montre des versions fréquentes et une grande empreinte de contribution. La conclusion opérationnelle est assez simple : les mises à jour font partie du système, et non un événement extérieur à celui-ci. Une configuration de production réelle suppose que les profils, les compétences et les hypothèses de flux de travail évolueront, puis utilise l’isolation et des packs de compétences étroits pour que le changement reste local lorsqu’il arrive inévitablement.

Hermes fonctionne mieux lorsque les compétences sont traitées comme des contrats procéduraux autour de profils clairement séparés. Le moment où un profil devient l’agent d’ingénierie, l’assistant de recherche, l’opérateur des opérations, le bot de boîte de réception et la plateforme ML tout à la fois, le système cesse de se composer et commence à fuir des responsabilités. Le modèle de production propre est moins question d’avoir plus de compétences et plus question de donner à chaque profil une description de poste qu’il peut réellement tenir.

Cet article fait partie du cluster Systèmes IA, qui couvre les assistants auto-hébergés, l’architecture de récupération, l’infrastructure LLM locale et l’observabilité.