Claude Code : le vocabulaire en une page

Tu veux qu’une vérification se lance à chaque fois, sans avoir à la demander. Tu cherches comment faire. Une réponse te dit d’en faire un « skill ». Une autre dit non, un « hook ». Une troisième parle d’un service à brancher, avec trois lettres.

Tu vas alors à la source, la documentation officielle de Claude Code. Et là, une page te parle de « skills », une autre de « compétences ». Tu passes dix minutes à chercher en quoi les deux diffèrent. Réponse : en rien, c’est le même mot traduit deux fois.

Cette page existe pour ces dix minutes-là.

Ce qui se passe vraiment

Ce n’est pas toi qui apprends mal. Le vocabulaire a trois défauts, et ils s’additionnent.

Les mots ne sont pas de la même espèce. Dans la même liste, on te présente côte à côte un fichier texte, un programme qui s’exécute, un branchement vers l’extérieur, un ouvrier qu’on envoie travailler ailleurs et une trace enregistrée sur ton disque. Neuf mots alignés comme s’il s’agissait de neuf variantes d’une même chose.

Un même mot en cache plusieurs. « Commande » en a trois sens dans la documentation, et rien ne te prévient quand tu passes de l’un à l’autre.

Et le vocabulaire a bougé — assez récemment pour qu’un tutoriel de l’an dernier t’envoie vers un mécanisme qui n’est plus celui qu’on recommande, sans être faux pour autant.

Ce qu’on fait

Rien à installer. Cette page se relit, elle ne se retient pas.

Les neuf mots, et où ils vivent

La colonne de droite est celle qu’on ne lit pas : ces choses n’existent pas au même endroit, et c’est ce qui explique qu’elles ne se comportent pas pareil. Deux emplacements y reviennent. Sous le .claude/ d’un projet, l’objet ne vaut que là, et il part avec le dépôt quand tu le partages. Sous ~/.claude/, ta configuration personnelle, il vaut pour tous tes projets et ne suit personne.

Le mot	En une phrase	Où ça vit
CLAUDE.md	le fichier de règles du projet, relu à chaque session	un fichier texte à la racine de ton projet
rules	des fichiers d’instructions séparés, qu’on peut n’activer que pour certains fichiers	des fichiers dans `.claude/rules/`, ou dans `~/.claude/rules/` pour tous tes projets
skill	une fiche réutilisable, du savoir ou une procédure, qu’on déclenche en tapant `/nom` et que Claude peut aussi lancer tout seul	un `SKILL.md` dans son propre dossier, sous `.claude/skills/` ou `~/.claude/skills/` ; à nom égal, c’est le personnel qui l’emporte
commande	ce qu’on déclenche en tapant `/nom` : une commande intégrée à l’outil, ou un fichier maison, qui est la forme d’avant du skill	intégrée, ou un fichier dans `.claude/commands/` ou `~/.claude/commands/` ; si un skill porte le même nom, c’est le skill qui l’emporte
subagent	un ouvrier isolé qui travaille à part et ne rend qu’un résumé	un fichier dans `.claude/agents/`, ou dans `~/.claude/agents/` pour tous tes projets ; ce qui est à part, c’est sa fenêtre de contexte, pas la session
hook	un déclenchement automatique attaché à un événement	déclaré dans tes réglages ; ce qu’il lance est le plus souvent une commande, mais pas seulement
MCP	le branchement vers un service extérieur, pour Model Context Protocol	ce que tu branches s’appelle un serveur MCP : soit un programme qui tourne sur ta machine, soit un service hébergé ailleurs, qu’on joint par une adresse
plugin	l’emballage qui permet de réutiliser tout ça ailleurs	un paquet installable, distribué par un marketplace
checkpoint	un point de restauration créé à chaque message envoyé	une trace sur ton disque, à côté de la conversation

Cinq d’entre eux ont déjà servi : CLAUDE.md, skill et hook en leçon 3, subagent et checkpoint en leçon 2. Ce qui suit ne les redéfinit pas — et ce que chacun devient quand la mémoire de travail sature est traité en leçon 3, qui en donne le tableau complet.

Savoir ce qu’est un mot ne dit pas quand s’en servir. C’est la leçon 5, et c’est un autre savoir-faire : on n’ajoute rien tant que le déclencheur ne s’est pas présenté.

Le piège que personne ne peut documenter

Voici pourquoi tu as perdu dix minutes tout à l’heure. La documentation officielle emploie deux vocabulaires selon la page que tu ouvres. C’est vérifiable en deux clics :

Le mot	Dans le glossaire officiel	Dans la page sur la fenêtre de contexte
skill	skill	« compétences »
subagent	subagent	« sous-agent »
token	renvoyé à un autre glossaire	« jetons »

C’est le même mot, la même chose, deux traductions. Le glossaire garde l’anglais pour presque tout : hook, plugin, checkpoint, command, rules, session. D’autres pages traduisent.

