Créer des Claude Skills : Guide Complet (2026)

1. Que sont les Claude Skills ? (Et en quoi diffèrent-elles des prompts)

Avant de vous lancer dans quoi que ce soit, il vaut mieux bien comprendre ce qu'est une Skill d'un point de vue technique, en quoi elle diffère d'un prompt, et où elle se situe dans l'écosystème Anthropic Claude au sens large. Cette section pose les bases conceptuelles sur lesquelles repose tout le reste.

Définir les Claude Skills

Une Claude Skill est une unité d'instruction autonome, nommée, versionnée, que Claude peut invoquer à la demande. Concrètement, c'est un dossier. Dans sa forme la plus simple, une skill est un répertoire contenant un fichier SKILL.md, et ce fichier doit commencer par un en-tête YAML (frontmatter) comportant certaines métadonnées obligatoires : le nom et la description.

Ce dossier, c'est tout. Il n'y a pas de modèle séparé, pas de binaire propriétaire, pas de module payant en plus. Les Skills ne sont ni des modèles, ni des plugins au sens WordPress du terme, ni des extensions payantes. Ce sont des instructions markdown open-source accompagnées de fichiers de support. C'est important de bien l'intégrer dès le départ, car ça change complètement la façon d'aborder le travail. Vous ne programmez pas un système. Vous rédigez une documentation tellement claire et tellement bien cadrée que Claude peut la suivre parfaitement, à chaque fois.

Les Skills apparaissent principalement à deux endroits. Dans l'API Claude, vous pouvez utiliser les skills préconçues par Anthropic, et aussi importer vos propres skills personnalisées via l'API Claude, leur création est simple, il suffit d'un dossier avec un fichier SKILL.md contenant l'en-tête YAML et les instructions. Dans Claude Code, elles résident dans un répertoire de votre projet ou plugin. Vous créez un répertoire skills à la racine de votre plugin ou projet, puis vous y ajoutez des dossiers de skills contenant des fichiers SKILL.md, et Claude les détecte et les utilise automatiquement une fois le plugin installé.

