D7 · Claude Code - AI Cert Prep

Ce domaine représente environ 2 items sur 53. Il vérifie que vous savez comment Claude Code est configuré et exploité : la hiérarchie CLAUDE.md, les scopes et permissions de settings.json, la gestion de session, les slash commands, le mode headless, les hooks, la config MCP et le plan mode. Le thème : le comportement vient des fichiers de configuration, et les permissions/hooks – pas la prose – imposent le contrôle.

Objectifs d’apprentissage

À la fin de cette page, vous devriez être capable de :

Identifier les composants principaux de Claude Code : Rules/CLAUDE.md, Skills, Commands, Agents/subagents, Agent Memory.
Expliquer la hiérarchie CLAUDE.md et les imports @path.
Configurer les scopes de settings.json et les permissions (allow/deny/ask).
Gérer les sessions (/compact, /clear, resume) et utiliser les slash commands.
Utiliser les modes headless (-p, --output-format) et streaming et les modes de permission.
Configurer les hooks, MCP, et le plan mode.

7.1 Core components

Component	Where	Purpose
Rules / `CLAUDE.md`	Hiérarchie de fichiers	Instructions persistantes projet/utilisateur
Skills	`.claude/skills/<name>/SKILL.md`	Capacités progressives, à la demande (frontmatter name + description)
Commands	`.claude/commands/*.md`	Slash commands personnalisées avec `$ARGUMENTS`
Agents / subagents	`.claude/agents/*.md`	Propre prompt système, liste blanche d’outils, modèle ; contexte isolé
Agent Memory	`/memory`	Notes durables entre sessions

7.2 CLAUDE.md hierarchy and imports

Les fichiers CLAUDE.md sont de la mémoire : des instructions persistantes que Claude charge au démarrage de la session. Ils se composent du plus large au plus étroit, les fichiers plus spécifiques se superposant aux (sans remplacer les) plus larges. La politique managée est au sommet et ne peut pas être outrepassée.

What belongs where

Content	File	Reason
Règles de sécurité à l’échelle de l’org, outils interdits	managed policy	Ne doit pas être outrepassable par un développeur
Préférences personnelles (style d’éditeur, notes d’alias)	`~/.claude/CLAUDE.md`	S’applique à vous sur tous les projets
Standards de code d’équipe, architecture, commandes build/test	`./CLAUDE.md`	Committé ; source unique de vérité de l’équipe
Conventions spécifiques à un module (p. ex. règles de la couche API)	`./services/api/CLAUDE.md`	Chargé seulement en travaillant dans ce sous-arbre
Vos notes de travail locales, instructions expérimentales	`CLAUDE.local.md`	Git-ignored ; jamais partagé
Standards partagés référencés depuis plusieurs endroits	fichier séparé via import `@path`	Écrire une fois, importer dans le `CLAUDE.md` du projet
Secrets, tokens, clés d’API	aucun de ce qui précède	Sous gestion de versions ; utilisez `env` / un gestionnaire de secrets

Example project CLAUDE.md

Les secrets ne vont jamais dans CLAUDE.md

CLAUDE.md est sous gestion de versions et partagé. Mettez les secrets dans des variables d’environnement ou un gestionnaire de secrets et référencez-les par nom. Une clé fuitée dans CLAUDE.md est un incident d’exfiltration.

7.3 settings.json scopes and permissions

settings.json contrôle le comportement (modèle, permissions, hooks, environnement). Comme la mémoire, il se compose à travers les scopes, et la politique managée ne peut pas être outrepassée.

Un settings.json de projet committé avec permissions, hooks, et env :

permissions.allow exécute l’outil sans demander ; ask demande confirmation ; deny bloque catégoriquement.
deny l’emporte sur allow. Un outil correspondant aux deux est refusé.
Les règles sont des patterns, p. ex. Bash(rm -rf:*) refuse cette famille de commandes tout en autorisant les autres Bash.
Préférez le refus par défaut pour les commandes destructrices ; gardez allow aux outils dont une tâche a réellement besoin.

Signal d’examen

« Imposer une règle / bloquer une commande / personne ne peut outrepasser » → permissions + managed policy, pas une phrase dans CLAUDE.md. La prose est une consigne ; les permissions et hooks sont de l’application.

7.4 Hooks

Les hooks sont des handlers déterministes shell ou HTTP qui se déclenchent sur des événements du cycle de vie. Contrairement aux instructions en prose, ils s’exécutent toujours et peuvent bloquer une action — le mécanisme pour imposer les règles métier critiques (l’anti-pattern nº 3 consiste à imposer les règles en prose à la place).

