Claude Code Skills : ce que c'est, ce que ça coûte

Fait partie du pilier réduire l'usage des tokens dans Claude Code, qui couvre tous les leviers qui font bouger la facture. Cette page est plus étroite : ce que skills et plugins ajoutent à votre contexte, et pourquoi ils sont rarement la raison pour laquelle il est plein.

Qu'est-ce qu'un skill Claude Code ?

Un skill est un fichier markdown qui apprend à Claude Code comment faire un travail précis, et qu'il invoque ensuite de lui-même quand la tâche correspond. Vous écrivez un SKILL.md, vous le posez dans un dossier, et à partir de là Claude peut s'en saisir sans que vous le demandiez — c'est toute l'idée, et c'est ce qui sépare un skill d'une slash command qu'il faut penser à taper. Concrètement, un skill est un répertoire contenant un SKILL.md obligatoire et les fichiers dont il a besoin (templates, exemples, scripts). Il vit à l'un de ces trois endroits :

.claude/skills/<nom>/SKILL.md — portée projet, versionnée avec le dépôt
~/.claude/skills/<nom>/SKILL.md — portée personnelle, vous suit d'un projet à l'autre
<plugin>/skills/<nom>/SKILL.md — embarqué dans un plugin, nommé /plugin:skill

Le fichier, c'est du frontmatter YAML plus des instructions markdown. Les champs à connaître :

Champ	Rôle
`name`	L'identifiant du skill
`description`	Quand Claude doit l'utiliser — c'est la partie qui occupe votre contexte
`disable-model-invocation`	À `true`, Claude ne le choisit plus seul ; vous l'invoquez vous-même
`user-invocable`	À `false`, il disparaît du menu `/`
`allowed-tools`	Outils pré-autorisés pour ce skill, révoqués à la fin
`hooks`	Gestionnaires d'événements en ligne (PreToolUse, PostToolUse…)

À quoi ressemble un skill, concrètement ?

À moins que vous ne l'imaginez. En voici un complet et fonctionnel — .claude/skills/release-notes/SKILL.md :

---
name: release-notes
description: >
Rédige les notes de version à partir des commits depuis le dernier tag.
À utiliser quand on demande un changelog, des notes de version, ou
« qu'est-ce qui est parti en prod ».
allowed-tools: Bash(git log:), Bash(git tag:)
---

Lis les commits depuis le tag le plus récent avec `git log <tag>..HEAD --oneline`.

Regroupe-les sous Ajouté / Modifié / Corrigé. Ignore les commits de merge et
tout ce qui ne touche que la configuration CI — ce n'est pas une nouvelle
pour un utilisateur.

Écris au passé, une ligne par changement, sans hash de commit. Si un
changement est visible par l'utilisateur, commence par ce qu'il peut
désormais faire, pas par ce que fait le code.

C'est tout le fichier. Aucune étape d'enregistrement, aucune configuration à éditer — Claude le récupère depuis le répertoire. Deux choses sont faites volontairement dans cet exemple. La description énonce les conditions de déclenchement (« quand on demande un changelog… ») et non l'implémentation, puisque ce champ est tout ce dont Claude dispose pour décider. Et allowed-tools restreint la portée à deux commandes git en lecture seule : un skill qui rédige du texte ne peut pas partir se promener dans votre arbre de travail.

Comment Claude décide-t-il d'utiliser un skill ?

Il lit le champ description et juge si elle colle à la tâche en cours. C'est le mécanisme, et il a une conséquence qu'on rate souvent : pour que Claude puisse choisir un skill, il faut qu'il sache qu'il existe — donc la description de chaque skill est chargée dans votre contexte au démarrage de la session. Ce qui fait de la rédaction de la description tout le métier d'auteur de skill. Comparez :

# Claude choisira celui-ci pour tout, ou pour rien
description: Aide sur les bases de données.

# Sur celui-ci, Claude peut réellement décider
description: >
Écrire et relire des migrations Postgres. À utiliser quand l'utilisateur
ajoute une colonne, change un type, ou demande si une migration passe
sans risque sur une table en production.

