03 · Configurer Claude Code et ses workflows

Version : 1.1 · Date : 2026-10-21 · Domaine 3 : Claude Code Configuration & Workflows (20 %)

En une phrase : Claude Code se configure en couches (CLAUDE.md et rules pour les consignes, skills pour les procédures, subagents pour isoler le travail, settings et hooks pour les garanties) ; l'architecte choisit la bonne couche, le bon niveau (partagé ou personnel), le bon mode (plan ou exécution directe) et sait faire tourner Claude Code sans humain dans une CI.

Ce que l'examen demande#

Les 6 task statements du domaine 3, mot pour mot (guide officiel CCAR-F v1.0, juillet 2026) :

Le domaine 3 est au cœur de deux des six scénarios officiels : Scenario 2 « Code Generation with Claude Code » (slash commands, CLAUDE.md, plan mode ou direct execution) et Scenario 5 « Claude Code for Continuous Integration » (revues automatiques, génération de tests, retours sur PR avec peu de faux positifs). Il revient aussi dans le Scenario 4 (Developer Productivity with Claude). Les scénarios complets sont dans 06-scenarios-examen.md.

Comment lire les encadrés « Réponse d'examen / État actuel » : le produit a évolué depuis la rédaction du guide (v1.0). À l'examen, on répond selon le guide. Dans la vie réelle, on applique l'état actuel, vérifié sur la documentation officielle le 21/10/2026.

1. Les bases : où vit la configuration de Claude Code#

1.1 Les briques et ce qu'elles garantissent#

La règle d'or, écrite noir sur blanc dans la doc : CLAUDE.md et la mémoire sont du contexte, pas une configuration appliquée. « To block an action regardless of what Claude decides, use a PreToolUse hook instead. » Une règle qui doit toujours s'appliquer (interdire terraform apply, imposer un formateur) va dans les permissions ou un hook, pas dans CLAUDE.md. Les hooks sont détaillés au chapitre 01 (TS 1.4 et 1.5).

1.2 Partagé ou personnel : .claude/ contre ~/.claude/#

Un seul motif à retenir, valable pour CLAUDE.md, rules, skills, commands, agents et settings :

1.3 Settings : précédence et permissions#

Quand une même clé est définie à plusieurs niveaux, la plus haute gagne : managed settings > command line (--settings) > project local (.claude/settings.local.json) > shared project (.claude/settings.json) > user (~/.claude/settings.json). Exceptions à connaître :

• les listes se combinent au lieu de s'écraser : un permissions.allow de l'équipe et le vôtre s'additionnent ;
• les règles de permission sont évaluées deny, puis ask, puis allow, quel que soit le niveau : un deny utilisateur bloque un allow projet, et un allow plus précis ne crée pas d'exception dans un deny ;
• les managed settings (déployés par l'organisation) ne peuvent pas être contournés ; le managed CLAUDE.md ne peut pas être exclu.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": ["Bash(terraform fmt *)", "Bash(npm run test *)"],
    "deny":  ["Read(./.env)", "Read(./.env.*)", "Bash(terraform apply *)"]
  }
}

Fichier .claude/settings.json commité : toute l'équipe peut formater et tester sans invite, personne ne lit les .env ni ne lance un terraform apply. Les allow d'un fichier commité attendent que chaque coéquipier ait accordé sa confiance au dossier ; les deny et ask s'appliquent tout de suite. Pour vérifier ce qui est chargé : /status (ligne Setting sources).

2. CLAUDE.md : hiérarchie, portée et organisation#

2.1 Les niveaux#

Le guide officiel ne cite que user, project et directory : ce sont les trois niveaux à connaître parfaitement pour l'examen. Le managed et le local sont des compléments réels.

2.2 Comment ils se chargent#

• Au lancement, Claude Code lit le CLAUDE.md (et le CLAUDE.local.md) du répertoire de travail et de chaque répertoire parent. Lancé dans foo/bar/, il charge foo/CLAUDE.md et foo/bar/CLAUDE.md.
• Les CLAUDE.md des sous-répertoires ne sont pas chargés au lancement : chacun est chargé à la demande, dès que Claude lit, écrit ou modifie un fichier de ce sous-répertoire.
• Tous les fichiers trouvés sont concaténés, ils ne s'écrasent pas. Ordre : du plus large au plus précis (managed, user, puis de la racine vers le répertoire de travail ; dans chaque dossier, CLAUDE.local.md après CLAUDE.md).
• Être lu en dernier ne donne pas la priorité : « if two instructions contradict each other, Claude may pick one arbitrarily ». On élimine les contradictions au lieu de compter sur l'ordre.