Event	Fires when	Typical use
`PreToolUse`	Avant l’exécution d’un outil	Valider/bloquer une commande ; `exit 2` la refuse
`PostToolUse`	Après l’exécution d’un outil	Auto-format, lint, exécuter les tests sur les fichiers édités
`UserPromptSubmit`	L’utilisateur soumet un prompt	Injecter du contexte ; scanner les secrets
`Stop`	L’agent principal a fini de répondre	Imposer des contrôles d’achèvement
`SubagentStop`	Un subagent termine	Valider la sortie du subagent
`SessionStart`	La session commence	Charger des infos d’environnement, afficher des rappels
`Notification`	Claude envoie une notification	Router vers Slack/paging
`PreCompact`	Avant la compaction du contexte	Persister l’état qui doit survivre à la compaction

Le code de sortie 2 d’un hook bloque l’action (stderr est montré à Claude) ; les autres codes non nuls sont des erreurs non bloquantes.

7.5 Skills vs slash commands vs subagents

Trois façons d’empaqueter un comportement réutilisable. L’examen teste laquelle convient à un scénario.

Dimension	Skill	Slash command	Subagent
Fichier	`.claude/skills/<name>/SKILL.md`	`.claude/commands/<name>.md`	`.claude/agents/<name>.md`
Déclencheur	Le modèle le charge à la demande quand pertinent	L’utilisateur tape `/<name>` explicitement	Une tâche lui est déléguée (auto ou explicite)
Contexte	Progressif ; chargé seulement quand nécessaire	Injecté dans le contexte courant	Isolé dans sa propre fenêtre de contexte
Propre prompt système / modèle	Non	Non	Oui (propre prompt, liste blanche d’outils, modèle)
Idéal pour	Une capacité vers laquelle Claude devrait aller automatiquement	Un prompt répétable que vous invoquez à la main	Un worker spécialisé nécessitant de l’isolation

Skill (.claude/skills/api-docs/SKILL.md) :

Slash command avec $ARGUMENTS (.claude/commands/fix-issue.md) :

Invoquez avec /fix-issue 482 — $ARGUMENTS devient 482.

Subagent (.claude/agents/reviewer.md) :

Signal d’examen

« Se charge automatiquement quand pertinent / divulgation progressive » → Skill. « Une commande que le développeur exécute avec un argument » → slash command avec $ARGUMENTS. « A besoin de son propre contexte / d’outils restreints / d’un modèle différent / d’isolation » → subagent.

7.6 Plan mode

Le plan mode (entrez avec Shift+Tab, ou --permission-mode plan en headless) fait explorer Claude en lecture seule et produire un plan avant qu’il n’édite quoi que ce soit. C’est la première étape sûre pour les changements importants ou risqués : une migration, un refactoring transversal, ou du code non familier. Vous relisez le plan, puis approuvez l’exécution.

L’examen associe le plan mode aux grandes migrations automatisées et à la réduction des risques : explorer → planifier → approuver → appliquer avec des tests.

7.7 Headless mode, streaming and permission modes

# One-shot, sortie exploitable par machine pour la CI
claude -p "Summarise the failing tests" --output-format json

# Événements JSON en streaming (parser incrémentalement)
claude -p "Refactor utils" --output-format stream-json --allowedTools "Read,Edit"

# Revue en lecture seule avec un ensemble d'outils restreint
claude -p "Review the staged diff for security issues; output JSON." \
  --output-format json \
  --allowedTools "Read,Grep" \
  --permission-mode plan

-p s’exécute de manière non interactive ; --output-format vaut json ou stream-json ; --allowedTools restreint l’ensemble d’outils ; --permission-mode fixe le comportement de contrôle.

--permission-mode (ou permissionMode dans le SDK) :

Mode	Behaviour
`default`	Demander avant les outils non listés en allow
`acceptEdits`	Auto-accepter les éditions de fichiers, protéger les autres outils
`plan`	Lecture seule ; explorer et planifier, aucun changement
`bypassPermissions`	Sauter toutes les invites — dangereux ; uniquement dans une CI de confiance, sandboxée

Shift+Tab en interactif entre en plan mode : exploration en lecture seule, puis un plan proposé que vous approuvez avant tout changement. L’équivalent headless est --permission-mode plan.

Signal d’examen

