Les huit moments où on ajoute quelque chose

Tu as passé la semaine à corriger les mêmes choses : le format des dates, la commande pour lancer les tests, le dossier auquel Claude ne devait pas toucher. Tu sais qu’il existe des mécanismes pour que ça tienne tout seul — on t’en a listé sept ou huit, tu sais même à peu près ce que fait chacun. Ce que tu ne sais pas, c’est lequel, pour toi, maintenant.

Et il y a la version pire du même problème : un dimanche entier passé à tout configurer, et le lundi, tu n’ouvres rien de ce que tu as monté.

Ce qui se passe vraiment

Tu poses la question par outil, et elle ne se règle pas comme ça. « À quoi sert un hook ? » n’a pas de réponse utile : ça sert à plein de choses, dont aucune n’est ton problème de mardi. La documentation officielle range d’ailleurs ces mécanismes de deux façons sur la même page. Un catalogue, fonctionnalité par fonctionnalité — utile quand on sait déjà ce qu’on cherche. Et une liste de moments, avec en face ce qu’on ajoute quand ce moment arrive. C’est la seconde qui sert.

Un atelier n’est pas un décor vide qu’on garnit. Le tien fournit déjà l’établi, les outils courants et les règles de sécurité, et c’est lui qui filtre ce que l’artisan a le droit de faire — c’est l’image posée en leçon 1. Ce qui s’y ajoute au fil du temps, ce sont les outils spécialisés. Ceux-là ne s’achètent pas d’avance : l’outil arrive quand le geste s’est répété assez souvent pour le payer, et il prend sa place au mur parce qu’on sait déjà où le ranger.

Ce qui paie l’outil, c’est donc la répétition, et elle se compte. C’est la partie que tout le monde escamote en écrivant « quand ça se répète ». La documentation, elle, donne des nombres — le premier suffit à comprendre la mécanique, les autres sont dans le tableau plus bas : Claude se trompe deux fois sur la même convention, et c’est le seuil de la première ligne. Pas une fois. Une erreur unique ne mérite pas de mécanisme ; la deuxième dit que ce n’était pas un accident. Une réserve au passage, et elle change qui doit compter : ces seuils sont des compteurs personnels. « Deux fois » veut dire deux fois pour toi. À plusieurs sur le même dépôt, le compteur ne s’additionne pas tout seul, et c’est la revue de code qui joue son rôle.

À retenir — on ne configure pas tout d’avance. Une seule chose se pose sans attendre : le fichier de règles du projet. Tout le reste attend qu’un moment précis se présente, et ces moments se comptent.

Ce qu’on fait

La seule chose qui ne demande pas de déclencheur

La documentation est explicite pour qui débute : commence par le CLAUDE.md, le fichier de règles du projet, relu à chaque session. Mets-y les conventions du projet, puis ajoute le reste au fur et à mesure que les déclencheurs se présentent.

Le geste est en leçon 3 : /init te le crée s’il n’existe pas. Son arbitrage aussi, et il vaut la peine d’être déplié ici. Posé à la racine du projet, ce fichier est relu depuis le disque à chaque session et après chaque résumé automatique du contexte : c’est ce que tu achètes. Ce que tu paies : à chaque requête, il occupe de la place dans la fenêtre de contexte, le plan de travail de la leçon 3 — ce qui n’est pas dessus n’existe pas pour lui. Et plus il est long, moins chaque ligne est suivie.

D’où la nuance qui articule les deux faits : le fichier existe dès le premier jour, son contenu, lui, grossit par déclencheur. On n’y verse pas tout ce qu’on imagine utile ; on y écrit la convention le jour où elle a été ratée deux fois.

Les huit moments

Le tableau ci-dessous est celui de la documentation officielle, dans son ordre. Cet ordre est celui dans lequel, selon la source, la plupart des équipes ajoutent ces mécanismes — autrement dit un ordre d’arrivée constaté, pas une marche à suivre. Lis la colonne de gauche en pensant à ta semaine, pas à ton projet idéal.

Le moment que tu reconnais	Ce que tu ajoutes
Il se trompe deux fois sur la même convention ou la même commande	une ligne dans le fichier de règles
Tu retapes le même prompt pour démarrer une tâche	un skill que tu déclenches toi-même
Tu recolles la même procédure pour la troisième fois	un skill
Tu copies des données depuis un onglet qu’il ne voit pas	un branchement MCP
Il lit beaucoup de fichiers pour trouver où un symbole est défini ou utilisé	l’intelligence de code de ton langage (elle s’installe sous forme de plugin)
Une tâche annexe noie ta conversation d’une sortie que tu ne reliras pas	un subagent
Tu veux que ça arrive à chaque fois, sans le demander	un hook
Un deuxième dépôt a besoin du même réglage	un plugin