Il existe aussi un registre public d'exemples. Anthropic maintient un dépôt ouvert de Skills qui montre l'étendue de ce qui est possible. Ce dépôt rassemble des compétences illustrant ce que le système de skills de Claude permet de faire, des applications créatives (art, musique, design) aux tâches techniques (tests d'applications web, génération de serveurs MCP) jusqu'aux workflows d'entreprise. C'est une référence précieuse quand vous commencez à créer les vôtres.

Le meilleur modèle mental : si les prompts sont des post-it qu'on griffonne puis qu'on jette, les Skills sont des procédures documentées, des SOP (Standard Operating Procedures). Un post-it rappelle quelque chose à une personne, une fois. Une SOP standardise la façon dont tout le monde effectue une tâche, durablement, avec un propriétaire clair et un numéro de version.

Quelques termes à bien avoir en tête dès maintenant, car ils reviennent tout au long de ce guide :

• SKILL.md : le fichier obligatoire au cœur de chaque Skill. Notez que le nom de fichier est en majuscules dans l'implémentation d'Anthropic, même si on parle souvent du « fichier skill.md » de façon générique.
• Frontmatter : le bloc YAML en haut du fichier qui contient les métadonnées comme name et description.
• Corps de la Skill : les instructions en Markdown situées sous le frontmatter.
• Créateur de Skill : le processus de création, qu'il s'agisse d'un template, de l'API ou d'un répertoire dans Claude Code.
• Invocation : le moment où Claude juge qu'une Skill est pertinente et la charge.
• Portée de la Skill : le caractère plus ou moins précis de l'objectif de la Skill.

Vous faites tourner Claude sur plusieurs repos toute la semaine pour tester votre bibliothèque de Skills ? C'est souvent un forfait Max 20x à 200$/mois, facturé en USD. Avec Bleap, vous payez au vrai taux de change, 0% de frais FX, et vous touchez 20% de cashback fixe sur vos renouvellements Claude, ChatGPT et Gemini, sans abonnement carte requis. Découvrir la carte Bleap →

Prompts Claude vs Skills : les différences essentielles

On demande souvent pourquoi ne pas simplement continuer à utiliser un bon prompt. Parfois, c'est effectivement la bonne solution. Mais dès qu'une tâche se répète, est partagée, ou devient critique pour l'activité, une Skill l'emporte sur pratiquement tous les plans. Voici le détail.

Persistance. Un prompt n'existe que le temps du tour de conversation où il est collé. Une fois la session terminée, il disparaît. Une Skill, elle, persiste d'une session à l'autre et d'un utilisateur à l'autre. Elle est stockée, indexée, et disponible dès qu'elle devient pertinente.

Découvrabilité. C'est le point le plus subtil. Claude ne peut pas voir un prompt tant que quelqu'un ne l'a pas injecté. Une Skill, à l'inverse, se signale d'elle-même. Au démarrage, l'agent précharge le nom et la description de chaque skill installée dans son system prompt, ce qui donne à Claude juste assez d'informations pour savoir quand utiliser telle ou telle skill, sans avoir à tout charger dans son contexte. Claude décide activement du moment où il va faire appel à une Skill. Il ne peut jamais décider de faire appel à un prompt qu'il n'a jamais vu.

Réutilisabilité. Une Skill peut être appelée par n'importe quel utilisateur autorisé ou sous-agent, sans que personne n'ait besoin de copier-coller du texte. Un prompt, lui, doit être partagé et repartagé manuellement, et il se dénature un peu plus à chaque fois.

Gestion des versions. Les Skills peuvent être itérées et suivies dans le temps. Les prompts bruts qui traînent dans les messages des utilisateurs ne peuvent pas être versionnés de manière cohérente.

Intégration d'outils. Les Skills peuvent embarquer des scripts et de la documentation de référence, et décrire précisément comment et quand les utiliser. Les prompts ne peuvent pas porter nativement ce genre de structure.

Composabilité. Les Skills peuvent faire référence à d'autres ressources et être connectées à des sous-agents pour du travail délégué. Les prompts, eux, ne sont que des blocs de texte monolithiques.

Voici une comparaison détaillée sur huit dimensions :

Quand utiliser un prompt plutôt que de créer une Skill. Le principe de décision est simple. Utilisez un prompt pour les demandes ponctuelles, exploratoires ou très liées à un contexte précis. Créez une Skill dès qu'une tâche revient régulièrement, doit produire un résultat cohérent, sera utilisée par plusieurs personnes, ou encode un savoir qu'il faudrait sinon réexpliquer à chaque session. Si vous vous surprenez à coller deux fois les mêmes instructions, c'est le signal qu'il vous faut.

La place des Skills dans l'écosystème Claude d'Anthropic

Les Skills n'existent pas en vase clos. Comprendre leur articulation avec le reste de l'écosystème Claude vous évite de créer une Skill pour quelque chose qu'un autre mécanisme gère déjà mieux.

Skills vs Projects. Dans Claude.ai, les Projects regroupent des conversations et des fichiers autour d'un objectif commun. Les Skills viennent enrichir les Projects en ajoutant des connaissances procédurales réutilisables, mais ce n'est pas la même chose. Un Project, c'est un espace de travail. Une Skill, c'est une capacité que vous pouvez invoquer dans cet espace de travail ou ailleurs.

Skills vs MCP. Cette distinction est importante. Le Model Context Protocol constitue la couche de connectivité, c'est-à-dire la manière dont Claude accède à des outils externes, des sources de données et des services. Les Skills, elles, forment la couche d'instructions, qui indique à Claude comment et quand agir. On combine souvent les deux : MCP connecte Claude à votre base de données, et une Skill lui indique la procédure exacte pour interroger et formater ces données. L'une des Skills d'exemple fournies par Anthropic porte même sur la génération de serveurs MCP, ce qui montre à quel point les deux concepts s'imbriquent étroitement.

Skills vs subagents. Les Skills peuvent être intégrées à des subagents personnalisés, de sorte qu'un agent spécialisé traite une tâche déléguée de façon isolée. Vous pouvez partager vos skills avec votre équipe en les archivant dans un dépôt, les diffuser via des plugins, les déployer à l'échelle de toute l'organisation, et les connecter à des subagents personnalisés pour déléguer des tâches expertes de manière isolée. La Skill apporte l'expertise ; le subagent fournit le contexte d'exécution isolé.

Skills vs l'API. Les Skills ne sont pas cantonnées à l'interface de chat. Elles sont accessibles par programmation, ce qui les rend exploitables pour l'automatisation en production, les pipelines CI, et les fonctionnalités produit embarquées.

Skills vs la hiérarchie de contexte. Quand Claude formule une réponse, il prend en compte le system prompt, le contenu des Skills chargées, les messages de l'utilisateur, ainsi que les résultats d'outils éventuels. Les Skills se situent au-dessus du message individuel, mais en dessous des garde-fous fixes du niveau système. Comprendre cette hiérarchie vous aide à rédiger des Skills qui orientent le comportement de Claude sans aller à l'encontre de ses réglages par défaut.

Pourquoi les Claude Skills changent la donne pour l'automatisation IA

La valeur stratégique des Skills s'accumule avec le temps. Voici d'où vient réellement ce levier.

Éliminer la dérive des prompts. Quand une équipe s'appuie sur un Skill partagé, tout le monde utilise les mêmes instructions faisant autorité. Fini le "tu utilises quelle version du prompt ?". Le Skill devient la référence unique.

Élargir l'accès. Un Skill bien conçu permet à des collaborateurs non techniques de profiter d'une automatisation sophistiquée. Ils n'ont pas besoin de savoir écrire un system prompt de 400 mots. Ils décrivent simplement ce qu'ils veulent, et Claude va chercher le bon Skill.

Réduire le gaspillage de la fenêtre de contexte. C'est là que réside le génie technique de cette conception. Les Skills utilisent un système de chargement à trois niveaux pour gérer le contexte efficacement, et cette divulgation progressive permet d'installer de nombreux skills différents pour réaliser des tâches complexes sans surcharger la fenêtre de contexte. Les instructions statiques restent en dehors de la conversation jusqu'au moment où elles sont réellement nécessaires.

L'effet de bibliothèque cumulatif. Chaque Skill que vous créez rend le suivant plus précieux, car les Skills peuvent référencer des ressources partagées et se combiner en workflows. Une équipe disposant de 40 Skills bien délimités a un profil de capacités réellement différent d'une équipe qui se contente de copier-coller des prompts. Une équipe utilisant des dizaines de Skills a rapporté que le coût total en tokens tourne autour de 1 500 tokens pour l'ensemble des 40 skills, seul celui pertinent se déployant réellement au moment voulu.

Cas d'usage concrets. Ce schéma se retrouve partout : automatisation de la revue de code, playbooks de support client, normalisation des données, contrôle qualité des contenus, génération de documents conformes à la charte de marque, ou encore synthèse de recherches. La force des skills réside dans leur capacité à encoder le savoir-faire de l'entreprise, à standardiser les résultats et à gérer des workflows complexes en plusieurs étapes qui, autrement, nécessiteraient des explications répétées ou l'investissement dans la création d'un agent sur mesure.

La thèse sur la productivité est simple. Chaque minute qu'un travailleur du savoir passe à réexpliquer le même contexte à une IA, c'est du temps perdu, et ce temps perdu se multiplie mal à l'échelle d'une équipe. Des workflows structurés et réutilisables suppriment ce gaspillage. Les économies exactes dépendent de vos propres workflows, donc mieux vaut rester prudent face aux chiffres précis qu'on peut croiser en ligne, mais la tendance générale est claire : moins de répétition, plus de cohérence, plus de levier.

2. Comment fonctionnent les Claude Skills : architecture, cycle de vie du contenu et types de Skills

Maintenant que vous savez ce que sont les Skills et pourquoi elles comptent, place au capot. Comprendre l'architecture et le cycle de vie, c'est ce qui distingue les personnes qui écrivent des Skills qui se déclenchent de façon fiable de celles dont les Skills restent inutilisées parce que Claude ne réalise jamais qu'elles sont pertinentes.

L'architecture des Claude Skills en un coup d'œil

Globalement, le flux fonctionne ainsi : un utilisateur ou un agent fait une requête, Claude vérifie les métadonnées de chaque Skill installée, décide si l'une d'elles est pertinente, charge le contenu complet de cette Skill dans son contexte si c'est le cas, puis génère une réponse enrichie par ce contenu. On peut résumer ça par : Utilisateur ou Agent → analyse des métadonnées de la Skill → décision de pertinence → chargement du contenu → réponse enrichie.

Chaque Skill comporte trois couches conceptuelles :

• Définition. Ce qu'est la Skill : son nom, sa description, sa version et ses métadonnées. C'est ce que Claude voit en permanence.
• Contenu. Ce que la Skill apporte au contexte : les instructions complètes, des exemples, et toutes les ressources référencées. Ce contenu ne se charge que lorsque c'est nécessaire.
• Exécution. La façon dont Claude utilise concrètement le contenu chargé pour accomplir la tâche, y compris les scripts ou outils vers lesquels la Skill pointe.

Où sont stockées les Skills ? Cela dépend de votre configuration. Dans Claude Code, elles vivent dans un répertoire skills/ au sein de votre projet ou plugin. Via l'API, elles sont téléversées vers un espace de stockage géré par Anthropic. Les équipes conservent généralement les versions de référence dans leur propre dépôt Git et les distribuent depuis là.

Comment Claude « sait-il » qu'une Skill existe ? Grâce à la couche de métadonnées toujours chargée. Le frontmatter YAML est systématiquement chargé dans le prompt système de Claude, pour un coût d'environ 100 tokens par skill, quel que soit le nombre de skills installées. Cette couche de métadonnées donne à Claude juste assez d'informations pour décider si la skill est pertinente pour la tâche en cours, sans avoir à charger tout son contenu. Ce coût de 100 tokens, c'est en quelque sorte le prix d'entrée pour qu'une Skill soit détectable, et c'est ce qui permet au système de tenir la charge avec des dizaines de Skills.

Enfin, il existe deux façons de déclencher une Skill. L'invocation implicite, c'est quand Claude décide lui-même qu'une Skill est pertinente en se basant sur la description et la demande de l'utilisateur. L'invocation explicite, c'est quand un utilisateur ou un agent nomme directement la Skill. Les deux sont valables : c'est à vous de trouver le bon équilibre entre les deux au moment où vous rédigez la description.

Le cycle de vie du contenu d'une Skill

Une Skill traverse un cycle de vie assez prévisible, de l'idée jusqu'à la production et au-delà. Comprendre chaque étape, et ses pièges potentiels, vous fera gagner des heures de débogage.

Étape 1, la rédaction. Vous écrivez le SKILL.md et les éventuels fichiers annexes. C'est là que se joue l'essentiel de la qualité. Piège à éviter : commencer à écrire avant d'avoir clairement défini le problème. Avant de rédiger quoi que ce soit, clarifiez le problème que votre skill est censée résoudre, car les skills les plus solides répondent à des besoins concrets avec des résultats mesurables.

Étape 2, la publication. Vous validez la Skill là où Claude ira la lire : un répertoire, l'API, ou un pipeline CI/CD. Piège à éviter : publier au mauvais endroit ou oublier d'installer le plugin, ce qui fait que Claude ne la découvrira jamais.

Étape 3, l'indexation. Claude charge les métadonnées de la Skill dans le prompt système au démarrage. Piège à éviter : s'attendre à ce qu'une Skill fraîchement ajoutée soit disponible en cours de session, sans redémarrage ni rechargement.

Étape 4, Invocation. Claude confronte une requête à la description du Skill et décide de l'utiliser. Piège : une description trop restrictive, et Claude ne déclenche jamais le Skill.

Étape 5, Injection. Le corps complet du SKILL.md se charge dans le contexte. Le corps du fichier constitue le second niveau de détail, et si Claude juge le skill pertinent pour la tâche en cours, il le charge en lisant l'intégralité du SKILL.md. Piège : un corps trop volumineux qui bouffe le contexte et noie les instructions importantes.

Étape 6, Exécution. Claude traite le contexte enrichi et produit sa réponse, en exécutant les scripts éventuellement pointés par le Skill. Piège : des instructions qui entrent en conflit avec les comportements par défaut de Claude, ce qui donne des résultats incohérents.

Étape 7, Itération. Vous versionnez, modifiez et republiez. Piège : modifier un Skill sans incrémenter la version, si bien que personne ne sait quel comportement il va obtenir.

Le réflexe le plus utile ici, c'est de tester séparément le déclenchement et l'exécution. Testez-les indépendamment : si les skills ne s'activent pas, élargissez votre description et ajoutez des cas d'usage ; si les résultats sont incohérents, précisez davantage les instructions et ajoutez des étapes de validation. Ce sont deux problèmes différents avec deux solutions différentes, et les traiter comme un seul problème, c'est justement ce qui fait tourner en rond.

Les différents types de contenu de Skill

Tous les Skills ne remplissent pas la même fonction. Identifier le type que vous construisez détermine la structure de votre SKILL.md.

Les Skills purement instructifs fournissent un ensemble de règles comportementales ou une procédure étape par étape. La checklist de revue de code en est l'exemple classique : pas de données externes, pas d'outils, juste un processus fiable que Claude suit à chaque fois.

Les Skills d'enrichissement de contexte injectent des connaissances métier, des données de référence ou de la terminologie. Imaginez une Skill qui embarque le glossaire de votre entreprise, votre taxonomie produit ou votre ton de marque, pour que Claude parle le bon langage sans que vous ayez à tout réexpliquer.

Les Skills d'activation d'outils décrivent comment et quand utiliser certains outils ou scripts. Elles s'associent souvent aux connexions MCP et orientent Claude vers des scripts exécutables dans le répertoire scripts/.

Les Skills de modèles (templates) fournissent des formats de sortie structurés : un schéma JSON, un modèle de rapport, une ébauche de code. Ce qui compte ici, c'est la cohérence de la forme, pas seulement du contenu.

Les Skills hybrides combinent plusieurs des types précédents en une seule unité. Les Skills d'édition de documents d'Anthropic en sont une bonne illustration. L'une des skills qui alimentent les capacités d'édition de documents de Claude répond au fait que Claude sait déjà beaucoup de choses sur la compréhension des PDF, mais reste limité dans sa capacité à les manipuler directement, comme remplir un formulaire par exemple. Cette Skill PDF donne à Claude ces nouvelles capacités. Elle mêle donc instructions, outils et modèles à la fois.

Choisir le bon type. Demandez-vous ce dont la tâche a réellement besoin. Un simple changement de comportement ? Instructions uniquement. Des connaissances manquantes ? Enrichissement de contexte. Besoin d'agir sur un élément externe ? Activation d'outils. Besoin d'un format de sortie précis ? Modèle. Plusieurs besoins à la fois ? Hybride, mais en restant aussi ciblé que possible.

Comment le type influence la structure. Les Skills à instructions uniquement et les Skills de modèles sont généralement courtes et peuvent tenir entièrement dans le corps du SKILL.md. Les Skills d'enrichissement de contexte et les Skills hybrides nécessitent souvent des fichiers complémentaires, ce pour quoi le système de divulgation progressive a justement été conçu. En règle générale, gardez le corps du SKILL.md centré sur l'essentiel et sous les 500 lignes ; si vous approchez cette limite, répartissez le contenu dans des fichiers séparés.

Comment Claude décide d'invoquer une Skill

C'est le point sur lequel on se trompe le plus souvent, donc ça mérite qu'on s'y attarde. Le déclenchement d'une Skill repose principalement sur le champ description. Claude lit la description de chaque Skill installée et la compare sémantiquement à la demande en cours. Si la description est bien rédigée, la Skill se déclenche de façon fiable. Si elle est mal rédigée, même une Skill excellente reste inactive.

Il existe un comportement particulier dont il faut tenir compte. Claude a tendance à sous-déclencher les skills, à ne pas les utiliser alors qu'elles seraient utiles, et pour contrer cela, il faut rendre les descriptions un peu plus insistantes. Anthropic recommande elle-même de détailler précisément les situations qui doivent activer la Skill, y compris les cas implicites. Par exemple, plutôt qu'une simple phrase, on peut ajouter « veille à utiliser cette skill chaque fois que l'utilisateur mentionne des tableaux de bord, de la visualisation de données, des métriques internes, ou souhaite afficher un type quelconque de données d'entreprise, même s'il ne demande pas explicitement un tableau de bord ».

Le déclenchement explicite passe par une référence directe : un utilisateur ou un agent nomme la Skill, ou une commande slash la déclenche. C'est le chemin le plus fiable, mais il suppose que celui qui l'appelle sache que la Skill existe.

Phrases déclencheuses et exemples. Inclure des exemples de formulations et des cas d'usage dans votre description affine la correspondance sémantique. Ces exemples donnent à Claude des signaux concrets pour identifier quand la Skill est pertinente. Le conseil d'Anthropic quand une Skill ne se déclenche pas est sans détour : si les skills ne s'activent pas, élargissez votre description et ajoutez des cas d'usage.

Confiance et sur-déclenchement. Le problème inverse, c'est une description si large que la Skill se déclenche sur presque tout, en s'immisçant dans des conversations qui n'ont rien à voir. La solution, c'est de bien cadrer le périmètre. Une description bien ciblée, avec des conditions de déclenchement précises, s'active quand il le faut et reste silencieuse le reste du temps.

Plusieurs Skills et priorisation. Quand plusieurs Skills pourraient correspondre, Claude évalue la pertinence de chacune. Les conflits de priorité sont une vraie catégorie de dépannage, et une partie du travail de conception d'une bonne Skill consiste justement à éviter que deux Skills ne se marchent dessus avec des descriptions qui se chevauchent.

Contexte dynamique. Les variables d'exécution, les fichiers ouverts à ce moment-là, les outils connectés, la formulation de la demande, tout ça influence quelle Skill s'active. Une Skill qui fait référence à une base de données va s'activer plus facilement quand une connexion à une base de données est présente. C'est en concevant pour ce contexte dynamique qu'une Skill donne l'impression de "savoir" quand intervenir.

Créer et tester des Skills toute la journée, ça consomme vite votre forfait Claude. Claude Pro coûte 20$/mois et Max entre 100 et 200$/mois, facturés en dollars. Payez avec Bleap et profitez de 0% de frais de change plus 20% de cashback fixe sur Claude, ChatGPT et Gemini, sans abonnement carte. Obtenir la carte Bleap →

3. Créer votre première Skill Claude : un guide pas à pas

Assez de théorie, passons à la pratique. Nous allons construire une Skill fonctionnelle de bout en bout. On va prendre un exemple concret, une Skill de checklist de revue de code, et parcourir chaque étape, de la configuration jusqu'au premier déclenchement réussi.

Prérequis et configuration de l'environnement

Premièrement, vérifiez que vous avez bien accès à la fonctionnalité. La création de Skills est disponible via Claude Code, l'API Claude et Claude.ai, la gestion à l'échelle de l'organisation étant encore en cours de maturation. Selon les indications actuelles, sur Claude.ai les skills sont pour l'instant propres à chaque utilisateur, même si des fonctionnalités de gestion et de partage à l'échelle de l'organisation arrivent bientôt. En attendant, il est conseillé de créer un dépôt de documents partagé avec les spécifications des skills, histoire de préparer ces futures fonctionnalités tout en posant dès maintenant les bases d'une bonne gouvernance.

Pour un accès payant, les formules Claude concernées sont simples à comprendre. La tarification Claude en 2026 se décline en sept niveaux : Free (0 $), Pro (20 $/mois), Claude Max 5x (100 $/mois), Max 20x (200 $/mois), Team Standard (25 $/utilisateur/mois), Team Premium (125 $/utilisateur/mois), et Enterprise (sur devis). Si vous construisez des Skills dans le cadre d'un workflow d'équipe, les formules Team et Enterprise apportent les contrôles d'administration dont vous aurez besoin tôt ou tard. Si vous automatisez via l'API, la facturation se fait séparément, au token.

Connaissances requises. Honnêtement, pas grand-chose. Une base en Markdown et une idée claire de la tâche que vous voulez automatiser. C'est tout ce qu'il faut.

Outils recommandés. VS Code avec une extension de prévisualisation Markdown rend la rédaction du SKILL.md bien plus agréable. Git vous donne un suivi de versions dès le premier jour. Gardez aussi une conversation Claude dédiée uniquement aux tests, séparée de votre travail réel, pour que le contexte ne vienne pas polluer vos essais.

Dossier de développement local. Créez un dossier avant de publier quoi que ce soit, afin que vos Skills aient un espace propre et un historique de versions.

[CTA BANNER]

Trois façons de créer un Skill. Vous pouvez rédiger directement dans un dossier skills/ dans Claude Code, l'importer via l'API Claude, ou partir du modèle proposé par Anthropic. Vous pouvez créer des skills qui transforment Claude d'assistant généraliste en expert spécialisé, que ce soit avec le modèle "skill creator" ou manuellement. Pour se simplifier la vie, il est recommandé de construire son fichier SKILL.md à partir du modèle, puis de l'adapter ensuite.

Bien préparer son Skill avant d'écrire la moindre ligne

Résistez à l'envie d'ouvrir tout de suite votre éditeur. Les meilleurs Skills sont ceux qu'on planifie d'abord. Le guide d'Anthropic est clair sur ce point : identifiez deux ou trois cas d'usage concrets avant de toucher au moindre fichier, et demandez-vous quelles connaissances métier ou bonnes pratiques devraient être intégrées, celles que l'utilisateur devrait sinon réexpliquer à chaque session.

Répondez à ces cinq questions avant de vous lancer dans la rédaction :

1. Quelle tâche précise ce Skill doit-il permettre d'accomplir ? Dans notre exemple : "Analyser un diff de code par rapport à la checklist qualité de notre équipe et produire un rapport structuré des points relevés."
2. Comment Claude ou l'utilisateur saura-t-il quand l'invoquer ? Quand quelqu'un partage un diff, une pull request, ou demande une revue de code.
3. Quelles informations doivent être présentes dans le contexte pour que le Skill fonctionne ? Les critères de la checklist et le format de sortie attendu. Le code lui-même vient de l'utilisateur.
4. De quels outils le Skill a-t-il besoin, le cas échéant ? Pour une simple checklist, aucun. S'il devait exécuter des linters, il aurait besoin d'un accès à des scripts.
5. Qui doit y avoir accès ? Commencez en privé, puis élargissez à l'équipe une fois que le Skill a fait ses preuves.

Restez précis, évitez le trop large. Un Skill qui "aide sur le code" ne sert à rien : il se déclenche sur tout et n'apporte rien de concret. Un Skill qui "analyse les pull requests Python par rapport à la checklist de l'équipe et sort les remarques groupées par niveau de gravité" est précis, se déclenche au bon moment, et apporte une valeur cohérente à chaque fois. Mieux vaut viser trop étroit que trop large.

Rédigez d'abord la description, comme un cahier des charges. Traitez la description comme un document de spécification. Si vous n'arrivez pas à décrire en deux ou trois phrases exactement ce que fait la Skill et quand elle doit se déclencher, c'est que vous n'êtes pas encore prêt à écrire le corps.

Identifiez la version minimale viable de la Skill. Commencez par la plus petite version qui apporte de la valeur, publiez-la, puis itérez. Anthropic pose clairement l'objectif : à la fin, vous serez capable de créer une skill fonctionnelle en une seule session, ce que le guide officiel promet à quiconque suit correctement la structure.

Étape 1 : Créer le répertoire de votre Skill

Créez un dossier pour la Skill. La structure recommandée :

code-review-checklist/
├── SKILL.md ← obligatoire
├── references/ ← connaissances complémentaires (optionnel)
├── scripts/ ← scripts exécutables (optionnel)
└── assets/ ← fichiers statiques (optionnel)

Cela reprend la convention utilisée par Anthropic elle-même. Dans le dossier de la skill se trouve un fichier SKILL.md (obligatoire), et éventuellement un répertoire scripts/ pour le code exécutable, un répertoire references/ pour la documentation que Claude charge selon les besoins, et un répertoire assets/ pour les modèles et fichiers annexes.

Conventions de nommage. Utilisez le kebab-case pour les noms de dossiers (code-review-checklist, et non CodeReviewChecklist). Préfixez par catégorie pour qu'une grosse bibliothèque reste facile à naviguer : qa-, dev-, ops-, content-. Notre exemple pourrait ainsi devenir dev-code-review-checklist.

Un répertoire par Skill. Garder chaque Skill autonome, ce n'est pas juste une question d'ordre. Cela signifie que vous pouvez versionner, partager et déplacer vos Skills indépendamment les unes des autres, ce qui devient extrêmement rentable dès que vous en avez des dizaines. Chaque skill est autonome dans son propre dossier, avec un fichier SKILL.md qui contient les instructions et les métadonnées utilisées par Claude.

Gestion des versions. Initialisez Git dans le dossier ou son parent, et utilisez des tags Git pour les versions de vos Skills. Quand vous faites passer un Skill de la version 1.2.0 à 1.3.0, taguez-le. Votre futur vous, en train de comprendre pourquoi le comportement a changé mardi dernier, vous remerciera.

Étape 2 : rédiger le fichier SKILL.md (version minimale viable)

Voici un fichier SKILL.md complet et fonctionnel pour notre Skill « Checklist de revue de code ». C'est le fichier entier, du frontmatter au corps du texte.

---
name: code-review-checklist
description: >
Reviews code diffs and pull requests against the team's quality
checklist and returns findings grouped by severity. Use this skill
whenever the user shares a diff, a pull request, a code snippet for
review, or asks for a code review, quality check, or PR feedback,
even if they do not explicitly say "checklist."
version: 1.0.0

# Code Review Checklist

You are performing a structured code review. Work through every
item in the checklist below against the code the user provides.

## Checklist

1. **Correctness**, Does the code do what it claims? Flag logic errors.
2. **Null and error handling**, Are edge cases and failures handled?
3. **Security**, Flag hardcoded secrets, unsafe input handling, or
injection risks.
4. **Tests**, Is there adequate test coverage for the change?
5. **Naming and style**, Do names follow our conventions
(kebab-case files, camelCase variables)?
6. **Readability**, Could a new teammate understand this in 60 seconds?

## Output format

Group findings under three headings: **Blocking**, **Should fix**, and
**Nice to have**. For each finding, cite the relevant line or function
and give a one-line, actionable recommendation. End with a one-sentence
overall verdict.

## Guidelines

- If the code is clean, say so plainly. Do not invent issues.
- Be specific. "Improve error handling" is useless;
"wrap the file read in a try/except" is useful.
- Do not rewrite the whole file unless asked. Point to the fix.

Cette structure suit de près le modèle d'Anthropic. Le modèle public montre le même squelette : un nom et une description claire de ce que fait la skill et quand l'utiliser, une section avec les instructions que Claude va suivre quand la skill est active, une section Exemples, et une section Guidelines.

Voyons ce qui compte vraiment ici :

• La description fait tout le travail. Remarquez qu'elle est volontairement « insistante », qu'elle liste précisément les situations censées la déclencher, et qu'elle couvre explicitement le cas où l'utilisateur n'emploie pas le mot « checklist ». Ça permet d'éviter le sous-déclenchement.
• Le corps est une procédure claire, pas une simple suggestion vague. Les éléments de la checklist sont concrets et chacun est actionnable.
• Le format de sortie est fixe. C'est ce qui transforme « un peu de feedback » en un rapport cohérent et comparable, à chaque fois.
• Les consignes ferment les portes dérobées, en disant à Claude de ne pas inventer de problèmes et de ne pas réécrire à outrance.

Les erreurs classiques d'un premier jet. Des descriptions trop laconiques. Des instructions qui entrent en conflit avec les comportements par défaut de Claude (par exemple, lui demander d'être concis puis lui réclamer des explications détaillées). Des corps de texte qui gonflent au-delà du raisonnable. Et des formats de sortie laissés implicites, ce qui donne des résultats incohérents.

