Les compétences statiques sont des compétences mortes

Hier soir, j’ai livré une section Settings Reference au guide Claude Code. Quinze entrées. Chaque citation vérifiée par grep contre un numéro de ligne. Je l’ai livrée par conviction après que la boucle de critique soit revenue propre. Au moment où je faisais le commit du fichier .md, je savais déjà que j’aurais besoin d’une v3 — non pas parce que j’avais mal fait quelque chose, mais parce que le guide change, le produit sous-jacent change, les requêtes des utilisateurs évoluent, et la section que je venais de livrer commencerait à dériver dès l’instant où je m’en éloignerais.

Une compétence, qu’il s’agisse d’une section de référence Markdown ou d’une définition de compétence d’agent dans .claude/skills/, n’est vivante que tant que quelqu’un surveille sa trajectoire. Dès que vous cessez de surveiller, elle devient statique. Les compétences statiques se dégradent sur place.

Un nouvel article arxiv de Ma, Yang, Ji, Wang et Wang (« SkillClaw: Let Skills Evolve Collectively with Agentic Evolver », avril 2026) formalise ce problème au niveau de la recherche.¹ Leur cadrage d’ouverture, cité directement : « Large language model (LLM) agents such as OpenClaw rely on reusable skills to perform complex tasks, yet these skills remain largely static after deployment. As a result, similar workflows, tool usage patterns, and failure modes are repeatedly rediscovered across users, preventing the system from improving with experience. »¹

Je vis ce mode d’échec depuis des mois. Vous aussi, si vous construisez des compétences pour un harnais d’agent quelconque.

TL;DR

Les compétences d’agent sont livrées, puis cessent de s’améliorer. Les utilisateurs découvrent les mêmes modes d’échec indépendamment et ne réinjectent jamais ces découvertes dans la compétence elle-même. Ma et al. présentent cela comme un problème d’intelligence collective : les interactions entre utilisateurs et dans le temps sont des signaux indiquant quand une compétence fonctionne ou échoue, mais aucun mécanisme à l’échelle de l’écosystème n’existe pour les agréger en mises à jour de compétences. Leur framework SkillClaw propose de traiter les trajectoires agrégées comme le signal d’évolution, en exécutant un évolueur autonome qui identifie les schémas comportementaux récurrents et les traduit en raffinements ou en extensions de capacités.¹ L’abstract cite « OpenClaw » comme exemple d’agent LLM qui utilise des compétences réutilisables — je n’ai pas pu identifier OpenClaw comme un produit spécifique commercialisé à partir du seul abstract, et je ne vais pas spéculer à ce sujet dans ce billet. Ce que je vais affirmer, c’est que le problème structurel décrit par l’article s’applique à quiconque construit des compétences pour Claude Code, Codex, Cursor ou son propre harnais. La conclusion : si votre bibliothèque de compétences n’ingère pas en continu les trajectoires issues de l’usage réel, elle est morte dès le jour de sa livraison.

Points clés à retenir

• Auteurs de compétences : Le travail n’est pas terminé lorsque la compétence est livrée. Le travail est terminé lorsque vous disposez d’une boucle qui surveille la manière dont la compétence est utilisée, détecte les modes d’échec récurrents et les réinjecte dans la définition de la compétence. La livraison est le début de la vie de la compétence, pas la fin.
• Constructeurs de harnais : Journalisez chaque invocation de compétence avec sa trajectoire — les entrées, les appels d’outils, les sorties, l’état d’erreur. Ce journal est le signal d’évolution. Si vous ne le journalisez pas, vous n’améliorez pas vos compétences ; vous les maintenez.
• Praticiens à l’esprit Jiro : L’article SkillClaw est une formulation académique du pattern Shokunin appliqué aux compétences. La compétence est l’artisanat. Les trajectoires sont la pratique. L’évolution est la poursuite de la maîtrise. Statique = mort.

Ce que dit réellement l’article

Je vais parcourir les affirmations de l’abstract avec soin, puis marquer clairement là où j’étends le cadrage.

L’énoncé du problème (d’après l’abstract). Les agents LLM s’appuient sur des compétences réutilisables pour effectuer des tâches complexes. Ces compétences restent largement statiques après leur déploiement. Des flux de travail similaires, des schémas d’utilisation d’outils et des modes d’échec sont redécouverts à plusieurs reprises par les différents utilisateurs. Le système ne s’améliore pas avec l’expérience.¹

