La plupart des gens ouvrent Claude Code comme un ChatGPT dans un terminal : une question, une réponse, un copier-coller. Je m'en sers autrement, et la bascule tient dans une phrase que la documentation d'Anthropic écrit noir sur blanc. Les fichiers de mémoire sont traités comme du contexte, jamais comme une configuration appliquée. Pour empêcher une action quelle que soit la décision du modèle, il faut un hook.
Entre le 15 juin et le 10 août 2026, j'ai lancé 11 879 agents sur mes projets, soit 151 jours et 23 heures de travail machine cumulées en 56 jours de calendrier. À ce rythme, un agent qui improvise coûte cher, et une consigne polie ne suffit plus. Ce que je décris ici est mon poste de travail réel chez Noxcod : la mémoire écrite, les hooks, les skills, les commandes, les plugins et les serveurs MCP. Chaque brique y est parce qu'un incident l'a rendue nécessaire.
J'ai filmé ce réglage dans une vidéo de onze minutes. L'article reprend la méthode et y ajoute ce que j'ai revérifié depuis dans la documentation officielle, qui évolue vite.
Écrivez d'abord ce que l'agent n'a pas le droit de faire
La première chose que je pose sur un projet neuf, ce sont les interdits. Ils forment la seule catégorie de consigne qu'on peut rendre opposable au modèle, et tout le reste du réglage en découle. On passe des heures à décrire ce que l'agent doit produire, et presque personne n'écrit ce qu'il ne doit jamais lancer.
La documentation officielle sur la mémoire est explicite là-dessus : les instructions d'un fichier CLAUDE.md orientent le comportement de Claude mais ne constituent pas une couche d'application stricte, alors que les règles posées dans les réglages sont appliquées par le client quoi que le modèle décide. La conséquence pratique est brutale. Une phrase du type « ne touche jamais à la production » posée dans un fichier de mémoire relève de la recommandation. La même intention écrite en hook devient une porte fermée.
Cette distinction n'est pas théorique chez moi. Quand j'ai fait tourner l'analyse d'usage de Claude Code sur mes propres sessions, mes deux frictions les plus fréquentes étaient que l'agent agissait avant que mon intention soit verrouillée, et qu'en rédaction il comblait les trous en inventant des détails plausibles. Deux comportements qu'aucune consigne de style n'a jamais corrigés durablement, et que des garde-fous mécaniques ont réglés en une soirée.
C'est aussi ce qui sépare un réglage sérieux du vibe coding et de ses limites en projet réel. Un agent bien briefé produit vite. Un agent bien encadré produit vite sans vous obliger à relire chaque diff comme si vous aviez embauché un inconnu. Si vous découvrez l'outil, la fiche que nous tenons sur Claude Code résume son périmètre avant d'entrer dans le réglage fin.
Deux fichiers de mémoire, deux métiers différents
Le fichier global porte qui vous êtes, le fichier projet porte comment on touche à ce code précis, et confondre les deux est l'erreur la plus coûteuse du débutant. La documentation recense quatre emplacements possibles pour un fichier CLAUDE.md : une politique gérée par l'organisation, vos instructions personnelles, les instructions du projet partagées par le dépôt, et un fichier local ignoré par le gestionnaire de versions. Ils ne s'écrasent pas, ils se concatènent, du plus large au plus spécifique.
Dans mon fichier personnel vivent les règles qui valent partout : la confidentialité des dossiers clients, le style de rédaction, l'interdiction d'annoncer comme faite une action qui ne l'est pas. Dans le fichier du dépôt vivent la stack, les commandes de test, les migrations, les conventions maison. Un backend produit mature peut y consacrer des dizaines de milliers de caractères sans que cela pollue les autres projets.
Anthropic recommande de viser moins de 200 lignes par fichier, au motif qu'un fichier long consomme du contexte et dégrade l'adhérence, et Claude Code refuse purement un fichier au-delà de 4 Mio. Mon fichier personnel dépasse cette recommandation, en connaissance de cause, parce qu'il ne contient pas de principes généraux mais une liste de cicatrices : chaque ligne renvoie à un incident daté. Le compromis que je tiens, lui, respecte l'esprit de la règle. Tout ce qui est une procédure en plusieurs étapes quitte la mémoire pour devenir un skill, qui ne se charge que lorsqu'il sert.
Claude Code tient aussi sa propre mémoire, alimentée sans que vous écriviez quoi que ce soit : il y range vos préférences, les corrections que vous lui donnez, le contexte projet qu'il ne peut pas déduire du code, et les pointeurs vers vos outils externes. Seul l'index de cette mémoire entre en session, et il est tronqué à 200 lignes ou 25 Ko. Autant le relire de temps en temps, parce qu'une note fausse y survit longtemps.
Les hooks, la seule pièce qui ne dépend pas du modèle
Un hook est un script déclenché à un moment précis de la vie de l'agent, et il s'exécute que le modèle soit d'accord ou non. La documentation en recense aujourd'hui 33 événements différents, du démarrage de session à la fin, en passant par l'avant et l'après de chaque appel d'outil, la compaction, la création d'une tâche ou l'arrêt d'un sous-agent. Le plus utile de tous reste celui qui se place avant l'appel d'outil, parce qu'il peut refuser l'appel.
Trois hooks portent l'essentiel de ma tranquillité. Le premier inspecte chaque commande shell avant qu'elle parte et refuse les familles de commandes destructrices. Le deuxième déclenche une relecture par une seconde IA avant qu'un commit existe, avec un statut visible dans le terminal pendant que la relecture tourne. Le troisième garde les déploiements sensibles, parce qu'un modèle sûr de lui reste un modèle sûr de lui. Un quatrième, plus modeste, m'envoie une notification quand l'agent attend une réponse, ce qui change tout quand plusieurs sessions tournent en parallèle.
La cicatrice que je raconte volontiers concerne le premier. Ma version initiale examinait le texte de la commande au lieu de son effet réel. Un script qui manipulait une chaîne de caractères contenant une commande dangereuse se faisait refuser alors qu'il ne supprimait rien, et je perdais du temps à contourner mon propre garde-fou. Un hook mal écrit fait plus de dégâts qu'un hook absent, parce qu'il crée une friction que vous finirez par désactiver.
Deux précisions méritent d'être connues avant d'y investir. La documentation des hooks avertit qu'un hook qui dépasse son délai d'exécution ne bloque pas l'appel, celui-ci repart dans le flux de permissions normal, donc un hook bloqué ne fait jamais office de barrière. Un hook sert aussi à réduire le contexte, et la page consacrée aux coûts en donne l'exemple : plutôt que de laisser l'agent lire un journal de 10 000 lignes pour trouver trois erreurs, un script filtre en amont et ne rend que les lignes utiles.
Skills et commandes : l'expertise qui ne coûte rien tant qu'elle ne sert pas
Un skill est un dossier contenant un fichier d'instructions dont le corps ne se charge que lorsque la tâche correspond, ce qui permet d'accumuler de la documentation sans alourdir chaque session. La documentation des skills le formule ainsi : une matière de référence longue ne coûte pratiquement rien tant que vous n'en avez pas besoin. C'est la différence de nature avec la mémoire, qui entre en contexte au démarrage, toujours, même quand vous travaillez sur autre chose.
J'en ai quarante-huit sur ma machine. Un skill pour piloter le navigateur, un pour l'orchestration de plusieurs agents, un par domaine produit, un pour les procédures de relecture. Le point que les gens ratent le plus souvent tient à la description : c'est le seul texte que Claude lit pour décider s'il ouvre le skill, et cette description est tronquée à 1 536 caractères dans la liste des skills disponibles. Une description vague donne un skill que personne ne déclenche jamais. J'y écris donc les mots que je tape vraiment quand le sujet arrive, y compris en français.
Les commandes slash sont l'autre moitié du dispositif, et elles répondent à un besoin distinct : un rituel que je veux fiable plutôt qu'une expertise à la demande. Deux tournent chez moi tous les jours. La première clôt une session en ne gardant en mémoire que ce qui passe une barre de qualité haute. La seconde prépare une passation, avec un plan de reprise autosuffisant pour la session suivante. Ma règle de bascule est simple à retenir : dès que je retape la même consigne pour la troisième fois, elle devient un skill ou une commande.
Plugins et MCP : pourquoi j'en branche trois et pas vingt
Chaque serveur MCP branché consomme du contexte et élargit la surface de ce que l'agent peut faire, donc j'en garde trois qui tournent tous les jours plutôt que vingt qui impressionnent. Claude Code a beaucoup amélioré le sujet : les définitions d'outils MCP sont désormais différées par défaut, seuls les noms d'outils et les instructions du serveur entrent en contexte tant que Claude n'appelle pas un outil précis.
La documentation va plus loin, et elle rejoint une position que je défends depuis longtemps. Les outils en ligne de commande restent plus économes en contexte que les serveurs MCP, parce qu'ils n'ajoutent aucune liste d'outils, et l'agent peut les lancer directement. Mon navigateur partagé fonctionne sur ce principe : je le pilote en ligne de commande plutôt que par une extension, ce qui me laisse voir exactement le même écran que l'agent pendant une démonstration ou une recette visuelle. Si le sujet vous intéresse, nous avons détaillé à quoi sert le Model Context Protocol dans un article dédié.
Les plugins suivent la même logique de sobriété. Ce sont des paquets installables qui embarquent des skills, des hooks et des outils d'un coup. J'en active quelques-uns, sur la documentation à jour, la relecture de sécurité et le suivi d'erreurs, et je laisse le reste de côté. Le raisonnement vaut aussi pour les équipes d'agents, que la documentation chiffre à environ sept fois plus de jetons qu'une session classique quand les coéquipiers travaillent en mode plan. La puissance se paie en contexte, et le contexte se paie en oublis.
Le compactage, ou la session qui vous oublie poliment
Quand une session atteint la limite de contexte, Claude Code résume l'historique pour continuer, et votre agent perd des détails sans jamais vous prévenir lesquels. Le résumé se déclenche automatiquement chez moi, et il peut aussi se demander à la main. Ce que les gens sous-estiment, c'est le tri qui s'opère à ce moment précis.
Une chose survit avec certitude : le fichier de mémoire du projet est relu depuis le disque après le compactage et réinjecté dans la session. Ce qui disparaît, ce sont les instructions données uniquement dans la conversation, ainsi que les fichiers de mémoire imbriqués et les règles rattachées à des chemins tant qu'aucun fichier concerné n'a été rouvert. Autrement dit, tout ce que vous avez expliqué à l'oral pendant deux heures ne vaut plus rien passé ce cap, et c'est exactement pour cette raison que j'écris des plans de reprise sur disque plutôt que de compter sur la continuité d'une session.
Le compactage a aussi un coût direct qu'on oublie de compter. Résumer une grande conversation demande de la relire, donc l'opération est elle-même une grosse requête. Quand je change franchement de sujet, je repars d'une session vide, ce qui ne coûte rien du tout. Sur les déploiements en entreprise, Anthropic documente une dépense moyenne d'environ 13 dollars par développeur et par jour actif, et de 150 à 250 dollars par développeur et par mois, la dépense restant sous 30 dollars par jour actif pour 90 % des utilisateurs. Une bonne part de l'écart entre le bas et le haut de cette fourchette se joue dans la gestion du contexte.
Par où commencer si votre installation est encore au réglage d'usine
Commencez par mesurer comment vous travaillez vraiment, avant d'ajouter quoi que ce soit. Claude Code embarque une commande d'analyse d'usage qui lit vos sessions locales et produit un rapport détaillant vos frictions et ce que vous répétez. Attention à ce qu'elle couvre : un passage analyse au maximum 200 sessions qu'il n'a jamais vues et ignore les plus courtes, donc le rapport porte sur vos sessions récentes et pas sur tout votre historique.
Le mien, lancé le 10 août 2026, avait analysé 87 sessions sur 869, pour 2 219 messages et 165 commits. Le chiffre qui m'a fait changer d'avis sur ma propre pratique tient en une ligne : 10 170 appels au terminal, cinq fois plus que tous les autres outils réunis. Un agent qui appelle autant le shell n'est pas un assistant de rédaction de code, c'est un collègue qui travaille dans la machine, et il mérite les mêmes garde-fous qu'un collègue junior à qui on donne les accès de production.
L'ordre dans lequel j'installerais tout ça aujourd'hui, sur un projet neuf :
- Un fichier de mémoire projet court, avec les commandes de build et de test, les conventions et les pièges du dépôt.
- Un hook de notification à l'arrêt, pour arrêter de surveiller le terminal.
- Un hook qui refuse les commandes que vous ne taperiez jamais vous-même.
- Une commande slash pour votre rituel le plus répété.
- Un skill par procédure longue, sortie de la mémoire pour ne plus peser sur chaque session.
Le choix de l'outil compte moins que la discipline de réglage, et nous avons comparé ailleurs Claude Code, Cursor et GitHub Copilot selon le profil d'équipe. Si vous voulez ce type de poste de travail sur vos projets sans y passer vos soirées, vous pouvez contacter Noxcod et nous regarderons votre dépôt ensemble.
Questions fréquentes sur l'utilisation de Claude Code
Faut-il savoir coder pour régler Claude Code de cette façon ?
Pour la mémoire écrite et les commandes slash, non : ce sont des fichiers texte en markdown, et une bonne description vaut mieux qu'un bon script. Pour les hooks, oui, il faut être à l'aise avec un script shell, savoir lire une entrée au format JSON et comprendre ce que renvoie votre code de sortie. Comptez une soirée pour le premier hook et vingt minutes pour les suivants.
Un hook peut-il vraiment empêcher une commande dangereuse ?
Oui, et c'est la seule pièce du dispositif qui le garantisse. Un hook placé avant l'appel d'outil refuse la commande, soit par son code de sortie, soit en renvoyant une décision de refus motivée. Une réserve toutefois : un hook qui dépasse son délai d'exécution laisse l'appel repartir dans le flux normal, donc ne comptez jamais sur un hook lent comme unique barrière de sécurité.
Combien coûte Claude Code par développeur et par mois ?
Anthropic documente, sur ses déploiements en entreprise, une moyenne de 150 à 250 dollars par développeur et par mois, avec environ 13 dollars par jour actif et une dépense inférieure à 30 dollars par jour actif pour 90 % des utilisateurs. Les abonnements individuels suivent une autre logique tarifaire. Le poste qui fait vraiment varier la note reste la taille du contexte transporté à chaque requête.
Que faire quand l'agent annonce une tâche faite alors qu'elle ne l'est pas ?
Ne jamais accepter le rapport de l'agent comme preuve, et exiger une trace vérifiable : un fichier modifié, une sortie de test, un identifiant de commit. Chez moi cette règle est écrite dans la mémoire globale, et doublée par le hook de relecture avant commit, qui rend le contrôle indépendant de la bonne volonté du modèle. La mémoire donne l'intention, le hook donne la garantie.
Vaut-il mieux un gros fichier de mémoire ou beaucoup de skills ?
Beaucoup de skills, dès que le contenu est une procédure plutôt qu'un fait. La mémoire entre en contexte à chaque démarrage de session, y compris quand elle ne sert à rien, alors qu'un skill ne se charge que si la tâche correspond. Gardez dans la mémoire les faits utiles partout, comme les commandes de build et les conventions, et sortez tout le reste.
