Comment créer des Claude Skills efficaces en entreprise ?

Il faut créer un dossier avec un fichier SKILL.md clair, puis y ajouter des ressources seulement si elles servent vraiment. Le vrai sujet, c’est de décrire quand Claude doit utiliser le Skill, quoi faire, et comment éviter les réponses floues.

C’est quoi un Claude Skill ?

Un Claude Skill, c’est simplement un petit dossier bien rangé qui explique à Claude comment faire une tâche précise. Je le vois comme une procédure métier utilisable par l’IA, mais dans un format propre, stable, versionnable, et surtout beaucoup moins fragile qu’une consigne copiée-collée dans un prompt.

Au minimum, ce dossier contient un fichier SKILL.md. C’est le cœur du Skill. Ce fichier décrit trois choses essentielles : le rôle du Skill, le moment où Claude doit l’utiliser, et le déroulé de la tâche à exécuter. En clair, on dit à Claude : “Quand tu reconnais ce type de demande, utilise cette méthode, avec ces règles, dans cet ordre.”

La différence avec un prompt classique est énorme. Un prompt, souvent, vit dans un document, dans Notion, dans la tête de quelqu’un, ou dans un message Slack oublié. Un Skill, lui, devient un actif réutilisable. Je peux le mettre dans un dépôt Git, le relire, l’améliorer, le partager à une équipe, et garder une logique claire. Chez un client, on avait remplacé une dizaine de prompts “officiels” par quelques Skills bien écrits. Le gain n’était pas magique, mais les réponses sont devenues plus cohérentes, et les équipes arrêtaient de réinventer la consigne à chaque fois.

Un Skill peut aussi contenir d’autres éléments, mais ce n’est pas obligatoire. On peut ajouter des scripts, des modèles, des exemples, ou des fichiers de référence. Par exemple, un modèle de compte rendu, un script Python de nettoyage de données, ou un fichier qui décrit les règles internes de rédaction. Claude peut s’appuyer dessus pour exécuter la tâche avec plus de contexte et moins d’improvisation.

Les Skills suivent la norme Agent Skills. Ça veut dire que le format n’est pas juste une astuce locale. Il est pensé pour être compatible avec plusieurs produits Claude. C’est important en entreprise, parce qu’on évite de créer des consignes enfermées dans un seul usage ou un seul outil.

Format	Usage	Limite
Prompt classique	Donner une consigne ponctuelle à Claude.	Facile à oublier, dupliquer, modifier sans contrôle.
Custom command	Lancer rapidement une instruction récurrente.	Pratique, mais souvent moins structuré qu’un Skill complet.
Claude Skill	Décrire une capacité réutilisable avec méthode, contexte et fichiers optionnels.	Demande un peu plus de rigueur au départ, mais tient mieux dans le temps.

Que mettre dans SKILL.md ?

Le fichier SKILL.md, c’est la notice d’utilisation du Skill. Claude le lit pour comprendre deux choses très simples : est-ce que ce Skill est utile maintenant, et si oui, comment il doit s’en servir. Dans les projets que je vois en entreprise, le problème vient rarement du code. Il vient souvent d’un SKILL.md trop flou.

Les métadonnées sont le point critique. Le nom doit être court et explicite. La description doit dire précisément quand activer le Skill. Claude lit ça en premier pour décider si le Skill correspond à la demande utilisateur. Une description vague comme “Aide à analyser des documents” déclenche mal. Une description précise comme “À utiliser pour résumer un contrat fournisseur et extraire les clauses de paiement, durée, résiliation et pénalités” aide Claude à choisir au bon moment.

La structure logique peut rester simple. Je mets généralement les éléments suivants dans le fichier :

• Nom : Le nom lisible du Skill.
• Description : Le contexte précis dans lequel Claude doit l’activer.
• Workflow : Les étapes à suivre, dans l’ordre.
• Règles permanentes : Les contraintes qui ne changent jamais.
• Format de sortie attendu : La forme exacte de la réponse finale.

---
name: analyse-contrat-fournisseur
description: À utiliser quand l’utilisateur demande d’analyser un contrat fournisseur, d’identifier les clauses importantes et de produire une synthèse opérationnelle pour une équipe achat.
---

# Workflow

1. Lire le document fourni.
2. Identifier les parties, les dates clés, les montants et les obligations principales.
3. Repérer les clauses sensibles : paiement, durée, renouvellement, résiliation, pénalités, confidentialité.
4. Signaler les points ambigus ou manquants.
5. Produire une synthèse claire pour une décision métier.

# Règles permanentes

- Ne pas inventer d’information absente du contrat.
- Citer les passages utiles quand c’est possible.
- Séparer les faits, les risques et les recommandations.
- Utiliser un langage simple, compréhensible par une équipe non juridique.

# Format de sortie attendu

- Résumé en 5 lignes maximum.
- Tableau des clauses clés.
- Liste des risques.
- Questions à poser au fournisseur.
- Recommandation finale.

Le bon réflexe, c’est d’écrire la description comme une condition d’activation. Pas comme une phrase marketing. Claude n’a pas besoin d’être séduit, il a besoin de savoir quand déclencher le bon outil.

