Comment créer des Claude Skills vraiment utiles ?

Une Claude Skill, c’est un dossier avec un fichier SKILL.md qui apprend à Claude une façon de travailler. Je vais vous montrer ce qu’il faut mettre dedans, quand ajouter du code, comment Claude charge ces instructions et comment éviter les skills lourdes ou inutilisables.

C’est quoi une Claude Skill ?

Une Claude Skill est un répertoire structuré autour d’un fichier obligatoire SKILL.md, utilisé pour décrire à Claude un objectif, des règles de travail et un flux d’exécution réutilisable.

Dans sa version la plus simple, une skill peut tenir dans ce seul fichier. Pas besoin de code. Pas besoin de scripts. Pas besoin de fichiers annexes. Si le besoin est clair et que les consignes sont bien écrites, SKILL.md suffit largement pour créer une skill utile.

Son rôle est central. C’est lui qui donne à Claude le contexte métier, les consignes permanentes, les contraintes à respecter, les formats de sortie attendus et la logique générale à suivre. En gros, au lieu de répéter vingt fois le même prompt, je mets la méthode dans un fichier propre, réutilisable, versionnable, et Claude sait comment travailler.

Une skill peut aussi contenir d’autres ressources, mais seulement si ça apporte quelque chose :

• Des scripts pour automatiser un calcul ou un contrôle.
• Des exemples pour montrer le résultat attendu.
• Des modèles de rapports ou de fichiers.
• Des fichiers de référence, comme une nomenclature métier.
• Des templates pour garder une structure stable.

Ces fichiers sont optionnels. Et franchement, il ne faut pas les ajouter par réflexe. J’ai vu des skills devenir inutilisables parce qu’on voulait tout mettre dedans. Le bon réflexe, c’est d’abord d’écrire un SKILL.md clair, puis d’ajouter des ressources seulement quand elles réduisent vraiment l’ambiguïté.

Les Claude Skills s’inscrivent aussi dans l’idée du standard ouvert Agent Skills. Le principe est simple : décrire des compétences de façon structurée, portable et compréhensible par des agents IA. Pas juste pour Claude dans l’absolu, mais pour construire des briques de travail réutilisables.

Prenons une skill d’audit qualité de données. Dans SKILL.md, je peux expliquer à Claude comment repérer les valeurs manquantes, les incohérences, les doublons, les formats suspects, puis comment produire un rapport clair avec les problèmes, leur gravité et les actions recommandées. Chez des clients, le vrai gain vient souvent de là. Pas du code. Du cadrage des règles dans SKILL.md. Quand les règles sont nettes, Claude travaille beaucoup mieux.

Élément	Rôle	Obligatoire ou optionnel
SKILL.md	Décrit l’objectif, les règles, le contexte et le flux de travail.	Obligatoire
Ressources complémentaires	Ajoutent des exemples, modèles, références ou supports utiles.	Optionnel
Scripts ou templates	Automatisent certaines tâches ou standardisent les livrables.	Optionnel

Où placer une skill Claude ?

Une skill Claude se place dans un dossier dédié aux skills, par exemple .claude/skills/. Les anciennes commandes personnalisées, elles, pouvaient vivre dans .claude/commands/. C’est le premier repère à avoir, et ça évite déjà pas mal de confusion.

Les skills remplacent et étendent les anciennes custom commands. Une custom command, c’est simplement une commande personnalisée que vous pouviez appeler dans Claude Code pour déclencher un comportement précis. Une skill va plus loin. Elle peut contenir des consignes, des exemples, des fichiers de référence, parfois même des scripts.

Point important : si une commande et une skill portent le même nom, côté usage, vous obtenez le même comportement attendu. Vous appelez le même nom. Mais si les deux existent en même temps, la skill prend la priorité. C’est pratique, parce que ça permet de migrer tranquillement.