Les mots de la colonne de droite ont été définis en leçon 4 — sauf l’intelligence de code, qui est une des cinq familles d’outils de la leçon 3. Rappel en une ligne chacun, pour ne pas avoir à changer de page :

• le skill : une fiche réutilisable, du savoir ou une procédure ;
• le subagent : un ouvrier isolé qui travaille à part et ne rend qu’un résumé — l’assistant qu’on envoie aux archives, qui lit trois cartons et revient avec une fiche ;
• le hook : un déclenchement automatique attaché à un événement ;
• le MCP : le branchement vers un service extérieur — le seul de la liste qui fasse entrer dans ta boucle du contenu que personne n’a écrit pour toi, et c’est de là que vient le risque dont la leçon 10 fait son sujet. Faire entrer un programme que tu n’as pas écrit, en revanche, n’a rien d’exclusif : la documentation prévient qu’un plugin peut exécuter n’importe quel code sur ta machine avec tes privilèges d’utilisateur, et qu’Anthropic ne peut pas vérifier qu’il fait ce qu’il annonce. Deux versants d’une même question, et dans les deux cas l’ajout se décide sur la confiance autant que sur le besoin ;
• le plugin : l’emballage, glosé en leçon 3 — c’est ce qui fait voyager tout le reste d’un dépôt à l’autre ;
• l’intelligence de code (code intelligence dans la documentation) : la famille d’outils qui sait où un symbole est défini et qui l’utilise — la seule qui ne soit pas fournie d’office, et qui se paie en deux installations, comme l’a dit la leçon 3. Les deux, pour qu’on ne t’envoie pas au mur : le plugin de ton langage, et le serveur de langage correspondant, qui s’installe à part et que le plugin n’installe pas pour toi.

Huit moments, sept mécanismes

Le tableau a huit lignes et sept réponses distinctes : les deux répétitions mènent toutes les deux à un skill. Ce n’est pas un détail de comptage, c’est ce qui empêche de chercher un huitième mécanisme qui n’existe pas.

Mais ce n’est pas le même skill, et la documentation les distingue en un mot. Le premier est un skill que tu déclenches toi-même : tu tapes son nom, il fait ce que tu retapais à la main. Le second est une procédure que Claude peut charger de lui-même quand elle devient pertinente. Ce qui sépare les deux tient dans une ligne posée en tête du fichier du skill, disable-model-invocation. Mise à true, elle réserve le déclenchement à toi seul, et /skills affiche alors une étiquette user-only à côté du nom. La documentation en donne deux motifs dans la même phrase : l’économie de contexte, et le contrôle des effets de bord. Le premier est marginal ; le second est la vraie raison — ne pas laisser Claude décider tout seul de déployer parce que le code a l’air prêt. L’écriture de ces fiches est le sujet de la leçon 9.

Le mot plugin apparaît à deux lignes, et ce ne sont pas les mêmes gestes. À la cinquième, tu installes celui de quelqu’un d’autre pour avoir l’intelligence de code de ton langage — c’est le mécanisme qui compte, le plugin n’est que son emballage. Ce jour-là, deux programmes tiers entrent chez toi, le plugin puis son serveur de langage : c’est le versant code de la question posée plus haut, et elle se tranche sur la source, avant d’installer. À la huitième, tu fabriques le tien.

Piège — le déclencheur du plugin n’est pas « je voudrais partager ça ». C’est un deuxième dépôt qui a besoin du même réglage. Tant que tu n’as qu’un projet, ce que tu as posé dans son dossier de configuration fait déjà le travail. Publier, distribuer, passer par un marketplace : autre sujet, autre moment.

La seule ligne qui ne dépend pas de ce que Claude décide

C’est la lecture du tableau qui compte pour la suite du parcours, et elle tient en une opposition :

• « Tu veux que ça arrive à chaque fois, sans le demander » est la ligne du hook. Un hook se déclenche sur son événement, que le modèle l’ait voulu ou non — la documentation parle d’un déclenchement garanti ;
• écrire la même chose dans le fichier de règles ou dans un skill produit du contexte : Claude le lit et l’interprète. La formule officielle vise nommément ces deux endroits : une instruction comme « ne touche jamais à .env » écrite dans un CLAUDE.md ou dans un skill est une demande, pas une garantie. Et pour ce cas-là précisément, il existe mieux que les deux : un refus de lecture, une ligne, qui bloque au lieu de demander — c’est la leçon 8.

