Comment créer des Claude Skills sans coder dans Claude ?

Je crée un Claude Skill avec un simple dossier et un fichier SKILL.md. Le code reste optionnel. Le vrai sujet, c’est de bien décrire quand Claude doit l’utiliser, quelles règles suivre, et comment garder un workflow stable sans remplir inutilement le contexte.

À quoi sert un Claude Skill ?

Un Claude Skill, ça sert surtout à arrêter de répéter les mêmes consignes à Claude. Quand vous avez un workflow, des règles métier, un format de sortie ou une méthode de travail que vous utilisez souvent, vous le mettez dans un skill. Claude peut ensuite le réutiliser dans les bonnes situations, sans que vous ayez à tout réexpliquer à chaque conversation.

Dans les faits, un skill est simplement un répertoire. À l’intérieur, il contient au minimum un fichier SKILL.md. Ce fichier décrit le nom du skill, sa description, les conditions dans lesquelles Claude doit l’utiliser, et les instructions à suivre. C’est le cœur du système.

Un skill peut aussi contenir d’autres éléments, mais ce n’est pas obligatoire. Par exemple :

• Des scripts pour exécuter une tâche précise.
• Des modèles de documents à remplir.
• Des exemples de sorties attendues.
• Des fichiers de référence, comme une grille d’audit, une procédure interne ou une charte éditoriale.

Les Claude Skills suivent la norme Agent Skills. L’idée, c’est de décrire des compétences réutilisables de manière assez standardisée pour qu’elles soient plus faciles à déplacer entre certains produits Claude. Je reste prudent là-dessus : ça ne veut pas dire que tout sera compatible partout, tout le temps. Mais ça donne un cadre propre, au lieu d’avoir des consignes éparpillées dans des prompts copiés-collés.

Côté business, c’est là que ça devient intéressant. Un skill peut servir à homogénéiser les réponses d’une équipe, auditer des fichiers, appliquer une checklist qualité, générer un livrable toujours au même format, ou documenter une procédure interne. Chez les clients, le vrai gain vient rarement du fichier lui-même. Il vient du fait qu’on arrête de recopier les mêmes consignes dans tous les prompts, avec des petites variations qui finissent par créer des écarts.

Approche	Usage	Avantage	Limite
Prompt classique	Demander une tâche ponctuelle à Claude.	Rapide à écrire et flexible.	Les consignes doivent être répétées à chaque fois.
Claude Skill	Réutiliser une méthode, un format ou une procédure.	Les règles sont centralisées et plus stables.	Il faut prendre le temps de formaliser le fonctionnement.
Script automatisé	Exécuter une action technique très précise.	Très fiable quand le besoin est bien cadré.	Moins souple et souvent plus technique à maintenir.

Faut-il savoir coder ?

Non, je n’ai pas besoin de savoir coder pour créer un Claude Skill minimal. Dans beaucoup de cas, un simple fichier SKILL.md bien écrit suffit. Markdown, c’est juste un format texte très simple pour structurer des consignes lisibles par Claude.

La règle que j’utilise est assez simple. Si le skill sert à guider Claude avec des instructions, des règles, des exemples, un ton, une méthode de travail et un format de sortie attendu, je reste en Markdown. C’est largement suffisant.

Le code devient utile quand je veux quelque chose de plus mécanique, plus vérifiable, ou moins dépendant de l’interprétation du modèle.

• Un skill de relecture éditoriale peut rester en SKILL.md, avec les critères de relecture, les erreurs à repérer, le niveau de correction attendu et le format de retour.
• Un skill qui contrôle la qualité d’un fichier CSV, donc un tableau de données texte avec des colonnes séparées par des virgules ou des points-virgules, peut s’appuyer sur un script.
• Un skill qui génère une visualisation de données peut aussi utiliser du code, parce qu’il faut produire un graphique de manière fiable.
• Un skill qui applique une validation stricte, par exemple vérifier que toutes les dates suivent le même format, gagne à utiliser un traitement automatisé.
• Un skill qui appelle un outil CLI, c’est-à-dire un outil en ligne de commande, aura souvent besoin d’un script pour exécuter l’action proprement.

Dans une équipe, je préfère presque toujours commencer sans code. On stabilise d’abord la méthode. On voit comment les gens formulent les demandes, quels cas reviennent souvent, quelles règles changent encore. Puis seulement après, je code les parties répétitives ou sensibles. J’ai vu trop de clients transformer un simple mode opératoire en usine à gaz juste parce qu’ils voulaient automatiser trop tôt.

Une structure minimale peut ressembler à ça :

mon-skill/
  SKILL.md

Dans le fichier SKILL.md, je prévois en général ces blocs simples :

Nom :
Skill de relecture éditoriale

Description :
Aide à relire un texte pour améliorer la clarté, le ton et la structure.

Quand utiliser ce skill :
Quand l'utilisateur demande une relecture, une amélioration ou une reformulation.

Instructions permanentes :
Corriger sans réécrire inutilement.
Garder le sens initial.
Signaler les passages ambigus.