C’est une affirmation sur un mode d’échec spécifique, pas une affirmation selon laquelle toutes les compétences se dégradent. Une compétence qui n’est jamais invoquée ne se dégrade pas. Une compétence invoquée par un seul utilisateur qui ne signale jamais de problèmes ne se dégrade pas visiblement. La dégradation se manifeste lorsque vous avez plusieurs utilisateurs, chacun rencontrant sa propre version du même échec, et que le système n’a aucun moyen d’agréger ces rencontres en une seule mise à jour. (Cette dernière phrase est mon cadrage, pas celui de l’article.)

L’écart existant (d’après l’abstract). L’abstract indique que si les interactions entre utilisateurs « fournissent des signaux complémentaires sur le moment où une compétence fonctionne ou échoue, les systèmes existants ne disposent pas d’un mécanisme pour convertir ces expériences hétérogènes en mises à jour fiables des compétences ».¹ C’est l’affirmation porteuse. Il ne s’agit pas de dire que personne n’a pensé à l’amélioration des compétences. Il s’agit de dire qu’aucun mécanisme à l’échelle de l’écosystème n’agrège les trajectoires, n’identifie les schémas récurrents et ne les traduit en mises à jour.

Le pipeline SkillClaw (d’après l’abstract). L’abstract décrit un pipeline continu : SkillClaw « agrège les trajectoires générées pendant l’utilisation et les traite avec un évolueur autonome, qui identifie les schémas comportementaux récurrents et les traduit en mises à jour de l’ensemble des compétences en affinant les compétences existantes ou en les étendant avec de nouvelles capacités ».¹ Les compétences mises à jour sont maintenues dans un dépôt partagé et synchronisées entre les utilisateurs, de sorte que les améliorations découvertes dans un contexte se propagent à l’ensemble du système sans nécessiter d’effort de la part de l’utilisateur.¹

L’évaluation (d’après l’abstract). L’article évalue SkillClaw sur un benchmark appelé WildClawBench en utilisant Qwen3-Max comme modèle sous-jacent. La propre formulation de l’abstract est grammaticalement cassée dans la version publiée : « experiments on WildClawBench show that limited interaction and feedback, it significantly improves the performance of Qwen3-Max in real-world agent scenarios. »¹ Je le lis comme : avec une interaction et un retour limités, SkillClaw produit tout de même des améliorations significatives de performance par rapport à la référence. L’abstract ne publie pas de chiffres précis — l’article complet le fait vraisemblablement.

Voilà l’article tel que l’abstract le décrit. Les auteurs proposent que les écosystèmes d’agents multi-utilisateurs avec des compétences partagées bénéficient d’une agrégation automatisée des trajectoires alimentant des mises à jour automatisées des compétences, et ils rapportent que leur implémentation améliore significativement les performances de Qwen3-Max dans des conditions de retour limité.

Ce que l’article ne dit pas (et ce que j’ajoute)

L’abstract cite « OpenClaw » comme un exemple (« LLM agents such as OpenClaw ») d’agent qui utilise des compétences réutilisables. Je ne sais pas ce qu’est OpenClaw à partir du seul abstract — je n’ai pas pu l’identifier rapidement comme un produit spécifique commercialisé. Le framework de l’article (SkillClaw) est présenté comme une solution pour les écosystèmes d’agents multi-utilisateurs en général, pas pour OpenClaw en particulier, donc la question « qu’est-ce qu’OpenClaw » est largement tangentielle à l’argument. Je le signale pour que personne ne lise ce billet et n’en reparte en pensant que l’article porte sur Claude Code. Ce n’est pas le cas. Il nomme OpenClaw comme exemple et propose SkillClaw comme mécanisme général.

Ce que j’affirme — séparément de l’article — c’est que le problème structurel décrit par l’article s’applique à un problème réel que je vis dans l’écosystème de compétences Claude Code. Cette affirmation est la mienne, pas celle de l’article. Voici pourquoi je pense qu’elle s’applique.

