Configuration et flux de travail Claude Code

La configuration de Claude Code est un système de fichiers, et l’examen la parcourt couche par couche. Les instructions — les conseils qui orientent ce que Claude va tenter — vivent dans les fichiers CLAUDE.md. L’imposition — les règles qu’il ne pourra pas raisonner en contour — vit dans settings.json, les hooks et les permissions. Deux systèmes, deux jeux de noms de fichiers, deux réponses différentes à « que se passe-t-il quand deux couches se rencontrent ». Apprenez les règles de collision ; l’examen ne demande presque que cela.

01CLAUDE.md : la hiérarchie des instructions

CLAUDE.md est le fichier de conseils que Claude Code charge automatiquement au lancement — conventions du projet, règles de style, carte du dépôt. Il existe en une hiérarchie de portées : des paramètres managés par l’organisation peuvent installer des instructions à l’échelle de l’entreprise ; la portée utilisateur vit dans ~/.claude/CLAUDE.md et vous suit de projet en projet ; la portée projet est ./CLAUDE.md à la racine du dépôt, commité et partagé ; et une variante locale au projet (CLAUDE.local.md, effectivement dépréciée) couvre les ajouts personnels non commités. Quand plusieurs couches parlent, toutes se chargent — elles se concatènent, elles ne s’opposent pas ; le fichier le plus spécifique apparaît simplement plus tard, là où la fraîcheur et la spécificité emportent l’argument.

Deux règles du traitement CCDV-F restent d’actualité pour l’examen et se méritent au mot près. D’abord : CLAUDE.md ou AGENTS.md, jamais les deux par défaut — la présence d’un CLAUDE.md de projet (même un CLAUDE.local.md) supprime le repli AGENTS.md, donc un dépôt qui repose sur AGENTS.md se tait le jour où quelqu’un ajoute un CLAUDE.md perdu. Ensuite : les conseils ne sont pas l’imposition. Une ligne de CLAUDE.md est un avis que le modèle lit et peut peser ; une règle deny dans settings est un mur. Les scénarios qui disent « ne doit jamais » demandent le mur.

L’organisation modulaire est le troisième acte. CLAUDE.md supporte les imports — une ligne comme @docs/conventions/frontend.md tire un autre fichier — donc le fichier racine devient une table des matières et les fichiers par sujet restent petits et maintenables séparément. C’est plus qu’une question d’esthétique : les fichiers d’instructions enflent le contexte à chaque lancement (ils sont lus à chaque session), et un monolithe de cinq cents lignes taxe chaque exécution pour servir des règles qui ne concernent qu’une fraction du travail. Petits fichiers importés, par sujet : c’est la réponse examinée à « notre CLAUDE.md est devenu-ingérable ».

02settings.json : la hiérarchie de l’imposition

Là où les instructions conseillent, les settings décident. La hiérarchie des settings court managé (géré par l’organisation, rien ne le prime) → ligne de commande (drapeaux sur cette invocation) → projet (.claude/settings.json, commité) → local (.claude/settings.local.json, personnel, gitignoré). La fusion se fait par clé : une couche supérieure ne gagne que sur les clés qu’elle définit réellement, et les clés de liste comme permissions.allow se combinent entre couches au lieu de se remplacer. Les petits caractères de l’examen sont précis : les approbations « Ne plus demander » atterrissent dans .claude/settings.local.json — et quand c’est Claude Code lui-même qui a fait l’approbation, il ajoute l’entrée gitignore pour vous. Les settings 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 et s’applique à la session suivante. Les paramètres managés sont le mur derrière le mur : rien dans votre projet ne les prime.

03Commandes slash personnalisées et skills

Une commande slash personnalisée est un fichier markdown qui devient un gabarit de prompt : placez deploy-check.md dans .claude/commands/ et /project:deploy-check se déploie en son contenu. La mécanique que l’examen cite : $ARGUMENTS injecte ce qui suit la commande ; le frontmatter peut déclarer des outils autorisés et une description ; une ligne comme !`git diff HEAD` exécute la commande et injecte sa sortie en direct avant que Claude lise le gabarit ; des références @fichier tirent le contenu du fichier. Les commandes à portée utilisateur (~/.claude/commands/) voyagent avec vous ; celles à portée projet voyagent avec le dépôt — même choix, mêmes verbes, que les portées MCP.

