Ceux qui prennent au sérieux le budget contextuel obtiendront une meilleure expérience d'assistance par l'IA que ceux qui entassent aveuglément les compétences.

Auteur et source de l'article : 0x9999in1, ME News

TL;DR

• L'écosystème de compétences/plugins des assistants de programmation IA dominants connaît actuellement une « indigestion après une croissance sauvage » — accumulation de compétences redondantes, inutiles et fantômes, qui érodent gravement les ressources précieuses de la fenêtre de contexte.
• Lobster Dad a open-source un méta-compétence dédiée à un "examen complet" de Skill, couvrant cinq fonctions principales : audit budgétaire, détection de doublons, détection d'inactifs, audit du répertoire racine et simplification des descriptions.
• La fenêtre de contexte est l'une des ressources les plus rares des grands modèles d'IA ; chaque compétence redondante utilise des tokens inutiles pour occuper l'espace de raisonnement dont vous avez réellement besoin.
• La valeur fondamentale de cet outil n'est pas « encore une compétence de plus », mais de gérer toutes les compétences avec une seule compétence — c'est une infrastructure de niveau fondamental.
• Le désordre dans l'écosystème Skill n'est pas un phénomène isolé, mais un problème structurel. Un système de plugins sans mécanisme d'audit finira inévitablement par connaître une augmentation de l'entropie.
• L'open source permet à la communauté d'itérer à partir de cela, ce qui pourrait être le point de départ de la standardisation de la gouvernance de Skill.

D'abord, la situation actuelle : votre dépôt Skill pourrait déjà être une décharge.

C'est dur à entendre. Mais ouvre ta configuration d'assistant IA, compte combien de compétences tu as installées, puis réfléchis auxquelles tu as utilisées la dernière fois.

La réponse risque de laisser la plupart des gens silencieux.

À partir du second semestre 2025, des outils de programmation IA tels que Cursor, Windsurf, Codex et Claude Code entrent collectivement dans une « course aux compétences ». Les contributeurs de la communauté produisent en masse, les bibliothèques intégrées officielles ne cessent de s’agrandir, et les configurations personnelles s’accumulent couche après couche.

What about the result?

Un utilisateur intensif typique possède facilement plus de 50 compétences. Parmi celles-ci, peut-être moins de 10 sont déclenchées au quotidien. Les 40 autres reposent en silence, chargées dans le contexte à chaque démarrage de conversation, consommant discrètement le budget de tokens, puis — ne font rien.

Ce n'est pas une perte. C'est un crime.

Pourquoi cela ? Parce que la fenêtre de contexte n’est pas infinie. Même en 2026, la longueur de contexte efficace des modèles dominants se situe entre 128K et 200K tokens, ce qui semble beaucoup, n’est-ce pas ? Mais faites le calcul : instructions système, historique de conversation, extraits de code, contenu de fichiers, définitions d’outils, descriptions de compétences… l’espace réellement disponible pour la « réflexion » est bien plus limité que vous ne le pensez.

Chaque description inutile de compétence occupe 200 tokens ; 50 en font 10 000. Dix mille tokens, c’est assez pour que le modèle lise 400 lignes de code supplémentaires.

Ce n'est pas une déduction théorique. C'est quelque chose qui se produit chaque jour.

Pourquoi personne ne s'en occupe ? Parce que "ajouter" est dix mille fois plus facile que "soustraire"

Les humains présentent un biais psychologique profondément ancré : le biais d'ajout.

Face aux problèmes, nous avons naturellement tendance à "ajouter quelque chose" pour les résoudre, plutôt que de "supprimer quelque chose". Une étude publiée en 2021 dans la revue Nature a clairement montré que les humains ignorent systématiquement les solutions par soustraction, même lorsque celles-ci sont plus efficaces.

L'écosystème Skill a parfaitement reproduit cet écart.

Un contributeur de la communauté a créé une nouvelle fonctionnalité et l'a publiée. L'utilisateur a trouvé que "cela pourrait être utile" et l'a installée. L'équipe officielle a jugé que "la fonctionnalité couvre un large éventail de cas d'utilisation" et l'a intégrée.

Qui supprime ? Qui audite ? Qui dit « Ce Skill est en double avec celui-là, supprime-en un » ?

Personne.

Parce qu'il n'y a pas d'incitation à supprimer. Créez une nouvelle compétence qui vous permette d'obtenir des étoiles, d'être reconnu par la communauté et de l'ajouter à votre CV. Nettoyer une ancienne compétence ? Vous n'obtenez rien.

C'est un problème structurel. Ce n'est pas une question technique, mais un problème d'incitation.

Jusqu’à ce que quelqu’un décide : peu importe les incitations, je vais le faire.

Le père des langoustes agit : utilise une seule Skill pour gérer toutes les Skill