Deux réserves, sans lesquelles la ligne du hook devient une promesse nue — exactement ce que cette leçon reproche aux listes de fonctionnalités. La première : ce qui est garanti, c’est le déclenchement, pas le résultat. La seconde : un hook mal câblé ne se déclenche pas du tout. Un chemin de script mal tapé « laisse la barrière silencieusement désactivée », écrit la documentation. Mais il affiche bien un avertissement d’échec, encore faut-il le voir passer. Le cas réellement muet est ailleurs : un nom d’outil mal orthographié dans la condition de déclenchement ne correspond à rien, et le hook « échoue silencieusement ». Un garde-fou qu’on croit posé et qui ne tourne pas est le sujet entier de la leçon 13.

Et le hook n’est pas le seul mécanisme d’application qui existe : les règles d’autorisation, sujet de la leçon 8, en sont un autre, et le hook leur est subordonné — il peut resserrer ce qu’elles permettent, jamais l’élargir. Il est simplement le seul à figurer dans ce tableau-ci.

Le même tableau sert à réparer l’existant

C’est l’usage le plus rentable et le moins connu. Les déclencheurs ne disent pas seulement quand ajouter, ils disent quand mettre à jour ce que tu as déjà :

• une erreur qui revient, ou une remarque que tu refais à chaque relecture, est une ligne à modifier dans le fichier de règles — pas une correction de plus dans la conversation ;
• une procédure que tu retouches à la main à chaque fois est un skill qui a besoin d’une révision.

Une question de diagnostic avant d’écrire, parce que sans elle la première ligne du tableau se retourne : est-ce qu’il a raté cette convention parce qu’elle n’est écrite nulle part, ou parce qu’elle est noyée ? La documentation liste trois causes de baisse d’adhérence — une instruction qu’on peut interpréter de plusieurs façons, deux fichiers qui se contredisent, et un fichier devenu assez long pour que chaque règle reçoive moins d’attention. Dans les deux derniers cas, ajouter une ligne aggrave le problème.

Et le geste concret, si tu veux commencer aujourd’hui : ne tiens pas un carnet. Un compteur manuel tenu sur une semaine est exactement le genre de discipline qui ne survit pas à un mardi chargé. Demande plutôt à Claude, en fin de session, ce que tu lui as corrigé deux fois dans la journée : la conversation fait office de compteur, à une réserve près. Si la session a été compactée, le résumé automatique du contexte vu en leçon 3 a remplacé le fil par un résumé structuré, et sa réponse ne portera plus que sur ce que ce résumé a gardé. Sur une longue journée, pose la question plus tôt, ou recoupe avec ce qui suit. Et lance /insights une fois de temps en temps : il produit un rapport à partir de tes sessions passées sur cette machine — dans quels projets tu travailles, comment tu t’en sers, où ça coince. C’est le seul instrument qui regarde la bonne fenêtre : un seuil « deux fois » ne se constate pas dans la session en cours, il se constate sur les semaines écoulées. Il n’est pas disponible en session cloud. Passe aussi /doctor sur ta configuration : ce contrôle intégré signale les skills, serveurs MCP et plugins que tu n’utilises pas au regard de ce qu’ils coûtent en contexte, et propose d’élaguer d’un fichier de règles versionné ce que Claude peut déduire du code tout seul, cette vérification-là à partir de la version 2.1.206. Il rapporte d’abord et ne change rien sans que tu confirmes.

Vérifier que ce que tu as ajouté est vivant

Une chose ajoutée n’est pas une chose active, et c’est vrai dès le premier jour. Tout ce qui suit se tape dans la zone de saisie de Claude Code, là où tu écris tes demandes, comme /init en leçon 3. Et /context vient en premier : il dit ce qui occupe réellement la fenêtre de contexte, et la documentation le désigne comme le premier geste — ton CLAUDE.md, tes fichiers de rules (les instructions rangées à part, vues en leçon 4), les descriptions de tes skills. Si ce que tu viens de poser n’y figure pas, il n’existe pas pour lui.

