Les Claude Skills, c'est la feature qu'Anthropic a sorti discrètement en mars 2026 et que personne n'a vraiment remarquée avant avril. Deux mois plus tard, je les utilise tous les jours dans Claude Code pour briefer l'IA sur mes projets. Et franchement, ça règle un problème que les system prompts et les MCP ne réglaient pas : avoir un contexte de travail partageable, versionné, et qui ne disparaît pas toutes les 3 conversations.
Voici ce que j'ai appris en les utilisant sur capsül, QuantAnalyst, ucut, et surtout pour automatiser la rédaction de ce blog.
Le problème : briefer Claude 50 fois par jour
Avant les Skills, mon workflow Claude Code ressemblait à ça. Nouvelle conversation. Coller le system prompt. Expliquer le contexte projet. Répéter les conventions de code. Re-préciser que je veux du TypeScript strict, pas du JavaScript déguisé. Attendre que Claude comprenne enfin que "refacto" ne veut pas dire "réécrire tout le fichier".
Le system prompt aide, mais il faut le recharger à chaque session. Les MCP (Model Context Protocol) permettent de connecter des outils externes, ce qui est puissant pour lire une base de données ou appeler une API. Mais MCP ne règle pas le problème du briefing récurrent. C'est fait pour les données, pas pour les instructions.
Les Skills, eux, sont exactement ça : des instructions packagées et réutilisables. Tu les crées une fois. Claude les charge automatiquement dès que tu lances une conversation dans le contexte où ils sont actifs. Pas besoin de re-briefer.
Claude Skills : un system prompt qui survit entre les conversations
Un Skill, c'est un fichier markdown avec un frontmatter YAML. Le frontmatter définit le nom, la description, quand l'activer. Le corps markdown contient les instructions. Claude lit le Skill au démarrage de la conversation et l'applique.
Exemple basique que j'utilise pour capsül (projet de gestion de capsules éditoriales) :
---
name: capsul-conventions
description: Code conventions pour le projet capsül
trigger: always
---
# Conventions capsül
- TypeScript strict. Pas de `any`.
- Composants React Server Components par défaut.
- Prisma pour la DB. Pas de raw SQL sauf cas critique.
- Pas de refacto non demandée. Si je dis "ajoute X", tu ajoutes X.
Rien de révolutionnaire. Mais ça marche. Claude l'applique. Je ne répète plus 10 fois "strict TypeScript" par jour.
Le gain réel, c'est la persistance. Un system prompt, tu le perds dès que tu fermes l'onglet ou que tu dépasses la limite de tokens. Un Skill, il est toujours là. Toutes les conversations dans le projet capsül héritent automatiquement de ces règles.
Ce qui change vraiment : la composition
Les Skills peuvent se combiner. J'en ai un pour les conventions de code. Un autre pour le workflow blog. Un troisième pour les tests (TDD strict, pas de tests vides). Claude charge les 3 en parallèle si je lance une conversation dans le contexte approprié.
La composition, c'est ce qui manquait aux system prompts. Avec un system prompt, tu mets tout dans un seul bloc. Ou tu as plusieurs prompts et tu dois choisir lequel coller. Avec les Skills, tu découpes par responsabilité. Chaque Skill fait une chose. Claude les merge.
Mon Skill write-like-human-fr fait 400 lignes. Il contient toutes les règles pour générer des articles de blog qui ne sonnent pas IA : lexique banni, anti-tells, structures narratives, checklist SEO et GEO. Je l'ai écrit une fois. Maintenant, dès que je demande à Claude de rédiger un article pour lalucide.com, il applique ces règles sans que je les répète.
Avant, je devais coller un prompt de 200 lignes à chaque fois. Ou bien je faisais un compromis : des instructions light, et Claude produisait du contenu moyen avec des "Plongeons dans..." et des em-dash partout. Avec le Skill, c'est systématique. Toutes les rédactions respectent la checklist.
Les Skills vs MCP : deux outils, deux jobs
MCP, c'est pour connecter Claude à des données externes. Lire un repo Git, interroger une base Postgres, appeler une API Stripe. C'est de l'intégration système.
Les Skills, c'est pour briefer Claude sur comment travailler. Conventions, ton, structure, workflow. C'est de la configuration comportementale.
Les deux sont complémentaires. Mon setup actuel sur QuantAnalyst (plateforme d'analyse quant) combine les deux. J'ai un MCP qui lit les schemas Prisma et les fichiers de migration. J'ai un Skill qui dit à Claude comment écrire les queries (pas de N+1, toujours include les relations nécessaires, utiliser les transactions pour les updates multi-tables).
Le MCP donne les données. Le Skill donne les règles. Claude fait le boulot.
Ce qui frustre : les limites actuelles
Les Skills sont encore jeunes. Plusieurs trucs manquent ou agacent.
Pas de versioning visible. Si tu modifies un Skill, Claude applique la nouvelle version immédiatement, mais tu n'as aucun historique. Git règle ça côté fichier, mais Claude ne te dit pas quelle version du Skill il a chargée. Quand un comportement change et que tu ne sais pas pourquoi, tu dois diff manuellement.
Pas de conditions complexes. Le trigger d'un Skill peut être always, on_request, ou basé sur des patterns simples. Tu ne peux pas dire "active ce Skill uniquement dans les fichiers .tsx du dossier app/". C'est tout ou rien par projet.
Pas de composition explicite. Claude merge les Skills, mais tu ne contrôles pas l'ordre ni les priorités. Si deux Skills donnent des instructions contradictoires, Claude fait... quelque chose. Ce n'est pas documenté. J'ai eu des cas où un Skill général était écrasé par un Skill spécifique, et d'autres cas où l'inverse se produisait. Pas de règle claire.
Debugging opaque. Claude ne te dit pas quels Skills il a chargés. Tu dois deviner. Il y a un indicateur visuel dans l'UI Claude Code, mais pas de log détaillé. Quand Claude ignore une instruction d'un Skill, tu ne sais pas si c'est parce que le Skill n'est pas chargé, ou parce que Claude a décidé de l'ignorer, ou parce qu'un autre Skill le contredit.
Retour terrain : ce que j'ai appris en 2 mois
Quelques patterns qui marchent après 60 jours d'utilisation quotidienne.
Un Skill = une responsabilité. Pas de Skills fourre-tout. J'ai un Skill conventions code, un Skill workflow Git, un Skill rédaction blog, un Skill tests. Chacun fait une chose. Si je dois modifier le workflow Git, je ne touche pas aux conventions code.
Être explicite sur ce qui est interdit. Les instructions positives ("fais X") marchent moins bien que les interdictions ("ne fais jamais Y"). Mon Skill write-like-human-fr contient une liste de 40+ mots et expressions bannies. Claude les respecte. Quand je disais juste "écris comme un humain", il mettait des "Plongeons" partout.
Inclure des exemples. Les Skills avec exemples concrets marchent mieux que les Skills théoriques. Dans mon Skill Prisma, j'ai mis 3 exemples de queries bien écrites et 3 contre-exemples. Claude s'aligne sur les exemples.
Tester les Skills isolément. Quand je crée un nouveau Skill, je le teste seul avant de l'activer avec les autres. Sinon, je ne sais pas si un problème vient du nouveau Skill ou d'une interaction avec un existant.
Documenter les décisions. Chaque Skill a une section "Pourquoi ces règles" en commentaire. Quand je reviens dessus 3 semaines plus tard, je comprends pourquoi j'ai interdit les em-dash ou forcé le lead-with-answer dans chaque section H2.
Les Skills ne sont pas des agents
Clarification importante : un Skill ne rend pas Claude "agent". Un agent IA, c'est un système qui planifie, exécute des actions multi-étapes, et boucle sur des feedbacks. Les Skills, c'est juste un moyen de configurer le comportement de Claude dans une conversation.
Claude avec un Skill reste Claude. Tu lui parles. Il répond. Il peut appeler des outils via MCP. Mais il ne va pas décider tout seul de lancer un pipeline CI, merger une PR, et déployer en prod. Ce n'est pas le job d'un Skill.
Les agents IA, c'est un autre sujet. Et d'après SWE-bench Verified, les agents autonomes ont encore un taux d'échec de 70% sur les tâches multi-étapes en mai 2026. Un agent qui marche 30% du temps, c'est un agent qu'un humain doit superviser 100% du temps.
Les Skills sont plus modestes. Ils configurent Claude pour qu'il fasse mieux ce qu'il fait déjà : répondre à tes demandes dans une conversation.
Ce que ça change concrètement pour un dev solo
Trois gains tangibles après 2 mois.
Moins de répétition. Je ne re-briefle plus Claude 10 fois par jour. Les conventions sont dans les Skills. Claude les applique. Je passe plus de temps à coder, moins à expliquer.
Qualité constante. Avant, la qualité des réponses de Claude variait. Parfois il suivait mes conventions. Parfois il improvisait. Avec les Skills, c'est constant. Toutes les conversations dans un projet respectent les mêmes règles.
Workflow partageable. Si je bosse avec quelqu'un d'autre sur capsül (ce qui n'arrive pas souvent, mais bon), je lui file mes Skills. Il a le même Claude que moi. Pas besoin d'un document "comment utiliser Claude sur ce projet". Le Skill est le document.
Le troisième point est sous-estimé. Les Skills sont versionables dans Git. Tu peux les partager, les forker, les améliorer en équipe. C'est du code. Pas du prompt copié-collé dans un Notion perdu.
Faut-il créer ses propres Skills en 2026 ?
Oui si tu utilises Claude quotidiennement sur les mêmes types de tâches. Non si tu fais des one-shots différents chaque jour.
Les Skills ont un coût de setup. Écrire un Skill de 400 lignes comme write-like-human-fr, ça m'a pris 6 heures. Mais ce Skill m'a fait gagner 30 minutes sur chaque article de blog depuis. J'ai écrit 15 articles avec. Rentabilisé.
Si tu utilises Claude pour des tâches répétitives (rédaction, code avec conventions strictes, analyse de données structurées), crée un Skill. Si tu l'utilises pour des questions ponctuelles variées, un system prompt suffit.
Un Skill, c'est un investissement. Comme écrire une lib. Tu ne le fais que si tu vas l'utiliser assez pour amortir.
Questions fréquentes
Les Claude Skills sont-ils réservés aux abonnés payants ?
Oui. Les Skills nécessitent un abonnement Claude Pro ou Anthropic Max. Ils ne sont pas disponibles sur le plan gratuit en mai 2026.
Peut-on partager un Skill publiquement ?
Techniquement oui, c'est un fichier markdown. Mais Anthropic n'a pas encore lancé de marketplace Skills. Tu peux mettre le fichier sur GitHub ou le partager directement. L'utilisateur devra l'importer manuellement dans son environnement Claude.
Les Skills fonctionnent-ils avec l'API Claude ?
Non. Les Skills sont une feature de l'interface Claude Code et Claude Web uniquement. Si tu utilises l'API Anthropic directement, tu dois passer tes instructions via system prompts classiques.
Quelle est la limite de taille d'un Skill ?
Anthropic ne documente pas de limite stricte. Mon plus gros Skill fait 400 lignes (environ 3000 tokens). Il passe sans problème. Au-delà de 500 lignes, je découperais probablement en plusieurs Skills.
Les Skills peuvent-ils appeler des outils externes ?
Non. Un Skill ne peut pas déclencher d'actions. Il configure le comportement de Claude. Pour appeler des outils externes (APIs, bases de données), utilise MCP. Les Skills et MCP se complètent.