Qui est le père de la langouste ? Si vous fréquentez la communauté des outils d'IA pour la programmation, vous ne pouvez pas ne pas connaître ce pseudonyme. Joueur profondément impliqué dans les écosystèmes Codex et Claude, il est réputé pour sa pensée systémique et son obsession de la propreté technique. Le titre de « père de la langouste » reflète lui-même la reconnaissance de la communauté — être qualifié de « père » signifie qu'il est incontournable dans son domaine spécifique.

Ce qu'il a open-sourcé cette fois-ci est, en substance, une méta-compétence (Meta-Skill).

Qu'est-ce qu'une méta-compétence ? C'est une compétence pour gérer les compétences. Elle ne vous aide pas à écrire du code, à appeler des API ou à générer des documents. Elle ne fait qu'une seule chose : effectuer un examen complet, quantifié et exécutable de toutes vos compétences actuelles.

Cinq fonctionnalités, détaillées une par une.

C'est le plus hardcore.

Il fait quelque chose de très direct : il calcule l'espace en tokens de contexte occupé par chaque compétence, détermine le pourcentage que chacune représente par rapport au budget total, puis fournit des recommandations d'optimisation.

Pourquoi est-ce important ? Parce que la grande majorité des utilisateurs n'ont aucune perception de la quantité de ressources que « Skill » a consommées.

Vous pensez qu'ajouter une compétence ne fait que rajouter une fonctionnalité. En réalité, le texte de description, les définitions de paramètres, le code d'exemple et les règles de déclenchement de chaque compétence doivent tous être intégrés dans le prompt système. À chaque inférence, le modèle doit d'abord « lire » tout ce contenu avant de décider s'il doit l'appeler.

C'est comme porter un sac à dos de randonnée rempli de 50 outils. Vous pensez que "porter, ce n'est pas perdre", mais chaque kilogramme supplémentaire augmente votre consommation d'énergie. Quand vous aurez vraiment besoin de sprinter, vous n'aurez plus de force.

Ce que fait l'audit budgétaire, c'est ouvrir ton sac et te dire : « Ce couteau suisse pèse 3 kg mais tu ne l'as jamais utilisé, jette-le. »

Le problème résolu par cette fonction est peut-être plus grave que vous ne le pensez.

Son champ de balayage couvre quatre niveaux :

• Bibliothèque intégrée Codex
• Cache du plugin
• Code repository
• Répertoire racine des compétences personnelles

Scannez les compétences portant le même nom, ayant une description similaire ou une fonction chevauchante à travers les niveaux, et marquez les éléments redondants.

Pourquoi y a-t-il des doublons ? Il y a de nombreuses raisons.

La plateforme intègre déjà un Skill de "mise en forme du code", que vous ne connaissiez pas, et vous en avez installé un autre provenant de la communauté, aux fonctions presque identiques. Deux Skills accomplissant la même tâche, consommant deux budgets.

Ou plus subtilement : il y a six mois, vous avez écrit un Skill personnalisé pour traiter l'analyse JSON, puis l'application officielle a été mise à jour et a intégré une meilleure solution dans sa bibliothèque intégrée. Votre ancienne version est toujours là, et personne ne vous a dit de la supprimer.

La détection de doublons ne se limite pas au nom. Même si les noms sont différents, mais que les descriptions sont hautement similaires, elles seront également signalées. C’est là que réside véritablement la composante technique — il s’agit d’effectuer une comparaison de similarité sémantique, et non une simple correspondance de chaînes de caractères.

À partir des journaux historiques, identifiez les « compétences fantômes » non utilisées depuis longtemps.

Cette logique est claire : si une compétence n'a jamais été déclenchée au cours des 30, 60 ou 90 derniers jours, il est probable que deux scénarios s'appliquent — soit votre flux de travail n'en a pas besoin, soit les conditions de déclenchement sont mal conçues, ce qui empêche le modèle de la sélectionner.

Quelle que soit la méthode, la conclusion est la même : cela gaspille simplement le budget.

Cette fonction génère une « liste de candidats à nettoyer ». Notez qu'il s'agit de « candidats », et non d'une suppression directe. La décision finale revient à l'utilisateur. Cette conception est retenue et intelligente — elle connaît ses limites.

Certains compétences sont effectivement rares mais cruciales. Par exemple, « assistance à la migration de base de données » : vous pourriez ne l’utiliser qu’une fois tous les trois mois, mais quand vous en avez besoin, elle peut vous sauver la vie. Ainsi, les résultats du filtrage sont une référence, pas un jugement.

Cette fonctionnalité a un caractère plus "opérationnel", mais elle est extrêmement utile.

Ce qu'il fait : recenser tous les répertoires sources des compétences, indiquer leur état d'activation/désactivation, et analyser la chaîne de chargement.

