Claude Code

Tout dans la configuration de Claude Code se ramène à la portée. Le même mécanisme — instructions, réglages, règles, skills, agents — existe en plusieurs couches, de l’organisation jusqu’à la machine d’un seul développeur. La couche dans laquelle vous écrivez décide qui reçoit le réglage et ce qui peut le surcharger. Apprenez les couches une bonne fois pour toutes, avec soin : les questions de l’examen ici sont presque toutes des questions de couches déguisées.

Comment lire cette page : les encadrés « Règle d’examen » rassemblent ce que l’examen attend que vous reproduisiez exactement — noms de fichiers, ordres, valeurs de drapeaux — tandis que la prose autour d’eux construit la compréhension que vous pourrez retrouver sous pression. Chaque fait a été vérifié auprès de la documentation officielle de Claude Code sur code.claude.com le 3 octobre 2026, et les Repères de révision à la fin lient les pages exactes. Claude Code évolue vite ; traitez ces pages comme la source vivante et celle-ci comme la carte calquée sur l’examen.

01Quatre foyers pour les instructions

CLAUDE.md est l’endroit où vivent les instructions que vous écrivez. Quatre emplacements, quatre audiences :

• —Politique gérée — un CLAUDE.md déposé par l’équipe IT via la gestion de configuration à un chemin système : /Library/Application Support/ClaudeCode/CLAUDE.md sur macOS, /etc/claude-code/CLAUDE.md sur Linux et WSL, C:\Program Files\ClaudeCode\CLAUDE.md sur Windows. Tout le monde dans l’organisation le reçoit.
• —Utilisateur — ~/.claude/CLAUDE.md. Le vôtre seul, chargé dans chaque projet.
• —Projet — ./CLAUDE.md ou ./.claude/CLAUDE.md, versionné dans le dépôt. La copie de l’équipe : architecture, standards, flux de travail.
• —Projet-local — ./CLAUDE.local.md, ignoré par git. Les détails personnels pour un seul projet : votre URL de sandbox, vos données de test préférées.

En dehors de ces quatre emplacements se trouve la mémoire automatique — des notes que Claude écrit lui-même, distillées à partir de vos corrections, limitées à un dépôt et partagées entre worktrees. Une session charge au plus les 200 premières lignes ou 25 Ko. C’est un plafond que CLAUDE.md lui-même n’a pas.

Deux règles de contenu sur lesquelles la documentation est insistante. Écrivez des instructions vérifiables : « Lancer npm test avant de committer » plutôt que « tester vos changements ». Et sachez comment les imports se comportent. Un CLAUDE.md peut importer d’autres fichiers avec des références @path — mais dès qu’une référence est enveloppée dans des backticks ou un bloc de code, le @ n’est que du texte littéral et rien n’est importé. Pas d’erreur, pas de chargement partiel. L’import est simplement ignoré.

02Fichiers de règles et portée de chemins

Pour les équipes qui préfèrent ne pas maintenir un fichier monolithique, .claude/rules/ accueille des fichiers d’instructions modulaires — un fichier de style de code, un fichier de tests, un fichier de sécurité — avec des équivalents personnels sous ~/.claude/rules/ et des jeux de règles partagés souvent liés par lien symbolique dans le répertoire du projet. Un fichier de règles peut déclarer des chemins dans son front-matter — une liste YAML ou une chaîne de globs séparés par des virgules comme src/api/**/*.ts — pour ne se charger que lorsque des fichiers correspondants sont en jeu. Et dans les monorepos, le réglage claudeMdExcludes tient les CLAUDE.md et fichiers de règles des autres équipes hors de vos sessions.

03AGENTS.md est un repli, pas un compagnon

Le point le plus interrogé de ce domaine : par défaut, Claude Code lit les fichiers CLAUDE.md ou AGENTS.md — jamais les deux. Si un CLAUDE.md, un .claude/CLAUDE.md, ou même un simple CLAUDE.local.md existe dans le répertoire de travail ou un parent, AGENTS.md n’est pas lu. Votre ~/.claude/CLAUDE.md personnel et le fichier de politique gérée ne déclenchent pas cette mise à l’écart — ce ne sont pas des fichiers de projet — et les fichiers de règles non plus.

Si vous voulez vraiment les deux, deux portes existent : importer AGENTS.md depuis votre CLAUDE.md avec une référence @, ou changer le réglage instructionFiles. Connaissez ses quatre valeurs, parce que l’examen peut vous demander de les distinguer. claude-md-or-agents-md est le défaut — le comportement l’un-ou-l’autre décrit ci-dessus. claude-md-and-agents-md charge les deux, les fichiers CLAUDE.md en premier dans chaque répertoire. claude-md ne lit que les fichiers CLAUDE.md. Et managed-only ne charge que le fichier de politique gérée plus la mémoire automatique, en ignorant entièrement les instructions utilisateur, projet et locales. Encore une chose à mémoriser — les fichiers jamais lus, quelle que soit la configuration : AGENTS.local.md, AGENTS.override.md, et tout ce qui vit sous .agents/.