Un skill est le grand frère découvrable : un répertoire avec un SKILL.md dont le frontmatter (name, description) est toujours chargé, tandis que le corps n’est lu qu’à la demande — divulgation progressive, si bien qu’une bibliothèque qui grandit ne coûte du contexte que lorsqu’on l’utilise. Les skills peuvent embarquer scripts et fichiers de référence, ce qui en fait la bonne forme pour « la procédure de release, avec ses trois scripts utilitaires, disponible chaque fois qu’on parle de release ». La bizarrerie de précédence est prête pour l’examen : un skill bat un fichier de commande du même nom ; votre skill peut remplacer une commande livrée mais pas ses alias ; les skills de plugin sont préfixés (/nom-du-plugin:nom-du-skill) et n’entrent jamais en collision avec les vôtres.

04Règles par chemin et chargement conditionnel

Toutes les conventions ne s’appliquent pas à tous les fichiers, et la formule de l’examen pour le remède est le chargement conditionnel — des règles qui n’arrivent que quand le travail touche leur territoire. Les mécanismes, du moins cher au premier. Les règles de permissions sont à portée de chemin : une règle comme Edit(docs/**) ne gouverne que les modifications sous docs/ — donc un agent de documentation peut être autorisé à écrire exactement là et nulle part ailleurs. Les hooks matchent par outil (et des motifs de matching sur le nom d’outil), et leur code peut inspecter les chemins qu’un appel touche — l’étage imposition du conditionnel. Et l’étage instructions : les imports modulaires de CLAUDE.md laissent les conventions d’un sous-répertoire vivre à côté du code qu’elles gouvernent, ou arriver via une commande ou un skill qui ne les charge que pour ce travail.

Le cadrage d’architecte que l’examen récompense : les règles conditionnelles sont un budget de contexte et d’imposition. Des permissions à portée de chemin donnent « peut modifier docs, ne peut pas modifier src » comme un mur, pas comme un vœu ; des hooks sensibles aux chemins donnent « lint seulement ce qui a changé » ; le chargement conditionnel d’instructions garde les quarante lignes de règles de contrat API hors de chaque session qui n’ouvre jamais un fichier d’API. Les mauvaises réponses dans ce territoire sont toujours inconditionnelles : des CLAUDE.md plus gros qui s’appliquent partout, ou de la revue manuelle à la place d’une règle cadrée.

05Mode plan contre exécution directe

Claude Code tourne dans des modes de permission, et la comparaison de l’examen est mode plan contre exécution directe. En mode plan, l’agent fait de la recherche en lecture seule — il peut explorer, grepper, lire, raisonner — mais n’exécute rien qui change l’état ; au bout, il propose un plan, et vous l’approuvez avant la moindre modification. L’exécution directe travaille simplement, demandant la permission aux portes habituelles. Shift+Tab fait défiler les modes en interactif ; les exécutions headless sélectionnent le comportement avec --permission-mode.

L’examen veut la règle de choix, pas le raccourci clavier. Le mode plan mérite son surcoût quand la tâche est grosse, la base de code inconnue, le schéma de modification incertain, ou le rayon d’action effrayant — les erreurs chères arrivent dans les dix premières minutes, et le mode plan est la façon d’acheter une revue de ces dix minutes avant qu’elles ne touchent quoi que ce soit. L’exécution directe gagne pour les petits changements bien compris et peu risqués, où un aller-retour de planification est de la pure latence. Notez la parenté architecturale : planifier-puis-exécuter est un flux — un point de contrôle conçu entre phases — exactement le point d’insertion HITL du domaine 1, en costume de raccourci clavier.

06Raffinement itératif : checkpoints, /clear, /compact

Les vraies sessions divaguent : trois tentatives ratées, une tangente, un contexte plein de raisonnements périmés. La trousse de raffinement de Claude Code compte trois instruments distincts, et l’examen exige que vous sachiez qu’ils ne sont pas interchangeables. Checkpoints et retour arrière : chaque session prend des checkpoints, et revenir en arrière (le menu double-Esc) restaure à la fois le code et la conversation jusqu’au point choisi — le geste « cette approche était fausse, ramène-moi en arrière » ; c’est un annuler, pas un oublier. /clear essuie le contexte et démarre une conversation vide dans la même session — le bon geste quand l’ancien raisonnement est pollué mais que le travail tient (après une grosse fusion, un sous-travail fini, une séance de débogage devenue fouille archéologique). /compact résume la conversation et continue avec le résumé — le bon geste quand le fil reste utile mais que la fenêtre se remplit (un correctif de taille moyenne dont l’historique vaut le dixième de sa taille). /compact accepte des instructions optionnelles sur ce qu’il faut préserver.

La distinction que l’examen ne cesse de sonder : compacter préserve un fil distillé ; clearer le sectionne ; revenir en arrière voyage le long du fil. Le verbe du scénario choisit l’outil — « continue mais la fenêtre est énorme » → /compact ; « attaque la tâche suivante proprement » → /clear ; « annule toute cette approche, modifications comprises » → retour arrière. Autour de ça vivent les habitudes du raffinement progressif : travailler par petits pas vérifiables, lancer les tests entre eux, poser un checkpoint avant le geste risqué — la même échelle que les budgets du domaine 1 : corriger le périmètre, pas le plafond.

07Claude Code en CI/CD

Le dernier sous-domaine est l’exploitation sans humain — Claude Code sans personne au clavier. La forme headless : claude -p "prompt" exécute un prompt jusqu’au bout sans l’interface interactive, et --output-format json (ou stream-json) émet des résultats lisibles par machine — coût, durée, identifiants de session, tout — pour que votre pipeline puisse analyser l’issue, la poster en commentaire, la joindre à la PR. Le code de sortie 0 en cas de succès fait faire fonctionner le branchement shell : l’étape après « claude -p » ne s’exécute que si Claude a réussi.

Les permissions en headless sont le même système sans humain à la porte : --allowedTools prend la syntaxe des règles de permission — Bash(git commit:*), pas juste Bash — et --permission-mode règle le comportement de toute la session (acceptEdits accepte automatiquement les modifications de fichiers ; plan force le mode recherche en lecture seule). Pour des exécutions reproductibles, --bare démarre une session minimale qui saute les extras auto-découverts — pas de hooks, skills, subagents, plugins, serveurs MCP ni CLAUDE.md — la configuration arrivant alors explicitement via --settings, --mcp-config ou --append-system-prompt. C’est la réponse CI que l’examen veut : la même machine à chaque fois, aucun ordinateur portable de développeur qui fuit dedans, la provenance de chaque règle visible dans la commande.

La liste de contrôle de l’architecte suit par composition de tout ce qui précède : serveurs MCP à portée projet (.mcp.json) pour que le pipeline partage exactement les outils de l’équipe ; CLAUDE.md et settings commités pour que conseils et imposition voyagent avec le clone ; --permission-mode et --allowedTools explicites pour que le rayon d’action d’une exécution sans humain soit une décision, pas un accident ; sortie JSON analysée et raccordée au verdict du pipeline ; et l’histoire d’audit — les exécutions non interactives sont précisément celles qu’on viendra vous demander de justifier.

08Les pièges de ce domaine

• —« Mets-le dans CLAUDE.md, ce sera imposé. » CLAUDE.md conseille ; il n’impose pas. « Ne doit jamais » exige settings/permissions ou un hook — un mur, pas un vœu.
• —« Supprime AGENTS.md, on utilise CLAUDE.md de toute façon. » Le sens dangereux est l’inverse : ajouter un CLAUDE.md réduit au silence un AGENTS.md sur lequel le dépôt reposait discrètement.
• —« /compact avant d’attaquer la tâche suivante. » Mauvais instrument — une nouvelle tâche veut /clear (sectionner le fil) ; compacter sert à continuer la même avec moins de bagages.
• —« settings.local.json, c’est la base de l’équipe. » Il est personnel et gitignoré. Les bases d’équipe se committent : .claude/settings.json et CLAUDE.md de projet.
• —« Le mode plan fait perdre du temps ; on fait confiance à l’agent. » Le mode plan est la revue que vous achetez avant que le rayon d’action existe — exactement le point de contrôle que les pipelines sans humain doivent concevoir.
• —« Utilise --allowedTools Bash pour qu’il puisse committer. » Trop large : le drapeau prend la syntaxe des règles de permission, et Bash(git commit:*) borne la permission à la commande exacte. Des permissions sans portée, ce sont des incidents programmés pour les exécutions sans humain.