Pourquoi cela est-il nécessaire ? Parce que les sources de Skill sont multiples : certaines proviennent de la configuration globale, d'autres de la configuration au niveau du projet, certaines sont injectées automatiquement par des plugins, et d'autres sont créées manuellement par les utilisateurs.

Lorsque le nombre de compétences est faible, vous avez une idée claire. Lorsqu'il augmente à plusieurs dizaines, vous ne savez plus d'où vient cette compétence, si vous pouvez la supprimer en toute sécurité, ou si sa suppression affectera d'autres éléments.

L'audit du répertoire racine vous dessine une carte. Il vous indique où se trouve chaque Skill, qui le charge et s'il est actif ou inactif.

Avec cette carte, vous pouvez opérer en toute sécurité.

La dernière fonctionnalité, qui semble la plus "petite", possède en réalité un levier énorme.

Ce qu'il fait : identifier les compétences dont la description est trop longue et proposer des solutions pour les simplifier.

Pourquoi la longueur de la description est-elle si importante ? Revenons à ce qui a été dit précédemment : la description des compétences doit être intégrée dans le prompt du système. Chaque mot est un token. Si la description d’une compétence peut être réduite de 200 à 80 tokens, l’espace économisé, multiplié par le nombre de compétences, devient très significatif.

De nombreuses compétences contribuées par la communauté sont décrites comme des résumés d’articles — contexte, motivation, scénarios d’application, précautions, exemples d’entrées et de sorties, avec beaucoup de détails. Les auteurs ont fait preuve de beaucoup de soin, mais du point de vue de l’ingénierie, il s’agit d’une surconception.

La description requise du modèle : précise, unique, distincte. Utilisez le moins de mots possible pour que le modèle comprenne « ce que fait ce Skill et quand l'appeler ». Chaque mot supplémentaire est une perte de budget de contexte.

Décrivez cette fonction de manière concise : il s'agit essentiellement d'une "optimisation inverse de l'ingénierie des invites" — il ne s'agit pas d'écrire de meilleures invites, mais de réduire les invites existantes tout en conservant la même quantité d'information.

Où est la valeur réelle ? Ce n’est pas la fonctionnalité, c’est la manière de penser.

Cinq fonctionnalités ont été décomposées. Prises individuellement, elles ne semblent pas « révolutionnaires ». Mais ensemble, elles représentent un changement de paradigme :

De la « création de davantage de Skill » à la « gouvernance des Skill existants ».

La valeur de cette affaire ne réside pas dans la quantité de code ni dans la complexité de l'algorithme, mais dans le fait que quelqu'un traite enfin ce problème comme une "priorité absolue".

Au cours des deux dernières années, l'attention de l'écosystème des outils IA s'est concentrée sur l'ajout de fonctionnalités. Plus de modèles, plus de fonctionnalités, plus de plugins, plus de compétences. Courir vite, courir fort, personne ne se retourne.

Mais toute personne ayant une expérience en ingénierie sait que la complexité d'un système, lorsqu'elle atteint un certain niveau sans mécanisme de gouvernance correspondant, s'effondre.

Ce n'est pas possible. C'est certain.

Dans l'ingénierie logicielle, il existe un concept appelé « dette technique ». Chaque solution temporaire, chaque « on va laisser comme ça pour l'instant », chaque redondance non nettoyée, constitue une dette. Plus vous empruntez, plus les intérêts augmentent, jusqu'au jour où vous réalisez que toute votre énergie est consacrée à rembourser la dette, sans aucune capacité left pour entreprendre de nouvelles choses.

La dette technique de l'écosystème Skill est arrivée à un moment où elle doit être prise en compte.

L'outil "Père de la langouste" est, en essence, un auditeur de dettes. Il ne rembourse pas vos dettes pour vous, mais il vous indique : combien vous devez, où vous devez, et quelles dettes prioriser.

Cela a bien plus de valeur que "j'ai écrit une autre compétence utile".

La signification du logiciel open source : des outils personnels aux normes communautaires

Le père du homard a choisi d'ouvrir le code, une décision en soi méritant d'être soulignée.

Il aurait tout à fait pu transformer cet outil en plugin payant. Le marché cible est clair, les besoins réels, et le nombre d'utilisateurs prêts à payer ne manquerait pas. Mais il a choisi de le rendre open source.

Pourquoi ?

Je suppose qu'il y a deux considérations.

Niveau 1 : Pour que cet outil atteigne véritablement sa pleine valeur, il faut une collaboration communautaire. Les mécanismes de chargement des compétences, les formats de journaux et les structures de répertoires varient d'une plateforme IA à l'autre. Une seule personne ne peut pas s'adapter à tout, mais cent contributeurs peuvent.