« Exécuter Claude Code en CI / de manière non interactive / sortie exploitable par machine » → headless -p avec --output-format json|stream-json et un --allowedTools restreint. « Explorer en toute sécurité avant de changer quoi que ce soit » → plan mode. Jamais bypassPermissions en dehors d’un sandbox de confiance.

7.8 Session commands and MCP configuration

Slash commands pendant une session interactive :

Command	Effect
`/compact`	Résumer la conversation côté serveur pour libérer du contexte (garde le fil narratif)
`/clear`	Réinitialiser entièrement la conversation (contexte neuf)
`/init`	Amorcer un `CLAUDE.md` pour le projet courant
`/memory`	Voir/éditer la mémoire de l’agent (fichiers `CLAUDE.md`)
`/agents`	Gérer les subagents
`/hooks`	Gérer les hooks
`/mcp`	Gérer/inspecter les serveurs MCP et l’auth
`/cost`	Afficher l’usage en tokens et le coût pour la session

/compact résume pour préserver le fil narratif ; /clear jette le contexte — ne les confondez pas.

MCP config scopes

Ajoutez des serveurs avec claude mcp add <name> --scope <scope> -- <command> ou en éditant .mcp.json :

Scope	Stored in	Shared?
`local`	Votre machine, projet courant uniquement	Non (personnel, ce projet)
`project`	`.mcp.json` dans le dépôt	Oui — committé, catalogue validé à l’échelle de l’équipe
`user`	Votre config utilisateur	Non — s’étend à vos projets, personnel

Utilisez le scope project pour un catalogue partagé et validé ; inspectez et authentifiez avec /mcp.

7.9 The permission model in depth: allow / ask / deny and precedence

Le contrôle d’outils de Claude Code est une surface de décision petite mais fortement testée. Les règles sont des patterns, elles se composent à travers les scopes, et deny l’emporte sur allow ; la politique managée surplombe tout.

Decision	Meaning	Use for
`allow`	Exécuter sans demander	Outils sûrs et fréquemment utilisés (Read, Grep, Glob)
`ask`	Demander confirmation	Outils à risque moyen (Bash, WebFetch)
`deny`	Bloquer catégoriquement (l’emporte sur `allow`)	Familles de commandes destructrices, lecture de `.env`

Scenario	Correct configuration
Bloquer `rm -rf` pour tout le monde, de manière non outrepassable	`Bash(rm -rf:)` dans `deny`, défini via managed policy*
Auto-exécuter les outils de lecture, confirmer le shell	`allow: [Read, Grep, Glob]`, `ask: [Bash]`
Ne jamais lire le fichier de secrets	`deny: [Read(./.env)]`
Expérience personnelle uniquement	`settings.local.json` (git-ignored)

Signal d’examen

« Personne ne peut outrepasser ce blocage » → managed policy deny. « Un outil est à la fois dans allow et deny » → refusé (deny l’emporte sur allow). « Imposer une règle » → permissions/hooks, jamais une phrase de CLAUDE.md.

7.10 Composing memory and settings across scopes

CLAUDE.md (mémoire) et settings.json (comportement) se composent tous deux du large au étroit, et sont tous deux surplombés par une politique managée non outrepassable. Savoir ce qui va où est un item fréquent.

Layer	`CLAUDE.md` (memory)	`settings.json` (behaviour)
Managé / entreprise	Règles de sécurité de l’org, outils interdits (non outrepassable)	Permissions/hooks managés (non outrepassable)
Utilisateur (`~/.claude/`)	Préférences personnelles sur tous les projets	Défauts personnels de modèle/permission
Projet (`./`, `.claude/`)	Standards d’équipe, commandes build/test (committé)	Permissions de base d’équipe, hooks, env (committé)
Sous-répertoire / local	Règles de module ; `CLAUDE.local.md` (git-ignored)	`settings.local.json` (git-ignored)

Les secrets n’appartiennent à aucun des deux — utilisez des variables d’env / un gestionnaire de secrets.
Les imports @path tirent des fichiers partagés dans n’importe quel CLAUDE.md.
Un fichier de sous-répertoire se superpose aux (ne remplace pas les) fichiers plus larges en travaillant dans ce sous-arbre.

Les fichiers locaux sont personnels, pas de la politique d’équipe

CLAUDE.local.md et settings.local.json sont git-ignored et personnels. Mettre une règle que vous voulez que toute l’équipe suive dans un fichier local signifie que personne d’autre ne l’obtient — utilisez des fichiers de projet committés ou une politique managée.

7.11 Common misconceptions

