Cédric Rittié

← Retour au blog
guideia

Comprendre les Skills de Claude Code

Claude Code permet de créer des Skills : des fichiers d'instructions réutilisables qui évitent de se répéter à chaque session. Ce qu'ils sont, comment les écrire, comment les partager.

Le problème

Tu utilises Claude Code. Il fait le job. Tu lui dis "ajoute un formulaire de contact", il l'ajoute. Tu lui dis "refais-moi cette page en plus épuré", il s'exécute.

Mais tu te répètes. À chaque nouvelle session, les mêmes explications. "Utilise un ton direct, pas de jargon." "Les couleurs du projet sont crème, olive et forest." "Quand tu rédiges, pas de tirets longs, pas d'emojis." Tu as peut-être mis ça dans ton CLAUDE.md, et c'est bien. Mais certaines tâches méritent plus qu'une ligne de convention.

Tu veux que Claude rédige tes articles dans un ton précis. Qu'il analyse un site concurrent avec ta grille à toi. Qu'il génère des briefs créa formatés pour ton équipe. Ça ne rentre pas dans un fichier de config global. Ça mérite son propre espace.

C'est exactement ce que font les Skills.

Avant d'aller plus loin : Claude Code, c'est pas que du code

Le nom est trompeur. Claude Code, c'est un outil qui peut lire des fichiers, en créer, naviguer sur le web, exécuter des commandes, structurer de l'information. Oui, il est excellent pour coder. Mais au quotidien, je l'utilise autant pour rédiger un article, analyser un positionnement, préparer un brief ou synthétiser une veille que pour écrire du JavaScript.

Tout ce qui suit dans cet article (les Skills, les commandes, les bibliothèques) s'applique à n'importe quel usage. Écriture, recherche, design, stratégie, organisation. Le code n'est qu'un cas parmi d'autres.

C'est quoi un Skill ?

Un Skill, c'est un mode d'emploi que tu donnes à Claude pour une tâche précise. Pas du code. Pas un plugin. Un fichier texte avec des instructions structurées.

Tu tapes /analyse-concurrence dans Claude Code, il lit les instructions du Skill et s'exécute. Il sait quoi regarder, dans quel ordre, avec quel format de sortie. Tu n'as rien à réexpliquer. C'est le même résultat que si tu avais passé 5 minutes à briefer Claude en début de conversation. Sauf que tu l'as fait une fois pour toutes.

La différence avec le CLAUDE.md : le CLAUDE.md est chargé à chaque conversation, c'est les règles du projet, toujours présentes en arrière-plan. Un Skill, lui, n'est chargé que quand tu l'appelles. C'est de la connaissance à la demande.

Ce qu'il te faut

Pré-requis

  • Claude Code installé (en CLI, dans VS Code, ou directement sur claude.ai/code)
  • Un éditeur de texte. N'importe lequel : VS Code, TextEdit, Notepad, peu importe
  • Savoir écrire en markdown. Si tu sais mettre un # devant un titre et des - devant une liste, c'est suffisant. On en reparle juste en dessous

C'est tout. Pas besoin de savoir coder.

L'anatomie d'un Skill

Un Skill, c'est un dossier avec un fichier SKILL.md à l'intérieur.

mon-skill/
  SKILL.md

Le fichier a deux parties. D'abord le frontmatter, la configuration, entre deux lignes ---. Ensuite le contenu, les instructions que Claude va suivre, écrites en markdown.

Voilà ce que ça donne pour un Skill qui analyse un site web :

---
name: analyse-site
description: Analyse un site web sur le design, le contenu et l'expérience utilisateur
disable-model-invocation: true
allowed-tools: Read, Grep, WebFetch
---

## Ta mission

Analyse le site demandé. Évalue :

1. La clarté du message (on comprend ce que fait le produit en 5 secondes ?)
2. La hiérarchie visuelle (titres, espaces, contrastes)
3. Le parcours utilisateur (de l'arrivée à l'action principale)
4. Le ton éditorial (formel, conversationnel, technique ?)

## Format de sortie

Pour chaque point :
- Constat (ce qui est)
- Verdict (ce qui marche / ce qui coince)
- Suggestion concrète

C'est du markdown. Si tu sais écrire un email un minimum structuré, tu sais écrire un Skill.

C'est quoi le markdown ?

Un format de texte simple utilisé partout dans l'écosystème tech. Les # font des titres, les ** du gras, les - des listes. Tu en as déjà vu dans les README sur GitHub. Aucun logiciel spécial nécessaire, un éditeur de texte suffit.

Le frontmatter en 4 lignes

Quatre champs, pas plus, et tu couvres 90% des cas :

  • name : le nom de ton Skill. C'est aussi ta commande slash. analyse-site donne /analyse-site.
  • description : ce que fait le Skill. Important : Claude utilise cette description pour décider s'il doit l'invoquer tout seul. Plus c'est précis, mieux il décide.
  • disable-model-invocation : true si tu veux garder le contrôle. Claude ne lancera le Skill que quand tu le lui demandes explicitement.
  • allowed-tools : les outils autorisés sans te demander la permission. Read, Grep pour de la lecture. Ajoute WebFetch s'il doit aller sur le web.