Deuxième couche : Il pourrait vouloir promouvoir non seulement un outil, mais une norme. Comment la gouvernance de Skill devrait-elle être mise en œuvre ? Quels sont les axes d’audit ? Quelles sont les meilleures pratiques en matière d’allocation budgétaire ? Ces questions nécessitent un consensus communautaire pour trouver des réponses.

L'open source est le meilleur moyen d'atteindre un consensus.

En revisitant l'histoire de l'ingénierie logicielle, ESLint pour la norme de code JavaScript, Black pour la mise en forme Python, et Prettier pour le style de code frontend — ces outils sont devenus des standards de fait parce que l'open source a permis à la communauté de participer à l'établissement des règles.

Ce Meta-Skill du père du homard peut-il devenir l'ESLint de la gouvernance des Skill ?

Il est trop tôt pour juger. Mais la direction est bonne.

Une question plus profonde : le système Skill devrait-il être redessiné ?

Les outils d'audit résolvent les problèmes de « stock ». Mais si nous élevons notre point de vue d'un niveau, nous constatons un problème plus fondamental :

Pourquoi Skill perd-il le contrôle ?

La réponse est : le système Skill actuel manque de gestion du cycle de vie.

Une fois qu'une compétence est créée, elle existe pour toujours. Il n'y a pas de mécanisme d'expiration, pas de dépréciation de version, pas de déclin d'activité. Elle agit comme un processus qui ne meurt jamais, occupant des ressources jusqu'à ce que quelqu'un la tue manuellement.

Comparez la gestion des processus du système d'exploitation : création, planification, mise en sommeil, terminaison. Cycle de vie complet et fermé.

Comparez la gestion des dépendances des gestionnaires de paquets :npm auditvérifie les vulnérabilités de sécurité, npm outdatedvérifie les dépendances périmées, npm prunenettoie les paquets inutiles. Les outils de gestion font partie de l'écosystème.

Et le système Skill ? Créer → Utiliser → ... plus rien. De nombreux éléments sont manquants au milieu.

L'outil du père du homard consiste essentiellement à compenser les lacunes de la conception du système à l'aide d'outils externes. Il est utile, mais il révèle également un fait : les infrastructures de plateforme d'outils IA en matière de gouvernance des compétences sont encore à un stade primitif.

Ce n'est pas une critique. C'est une étape inévitable du développement. De 2024 à 2025, l'objectif principal de la plateforme était de « faire fonctionner l'écosystème » ; la gouvernance pouvait attendre. Mais au milieu de 2026, l'écosystème fonctionne déjà. Il est temps de rattraper le retard.

En conclusion

Revenons à la question initiale : combien de compétences dans ton assistant IA sont actives ?

Si tu ne peux pas répondre, cela signifie que tu dois faire un examen médical.

Le père du homard a fourni un outil. Gratuit. Open source. Cinq dimensions, couverture complète.

C'est à toi de décider.

Mais je suis certain d'un point : ceux qui prennent au sérieux le budget contextuel auront une meilleure expérience d'assistance par l'IA que ceux qui entassent sans réflexion les compétences.

Parce que l'IA n'est pas tout-puissante. Son attention est limitée, sa mémoire est limitée, ses ressources de raisonnement sont limitées. Plus les informations que vous lui fournissez sont précises et propres, meilleur sera le résultat qu'elle vous renvoie.

Ce n'est pas de la métaphysique. C'est la théorie de l'information.

Shannon nous l'a déjà dit en 1948 : la capacité d'un canal est limitée, plus il y a de bruit, plus le taux de transmission d'informations utiles diminue.

Les compétences zombies dans votre liste sont du bruit.

Éliminez-les.

Références

1. Adams, G. S., Converse, B. A., Hales, A. H., & Klotz, L. E. (2021). Les gens ignorent systématiquement les changements soustractifs. Nature, 592(7853), 258–261.
2. Shannon, C. E. (1948). A Mathematical Theory of Communication. Bell System Technical Journal, 27(3), 379–423.
3. OpenAI. (2024). Documentation sur la fenêtre de contexte et les limites de jetons de GPT-4 Turbo. https://platform.openai.com/docs/models
4. Anthropic. (2025). Fiche du modèle Claude : utilisation de la fenêtre de contexte et surcharge du prompt système. https://docs.anthropic.com/en/docs/about-claude/models
5. Équipe Cursor. (2025). Règles et compétences : Comment les instructions personnalisées sont chargées dans le contexte. Documentation Cursor.
6. Documentation npm. (2025). npm-audit, npm-prune : Gestion du cycle de vie des paquets. https://docs.npmjs.com/cli
7. Père du homard. (2026). Skill Health Check Meta-Skill [projet open source]. Dépôt GitHub.
8. Sculley, D., et al. (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems (NeurIPS), 28.