CCA-F Domaine 3 — Claude Code Configuration & Workflows (20 %) : la leçon complète

Le domaine 3 pèse 20 % — environ 12 questions sur 60 — et c'est de loin le plus factuel des cinq : la plupart des questions ont une réponse exacte qui se vérifie dans la documentation de Claude Code. Où va un fichier, quel flag active quoi, quelle portée est partagée par le contrôle de version. C'est aussi pour ça qu'il rapporte le plus de points par heure de révision : on ne te demande pas de juger, on te demande de savoir. Les candidats qui y perdent des points confondent presque toujours deux portées (utilisateur vs projet) ou deux mécanismes proches (commande vs skill, CLAUDE.md de répertoire vs règle à glob).

Cette leçon suit les 6 task statements du guide officiel v1.0 (juillet 2026). Les scénarios d'examen qui tirent sur ce domaine sont Code Generation with Claude Code (scénario 2), Developer Productivity (scénario 4) et Claude Code for Continuous Integration (scénario 5).

La carte du domaine

Les six task statements se rangent en deux groupes : configurer (3.1 CLAUDE.md, 3.2 commandes et skills, 3.3 règles par chemin) et travailler (3.4 plan mode, 3.5 raffinement, 3.6 CI/CD). Le premier groupe est pur fait ; le second demande un jugement de proportion.

3.1 — CLAUDE.md : hiérarchie, portée, modularité

CLAUDE.md est le fichier d'instructions que Claude Code charge automatiquement. Tout le task statement tourne autour d'une question : qui voit quoi, et depuis où.

Ce qu'il faut savoir

Trois niveaux. Utilisateur : ~/.claude/CLAUDE.md, s'applique à tous les projets de cet utilisateur, n'est pas partagé par le contrôle de version. Projet : CLAUDE.md à la racine ou .claude/CLAUDE.md, versionné, s'applique à toute l'équipe. Répertoire : un CLAUDE.md dans un sous-dossier, qui ne concerne que ce qu'il y a dessous.

Le diagnostic classique. « Un nouveau membre de l'équipe ne reçoit pas les instructions que les autres ont. » Cause attendue : les instructions sont au niveau utilisateur (chez chacun des anciens) et non au niveau projet. La correction est de les déplacer dans le CLAUDE.md du projet. Même logique que .mcp.json vs ~/.claude.json au domaine 2.

@import. Syntaxe pour référencer un fichier externe depuis un CLAUDE.md, afin de le garder court. Usage attendu : dans un monorepo, le CLAUDE.md de chaque package importe sélectivement les fichiers de standards qui le concernent, choisis par les mainteneurs qui connaissent le domaine.

.claude/rules/. Répertoire de fichiers de règles thématiques (testing.md, api-conventions.md, deployment.md) comme alternative à un CLAUDE.md monolithique. Avec un frontmatter paths:, ils deviennent conditionnels (§3.3).

/memory. Commande qui affiche quels fichiers mémoire sont effectivement chargés. C'est le premier réflexe quand le comportement est incohérent d'une session à l'autre : vérifier ce qui est réellement chargé avant de réécrire quoi que ce soit.

<!-- packages/api/CLAUDE.md — niveau répertoire, importe uniquement les standards pertinents -->
# API package

@../../docs/standards/api-conventions.md
@../../docs/standards/error-handling.md

Handlers en async/await, erreurs via `AppError`, jamais de `console.log` en production.

3.2 — Commandes et skills : où, et avec quel frontmatter

Deux mécanismes d'invocation à la demande, chacun avec une portée projet et une portée personnelle. L'examen teste la portée et les trois options de frontmatter des skills.

Ce qu'il faut savoir

Commandes. .claude/commands/<nom>.md dans le dépôt : partagée, disponible à tout développeur qui clone ou pull (question 4 du guide). ~/.claude/commands/<nom>.md : personnelle. Ni CLAUDE.md ni un hypothétique .claude/config.json avec un tableau commands — ce dernier n'existe pas et sert de distracteur.

Skills. .claude/skills/<nom>/SKILL.md, avec un frontmatter YAML. Trois options à connaître :