flowchart TD
    A["Une consigne pour Claude Code"] --> B{"Doit-elle s'appliquer<br/>à coup sûr ?"}
    B -- Oui --> H["Permission deny/ask ou hook<br/>(settings.json)"]
    B -- Non --> C{"Pour toute l'équipe ?"}
    C -- Non --> P["~/.claude/CLAUDE.md<br/>ou CLAUDE.local.md"]
    C -- Oui --> D{"Toujours utile,<br/>à chaque session ?"}
    D -- Non --> S["Skill dans .claude/skills/<br/>(procédure à la demande)"]
    D -- Oui --> E{"Seulement pour certains<br/>types de fichiers ?"}
    E -->|"Oui, éparpillés"| R["Rule .claude/rules/ avec paths"]
    E -->|"Oui, un seul dossier"| SD["CLAUDE.md du sous-dossier"]
    E -- Non --> PR["CLAUDE.md du projet"]

2.3 Rester modulaire : les imports @path#

Un CLAUDE.md peut importer d'autres fichiers avec @chemin/vers/fichier, sur sa propre ligne :

# Projet plateforme

- Build : `npm run build` ; tests : `npm run test -- --watch=false`
- Standards de nommage : @docs/standards/naming.md
- Conventions de l'API : @packages/api/API-CONVENTIONS.md

• Les chemins relatifs partent du fichier qui importe, pas du répertoire de travail ; les chemins absolus et ~/… sont permis ; les imports sont récursifs jusqu'à 4 niveaux.
• Un import qui sort du dépôt (vers ~/… par exemple) déclenche une demande d'approbation la première fois : protection contre les fichiers commités par d'autres.
• Un @chemin entre backticks n'est pas importé.
• Piège : importer ne réduit pas le contexte. Les fichiers importés sont chargés au lancement avec le CLAUDE.md qui les référence. Pour réduire le contexte, on utilise des rules avec paths (section 4).

L'usage visé par le guide : dans un monorepo, chaque package importe seulement les standards qui le concernent, selon la connaissance de ses mainteneurs.

2.4 Découper un gros CLAUDE.md : .claude/rules/#

Au lieu d'un CLAUDE.md monolithique, on range des fichiers thématiques dans .claude/rules/ : testing.md, api-conventions.md, deployment.md. Tous les .md sont découverts récursivement (sous-dossiers frontend/, backend/ permis). Sans frontmatter paths, une rule se charge à chaque session, comme le CLAUDE.md ; avec paths, elle devient conditionnelle (section 4). Des rules personnelles peuvent vivre dans ~/.claude/rules/.

2.5 Diagnostiquer : /memory, /context, /init#

Réponse d'examen : /memory sert à vérifier quels fichiers de mémoire sont chargés et à diagnostiquer un comportement incohérent d'une session à l'autre.

État actuel (21/10/2026) : /memory liste les emplacements (CLAUDE.md, CLAUDE.local.md, mémoire automatique), les ouvre dans l'éditeur et active ou coupe l'auto memory. La liste de ce qui a réellement été chargé au lancement est dans /context, rubrique Memory files. Aucune des deux commandes ne charge quoi que ce soit.

/init génère un CLAUDE.md de départ à partir du code (commandes de build, de test, conventions découvertes) ; s'il existe déjà, il propose des améliorations au lieu de l'écraser.

2.6 Ce qu'on met dans un CLAUDE.md#

Viser moins de 200 lignes par fichier : un CLAUDE.md trop long est moins bien suivi. Après /compact, le CLAUDE.md de la racine du projet est relu sur le disque et réinjecté ; les CLAUDE.md de sous-dossiers et les rules avec paths reviennent à la demande ; une consigne donnée seulement dans la conversation peut être perdue au résumé (voir le chapitre 05).

3. Slash commands et skills#

3.1 Commands et skills : un même mécanisme#

Réponse d'examen : les slash commands d'équipe se créent dans .claude/commands/ (partagés via git), les commandes personnelles dans ~/.claude/commands/ ; les skills vivent dans .claude/skills/ avec un SKILL.md.

État actuel : commands et skills sont fusionnés. Les deux fichiers ci-dessus créent la même commande /review ; .claude/commands/ fonctionne toujours, et en cas de conflit de nom, le skill gagne. Le skill est l'emplacement recommandé : il apporte un dossier de fichiers de support, le contrôle d'invocation et le chargement automatique. Un fichier .md posé à plat dans .claude/skills/ (sans dossier ni SKILL.md) ne crée aucune commande.