Avec une exception qui tombe pile sur le premier mécanisme que ce tableau recommande : un skill que tu es seul à pouvoir déclencher n’apparaît jamais dans /context. C’est écrit noir sur blanc — ces skills « restent complètement hors du contexte jusqu’à ce que tu les invoques par /nom ». Leur absence ne prouve rien. Pour eux, comme pour le détail de chaque mécanisme, c’est la commande dédiée qui répond : /skills, /hooks, /mcp.

Trois pannes reviennent :

• un skill posé en fichier (.claude/skills/nom.md) au lieu d’un dossier contenant son SKILL.md : .claude/skills/nom/SKILL.md. Il n’apparaît pas dans /skills. Attention à ne pas généraliser : un fichier seul fonctionne ailleurs, .claude/commands/nom.md produit bien un /nom ;
• des hooks écrits dans un fichier à eux ne se déclenchent jamais. Dans ton projet ou ta configuration personnelle, ils vivent sous la clé hooks d’un fichier de réglages, et il n’existe pas de fichier de hooks autonome. Un plugin, lui, a bien le sien (hooks/hooks.json) — et un skill ou un subagent peut en déclarer dans son en-tête ;
• un dossier de skills de premier niveau créé après le lancement de la session n’est pas surveillé : c’est le cas de ton tout premier skill. La page des skills dit de redémarrer. Il existe aussi une commande dédiée, /reload-skills, qui rebalaie les dossiers de skills et de commandes sans redémarrer — essaie-la d’abord.

Le reste est pris en compte à chaud, avec deux limites. La détection à chaud ne couvre que le texte du SKILL.md — pour un dossier de skill qui est aussi un plugin, ses hooks, son .mcp.json et ses subagents demandent /reload-plugins. Et les skills rangés dans des sous-dossiers plus bas que ton point de départ ne sont pas chargés au lancement : ils arrivent la première fois que Claude lit ou modifie un fichier de ce sous-dossier.

Dans ces trois cas, le symptôme documenté est une absence — la chose n’apparaît pas, le hook ne se déclenche pas. Pas un message d’erreur : c’est à toi d’aller regarder. Tout ne se passe pas en silence, cela dit : un fichier de réglages invalide, lui, provoque bien un avertissement et se voit dans /doctor. C’est exactement le sujet de la leçon 13 : un dispositif qu’on ne vérifie pas n’existe pas.

Ce que ça ne fait pas

Ce n’est pas une liste à cocher. Huit lignes alignées donnent envie d’y passer un week-end, et c’est le contresens le plus coûteux : tu aurais huit mécanismes montés pour des problèmes que tu n’as pas, dans un projet que tu connais moins bien qu’eux.

Le tableau ne recense pas tout ce qui existe. Le catalogue de la même page compte le même nombre d’entrées, huit de chaque côté, mais ce ne sont pas les mêmes. Trois écarts, vérifiables en comptant, et ce n’est pas une erreur : tout ce qui existe n’a pas de moment reconnaissable.

• les équipes de sessions figurent au catalogue sans avoir de moment. Elles sont expérimentales et désactivées par défaut, et c’est le sujet de la leçon 15 ;
• les artifacts (publier la sortie d’une session en page web privée) sont dans le même cas ;
• le plugin, à l’inverse, a un moment sans avoir de ligne au catalogue : la page le range à part, comme la couche d’emballage.

Reconnaître le moment ne monte pas le dispositif. Cette leçon te donne le quoi et le pourquoi ; ce que tu écris à l’intérieur, comment tu le formules et jusqu’où tu le laisses agir sont d’autres questions — les leçons 6, 8 et 9 en prennent chacune un morceau.

Ajouter n’est jamais gratuit. La leçon 4 l’a établi : pris un par un ces mécanismes ne coûtent presque rien, ce qui coûte c’est le nombre. Et le vrai prix n’est pas la place qu’ils occupent dans la fenêtre, c’est le bruit — une consigne noyée parmi cent autres est moins bien suivie qu’une consigne seule. Un déclencheur qui ne s’est pas présenté est une ligne que tu n’écris pas, et c’est un gain.

Et il ne te dira pas quand retirer. Le tableau couvre l’ajout et la mise à jour, jamais la suppression, alors qu’il s’adresse à quelqu’un dont le projet grossit. Deux signes observables, à défaut d’un seuil aussi net que « deux fois » :