Les erreurs à éviter sont assez classiques :

• Écrire une description trop générale.
• Mélanger plusieurs usages différents dans un seul Skill.
• Oublier le format de sortie attendu.
• Ajouter des règles contradictoires.
• Mettre trop de contexte inutile au lieu d’instructions actionnables.

Faut-il coder pour créer un Skill ?

Non, il n’est pas nécessaire de coder pour créer un Claude Skill de base. Dans beaucoup de cas, un simple fichier en Markdown suffit. Markdown, c’est juste du texte structuré avec des titres, des listes, des consignes et des exemples. Si votre Skill sert à cadrer une méthode, un style de réponse, une checklist ou un processus métier, je préfère souvent rester là-dessus. C’est plus lisible, plus maintenable, et les équipes métier peuvent le relire sans appeler un développeur.

Par exemple, un Skill qui aide à rédiger des comptes rendus commerciaux peut très bien être composé uniquement d’instructions. Il peut préciser le ton, les sections attendues, les points à vérifier, les formulations à éviter. Même chose pour un Skill RH qui suit une trame d’entretien, ou un Skill juridique qui impose une checklist avant de générer une réponse. Là, le sujet n’est pas de calculer. Le sujet, c’est de guider Claude pour qu’il applique toujours la même logique.

Le code devient utile quand on veut sortir du “Claude interprète la consigne” pour aller vers “Le système applique une règle exacte”. C’est souvent le cas dès qu’on touche à la data. Si je dois analyser un fichier, traiter des colonnes, faire des calculs déterministes, générer un graphique ou appeler un outil externe, un script devient pertinent.

J’ai vu ça chez un client avec un besoin très simple en apparence : auditer la qualité de fichiers CSV envoyés par plusieurs équipes. Le Skill devait vérifier les colonnes obligatoires, détecter les valeurs manquantes, repérer les doublons, contrôler les formats de dates et produire un petit résumé. On aurait pu tout demander à Claude en langage naturel. Mais les résultats auraient varié selon les fichiers et la formulation. Avec un petit script, les mêmes contrôles sont appliqués à chaque fois, dans le même ordre, avec les mêmes seuils. C’est moins magique, mais beaucoup plus fiable.

La bonne question n’est donc pas “Est-ce que je dois coder ?”. La vraie question, c’est “Est-ce que j’ai besoin d’un résultat reproductible, mesurable, vérifiable ?”. Si oui, le code a sa place. Sinon, du Markdown propre fait déjà très bien le travail.

Cas d’usage	Code requis ou non	Raison
Définir un style de réponse	Non	Des consignes Markdown suffisent pour cadrer le ton, la structure et les exemples.
Suivre une checklist métier	Non	Claude peut appliquer une liste d’étapes à partir d’instructions claires.
Auditer un fichier de données	Oui	Un script garantit les mêmes contrôles et les mêmes règles à chaque exécution.
Faire des calculs précis	Oui	Le code réduit l’interprétation et produit un résultat déterministe.
Générer une visualisation	Oui	Il faut transformer les données et produire un graphique avec une logique stable.
Connecter un CRM, un ERP ou une API	Oui	Une connexion externe demande une logique technique, des accès et souvent des contrôles d’erreur.

Comment Claude choisit un Skill ?

Quand je conçois un Skill Claude en entreprise, je pars d’un principe simple : Claude ne charge pas tout d’un coup. Il avance par couches. C’est ce mécanisme de chargement progressif qui permet d’avoir des Skills puissants sans exploser le contexte avec des fichiers inutiles.

La première étape, c’est la découverte. Claude regarde les métadonnées du Skill, surtout son nom et sa description. C’est là qu’il décide si le Skill a une chance d’être utile pour la demande. Une description vague donne un mauvais signal. Une description précise aide Claude à choisir le bon outil au bon moment.

Étape	Ce que Claude lit	Impact sur les tokens
Découverte	Les métadonnées du Skill	Très faible
Invocation	Le fichier SKILL.md	Consomme des tokens
Support	Scripts, exemples, fichiers de référence	Seulement si Claude les lit

La deuxième étape, c’est le chargement du fichier SKILL.md. Là, on n’est plus dans le simple repérage. Claude lit les instructions du Skill et les applique à la tâche. Pour moi, c’est le cœur du système. Ce fichier doit dire clairement comment travailler, quelles règles suivre, quels formats respecter, quoi éviter, et dans quels cas utiliser les ressources associées.

La troisième étape concerne les fichiers de support. Les scripts, les exemples, les modèles, les fichiers de référence, tout ça ne consomme pas de tokens tant que Claude ne les ouvre pas. C’est important. Vous pouvez donc avoir un Skill avec beaucoup de ressources sans alourdir chaque conversation. Le coût arrive uniquement quand Claude a besoin de lire un fichier pour exécuter correctement la tâche.