Format attendu :
Retourner une version corrigée puis une liste courte des modifications importantes.

Ça paraît basique, mais c’est souvent exactement ce qu’il faut pour démarrer proprement.

Comment Claude charge un skill ?

Quand je parle de skill Claude, il faut éviter une confusion assez classique. Claude ne charge pas tout le contenu du skill d’un coup. Il fonctionne plutôt par divulgation progressive. En clair, il lit seulement ce dont il a besoin, au moment où il en a besoin, pour éviter de remplir inutilement son contexte.

Le contexte, c’est la quantité d’information que Claude garde sous les yeux pendant une session. Cette information est comptée en tokens, c’est-à-dire en petits morceaux de texte. Moins on en consomme pour rien, mieux Claude peut travailler proprement.

Le chargement se fait généralement en trois temps.

• La découverte. Claude lit surtout les métadonnées du skill, comme son nom et sa description. C’est là qu’il décide si le skill semble pertinent pour la demande. À ce stade, il n’a pas besoin de lire tous les fichiers.
• Le chargement des instructions. Si le skill est utile, Claude lit le corps de SKILL.md. C’est le fichier principal du skill, celui qui contient les règles, les consignes et la manière de raisonner ou d’agir.
• Les ressources de support. Claude consulte les scripts, exemples, modèles ou fichiers de référence seulement si c’est nécessaire. Il ne va pas fouiller partout par défaut.

C’est là que le fonctionnement devient intéressant. Les fichiers de référence, les données, les modèles ou les exemples ne consomment pas de tokens tant qu’ils ne sont pas lus. Et si le skill contient des scripts, ils peuvent être exécutés via bash, donc via une commande système. Dans ce cas, ce n’est pas tout le script qui remplit le contexte. C’est surtout sa sortie, le résultat utile, qui peut être réinjecté dans la discussion.

Il y a une conséquence importante dans Claude Code. Le contenu rendu de SKILL.md reste dans la session et n’est pas relu automatiquement à chaque fois. Donc j’évite d’y mettre des étapes trop ponctuelles, du genre “fais d’abord ça, puis ça”, qui vieillissent mal dès que la conversation avance. Je préfère y mettre des instructions permanentes, stables, qui servent de référence pendant toute la session.

Sur le terrain, je vois souvent le même piège. Un skill trop bavard redevient juste un gros prompt déguisé. Le bon réflexe, c’est simple. Je mets dans SKILL.md ce qui doit guider Claude en permanence, et je garde le reste dans des ressources appelées seulement quand elles sont vraiment utiles.

Où placer et nommer un skill ?

Un skill Claude, je le range toujours comme un petit outil autonome. Pas dans un coin vague du projet. Dans un répertoire dédié, avec un fichier obligatoire SKILL.md. C’est ce fichier qui porte les instructions principales du skill.

Le nom du dossier compte aussi. Il doit rester clair, court, lisible, et orienté usage. Pourquoi ? Parce que dans Claude Code, ce nom peut servir à exposer une commande du type /nom. Un skill appelé data-quality-auditor, c’est tout de suite plus utile qu’un truc nommé skill-test-v2-final. Oui, j’en ai déjà vu chez un client, et personne ne savait à quoi ça servait trois semaines après.

La structure que je recommande ressemble à ça :

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

Les sous-dossiers sont optionnels. Je les ajoute seulement quand ils apportent quelque chose. scripts pour du code exécutable, templates pour des modèles réutilisables, examples pour montrer le résultat attendu, references pour stocker de la documentation ou des règles métier.

Dans Claude Code, les anciennes commandes personnalisées et les skills sont maintenant alignés. Une ancienne commande placée dans .claude/commands/ et un skill placé dans .claude/skills/ peuvent produire le même comportement avec une commande /nom. Point important : si une commande et un skill portent le même nom, le skill prend la priorité.

Dans le frontmatter, c’est-à-dire le bloc de métadonnées en haut du fichier, je garde ça simple :

---
name: data-quality-auditor
description: Analyse un jeu de données pour détecter les problèmes de qualité, les valeurs manquantes, les doublons et les incohérences.
---

La description est critique. Claude s’en sert dès la phase de découverte, quand il décide si le skill est pertinent ou non. Une description floue donne un skill rarement appelé. Une description orientée usage aide Claude à comprendre le bon moment pour l’utiliser.

Bonne pratique	Pourquoi c’est utile
Nom explicite	La commande /nom devient compréhensible immédiatement.
Description orientée usage	Claude comprend quand déclencher le skill.
Instructions permanentes	Le comportement reste stable d’une utilisation à l’autre.
Ressources séparées	Les exemples, modèles et références restent faciles à maintenir.
Scripts seulement quand nécessaires	On évite de complexifier un skill qui peut rester simple.

Comment créer un auditeur qualité ?

Oui, je peux créer un auditeur qualité avec un skill Claude. Le principe est simple : je décris les contrôles attendus, le format de restitution, et si besoin j’ajoute des scripts pour rendre certaines vérifications plus carrées. Un script n’est pas obligatoire, mais sur des contrôles de doublons ou de formats de dates, ça évite les interprétations un peu floues.