Le test de la lecture à voix haute. Lisez votre SKILL.md à voix haute. Si une phrase vous paraît alambiquée ou ambiguë, elle perturbera Claude aussi. Une écriture claire n'est pas un luxe ici, c'est tout le travail d'ingénierie.

Étape 3 : Publier la Skill

La façon de publier dépend de votre environnement.

Dans Claude Code, déposez le dossier dans le répertoire skills/ de votre projet, et Claude s'en charge automatiquement. Vous créez un répertoire skills à la racine de votre plugin ou de votre projet, vous y ajoutez des dossiers de skills contenant des fichiers SKILL.md, et Claude les découvre et les utilise automatiquement une fois le plugin installé.

Via l'API, téléversez le dossier de la Skill à l'aide de la Skills API. La documentation d'Anthropic propose justement un Skills API Quickstart pour ça.

Dans Claude.ai, ajoutez la Skill via l'interface Skills de votre espace de travail, collez ou importez le SKILL.md, puis définissez le niveau d'accès initial. N'oubliez pas que, pour l'instant, les Skills dans Claude.ai sont limitées à l'utilisateur individuel, un partage plus large étant prévu sur la feuille de route.

Définir le niveau d'accès. Commencez en privé. Vérifiez que la Skill fonctionne de manière isolée avant de l'exposer à une équipe ou à un espace de travail. Il est bien plus simple d'élargir l'accès par la suite que de revenir en arrière sur une Skill défaillante dont une dizaine de personnes dépendent déjà.