Je le vois souvent chez des équipes qui ont déjà quelques commandes utiles dans Claude Code. Elles n’ont pas envie de tout casser pour “faire propre”. Et franchement, elles ont raison. Vous pouvez garder vos anciennes commandes, puis transformer progressivement celles qui méritent mieux en vraies skills. Pas besoin de tout réécrire d’un coup.

Une structure simple peut ressembler à ça :

.claude/
  skills/
    data-quality-auditor/
      SKILL.md
      scripts/
      examples/

Le fichier SKILL.md contient le cœur de la skill : ce que Claude doit faire, comment il doit raisonner, quelles règles suivre, quels formats respecter. Les dossiers scripts/ et examples/ sont utiles si la skill a besoin d’aller plus loin, par exemple avec un script d’analyse ou des exemples de fichiers attendus.

Le nommage compte plus qu’on ne le croit. Je garde des noms courts, lisibles, orientés usage. Si la skill sert à auditer la qualité des données, data-quality-auditor est clair. Un nom comme assistant-data, lui, ne dit pas grand-chose. Assistant pour quoi ? Nettoyer ? Auditer ? Documenter ? Générer du SQL ? On perd du temps avant même de commencer.

Une fois que l’emplacement est clair, la vraie question devient plus intéressante : est-ce qu’on a besoin de coder quelque chose, ou est-ce qu’un simple fichier Markdown suffit ?

Faut-il coder une Claude Skill ?

Non, Il n’est pas nécessaire de coder pour créer une Claude Skill simple. Un fichier SKILL.md bien écrit suffit souvent largement, surtout si votre besoin consiste à guider Claude avec une méthode claire, des règles métier et des exemples.

J’insiste là-dessus parce que je vois souvent l’erreur inverse. On veut tout de suite ajouter des scripts, des dossiers, des automatisations, alors que le vrai sujet, au départ, c’est le raisonnement. Si la skill sert à appliquer une méthode, un cadre d’analyse, une grille de relecture, une checklist qualité ou une façon standard de produire un rapport, le Markdown est généralement le meilleur point de départ.

Par exemple, une skill peut très bien contenir :

• Une grille d’audit commercial avec les critères à vérifier.
• Une méthode de scoring pour relire une page de vente.
• Un format de rapport mensuel à respecter.
• Une checklist métier avant publication d’un document.
• Des exemples de bonnes et mauvaises réponses.

Dans ces cas-là, coder trop tôt ajoute surtout de la friction. Le SKILL.md sert à dire à Claude comment réfléchir, quoi vérifier, dans quel ordre travailler, quel niveau de détail produire. Et franchement, c’est déjà beaucoup.

Le code devient utile quand on veut quelque chose de déterministe. Déterministe, ça veut dire que pour la même entrée, on veut toujours le même résultat. Là, Claude ne doit pas improviser. On parle d’analyse de données, de validation de fichiers, de génération de graphiques, de transformations structurées, d’automatisation, d’appels à des outils externes ou d’intégrations avec d’autres systèmes.

Exemple simple. Une skill d’audit qualité peut garder toutes ses règles dans SKILL.md. Mais si elle doit calculer le taux de valeurs manquantes dans un fichier CSV, détecter des doublons ou contrôler un format de colonne, un petit script devient pertinent. Il apporte de la fiabilité. Les scripts peuvent être exécutés via bash quand c’est nécessaire. Bash, c’est l’interface en ligne de commande qui permet de lancer un script ou une commande sur une machine.

Dans mes projets IA et automatisation, je commence presque toujours par formaliser le raisonnement en Markdown. Puis j’ajoute du code uniquement là où Claude ne doit pas deviner, interpréter ou refaire un calcul à sa façon.

