Compétences de l'assistant IA Hermes pour des configurations de production réelles

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

Pour l’installation, la configuration du fournisseur, l’isolation des outils (sandboxing) et la configuration de la passerelle, consultez le guide de l’assistant Hermes AI. Cet article se concentre sur l’architecture des compétences et des profils qui détermine le comportement de Hermes une fois en fonctionnement.

La documentation officielle et le dépôt décrivent un agent à amélioration continue avec une boucle d’apprentissage intégrée qui crée des compétences à partir de l’expérience, les améliore lors de l’utilisation, persiste les connaissances entre les sessions et fonctionne sur n’importe quelle infrastructure, depuis un VPS à faible coût jusqu’aux sandboxes cloud.

En avril 2026, le dépôt GitHub public affiche environ 94,6 k étoiles, 13,2 k forks et une dernière version étiquetée v0.10.0 le 16 avril 2026. Cette activité suffit à qualifier le projet comme rapide, bien adopté et, en même temps, encore opérationnellement jeune.

Cette double nature est importante pour la conception en production. Hermes est suffisamment 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 le profil

Les compétences Hermes sont des documents de connaissances à la demande. Elles utilisent une divulgation progressive pour que l’agent puisse voir d’abord un index de compétences compact et ne charge le contenu complet de la compétence 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 en slash dans le CLI et dans les interfaces de messagerie, et la documentation positionne explicitement les compétences comme le mécanisme d’extension privilégié lorsqu’une capacité peut être exprimée avec des instructions, des commandes shell et des outils existants plutôt que 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 incluses, les compétences installées via l’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 correctif (patch), d’édition, de suppression et de gestion de fichiers supportés pour la gestion des compétences. C’est puissant, mais cela signifie aussi qu’un agent “tout faire” trop volumineux a tendance à devenir un tiroir de procédures désordonné.

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, souvenirs, sessions, compétences, tâches cron et base de données d’état. Le 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é de production, et non la compétence individuelle.

La ligne de base de production

La forme de la ligne de base est étonnamment propre. Hermes stocke les comportements non secrets 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 également la réponse la plus claire à la FAQ de production sur la façon dont les secrets et la configuration doivent être séparés.

Une disposition pratique multi-profils 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 motif correspond à la façon dont les profils Hermes sont documentés : chaque profil est son propre 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 ni mémoire ni sessions, et que les compétences mises à jour peuvent être synchronisées entre les profils lorsque l’installation principale est mise à jour.

La prochaine frontière 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 comprend l’approbation de 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 de backend répond à la question de là où le travail risqué est autorisé.

L’automatisation repose sur cette ligne de base. Les jobs cron Hermes peuvent attacher zéro, un ou plusieurs compétences, et ils s’exécutent dans de nouvelles sessions d’agent 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 le cron et achemine les résultats vers des plateformes comme Telegram, Discord, Slack, WhatsApp, Email, Matrix et d’autres. Le guide officiel MCP ajoute une règle de production de plus facile à négliger : le meilleur motif n’est pas de tout connecter, mais d’exposer la surface la plus petite utile.

Le profil d’ingénierie logicielle

La persona Hermes la plus évidente est l’ingénieur logiciel qui veut que l’agent se comporte moins comme une fenêtre de chat et plus comme un opérateur de répétoire répétable. Ce profil s’intéresse généralement à l’authentification du dépôt, au tri des problèmes (issues), à 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 paquet 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 paquet utile n’est pas une compétence unique. C’est la façon dont les compétences codifient 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 réflexion après coup, et systematic-debugging empêche l’agent de passer directement à des corrections prématurées. 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 Hermes renforce davantage ce profil. La plateforme peut générer des agents enfants isolés avec leur propre conversation, session de terminal 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 d’encombrer chaque différence 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 d’ensembles de compétences étroits, 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’endroit 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 optionnel officiel ajoute qmd, parallel-cli, scrapling et une couche de recherche plus large pour des domaines spécialisés. Cette pile couvre la recherche d’articles, la surveillance des sources, OCR, les systèmes de notes locaux, la reconnaissance de domaine, l’écriture et la récupération hybride sans tout forcer dans un seul motif RAG.

Ce profil est également l’endroit le plus clair pour répondre à la question mémoire contre compétences. La documentation 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 des procédures sur la façon de faire les choses. Le travail de recherche a besoin des deux. La mémoire contient ce que l’assistant a déjà appris sur le domaine et les préférences du lecteur ; les compétences codifient des procédures répétables telles que “scanner arXiv, résumer les nouveaux articles et écrire des notes dans Obsidian”. Cette distinction est importante car les systèmes de recherche de production échouent lorsque tout est traité comme de la mémoire ou tout est traité comme un flux de travail. Hermes donne à ces préoccupations des domiciles séparés.