Piège — quand une page francophone te parle de « compétences », de « sous-agents » ou de « jetons », traduis mentalement en skills, subagents, tokens. Ce sont les mots que tu verras sur ton écran, dans les noms de dossiers et dans les messages d’erreur. C’est exactement pour ça que ce parcours garde les termes anglais : une traduction, même officielle, te coupe de ce que tu as sous les yeux.

Aucune documentation ne peut t’avertir de ça : elle ne documente pas ses propres écarts de traduction. C’est la raison d’être de cette page.

Le mot « commande » en cache trois

Trois sens, et deux d’entre eux n’ont rien à voir avec le premier :

Ce que tu tapes dans la zone de saisie : /clear, /compact. C’est le sens du tableau ci-dessus.
Les sous-commandes du programme, tapées dans ton terminal : claude mcp add.
Le champ command d’un service branché, qui désigne le programme à lancer. Ni une instruction que tu tapes, ni une sous-commande : un chemin vers un exécutable. Il ne sert qu’au service qui tourne sur ta machine ; celui qui est hébergé ailleurs se déclare avec une adresse, et n’a pas de champ command.

S’y ajoute, en dehors de tout produit, l’usage ordinaire du mot en informatique : une ligne tapée dans un terminal.

Le tri se fait sur une seule question : où on te demande d’écrire. Zone de saisie, terminal, ou fichier de configuration. Trois endroits, trois choses.

Trois mots ne se disent plus pareil

Ce n’est pas de la coquetterie : c’est ce qui explique qu’un conseil trouvé en ligne puisse être exact et périmé en même temps. Deux sont de simples renommages. Le troisième non, et c’est celui qui compte.

Ce que tu lis dans un vieux tutoriel	Ce que c’est aujourd’hui
headless mode	non-interactive mode — renommage, même option, même comportement
slash commands	commands, tout court — renommage
custom commands	skills — pas un renommage : les deux ont fusionné en un seul objet, les anciens fichiers fonctionnent toujours, et à nom égal c’est le skill qui l’emporte

La dernière ligne est la plus utile, et c’est aussi celle qu’on lit de travers. Un skill et une commande maison ne sont pas deux mécanismes dont l’un remplacerait l’autre : la documentation écrit qu’ils ont été fusionnés. .claude/commands/deploy.md et .claude/skills/deploy/SKILL.md produisent tous les deux /deploy et se comportent pareil ; les anciens fichiers marchent encore, et rien ne presse de les convertir. Ce qu’un skill ajoute par-dessus, c’est de pouvoir partir tout seul quand la situation s’y prête, un dossier pour ses fichiers annexes, et un en-tête qui règle qui a le droit de le déclencher. Les skills en sont le successeur recommandé, et quand les deux existent sous le même nom, c’est le skill qui l’emporte. Autrement dit, quand un article te dit d’écrire une commande, il n’a pas tort — il a un an.

Ce qui coûte, ce n’est presque jamais la chose elle-même

La leçon 3 a posé le plan de travail et a dit où part la place : dans les fichiers qu’il lit. Ça reste vrai, et ça change la façon de raisonner sur ces neuf mots.

Pris un par un, ces mécanismes ne coûtent presque rien. Un fichier de règles, la description d’un skill, les noms d’outils d’un service branché : additionnés, on parle de quelques pour cent de la place disponible, quand une seule lecture de fichier peut peser plus qu’un fichier de règles entier.

Pour la plupart d’entre eux, ce qui compte ensuite, c’est combien tu en as. Une poignée de skills ne se remarque pas ; une bibliothèque entière, si — leurs descriptions sont relues à chaque requête. Et le vrai coût n’est d’ailleurs pas la place : c’est le bruit. Une consigne noyée parmi cent autres est moins bien suivie qu’une consigne seule.

Trois mécanismes échappent à ce calcul, chacun à sa façon, et c’est ce qui les rend précieux — aucun des trois n’étant gratuit pour autant :

Le service branché reste discret, mais pas gratuit. Au démarrage se chargent les noms de ses outils et les instructions du serveur, ces dernières jusqu’à 2 Ko chacune : c’est la part qui grandit avec le nombre de services branchés, et c’est pourquoi on retire ceux dont on ne se sert plus. Les schémas des outils, eux, restent différés tant qu’aucun outil n’est utilisé, sauf configurations qui n’en bénéficient pas : adresse d’API personnalisée, mécanisme désactivé, certaines plateformes cloud.
Le subagent travaille dans sa fenêtre, pas dans la tienne. Attention, il ne coûte pas zéro : ce qui remonte chez toi, c’est l’ordre de mission et le résumé — quelques centaines de tokens, là où lui en a lu des milliers. L’économie est réelle, elle n’est pas totale.
Le hook ne coûte rien du tout, sauf s’il te renvoie du texte : c’est un programme extérieur, pas du contexte.

Skill ou subagent : la confusion la plus fréquente

Elle se règle par une phrase : le skill s’ajoute à ta fenêtre, le subagent utilise la sienne.