Entre emplacements, l'ordre de priorité d'un skill de même nom est : enterprise > personal > project (les skills de plugin ont leur propre espace de noms, /plugin-name:skill-name). C'est pourquoi le guide recommande de créer ses variantes personnelles sous un autre nom dans ~/.claude/skills/ : on garde son propre /review-strict sans masquer le /review de l'équipe pour soi-même, ni gêner ses coéquipiers.

3.2 Anatomie d'un skill#

---
name: review
description: Revue de la branche courante selon la checklist de l'équipe. À utiliser avant d'ouvrir une PR.
argument-hint: "[branche-de-base]"
allowed-tools: Read, Grep, Glob, Bash(git diff *)
---

Compare la branche courante à $ARGUMENTS (par défaut `main`) avec `git diff`.
Applique la checklist ci-dessous et rends une liste de constats : fichier, ligne, gravité, correction proposée.

1. Pas de secret, de clé ni de chaîne de connexion dans le code.
2. Chaque ressource Terraform nouvelle a ses tags obligatoires.
3. Les tests couvrent les cas limites listés dans `@reference/edge-cases.md`.

• Le frontmatter YAML est entre --- ; le corps est la procédure. Garder SKILL.md sous 500 lignes et déplacer le détail dans des fichiers de support du dossier (reference.md, scripts/), accessibles via ${CLAUDE_SKILL_DIR}.
• Chargement : la description (avec when_to_use) est toujours dans le contexte, pour que Claude sache que le skill existe et puisse l'appeler de lui-même ; le corps n'est chargé qu'à l'invocation (/review main, ou automatiquement si la demande correspond à la description).
• Substitutions utiles : $ARGUMENTS (tous les arguments), $0, $1… ; !`commande` exécute une commande avant l'envoi et injecte sa sortie.

3.3 Le frontmatter à connaître#

Réponse d'examen : allowed-tools restreint les outils ; argument-hint invite à fournir les paramètres.

État actuel : allowed-tools pré-approuve, disallowed-tools restreint ; argument-hint est un indice d'autocomplétion.

3.4 context: fork : isoler une sortie verbeuse#

À utiliser pour ce qui produit beaucoup de texte intermédiaire : analyse d'un code inconnu, brainstorming d'alternatives, inventaire d'un dépôt. La conversation principale ne reçoit que le résultat. Le corps du skill doit être une tâche autonome (le subagent ne voit pas la conversation) : un skill qui ne contient que des directives générales ne produit rien d'utile en fork.

---
name: explorer-alternatives
description: Propose 3 architectures possibles pour une fonctionnalité et compare-les. Sortie longue.
context: fork
disallowed-tools: Edit, Write
---