Situation	Quand l’utiliser	Exemple
Skill entièrement en Markdown	Quand la skill décrit une méthode, une grille, une checklist ou un format de réponse.	Audit de contenu, relecture qualité, rapport type, analyse stratégique.
Skill avec scripts	Quand il faut calculer, valider, transformer ou produire un résultat répétable.	Détection de doublons, contrôle de fichier, calcul de statistiques, génération de graphiques.
Skill avec ressources de référence	Quand Claude doit s’appuyer sur des documents stables sans les réécrire dans le SKILL.md.	Référentiel métier, guide de marque, exemples validés, procédures internes.

Comment Claude charge une skill ?

Claude ne charge pas toute une skill d’un seul coup. Il avance par étapes, surtout pour économiser le contexte. Et c’est une bonne nouvelle, parce qu’une skill peut contenir des instructions, des scripts, des exemples, des fichiers de référence… Si tout était chargé dès le départ, on remplirait vite la fenêtre de contexte pour rien.

La première phase, c’est Discovery. Claude lit seulement les métadonnées de la skill, surtout le nom et la description. Il s’en sert pour décider si cette skill peut répondre à la demande. C’est pour ça que la description est critique. Pas “Skill pour gérer des fichiers”, trop vague. Plutôt “Analyse des exports CSV CRM, détection des doublons, normalisation des colonnes et génération d’un rapport de qualité”. Là, Claude comprend quand l’utiliser.

La deuxième phase, c’est Instruction loading. Si Claude estime que la skill est pertinente, il charge le corps Markdown du fichier SKILL.md. C’est là qu’il récupère les workflows, les règles, les formats de sortie, les contraintes métier, les consignes à suivre. Autrement dit, c’est ici que la qualité rédactionnelle compte vraiment. Une skill utile, ce n’est pas juste une liste d’idées. C’est une façon claire de travailler.

La troisième phase, c’est Supporting resources. Claude ne va chercher les scripts, les exemples ou les fichiers de support que si le besoin se présente. Les fichiers de référence ne consomment pas de tokens tant qu’ils ne sont pas lus. Ce point est important. J’ai vu des skills devenir inutilisables parce que tout était mis dans SKILL.md, alors que certaines infos auraient dû rester dans des fichiers séparés, appelés seulement au bon moment.

Il y a aussi un effet côté session dans Claude Code. Quand le contenu d’une skill est rendu dans une session, il reste présent tout au long de cette session. Donc j’évite d’écrire des consignes du type “fais ceci une fois”. Je préfère des règles permanentes, des guidelines durables, des principes qui restent vrais pendant toute la conversation.

Étape	Ce que Claude lit	Pourquoi c’est important
Discovery	Nom et description	Claude choisit si la skill est pertinente
Instruction loading	Corps de SKILL.md	Claude applique les workflows, règles et formats
Supporting resources	Scripts, exemples, fichiers de support si nécessaire	Le contexte reste léger tant que ces fichiers ne sont pas lus

Comment structurer SKILL.md ?

SKILL.md doit être structuré comme un mode opératoire durable, pas comme une liste de tâches jetable. Je le vois comme une fiche de transmission : si quelqu’un de votre équipe devait expliquer à Claude comment travailler correctement dans un contexte précis, qu’est-ce qu’il garderait ?

La structure la plus simple tient souvent en quelques blocs bien séparés.

• Métadonnées : Nom de la skill et description courte. Claude s’appuie sur ces éléments pour comprendre quand utiliser la skill.
• Objectif : Ce que la skill doit produire, et dans quel contexte elle est utile.
• Règles permanentes : Les principes qui ne changent pas. Par exemple, ne jamais ignorer les valeurs nulles dans un audit qualité.
• Workflow recommandé : Les grandes étapes, sans enfermer Claude dans une mécanique inutile.
• Format de sortie attendu : La forme de la réponse finale, avec les sections importantes.
• Ressources disponibles : Scripts, fichiers exemples, grilles de contrôle, si la skill en contient.

