Si vous utilisez Claude régulièrement, vous avez peut-être remarqué qu’il adapte son comportement selon les contextes — il sait créer des documents Word propres, lire des PDFs complexes, ou générer des présentations PowerPoint clé en main. Derrière cette magie, il y a souvent un skill. Ce tutoriel vous explique tout : ce que c’est, comment en créer un, comment le rendre vraiment efficace, et comment Claude décide de l’utiliser.
Qu’est-ce qu’un skill ?
Un skill est un fichier d’instructions que vous donnez à Claude pour lui apprendre à accomplir une tâche spécifique de façon reproductible et de qualité professionnelle.
Imaginez que vous êtes chef cuisinier et que vous recrutez un assistant. Plutôt que de lui expliquer chaque soir comment préparer votre sauce signature, vous lui remettez une fiche recette détaillée : les ingrédients, les étapes dans l’ordre, les erreurs à éviter, les variantes possibles. C’est exactement ça, un skill. Avant je faisais toujours un long prompt avec des différence entre chaque fois, donc avec un skill c’est beaucouyp plus carré et je suis sûr de ne rien oublier, et je peux même améliorer mon skill puisque vous pouvez versionner le skill sur Github.
Concrètement, un skill c’est :
- Un dossier portant le nom du skill (ex : docx/, pdf/, pptx/)
- Un fichier principal appelé SKILL.md — le cœur du skill
- Optionnellement : des scripts, des fichiers de référence, des assets (modèles, polices, icônes…)
mon-skill/
├── SKILL.md ← obligatoire
├── scripts/ ← scripts réutilisables
├── references/ ← documentation technique
└── assets/ ← templates, polices, image
À quoi ça sert concrètement un skill ?
Sans skill, si vous demandez à Claude « crée-moi un document Word professionnel », il va faire de son mieux — mais il risque d’oublier de gérer les styles, la table des matières, les en-têtes, les numéros de page. Avec un skill docx, Claude suit une méthode éprouvée : il installe les bonnes librairies Python, utilise python-docx de la bonne façon, applique une mise en page cohérente. Le résultat est radicalement différent.
Les skills servent à :
- Capitaliser sur une méthode qui fonctionne bien
- Standardiser les sorties pour qu’elles soient toujours de qualité
- Éviter de réexpliquer la même chose à chaque conversation
Gérer des cas complexes avec des scripts et des ressources bundlées
Comment est structuré un SKILL.md ?
Le fichier SKILL.md a deux parties : un en-tête YAML (appelé frontmatter) et un corps en Markdown.
---
name: mon-skill
description: Ce que fait ce skill et quand l'utiliser. Inclure les déclencheurs spécifiques.
---
# Corps du skill
## Ce que Claude doit faire
Le frontmatter : la clé du déclenchement
Le frontmatter contient deux champs essentiels :
name — l’identifiant du skill. Simple, en minuscules, avec des tirets.
description — c’est le champ le plus important de tout le skill. C’est grâce à lui que Claude décide d’utiliser (ou non) le skill. Claude ne lit pas l’intégralité du skill à chaque requête — il scanne les descriptions de tous les skills disponibles et choisit lesquels consulter.
Pour une bonne description répondez à ces trois questions :
- Qu’est-ce que ce skill fait ?
- Dans quelles contextes l’utiliser ?
- Quels mots-clés ou situations doivent le déclencher ?
description: >
Crée des documents Word (.docx) professionnels avec mise en page avancée.
Utiliser dès que l'utilisateur mentionne "Word", "docx", ".docx", ou demande
un rapport, mémo, lettre, ou tout document téléchargeable. Également utile
pour extraire du contenu depuis un .docx existant ou pour insérer des images
dans un document Word.
Le corps : les instructions pour Claude
Le corps du SKILL.md contient tout ce dont Claude a besoin pour accomplir la tâche : étapes à suivre, formats de sortie attendus, exemples, cas limites à gérer, erreurs courantes à éviter.
Il n’y a pas de format imposé — c’est du Markdown libre. :
## Workflow
1. Installer les dépendances : `pip install python-docx --break-system-packages`
2. Créer le document avec les styles appropriés
3. Sauvegarder dans /mnt/user-data/outputs/
## Format de sortie
Toujours utiliser cette structure :
- En-tête avec titre et date
- Table des matières si > 3 sections
- Pied de page avec numéros de page
## Exemples
**Exemple 1 :**
Requête : "Fais-moi un rapport d'analyse"
Action : Créer un .docx avec titre, TOC, sections numérotées
## À ne pas faire
- Ne pas utiliser reportlab (pour les PDFs, pas les .docx)
- Ne pas oublier d'appeler present_files à la fin
Le système de chargement progressif
Un des concepts les plus élégants des skills est la progressive disclosure : un système à trois niveaux.
Niveau 1 : Métadonnées (toujours en contexte)
name + description (~100 mots)
Niveau 2 : Corps du SKILL.md (chargé quand le skill est déclenché)
Instructions complètes (<500 lignes idéalement)
Niveau 3 : Ressources bundlées (chargées à la demande)
Scripts, références, assets (taille illimitée)
Cela signifie que Claude ne lit pas tous les skills en entier à chaque requête — ce serait beaucoup trop lourd. Il ne consulte que ce dont il a besoin, au moment où il en a besoin. A la différence des serveurs MCP qui peuvent être gourmand en tokens.
Implication pratique : gardez votre SKILL.md sous 500 lignes. Si vous avez beaucoup de documentation (par exemple, plusieurs frameworks cloud : AWS, GCP, Azure), mettez-la dans des fichiers de référence séparés et indiquez dans le SKILL.md quand les lire :
## Documentation spécifique par plateforme
Selon la plateforme demandée, lire le fichier correspondant :
- AWS → references/aws.md
- GCP → references/gcp.md
- Azure → references/azure.md
Pensez à économiser vos tokens !
Comment créer un bon skill
Je sais qu’il existe des sites qui listent des milliers de skills, mais vous devez apprendre à les concocter vous même. Vous pouvez néanmoins vous inspirer pour faire les votre, comme ça vous comprendrez ce que vous faites.
Voici les principes qui distinguent un skill basique d’un skill vraiment efficace.
Principe 1 : la description est reine
Répétons-le car c’est crucial : la description détermine si le skill sera utilisé ou non. Une description trop vague = skill ignoré. Une description trop restrictive = skill sous-utilisé.
La description doit être légèrement « assertive » — elle doit pousser Claude à utiliser le skill dans tous les cas pertinents. Comparez :
description: Outil pour créer des dashboards. << trop vague
Crée des dashboards interactifs pour visualiser des données internes.
Utiliser dès que l'utilisateur mentionne des dashboards, de la visualisation
de données, des métriques, ou veut afficher n'importe quel type de données
d'entreprise — même sans le mot "dashboard" explicitement.
^ beaucoup plus précis, le contexte est plus riche, moins de devinette de la part du LLM.
Principe 2 : le principe de moindre surprise
Le comportement du skill doit correspondre exactement à ce que sa description promet. Un skill qui fait des choses inattendues crée de la confusion. Si votre description dit « crée des PDFs », le skill ne devrait pas aussi modifier des fichiers Excel sans le mentionner.
Principe 3 : préférez l’impératif dans les instructions
Les instructions doivent être claires et directes :
Il serait bien d'installer les dépendances << trop vague, ce n'est pas un ordre...
"Installer les dépendances avec pip install python-docx --break-system-packages" << précis et impératif
Principe 4 : inclure des exemples
Les exemples sont parmi les éléments les plus puissants d’un skill. Ils ancrent les instructions dans le concret :
## Exemples de messages de commit
Input: "Ajout de l'authentification avec JWT"
Output: feat(auth): implement JWT-based authentication
Input: "Correction du bug d'affichage sur mobile"
Output: fix(ui): resolve display issue on mobile screens
Principe 5 : anticipez les cas limites
Qu’est-ce qui peut mal tourner ? Documentez-le :
## Cas limites et erreurs courantes
- Si le fichier est trop volumineux (>50MB), prévenir l'utilisateur et proposer de traiter par chunks
- Si python-docx n'est pas disponible, l'installer avec --break-system-packages
- Si l'utilisateur ne précise pas de langue, utiliser le français par défaut
Principe 6 : déléguez aux scripts pour les tâches répétitives
Pour des opérations complexes et reproductibles, créez des scripts dans scripts/. Claude peut les exécuter sans même les lire entièrement — ce qui économise du contexte et garantit la cohérence.
## Création du document
Exécuter le script de génération :
```bash
python scripts/generate_report.py --title "$TITRE" --output /mnt/user-data/outputs/
---
## 5. Comment Claude décide d'invoquer un skill
C'est la question que tout créateur de skills se pose : quand est-ce que Claude va réellement utiliser mon skill ?
### Le mécanisme de déclenchement
### Ce qui favorise le déclenchement
- **Des mots-clés dans la requête** qui correspondent à la description du skill
- **La complexité de la tâche** — les tâches multi-étapes déclenchent mieux
- **Une description assertive** qui liste explicitement les déclencheurs
- **Le format de sortie attendu** — si l'utilisateur mentionne ".docx", ".pdf", ".pptx"
### Ce qui empêche le déclenchement
- Description trop vague ou trop générique
- Tâche trop simple (Claude la gère sans aide)
- Mots-clés absents de la description
### Astuce : tester et optimiser
Pour vérifier qu’un skill se déclenche bien, essayez différentes formulations de requête et observez si Claude consulte le skill. Si des requêtes légitimes passent à travers, enrichissez la description avec ces formulations.
Il existe même des outils d’optimisation automatique (comme run_loop.py dans l’outil skill-creator) qui testent la description avec des dizaines de variantes et proposent des améliorations basées sur les résultats.
Les skills par défaut de Claude
Vous avez dû sans doute rencontré ces skills car il les affiche dans la version web : docx, pptx,pdf,xlsx, frontend-design (en tant que dév web je le vois souvent), et skill-creator (un skill puor créer des skills !)