Pour la fonctionnalité décrite dans $ARGUMENTS : lis le code concerné, propose trois approches, compare-les
(complexité, coût d'exploitation, risques) et termine par une recommandation argumentée en 10 lignes maximum.

3.5 Quoi mettre où#

Un subagent (.claude/agents/security-reviewer.md, frontmatter name, description, tools, model…) contrôle son propre prompt système et charge, par défaut, la hiérarchie CLAUDE.md ; un skill context: fork injecte son contenu dans un agent existant. Les deux démarrent sans l'historique de la conversation. Le détail des subagents est au chapitre 01 (TS 1.2 et 1.3).

4. Path-specific rules : charger une convention seulement quand elle sert#

Une rule de .claude/rules/ avec un champ paths (liste de globs) ne se charge que lorsque Claude lit, écrit ou modifie un fichier qui correspond (outils Read, Write, Edit, ou un cat / head sur un seul fichier).

---
paths:
  - "terraform/**/*.tf"
  - "**/*.tfvars"
---

# Conventions Terraform

- Tout le nommage est construit dans `locals.tf`, jamais dans `main.tf`.
- Chaque variable a un `type` et une `description` ; `sensitive = true` sur les secrets.
- Jamais de `terraform apply` depuis Claude Code : seulement `terraform fmt`.

Pourquoi c'est la bonne réponse quand une convention concerne des fichiers éparpillés (tests à côté de leurs sources dans 50 dossiers) :

• un CLAUDE.md par dossier obligerait à dupliquer la convention 50 fois, avec une dérive certaine entre les copies ;
• le CLAUDE.md racine chargerait la convention à chaque session, même pour modifier un README : du contexte et des jetons gaspillés, et des consignes qui diluent les autres ;
• un skill demanderait une invocation : la rule, elle, s'active toute seule.

Le CLAUDE.md de sous-dossier reste le bon choix pour les conventions d'un seul dossier (le package api/).

5. Plan mode ou direct execution#

5.1 La règle de choix#

Le critère est l'incertitude sur l'approche, pas la difficulté :

Le plan mode permet d'explorer et de concevoir sans rien modifier, ce qui évite de reprendre un chantier mal parti. Si la complexité est connue dès l'énoncé, on choisit le plan mode d'emblée, sans attendre la première surprise.

5.2 Le mettre en œuvre#

• Entrer : Shift+Tab jusqu'à ⏸ plan mode on, préfixer un prompt par /plan, ou lancer claude --permission-mode plan ; "permissions": { "defaultMode": "plan" } dans .claude/settings.json en fait le mode par défaut d'un projet. Écrire « passe en plan mode » dans un prompt ne change pas le mode.
• Pendant : Claude lit les fichiers, lance des commandes d'exploration et écrit un plan, mais ne modifie pas les sources.
• Sortir : Claude présente le plan ; on approuve (Yes, and use auto mode, Yes, manually approve edits) ou on continue à planifier (No, keep planning). Ctrl+G ouvre le plan dans l'éditeur pour le corriger avant exécution.
• Approche hybride, celle que le guide attend souvent : planifier la migration (stratégie, ordre, cas particuliers), puis exécuter le plan approuvé en direct execution, fichier par fichier, avec des tests.

5.3 Explore subagent : garder le contexte principal propre#

Une découverte verbeuse (lire 80 fichiers pour comprendre un flux) remplit la fenêtre de contexte et dégrade la suite. Le subagent Explore, en lecture seule (Write et Edit refusés), mène cette recherche dans son propre contexte et ne renvoie qu'un résumé. En plan mode, Claude délègue la recherche au subagent intégré Plan, pour la même raison. Explore et Plan ne chargent pas les CLAUDE.md. Les stratégies d'exploration de gros dépôts sont au chapitre 05 (TS 5.4).

6. Iterative refinement : converger vers le bon résultat#

La première sortie est rarement la bonne. L'examen teste quelle technique choisir selon la situation :

flowchart TD
    A["Le résultat n'est pas celui attendu"] --> B{"Le développeur sait-il<br/>exactement ce qu'il veut ?"}
    B -- Non --> I["Interview pattern :<br/>faire poser les questions"]
    B -- Oui --> C{"Transformation simple<br/>mais mal comprise ?"}
    C -- Oui --> E["2-3 exemples entrée / sortie"]
    C -- Non --> T["Tests d'abord,<br/>puis itérer sur les échecs"]
    E --> D{"Plusieurs problèmes restants ?"}
    T --> D
    D -->|"Liés entre eux"| G["Un seul message groupé"]
    D -- Indépendants --> S["Corrections séquentielles"]

Pièges : continuer à reformuler la prose quand elle est mal interprétée (la dérive continue, il faut des exemples) ; corriger un par un des problèmes liés (chaque correctif vise un état que le suivant change) ; faire une interview alors que la transformation exacte est déjà connue. La doc ajoute deux réflexes utiles : donner à Claude un moyen de vérifier son travail (tests, build, capture) et, après deux corrections ratées sur le même point, faire /clear et repartir d'un meilleur prompt.

Exemple d'interview, recommandé par la doc pour les grosses fonctionnalités :

Je veux ajouter un cache devant l'API de tarification. Interroge-moi en détail avec l'outil AskUserQuestion :
implémentation, cas limites, modes de panne, compromis. Ne pose pas de questions évidentes. Quand tout est couvert,
écris la spécification complète dans SPEC.md.

7. Claude Code dans une CI/CD#

7.1 Le mode non interactif : -p#

En CI, personne ne répond aux questions. Sans -p, la commande attend une saisie et le job reste bloqué. Avec -p (--print), Claude traite le prompt, écrit le résultat sur la sortie standard et se termine, avec un code retour 0 en cas de succès et non nul en cas d'échec.

claude -p "Explique la cause racine de cette erreur de build" < build-error.txt

Les fausses pistes classiques (CLAUDE_HEADLESS=true, un --batch, rediriger stdin depuis /dev/null) n'existent pas ou ne règlent rien : la seule réponse est -p.

7.2 Une sortie exploitable par une machine#

SCHEMA='{"type":"object","properties":{"findings":{"type":"array","items":{"type":"object",
 "properties":{"file":{"type":"string"},"line":{"type":"integer"},
 "severity":{"type":"string","enum":["critical","major","minor"]},"message":{"type":"string"}},
 "required":["file","line","severity","message"]}}},"required":["findings"]}'