• la longueur du fichier de règles. L’objectif officiel est de rester sous 200 lignes ; au-delà, les fichiers consomment plus de contexte et réduisent l’adhérence ;
• ce que /doctor remonte, vu plus haut : les skills, serveurs MCP et plugins que tu n’utilises pas au regard de ce qu’ils coûtent, et le contenu d’un fichier de règles versionné que Claude peut déduire du code. Il propose de déplacer le reste vers des skills et des fichiers de règles chargés à la demande, plutôt que de tout garder en permanence sur le plan de travail. Rien de tout ça ne part sans que tu confirmes : c’est un rapport, pas un ménage.

Où c’est écrit

Le fond de cette leçon vient de trois pages officielles, et il vaut mieux les avoir en signet que de nous croire sur parole :

• Vue d’ensemble des fonctionnalités — le tableau des déclencheurs, le catalogue, et la comparaison hook / skill dont vient la phrase sur la demande qui n’est pas une garantie ;
• Diagnostiquer sa configuration — d’où viennent l’ordre /context puis la commande dédiée, et les trois pannes ;
• Les skills — pour la ligne qui apparaît deux fois, ce qui distingue les deux, et la détection des changements à chaud.

La même page en lie une quatrième, un billet du blog officiel qui traite le même sujet plus longuement : Steering Claude Code: when to use CLAUDE.md, skills, hooks, and subagents. Si tu ne devais lire qu’une chose de plus après cette leçon, ce serait celle-là.

Ces liens pointent vers les pages anglaises, pour les raisons données en leçon 4 : la version française existe — remplace /en/ par /fr/. Mais elle traduit une partie des mots que tu verras sur ton écran.

Ce que cette leçon ajoute, et rien de plus. Les seuils, les mécanismes et les commandes sont dans les pages ci-dessus : va les vérifier, c’est le but. Ce qui est à nous tient en trois choses. D’abord la jonction : la page des déclencheurs dit quoi ajouter et ne dit jamais d’aller vérifier que c’est chargé ; la page de diagnostic dit comment vérifier et ne dit jamais quand ajouter — et, à la date où nous écrivons, aucune des deux ne renvoie à l’autre. Ensuite le décompte huit / sept et la raison qui va avec, que le tableau officiel laisse au lecteur. Enfin l’usage réparer plutôt qu’ajouter, qui tient dans une phrase de la source et que personne ne développe.

Le point de bascule

Ça se lit dans la question que tu poses. Tant que c’est « à quoi sert un hook ? », tu n’y es pas. Le jour où c’est « est-ce que ça vient de m’arriver pour la deuxième fois ? », c’est fait.

Vérifier que c’est passé

Deuxième fois cette semaine qu'il te propose la mauvaise commande pour lancer tes tests. Tu le corriges encore une fois dans la conversation ?

Non : deux fois sur la même commande, c’est exactement le seuil de la première ligne du tableau. Ça s’écrit dans le fichier de règles du projet, pas dans le fil de la conversation, où ça disparaîtra au prochain résumé automatique du contexte, la compaction vue en leçon 3. Une réserve, et elle est importante : ce que tu écris là est une consigne, pas une barrière. Si la chose doit se déclencher à chaque fois quoi que Claude décide, tu n’es plus sur la première ligne du tableau, tu es sur celle du hook — étant entendu que c’est le déclenchement du hook qui est garanti, pas son résultat.

Depuis un mois, tu ouvres chacune de tes sessions en retapant la même consigne de démarrage. Et par ailleurs tu recolles régulièrement la même procédure de mise en ligne. Deux moments distincts : deux mécanismes différents ?

Non, les deux mènent à un skill — c’est pour ça qu’il y a huit moments et sept mécanismes. Mais pas au même réglage. Le premier est un skill que tu déclenches toi-même : tu tapes son nom au lieu de retaper ta consigne. Le second est une procédure que Claude peut charger de lui-même quand elle devient pertinente. Le mécanisme est le même, la question « qui l’invoque » ne l’est pas, et elle se tranche par une ligne en tête du fichier du skill.

Tu as écrit hier soir ton premier skill, celui que tu es seul à pouvoir déclencher. Tu ouvres une session, tu tapes son nom : rien ne se passe. Par quoi tu commences ?

Par /skills, et pas par /context. C’est le cas particulier qui inverse l’ordre habituel. Un skill réservé à ton propre déclenchement reste hors du contexte tant que tu ne l’as pas appelé : son absence de /context est normale et ne t’apprend rien. Deux causes fréquentes ensuite, l’une et l’autre sans message d’erreur — un skill posé en fichier au lieu d’un dossier contenant son SKILL.md, ou un dossier de skills créé après le lancement de la session, ce qui est justement le cas du tout premier : là, /reload-skills ou un redémarrage.