Une configuration en huit couches pour Claude Code : CLAUDE.md, mémoire, hooks et garde-fous.

La configuration détermine dans quelle mesure on peut faire confiance à la réponse

N’importe qui peut saisir une requête dans Claude Code, mais c’est la configuration associée qui décide si le résultat mérite confiance. Ce qui suit est une présentation étape par étape d’une configuration réaliste pour un travail d’ingénierie sérieux, accompagnée des raisons de chaque étape. Il ne s’agit ni d’une liste de fonctionnalités ni d’une version marketing. Huit couches combinées permettent d’obtenir un outil d’ingénierie bien configuré, plutôt qu’une simple fenêtre de chat capable d’écrire du code.

Couche 1 : CLAUDE.md à deux niveaux d’accès

Claude Code lit les fichiers CLAUDE.md à plusieurs niveaux d’abstraction, et la distinction entre eux est plus importante que ce que la plupart des gens imaginent. Un fichier personnel situé à ~/.claude/CLAUDE.md s’applique à tous les projets, quel que soit le répertoire ouvert. Chaque projet dispose également de son propre CLAUDE.md soumis au contrôle de version, de sorte que toute l’équipe consulte les mêmes instructions via ce système de contrôle.

Une règle simple permet de les séparer. Tout ce qui concerne la manière de travailler d’une personne, quel que soit le codebase, est placé dans le fichier global : des règles d’utilisation d’outils comme la préférence pour une recherche via des outils d’intelligence de code plutôt qu’un simple grep, des préférences et conventions de communication destinées à s’appliquer partout. Tout ce qui concerne un codebase spécifique est mis dans le fichier propre à chaque répertoire : des commandes de compilation, des décisions architecturales, des conventions de nommage et des types de bugs qui ont déjà affecté ce projet. Dans tout autre projet, ces éléments ne font que créer du bruit et perturbent inutilement le contexte.

Le déclencheur pour noter quelque chose est concret. Imaginez un schéma de bug qui apparaît deux fois dans la même partie d’un projet. La correction semble correcte et convient à un coup d’œil rapide, mais elle réintroduit le même problème, car la contrainte sous-jacente n’a jamais été enregistrée nulle part où l’agent puisse la voir. La première fois, la contrainte est expliquée lors d’une conversation et tout le monde passe à autre chose. La deuxième fois, la même erreur entraîne la même explication. C’est le signal. Une règle doit figurer dans CLAUDE.md non pas parce qu’elle pourrait être utile un jour, mais parce qu’elle a coûté deux fois la même conversation. Une fois qu’il s’agit d’une règle concrète et vérifiable, et non d’un avertissement vague, le problème cesse de se reproduire.

Un détail pratique : le contenu de CLAUDE.md est transmis sous forme de message utilisateur et n’est pas intégré au prompt du système, donc la précision l’emporte sur la longueur. Un fichier contenant moins de 200 lignes de règles claires est plus efficace qu’un fichier long rempli de règles vagues.

Niveau 2 : mémoire automatique

CLAUDE.md correspond à ce que le développeur indique à l’agent, tandis que la mémoire correspond à ce que l’agent détermine par lui-même. Ils ont des fonctions distinctes et ne doivent pas être confondus. Claude Code dispose d’un second système, la mémoire automatique, qui s’accumule au fil des projets et est stocké en dehors du répertoire de code ; c’est l’agent qui y écrit. Ce système conserve quatre types de notes : le rôle et les préférences de travail du développeur, les corrections et retours déjà donnés, l’état en cours du projet qui ne peut pas être déduit du code, ainsi que des références externes menant à des informations situées en dehors de la base de code. Un fichier léger MEMORY.md indexe tout cela.

La différence réside dans le fait que CLAUDE.md contient des instructions écrites délibérément, tandis que la mémoire conserve le contexte acquis au fil de sessions successives, sans jamais être formalisé par écrit. L’un est un manuel de règles. L’autre ressemble aux connaissances institutionnelles que possède un collègue expérimenté sans aucun document d’intégration. Trois exemples illustrent les changements :

• Une correction ponctuelle, telle que « ne touchez pas à ce fichier sans demander d’abord », reste valable pour la session suivante et n’a pas besoin d’être répétée à chaque début de conversation.
• Le statut d’un projet invisible dans le code est mémorisé : une migration en cours, une décision délibérément reportée, ou une architecture qui semble intentionnellement incorrecte en raison d’une contrainte que les différences de code ne révèlent pas.
• Les indications sur l’endroit où se trouvent les réponses survivent, comme le tableau de bord concerné, le document externe ou le système qui contient des informations que la base de code ne peut pas fournir.

Rien de tout cela ne doit figurer dans CLAUDE.md, car il ne s’agit d’aucune règle à appliquer. Il s’agit de contexte qui disparaîtrait dès la fermeture d’une session.

Niveau 3 : les hooks comme friction intentionnelle