Après la publication, il y a une brève étape d'indexation pendant laquelle les métadonnées se chargent dans le system prompt. Dans une session en cours, il se peut que vous deviez recharger ou repartir sur une nouvelle conversation pour qu'une Skill récemment ajoutée devienne disponible.

Étape 4 : effectuez votre premier test d'invocation

Ouvrez une nouvelle conversation. C'est important. Une conversation existante conserve un contexte qui peut masquer le fait que votre Skill s'est réellement déclenchée ou que Claude répond simplement en fonction des messages précédents.

Testez d'abord l'invocation implicite. Collez un diff de code et dites simplement : « Peux-tu relire ça ? » Ne mentionnez pas la Skill par son nom. Si votre description est bien rédigée, Claude devrait faire appel à la Skill automatiquement et renvoyer une réponse dans le format que vous avez défini.

Testez ensuite l'invocation explicite. Référencez directement la Skill et vérifiez qu'elle se déclenche sur demande.

Interprétez la réponse. Le signe le plus clair que la Skill s'est bien chargée, c'est que la réponse correspond exactement au format que vous avez défini : les observations regroupées sous Bloquant, À corriger et Bonus, avec un verdict en une phrase. Si vous obtenez à la place un retour générique sous forme de texte libre, c'est que la Skill ne s'est probablement pas déclenchée.