Misconception	Reality	Why it matters on the exam
Une phrase de `CLAUDE.md` impose une règle	La prose est une consigne ; l’application est permissions/hooks	Anti-pattern nº 3 sous forme Claude Code
Les settings de projet peuvent outrepasser la politique managée	La politique managée/entreprise est non outrepassable	Questions de précédence
`allow` l’emporte si un outil est aussi refusé	`deny` l’emporte sur `allow`	Piège de résolution de permissions
`bypassPermissions` convient par commodité	Uniquement dans une CI de confiance, sandboxée ; il supprime les garde-fous	Piège de sécurité
`/compact` et `/clear` sont interchangeables	Compact résume (garde le fil) ; clear réinitialise	Piège de gestion de session
Les secrets peuvent vivre dans `CLAUDE.md` comme documentation	Il est sous gestion de versions ; utilisez env/gestionnaire de secrets	Piège d’hygiène des secrets
Une slash command se charge automatiquement	Les slash commands sont invoquées par l’utilisateur ; les Skills se chargent à la demande	Skill vs command vs subagent
`CLAUDE.local.md` est un bon endroit pour les règles d’équipe	Il est git-ignored et personnel	Piège de scope

7.12 Scenario walkthrough: hardening a shared Claude Code setup for CI

Scénario. Une équipe utilise Claude Code à la fois en interactif et en CI. La sécurité exige que rm -rf, git push --force, et la lecture de .env soient bloqués pour tout le monde et ne puissent pas être outrepassés par un développeur. La CI doit s’exécuter de manière non interactive, produire une sortie exploitable par machine, et ne lire que le code (aucune édition). Les développeurs demandent sans cesse bypassPermissions en CI « pour accélérer », et l’un a ajouté « never force-push » à ./CLAUDE.md en s’attendant à ce que ce soit imposé. Concevez la configuration.

Trace de raisonnement d’expert.

Imposez les blocages de commandes destructrices de manière non outrepassable. Placez les patterns deny (Bash(rm -rf:*), Bash(git push --force:*), Read(./.env)) dans la managed policy pour qu’aucun fichier user/project/local ne puisse les outrepasser ; deny l’emporte sur allow. La phrase de ./CLAUDE.md est de la prose, pas de l’application (anti-pattern nº 3) — elle doit être retirée comme un faux sentiment de sécurité et remplacée par la règle de permission.
Configurez correctement la CI. Headless claude -p "..." --output-format json avec un --allowedTools "Read,Grep,Glob" explicite et --permission-mode plan (lecture seule). C’est exploitable par machine, non interactif et sans édition.
Rejetez bypassPermissions. Il supprime précisément les garde-fous requis et laisserait une étape compromise ou injectée exécuter des commandes destructrices ; ne l’autorisez qu’à l’intérieur d’une automatisation entièrement de confiance et sandboxée — pas la CI générale ici.
Placez les règles d’équipe dans le bon scope. Les standards de code et les commandes build/test vont dans un ./CLAUDE.md committé ; les blocages de sécurité vont dans la managed policy ; les expériences personnelles vont dans un CLAUDE.local.md/settings.local.json git-ignored.
Rejetez les alternatives tentantes. « Faire confiance à la règle de CLAUDE.md » — la prose n’est pas de l’application. « Utiliser bypassPermissions pour la vitesse » — supprime les garde-fous. « Ajouter le blocage seulement aux settings de projet » — un développeur pourrait l’outrepasser localement, donc ce doit être de la managed policy.

Décision correcte. Patterns deny en managed policy pour les commandes destructrices et .env ; CI headless avec --output-format json, une liste blanche --allowedTools en lecture seule, et --permission-mode plan ; pas de bypassPermissions en dehors d’un sandbox de confiance ; standards d’équipe dans un CLAUDE.md committé, éléments personnels dans des fichiers locaux git-ignored.

Pièges de l’examen dans ce domaine