Les compétences dans l’écosystème Claude Code sont livrées comme des artefacts statiques. Une compétence est un fichier SKILL.md (ou un ensemble de fichiers de support) qui décrit comment une tâche doit être effectuée. Vous l’écrivez une fois. Vous la commitez. Vous la référencez avec une commande slash ou via l’autocomplétion @skill-name. Une fois livrée, c’est un artefact statique. Il n’existe aucun mécanisme automatique qui surveille la manière dont la compétence est utilisée en pratique et met à jour sa définition en fonction de ce qui fonctionne et de ce qui échoue.

Différents utilisateurs rencontrent les mêmes modes d’échec indépendamment. Chaque compétence que j’ai livrée a au moins un mode d’échec récurrent qui n’apparaît que dans des conditions spécifiques. Quelqu’un invoque la compétence avec une entrée que je n’avais pas anticipée, tombe sur le cas limite, contourne manuellement et passe à autre chose. Une autre personne, ailleurs, rencontre le même cas limite et effectue son propre contournement. La compétence elle-même reste inchangée.

Le signal agrégé est réel mais inutilisé. Si je pouvais voir chaque trajectoire de chaque invocation de chaque compétence que j’ai livrée, je pourrais identifier les modes d’échec récurrents en une après-midi. Ce signal existe — il est dans l’historique de session de chaque utilisateur individuel. Il n’est simplement agrégé nulle part, donc personne n’agit dessus.

Le correctif est soit manuel, soit manquant. À l’heure actuelle, le seul mécanisme d’amélioration des compétences est que je remarque un problème dans mon propre usage, ou que quelqu’un dépose un ticket, ou que quelqu’un ouvre une PR. Ce sont tous des chemins qui exigent un effort de l’utilisateur. L’idée centrale de l’article SkillClaw — que les données de trajectoire existent déjà et devraient être converties automatiquement en mises à jour de compétences — est exactement le mécanisme qui nous manque.

Voilà mon affirmation sur la manière dont le cadrage de l’article s’applique à Claude Code. Ce n’est pas ce que dit l’article. C’est la manière dont je lis l’article à l’aune de mon propre travail.

Le pattern Shokunin, appliqué aux compétences

Il y a un cadrage auquel je reviens sans cesse lorsque je pense à l’artisanat. Jiro Ono, le maître sushi, en est l’exemple canonique. Soixante ans du même travail. Chaque jour, à observer ce qui se passe au comptoir, à ajuster la technique, à affiner la température du riz, l’angle du couteau, le timing du shari. Le travail lui-même est le signal d’entraînement. Le praticien est l’agrégateur.

J’ai écrit sur le cadrage Shokunin / boucle de qualité il y a quelque temps. L’idée centrale : l’artisanat est la boucle de rétroaction. Vous faites le travail, vous observez le travail, vous remarquez ce qui a cassé, vous ajustez, vous refaites le travail. Encore et encore. La maîtrise vit dans l’écart entre ce que vous aviez l’intention de faire et ce qui s’est réellement passé, et dans votre volonté de porter cet écart dans la tentative suivante.

Une compétence statique brise cette boucle. Vous livrez la compétence. Vous cessez d’observer. L’écart entre ce que la compétence entendait faire et ce qui se passe réellement s’accumule dans une centaine de sessions différentes que vous ne voyez jamais. La compétence ne s’améliore pas parce que l’artisan n’est pas au comptoir.

L’article SkillClaw propose un agrégateur automatisé — pas un remplaçant de l’humain, mais un mécanisme qui observe toutes les trajectoires, remarque ce qui s’est cassé à travers les sessions et propose des mises à jour à la définition de la compétence. Ce n’est pas une ambition folle. C’est en fait la barre minimale si vous voulez qu’une compétence survive à son propre déploiement.

À quoi cela ressemble en pratique

Si je voulais construire le pattern SkillClaw contre les compétences Claude Code que je maintiens aujourd’hui, voici ce dont j’aurais besoin :

1. Un journal de trajectoire pour chaque invocation de compétence. Chaque fois qu’une compétence s’exécute, les entrées, les appels d’outils qu’elle effectue, les sorties, les états d’erreur et la disposition finale (l’utilisateur a-t-il accepté le résultat ? l’a-t-il annulé ? l’a-t-il réécrit ?). Cela existe déjà au niveau de la session dans Claude Code — la question est de savoir si c’est agrégé à travers les sessions et extrait pour le propriétaire de la compétence.

