Les compétences statiques sont des compétences mortes

Hier soir, j’ai livré une section « Référence des paramètres » pour le 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 est revenue propre. Au moment où je validais le fichier .md, je savais déjà qu’il me faudrait une v3, non pas parce que j’avais mal fait quelque chose, mais parce que le guide évolue, le produit sous-jacent évolue, les requêtes des utilisateurs changent, et la section que je venais de livrer commencerait à dériver dès l’instant où je m’en détournerais.

Une compétence (qu’il s’agisse d’une section de référence en 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 arrêtez de surveiller, elle devient statique. Les compétences statiques se dégradent sur place. L’article ci-dessous fait partie de la série AI engineering qui documente comment l’infrastructure des agents évolue en production.

Les compétences statiques d’agents IA échouent parce qu’elles cessent d’apprendre dès leur livraison. Sans boucle de rétroaction qui ingère les trajectoires d’invocation réelles (les entrées, les appels d’outils, les sorties et les états d’erreur issus d’un usage réel), les compétences ne peuvent s’adapter aux produits qui changent, aux requêtes utilisateurs qui évoluent, ni aux modes d’échec récurrents. Plusieurs utilisateurs redécouvrent indépendamment les mêmes contournements pendant que la définition de la compétence reste figée. La solution : une agrégation continue des trajectoires qui convertit les schémas d’usage en mises à jour automatisées des compétences.

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 formulation d’ouverture, citée directement : « Les agents de grands modèles de langage (LLM) tels qu’OpenClaw s’appuient sur des compétences réutilisables pour effectuer des tâches complexes, pourtant ces compétences restent largement statiques après le déploiement. Par conséquent, des workflows similaires, des schémas d’utilisation d’outils et des modes d’échec sont redécouverts à plusieurs reprises par différents utilisateurs, empêchant le système de s’améliorer avec l’expérience. »¹

Je vis ce mode d’échec depuis des mois. Vous aussi, si vous construisez des compétences pour n’importe quel framework d’agent.

TL;DR

Les compétences d’agents sont livrées, puis cessent de s’améliorer. Les utilisateurs découvrent indépendamment les mêmes modes d’échec sans jamais réinjecter ces découvertes dans la compétence elle-même. Ma et al. formulent 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 au niveau 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 signal d’évolution, en exécutant un évolueur autonome qui identifie les schémas comportementaux récurrents et les traduit en raffinements ou extensions de capacités.¹ Le résumé cite « OpenClaw » comme exemple d’agent LLM qui utilise des compétences réutilisables. Je n’ai pas réussi à identifier OpenClaw comme un produit commercial spécifique à partir du seul résumé, et je ne vais pas spéculer à son 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 framework d’agent. Le constat : si votre bibliothèque de compétences n’ingère pas continuellement des trajectoires issues d’un 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é quand la compétence est livrée. Le travail est terminé quand vous avez une boucle qui surveille comment la compétence est utilisée, repère les modes d’échec récurrents et les réinjecte dans la définition. La livraison est le début de la vie de la compétence, pas la fin.
• Constructeurs de frameworks : consignez 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 consignez pas, vous n’améliorez pas vos compétences ; vous les maintenez.
• Praticiens d’esprit Jiro : l’article SkillClaw est le langage académique du schéma Shokunin appliqué aux compétences. La compétence est le métier. 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 du résumé avec soin, puis marquer clairement les endroits où je prolonge la formulation.

L’énoncé du problème (tiré du résumé). 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 le déploiement. Des workflows similaires, des schémas d’utilisation d’outils et des modes d’échec sont redécouverts à plusieurs reprises par différents utilisateurs. Le système ne s’améliore pas avec l’expérience.¹

Les auteurs visent un mode d’échec spécifique, et non une affirmation universelle selon laquelle toutes les compétences se dégradent. Une compétence jamais invoquée ne se dégrade pas. Une compétence invoquée par un seul utilisateur sans signalement de problème ne se dégrade pas visiblement. La dégradation apparaît quand plusieurs utilisateurs rencontrent chacun leur propre version du même échec, et que le système n’a aucun moyen d’agréger ces rencontres en une mise à jour unique. (Cette dernière phrase est ma formulation, pas celle de l’article.)

Le manque existant (tiré du résumé). Le résumé indique que, bien que les interactions entre utilisateurs « fournissent des signaux complémentaires sur le moment où une compétence fonctionne ou échoue, les systèmes existants manquent de mécanisme pour convertir ces expériences hétérogènes en mises à jour fiables des compétences ».¹ L’affirmation porteuse se situe ici. Le manque n’est pas que personne n’ait pensé à l’amélioration des compétences. Le manque est qu’aucun mécanisme au niveau 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 (tiré du résumé). Le résumé décrit un pipeline continu : SkillClaw « agrège les trajectoires générées pendant l’usage et les traite avec un évolueur autonome, qui identifie les schémas comportementaux récurrents et les traduit en mises à jour de l’ensemble de compétences en raffinant les compétences existantes ou en les étendant avec de nouvelles capacités ».¹ Le système maintient les compétences mises à jour dans un dépôt partagé et les synchronise entre utilisateurs, afin que les améliorations découvertes dans un contexte se propagent à l’ensemble du système sans effort de l’utilisateur.¹

L’évaluation (tirée du résumé). L’article évalue SkillClaw sur un benchmark appelé WildClawBench en utilisant Qwen3-Max comme modèle sous-jacent. La formulation même du résumé est grammaticalement cassée dans la version publiée : « les expériences sur WildClawBench montrent que interaction et rétroaction limitées, il améliore significativement les performances de Qwen3-Max dans des scénarios d’agents en conditions réelles ».¹ Je lis cela comme : avec une interaction et une rétroaction limitées, SkillClaw produit néanmoins des améliorations de performance significatives par rapport à la référence. Le résumé ne publie pas de chiffres spécifiques ; le texte complet le fait vraisemblablement.

Voilà l’article tel que le résumé le décrit. Les auteurs proposent que les écosystèmes d’agents multi-utilisateurs avec 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 rétroaction limitée.

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

Le résumé cite « OpenClaw » comme un exemple (« les agents LLM tels qu’OpenClaw ») d’agent qui utilise des compétences réutilisables. Je ne sais pas ce qu’est OpenClaw à partir du seul résumé ; je n’ai pas pu l’identifier rapidement comme un produit commercial spécifique. Le framework de l’article (SkillClaw) cible les écosystèmes d’agents multi-utilisateurs en général, et non OpenClaw spécifiquement, donc la question « qu’est-ce qu’OpenClaw » est essentiellement tangentielle à l’argument. Je le signale pour que personne ne lise ce billet 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 correspond à un problème réel que je vis dans l’écosystème des compétences Claude Code. Cette affirmation m’appartient, pas à l’article. Voici pourquoi je pense que la correspondance tient.

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 d’accompagnement) qui décrit comment une tâche doit être effectuée. Vous l’écrivez une fois. Vous la validez. Vous la référencez avec une commande slash ou via l’autocomplétion @skill-name ; la mécanique de construction de compétences personnalisées est simple. Une fois livrée, c’est un artefact statique. Aucun mécanisme automatique ne surveille comment la compétence est utilisée en pratique ni ne met à jour sa définition en fonction de ce qui fonctionne et de ce qui échoue.