Piège	Pourquoi c’est faux
Mettre des secrets dans `CLAUDE.md`	Il est sous gestion de versions ; utilisez env/gestionnaire de secrets
Supposer que le `CLAUDE.md` de projet outrepasse la politique managée	La politique managée/entreprise l’emporte et n’est pas outrepassable
Utiliser `bypassPermissions` à la légère	Supprime les garde-fous ; uniquement en automatisation de confiance, sandboxée
Imposer les règles dans la prose de `CLAUDE.md` au lieu des permissions/hooks	La prose est une consigne, pas de l’application (anti-pattern nº 3)
Attendre des invites interactives en CI	Utilisez headless `-p` + `--output-format` + `--allowedTools`
Confondre `/compact` avec `/clear`	Compact résume et garde le fil ; clear réinitialise
Charger un énorme ensemble d’outils au lieu de subagents	Surcharge la sélection ; utilisez subagents + tool search
Oublier que `deny` l’emporte sur `allow`	Un outil dans les deux listes est refusé
Utiliser une slash command là où un Skill est nécessaire	Les Skills se chargent à la demande ; les commandes sont invoquées par l’utilisateur
Donner à un subagent des outils larges « au cas où »	Viole le moindre privilège ; cadrez la liste blanche
Mettre une règle dans `CLAUDE.local.md` pour toute l’équipe	Il est git-ignored et personnel ; utilisez committé/managé
Confondre les scopes MCP `local` et `project`	Seul `project` (`.mcp.json`) est partagé/committé
Mettre un blocage non outrepassable seulement dans les settings de projet	Un développeur peut l’outrepasser localement ; utilisez la managed policy
Supposer que `allow` l’emporte sur `deny`	`deny` l’emporte sur `allow` ; la résolution est deny > ask > allow
Imposer une règle de sécurité via une phrase de `./CLAUDE.md`	La prose est une consigne ; utilisez une permission `deny` ou un hook (anti-pattern nº 3)
Utiliser `bypassPermissions` en CI générale pour la vitesse	Supprime les garde-fous ; uniquement dans un sandbox entièrement de confiance
Stocker les standards d’équipe dans `settings.local.json`	Il est git-ignored et personnel ; utilisez les settings de projet committés

Questions d’entraînement

Q1 · Une équipe exécute Claude Code dans un pipeline CI et a besoin de résultats exploitables par machine sans invites interactives. Quelle invocation convient ? (Sélectionnez une réponse)

A. claude interactif avec plan mode. B. claude -p "..." --output-format json avec une liste blanche --allowedTools explicite. C. claude avec bypassPermissions et sans format de sortie. D. Ouvrir Claude Desktop.

Réponse : B. Headless -p avec --output-format json et une liste blanche d’outils est le pattern CI. Le plan mode interactif (A) et Desktop (D) ne sont pas headless et ne peuvent pas s’exécuter sans surveillance ; bypassPermissions (C) supprime les garde-fous et donne une sortie non structurée que la CI ne peut pas parser.

Q2 · Une politique d’entreprise managée interdit l’outil Bash, mais un `CLAUDE.md` de projet dit de l’utiliser et `settings.local.json` l’autorise. Que se passe-t-il ? (Sélectionnez une réponse)

A. Le setting de projet l’emporte. B. Le setting local l’emporte. C. La politique managée l’emporte et Bash reste refusé. D. C’est indéfini.

Réponse : C. La politique managée/entreprise est au sommet de la précédence et ne peut pas être outrepassée par la config user, project ou local. La prose dans CLAUDE.md (A) n’est pas de l’application, et un fichier local (B) ne peut pas outrepasser un deny managé ; le comportement est bien défini, pas indéfini (D).

Q3 · Un sous-répertoire `./services/api/CLAUDE.md` fixe une règle qui entre en conflit avec le `./CLAUDE.md` racine pendant que vous travaillez dans ce sous-arbre. Lequel s’applique, et pourquoi ? (Sélectionnez une réponse)

A. Le fichier racine l’emporte toujours car il est committé en premier. B. Le fichier de sous-répertoire plus spécifique se superpose pour le travail dans ce sous-arbre, tandis que le fichier racine contribue toujours ; la politique managée outrepasse encore les deux. C. Ni l’un ni l’autre ne s’applique ; vous devez les fusionner manuellement. D. Seul CLAUDE.local.md s’applique dans les sous-répertoires.

Réponse : B. La mémoire se compose du large à l’étroit : le fichier de sous-répertoire ajoute un contexte spécifique au module par-dessus le standard racine, et la politique managée reste non outrepassable au-dessus des deux. La racine ne l’emporte pas simplement (A) ; les fichiers se composent automatiquement plutôt que d’exiger une fusion manuelle (C) ; CLAUDE.local.md est un override personnel git-ignored, pas le mécanisme général (D).

Q4 · Une équipe veut qu’une famille de commandes destructrices comme `rm -rf` soit bloquée de manière déterministe pour tout le monde, et veut aussi que le blocage soit imposé même si un développeur tente de l’autoriser. Quelles DEUX étapes réalisent cela ? (Sélectionnez deux réponses)