Le profil de recherche bénéficie également de manière disproportionnée du cron. Les jobs cron Hermes peuvent charger explicitement 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 de nouvelles sessions. Un pipeline récurrent qui combine 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, l’écriture de notes et le stockage à long terme sont chacun représentés par une compétence nommée plutôt que cachés à l’intérieur d’une longue invite de langage naturel.

Le profil d’automatisation et d’opérations

Le profil ops est moins glamour et souvent plus précieux. C’est l’utilisateur qui veut 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 passif. Hermes possède les bons blocs de construction pour ce style de travail : webhook-subscriptions intégrés 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 optionnelles officielles 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 paquet fonctionne est que chaque compétence possède une frontière. webhook-subscriptions gère l’ingrès des systèmes externes. docker-management transforme les corvées de conteneurs en une procédure nommée plutôt qu’un jeu de shell libre. fastmcp est utile lorsque Hermes doit devenir l’orchestrateur autour de nouveaux outils MCP, et 1password maintient la gestion des secrets explicite plutôt que dissimulée dans l’historique shell ou les fichiers markdown. Les directives officielles MCP renforcent le même instinct de production : connecter la bonne chose avec la surface la plus petite utile.

Ce profil est également l’endroit le plus clair pour répondre à la question de savoir comment les flux de travail IA planifiés restent fiables. La documentation cron Hermes indique que les jobs s’exécutent dans de nouvelles sessions, 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 ticker de la passerelle plutôt que d’une session de chat CLI ordinaire. Ainsi, le motif fiable est simple même si la mise en œuvre ne l’est pas : compétences explicites, cible de livraison explicite, invite autonome, backend isolé et une passerelle qui fonctionne réellement.

Le profil d’opérations exécutives

Il existe une persona Hermes plus discrète mais très réelle qui ressemble à un chef d’état-major, un responsable des opérations ou un fondateur lourdement surchargé. Les compétences pertinentes sont moins flashées et plus axées sur le bureau : google-workspace, notion, linear, nano-pdf, powerpoint et la compétence email intégrée himalaya, plus des compétences optionnelles officielles telles que agentmail, telephony et one-three-one-rule. Ce mélange donne à Hermes 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 à des flux de travail téléphoniques 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 d’enregistrement des tâches. one-three-one-rule est étonnamment utile car le soutien à la décision 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 de “résumer ceci”. nano-pdf et powerpoint sont le genre de multiplicateurs opérationnels qui semblent petits jusqu’à ce qu’une équipe commence à toucher des présentations et des PDF tous les jours.

Les fonctionnalités de messagerie et de voix de Hermes rendent ce profil plus pratique qu’il n’y paraît au premier abord. 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 parlées dans la messagerie et les conversations vocales en direct sur Discord. 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 axé sur la communication bénéficie généralement d’au moins un profil dédié plutôt que 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 de production, et une grande couche MLOps intégrée et optionnelle 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 remarquable ici n’est pas seulement l’étendue. C’est que les compétences couvrent 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 qui peut 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 également le profil où la retenue est la plus importante. Parce que le catalogue MLOps optionnel est si vaste, une configuration Hermes de production pour le travail ML bénéficie généralement d’être avisée 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 articles et des systèmes de notes n’a pas besoin de chaque compétence de base de données vectorielle. Hermes peut transporter d’énormes inventaires de compétences, mais l’utilité de production vient toujours de l’approfondissement de la surface active.

Là où les compétences deviennent des passifs

La partie la plus forte du système de compétences Hermes est aussi l’endroit où les configurations de production échouent. Hermes peut parcourir et installer des compétences à partir de son catalogue intégré, du catalogue optionnel officiel, de skills.sh de Vercel, des points de terminaison de compétences bien connus, des dépôts GitHub directs et de sources communautaires de style marketplace. Le modèle de sécurité distingue entre les sources builtin, official, trusted et community, exécute des analyses de sécurité pour les compétences installées via l’hub et autorise --force uniquement pour les blocs de politique non dangereux. Un verdict d’analyse dangereux reste bloqué. Hermes affiche également des métadonnées en amont telles que l’URL du dépôt, les installations hebdomadaires et les signaux d’audit lors de 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 devrait demander à une compétence de faire. La documentation Hermes est explicite : les compétences sont le choix privilégié lorsque le travail peut être exprimé comme des instructions plus des commandes shell plus des 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 de plugin montre même comment un plugin peut inclure 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é à une conception d’outil ou de plugin appropriée.

La communauté et le support semblent sains, mais ils n’effacent pas la vélocité de changement. La documentation Hermes oriente les utilisateurs vers Discord, les Discussions GitHub, les Problèmes 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 suffisamment simple : les mises à jour font partie du système, et non un événement extérieur. Une véritable configuration de production suppose que les profils, les compétences et les hypothèses de flux de travail évolueront, puis utilise l’isolation et des paquets 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. Au moment où un profil devient l’agent d’ingénierie, l’assistant de recherche, l’ouvrier ops, le bot de boîte de réception et la plateforme ML tous à la fois, le système cesse de composer et commence à fuir les responsabilités. Le motif 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é.