La friction choisie délibérément n’a rien à voir avec celle à laquelle on est simplement confronté. Les hooks s’exécutent de manière déterministe, comme de véritables commandes de shell à des moments précis du cycle de vie, ce qui offre une garantie plus solide que de compter sur le fait que le modèle se souvienne généralement. Un hook PreToolUse se déclenche avant toute appel à un outil et peut l’arrêter complètement. Un hook Stop se déclenche lorsque Claude termine sa réponse et peut la forcer à continuer si certaines conditions ne sont pas encore remplies.

Le modèle le plus utile est un crochet PreToolUse limité aux modifications de fichiers. Avant que la modification ne soit effectuée, il exige un rapport écrit des faits : quels modules importent le fichier, ce qui pourrait être endommagé et quelle était réellement la demande. Il agit comme un frein destiné à empêcher des changements négligents, et cet effort en vaut la peine car il intervient précisément là où la prudence est nécessaire. Contrairement à l’attention humaine, un crochet ne passe pas à côté ni ne se précipite pour traiter la quarantième modification d’une longue session.

Un deuxième crochet assure la discipline de l’output en gardant les réponses concises, en éliminant le superflu réflexif et les hésitations qui apparaissent lors de sessions plus longues. Il s’agit moins de sécurité que d’éviter de gaspiller du temps de lecture en contenu inutile. Un troisième crochet surveille l’état du contexte, incitant à la compression à un point naturel et non arbitraire. Un crochet PreCompact ou SessionStart lié aux événements de compression peut proposer un résumé lorsque la conversation atteint réellement un point d’arrêt, afin qu’elle ne soit pas interrompue au milieu d’une pensée.

Cette contrainte en vaut-elle la peine ? Pour la protection contre les erreurs de modification de fichiers, absolument, car elle a permis d’éviter que de vrais problèmes ne surviennent. Les mécanismes de concision et de suivi du contexte servent davantage à ajuster le confort d’utilisation qu’à assurer une protection, mais ils sont utiles une fois correctement configurés.

Couche 4 : un graphe de connaissances en code bat grep

Grep indique où apparaît une chaîne de caractères, mais pas ce qui la invoque, ce qu’elle invoque elle-même ou ce qui se brise lorsqu’elle change. L’exploration classique consiste en une boucle : rechercher un terme, ouvrir le fichier, rechercher ce que ce fichier importe, ouvrir également ce dernier, et continuer jusqu’à ce qu’une image se forme. Cette méthode fonctionne, mais lentement, et elle nécessite de nombreuses appels d’outils pour reconstruire un modèle mental basé sur des faits structurels qui ne devraient pas avoir à être redécouverts par force brute à chaque session.

Un graphe de connaissances pré-indexé modifie les principes économiques en jeu. Une seule requête restitue la source pertinente ainsi que les chemins d’appel réels : qui l’appelle, ce qu’il appelle et jusqu’où s’étend la chaîne de dépendances. Cela se fait en une seule passe au lieu de multiples recherches, ce qui réduit les allers-retours et fournit une vision plus complète dès le départ, car les détails des chemins d’appel que grep ne pourrait jamais produire sont inclus directement dans le résultat. La documentation officielle de Claude Code avance une idée similaire pour les plugins d’intelligence de code, soulignant que les grands bases de code structurées tirent un grand avantage des requêtes tenant compte de la structure par rapport à la simple correspondance de texte, où les cycles répétés de recherche et de lecture deviennent rapidement coûteux.

Couche 5 : vérification sur un appareil réel

Ce qui importe, c’est de savoir si une modification fonctionne réellement sur le dispositif ou si elle est simplement compilée, ce qui correspond à deux affirmations différentes. Pour Flutter, c’est cette couche qui est utilisée le plus souvent. Réconstruire tout depuis zéro pour vérifier une petite modification de l’interface utilisateur est un gaspillage lorsque l’on dispose d’une connexion à une application exécutée sur du matériel réel, connexion qui permet de combler les lacunes que la génération de code ne peut pas atteindre. Elle prend en charge les captures d’écran, la navigation à travers les flux et l’inspection de l’arborescence de l’interface utilisateur en temps réel. Claude Code prend désormais correctement en charge ces fonctionnalités, en offrant un accès au simulateur iOS ainsi que des outils permettant d’utiliser un ordinateur pour valider une version native, reproduire un bug de mise en page ou exécuter un flux de simulation par rapport à ce qui est affiché.

En se connectant à la VM Dart pour le chargement en temps réel et la redémarrage en temps réel, le cycle passe de « deviner, reconstruire, attendre, vérifier » à « deviner, recharger, vérifier ». Cela est plus rapide, et cela évite également un piège fréquent : considérer qu’une compilation réussie prouve que la correction fonctionne. Un bâti qui se compile et un bâti qui se comporte correctement sur le matériel sont deux affirmations distinctes, et l’habitude de se contenter de reconstruire ne permet pas de les distinguer. Le faire fonctionner sur le dispositif répond directement à cette question.