Cinq indices qui montrent que votre Skill fonctionne :

1. La réponse suit précisément le format que vous avez spécifié.
2. Claude applique les points précis de votre checklist, et pas seulement des bonnes pratiques génériques.
3. Elle respecte vos consignes (elle n'invente pas de problèmes sur du code propre).
4. Elle se déclenche sur des demandes naturelles, sans que vous ayez besoin de la nommer.
5. Le comportement reste cohérent d'un test à l'autre, avec des entrées différentes.

Si le déclenchement n'est pas fiable, rappelez-vous la règle de séparation des responsabilités : pour corriger le déclenchement, élargissez et affinez la description ; pour corriger la qualité de la réponse, ajoutez des précisions et des étapes de validation dans le corps du texte.

Les erreurs classiques de débutant (et comment les corriger)

Quelques erreurs reviennent dans la grande majorité des frustrations de départ.

Des instructions qui vont à l'encontre des comportements par défaut de Claude. Si votre Skill demande à Claude d'agir d'une façon qui contredit son comportement de base sans justification claire, vous obtenez des résultats incohérents. Solution : expliquez clairement pourquoi cet écart est nécessaire, et validez.

Des descriptions tellement larges que la Skill se déclenche sur tout. Une Skill qui s'active à chaque message est pire qu'inutile. Solution : réduisez le périmètre, ajoutez des conditions de déclenchement précises.

Un mauvais niveau d'accès avant le partage. Publier à l'échelle de toute l'équipe avant d'avoir testé, ou laisser une Skill défectueuse accessible à tous. Solution : commencez en privé, élargissez seulement après validation.

Des corps de texte surchargés. Un SKILL.md trop dense gaspille du contexte et noie les instructions essentielles. Solution : gardez le corps du texte sous les 500 lignes et renvoyez les détails complémentaires vers references/. Comme le veut la bonne pratique, limitez le corps du SKILL.md à l'essentiel et à moins de 500 lignes, et si vous approchez de cette limite, répartissez le contenu dans des fichiers séparés.

Ne pas tester les cas limites. Une Skill qui fonctionne dans les cas simples mais plante sur des entrées inhabituelles va vite entamer la confiance. Solution : constituez une vraie bibliothèque de cas de test. Créez une bibliothèque de cas de test couvrant l'usage courant, les cas limites et les demandes hors périmètre.

4. Structurer le fichier SKILL.md : métadonnées, frontmatter et corps du texte

Vous avez maintenant un Skill fonctionnel. Allons plus loin dans le détail du fichier lui-même, car c'est en maîtrisant la structure du SKILL.md que l'on passe de Skills qui marchent globalement à des Skills fiables à tous les coups, à grande échelle, au sein d'une équipe.

Comprendre le format du fichier SKILL.md

Pourquoi Markdown ? Parce que c'est lisible pour un humain, facile à comparer dans Git (diff-friendly), universellement supporté, et que ça oblige à être clair. Le Markdown, c'est aussi la façon dont Claude "pense" déjà le texte structuré : des instructions en Markdown, ce sont des instructions que Claude suit naturellement. Ce choix n'a rien d'anodin : les Skills sont pensés pour être écrits et relus par des humains autant qu'exécutés par Claude.

Une structure en deux parties. Chaque SKILL.md se compose d'un bloc de frontmatter YAML suivi d'un corps en Markdown. Un fichier SKILL.md doit obligatoirement commencer par un frontmatter YAML contenant un nom de fichier et une description, qui sont chargés dans le system prompt au démarrage. Le frontmatter, c'est la métadonnée ; le corps, ce sont les instructions.

Un traitement différent pour chaque partie. C'est là tout l'enjeu de l'architecture de divulgation progressive. Le frontmatter est toujours chargé. Le corps, lui, ne se charge que quand c'est pertinent. Le frontmatter YAML est systématiquement chargé dans le system prompt de Claude, pour un coût d'environ 100 tokens par skill, de quoi donner à Claude juste assez d'informations pour juger de la pertinence sans avoir à charger tout le contenu. Le corps du SKILL.md, lui, n'est chargé que lorsque Claude détermine que le skill est pertinent, et c'est là que se trouvent les instructions complètes, les workflows étape par étape, les exemples et les conseils de dépannage.

Les limites de taille de fichier. Il n'existe pas de règle universelle absolue, mais la recommandation pratique est de rester sous les 500 lignes. Au-delà, mieux vaut répartir le contenu dans des fichiers references/ que Claude charge à la demande. Anthropic a conçu un troisième niveau de divulgation exactement pour ce cas de figure : quand une Skill devient trop volumineuse pour tenir dans un seul SKILL.md, les fichiers annexes prennent le relais. À mesure que les skills gagnent en complexité, elles peuvent contenir trop de contexte pour tenir dans un seul SKILL.md.

Encodage et formatage. Utilisez l'encodage UTF-8 et des sauts de ligne standards. Gardez votre Markdown propre et bien structuré, car cette structure est elle-même un signal qui indique à Claude comment prioriser l'information.

Ce que contient le fichier vs ce que reçoit Claude. Ce n'est pas la même chose. Le fichier contient tout : le frontmatter, le corps du texte, et les pointeurs vers les ressources. Ce que Claude reçoit à un instant donné dépend du niveau de divulgation. Au démarrage, il ne reçoit que vos métadonnées d'environ 100 tokens. Lors de l'invocation, il reçoit le corps du texte. Il ne lit les fichiers référencés que si le corps du texte le lui indique. Concevoir sa Skill en gardant cette transformation à l'esprit, c'est toute la différence entre une Skill efficace et une Skill qui gaspille discrètement du contexte.

Le frontmatter YAML : tous les champs expliqués

Le frontmatter est petit mais déterminant. Deux champs sont obligatoires (name et description) ; les autres sont facultatifs mais précieux à grande échelle. Voici la référence complète.

name, l'identifiant canonique de la Skill. Utilisez le kebab-case, restez descriptif, et veillez à ce qu'il soit unique dans votre espace de travail pour qu'il n'y ait aucune ambiguïté sur la Skill concernée. code-review-checklist est un bon exemple ; helper ne l'est pas. Le nom est à la fois une étiquette lisible par un humain et, en cas d'invocation explicite, ce que les gens vont réellement utiliser pour l'appeler.

version, un versionnage sémantique au format MAJEUR.MINEUR.CORRECTIF. On incrémente le CORRECTIF pour les petits correctifs et clarifications, le MINEUR pour les nouvelles fonctionnalités qui restent rétrocompatibles, et le MAJEUR pour les changements qui modifient le comportement existant d'une façon qui pourrait surprendre les utilisateurs actuels. Le versionnage, c'est ce qui permet à une équipe de savoir exactement quel comportement elle obtient, et c'est la colonne vertébrale d'une itération sûre. Quand vous republiez, taguez la version dans Git pour que l'historique du fichier et le numéro de version restent synchronisés.

description, le champ le plus important, un point c'est tout. C'est lui qui pilote le routage d'invocation via la correspondance sémantique, et il est toujours chargé, donc il doit mériter ses ~100 tokens. Voici quelques principes qui fonctionnent en pratique :

• Visez environ 100 à 200 mots. Assez long pour être précis, assez court pour rester dans le budget toujours chargé.
• Écrivez pour la similarité sémantique, pas pour le bourrage de mots-clés. Décrivez les situations que le Skill gère, pas une liste de mots-clés.
• Soyez « insistant » pour éviter le sous-déclenchement. Listez explicitement les scénarios déclencheurs, y compris les implicites. Rappelez-vous l'exemple d'Anthropic : préciser qu'un Skill de tableau de bord doit se déclencher dès qu'un utilisateur mentionne la visualisation de données ou des métriques internes, même sans demande explicite de tableau de bord.
• Une description solide ressemblerait à : « Passe en revue les diffs de code et les pull requests selon la checklist qualité de l'équipe, et renvoie les résultats classés par gravité. À utiliser dès que l'utilisateur partage un diff, une PR ou un extrait de code à relire. » Une description faible ressemblerait à : « Aide avec le code. » La première déclenche correctement ; la seconde se déclenche sur tout ou rien.

author, l'attribution à une personne ou une équipe. C'est plus important qu'il n'y paraît. Cela établit une responsabilité claire (qui possède ce Skill, à qui s'adresser en cas de dysfonctionnement) et soutient la gouvernance à mesure que votre bibliothèque grandit.

tags, une stratégie de taxonomie pour faciliter la découverte dans les grandes bibliothèques. Catégories recommandées : domaine (security, data, content), fonction (review, generation, analysis), audience (engineering, support, marketing), et maturité (experimental, stable, deprecated). C'est un étiquetage cohérent qui permet de garder une bibliothèque de 40 Skills navigable au lieu de sombrer dans le chaos.

trigger_phrases, un tableau optionnel d'exemples d'énoncés censés déclencher la Skill. Ces exemples affinent le scoring d'invocation en donnant à Claude des points d'ancrage concrets. Le bon dosage se situe entre cinq et dix : assez pour couvrir les principales formulations, mais pas trop pour ne pas simplement reformuler la description. À noter que la prise en charge de ce champ varie selon l'environnement, donc vérifiez le schéma actuel de votre configuration ; là où ce n'est pas un champ formel, intégrez des exemples équivalents directement dans le corps de la description.

arguments, les définitions des entrées dynamiques que les appelants transmettent à la Skill. Chaque argument précise généralement un nom, un type, s'il est requis ou optionnel, et une valeur par défaut. Les arguments sont ce qui rend une Skill flexible : une Skill de génération de rapports pourrait prendre un argument format (par défaut markdown) ou un severity_threshold. Gardez l'ensemble des arguments minimal et bien documenté, car chaque argument est une chose de plus que l'appelant doit comprendre et un chemin de plus que vous devez tester.

Rédiger un corps de SKILL.md efficace

C'est dans le corps que réside l'expertise concrète, et la façon dont vous le rédigez détermine directement la fiabilité d'exécution de Claude.

Adaptez le niveau de guidage à la marge de manœuvre de la tâche. Anthropic utilise ici une analogie facile à retenir. Imaginez Claude en train d'explorer un chemin : un pont étroit surplombant des falaises exige des garde-fous précis (peu de liberté), tandis qu'un champ ouvert permet une multitude de trajets (beaucoup de liberté), le niveau de guidage de votre Skill doit donc coller au terrain. Une Skill de vérification de conformité a besoin d'étapes strictes et prescriptives. Une Skill de brainstorming, elle, peut laisser beaucoup plus de marge. Ne sur-contraignez pas les tâches créatives, et ne sous-contraignez pas celles à fort enjeu.

Structurez le corps du texte de façon prévisible. Un schéma qui fonctionne bien : une phrase résumant la tâche, une procédure étape par étape, un format de sortie fixe, et une section de consignes qui referme les zones d'ambiguïté. Les exemples de workflow d'Anthropic suivent d'ailleurs ce même schéma, avec une vérification finale en guise de conclusion : rédiger le brouillon en suivant la structure des titres et les consignes de ton, puis passer la checklist qualité avant de livrer le brouillon.

Incluez des exemples et des étapes de validation. Des exemples concrets ancrent la compréhension de Claude, et des étapes de validation explicites permettent de repérer les erreurs avant qu'elles n'atteignent l'utilisateur. Quand les résultats sont incohérents, la solution est presque toujours d'ajouter plus de précision et plus de validation, pas plus de longueur.

Restez concis. Chaque ligne que vous ajoutez est chargée dans le contexte à l'invocation. La recommandation de rester sous les 500 lignes n'est pas arbitraire : elle protège votre budget de contexte et évite que les instructions importantes ne se retrouvent diluées.

Utiliser les fichiers complémentaires : références, scripts et ressources

Les répertoires optionnels sont là pour garder le SKILL.md léger tout en donnant à Claude accès à davantage de contenu quand il en a besoin. C'est le troisième niveau de la divulgation progressive.

references/ contient la documentation que Claude charge à la demande : spécifications détaillées, longs tableaux de référence, guides de style. Le corps du fichier renvoie vers ces documents et Claude ne les lit que si la tâche l'exige. C'est ainsi que l'on gère un Skill doté d'une large base de connaissances sans payer le coût de contexte à chaque invocation.

scripts/ contient les outils exécutables. Quand un Skill doit faire quelque chose de déterministe, comme lancer un linter, parser un fichier ou appeler une API, un script est plus fiable que de demander à Claude de simuler le travail. Le corps du fichier indique à Claude quand et comment exécuter chaque script.

assets/ contient les fichiers statiques : modèles, schémas, boilerplate, images. Un Skill de génération de documents garde son modèle de rapport ici.

Le principe général est élégant. Pour activer des skills, il suffit d'écrire un fichier SKILL.md avec des instructions personnalisées pour votre agent, et un skill est un répertoire contenant un fichier SKILL.md avec des dossiers organisés d'instructions, de scripts et de ressources qui donnent aux agents des capacités supplémentaires. Commencez avec le simple SKILL.md et n'ajoutez des répertoires complémentaires que lorsque le corps du fichier dépasse vraiment le cadre d'un seul fichier.

Contrôle d'accès et packaging pour les équipes

Deux enjeux de production complètent le tableau : qui peut utiliser un Skill, et comment le distribuer.

Contrôle d'accès. Définissez les niveaux d'accès de façon réfléchie. Privé pendant le développement et les tests, équipe ou espace de travail une fois validé. Comme Claude.ai limite actuellement les Skills à des utilisateurs individuels, les équipes doivent en attendant maintenir un dépôt partagé des spécifications. Il est recommandé de créer un dépôt de documents partagé avec les spécifications des skills, ce qui prépare votre organisation aux prochaines fonctionnalités tout en instaurant dès aujourd'hui de bonnes pratiques de gouvernance.

Packaging et distribution. Une fois qu'une Skill est bien rodée, il faut la distribuer correctement plutôt que de faire circuler des fichiers au hasard. La méthode qui a fait ses preuves, c'est Git, plus les plugins, plus les paramètres entreprise. Vous pouvez partager vos skills avec votre équipe en les commitant dans un repository, les diffuser plus largement via des plugins, ou les déployer à l'échelle de toute l'organisation grâce aux paramètres gérés en entreprise. Pour une gouvernance à grande échelle, les clients Enterprise bénéficient d'un accompagnement supplémentaire. Ils peuvent notamment travailler avec l'équipe customer success d'Anthropic pour explorer d'autres options de déploiement et de gouvernance.

Tester avant de distribuer. Ne distribuez jamais une Skill que vous n'avez pas testée sur une bibliothèque de cas réalistes. Il faut couvrir le cas normal, les cas limites, et surtout les demandes hors périmètre qui ne doivent pas déclencher la Skill. C'est cette dernière catégorie qui vous permet de repérer les déclenchements abusifs avant que vos collègues ne le fassent à votre place.

5. Modèles avancés : intégration MCP, sous-agents et validation des outils

Une fois qu'on est à l'aise avec les Skills prises individuellement, le vrai gain vient de leur combinaison avec le reste de la plateforme Claude. Cette section couvre les modèles qui transforment une bibliothèque de Skills en véritable automatisation.

Intégration MCP avec les Skills Claude

Le Model Context Protocol connecte Claude à des systèmes externes : bases de données, API, systèmes de stockage, outils internes. Skills et MCP sont complémentaires, pas concurrents. MCP fournit la connexion ; la Skill fournit la procédure pour bien utiliser cette connexion.

Un exemple concret : MCP connecte Claude à votre base de données analytics. Livré à lui-même, Claude peut l'interroger mais ne connaît ni vos conventions de nommage de tables, ni la définition de vos indicateurs clés, ni le format de rapport attendu par votre équipe. Une Skill apporte tout ça. Elle indique à Claude quelles tables contiennent quelles données, comment "utilisateur actif" est défini dans votre organisation, et comment structurer précisément le résultat. Ensemble, elles transforment une simple connexion en un analyste fiable.

La bibliothèque d'exemples d'Anthropic inclut même la génération de serveurs MCP parmi ses Skills de démonstration, ce qui montre bien à quel point les deux couches s'articulent naturellement. Quand vous concevez une Skill d'activation d'outil, partez du principe que MCP gère le transport, et concentrez votre SKILL.md sur la logique de décision : quand faire appel à l'outil, quels paramètres transmettre, et comment valider ce qui revient.

Sous-agents Claude et délégation de Skills

Les sous-agents permettent de déléguer une tâche bien délimitée à un agent séparé, doté de son propre contexte isolé. Associer un sous-agent à une Skill vous donne un exécutant expert pour une tâche précise, sans encombrer votre conversation principale.

Ce schéma est particulièrement efficace pour les pipelines à plusieurs étapes. Imaginez un workflow de release : un premier sous-agent, doté d'un Skill de revue de code, examine le diff ; un deuxième, équipé d'un Skill de changelog, rédige les notes de version ; un troisième, muni d'un Skill de QA, génère un plan de test. Chacun tourne en isolation, avec uniquement le contexte dont il a besoin. Anthropic décrit exactement cette capacité. Vous pouvez intégrer des Skills à des sous-agents personnalisés pour déléguer des tâches spécialisées en isolation, et il existe un guide de dépannage complet pour diagnostiquer les problèmes, des skills qui ne se déclenchent pas aux conflits de priorité et erreurs d'exécution.

L'avantage est double : un contexte plus propre (la conversation principale n'est pas polluée par les notes de travail du sous-agent) et une spécialisation plus claire (chaque sous-agent fait bien une seule chose). Le coût, c'est la complexité de coordination : réservez donc les sous-agents aux tâches qui bénéficient réellement de l'isolation, pas à tout et n'importe quoi.

Approbation des outils Claude et contrôle d'accès

Quand un Skill donne à Claude la capacité d'utiliser des outils, en particulier des outils qui déclenchent de vraies actions comme l'envoi d'e-mails, l'écriture dans une base de données ou l'appel d'une API payante, l'approbation des outils devient un enjeu de sécurité crucial. Le principe à suivre est celui du moindre privilège : un Skill ne devrait débloquer que les outils dont il a réellement besoin, et les actions ayant de vraies conséquences devraient exiger une confirmation.

Concevez vos Skills d'activation d'outils de façon à ce que les opérations en lecture seule circulent librement, tandis que les opérations d'écriture ou destructrices marquent une pause en attente d'approbation. Documentez précisément dans le corps du SKILL.md quels outils le Skill utilise et sous quelles conditions, afin que Claude comme tout relecteur humain comprennent le périmètre d'impact. C'est aussi là que le champ author et un versioning clair prennent toute leur valeur : quand un Skill peut déclencher des actions, on veut une responsabilité sans ambiguïté sur qui le possède et quelle version est active.

Pour les organisations, tout cela renvoie aux paramètres gérés en entreprise, où les administrateurs peuvent contrôler quelles Skills et quels outils sont accessibles à qui. Il faut traiter l'approbation des outils comme une partie intégrante de la conception des Skills dès le départ, pas comme un ajout après coup. Une Skill capable d'agir est une Skill capable de causer des dégâts si elle se déclenche à tort, ce qui est une raison de plus de bien délimiter les descriptions et de tester rigoureusement les demandes hors périmètre.

Tester les Skills et assurer la qualité à grande échelle

Tester une seule Skill, c'est facile. Maintenir la qualité sur une bibliothèque qui grandit, ça demande de la rigueur. Trois pratiques font vraiment la différence.

Séparer les tests de déclenchement des tests d'exécution. Comme on l'a vu plus haut, ce sont deux types d'échecs bien distincts. Il faut garder des cas de test pour chacun : un jeu qui vérifie que la Skill se déclenche (et qu'elle ne se déclenche pas quand elle ne devrait pas), un autre qui vérifie la qualité du résultat une fois qu'elle s'est déclenchée. Testez le déclenchement et l'exécution séparément ; si les skills ne s'activent pas, élargissez votre description et ajoutez des cas d'usage, et si les résultats sont incohérents, précisez davantage vos instructions et ajoutez des étapes de validation.