Sur un Data Quality Auditor, le skill sert à examiner un fichier de données et à repérer les problèmes classiques : valeurs manquantes, incohérences de format, doublons, colonnes suspectes, types de données bizarres. La clé, c’est de transformer ça en règles. Par exemple : “Une colonne email doit contenir un @”, “Un identifiant client ne doit pas être vide”, “Une date doit être au format YYYY-MM-DD”. Sans règles claires, Claude peut aider, mais il devine trop.

<p><strong>Nom du skill</strong> : Data Quality Auditor</p>

<p><strong>Description</strong> : Ce skill audite un fichier de données et signale les problèmes de qualité détectables à partir des règles fournies.</p>

<p><strong>Quand l’utiliser</strong> : Utiliser ce skill quand je fournis un fichier CSV, Excel ou un extrait de table à contrôler.</p>

<p><strong>Règles d’audit</strong> : Vérifier les valeurs manquantes, les doublons, les formats incohérents, les colonnes vides, les valeurs aberrantes et les colonnes qui semblent mal nommées.</p>

<p><strong>Format de sortie attendu</strong> : Répondre avec un tableau HTML contenant les colonnes problème, gravité, preuve, recommandation.</p>

<p><strong>Limites</strong> : Ne pas inventer de règle métier absente. Signaler les hypothèses quand elles sont nécessaires.</p>

<p><strong>Information manquante</strong> : Si une règle, un schéma ou un contexte métier manque, poser une question ou indiquer clairement l’hypothèse utilisée.</p>

Une sortie attendue peut ressembler à ça :

Problème	Gravité	Preuve	Recommandation
Email invalide	Haute	12 lignes sans caractère @ dans la colonne email	Corriger ou exclure les lignes avant import CRM
Doublons client_id	Moyenne	8 identifiants apparaissent plusieurs fois	Définir une règle de déduplication

Dans Claude Code, j’utilise le skill via la commande exposée par son nom, par exemple /data-quality-auditor si c’est le nom déclaré. Dans Claude Web ou Desktop, je le rends disponible par téléversement quand l’interface le permet. Je reste volontairement simple : le skill doit d’abord bien guider Claude avant de devenir une usine à gaz.

Ma recommandation concrète : je teste toujours sur un petit fichier, je corrige les instructions, puis seulement après j’ajoute des ressources ou des scripts. C’est comme ça que j’évite les skills trop compliqués qui marchent bien une fois puis deviennent pénibles à maintenir.

Et maintenant, quel skill vaut le coup d’être créé ?

Un Claude Skill, ce n’est pas un gadget. C’est une façon propre de transformer une bonne méthode en workflow réutilisable. Je pars d’un dossier simple, d’un SKILL.md clair, puis j’ajoute des ressources seulement si elles apportent quelque chose. Le code vient après, quand il faut automatiser, valider ou intégrer. Le point clé, c’est d’écrire des instructions durables, parce que Claude charge le skill progressivement et garde ses instructions dans la session. Si vous faites ça bien, vous gagnez du temps, vous réduisez les écarts entre utilisateurs, et vous obtenez des réponses plus homogènes avec moins d’effort.

FAQ

• Qu’est-ce qu’un Claude Skill ?
  Un Claude Skill est un dossier qui contient au minimum un fichier SKILL.md. Ce fichier explique à Claude quand utiliser le skill, quelles instructions suivre et quel résultat produire. Des scripts, modèles, exemples ou références peuvent être ajoutés, mais ils ne sont pas obligatoires.
• Peut-on créer un Claude Skill sans coder ?
  Oui, un skill minimal peut être créé uniquement avec du Markdown dans SKILL.md. Le code devient utile quand il faut automatiser un traitement, analyser des fichiers, valider une sortie, transformer des données ou appeler des outils externes.
• Comment Claude décide d’utiliser un skill ?
  Claude commence par lire les métadonnées du skill, surtout le nom et la description. Si le skill semble pertinent, il charge ensuite les instructions de SKILL.md. Les ressources complémentaires sont consultées seulement si elles sont nécessaires.
• Quelle différence entre skills et commandes personnalisées dans Claude Code ?
  Dans Claude Code, les skills et les anciennes commandes personnalisées ont été alignés. Un skill peut exposer une commande du type /nom. Si un skill et une commande portent le même nom, le skill prend la priorité.
• Que faut-il mettre dans SKILL.md ?
  Je mets le nom du skill, une description claire, les situations où il doit être utilisé, les règles permanentes à suivre et le format de sortie attendu. J’évite les consignes ponctuelles trop contextuelles, surtout dans Claude Code, parce que le contenu rendu de SKILL.md reste présent dans la session.

 

 

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. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’accompagne des équipes chez Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor sur des sujets très concrets : fiabiliser la donnée, automatiser les workflows et rendre l’IA vraiment utile dans le business. Si vous voulez structurer vos usages Claude, IA ou automatisation, contactez-moi.