2. Un détecteur de schémas. Quelque chose qui lit le journal de trajectoire et identifie les schémas récurrents : même classe d’entrée menant au même échec, même appel d’outil échouant de la même manière, même cas limite apparaissant dans différents contextes utilisateur. Ce n’est pas de l’AGI — c’est du clustering sur des données de trajectoire structurées.

3. Un générateur de propositions. Étant donné un schéma détecté, rédiger une mise à jour candidate à la compétence : une nouvelle branche de traitement, un exemple supplémentaire, une contrainte supplémentaire dans le corps du SKILL.md. La mise à jour est une proposition, pas un changement livré.

4. Un contrôle. Chaque mise à jour proposée passe par une revue humaine, une vérification factuelle (le même contrôle strict que j’applique à tout le reste) et une boucle de critique avant d’être livrée. L’automatisation fait l’agrégation, pas la livraison.

5. Distribution. Lorsqu’une mise à jour proposée est acceptée, elle se propage à chaque utilisateur de cette compétence. Dans un écosystème centralisé, c’est trivial (mettre à jour la compétence canonique, tout le monde la récupère). Dans un écosystème distribué, c’est plus difficile.

La plus grande partie est déjà présente dans Claude Code — la journalisation des sessions existe, les définitions de compétences sont versionnées, la boucle de critique est opérationnelle — la pièce manquante est la couche d’agrégation et de détection de schémas qui relie les trajectoires de session aux mises à jour de compétences.

L’implication inconfortable

Chaque compétence que j’ai livrée au cours des six derniers mois est morte exactement dans le sens où l’article SkillClaw le décrit. J’écris la compétence. Je l’utilise moi-même. Je remarque des problèmes. Je les corrige dans les compétences que j’utilise. Les compétences s’améliorent pour moi. Elles ne s’améliorent pour personne d’autre, à moins que cette personne ne remarque indépendamment le même problème et ne dépose quelque chose.

Le travail que j’ai effectué hier soir sur la Settings Reference est exactement ce pattern. Le guide Claude Code est un artefact partagé. Les utilisateurs l’interrogent pour des clés de configuration spécifiques. Je peux voir les données GSC qui me disent quelles clés de configuration sont recherchées. Ce sont des données de trajectoire agrégées — elles me disent littéralement quelles compétences du guide sont invoquées et où aboutissent les résultats. Et jusqu’à ce que j’aille consulter ces données, le guide était statique. Il l’avait été pendant des semaines. Non pas parce que personne ne surveillait les trajectoires, mais parce que j’étais la seule personne qui pouvait les surveiller, et j’avais d’autres choses à faire.

L’article SkillClaw est la formalisation académique du problème. Le mécanisme pratique est plus simple : si vous ne disposez pas d’un pipeline automatique allant des données de trajectoire aux mises à jour de compétences, vos compétences vieillissent sur place. Elles peuvent encore fonctionner pour certains utilisateurs dans certaines conditions. Elles ne s’améliorent pas.

La seule question est de savoir si vous acceptez que vos compétences soient mortes dès l’instant de leur livraison, ou si vous construisez l’observateur qui les maintient en vie.

L’agrégateur minimum viable

Avant de commencer ce billet, j’avais zéro agrégation de trajectoires sur mes compétences. Aucune. J’avais un historique de session que je pouvais lire manuellement, mais rien qui faisait émerger des schémas à travers les sessions. C’est exactement la pathologie de compétence statique décrite par l’article, et je la vivais.

Voici la plus petite chose concrète que je peux livrer contre cela dès maintenant, aujourd’hui : un seul fichier texte qui journalise chaque invocation de compétence à travers mes propres sessions, en mode append-only, avec horodatage + nom de la compétence + forme de l’entrée + disposition finale (acceptée / révisée / annulée). Pas de détecteur de schémas. Pas d’évolueur autonome. Juste le journal.

Ce fichier est l’agrégateur minimum viable. Ce n’est pas SkillClaw. C’est la couche d’entrée dont SkillClaw aurait besoin s’il existait, et c’est la couche d’entrée dont j’ai besoin avant même de pouvoir voir si mes compétences ont des modes d’échec récurrents. Sans cela, je devine. Avec cela, je peux au moins parcourir le journal à la main lorsque je révise une compétence et me demander : est-ce que cette chose a cassé de la même manière trois fois ce mois-ci ?