Des utilisateurs différents rencontrent indépendamment les mêmes modes d’échec. 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, heurte le cas limite, le contourne manuellement et passe à autre chose. Une autre personne, ailleurs, rencontre le même cas limite et met en place son propre contournement. La compétence elle-même ne change jamais.

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 dans l’historique de session de chaque utilisateur individuel. Il n’est simplement agrégé nulle part, donc personne n’agit dessus.

La solution est soit manuelle, soit absente. À l’heure actuelle, le seul mécanisme d’amélioration des compétences est que je remarque un problème dans mon propre usage, que quelqu’un ouvre un ticket, ou que quelqu’un ouvre une PR. Toutes ces voies exigent un effort de l’utilisateur. L’idée centrale de l’article SkillClaw, à savoir que les données de trajectoire existent déjà et devraient alimenter automatiquement les mises à jour des compétences, est exactement le mécanisme qui nous manque.

Voilà mon affirmation sur la manière dont la formulation de l’article s’applique à Claude Code. Ce n’est pas ce que dit l’article. C’est ma lecture de l’article à la lumière de mon propre travail.

Le schéma Shokunin, appliqué aux compétences

Une formulation revient sans cesse quand je pense au métier. Jiro Ono, le maître sushi, est l’exemple canonique. Soixante ans du même travail. Chaque jour, il observe ce qui se passe au comptoir, ajuste la technique, affine la température du riz, l’angle du couteau, le rythme du shari. Le travail lui-même est le signal d’apprentissage. Le praticien est l’agrégateur.

J’ai écrit sur la formulation Shokunin / boucle qualité il y a quelque temps. L’idée centrale : le métier 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 réside 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 arrêtez de surveiller. L’écart entre ce que la compétence visait 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é : non pas un remplacement de l’humain, mais un mécanisme qui surveille toutes les trajectoires, remarque ce qui a cassé d’une session à l’autre et propose des mises à jour en retour dans la définition de la compétence. L’ambition n’est pas 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 schéma SkillClaw pour les compétences Claude Code que je maintiens aujourd’hui, voici ce dont j’aurais besoin :

