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

L’assistant IA Hermes, officiellement documenté sous le nom de Hermes Agent, ne se positionne pas comme un simple wrapper de chat.

Pour l’installation, la configuration du fournisseur, le sandboxing des outils et la configuration du gateway, consultez le guide de l’assistant IA Hermes. Cet article se concentre sur les compétences et l’architecture de profil qui déterminent le comportement de Hermes une fois qu’il est en cours d’exécution.

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 les connaissances entre les sessions et fonctionne sur n’importe quoi, d’un VPS peu coûteux 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 taguée v0.10.0 le 16 avril 2026. Cette activité suffit à qualifier le projet comme à évolution rapide, bien adopté et, simultanément, encore jeune sur le plan opérationnel.

Cette double nature est importante pour la conception de la production. Hermes est suffisamment mature pour supporter un travail réel, mais suffisamment 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 à la demande. Elles utilisent la divulgation progressive afin que l’agent puisse voir d’abord un index de compétences compact et ne charger le contenu complet des compétences que si 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 l’CLI et dans les surfaces 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, celles installées via le hub et celles 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é tend à devenir un tiroir de 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, tâches cron et base de données d’état. L’CLI transforme également un profil en son propre alias de commande, ainsi un profil nommé coder devient coder chat, coder setup, coder gateway start, etc. En pratique, cela fait des profils la véritable unité de propriété en production, et non la compétence individuelle.

La ligne de base de production

La forme 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 tâches planifiées 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 dont les secrets et la configuration doivent être séparés.

Une disposition pratique multi-profils finit généralement par ressembler à 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 son propre environnement isolé, et les profils peuvent être clonés depuis 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 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 inclut l’approbation des commandes dangereuses, l’isolation des conteneurs, le filtrage des identifiants MCP, le scan 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 l’endroit où le travail risqué est autorisé à avoir lieu.

L’automatisation repose sur cette ligne de base. Les tâches cron de Hermes peuvent attacher zéro, une ou plusieurs compétences, et elles s’exécutent dans des sessions d’agent fraîches plutôt que d’hériter du chat actuel. Le gateway 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 autres. Le guide officiel MCP ajoute une règle de production supplémentaire facile à manquer : le meilleur modèle n’est pas de connecter tout, mais d’exposer la plus petite surface utile.

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 répétable. 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 révision de code, au débogage et à l’exécution soutenue par un plan. Dans les catalogues de Hermes, le pack de compétences intégré de base est anormalement 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 propose é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 aucune compétence individuelle. C’est la manière dont les compétences encodent 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 révision une étape distincte plutôt qu’une réflexion après coup, et systematic-debugging empêche l’agent de passer directement à des correctifs prématurés. Cela répond également à la question pratique de savoir quelles compétences d’assistant IA comptent le plus pour les workflows de codage. Les compétences à la plus haute valeur sont généralement celles qui verrouillent l’hygiène du dépôt et la discipline de révision, et non celles qui promettent une génération de code brute accrue.

La délégation de Hermes renforce davantage ce profil. 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 meilleur ajustement que de fourrer chaque diff intermédiaire, trace de pile et note de révision 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 les domaines spécialisés. Cette pile couvre la recherche de papiers, la surveillance des sources, l’OCR, les systèmes de notes locaux, la reconnaissance de domaine, l’écriture et la récupération hybride sans forcer tout dans un seul modèle RAG.

Ce profil est aussi 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 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 encodent des procédures répétables 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 quand tout est traité comme de la mémoire ou quand tout est traité comme un workflow. Hermes donne à ces préoccupations des logements séparés. Pour l’image technique complète de comment la mémoire fonctionne — l’architecture à deux fichiers, les limites de caractères, le cache préfixe et les huit options de fournisseurs externes — consultez Système de mémoire de l’Agent Hermes.

Le profil de recherche bénéficie également de manière disproportionnée du cron. Les tâches cron de Hermes peuvent charger explicitement des compétences avant l’exécution, et les guides d’automatisation insistent sur le fait que les prompts planifiés doivent être entièrement autonomes car ils s’exécutent dans des sessions fraîches. Un pipeline récurrent qui combine blogwatcher, arxiv, obsidian ou llm-wiki est donc plus fiable qu’une tâche 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’un long prompt en langage naturel.

Le profil d’automatisation et d’opérations

Le profil ops 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 a 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é pour les outils basés sur MCP, et des compétences officielles optionnelles telles que docker-management, fastmcp, cli et 1password lorsque le workflow 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 conteneurs 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 camouflée dans l’historique shell ou les fichiers markdown. Les conseils officiels MCP renforcent le même instinct de production : connecter la bonne chose avec la plus petite surface utile.

Ce profil est aussi l’endroit le plus propre pour répondre à la question de savoir comment les workflows IA planifiés restent fiables. La documentation cron de Hermes dit que les tâches s’exécutent dans des sessions fraîches, peuvent attacher une ou plusieurs compétences, et doivent utiliser des prompts autonomes. Le guide de dépannage cron ajoute que le déclenchement automatique dépend du ticker du gateway plutôt que d’une session de chat CLI ordinaire. Le modèle fiable est donc simple, même si l’implémentation ne l’est pas : compétences explicites, cible de livraison explicite, prompt autonome, backend isolé et un gateway 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 cabinet, 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 workflows 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 de tâches de référence. one-three-one-rule est surprenament 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 « résumez 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 à première vue. Le gateway 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 microphone, les réponses parlées 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 de permission et l’appariement DM, tandis que les jetons bot restent exclusifs à un seul profil. C’est pourquoi un déploiement lourd en communication bénéficie généralement d’au moins un profil dédié au lieu de partager la même identité 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 un 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 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 remarquable ici n’est pas seulement l’étendue. 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 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 aussi le profil où la retenue compte le plus. Parce que le catalogue MLOps optionnel est si grand, une configuration de production Hermes 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 les papiers et les 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é en production vient toujours de resserrer la surface active.

Là où les compétences deviennent des passifs

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 optionnel officiel, 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 devrait demander à une compétence. La documentation de Hermes est explicite : 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 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 de Hermes oriente 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. Une configuration de production réelle suppose que les profils, les compétences et les hypothèses de workflow évolueront, puis utilise l’isolation et les packs de compétences restreints afin 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’ouvrier des opérations, le bot de boîte de réception et la plateforme ML tous en même temps, le système cesse de composer et commence à fuir des responsabilités. Le modèle de production propre consiste moins à avoir plus de compétences et plus à 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é.