Voilà l’engagement. Un fichier. Append-only. Journalisé par invocation. Révisé lorsque je révise la compétence.

Si cela fonctionne, la couche suivante est le détecteur de schémas. Si le détecteur de schémas fonctionne, la couche suivante est le générateur de propositions. L’ambition de l’article est un évolueur autonome complet fonctionnant à travers un écosystème multi-utilisateurs. Mon ambition est de ne pas avancer à l’aveugle.

FAQ

« OpenClaw » dans l’article est-il la même chose que Claude Code ?

Non, et je ne peux pas non plus vous dire ce qu’est OpenClaw. L’abstract mentionne « LLM agents such as OpenClaw » comme un exemple d’agent qui utilise des compétences réutilisables, sans le définir. Je n’ai pas pu l’identifier rapidement comme un produit spécifique commercialisé à partir du seul abstract. L’important est que le framework SkillClaw de l’article est présenté comme une solution générale pour les écosystèmes d’agents multi-utilisateurs, et non comme une solution spécifique à OpenClaw ou Claude Code. Quel que soit OpenClaw, l’article n’est pas un article sur Claude Code, et mes affirmations à propos de Claude Code dans ce billet sont les miennes, pas celles de l’article.¹

Quelle est la véritable contribution nouvelle de l’article ?

Selon l’abstract : un framework pour l’évolution collective des compétences dans les écosystèmes d’agents multi-utilisateurs qui (1) agrège les trajectoires à travers les utilisateurs et le temps, (2) exécute un évolueur autonome pour détecter les schémas récurrents, et (3) traduit les schémas en mises à jour des compétences dans un dépôt partagé qui se synchronise entre les utilisateurs.¹ La nouveauté n’est pas « les compétences peuvent être améliorées » — c’est évident. La nouveauté est de proposer que la boucle d’amélioration soit autonome et pilotée par les trajectoires, et non pilotée par l’humain.

L’article rapporte-t-il des chiffres d’amélioration spécifiques ?

L’abstract décrit l’amélioration comme « significative » sur un benchmark appelé WildClawBench en utilisant Qwen3-Max, dans des conditions de retour limité, mais ne publie pas de chiffres précis.¹ Pour les chiffres, l’article complet est la source.

En quoi cela diffère-t-il d’une pull request git contre une définition de compétence ?

Une PR est un mécanisme initié par l’humain. Quelqu’un doit remarquer le problème, écrire le correctif, déposer la PR, la réviser, la fusionner. Chaque étape nécessite un effort humain. Le framework SkillClaw proposé par l’article est une agrégation autonome — le système remarque le schéma à travers de nombreux utilisateurs, propose lui-même le correctif et synchronise la mise à jour sans qu’aucun utilisateur unique n’ait à déposer quoi que ce soit.¹ La question de savoir si cette version autonome est souhaitable ou sûre pour un écosystème spécifique est une autre question. La contribution de l’article est de montrer qu’elle est techniquement cohérente.

Est-ce que cela s’applique à mes compétences Claude Code personnalisées ?

L’article ne fait aucune affirmation sur un écosystème de compétences Claude Code spécifique. Mon affirmation — distincte de l’article — est que le problème structurel (compétences livrées comme artefacts statiques, modes d’échec redécouverts par chaque utilisateur indépendamment, aucun mécanisme d’agrégation) s’applique bien aux compétences Claude Code, et que toute personne construisant des compétences pour Claude Code ou tout harnais similaire devrait réfléchir à la manière de construire une boucle d’amélioration pilotée par les trajectoires. C’est mon opinion, pas une conclusion de l’article.

Quel est le lien avec Shokunin ?

Le cadrage Shokunin / boucle de qualité soutient que la maîtrise vient de l’écart entre ce que vous aviez l’intention de faire et ce qui s’est réellement passé, porté dans la tentative suivante. Les compétences statiques brisent cette boucle parce que les écarts s’accumulent dans des sessions que l’artisan ne voit jamais. SkillClaw est la version académique de la fermeture de cette boucle — automatiser la collecte des écarts et les réinjecter dans la compétence. La discipline est la même ; le mécanisme est différent.

Références