gh pr diff "$PR" > pr.diff
claude -p "Relis pr.diff selon les critères de revue de CLAUDE.md. Les constats déjà publiés sont dans
previous-findings.json : ne signale que les problèmes nouveaux ou toujours non corrigés." \
  --output-format json --json-schema "$SCHEMA" --allowedTools "Read" \
  | jq '.structured_output.findings' > findings.json   # vérifier que structured_output existe avant de l'utiliser

Chaque constat (fichier, ligne, gravité, message) peut ensuite être publié en commentaire inline sur la PR. Si Claude ne produit pas de sortie valide (refus, échec), le champ structured_output est absent : le script doit le vérifier.

7.3 Les bonnes pratiques que l'examen teste#

• CLAUDE.md donne le contexte du projet à la CI : standards de test, fixtures disponibles, critères de revue, ce qui compte comme un test utile. Claude Code invoqué par la CI le lit comme en interactif. Documenter ces critères réduit les tests sans valeur et les faux positifs (les critères explicites sont traités au chapitre 04, TS 4.1).
• Revue par une instance indépendante : la session qui a généré le code garde son raisonnement et critique mal ses propres choix. La revue se fait dans un autre claude -p, sans contexte partagé (motif writer / reviewer ; voir les revues multi-passes au chapitre 04, TS 4.6).
• Revue incrémentale sans doublons : à chaque nouveau commit, on relance une revue en fournissant les constats précédents et en demandant de ne rapporter que les problèmes nouveaux ou encore non traités. Revoir seulement le diff du dernier commit ou reprendre la session précédente ne sont pas les bonnes réponses.
• Génération de tests : fournir les fichiers de test existants pour éviter de proposer des scénarios déjà couverts.
• Synchrone ou batch : un contrôle bloquant avant fusion doit être synchrone ; la Message Batches API (-50 %, jusqu'à 24 h, sans SLA) convient aux audits de nuit (chapitre 04, TS 4.5).

sequenceDiagram
    participant Dev as Développeur
    participant CI as Pipeline CI
    participant C as claude -p (revue)
    participant PR as Pull request
    Dev->>PR: Pousse un commit
    PR->>CI: Événement pull_request
    CI->>CI: Récupère le diff et previous-findings.json
    CI->>C: Prompt, CLAUDE.md, constats précédents, schéma JSON
    C-->>CI: JSON (structured_output.findings)
    CI->>PR: Commentaires inline (nouveaux constats seulement)
    CI->>CI: Met à jour previous-findings.json

7.4 Les autres flags utiles en CI#

Réponse d'examen : -p pour éviter le blocage ; --output-format json + --json-schema pour des constats structurés ; CLAUDE.md comme contexte du projet en CI ; une instance indépendante pour la revue.

État actuel : tout cela est vrai. À savoir en plus : la doc recommande --bare pour les appels scriptés et annonce qu'il deviendra le défaut de -p dans une version future. Ce jour-là, un pipeline qui compte sur le CLAUDE.md devra le passer explicitement.

7.5 GitHub Actions#

L'action officielle anthropics/claude-code-action@v1 exécute Claude Code dans un workflow (installation rapide : /install-github-app dans Claude Code ; secret ANTHROPIC_API_KEY). Sans prompt, elle répond aux mentions @claude ; avec un prompt, elle s'exécute automatiquement sur l'événement. Les flags CLI passent par claude_args.

name: Revue de PR
on:
  pull_request:
    types: [opened, synchronize, ready_for_review, reopened]
jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: read          # comme l'exemple officiel : la Claude GitHub App publie les commentaires
      issues: read
      id-token: write              # authentification de l'action par la GitHub App
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}   # secret du dépôt, jamais en clair
          prompt: "/review ${{ github.event.pull_request.base.ref }}"   # skill d'équipe de .claude/skills/
          claude_args: '--max-turns 8 --allowedTools "Read,Grep,Glob,Bash(git diff *),mcp__github_inline_comment__create_inline_comment"'