A. Ajouter Bash(rm -rf:*) à permissions.deny dans le .claude/settings.json committé. B. Écrire « never run rm -rf » dans ./CLAUDE.md. C. Imposer le deny via la managed policy pour qu’il ne puisse pas être outrepassé. D. Ajouter un hook PostToolUse pour s’excuser après l’exécution de la commande. E. Demander aux développeurs d’être prudents.

Réponse : A et C. Un pattern deny bloque la famille de commandes de manière déterministe (deny l’emporte sur allow), et le mettre en managed policy le rend non outrepassable. La prose dans CLAUDE.md (B) est une consigne, pas de l’application ; un hook PostToolUse (D) se déclenche après les dégâts ; demander aux développeurs (E) n’est pas un contrôle.

Q5 · Vous voulez que Claude aille automatiquement chercher un style maison documenté chaque fois qu’il écrit de la documentation de référence d’API, sans que le développeur ait à invoquer quoi que ce soit. Quel composant convient ? (Sélectionnez une réponse)

A. Une slash command dans .claude/commands/. B. Un Skill (.claude/skills/api-docs/SKILL.md) avec un name et une description, chargé à la demande. C. Un subagent avec son propre modèle. D. Une ligne dans settings.local.json.

Réponse : B. Les Skills se chargent progressivement et automatiquement quand leur description correspond à la tâche — exactement « y aller quand c’est pertinent ». Une slash command (A) doit être tapée par l’utilisateur ; un subagent (C) sert au travail délégué isolé avec son propre contexte ; un fichier de settings (D) ne porte pas de contenu de capacité rédigé.

Q6 · Un développeur veut que `/fix-issue 482` investigue et corrige l’issue GitHub 482. Comment le numéro d’issue est-il passé dans la définition de la commande ? (Sélectionnez une réponse)

A. Il est lu automatiquement depuis une variable d’environnement. B. Via $ARGUMENTS dans le fichier .claude/commands/fix-issue.md. C. Par la liste blanche d’outils du subagent. D. Il ne peut pas prendre d’arguments ; les commandes sont statiques.

Réponse : B. Les slash commands personnalisées substituent le texte après le nom de la commande dans $ARGUMENTS. Ce n’est pas une variable d’env (A) ; la liste blanche d’outils (C) régit les permissions du subagent, pas les arguments de commande ; les commandes acceptent bien des arguments (D).

Q7 · Un subagent reviewer devrait lire et analyser du code mais ne doit jamais modifier de fichiers, et devrait utiliser un modèle plus puissant pour le jugement. Quelle configuration est correcte ? (Sélectionnez une réponse)

A. tools: Read, Grep, Glob et model: claude-opus-5 dans .claude/agents/reviewer.md. B. Lui donner tous les outils et se fier à un prompt disant « do not edit ». C. Le mettre dans .claude/commands/ avec $ARGUMENTS. D. Régler bypassPermissions pour qu’il s’exécute sans friction.

Réponse : A. Un subagent prend une liste blanche d’outils explicite et son propre modèle ; le restreindre aux outils de lecture impose la règle no-edit, et Opus 5 fournit un jugement plus solide. Une règle par prompt seul (B) n’est pas de l’application ; une slash command (C) n’est pas un agent isolé ; bypassPermissions (D) supprime précisément les garde-fous voulus.

Q8 · Pendant une longue session, le contexte est presque plein mais le développeur veut garder le fil de travail et continuer. Quelle commande est appropriée, et en quoi diffère-t-elle de l’alternative ? (Sélectionnez une réponse)

A. /clear, car elle libère le plus d’espace. B. /compact, qui résume côté serveur en préservant le fil narratif ; /clear jetterait entièrement la conversation. C. /init, pour reconstruire le contexte. D. /memory, pour effacer les anciens tours.

Réponse : B. /compact résume pour libérer du contexte tout en gardant la continuité ; /clear réinitialise tout et perd le fil narratif. /init (C) amorce un CLAUDE.md ; /memory (D) édite les fichiers de mémoire, pas la transcription en direct.

Q9 · Une équipe veut un ensemble validé de serveurs MCP partagé à travers le dépôt et committé sous gestion de versions. Quel scope devrait-elle utiliser ? (Sélectionnez une réponse)

A. Le scope local. B. Le scope user. C. Le scope project via .mcp.json, committé dans le dépôt. D. Il n’y a aucun moyen de partager des serveurs MCP.

