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 qui manque partout : ces choses n’existent pas au même endroit, et c’est ce qui explique qu’elles ne se comportent pas pareil.

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 le dossier `.claude/rules/`
skill	une fiche réutilisable : du savoir ou une procédure	un fichier `SKILL.md`, dans son propre dossier sous `.claude/skills/`
commande	une instruction qu’on déclenche en tapant `/nom`	soit intégrée à l’outil, soit un fichier dans `.claude/commands/`
subagent	un ouvrier isolé qui travaille à part et ne rend qu’un résumé	un fichier dans `.claude/agents/` ; 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 installes s’appelle un serveur MCP : un programme qui tourne à côté, et à qui il parle
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, hook et subagent en leçon 3, 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.

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 ont changé de nom

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.

Ce que tu lis dans un vieux tutoriel	Ce que ça s’appelle maintenant
headless mode	non-interactive mode — même option, même comportement
custom commands	skills — les anciens fichiers fonctionnent toujours
slash commands	commands, tout court

La deuxième ligne est la plus utile. Il existe des commandes qu’on écrit soi-même, sous forme de fichier ; elles marchent encore, et rien ne presse de les convertir. Mais la documentation dit que les skills en sont le successeur recommandé : un fichier de commande et un skill portant le même nom produisent le même /nom et se comportent pareil. 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 même en nombre. Seuls les noms de ses outils sont chargés au démarrage ; les schémas, 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, mais c’est expérimental et désactivé par défaut ; 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.

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 le mécanisme a été renommé et remplacé — les skills en sont le successeur recommandé, et un skill du même nom produit le même /nom avec le même comportement. L’article n’est pas faux, il est daté. C’est le cas de trois termes au moins : headless mode, custom commands et slash commands ont tous changé d’appellation.

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.