Aller au contenu
Bureau d’études
en agents IA · Brest
← IngénierieTalk · 5 min · 17 sept. 2026

Quand l’agent écrit ses propres Skills, qui relit ?

Hermes Agent sait écrire et entretenir ses propres Skills. Nous l’utilisons tous les jours chez BTM. Ce que ça change pour les savoir-faire qu’on lui confie, et ce qui manque encore.

Tirée du talk « Skills Engineering », Nuit des communautés

Un agent qui prend des notes sur sa façon de travailler

Hermes Agent est un agent open source, publié par Nous Research en février 2026. Il tourne sur une machine ou un serveur, et on lui parle en ligne de commande ou par messagerie. Sa mémoire a trois étages.

Notes · deux petits fichierstoujours
Recherche · conversations passéesà la demande
Skills · procédures longuessi pertinent
Fig. 1 — Les trois étages de la mémoire d’Hermes, du plus présent au plus sélectif.

Ses Skills suivent le format ouvert publié par Anthropic en décembre 20251 : un dossier, un fichier SKILL.md, une description courte. C’est cette description, et elle seule, que l’agent lit pour décider de charger un Skill.

Ce qui distingue Hermes, c’est qu’il écrit ses Skills lui-même. Après une tâche complexe, une erreur délicate ou un enchaînement qu’il vient de découvrir, ses consignes lui demandent d’en faire un Skill. Et quand il en trouve un faux ou incomplet, de le corriger tout de suite, sans attendre qu’on le lui demande.

Hermes, c’est un agent qui prend des notes sur sa façon de travailler. Ces notes, ce sont des Skills.

Écrire, il sait. Relire, personne.

Hermes prévoit une approbation des écritures : chaque modification d’un Skill est mise en attente, on en lit le diff, on valide. Cette approbation est désactivée par défaut2.

Sur notre propre agent, entre fin août et mi-septembre, deux de nos Skills ont connu trente modifications. Aucune n’a été faite par le processus d’entretien autonome : toutes ont eu lieu dans nos conversations. Et aucune n’est passée par une relecture de diff. Le garde-fou, c’était la conversation, pas la relecture.

Ce qui est vérifié, et ce qui ne l’est jamais

Autour d’un Skill, Hermes contrôle beaucoup de choses.

VérifiéPar
La forme : en-tête, nom, description, longueurLe validateur
La sécurité des Skills installés depuis le HubLe scanner
L’usage : inutilisé trente jours, un Skill créé par l’agent est archivéLe curator, chaque semaine
Chaque modificationL’approbation, si on l’active
La performance, à partir des tracesUn projet séparé, avec un humain
Le sens— rien

Rien ne vérifie qu’un Skill dit encore ce que voulait la personne dont il décrit le savoir-faire.

Le sédiment

Celui qui écrit un Skill lit la conversation qui l’a précédé. Le contexte de la création fuit donc dans le texte : des détails du jour, des exemples de circonstance, des corrections qui n’avaient de sens que ce jour-là.

Et la correction par petites touches est l’action que recommande Hermes, parce qu’elle coûte moins de tokens qu’une réécriture. Chaque correction dépose une couche. Nous Research a un mot pour ça, le « sédiment », et une règle : des leçons, pas des journaux.

Et lire, pas toujours

Une issue ouverte sur le dépôt d’Hermes mesure la sélection des Skills sur un profil qui en compte environ 940 : sur 195 sessions, 85 chargements, et aucun chargement spontané des Skills pourtant épinglés3.

Un agent qui écrit beaucoup n’est donc pas un agent qui se sert de ce qu’il a écrit.

Ce que nous en retenons

Chez BTM, un principe guide le reste : le savoir-faire s’écrit avec qui le porte. Il vaut aussi quand c’est un agent qui tient la plume.

  1. Distinguer deux régimes. Les Skills opérationnels, qu’un agent peut entretenir seul. Ceux qui portent le savoir-faire d’une personne, qui restent sous sa main.
  2. Relire les diffs de ces derniers. L’approbation existe : activez-la pour eux.
  3. Protéger l’idée de départ : deux ou trois phrases qui disent ce que fait le Skill et ce qu’il ne fait pas, que seules les personnes concernées modifient.
  4. Versionner les Skills (dans Git, ou mieux : dans SolidSkills), pour que l’histoire vive dans l’historique, pas dans le texte.
  5. Tester avec des cas écrits par quelqu’un d’autre que l’auteur.

C’est aussi pour ça que nous construisons SolidSkills : pour que les Skills restent des actifs que leurs auteurs possèdent, versionnent et partagent.