Réponse : C. Le scope projet stocke les serveurs dans .mcp.json dans le dépôt, rendant un catalogue partagé et validé disponible à l’échelle de l’équipe. local (A) est personnel à une machine/un projet ; user (B) ne s’étend qu’à vos propres projets ; le partage est clairement possible (D).

Q10 · Avant une grande migration automatisée sur de nombreux fichiers, quelle est la première étape la plus sûre dans Claude Code ? (Sélectionnez une réponse)

A. Appliquer toutes les éditions immédiatement, puis relire le diff. B. Utiliser le plan mode (Shift+Tab ou --permission-mode plan) pour explorer en lecture seule et produire un plan, puis approuver et appliquer avec des tests. C. Régler bypassPermissions pour aller vite. D. Supprimer les tests pour éviter le bruit.

Réponse : B. Le plan mode explore sans éditer et fournit un plan relisible, réduisant le rayon d’impact sur les grands changements. Appliquer à l’aveugle (A), contourner les permissions (C), et retirer les tests (D) augmentent tous le risque.

Q11 · Quelles DEUX pratiques imposent correctement une règle critique et gèrent l’accès aux outils dans Claude Code ? (Sélectionnez deux réponses)

A. Un hook PreToolUse qui sort avec le code 2 pour bloquer une commande interdite. B. Un pattern permissions.deny pour la commande interdite. C. Un paragraphe dans CLAUDE.md décrivant la règle. D. tool_choice défini dans le texte du prompt. E. Faire confiance au modèle pour se souvenir de l’instruction.

Réponse : A et B. Un hook PreToolUse renvoyant le code de sortie 2 bloque l’action de manière déterministe, et un pattern deny refuse l’outil catégoriquement — les deux sont de l’application. La prose dans CLAUDE.md (C) et le recours à la mémoire (E) sont des consignes, pas du contrôle ; tool_choice (D) est un paramètre d’API, pas un mécanisme de permission de Claude Code.

Q12 · Un développeur veut des instructions expérimentales personnelles qui ne doivent jamais être committées ni partagées avec les collègues. Où appartiennent-elles ? (Sélectionnez une réponse)

A. ./CLAUDE.md. B. Managed policy. C. CLAUDE.local.md (git-ignored) ou settings.local.json. D. .mcp.json.

Réponse : C. CLAUDE.local.md et settings.local.json sont des overrides personnels git-ignored — le bon foyer pour les expériences non partagées. ./CLAUDE.md (A) est committé et partagé ; la managed policy (B) est à l’échelle de l’org et non outrepassable ; .mcp.json (D) configure les serveurs MCP, pas les instructions.

Q13 · Un outil correspond à la fois à un pattern `allow` et à un pattern `deny` dans les settings résolus. Que se passe-t-il ? (Sélectionnez une réponse)

A. allow l’emporte car il est listé en premier. B. deny l’emporte ; la résolution est deny > ask > allow. C. L’outil demande à l’utilisateur à chaque fois. D. Le comportement est indéfini.

Réponse : B. deny l’emporte sur allow dans la résolution des permissions. L’ordre ne décide pas (A) ; il est refusé, pas une invite ask (C) ; et le comportement est bien défini (D).

Q14 · La sécurité a besoin que `rm -rf` soit bloqué pour tout le monde sans qu’aucun développeur puisse l’outrepasser. Où la règle `deny` doit-elle vivre ? (Sélectionnez une réponse)

A. Dans le settings.local.json de chaque développeur. B. Dans la politique managée/entreprise, qui est non outrepassable et l’emporte sur allow. C. Dans ./CLAUDE.md comme une phrase. D. Dans un hook PostToolUse.

Réponse : B. Seule la managed policy est non outrepassable par la config user/project/local. Les fichiers locaux (A) peuvent être modifiés par le développeur ; une phrase de CLAUDE.md (C) est de la prose, pas de l’application ; un hook PostToolUse (D) se déclenche après l’exécution de la commande.

Q15 · Un job CI doit s’exécuter de manière non interactive, produire des résultats exploitables par machine, et ne jamais éditer de fichiers. Quelle invocation convient le MIEUX ? (Sélectionnez une réponse)

A. claude interactif avec plan mode. B. claude -p "..." --output-format json --allowedTools "Read,Grep,Glob" --permission-mode plan. C. claude -p "..." --permission-mode bypassPermissions. D. Claude Desktop avec MCP.

Réponse : B. Headless -p avec sortie JSON, une liste blanche en lecture seule, et plan mode est non interactif, exploitable par machine et sans édition. Le plan mode interactif (A) et Desktop (D) ne sont pas headless ; bypassPermissions (C) supprime les garde-fous et ne garantit pas la lecture seule.