Il existe d'autres champs (choix du modèle, niveau d'effort, exécution isolée) mais on n'en a pas besoin pour démarrer.

Invoquer un Skill

Le plus simple du monde. Tu tapes la commande slash :

/analyse-site

Claude charge les instructions du Skill. Il te demande ce qu'il lui manque, ici l'URL du site à analyser. Tu la donnes, il déroule l'analyse point par point, exactement comme tu l'as défini.

Et parfois, tu n'as même rien à taper. Si ton Skill a une bonne description et que l'invocation automatique est active, Claude le détecte tout seul. Tu lui dis "donne-moi ton avis sur le site de tel concurrent", il trouve ton Skill d'analyse et l'applique.

La règle de bon sens : si le Skill modifie des fichiers, publie quelque chose, ou a un quelconque effet de bord, garde le contrôle avec disable-model-invocation: true. Si c'est de la lecture, de l'analyse ou de la rédaction, laisse Claude décider.

Aller plus loin : passer des arguments

Tu peux injecter des informations directement dans la commande. Le Skill les récupère via $ARGUMENTS.

Exemple : un Skill qui génère un brief créatif.

---
name: brief-design
description: Génère un brief créatif structuré pour l'équipe design
disable-model-invocation: true
---

## Brief créatif

Crée un brief design sur le sujet suivant : $ARGUMENTS

Structure du brief :
- Contexte et objectif
- Cible utilisateur
- Direction artistique souhaitée
- Contraintes techniques (formats, responsive, accessibilité)
- 3 références d'inspiration (cherche sur le web)

L'invocation :

/brief-design refonte de la page pricing pour le segment PME

Claude reçoit toute la phrase après la commande et génère le brief complet. La structure est toujours la même, seul le sujet change. Tu produis un brief en 30 secondes au lieu de 10 minutes.

Tu peux aussi découper les arguments par position quand tu as plusieurs entrées distinctes :

---
name: compare-sites
description: Compare deux sites web sur le design et le contenu
---

Compare ces deux sites :
- Site A : $ARGUMENTS[0]
- Site B : $ARGUMENTS[1]

Pour chaque critère (clarté du message, design, parcours utilisateur, ton éditorial),
indique lequel est le plus efficace et pourquoi.

/compare-sites https://stripe.com https://lemonsqueezy.com

Ta bibliothèque personnelle

Les Skills vivent à deux endroits selon leur portée :

Portée Où les mettre
Ce projet uniquement .claude/skills/ dans le dossier du projet
Tous tes projets ~/.claude/skills/ dans ton répertoire personnel

Les Skills projet se partagent : tu les commit dans ton repo, toute l'équipe en bénéficie. Les Skills perso, c'est ta boîte à outils à toi. Ton style, tes méthodes, tes raccourcis.

Exemple de bibliothèque personnelle :

~/.claude/skills/
  analyse-site/SKILL.md        → Audit UX d'un site
  redige-article/SKILL.md      → Rédaction dans ton ton
  brief-design/SKILL.md        → Brief créa pour l'équipe
  veille-techno/SKILL.md       → Synthèse d'une tendance

Et dans un projet spécifique :

.claude/skills/
  charte-editoriale/SKILL.md   → Règles de rédaction du projet
  audit-accessibilite/SKILL.md → Checklist a11y spécifique

Si un Skill projet et un Skill perso ont le même nom, le projet gagne. Logique : les conventions d'un projet passent avant tes préférences individuelles.

Partager ses Skills

C'est là que ça devient intéressant. Les Skills suivent un standard ouvert, Agent Skills, pensé pour fonctionner au-delà de Claude Code.

Le partage se fait à trois niveaux :

Le repo Git, le plus naturel. Tes Skills sont dans .claude/skills/, tu push, tes collègues les ont. L'équipe construit ses standards, Claude les applique. Le nouveau qui arrive ? Il a les mêmes Skills dès le premier jour.

Les plugins, pour partager au-delà d'un projet. Tu packages tes Skills avec un manifeste JSON, tu distribues via GitHub ou un registre interne. Utile quand plusieurs équipes veulent les mêmes workflows.

Le marketplace, pour la communauté. Anthropic propose un espace où publier ses plugins. Tu soumets, c'est validé, et ça devient disponible pour tout le monde.

L'idée de fond est simple. Les meilleurs workflows ne se décrètent pas. Ils émergent de l'usage. Quelqu'un trouve une bonne façon d'analyser un marché, d'écrire une landing page, de structurer une veille. Il en fait un Skill, il le partage. D'autres l'adaptent, l'améliorent. C'est du open source appliqué aux méthodes de travail.

Et après

Si tu utilises Claude Code de temps en temps, les Skills ne changeront pas grand-chose. Mais si tu l'utilises tous les jours, pour concevoir, rédiger, analyser, structurer, les Skills transforment un assistant générique en un outil qui connaît tes méthodes.

Tu ne répètes plus, tu capitalises. Chaque bonne pratique que tu trouves, tu la figes dans un Skill. La prochaine fois, c'est automatique.

Le premier article parlait du pipeline : Claude Code, GitHub, Vercel, nom de domaine. La fondation. Les Skills, c'est la première couche de personnalisation par-dessus. Ton IA, tes règles.