04settings.json : cinq couches, une chaîne

Les réglages — permissions, hooks, variables d’environnement, modèle par défaut, configuration des plugins — vivent dans des fichiers JSON avec un ordre de précédence strict, la couche la plus haute d’abord :

• —Réglages gérés — managed-settings.json ou politique MDM. Déployés pour tout le monde ; rien de ce que fait l’utilisateur ne les surcharge.
• —Ligne de commande — --settings, --model et compagnie. Cette session seulement.
• —Projet local — .claude/settings.local.json. Le vôtre, ce projet.
• —Projet partagé — .claude/settings.json. Celui de l’équipe, une fois committé.
• —Utilisateur — ~/.claude/settings.json. Le vôtre, partout.

La fusion se fait clé par clé : une couche supérieure ne gagne que sur les clés qu’elle fixe réellement, et tout le reste vient des couches inférieures. Trois notes de comportement qui deviennent des questions. Première : les approbations « ne plus demander » sont écrites par Claude Code lui-même dans le fichier projet-local — qu’il ajoute ensuite au gitignore pour vous la première fois, dans un dépôt git, mais seulement si c’est lui qui a fait l’écriture. Créez le fichier à la main et le gitignore est votre affaire. Deuxième : les fichiers de réglages se rechargent à chaud en pleine session pour les permissions, les hooks et les variables d’environnement, mais le réglage du modèle est lu au lancement — modifiez le fichier et il s’appliquera à la session suivante. En pleine session, utilisez plutôt les commandes : /model change de modèle (au prix d’un certain coût de cache), /effort change l’effort. Troisième, une asymétrie de confiance. Tant que settings.local.json reste non suivi par git, ses règles allow s’appliquent sans l’étape de confiance de l’espace de travail — mais les règles allow du settings.json committé ne prennent effet pour vos collègues qu’après qu’ils ont accordé leur confiance au dossier (les règles deny et ask s’appliquent immédiatement dans tous les cas). Confiez le fichier local à git, et l’étape de confiance s’applique aussi à lui.

Les permissions elles-mêmes sont des chaînes de règles : des entrées allow comme Bash(npm run test *) et des entrées deny comme Read(./.env) — la forme que l’examen attend que vous lisiez couramment.

05Guider ou imposer

La distinction pour laquelle ce domaine existe : un CLAUDE.md — même le géré — est un guide. Il façonne le comportement ; il n’empêche techniquement rien, et « habituellement suivi » n’est pas un contrôle de sécurité. Tout ce qui doit tenir va dans les réglages gérés : permissions.deny pour bloquer des outils, des commandes et des chemins ; les réglages de sandbox pour l’isolation ; le routage d’environnement et de fournisseur ; les restrictions de connexion et d’organisation. Et la règle empirique de la documentation mérite d’être gardée : si un manquement est un désagrément, CLAUDE.md. Si c’est un incident, réglages.

06Ce qu’une équipe met au dépôt

La question de l’organisation du dépôt a une réponse propre, et elle est plus facile à tenir comme une image que comme une liste. Tout ce qui est partagé vit dans le dépôt, tout ce qui est personnel reste dehors, et tout ce qui relève de l’organisation se situe au-dessus des deux, sur une machine que votre équipe ne contrôle pas :

07Skills : des instructions qui se chargent à l’usage

Un skill est un jeu d’instructions réutilisables dans un fichier SKILL.md : skills de projet dans .claude/skills/<name>/ (partagés par commit), personnels dans ~/.claude/skills/<name>/, d’entreprise dans le répertoire géré. La différence avec CLAUDE.md, c’est le moment du chargement. Seul un relevé de noms et de descriptions siège en permanence dans le contexte — assez pour que Claude sache ce qui existe — tandis que le corps se charge quand le skill est invoqué : par vous comme /skill-name, ou par Claude lui-même quand la conversation correspond à la description. C’est la divulgation progressive. C’est pourquoi une longue documentation de référence appartient à un skill plutôt qu’à un CLAUDE.md chargé en entier à chaque session. Et le champ description du front-matter est le déclencheur — écrivez-le pour dire quand faire appel au skill.

Deux détails qui valent une question chacun. Un corps de skill peut injecter une sortie shell vivante avant que Claude ne le lise — une ligne comme !`git diff HEAD` incorpore le diff courant dans le prompt. Et les commandes slash personnalisées — fichiers Markdown dans .claude/commands/ — sont l’ancien format : elles fonctionnent encore et acceptent le même front-matter que les skills, sauf name et paths, mais tout nouveau travail devrait préférer un skill, dont le dossier peut porter des fichiers d’appui à côté du SKILL.md.

Quand un même nom est défini deux fois, connaissez l’ordre de préséance : l’entreprise bat le personnel, qui bat le projet — oui, le skill personnel prime sur le skill de projet. Un skill bat un fichier de commande du même nom ; votre propre skill remplace une commande livrée avec le produit mais pas ses alias ; et les skills de plugins n’entrent jamais en collision, parce qu’ils se chargent sous espace de noms /plugin-name:skill-name.