J’écris toujours les instructions avec des phrases courtes. Une règle par idée. Des exemples quand ça évite une mauvaise interprétation. Des critères de qualité quand le résultat doit être contrôlable. Ce qu’il faut éviter, c’est l’ambiguïté, les détails qui vieillissent vite, et les workflows de 25 étapes qui forcent Claude à dérouler une procédure même quand ce n’est pas nécessaire.

Pour une skill d’audit qualité de données, le contenu attendu pourrait ressembler à ça :

Nom : Audit qualité de données

Description : Analyse un jeu de données et identifie les problèmes de qualité prioritaires.

Objectif :
Produire un diagnostic clair sur la fiabilité d’un dataset avant analyse ou automatisation.

Règles d’analyse :
- Vérifier les valeurs manquantes, doublons, formats incohérents et valeurs extrêmes.
- Prioriser les anomalies qui peuvent fausser une décision métier.
- Distinguer les problèmes critiques des simples points d’attention.

Points de contrôle :
- Complétude
- Unicité
- Cohérence des formats
- Distribution des valeurs
- Risques métier associés

Sortie attendue :
- Résumé court
- Anomalies prioritaires
- Impact potentiel
- Recommandations concrètes

Si l’audit doit devenir plus déterministe, j’ajoute des scripts ou des fichiers exemples dans la skill. Ça évite les interprétations trop larges, surtout quand plusieurs personnes veulent le même niveau de contrôle.

Mon conseil terrain : je préfère une petite skill claire qu’une grosse skill qui essaie de tout faire. Les équipes l’adoptent plus vite, et Claude choisit mieux quand la description est nette.

Une bonne Claude Skill, au fond, c’est une manière de rendre votre savoir-faire réutilisable dans Claude sans tout réexpliquer à chaque session.

Alors, votre prochaine méthode mérite une skill ?

Créer une Claude Skill, ce n’est pas forcément faire du développement. Le point de départ, c’est un dossier propre et un fichier SKILL.md qui décrit clairement l’objectif, les règles et la façon de travailler. Le code vient après, seulement quand il apporte de la précision, de l’automatisation ou une intégration utile. Le vrai sujet, c’est la qualité des instructions : Claude découvre la skill par ses métadonnées, charge ses consignes si elles sont pertinentes, puis lit les ressources seulement au besoin. Bien pensée, une skill vous évite de répéter vos méthodes et vous fait gagner du temps à chaque usage.

FAQ

• Qu’est-ce qu’une Claude Skill ?
  Une Claude Skill est un dossier qui contient obligatoirement un fichier SKILL.md. Ce fichier explique à Claude l’objectif de la compétence, les règles à suivre, le workflow recommandé et parfois le format de sortie attendu.
• Est-ce que SKILL.md suffit pour créer une skill ?
  Oui, pour une skill simple, SKILL.md suffit. Vous pouvez créer une compétence uniquement en Markdown, sans script ni code. Les ressources complémentaires servent seulement quand le besoin devient plus structuré.
• Quelle différence entre une skill et une custom command ?
  Les skills remplacent et étendent les anciennes custom commands. Si une commande et une skill portent le même nom, elles produisent le même comportement d’usage, mais la skill prend la priorité.
• Quand faut-il ajouter du code dans une Claude Skill ?
  Le code devient utile pour des traitements déterministes, de l’analyse de données, de la validation, des transformations structurées, de l’automatisation ou des intégrations externes. Pour une méthode ou une grille d’analyse, le Markdown suffit souvent.
• Pourquoi Claude ne charge pas toute la skill directement ?
  Claude charge les skills par étapes pour optimiser le contexte. Il lit d’abord les métadonnées, puis les instructions de SKILL.md si la skill est pertinente, puis les ressources de support seulement si elles sont nécessaires.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent transformer leurs méthodes en systèmes vraiment utilisables, pas en gadgets IA. J’interviens via l’agence webAnalyste et l’organisme Formations Analytics, avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez structurer vos usages IA, automatiser vos workflows ou créer des skills utiles pour vos équipes, contactez-moi.