Le second nomme des situations, pas des capacités. C'est toute la différence entre un skill qui se déclenche quand vous en avez besoin et un skill que vous finissez par invoquer à la main — et si vous l'invoquez à la main, c'est une slash command que vous vouliez. Le contenu complet du skill, lui, ne l'est pas. Il ne se charge qu'à l'invocation. Anthropic documente explicitement ce chargement différé comme une mesure d'efficacité de contexte, et c'est la bonne conception : vous payez un petit coût permanent pour la découvrabilité, et le gros coût seulement à l'usage. Soyons précis sur ce qui est documenté et ce qui ne l'est pas. Le chargement différé l'est. Le raisonnement exact par lequel Claude préfère un skill à un autre ne l'est pas — ça se passe dans le modèle, et quiconque prétend avoir rétro-conçu l'heuristique devine. Et je n'ai trouvé aucun chiffre publié sur le coût réel en tokens d'une description de skill : c'est du markdown court, donc c'est petit, mais « petit » n'est pas un nombre et je préfère le dire plutôt que d'en inventer un.

Skills, plugins, MCP, hooks : quelle différence ?

C'est là que se concentre la confusion, alors voici la version en une ligne :

Élément	Ce que c'est	À utiliser quand
Skill	Des instructions que Claude découvre et invoque seul	Vous voulez que Claude choisisse un workflow sans qu'on le lui dise
Plugin	Un bundle versionné de skills, agents, hooks et serveurs MCP	Vous partagez des extensions dans une équipe ou entre dépôts
Serveur MCP	Une intégration exposant des outils externes (GitHub, Postgres…)	Claude doit appeler un service qui n'est pas à vous
Hook	Une commande déclenchée autour des actions de Claude	Vous voulez automatiser autour du travail — linter après édition, charger des secrets au démarrage
Subagent	Un agent isolé avec son propre contexte et ses outils	Une sous-tâche gonflerait sinon votre conversation principale
Slash command	Une invocation fixe et directe	Vous voulez un bouton, pas une décision

La distinction utile : un skill, c'est ce que Claude choisit ; une slash command, ce que vous déclenchez ; un hook, ce qui part que quelqu'un l'ait choisi ou non.

Qu'est-ce qu'un plugin Claude Code ?

Un plugin est un répertoire autonome et versionné qui regroupe des extensions pour qu'elles soient partageables et suivies en version — ce que des fichiers .claude/ épars ne permettent pas. Un seul plugin peut porter des skills, des agents personnalisés, des hooks, des serveurs MCP, des serveurs LSP, des moniteurs de fond, des styles de sortie, des réglages par défaut, et des binaires ajoutés au PATH du Bash. Il s'identifie par un manifeste .claude-plugin/plugin.json :

{
"name": "identifiant-unique",
"description": "Ce que fait ce plugin",
"version": "1.0.0",
"author": { "name": "Votre nom" }
}

L'installer tient en deux étapes — ajouter une marketplace, puis installer depuis celle-ci :

/plugin marketplace add anthropics/claude-plugins-community
/plugin install <nom>@<nom-marketplace>
/reload-plugins