Niveau 6 : charger les outils uniquement lorsque c’est nécessaire

Chaque outil présent dans le contexte, utilisé ou non, impacte chaque étape, et pas seulement celles qui l’utilisent. Par conséquent, tout n’est pas chargé par défaut, et c’est un choix de conception délibéré. Les outils spécialisés, tels que l’automatisation des navigateurs, les serveurs MCP moins courants et tout ce qui est utilisé occasionnellement, s’chargent sur demande et ne occupent pas le contexte pendant toute la session.

L’effet s’accumule au cours d’une session longue, car chaque définition d’outil coûte des tokens à chaque tour, que cet outil soit utilisé ou non. La fonction de recherche d’outils MCP de Claude Code a été conçue pour surmonter ce problème. Les serveurs peuvent s’inscrire à une découverte sur demande, au lieu de charger toutes les définitions au début de la session, ce qui permet à une session de plusieurs heures de rester efficace sans être alourdie par des éléments contextuels inutilisés qui continuent de coûter des ressources.

Niveau 7 : utilisez les workflows prêts à l’emploi dont vous avez réellement besoin

Claude Code dispose d’un vaste écosystème de workflows prêts à l’emploi, incluant des outils de revue de code, de vérification de sécurité, des outils spécifiques aux frameworks, ainsi que des agents de planification et d’exécution. Chacun d’eux peut être invoqué explicitement, évitant ainsi de devoir reconstruire constamment la même logique ad hoc à chaque session. Une grande bibliothèque ne sert à peu de chose si seuls trois éléments y sont jamais utilisés ; donc un bilan honnête de l’utilisation réelle vaut mieux qu’une liste complète du catalogue.

Trois méthodes sont utilisées régulièrement. Une revue de code générale a lieu avant toute fusion significative. Un revueur axé sur la sécurité examine tout ce qui concerne l’authentification ou le traitement des données. Un sous-agent dédié à la planification s’occupe des tâches suffisamment importantes pour que passer directement à l’implémentation échappe à une réflexion architecturale sérieuse. Ces trois méthodes couvrent presque toutes les utilisations explicites.

La plupart des outils de revue spécifiques aux frameworks non utilisés restent inutilisés, tout comme les modèles de sous-agents plus complexes conçus pour de grandes recherches parallèles. Ce ne sont pas de mauvais outils ; le travail quotidien ne nécessite tout simplement pas un tel niveau d’investigation. Utiliser des outils plus lourds que ce dont on a besoin constitue une perte en soi. La valeur réside dans la connaissance des trois ou quatre outils fiables à utiliser, sans se sentir obligé d’en employer d’autres simplement parce qu’ils existent.

Couche 8 : confirmation par réversibilité

La vitesse ne constitue un avantage que tant que le résultat reste fiable ; une fois la confiance ébranlée, c’est justement la vitesse qui provoque des dommages. Même avec tous les mécanismes activés, certaines actions nécessitent toujours une confirmation explicite : les opérations destructrices sur Git, les mises à jour et tout ce qui est véritablement irréversible. Aucun niveau d’automatisation ne permet de franchir cette limite, car une erreur à cet égard ne signifie pas simplement de refaire le travail, mais plutôt de réparer des dégâts qui pourraient être irréparables.

Le équilibre dépend de la réversibilité de l’action en question, et non du niveau de risque perçu. Une refonte importante impliquant des dizaines de fichiers exige beaucoup d’efforts mais reste entièrement réversible grâce au contrôle de version, ce qui permet une supervision plus légère. Une commande git push --force ne nécessite presque aucun effort et peut avoir des conséquences irréversibles, c’est pourquoi elle est strictement interdite, aussi courante soit-elle. L’effort et le risque relèvent de axes différents, et leur mélange est ce qui permet d’accorder une autonomie excessive aux actions inappropriées.

Choisir entre agir immédiatement ou demander l’autorisation d’abord ne se résume pas à un simple réglage. Il s’agit d’une décision spécifique à chaque type d’action, prise à l’avance et qui ne doit jamais être réexaminée au moment où l’épuisement fait que la demande de confirmation semble être un obstacle agaçant.

Ce que les différentes couches apportent

Aucun des huit niveaux ne se distingue à lui seul. CLAUDE.md est un fichier de texte brut, et un hook est une commande shell qui s’exécute au moment opportun. Ensemble, ils transforment Claude Code, qui n’est qu’un éditeur rapide dépourvu de contexte persistant et de tout sens de la réversibilité, en un outil doté de mémoire, de contrôles, de connaissances structurelles sur le codebase et de capacités de vérification réelle sur le dispositif.

La configuration elle-même n’est pas l’aspect intéressant, mais plutôt les raisons qui sous-tendent chaque niveau. Ceux qui utilisent Claude Code sans aucune de ces configurations ne devraient pas essayer d’ajouter les huit en même temps. Commencez par un vrai CLAUDE.md basé sur des erreurs qui se sont déjà produites à deux reprises, puis développez progressivement.