Constituer une vraie bibliothèque de cas de test. Pour chaque Skill, gardez des cas documentés couvrant l'usage normal, les cas limites et les demandes hors périmètre. Faites-les tourner à chaque modification de la Skill. Cela permet de repérer les régressions avant qu'elles n'atteignent les utilisateurs, et c'est vraiment l'habitude la plus précieuse pour une bibliothèque qui gagne en maturité.

Surveiller les conflits de priorité. Au fur et à mesure que votre bibliothèque s'étoffe, deux Skills aux descriptions qui se chevauchent vont commencer à entrer en concurrence. Une partie du contrôle qualité à grande échelle consiste à auditer les descriptions pour repérer les chevauchements et resserrer le périmètre de chacune pour qu'elle ait un territoire bien à elle. Les guides de dépannage fournis par Anthropic identifient d'ailleurs spécifiquement les conflits de priorité comme une catégorie de problème connue, donc autant s'y préparer et concevoir vos Skills en conséquence.

Vous faites tourner Claude sur plusieurs repos toute la semaine pour tester votre bibliothèque de Skills ? C'est souvent un forfait Max 20x à 200$/mois, facturé en USD. Avec Bleap, vous payez au vrai taux de change, 0% de frais FX, et vous touchez 20% de cashback fixe sur vos renouvellements Claude, ChatGPT et Gemini, sans abonnement carte requis. Découvrir la carte Bleap →