L'outil mcp__github_inline_comment__create_inline_comment doit être nommé dans --allowedTools pour que l'action démarre le serveur qui publie les commentaires inline ; sans lui, la revue n'apparaît que dans le journal du workflow. Les permissions du job restent en lecture : c'est la Claude GitHub App (droits Pull requests: read and write) qui écrit les commentaires, pas le GITHUB_TOKEN du workflow. Le skill officiel code-review publie avec l'argument --comment ; un skill maison comme /review doit demander explicitement de publier.

Pour Azure DevOps ou GitLab, le principe est le même : un job qui installe Claude Code et appelle claude -p avec un secret de pipeline (variable group, Key Vault). Une option de l'action permet aussi de router l'inférence via Microsoft Foundry (use_foundry: "true"), avec une fédération OIDC au lieu d'une clé.

8. Labs conseillés#

Un dépôt de test (par exemple un petit projet Node ou Terraform), Claude Code et une clé API de test suffisent. Coût : quelques dollars de jetons ; surveiller total_cost_usd dans les sorties JSON. Ne jamais pointer ces labs sur un dépôt ou un abonnement de production.

Lab 1 · Configurer un dépôt d'équipe (inspiré de l'exercice officiel n° 2 du guide)

1. Créer .claude/CLAUDE.md (build, tests, nommage) et un packages/api/CLAUDE.md (conventions REST).
2. Ajouter dans le CLAUDE.md projet un import @docs/standards/naming.md.
3. Créer un CLAUDE.local.md personnel et vérifier qu'il est ignoré par git.
4. Lancer /context à la racine, puis lire un fichier de packages/api/ et relancer /context.
5. Déplacer une convention dans ~/.claude/CLAUDE.md et ouvrir un clone neuf dans un autre dossier.