Le point souvent sous-estimé, surtout avec Claude Code, c’est que le contenu d’un Skill invoqué entre dans la conversation comme un message unique. Il reste actif pour la session. Donc je rédige toujours les consignes du SKILL.md comme des instructions permanentes, pas comme une aide ponctuelle. Si une règle doit guider Claude pendant toute la tâche, elle doit être écrite clairement dans ce fichier.

En pratique, plus les règles du SKILL.md sont stables, moins Claude improvise. J’ai vu ça chez un client sur un Skill de génération SQL. Dès qu’on a remplacé les consignes floues par des règles fixes sur les noms de tables, les jointures autorisées et le format de sortie, les réponses sont devenues beaucoup plus régulières. Pas magiques. Juste plus fiables.

Que deviennent les custom commands ?

J’ai vu pas mal d’équipes se poser la question : est-ce qu’on doit garder les anciennes custom commands, ou tout basculer en Skills ? La réponse courte, c’est que les deux mondes se rapprochent. Les commandes personnalisées placées dans .claude/commands/ et les Skills placés dans .claude/skills/ suivent maintenant une logique beaucoup plus unifiée.

Concrètement, une custom command servait souvent à déclencher une instruction réutilisable. Un peu comme un raccourci. Un Skill va plus loin. Il peut contenir des consignes plus propres, des ressources, des fichiers de référence, et parfois du code si le cas le justifie. C’est moins “commande magique” et plus “capacité métier réutilisable”. Et en entreprise, ça change pas mal de choses.

Le point important à retenir : si une commande et un Skill portent le même nom, le Skill prend le dessus. Donc si vous avez déjà une commande dans .claude/commands/ et que vous créez un Skill du même nom dans .claude/skills/, Claude utilisera le Skill. C’est pratique pour migrer progressivement, mais ça peut aussi surprendre si l’équipe n’a pas clarifié les noms.

Ce que je recommande en général, c’est de ne pas migrer bêtement une commande telle quelle. Une ancienne commande du type “analyse ce contrat” peut devenir un vrai Skill avec une description claire, un workflow, des règles d’analyse, des exemples attendus, et les modèles de documents utilisés par l’équipe juridique. On passe d’un prompt isolé à un petit module de travail. C’est plus fiable, plus maintenable, et surtout plus facile à partager.

Je resterais prudent sur la partie déploiement ou upload, parce que ça dépend de votre environnement et de ce qui est documenté côté outil. Mais sur le fond, la migration peut rester simple.

Voici la checklist que j’utilise pour faire le tri proprement :

• Identifier les commandes utiles : Garder seulement celles qui servent vraiment, pas les vieux tests oubliés.
• Clarifier la description : Écrire clairement quand le Skill doit être utilisé et ce qu’il doit produire.
• Transformer les étapes en workflow : Décrire le raisonnement attendu, les contrôles, les sorties.
• Ajouter les ressources nécessaires : Modèles, exemples, référentiels, règles internes.
• Tester dans une session Claude : Vérifier que le Skill se déclenche bien et donne un résultat stable.

Et si votre prochain workflow devenait un Skill ?

Créer un Claude Skill, ce n’est pas juste ranger un prompt dans un dossier. C’est transformer une façon de travailler en instruction réutilisable, plus stable, plus claire, et souvent plus facile à partager. Je retiens surtout trois choses : le fichier SKILL.md doit être précis, la description est décisive pour le déclenchement, et le code n’est utile que quand on veut automatiser ou fiabiliser un traitement. Les anciennes custom commands peuvent aussi être reprises dans cette logique. Le bénéfice pour vous est simple : moins de prompts bricolés, plus de workflows Claude propres, reproductibles et adaptés à votre business.

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 ce que le Skill fait, quand il doit être utilisé, et quelles étapes suivre. On peut aussi ajouter des scripts, des modèles, des exemples ou des fichiers de référence si le besoin le justifie.
• Est-ce qu’il faut savoir coder pour créer un Claude Skill ?
  Non. Pour un Skill simple, du Markdown suffit. Le code devient intéressant quand le Skill doit analyser des données, traiter des fichiers, effectuer des calculs déterministes, générer des visualisations ou s’intégrer à un système externe.
• Pourquoi la description d’un Skill est-elle importante ?
  Parce que Claude lit d’abord les métadonnées, notamment le nom et la description, pour décider si le Skill est pertinent. Une description trop vague peut empêcher le bon déclenchement. Une description précise aide Claude à choisir le bon Skill au bon moment.
• Quelle différence entre custom command et Claude Skill ?
  Les anciennes custom commands et les Skills sont désormais unifiés. Les commandes placées dans .claude/commands/ sont rapprochées des Skills placés dans .claude/skills/. Si une commande et un Skill portent le même nom, le Skill est prioritaire.
• Les fichiers d’un Skill consomment-ils toujours des tokens ?
  Non. Les scripts, exemples et fichiers de référence ne consomment pas de contexte tant que Claude ne les lit pas. Claude charge d’abord les métadonnées, puis les instructions, 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 rendre leurs données, leurs automatisations et leurs usages IA plus fiables, pas juste plus jolis en démo. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’ai travaillé 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 et automatiser vos workflows proprement, contactez-moi.