6. Bonnes pratiques en production et la manière intelligente de payer Claude

Vous avez maintenant tout ce qu'il faut pour créer, structurer et combiner des Skills. Deux derniers éléments font la différence entre un hobby et une vraie pratique en production : la rigueur opérationnelle, et le fait de considérer le coût de votre abonnement Claude comme quelque chose à optimiser.

Checklist des bonnes pratiques en production

• Restreignez le périmètre. Chaque Skill doit faire une seule chose, mais bien. Un périmètre restreint garantit un déclenchement fiable et un résultat cohérent.
• Rédigez des descriptions percutantes. Luttez contre le sous-déclenchement en listant explicitement les scénarios qui doivent activer la Skill, y compris les cas implicites.
• Gardez les corps de texte légers. Moins de 500 lignes, avec les détails renvoyés vers references/. Protégez votre budget de contexte.
• Versionnez tout. Versioning sémantique plus tags Git pour que tout le monde sache quel comportement est actif.
• Testez selon trois catégories. Cas normal, cas limite, et hors périmètre, en testant séparément le déclenchement et l'exécution.
• Contrôlez les accès avec discernement. Privé d'abord, élargissez seulement après validation. Appliquez le principe du moindre privilège pour les outils.
• Maintenez un dépôt de spécifications. Surtout tant que le partage à l'échelle de l'organisation n'est pas encore mature, un dépôt de specs partagé garde l'équipe alignée et vous prépare aux paramètres gérés.
• Documentez la responsabilité. Utilisez le champ author pour que chaque Skill ait un propriétaire clairement identifié.

Suivez ces principes et vous construirez une bibliothèque de Skills qui prend de la valeur avec le temps, au lieu d'accumuler de la dette technique.

L'angle coût : payer Claude sans perdre d'argent

[CTA BANNER]

Voici la partie que la plupart des guides passent sous silence. Créer des Skills implique de payer pour Claude, et les abonnements Claude sont facturés en dollars. Le plan Claude Pro coûte 20$/mois (ou 17$/mois avec facturation annuelle), et Claude Max va de 100 à 200$/mois. Pour les équipes, le plan Team démarre à 25$ par utilisateur et par mois, et à 150$/mois pour les postes premium incluant l'environnement de développement Claude Code.

Si vous êtes dans l'EEE et que vous payez un abonnement en USD avec une carte européenne classique, vous perdez de l'argent à chaque renouvellement sans même vous en rendre compte. La plupart des cartes ajoutent 2 à 3% de frais de change en plus d'un taux déjà majoré. Sur un plan Max équivalent à 200€, ces 2-3% représentent environ 4 à 6€ par mois, soit 48 à 72€ par an, rien qu'en frais de change. Pour une équipe de cinq personnes sur des postes Team, la fuite s'accumule vite.

C'est là que Bleap entre en jeu. Bleap n'est pas un outil d'IA et ne créera pas vos Skills à votre place. C'est une entreprise fintech de cartes bancaires, et c'est la façon la plus intelligente de payer les abonnements IA dont ce guide parle. Deux avantages concrets s'appliquent directement ici :

• 0% de frais de change sur les abonnements en USD. Vous payez votre facture Claude Pro, Max ou Team au taux de change réel, sans frais de transaction à l'étranger et sans majoration le week-end. L'argent qui serait parti en frais de change reste dans votre poche.
• 20% de cashback sur Claude, ChatGPT et Gemini. Bleap offre un cashback fixe de 20% (versé en USDC) sur les abonnements à ces trois outils d'IA en particulier. Sur un plan Claude Pro à 20$/mois, c'est de l'argent bien réel récupéré chaque mois, et sur un plan Max à 200$/mois, c'est nettement plus.