• context: fork — la skill s'exécute dans un sous-agent au contexte isolé ; sa sortie ne pollue pas la conversation principale. Cas d'usage : une analyse de codebase verbeuse, un brainstorm d'alternatives exploratoire.
• allowed-tools — restreint les outils accessibles pendant l'exécution de la skill (par exemple, limiter aux écritures de fichiers pour empêcher une action destructive via Bash).
• argument-hint — texte affiché pour inviter le développeur à fournir les paramètres attendus quand il invoque la skill sans arguments.

Variante personnelle. Pour personnaliser une skill d'équipe sans affecter les autres, on crée une variante dans ~/.claude/skills/ sous un autre nom. Modifier la skill partagée impacte tout le monde.

Skill vs CLAUDE.md. Une skill est invoquée à la demande pour un workflow précis. CLAUDE.md est toujours chargé : standards universels, conventions permanentes. Si la question dit « à chaque session, sans que personne ne le demande », c'est CLAUDE.md ; si elle dit « quand un développeur lance la tâche X », c'est une skill.

<!-- .claude/skills/analyze-codebase/SKILL.md -->
---
name: analyze-codebase
description: Cartographie un module, liste points d'entrée, dépendances et zones à risque.
context: fork
allowed-tools: [Read, Grep, Glob]
argument-hint: "<chemin du module> [--depth N]"
---

Analyse le module fourni. Renvoie UNIQUEMENT un résumé structuré :
points d'entrée, dépendances externes, zones à fort couplage, tests existants.

<!-- .claude/commands/review.md — commande d'équipe, versionnée -->
Relis les changements en cours selon la checklist d'équipe :
sécurité (injections, secrets), gestion d'erreurs, tests couvrant les branches, lisibilité.
Format : fichier · ligne · sévérité · problème · correction proposée.

3.3 — Règles par chemin : le chargement conditionnel

C'est la question 6 du guide officiel, et l'un des items les plus discriminants du domaine. Un codebase avec des conventions différentes par zone (composants React, handlers API, modèles de données), et des fichiers de test dispersés partout à côté du code qu'ils testent. Comment appliquer automatiquement la bonne convention ?

Ce qu'il faut savoir

Le mécanisme. Un fichier dans .claude/rules/ avec un frontmatter YAML contenant paths: et une liste de globs. La règle ne se charge que lorsque Claude édite un fichier correspondant.