Une marketplace n'est qu'un catalogue : un dépôt git, un répertoire local ou une URL hébergeant un marketplace.json. Anthropic maintient une marketplace officielle curatée, claude-plugins-official (disponible d'office), et une communautaire filtrée, claude-plugins-community. Vous pouvez héberger la vôtre pour une équipe — c'est d'ailleurs la vraie raison d'être des plugins : la distribution, pas la capacité.

Ce que skills et plugins coûtent en contexte

Voici la partie qui compte si vous surveillez votre facture ou votre quota, et c'est plutôt une bonne nouvelle, avec une réserve. Les skills sont peu coûteux par conception. Descriptions au démarrage, contenu à la demande. Installez vingt skills et vous payez vingt descriptions courtes, pas vingt playbooks complets. Les plugins sont compatibles avec le cache. Skills, agents, hooks et thèmes issus d'un plugin sont ajoutés après le préfixe de prompt mis en cache : activer ou désactiver un plugin n'invalide donc pas votre cache. C'est plus important qu'il n'y paraît — une invalidation de cache, c'est repayer plein tarif un contexte déjà acheté. Les serveurs MCP sont l'exception, et la réserve. Sur les modèles compatibles, les outils MCP sont différés par défaut : seuls les noms d'outils occupent le contexte, les définitions complètes se chargent à l'usage. C'est sûr pour le cache. Mais quand ce différé n'est pas disponible (certains fournisseurs et passerelles personnalisées ne gèrent pas la recherche d'outils), chaque définition atterrit dans le system prompt. C'est à la fois cher et invalidant pour le cache : connecter ou déconnecter un tel serveur force une reconstruction. D'où la hiérarchie pratique, du moins cher au plus cher : skills et hooks sont quasi gratuits, les plugins sont gratuits à activer/désactiver, et les serveurs MCP sont ce qu'il faut auditer — surtout si vous en avez connecté plusieurs sans jamais vérifier s'ils différaient. Le coût permanent est réel mais petit. Le coût qui apparaît vraiment sur votre facture est ailleurs : les fichiers que votre agent lit, les sorties de commandes qu'il avale entières, et la conversation rejouée à chaque tour. Un simple « corrige ce test » fait quarante tokens de vos mots et des dizaines de milliers de tokens de contexte. Aucune hygiène de skills ne touche à ça.

Comment appliquer ça dès aujourd'hui

Écrivez des skills, pas des slash commands, pour tout ce qui est répétitif. Si vous devez penser à la taper, vous ne le ferez pas un jour de fatigue. La description est toute l'interface.
Gardez les descriptions serrées. C'est la partie résidente en permanence. Une phrase claire sur quand utiliser le skill vaut mieux qu'un paragraphe sur ce qu'il fait.
Passez disable-model-invocation: true sur les skills que vous ne lancez qu'à la main. Ça retire complètement la description de la vue de Claude — le seul levier qui supprime le coût permanent.
Auditez vos serveurs MCP avant vos skills. C'est là que part réellement le contexte. Déconnectez ceux que vous avez branchés une fois puis oubliés.
Puis attaquez la vraie facture. Comment réduire l'usage des tokens de Claude Code couvre les leviers qui déplacent le chiffre : récupération plutôt que lectures de fichiers entiers, filtrage des sorties verbeuses, structure avant les corps.

Si vous préférez ne pas faire l'étape 5 à la main, c'est ce que fait Tokenade : il se place entre l'agent et ses outils et applique ces leviers automatiquement, y compris le repliement des résultats MCP tiers à la frontière. Sur le benchmark ouvert des optimiseurs de tokens, il réduit le coût de 39 % sur les longues sessions par rapport à l'absence d'outil.

Ce qui cloche en pratique (anti-patterns)

Écrire un skill à la description vague. Claude sélectionne sur la seule description. « Aide pour les tests » sera choisi pour tout ou pour rien. Installer des plugins qu'on n'utilise pas. Peu coûteux ne veut pas dire gratuit, et chaque description de skill est résidente. Une liste /plugin propre vaut dix minutes par trimestre. Accuser les skills d'une grosse facture. Ce n'est pas le bon suspect. Regardez ce que votre agent lit avant d'auditer ce qu'il charge. Supposer que tous les serveurs MCP différent leurs outils. Ça dépend du modèle et du fournisseur. Si votre contexte s'alourdit après avoir connecté un serveur, c'est la première chose à tester.

À voir aussi :

Meilleurs serveurs MCP pour Claude Code — ceux qui valent le contexte qu'ils prennent
Usage des outils MCP économe en tokens — réduire spécifiquement le coût des manifestes
Le prix de Claude Code — de quoi la facture est réellement faite
Les limites d'usage de Claude expliquées — pourquoi le plafond arrive plus tôt que prévu

Sources : Skills · Plugins · Marketplaces de plugins · Prompt caching et chargement du contexte · Comment fonctionne Claude Code