Résultat attendu : le CLAUDE.md de api/ n'apparaît qu'après la lecture d'un de ses fichiers ; la convention déplacée en user n'existe pas pour le clone neuf (le piège du « nouveau membre de l'équipe »).

Lab 2 · Rules par chemin

1. Créer .claude/rules/testing.md avec paths: ["**/*.test.ts"] et .claude/rules/terraform.md avec paths: ["terraform/**/*"].
2. Nouvelle session : demander de modifier un fichier de test, puis /context.
3. Nouvelle session : modifier un .tf, puis /context.

Résultat attendu : seule la rule correspondante est chargée à chaque fois ; aucune des deux n'est chargée pour modifier le README.

Lab 3 · Skill d'équipe et skill personnel

1. Créer .claude/skills/review/SKILL.md (exemple de la section 3.2) et le commiter.
2. Créer ~/.claude/skills/explorer-alternatives/SKILL.md avec context: fork et disallowed-tools: Edit, Write.
3. Lancer /review main, puis /explorer-alternatives ajout d'un cache Redis.
4. Ajouter disable-model-invocation: true au premier et vérifier que Claude ne le lance plus de lui-même.

Résultat attendu : /review est disponible pour un coéquipier qui clone ; l'analyse verbeuse du second skill n'encombre pas la conversation, seul son résumé revient.

Lab 4 · Plan mode sur une migration

1. Choisir une migration réelle du dépôt test (remplacer une bibliothèque de logs utilisée dans 10 fichiers et plus).
2. claude --permission-mode plan, demander l'exploration et un plan, puis vérifier avec git status qu'aucun fichier n'a bougé.
3. Corriger le plan avec Ctrl+G, l'approuver en manually approve edits, laisser Claude exécuter et lancer les tests.
4. Comparer avec un correctif d'une ligne fait en direct execution.

Résultat attendu : zéro modification pendant le plan ; migration cohérente sur tous les fichiers ensuite.

Lab 5 · Revue de PR en headless

1. Écrire le script de la section 7.2 et le lancer sur une branche de test avec deux défauts volontaires.
2. Corriger un défaut, pousser, relancer avec previous-findings.json.
3. Brancher le workflow GitHub Actions de la section 7.5 sur le dépôt test.

Résultat attendu : JSON valide dans structured_output, commentaires inline, et au second passage seul le défaut non corrigé est encore signalé.

9. Les pièges d'examen#

10. Scénarios d'entraînement#

Format de l'examen : une seule bonne réponse sauf mention contraire. Questions originales, inspirées des scénarios 2 et 5.

1. Une équipe plateforme maintient un monorepo Terraform. Les conventions de nommage sont parfaitement suivies sur le poste de la lead, mais pas sur celui d'un développeur arrivé hier, qui a cloné le même dépôt. Que faire ?

• A. Demander au nouveau de lancer /memory au début de chaque session
• B. Déplacer les conventions du ~/.claude/CLAUDE.md de la lead vers le CLAUDE.md du projet et le commiter
• C. Ajouter les conventions dans le CLAUDE.local.md du nouveau
• D. Installer un serveur MCP qui distribue les conventions

Réponse : B. Le niveau user n'est pas versionné. A ne charge rien, C reste personnel, D n'a aucun rapport avec le chargement des consignes.

2. Les fichiers *.tf sont répartis dans modules/, envs/dev/, envs/prd/ et une vingtaine d'autres dossiers. L'équipe veut que ses conventions Terraform s'appliquent dès qu'on modifie un .tf, sans alourdir les autres sessions. Meilleure option ?

• A. Un CLAUDE.md dans chacun des dossiers
• B. Une section Terraform dans le CLAUDE.md racine
• C. Une rule .claude/rules/terraform.md avec paths: ["**/*.tf"]
• D. Un skill /terraform-conventions à lancer avant chaque modification

Réponse : C. Un seul fichier, chargé seulement sur les .tf. A duplique, B charge tout le temps, D dépend d'une action manuelle.

3. Un architecte veut un /analyse-dependances personnel qui lit des dizaines de fichiers et produit un long rapport, sans encombrer sa conversation ni modifier les commandes de l'équipe. Quelle configuration ?

• A. .claude/skills/analyse-dependances/SKILL.md avec context: fork
• B. ~/.claude/skills/analyse-dependances/SKILL.md avec context: fork
• C. ~/.claude/CLAUDE.md avec la procédure complète
• D. .claude/commands/analyse-dependances.md sans frontmatter

Réponse : B. ~/.claude/ = personnel, context: fork = sortie isolée. A et D sont partagés avec l'équipe ; C charge la procédure à chaque session.

4. D'après le guide d'examen, quel champ du frontmatter d'un skill limite les outils disponibles pendant son exécution, par exemple pour éviter des actions destructrices ?

• A. argument-hint
• B. context: fork
• C. allowed-tools
• D. description

Réponse : C (réponse du guide). Dans le produit actuel, allowed-tools pré-approuve et c'est disallowed-tools qui retire des outils : à savoir pour le travail réel, pas pour cocher la case à l'examen.

5. Trois demandes : (1) découper une application monolithique en trois services, (2) corriger une division par zéro dans une fonction signalée par une stack trace, (3) remplacer le client HTTP dans 40 fichiers qui gèrent les erreurs différemment. Quel choix ?

• A. Plan mode pour les trois
• B. Direct execution pour les trois
• C. Plan mode pour 1 et 3, direct execution pour 2
• D. Plan mode pour 1, direct execution pour 2 et 3

Réponse : C. 1 et 3 imposent une stratégie cohérente sur de nombreux fichiers ; 2 est délimité et la cause est connue.

6. Pendant une migration en plusieurs phases, la phase de découverte lit tant de fichiers que les réponses suivantes se dégradent. Que faire ?

• A. Passer en direct execution pour aller plus vite
• B. Confier la découverte au subagent Explore, qui ne renvoie qu'un résumé
• C. Copier tous les fichiers dans le CLAUDE.md racine
• D. Augmenter --max-turns

Réponse : B. Le contexte principal ne reçoit que la synthèse. A ne règle rien, C alourdit chaque session, D n'agit pas sur le contexte.

7. Un développeur sait exactement comment doivent être réécrits les noms de ressources, mais Claude Code applique sa description de façon différente à chaque essai. Première chose à essayer ?

• A. Réécrire la description en prose de façon plus détaillée
• B. Fournir 2 ou 3 exemples concrets « avant → après »
• C. Utiliser l'interview pattern
• D. Passer en plan mode

Réponse : B. La transformation est connue : des exemples la fixent. A prolonge la dérive, C sert quand le domaine est inconnu.

8. Un job de pipeline exécute claude "Revois cette PR" et ne se termine jamais. Correction ?

• A. Définir CLAUDE_HEADLESS=true
• B. Ajouter --batch
• C. Ajouter -p
• D. Rediriger stdin depuis /dev/null

Réponse : C. -p (--print) est le mode non interactif. A et B n'existent pas ; D ne règle pas le mode interactif.

9. La revue automatique republie à chaque push les mêmes remarques, y compris celles que l'équipe a choisi de garder. Que faire ? (une réponse)

• A. Ne revoir que le diff du dernier commit
• B. Reprendre la session de la première revue avec --resume
• C. Relancer une revue complète en fournissant les constats précédents et en demandant de ne signaler que les problèmes nouveaux ou non traités
• D. Passer la revue sur la Message Batches API

Réponse : C. A rate les problèmes qui traversent plusieurs commits, B réutilise un contexte figé, D ajoute du délai sans régler les doublons.

10. La génération de tests en CI propose sans cesse des cas déjà couverts et des tests sans intérêt. Quelles actions ? (deux réponses)

• A. Fournir les fichiers de test existants dans le contexte
• B. Documenter dans CLAUDE.md les standards de test, les critères d'un test utile et les fixtures disponibles
• C. Générer les tests dans la même session que le code, pour qu'elle connaisse l'implémentation
• D. Ajouter « sois plus pertinent » au prompt

Réponses : A et B. C reproduit le biais d'auto-revue, D est une consigne vague sans critère.

11. Pour aller plus loin (hors examen)#

• Hooks côté Claude Code : PreToolUse pour bloquer, PostToolUse pour lancer un linter après chaque modification, Stop pour empêcher la fin d'un tour tant que les tests échouent (chapitre 01, TS 1.5).
• Git worktrees : claude --worktree <nom> isole une session sur sa propre branche ; plusieurs sessions travaillent en parallèle sans conflit de fichiers. Un subagent peut aussi tourner dans un worktree temporaire (isolation: worktree).
• /goal : une condition réévaluée après chaque tour, jusqu'à ce qu'elle soit atteinte (pour un travail non surveillé).
• Managed settings et managed CLAUDE.md : imposer des règles à toute l'organisation, non contournables.
• AGENTS.md : Claude Code le lit à la place d'un CLAUDE.md absent, ce qui facilite la cohabitation avec d'autres agents de code.
• Plugins : regroupent skills, hooks, subagents et MCP servers en une unité installable (/plugin).
• Auto mode : un classifieur relit les actions au lieu de demander à l'utilisateur ; c'est le mode de départ des sessions interactives depuis la v2.1.283.
• Code Review : produit qui relit automatiquement chaque PR sans workflow à maintenir.

12. Fiche à retenir#

• .claude/ = partagé via git ; ~/.claude/ = personnel ; CLAUDE.local.md et settings.local.json = personnel au projet.
• CLAUDE.md : user ~/.claude/CLAUDE.md, project CLAUDE.md ou .claude/CLAUDE.md, directory dans un sous-dossier ; concaténés.
• Sous-dossiers chargés à la demande ; contradictions = choix arbitraire ; viser moins de 200 lignes.
• @path : relatif au fichier, 4 niveaux, chargé au lancement (n'économise rien).
• /memory = réponse d'examen pour diagnostiquer ; /context = ce qui est vraiment chargé.
• Consigne ≠ garantie : deny / hook pour l'obligatoire ; permissions évaluées deny > ask > allow.
• Précédence des settings : managed > CLI > local > project > user ; les listes se combinent.
• Commands .claude/commands/ et skills .claude/skills/<nom>/SKILL.md créent la même /commande ; le skill gagne.
• context: fork = sous-agent isolé ; allowed-tools (guide : restreint ; réalité : pré-approuve) ; argument-hint.
• Variante personnelle d'un skill d'équipe : ~/.claude/skills/ sous un autre nom.
• Rules .claude/rules/ + paths (globs) : convention d'un type de fichier éparpillé, chargée seulement quand elle sert.
• Plan mode : grande échelle, plusieurs approches, architecture, multi-fichiers ; direct : simple et délimité ; hybride : plan puis exécution.
• Explore subagent : découverte verbeuse isolée, résumé seulement.
• Raffinement : exemples (prose mal comprise), tests d'abord (complexe), interview (domaine inconnu), groupé (lié) ou séquentiel (indépendant).
• CI : -p ; --output-format json + --json-schema → structured_output ; CLAUDE.md = contexte ; revue par une instance indépendante ; constats précédents fournis.

Références#

Toutes lues le 21/10/2026 :

• Claude Certified Architect – Foundations, Exam Guide v1.0 (PDF officiel), domaine 3, scénarios 2 et 5, exercice 2
• claudecertificationguide.com, domaine 3 : leçons 3.1 à 3.6
• How Claude remembers your project (CLAUDE.md, rules, auto memory)
• Extend Claude with skills
• Settings files and precedence
• Configure permissions
• Choose a permission mode (plan mode)
• Create custom subagents
• Best practices for Claude Code
• Run Claude Code programmatically (headless)
• CLI reference
• Claude Code GitHub Actions
• Hooks reference