Claude Skills : révolution ou gadget ? Mon analyse
Claude Skills, annoncés début 2026 par Anthropic, sont présentés comme le futur de l'organisation des comportements des agents : des modules réutilisables, composables, versionnés, qui encapsulent une compétence (« publier un article », « faire une release Vercel », « résumer un PDF »). Après 2 mois d'utilisation quotidienne avec ~30 skills installés sur mon Claude Code, voici mon verdict : ni révolution, ni gadget. C'est un outil utile qui résout un vrai problème, mais avec des limites qui empêchent la promesse marketing de se réaliser.
Ce que Claude Skills promettent
Un skill, c'est un dossier avec un SKILL.md (manifeste + instructions) et éventuellement des scripts, templates, données. Quand Claude détecte une situation qui match le skill, il le charge et suit ses instructions.
En théorie, ça remplace :
- •Les gros CLAUDE.md monolithiques
- •Les snippets que tu copies-colles dans tes prompts
- •Les scripts custom pour chaque workflow répétitif
En pratique, ça marche en partie.
Ce que les skills font bien
1. Encapsuler un workflow répétitif
Mon skill publish-article déclenche à chaque fois que je finis un article markdown. Il fait : validation, génération d'un slug, écriture dans content/articles/, call au script de publication, confirmation. Un skill = une tâche claire.
Avant, j'avais un CLAUDE.md avec 200 lignes qui décrivait ce workflow. Je le maintenais avec peine. Maintenant, le skill est un dossier self-contained.
2. Composer entre eux
Un skill peut en appeler un autre. Mon skill write-blog-article appelle validate-markdown qui appelle count-shortcodes. La composition marche, et ça rend chaque skill plus focus.
3. Versionnage via git
Les skills vivent dans des dossiers versionnés. Je peux revenir en arrière si une modification casse quelque chose.
Ce que les skills font mal
1. Détection automatique floue
Anthropic promet que Claude « détecte automatiquement » quand utiliser un skill. En pratique, cette détection est imprévisible. Certains de mes skills s'activent quand je ne m'y attends pas, et inversement.
Fix : j'invoque presque toujours mes skills explicitement (/skill-name). Ça marche, mais ça casse la promesse « auto-détection ».
2. Pas de tests
Écrire un skill, c'est écrire des instructions en prose pour Claude. Tester qu'un skill « marche » demande de lancer Claude dessus et de regarder le résultat. Pas de framework de test, pas de CI, pas de régression tracking. C'est l'âge pré-tests du software.
3. Interaction avec d'autres skills chaotique
Quand j'ai 30 skills installés, leur priorité d'activation devient imprévisible. Un skill générique peut « voler » une activation qui aurait dû revenir à un skill spécifique. Pas de règle claire.
4. Pas de partage standardisé
Il n'y a pas de « marketplace » de skills officielle. Tu trouves des repos GitHub communautaires, mais chacun suit sa propre convention. Installer un skill externe = le copier à la main dans ton dossier skills.
Ma matrice d'évaluation d'un skill
Après 2 mois, je n'installe un skill que si :
| Critère | Minimum acceptable |
|---|---|
| Fréquence d'usage | ≥ 3 fois / semaine |
| Gain par usage | ≥ 2 minutes |
| Prévisibilité | Sait quand s'activer |
| Maintenance | < 10 min / mois |
| Composabilité | Fonctionne seul OU avec 1 autre skill max |
Sur les ~30 skills que j'ai installés, 12 survivent à ces critères après 2 mois. Les autres sont désinstallés ou jamais utilisés.
Les 5 skills que je garde
- 1.
write-blog-article— le skill que j'ai construit moi-même (voir mon article dédié) - 2.
publish-article— validation + publication - 3.
commit-with-convention— génère des messages de commit conventional commits - 4.
debug-test-failure— lit les logs de tests échoués et propose un fix - 5.
generate-svg-diagram— génère des SVG hand-coded dans le style Ralph_Loop
Chacun de ces skills économise 5-15 minutes par usage. Avec 3-10 usages par semaine chacun, c'est 1h30 à 2h de gain hebdomadaire total.
Ce qui manque pour que ce soit vraiment révolutionnaire
- 1.Marketplace officielle avec rating, versioning, dependencies
- 2.Framework de test pour valider qu'un skill fait ce qu'il dit
- 3.Observability — logs structurés de quels skills se sont activés et pourquoi
- 4.Priorité explicite entre skills qui peuvent matcher la même situation
- 5.Sandbox d'exécution — empêcher un skill externe de toucher à ton filesystem sans consentement
Verdict
Ni révolution, ni gadget. Les Claude Skills résolvent un vrai problème (encapsuler des workflows), mais leur implémentation actuelle est à mi-chemin entre une convention communautaire et un vrai système. Utiles si tu les utilises avec discipline, inutiles voire nuisibles si tu les installes en masse.
Ma prédiction : dans 6-12 mois, Anthropic ajoutera un marketplace, un système de tests, et des règles de priorité. Là, ça deviendra vraiment révolutionnaire. Pour l'instant, c'est un outil pragmatique pour les power users.
Ce qu'il faut retenir
- 1.12 skills sur 30 installés survivent après 2 mois d'usage réel.
- 2.La détection automatique est imprévisible — invoque explicitement par défaut.
- 3.Pas de tests, pas de marketplace, pas d'observability — ce qui manque vraiment.
- 4.Gain réel : 1h30-2h par semaine avec 5 skills bien choisis.
- 5.Verdict : outil pragmatique, pas encore révolution.
Pour le workflow complet Claude Code + Ralph Loop qui s'appuie sur ces skills, j'ai écrit un livre dédié :
Soutenez mon travail sur Patreon
Accès anticipé aux articles, contenu exclusif, et la satisfaction de soutenir un auteur indépendant.
Rejoindre — à partir de 3€/mois
