Au-delà de l'annonce : nous avons exécuté 1416 skills Claude pour trouver le nombre réel de celles qui fonctionnent

Vous avez probablement vu les chiffres : des titres et des annuaires annonçant plus de 23 000 skills Claude disponibles à l'installation. Ce chiffre suggère un écosystème vaste et mature d'outils prêts à augmenter les capacités du modèle de base. C'est un nombre impressionnant, mais il soulève une question technique essentielle : que signifie réellement « disponible » ? Dans la plupart des cas, cela signifie qu'un manifeste SKILL.md a été trouvé dans un dépôt de code public. Il s'agit d'un décompte basé sur la découverte de fichiers, et non sur une vérification fonctionnelle.

Cette approche est simple, scalable, et finalement trompeuse. Elle n'indique en rien si une skill s'installera, s'exécutera sans erreurs, ou remplira efficacement sa fonction annoncée. Elle ne vous dit pas s'il s'agit d'un projet abandonné, d'une preuve de concept défectueuse, ou même si ses performances sont inférieures à celles obtenues sans utiliser de skill du tout.

Chez SkillProof, nous adoptons une approche différente. Nous ne comptons pas les dépôts ; nous installons et exécutons les skills sur un ensemble standardisé de tâches réelles. Cet article présente nos résultats issus du test de 1416 skills. C'est une réponse directe, étayée par des données, à la question du nombre de skills de code Claude qui fonctionnent réellement, et une analyse de la fiabilité des marketplaces de skills Claude en tant que sources d'outils prêts pour la production.

Le défaut du décompte de fichiers

Le problème fondamental d'un décompte de plus de 23 000 skills est qu'il considère la découverte comme une validation. Le scraping de plateformes comme GitHub à la recherche de fichiers SKILL.md est une tâche triviale. Le nombre qui en résulte est un bon argument marketing, mais c'est une métrique de vanité qui ignore la réalité du développement logiciel.

Un dépôt contenant un manifeste de skill n'est qu'un point de départ. C'est une affirmation, pas une garantie. Lorsque nous avons commencé notre processus de test systématique des skills, nous avons rapidement identifié des schémas d'échec courants que le simple décompte de fichiers ignore complètement :

• Manifestes incomplets ou malformés : Le fichier SKILL.md existe, mais il lui manque des sections requises, il pointe vers des définitions d'outils inexistantes ou sa syntaxe est incorrecte. La skill est impossible à installer sans correction manuelle.
• Dépendances cassées : Le code de la skill repose sur des bibliothèques externes qui sont obsolètes, qui ont subi des changements majeurs (breaking changes), ou qui ne sont plus disponibles. L'installation peut réussir, mais la skill échouera à l'exécution.
• Prérequis d'environnement non documentés : Une skill peut nécessiter des variables d'environnement spécifiques, un service local en cours d'exécution ou des jetons d'authentification qui ne sont pas mentionnés dans sa documentation. Une skill que nous avons testée exigeait une version spécifique d'une base de données fonctionnant sur localhost:5433, un détail découvert uniquement en lisant son code source Python. Sans cela, elle n'était pas fonctionnelle.
• Projets abandonnés : Le dépôt n'a pas été mis à jour depuis des années. Le code a été écrit pour une version antérieure de l'API Claude et n'est plus compatible.
• « Prompt-en-tant-que-Skill » : Certaines skills ne contiennent aucun outil réel. Ce sont simplement des prompts élaborés, empaquetés dans un format de skill. Bien que potentiellement utiles, elles ne représentent pas une extension fonctionnelle des capacités du modèle et n'offrent souvent pas de meilleures performances qu'un prompt bien rédigé.

Le simple fait de compter ces dépôts gonfle la taille et la santé perçues de l'écosystème. Cela crée un paysage où trouver un outil fonctionnel et fiable relève de l'expérimentation. Notre méthodologie de test a été conçue spécifiquement pour filtrer ce bruit en faisant de l'exécution la principale mesure de la validité d'une skill.

Nos résultats : un regard réaliste sur le décompte réel