Deux bénéfices. Un fonctionnel : la convention s'applique par type de fichier, quel que soit l'emplacement (**/*.test.tsx attrape tous les tests). Un économique : le contexte non pertinent n'est pas chargé, ce qui réduit les tokens.

Quand choisir le glob plutôt que le répertoire. Dès que les fichiers concernés sont dispersés dans plusieurs dossiers. Un CLAUDE.md de répertoire reste valable pour un périmètre réellement délimité par un dossier.

Pourquoi pas les autres options de la question 6. Tout consolider dans le CLAUDE.md racine « en laissant Claude déduire quelle section s'applique » : repose sur l'inférence, pas sur un matching explicite. Des skills par type de code : nécessitent une invocation, contredisent le « automatiquement ».

<!-- .claude/rules/testing.md -->
---
paths: ["**/*.test.tsx", "**/*.test.ts", "**/__tests__/**"]
---

Tests avec Vitest. Un `describe` par fonction publique. Cas nominal, cas limites, erreurs.
Pas de mocks de la base : utiliser les fixtures de `test/fixtures/`.
Nommer : `it("returns X when Y")`.

3.4 — Plan mode ou exécution directe

Question 5 du guide : restructurer un monolithe en microservices, des dizaines de fichiers, des décisions de frontières de services. Réponse : plan mode d'abord. La difficulté n'est pas cette question-là, c'est de reconnaître les cas où le plan mode est inutile.

Ce qu'il faut savoir

Plan mode. Pour les tâches à changements larges, plusieurs approches valables, décisions d'architecture, modifications multi-fichiers. Il permet d'explorer le codebase et de concevoir avant de s'engager, ce qui évite un rework coûteux. Exemples du guide : restructuration en microservices, migration de bibliothèque touchant 45+ fichiers, choix entre deux approches d'intégration aux besoins d'infrastructure différents.

Exécution directe. Pour un changement simple et bien délimité : un correctif dans un fichier avec une stack trace claire, l'ajout d'une condition de validation de date.

Le sous-agent Explore. Pendant les phases de découverte verbeuses (lire des dizaines de fichiers), il isole la sortie et ne renvoie qu'un résumé au contexte principal, ce qui évite l'épuisement de la fenêtre sur les tâches multi-phases.

La combinaison. Plan mode pour l'investigation et la conception, puis exécution directe pour l'implémentation de l'approche planifiée.

3.5 — Raffinement itératif : faire converger Claude Code

Section plus « méthode » que « configuration ». Quatre techniques, et surtout la règle pour décider entre un message groupé et des itérations séquentielles.

Ce qu'il faut savoir

Exemples entrée/sortie. Le moyen le plus efficace de communiquer une transformation attendue quand la prose est interprétée de façon inconsistante. Deux ou trois exemples concrets valent mieux qu'un paragraphe de description.

Itération pilotée par les tests. Écrire d'abord la suite de tests couvrant le comportement attendu, les cas limites et les exigences de performance ; puis itérer en partageant les échecs de tests, qui guident la correction de façon précise.

Le pattern interview. Avant d'implémenter dans un domaine peu familier, demander à Claude de poser des questions pour faire émerger les considérations que le développeur n'avait pas anticipées : stratégie d'invalidation de cache, modes de défaillance, contraintes de cohérence.

Groupé ou séquentiel. Si les problèmes interagissent (corriger l'un change la solution de l'autre), on les décrit tous dans un seul message détaillé pour que la solution soit cohérente. S'ils sont indépendants, on les traite l'un après l'autre.

3.6 — Claude Code en CI/CD

Le scénario 5 (revue automatisée de PR, génération de tests) repose sur cette section. Elle contient l'item le plus « gratuit » de l'examen — le flag -p — et l'un des plus subtils — la relecture par une instance indépendante.

Ce qu'il faut savoir

-p / --print. Mode non interactif : Claude Code traite le prompt, écrit sur stdout et sort. Sans ce flag, le job attend une saisie et pend indéfiniment (question 10 du guide). Les distracteurs sont des fonctionnalités inexistantes (CLAUDE_HEADLESS=true, --batch) ou des bricolages Unix (< /dev/null).

--output-format json et --json-schema. Pour produire des résultats structurés et validés, exploitables par le pipeline : poster chaque finding comme commentaire inline sur la PR, filtrer par sévérité, compter.

CLAUDE.md comme contexte du CI. Standards de test, conventions de fixtures, critères de revue : c'est là que le CI apprend ce qui compte pour l'équipe. Documenter les standards de test et les fixtures disponibles réduit directement les tests de faible valeur générés.

Éviter les doublons. Sur une relecture après de nouveaux commits, on inclut les findings précédents en contexte avec l'instruction de ne remonter que le nouveau ou le non résolu. Pour la génération de tests, on fournit les fichiers de tests existants pour ne pas proposer des scénarios déjà couverts.

L'isolement de session. Une session qui a généré du code est moins efficace pour relire ses propres changements qu'une instance indépendante : elle conserve son raisonnement et tend à ne pas remettre en cause ses décisions. Pour la revue, on lance une instance fraîche sans le contexte de génération (thème repris au domaine 4, revue multi-instances).

# Étape CI : revue non interactive, sortie structurée, contexte des findings précédents
claude -p "Relis cette PR selon les critères de CLAUDE.md. \
Findings précédents (ne remonter que le nouveau ou le non résolu) : $(cat prev-findings.json)" \
  --output-format json \
  --json-schema review.schema.json \
  > findings.json

# Le pipeline parse findings.json et poste des commentaires inline
jq -c '.findings[] | select(.severity != "info")' findings.json | while read f; do
  post_pr_comment "$f"
done

{
  "type": "object",
  "properties": {
    "findings": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "file": {"type": "string"},
          "line": {"type": "integer"},
          "severity": {"type": "string", "enum": ["critical", "high", "medium", "low", "info"]},
          "issue": {"type": "string"},
          "suggested_fix": {"type": "string"},
          "detected_pattern": {"type": "string"}
        },
        "required": ["file", "line", "severity", "issue"]
      }
    }
  },
  "required": ["findings"]
}

Les pièges transversaux du domaine 3

1. Partagé = versionné = projet. Tout ce qui doit atteindre un coéquipier via git clone vit sous .claude/ ou à la racine du dépôt. Tout ce qui est sous ~/ est personnel.
2. Le matching explicite bat l'inférence. Une règle à glob s'applique par construction ; « Claude déduira la bonne section » ne s'applique que par chance.
3. La complexité annoncée ne se découvre pas. Si l'énoncé décrit une tâche large, on planifie d'emblée.
4. Les fonctionnalités inventées sont des distracteurs. --batch, CLAUDE_HEADLESS, un tableau commands dans config.json : n'existent pas.

Checklist de la veille

Cinq questions-scénario originales, corrigées

Questions écrites par nAIvigate dans l'esprit de l'examen, sans reproduction d'items réels.

Question 1 — Scénario code generation. Trois développeurs seniors obtiennent des revues conformes aux conventions d'équipe ; le stagiaire arrivé hier obtient des revues génériques. Les conventions sont dans le ~/.claude/CLAUDE.md de chacun des seniors. Correction ?

A. Envoyer le fichier au stagiaire pour qu'il le copie dans son ~/.claude/. B. Déplacer les conventions dans le CLAUDE.md à la racine du dépôt, versionné. C. Créer une skill /conventions que chacun invoque en début de session. D. Ajouter les conventions dans .mcp.json.

Question 2 — Scénario productivité. Une skill d'analyse de codebase produit 4 000 lignes de sortie qui saturent la conversation principale, et elle a un jour supprimé un fichier via Bash. Quel frontmatter ?

A. context: fork et allowed-tools: [Read, Grep, Glob]. B. argument-hint et allowed-tools: [Bash]. C. context: fork seulement. D. Déplacer la skill dans ~/.claude/skills/.

Question 3 — Scénario code generation. Les conventions Terraform doivent s'appliquer aux fichiers .tf présents dans infra/, modules/ et envs/prod/. Approche la plus maintenable ?

A. Un CLAUDE.md dans chacun des trois dossiers. B. Un fichier .claude/rules/terraform.md avec paths: ["**/*.tf"]. C. Tout dans le CLAUDE.md racine sous un titre « Terraform ». D. Une skill /terraform à invoquer avant chaque édition.

Question 4 — Scénario CI. Le job de revue génère les mêmes 12 commentaires à chaque push sur la PR, y compris pour des points déjà corrigés. Correction ?

A. Ne lancer la revue qu'à l'ouverture de la PR. B. Inclure les findings précédents dans le prompt avec l'instruction de ne remonter que le nouveau ou le non résolu. C. Passer en --output-format text. D. Demander à Claude d'être « plus concis ».

Question 5 — Scénario CI. Le pipeline génère du code avec Claude Code puis lui demande, dans la même session, de relire ce code « avec un œil très critique ». Les revues ne relèvent presque jamais de problème. Que faire ?

A. Activer le raisonnement étendu pour la phase de revue. B. Renforcer l'instruction d'auto-critique. C. Lancer la revue dans une instance indépendante, sans le contexte de génération. D. Faire trois relectures dans la même session et fusionner.

Quiz de validation

Pour aller plus loin

La suite est le Domaine 4 — Prompt Engineering & Structured Output (20 %), qui approfondit les critères de revue explicites, le few-shot, la sortie structurée via tool_use et la revue multi-instances évoquée ici. Pour un panorama d'outils réels de l'écosystème Claude Code et MCP, notre fiche 40 outils Claude Code / MCP est mise à jour en continu.

Si tu veux certifier une équipe entière — ou mettre Claude Code en place proprement sur un vrai dépôt (hiérarchie CLAUDE.md, règles, skills, pipeline CI avec revue indépendante) — c'est ce que nAIvigate Studio fait en Sprint.