08Les sous-agents dans le code

Ce qu’est un sous-agent et quand y recourir appartient au domaine des patterns d’agents ; Claude Code, lui, vous demande où les sous-agents sont définis. Ceux définis dans des fichiers sont des fichiers Markdown placés dans .claude/agents/ — front-matter pour name, description (quand le parent doit lui déléguer), tools et model, puis le corps servant de prompt système. Les sources de définition s’empilent, la plus haute d’abord : réglages gérés, drapeau --agents, .claude/agents/ du projet, ~/.claude/agents/ personnel, puis les plugins. Et un piège : après avoir créé le premier fichier d’agent dans un nouveau répertoire agents, redémarrez la session avant qu’il soit pris en compte.

Trois sous-agents sont livrés en standard. Explore et Plan reçoivent des jeux d’outils en lecture seule — Write et Edit sont interdits —, Explore pour chercher et arpenter le code, Plan pour la recherche pendant la planification. general-purpose reçoit tous les outils disponibles pour les sous-agents et c’est lui qui fait les changements de code. Cette séparation en lecture seule est une distinction favorite de l’examen.

09Les quatre systèmes, côte à côte

Instructions, réglages, skills, sous-agents — quatre systèmes, quatre jeux de noms de fichiers, et trois réponses différentes à ce qui arrive quand deux couches se rencontrent. Avant la moitié headless du domaine, un tableau pour remettre l’image en place :

10Headless : Claude Code depuis un script

claude -p (forme longue --print) fait tourner la même boucle d’agent de façon non interactive : il prend un prompt, lit l’entrée pipée sur stdin, imprime le résultat et sort — la forme que veulent les scripts, les tâches CI et les pipelines, avec un code de sortie 0 en cas de succès pour que le branchement shell fonctionne. Approuvez les outils à l’avance plutôt qu’interactivement. --allowedTools prend la syntaxe des règles de permission — Bash(git commit *), pas seulement Bash — et --permission-mode règle le comportement de toute la session : acceptEdits laisse passer les éditions de fichiers, tandis que auto fait passer chaque action au crible d’un classifieur et convient aux exécutions longues sans surveillance. Associez --permission-prompts none à l’un ou à l’autre, et tout ce qui n’est pas résolu est refusé au lieu de suspendre le travail.

La forme de sortie, c’est le drapeau --output-format. text est la valeur par défaut — une sortie en clair. json est un objet structuré avec la réponse dans result, plus session_id et des métadonnées de coût ; ajoutez --json-schema pour une sortie validée par schéma. Et stream-json est une suite d’événements JSON délimités par des sauts de ligne, au fil de l’eau, typiquement avec --verbose — des événements système comme api_retry portent attempt et retry_delay_ms. Chaque exécution a un identifiant de session ; lisez-le dans la sortie json. --resume <id> reprend exactement cette conversation, tandis que --continue prend la plus récente — c’est ainsi qu’un script transporte son contexte d’une invocation à l’autre.

Deux drapeaux de plus qui apparaissent dans des questions. --bare démarre une session minimale, sans aucun des extras auto-découverts — pas de hooks, skills, sous-agents, plugins, serveurs MCP, mémoire automatique ni CLAUDE.md — ce que veulent les exécutions scriptées reproductibles ; la configuration arrive alors explicitement via --settings, --mcp-config ou --append-system-prompt. Et les commandes slash dans un prompt -p : les commandes personnalisées et les skills invoqués par l’utilisateur fonctionnent quand ils sont inclus dans la chaîne du prompt, et prennent leurs valeurs en arguments (/model sonnet, /config thinking=false). Mais les commandes qui n’existent que dans l’interface du terminal — /login étant l’exemple standard — ne sont pas disponibles du tout.

11Les pièges de ce domaine

• —« CLAUDE.local.md est le fichier partagé de l’équipe » — l’inverse. ./CLAUDE.md est partagé ; le fichier local est personnel et ignoré par git.
• —« AGENTS.md se charge aux côtés de CLAUDE.md » — seulement si vous le configurez ; par défaut, l’un écarte l’autre.
• —« --settings surcharge la politique de l’organisation » — il surclasse les fichiers utilisateur et projet, pas les réglages gérés.
• —« Un CLAUDE.md géré peut bloquer des commandes dangereuses » — la prose ne peut pas imposer ; utilisez permissions.deny dans les réglages gérés.
• —« Le skill de projet gagne parce qu’il est plus spécifique » — l’ordre est enterprise > personal > project, donc le skill personnel tourne.
• —« Explore peut corriger les fichiers qu’il trouve » — Explore et Plan ont Write et Edit interdits ; les changements de code vont à general-purpose.
• —« Toute commande slash fonctionne en headless » — les commandes personnalisées et les skills invoqués par l’utilisateur fonctionnent dans la chaîne du prompt -p ; celles purement terminales comme /login, non.