Nous avons installé et tenté d'exécuter 1416 skills provenant de divers annuaires et dépôts publics. Chaque skill a été soumise à une série de tests automatisés conçus pour invoquer ses fonctionnalités principales. Les résultats donnent une image beaucoup plus claire de l'état de l'écosystème.

Sur les 1416 skills que nous avons testées, seules 889 (63 %) ont réussi nos tests d'exécution initiaux sans aucune intervention manuelle.

Voici une ventilation complète de nos résultats :

Statut	Nombre	Pourcentage du total
Réussite (Fonctionne sans configuration)	889	63 %
Nécessite une configuration (Requiert une configuration manuelle)	467	33 %
Échec (Performances inférieures au modèle de base)	60	4 %
Total testé	1416	100 %

Analysons ce que chacune de ces catégories signifie pour un développeur qui essaie d'utiliser ces outils.

Réussite (63 %) : Ces skills se sont installées correctement et se sont exécutées sur notre banc d'essai sans erreurs. C'est le « décompte réel des skills Claude de l'annuaire » à partir de notre échantillon — le sous-ensemble des skills qui sont immédiatement utilisables. C'est le niveau de référence qu'un utilisateur devrait attendre de toute skill listée dans un annuaire. Cependant, comme nous le verrons, « fonctionner » ne signifie pas automatiquement « haute qualité ».

Nécessite une configuration (33 %) : C'est une catégorie importante et souvent négligée. Ces 467 skills n'étaient pas défectueuses, mais elles n'étaient pas prêtes à l'emploi (plug-and-play). Les raisons courantes incluaient :

• La nécessité de définir manuellement des clés d'API en tant que variables d'environnement.
• Le besoin de se connecter à une base de données fournie par l'utilisateur ou à un service tiers.
• La dépendance à des fichiers locaux ou à des configurations système non spécifiées dans le SKILL.md.

Par exemple, une skill pour interagir avec une API de gestion de projet est inutile sans une clé d'API et une URL de point de terminaison. Ces skills ne sont pas des échecs, mais les lister sans instructions de configuration claires et préalables dessert l'utilisateur. Un annuaire qui ne fait pas la différence entre une skill en « Réussite » et une skill « Nécessitant une configuration » présente une image peu fiable.

Échec (4 %) : C'est la catégorie la plus préoccupante. Ces 60 skills ont non seulement échoué à remplir leur fonction, mais ont produit des résultats activement pires que ceux obtenus en utilisant le modèle de base sans aucune skill. Cela se produit lorsque la logique d'une skill est défectueuse, amenant le modèle à :

• Se retrouver bloqué dans une boucle, en essayant d'appeler de manière répétée un outil défectueux.
• Halluciner l'utilisation d'outils qui n'existent pas dans sa propre définition.
• Mal interpréter l'intention de l'utilisateur et appliquer un outil de manière incorrecte, ce qui conduit à des erreurs ou à des résultats absurdes.

Une skill que nous avons testée était conçue pour formater des extraits de code. Lorsqu'on lui a fourni une simple fonction Python, elle a tenté d'appeler un outil format_javascript, a échoué et a renvoyé un message d'erreur. La même requête adressée à Claude seul aurait abouti à un extrait de code Python correctement formaté. Ces 60 skills ne sont pas seulement inutiles ; elles sont préjudiciables. Aucun annuaire sérieux ne devrait les lister sans un avertissement clair. Nous publions ces échecs car ils constituent une partie essentielle des données.

Au-delà de l'exécution : qu'est-ce qui définit la qualité d'une skill ?

Les données montrent qu'environ deux skills sur trois que vous pourriez trouver s'exécuteront. Mais cela ne répond qu'à la première partie de la question. La seconde, plus importante, concerne la qualité. La « qualité des 23 000 skills Claude » n'est pas une question de quantité, mais de performance.

Une skill qui s'exécute mais accomplit mal sa tâche n'est guère meilleure qu'une skill qui ne s'exécute pas du tout. C'est pourquoi, après qu'une skill a réussi notre test d'exécution initial, nous la notons sur une échelle de 1 à 10 en fonction de ses performances sur une batterie de tâches réelles. Notre grille de notation complète est détaillée dans notre méthodologie, mais elle s'articule autour de quelques principes clés :