C'est une carte de débit Mastercard auto-custodiale, utilisable partout où Mastercard est accepté, sans abonnement mensuel qui lui soit propre. Il n'y a aucun compromis à faire : vous gardez le contrôle total de vos fonds, vous payez vos factures d'IA exactement comme avant, et vous arrêtez de perdre de l'argent en frais de change tout en gagnant du cashback sur les trois plus grands abonnements IA. Pour quiconque utilise Claude assez sérieusement pour créer des Skills, c'est une optimisation qui coule de source.

Une précision honnête : le cashback forfaitaire de 20% s'applique spécifiquement à Claude, ChatGPT et Gemini. Pour les autres outils d'IA, vous bénéficiez toujours de l'avantage des 0% de frais de change sur la facturation en USD, mais pas des 20% de cashback. Et les coffres d'épargne de Bleap, qui rapportent 3,65% AER (Steady, risque le plus bas) et 3,83% AER (Dynamic, risque faible) en USD avec un minimum de 1$ et 0% de frais de retrait, sont une fonctionnalité à part qui vaut le coup de connaître si vous voulez que votre solde disponible travaille pendant que vous développez.

Questions fréquentes

Qu'est-ce qu'une Claude Skill exactement ?

Une Claude Skill est une unité d'instructions autonome et réutilisable que Claude charge à la demande pour accomplir une tâche précise de manière fiable. Les Skills sont des dossiers contenant des instructions, des scripts et des ressources que Claude charge dynamiquement pour améliorer ses performances sur des tâches spécialisées, en lui apprenant comment mener à bien certaines tâches de façon reproductible. Concrètement, il s'agit simplement d'un dossier contenant un fichier SKILL.md avec un en-tête YAML et des instructions au format Markdown, accompagné éventuellement de répertoires complémentaires.

Quelle est la différence entre un fichier skill.md et un prompt ?

Un prompt ne vit que le temps d'un échange et disparaît ensuite. Un fichier SKILL.md, lui, est persistant, versionné, repérable et réutilisable. La vraie différence structurelle, c'est que Claude sait activement qu'une Skill existe : au démarrage, l'agent précharge le nom et la description de chaque skill installée directement dans son prompt système. Claude ne peut jamais utiliser un prompt qu'on ne lui a pas montré, mais il peut mobiliser automatiquement une Skill pertinente.

Faut-il savoir coder pour créer des Claude Skills ?

Non. Les Skills relèvent avant tout d'un exercice de rédaction et de configuration. Ce ne sont ni des modèles ni des add-ons payants : ce sont des instructions Markdown open source accompagnées de fichiers complémentaires. Si vous êtes capable d'écrire des instructions claires en Markdown et de réfléchir précisément aux conditions de déclenchement d'une tâche, vous pouvez créer une Skill de qualité professionnelle. Les scripts restent optionnels et ne sont utiles que pour les tâches nécessitant une exécution déterministe.

Comment Claude décide-t-il quand utiliser une Skill ?

Claude compare la requête en cours au champ description de chaque Skill installée en s'appuyant sur une similarité sémantique. Comme Claude a tendance à sous-déclencher les skills, c'est-à-dire à ne pas les utiliser alors qu'elles seraient utiles, Anthropic recommande de rédiger des descriptions qui listent explicitement les scénarios devant activer la Skill, y compris les cas implicites. Une description forte, précise et un peu insistante reste le facteur numéro un pour un déclenchement fiable.

Quelle longueur donner à un fichier SKILL.md ?

Restez concentré sur l'essentiel. La bonne pratique consiste à garder le corps du SKILL.md limité aux éléments essentiels, sous la barre des 500 lignes, et si vous approchez de cette limite, à répartir le contenu dans des fichiers séparés. Le frontmatter, toujours chargé, est minuscule (environ 100 tokens), tandis que le corps ne se charge que lorsque la Skill est invoquée. Un corps allégé protège donc votre budget de contexte et évite de diluer les instructions importantes.

Quel est le lien entre les Skills, MCP et les subagents ?

Ce sont des couches complémentaires. MCP constitue la couche de connectivité qui relie Claude aux outils et données externes ; une Skill est la couche d'instructions qui indique à Claude comment utiliser cette connexion. Les subagents apportent, eux, l'isolation, et vous pouvez intégrer des Skills à des subagents personnalisés pour déléguer des tâches expertes dans un environnement isolé. Un schéma de production courant combine les trois : MCP connecte les données, une Skill définit la procédure, et un subagent l'exécute dans un contexte propre.

Puis-je partager mes Skills avec toute mon équipe ?

De plus en plus, oui, même si les outils sont encore en maturation. Sur Claude.ai, les Skills sont pour l'instant propres à chaque utilisateur, mais des fonctionnalités de gestion et de partage à l'échelle de l'organisation arrivent bientôt. En attendant, vous pouvez les partager via un dépôt Git, les distribuer sous forme de plugins, et les déployer à l'échelle de l'organisation grâce aux paramètres de gestion entreprise. Maintenir un dépôt de spécifications partagé dès maintenant vous prépare aux futures fonctionnalités de gestion centralisée.

Combien coûte l'utilisation de Claude pour créer des Skills ?

La création de Skills fait elle-même partie des plans Claude. Les tarifs de Claude en 2026 vont de Free (0 $) à Pro (20 $/mois), Max 5x (100 $/mois), Max 20x (200 $/mois), Team Standard (25 $/poste/mois), Team Premium (125 $/poste/mois), jusqu'à Enterprise (sur devis). Comme ces abonnements sont facturés en dollars, payer depuis l'EEE avec une carte qui applique 2 à 3 % de frais de change vous coûte plus cher chaque mois. Avec Bleap, vous payez sans frais de change et bénéficiez d'un cashback fixe de 20 % sur vos abonnements Claude, ce qui vous laisse plus de budget pour l'usage réel du service.

Quelle est l'erreur la plus courante des débutants avec les Skills ?

Deux erreurs arrivent à égalité en tête de liste : rédiger une description trop vague (du coup, le Skill ne se déclenche jamais, ou alors se déclenche pour tout et n'importe quoi) et surcharger le corps du Skill. Pour résoudre le problème de déclenchement, il faut une description précise et riche en scénarios concrets ; pour améliorer la qualité des résultats, mieux vaut miser sur la précision et la validation plutôt que sur la longueur. Et testez toujours avec une bibliothèque de cas de test digne de ce nom : couvrez les usages normaux, les cas limites, et les demandes hors périmètre.

Conclusion

Les Claude Skills transforment le prompting artisanal en automatisation conçue et réutilisable. Le principe de base est vraiment simple : un dossier, un fichier SKILL.md avec un nom clair et une description précise et un peu insistante, et un corps d'instructions minimal que Claude ne charge que quand c'est pertinent. Maîtrisez ça, ajoutez MCP pour la connectivité, les subagents pour l'isolation, et des tests rigoureux pour la fiabilité, et vous obtenez une bibliothèque de Skills dont la valeur ne fait que croître pour toute votre équipe.

L'effort d'ingénierie est en réalité un effort de rédaction. Restez précis dans le périmètre, décrivez avec exactitude, versionnez tout, et testez selon trois catégories. Faites ça de façon rigoureuse et Claude cesse d'être un assistant généraliste à qui vous devez tout réexpliquer chaque matin, pour devenir un expert spécialisé qui connaît déjà vos processus.

Un dernier conseil pratique qui n'a rien à voir avec le code, mais tout à voir avec votre budget. Quel que soit le plan Claude que vous utilisez, et quels que soient les autres outils d'IA que vous utilisez à côté, payez intelligemment. Ces abonnements sont facturés en USD, et une carte classique prélève discrètement 2 à 3% à chaque renouvellement. Avec Bleap, vous évitez complètement les frais de change, et sur Claude, ChatGPT et Gemini, vous touchez un cashback fixe de 20% sur chaque paiement, le tout depuis une Mastercard self-custodial sans abonnement. Créez de superbes Skills. Mais ne payez pas trop cher pour les faire tourner.

Vous avez optimisé votre workflow Claude. Optimisez maintenant ce que vous payez pour le faire tourner. Bleap vous offre 0% de frais de change sur les abonnements en USD et un cashback fixe de 20% sur Claude, ChatGPT et Gemini, sans frais de carte mensuels et avec un contrôle total de vos fonds. Ouvrir un compte Bleap →

Le cashback de 20% de Bleap s'applique aux abonnements Claude, ChatGPT et Gemini, et il est versé en USDC. Pour les autres outils IA, l'avantage 0% de frais de change s'applique à la facturation en USD, mais le cashback de 20% ne s'applique pas. Les tarifs de Claude indiqués sont ceux en vigueur en 2026, fixés par Anthropic et non par Bleap ; consultez la grille tarifaire officielle d'Anthropic pour connaître les derniers paliers.