Un skill est du contenu réutilisable qu’on charge dans un contexte — le tien. Un subagent est un ouvrier isolé : il travaille à part, lit ce qu’il a à lire, et ne te rend qu’un résumé. Ils ne sont pas concurrents : un subagent peut d’ailleurs précharger des skills.

Deuxième confusion, plus rare : un subagent n’est pas une session. Une session, c’est une conversation liée à ton dossier, avec sa propre fenêtre — celle que tu ouvres en lançant l’outil. Un subagent vit à l’intérieur d’une session et ne rend compte qu’à elle. Faire travailler ensemble plusieurs sessions complètes existe aussi, sous deux formes qui ne se valent pas : les équipes de sessions, coordonnées, expérimentales et désactivées par défaut ; et la messagerie entre sessions, qui est active sans rien à activer dès que la version et la plateforme le permettent (2.1.224 sur macOS et Linux, 2.1.234 sur Windows natif). C’est le sujet de la leçon 15.

Ce que ça ne fait pas

Une définition ne promet aucune obéissance. Savoir qu’un fichier de règles est rechargé à chaque session ne dit pas qu’il sera suivi : c’est du contexte, pas un réglage appliqué. La documentation écrit qu’il n’y a « aucune garantie de conformité stricte, surtout pour les instructions vagues ou conflictuelles ». Ce qui s’applique vraiment, quoi que le modèle décide, ce sont les autorisations, les réglages imposés par une organisation, le bac à sable et les hooks — et un hook lui-même ne peut que resserrer ce que les autorisations permettent, jamais l’élargir.

Les notions tiennent, les valeurs bougent. Ce qui est stable, c’est de savoir qu’il existe un contexte, une mémoire, des autorisations, des déclencheurs. Les valeurs par défaut se revérifient le jour où tu t’en sers : l’outil est remanié plusieurs fois par semaine, retours en arrière compris. Cette page vieillira ; les noms de dossiers, moins vite que les chiffres.

Un mot d’ici n’est pas défini par la documentation de Claude Code : « token ». Elle renvoie ailleurs. La glose qu’on emploie (l’unité dans laquelle se compte la place occupée, un morceau de mot plutôt qu’un mot) est la nôtre, et elle est approximative par construction. Ne convertis jamais un nombre de tokens en nombre de mots.

Cette page ne remplace pas le glossaire officiel. Il contient bien plus que neuf mots, il est maintenu, et il tranche les désaccords. Ce que tu as ici, c’est ce qu’il ne peut pas dire.

Où c’est écrit

Glossaire — les définitions, et la table officielle des termes qui ont changé de nom ;
Explorer la fenêtre de contexte — ce que chaque mécanisme charge, et à quel moment ;
Démarrer avec MCP — les deux formes de serveur, celle qui tourne sur ta machine et celle qu’on joint par une adresse.

Ces liens pointent vers les pages anglaises. La version française existe : remplace /en/ par /fr/. Mais c’est elle qui porte les deux vocabulaires dont parle cette page, et il lui manque encore des passages, dont celui qui signale les autres sens du mot « commande ».

Le point de bascule

Le signe est une non-réaction. Devant une page qui te parle de « compétences », tu ne cherches plus en quoi ça diffère d’un skill : tu traduis, et tu continues.

Vérifier que c’est passé

Un article de blog de l'an dernier t'explique comment écrire une « custom command ». Tu suis, ou tu cherches plus récent ?

Tu peux suivre : les anciens fichiers de commandes fonctionnent toujours. Mais sache que les les deux ont fusionné en un seul objet, dont le skill est la forme actuelle : un fichier de commande et un skill du même nom produisent le même /nom, avec le même comportement. Un détail qui compte le jour où tu convertis : si les deux coexistent, c’est le skill qui l’emporte. L’article n’est pas faux, il est daté. Trois termes au moins sont dans ce cas — mais pas de la même façon : headless mode et slash commands ont simplement changé de nom, tandis que les custom commands ont fusionné dans autre chose.

Une tâche annexe va lui faire ouvrir quarante fichiers, et tu ne veux que la conclusion. Skill ou subagent ?

Subagent. La règle tient en une phrase : le skill s’ajoute à ta fenêtre, le subagent utilise la sienne. Ici, ce que tu veux éviter, c’est que quarante fichiers viennent occuper ton plan de travail pour une tâche dont tu ne liras pas le détail. Un skill ferait l’inverse. Précision utile : le subagent ne te coûte pas rien pour autant — son résumé remonte chez toi.

On te conseille : « écris-le dans tes règles, comme ça il le fera à chaque fois. » Qu'est-ce qui cloche ?

Le « à chaque fois ». Un fichier de règles est du contexte, pas un réglage appliqué, et la documentation dit qu’il n’y a aucune garantie de conformité stricte. Ce qui s’exécute quoi qu’il arrive, ce sont les autorisations que tu as posées, les réglages imposés par ton organisation, le bac à sable, et les hooks. Écrire la consigne dans tes règles reste utile — c’est simplement une consigne, pas une barrière.