• Fiabilité : La skill réussit-elle de manière constante sa tâche déclarée ? Utilise-t-elle les bons outils pour le travail ?
• Précision : Le résultat est-il correct et sans erreurs ? Si elle interagit avec une API, gère-t-elle les données correctement ?
• Efficacité : Résout-elle le problème sans étapes ou appels d'outils inutiles ?
• Gestion des échecs : Lorsqu'elle rencontre un cas limite ou une entrée non valide, renvoie-t-elle un message d'erreur utile ou plante-t-elle ?

La différence entre une skill bien notée et une skill mal notée est frappante.

Une skill bien notée, comme un outil d'infrastructure cloud bien conçu, interprétera correctement une requête telle que « lister toutes les instances EC2 dans us-east-1 », utilisera son outil list_instances avec le paramètre region correct, gérera la réponse paginée de l'API et présentera à l'utilisateur une liste propre et précise.

Une skill mal notée peut avoir le même objectif mais échouer dans son exécution. Par exemple, un autre outil cloud que nous avons testé ignorait la région spécifiée et listait les instances de sa région par défaut. Il « fonctionnait » dans le sens où il ne plantait pas, mais il produisait la mauvaise réponse, ce qui le rendait peu fiable.

Les 60 skills qui ont obtenu un score inférieur à celui du modèle de base représentent le plancher. Elles sont une démonstration tangible qu'une skill mal conçue est pire qu'aucune skill du tout. C'est un point de données essentiel qui est perdu lorsque les annuaires privilégient la taille du catalogue à la performance vérifiée.

Trouver le signal dans le bruit

La disparité entre les plus de 23 000 skills annoncées et notre taux de réussite aux tests de 63 % met en évidence le problème principal : l'écosystème est rempli de bruit. Le nombre réel de skills fonctionnelles et de haute qualité ne représente qu'une petite fraction du total annoncé.

Tester manuellement chaque skill que vous trouvez n'est pas une solution pratique pour un développeur. Le processus est long et gourmand en ressources. Notre test de 1416 skills a nécessité un effort d'ingénierie important pour construire le harnais de test et des ressources de calcul substantielles pour exécuter les évaluations. C'est précisément la raison pour laquelle la plupart des annuaires ne le font pas. Il est beaucoup plus facile d'exécuter un scraper et de publier un grand nombre non vérifié.

L'objectif d'un annuaire de skills devrait être de filtrer le signal du bruit. Il devrait effectuer le travail de validation pour le compte de l'utilisateur. Cela signifie :

1. Exécuter chaque skill : Une skill n'est pas « vérifiée » tant qu'elle n'a pas été exécutée.
2. Tester la correction : La skill doit être évaluée par rapport à des tâches réelles pour voir si elle fonctionne comme annoncé.
3. Publier les échecs : Un annuaire qui ne montre pas ce qui a échoué cache la moitié de l'histoire. Les données sur les échecs sont tout aussi importantes que les données sur les réussites.

En testant des skills dans des dizaines de catégories, de l'analyse de données au développement web, nous construisons une carte de ce qui fonctionne, de ce qui nécessite des ajustements et de ce qu'il faut éviter complètement.

Cette approche basée sur les données est la seule manière fiable de répondre à la question : « les marketplaces de skills Claude sont-elles fiables ? » La réponse est : elles ne sont fiables qu'à la hauteur de leur processus de vérification. Une marketplace qui n'est qu'une liste de dépôts n'est pas une source fiable d'outils professionnels. Un annuaire qui exécute, teste et note chaque entrée fournit une base de confiance.

Lectures associées : combien dépassent réellement le niveau de base · notre méthodologie de test.

Nous avons effectué ce travail sur l'ensemble de notre catalogue. Les 889 skills qui ont réussi nos tests sont disponibles à la consultation, avec leurs scores et un verdict sur leurs performances. Pour les développeurs qui ont besoin d'un ensemble d'outils éprouvés, nous proposons un pack sélectionné de nos skills les mieux notées pour 10 $, toutes garanties de fonctionner et de performer comme prévu. C'est notre solution au problème du signal sur bruit : un sous-ensemble restreint, vérifié et de haute qualité de l'écosystème public massif et non vérifié.