1. Un journal de trajectoires 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 ?). La journalisation au niveau de la session existe déjà dans Claude Code ; la question est de savoir si elle est agrégée entre sessions et extraite pour le propriétaire de la compétence.

2. Un détecteur de schémas. Quelque chose qui lit le journal de trajectoires 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 utilisateurs. L’exigence est un clustering sur des données de trajectoire structurées, pas de l’AGI.

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

4. Un filtre. Chaque mise à jour proposée passe par une revue humaine, une vérification factuelle (le même filtre 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. Une 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 récupère). Dans un écosystème distribué, c’est plus difficile.

La plupart existe déjà dans Claude Code : journalisation des sessions, définitions de compétences versionnées, boucle de critique 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. La taxonomie organisationnelle des commandes, compétences, sous-agents et règles fournit déjà le socle structurel ; ce qui manque, c’est le canal de rétroaction qui maintient chaque catégorie vivante après le déploiement.

L’implication inconfortable

Chaque compétence que j’ai livrée au cours des six derniers mois est morte exactement au sens décrit par l’article SkillClaw. 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. Mes 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 n’ouvre quelque chose.

Le travail que j’ai effectué hier soir sur la « Référence des paramètres » correspond exactement à ce schéma. 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 font l’objet de recherches. Ce sont des données de trajectoire agrégées, qui me disent littéralement quelles compétences du guide sont invoquées et où atterrissent les résultats. Et tant que je n’étais pas allé examiner ces données, le guide était statique. Il l’était depuis des semaines. Non pas parce que personne ne surveillait les trajectoires, mais parce que j’étais la seule personne à pouvoir 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 n’avez pas de pipeline automatique qui va 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 meurent à l’instant où elles sont livrées, ou si vous construisez le veilleur qui les maintient en vie. Le principe du compound context s’applique ici : chaque observation de trajectoire se compose avec la suivante, et la valeur de la compétence croît de manière non linéaire avec la rétroaction qu’elle ingère. Inversement, traiter context as architecture signifie reconnaître que la structure d’une compétence détermine sa capacité même à absorber de nouvelles informations.

L’agrégateur minimum viable

Avant de commencer ce billet, je n’avais aucune agrégation de trajectoires sur mes compétences. Aucune. J’avais un historique de session que je pouvais lire manuellement, mais rien qui faisait remonter des schémas à travers les sessions. C’est exactement la pathologie des compétences statiques que décrit l’article, et je la vivais.

Voici la plus petite chose concrète que je peux livrer maintenant, aujourd’hui : un seul fichier texte qui consigne chaque invocation de compétence à travers mes propres sessions, en ajout uniquement, 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 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 quand je révise une compétence et me demander : la même casse s’est-elle produite trois fois ce mois-ci ?

C’est l’engagement. Un fichier. En ajout uniquement. Journalisé par invocation. Revu quand 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 s’exécutant sur un écosystème multi-utilisateurs. Mon ambition est de ne pas opérer dans le noir.

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. Le résumé mentionne « les agents LLM tels qu’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 commercial spécifique à partir du seul résumé. L’important : le framework SkillClaw de l’article cible les écosystèmes d’agents multi-utilisateurs en général, pas OpenClaw ni Claude Code spécifiquement. Quoi qu’OpenClaw puisse être, l’article n’est pas un article sur Claude Code, et mes affirmations sur Claude Code dans ce billet m’appartiennent, elles ne viennent pas de l’article.¹

Quelle est la contribution réellement nouvelle de l’article ?

D’après le résumé : un framework pour l’évolution collective des compétences dans les écosystèmes d’agents multi-utilisateurs qui (1) agrège les trajectoires entre utilisateurs et dans 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 de compétences dans un dépôt partagé qui se synchronisent entre 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 ?

Le résumé décrit l’amélioration comme « significative » sur un benchmark appelé WildClawBench en utilisant Qwen3-Max, dans des conditions de rétroaction limitée, mais ne publie pas de chiffres spécifiques.¹ Pour les chiffres, le texte complet est la source.

En quoi cela diffère-t-il d’une pull request git sur 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, ouvrir 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 n’ait à ouvrir 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 question distincte. La contribution de l’article est de montrer qu’elle est techniquement cohérente.

Cela s’applique-t-il à 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 quiconque construit des compétences pour Claude Code ou tout framework d’agent similaire devrait réfléchir à la façon 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 le Shokunin ?

La formulation Shokunin / boucle 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