Q16 · Un développeur ajoute « never force-push » à `./CLAUDE.md` et s’attend à ce que ce soit imposé. Pourquoi est-ce insuffisant, et que devrait-il faire ? (Sélectionnez une réponse)

A. C’est suffisant ; les règles de CLAUDE.md sont imposées. B. CLAUDE.md est une consigne, pas de l’application ; ajoutez Bash(git push --force:*) à permissions.deny (idéalement via la managed policy) ou un hook PreToolUse. C. Déplacer la phrase dans settings.local.json. D. Augmenter le niveau d’effort du modèle.

Réponse : B. La prose dans CLAUDE.md est une suggestion (anti-pattern nº 3 sous forme Claude Code) ; un pattern deny ou un hook PreToolUse l’impose de manière déterministe. Ce n’est pas suffisant (A) ; un fichier local (C) est personnel et n’est pas de l’application ; l’effort (D) est sans rapport.

Q17 · Pendant une longue session, le contexte est presque plein mais le développeur doit garder le fil de travail. Quelle commande convient, et en quoi diffère-t-elle de l’alternative ? (Sélectionnez une réponse)

Réponse : B. /compact résume pour libérer du contexte tout en gardant la continuité ; /clear réinitialise tout. /init (C) amorce un CLAUDE.md ; /memory (D) édite les fichiers de mémoire, pas la transcription en direct.

Q18 · Une équipe veut des standards de code partagés avec tout le monde, mais un développeur a besoin d’une instruction expérimentale personnelle qui ne doit jamais être committée. Où appartient chacun ? (Sélectionnez une réponse)

A. Les deux dans ./CLAUDE.md. B. Les standards dans un ./CLAUDE.md committé ; l’expérience personnelle dans un CLAUDE.local.md git-ignored. C. Les deux dans settings.local.json. D. Les deux dans la managed policy.

Réponse : B. Les standards d’équipe vont dans le fichier de projet committé ; les instructions personnelles non partagées vont dans le fichier local git-ignored. Mettre l’élément personnel dans ./CLAUDE.md (A) le partage ; les fichiers locaux (C) cacheraient les standards d’équipe aux autres ; la managed policy (D) est pour les règles d’org non outrepassables, pas les expériences personnelles.

À retenir

Composants principaux : Rules/CLAUDE.md, Skills, Commands, Agents/subagents, Agent Memory.
La précédence de CLAUDE.md se compose du large à l’étroit : managed → user → project → subdirectory ; CLAUDE.local.md est git-ignored ; les imports @path tirent des fichiers partagés ; les secrets n’appartiennent jamais ici.
settings.json se compose à travers les mêmes scopes ; permissions (allow/ask/deny) imposent les outils de manière déterministe ; deny l’emporte sur allow et la politique managée est non outrepassable.
Les hooks (PreToolUse, PostToolUse, UserPromptSubmit, Stop, SubagentStop, SessionStart, Notification, PreCompact) sont déterministes ; le code de sortie 2 bloque l’action — la façon d’imposer les règles critiques plutôt que la prose.
Skill = capacité auto/progressive ; slash command = prompt invoqué par l’utilisateur avec $ARGUMENTS ; subagent = contexte isolé avec son propre prompt, sa liste blanche d’outils et son modèle.
Le plan mode explore en lecture seule et propose un plan avant les éditions — la première étape sûre pour les changements importants/risqués.
Headless -p + --output-format json|stream-json + --allowedTools + --permission-mode pour la CI ; bypassPermissions uniquement dans un sandbox de confiance.
Commandes de session : /compact (résumer, garder le fil) vs /clear (réinitialiser) ; /init, /memory, /agents, /hooks, /mcp, /cost. Scopes MCP : local (personnel), project (.mcp.json, partagé/committé), user (vos projets).
La résolution des permissions est deny > ask > allow, se composant du large à l’étroit, avec la politique managée non outrepassable — un blocage non outrepassable doit vivre en managed policy, pas dans les settings de projet ou locaux.
CLAUDE.md et settings.json se composent tous deux à travers les mêmes scopes ; les standards d’équipe vont dans des fichiers de projet committés, les éléments personnels dans des fichiers locaux git-ignored, et les secrets dans aucun.
Une règle que vous voulez imposée est un pattern deny ou un hook, jamais une phrase de CLAUDE.md (anti-pattern nº 3 sous forme Claude Code).