Guide Professeur — Session 6 : Claude Code & CI/CD

Programme : Applied AI — Niveau Avancé (préparation certification Claude Certified Architect) Instructeur : Yann Isola Durée : 2 heures 30 (150 minutes) Modules couverts : Chapitres 5 et 13 du guide de référence — Claude Code, outils intégrés, intégration continue

1. Vue d’ensemble de la session

Objectifs pédagogiques

À la fin de cette session, chaque participant doit être capable de :

Définir Claude Code : un assistant de codage agentique (agentic coding assistant) qui s’exécute dans le terminal, capable de lire, modifier et exécuter du code de manière autonome dans un périmètre de permissions contrôlé.
Structurer un fichier CLAUDE.md efficace : vue d’ensemble du projet, conventions, commandes courantes, pièges connus (gotchas) — et expliquer pourquoi ce fichier est le levier n°1 de la qualité des sorties.
Configurer le répertoire .claude/ : settings.json (outils autorisés via allowedTools), commandes personnalisées (.claude/commands/), hooks.
Maîtriser le modèle de permissions : allow/deny par outil, motifs d’auto-acceptation (auto-accept patterns), principe du moindre privilège appliqué à un agent de codage.
Concevoir un système de hooks : événements de cycle de vie (PreToolCall, PostToolCall, Notification, Stop) pour l’automatisation personnalisée — audit, garde-fous, notifications.
Exécuter Claude Code en mode headless (sans interface, non interactif) avec --print / -p pour l’intégrer dans un pipeline CI/CD (Continuous Integration / Continuous Deployment, intégration et déploiement continus).
Concevoir trois patterns d’intégration CI/CD : revue automatique de PR (Pull Request, demande de fusion), génération de tests, mise à jour de documentation.
Cartographier les outils intégrés (Chapitre 13) : Read, Write, Edit, MultiEdit, Bash, Glob, Grep, LS, TodoRead, TodoWrite, WebFetch, mcp__* — et associer chaque outil à son niveau de risque et son besoin de permission.
Gérer les coûts : commande /cost, mise en cache des prompts (prompt caching) dans les sessions longues, /compact pour compresser le contexte.

Prérequis

Sessions 1 à 5 du niveau Avancé (notamment : architecture d’agents, tool calling, MCP — Model Context Protocol, protocole de contexte de modèle).
Aisance en ligne de commande (terminal, shell bash ou équivalent).
Notions de Git et de CI/CD : savoir ce qu’est une PR, un pipeline, un runner.
Idéalement : avoir déjà installé Claude Code (npm install -g @anthropic-ai/claude-code ⚠ vérifier la commande d’installation actuelle avant la session, elle peut évoluer).

Positionnement certification

Cette session couvre un domaine fortement pondéré dans l’examen Claude Certified Architect : la configuration d’environnements agentiques et leur industrialisation. Les questions d’examen types portent sur :

le choix des outils à autoriser dans un contexte donné (scénarios de moindre privilège) ;
l’ordre et la sémantique des hooks ;
la différence entre mode interactif et mode headless ;
la structure canonique d’un CLAUDE.md.

Insistez auprès des participants : l’examen teste le jugement d’architecte, pas la mémorisation de flags. Chaque partie du cours se termine par une « question type certification » — utilisez-les.

Matériel nécessaire

Vidéoprojecteur + slides (slides/slides.md).
Page web interactive (webpage/index.html) — hors ligne : constructeur de CLAUDE.md, concepteur de pipeline CI/CD, configurateur de permissions.
Feuilles d’exercices (exercises/exercises.md).
Quiz (quiz/quiz.md).
Fortement recommandé : chaque participant avec un terminal et Claude Code installé. Prévoyez un dépôt Git d’exercice cloné à l’avance (n’importe quel petit projet avec tests fera l’affaire).

Message central de la session

« Claude Code n’est pas un chatbot qui parle de code : c’est un agent qui agit sur votre dépôt, dans un périmètre que vous définissez. Le fichier CLAUDE.md est son cerveau contextuel, settings.json est sa cage, les hooks sont vos caméras de surveillance, et le mode headless en fait un employé de votre pipeline. »

Répétez cette métaphore en quatre temps (cerveau / cage / caméras / employé) — elle structure toute la session.

Fil conducteur narratif

Toute la session s’appuie sur un projet fil rouge unique : facturation-api, une API de facturation fictive en Python avec des tests pytest. Chaque concept est illustré sur ce même projet :

Le CLAUDE.md décrit facturation-api.
Les permissions sont calibrées pour facturation-api.
Le pipeline CI/CD révise les PR de facturation-api.

La répétition du même contexte ancre les concepts et prépare aux questions de scénario de la certification.

2. Déroulé minute par minute

Horaire	Durée	Séquence	Support
0:00 – 0:05	5 min	Accueil, rappel Session 5, objectifs, enjeu certification	Slides 1–3
0:05 – 0:25	20 min	Partie A — Claude Code : anatomie d’un agent de terminal	Slides 4–8 + démo live
0:25 – 0:45	20 min	Partie B — CLAUDE.md : le cerveau contextuel	Slides 9–12 + constructeur web
0:45 – 1:05	20 min	Exercice 1 : Rédiger un CLAUDE.md	Feuille d’exercices + constructeur web
1:05 – 1:10	5 min	☕ Pause courte	—
1:10 – 1:30	20 min	Partie C — Permissions & outils intégrés : la cage	Slides 13–18 + configurateur web
1:30 – 1:45	15 min	Partie D — Hooks : les caméras de surveillance	Slides 19–22
1:45 – 2:00	15 min	Exercice 3 (démarrage) : Concevoir un système de hooks	Feuille d’exercices
2:00 – 2:15	15 min	Partie E — Mode headless & CI/CD : l’employé du pipeline	Slides 23–27 + concepteur de pipeline web
2:15 – 2:25	10 min	Exercice 2 (cadrage) : Pipeline CI/CD avec Claude Code — lancement, finition à la maison	Feuille d’exercices
2:25 – 2:30	5 min	Quiz éclair + Exit Tickets + annonce Session 7	Slides 28–30

Note de flexibilité : l’Exercice 2 (CI/CD complet) est le plus long — il est conçu pour être cadré en séance et terminé à la maison. Si vous prenez du retard, compressez la Partie D à 10 minutes (montrez uniquement PreToolCall et Stop), mais ne sacrifiez jamais la Partie C (permissions) : c’est le cœur du modèle de sécurité et le sujet le plus piégeux à l’examen.

3. Notes pédagogiques détaillées par séquence

0:00 – 0:05 | Accueil et cadrage

Quoi dire :

« Jusqu’ici, vous avez conçu des agents dans des applications. Aujourd’hui, on retourne la table : l’agent, c’est votre collègue de terminal. Il lit votre code, le modifie, lance vos tests. Et à la fin de la session, il travaillera tout seul dans votre pipeline CI/CD, la nuit, pendant que vous dormez. La question de la session n’est pas “est-ce que c’est possible ?” — c’est “comment garder le contrôle ?”. »

Annoncez l’enjeu certification : ce chapitre pèse lourd à l’examen. Distribuez le plan.

0:05 – 0:25 | Partie A — Claude Code : anatomie d’un agent de terminal

Concepts clés :

Définition. Claude Code est un assistant de codage agentique en ligne de commande. « Agentique » signifie : il ne se contente pas de répondre, il boucle — lit des fichiers, propose des modifications, exécute des commandes, observe les résultats, corrige. C’est la boucle agentique de la Session 3, incarnée dans le terminal.
Démarrage d’un projet. La commande /init inspecte le dépôt et génère un premier CLAUDE.md automatiquement. Insistez : c’est un brouillon — un bon architecte le retravaille toujours (transition vers la Partie B).
Interaction en langage naturel. On ne tape pas des commandes rigides : « corrige le bug de calcul de TVA dans invoice.py et ajoute un test » est une instruction valide. Claude Code planifie, ouvre les bons fichiers (via Glob/Grep), édite (via Edit/MultiEdit), teste (via Bash).
Éditions multi-fichiers. Contrairement à l’autocomplétion classique, Claude Code raisonne à l’échelle du dépôt : un renommage de fonction peut toucher 12 fichiers en une seule tâche.
Slash commands intégrées :
- /init — génère le CLAUDE.md initial ;
- /compact — compresse l’historique de conversation pour libérer du contexte (résumé automatique) ;
- /cost — affiche la consommation de tokens et le coût de la session ;
- /review — lance une revue de code ;
- commandes personnalisées dans .claude/commands/*.md — un fichier Markdown = une commande (ex. .claude/commands/deploy-check.md devient /deploy-check).

Démo live (8 min) : sur le projet facturation-api, lancez claude, puis /init, montrez le CLAUDE.md généré. Demandez ensuite en langage naturel : « liste les fichiers de test et dis-moi ce qui n’est pas couvert ». Montrez les demandes de permission qui apparaissent — c’est le teaser parfait de la Partie C.

Piège pédagogique : certains participants penseront que Claude Code « voit » tout le dépôt en permanence. Faux : il explore à la demande (via Glob, Grep, Read). Le contexte est construit incrémentalement — d’où l’importance du CLAUDE.md qui, lui, est chargé systématiquement.

Question type certification : « Un développeur constate que Claude Code ignore les conventions de nommage de l’équipe. Quelle est la première action corrective ? » → Documenter les conventions dans CLAUDE.md (pas : répéter l’instruction à chaque prompt, ni : changer de modèle).

0:25 – 0:45 | Partie B — CLAUDE.md : le cerveau contextuel

Concepts clés :

Ce que c’est. Un fichier Markdown à la racine du projet, chargé automatiquement au début de chaque session. C’est l’équivalent projet du message système : des instructions permanentes, versionnées avec le code, partagées par toute l’équipe.
Structure canonique (à faire noter) :
- Vue d’ensemble du projet — quoi, pour qui, stack technique. 3 à 5 lignes.
- Conventions — style de code, nommage, structure des dossiers, langue des commentaires.
- Commandes courantes — comment lancer les tests, le linter, le build, le serveur local. Exactes et copiables.
- Pièges connus (gotchas) — « le module X a une API trompeuse », « ne jamais toucher au dossier migrations/ à la main », « les tests d’intégration exigent Docker ».
Pourquoi ça marche. Chaque instruction dans CLAUDE.md économise des dizaines de corrections en aval. Analogie : c’est le document d’onboarding d’un nouveau développeur — sauf que ce développeur le relit à chaque session, intégralement, sans jamais l’oublier.
Anti-patterns à dénoncer :
- Le CLAUDE.md de 800 lignes : il consomme du contexte à chaque session et dilue les instructions critiques. Cible : moins de 150 lignes, dense.
- Les généralités (« écris du code propre ») : zéro valeur. Chaque ligne doit être spécifique au projet.
- Le fichier périmé : commandes qui ne marchent plus = l’agent perd confiance… non, correction : vous perdez du temps, car l’agent exécute des commandes cassées. Traitez CLAUDE.md comme du code : revue, mise à jour, responsabilité.
Hiérarchie. Il peut exister un CLAUDE.md global (niveau utilisateur, ~/.claude/CLAUDE.md) et des CLAUDE.md par sous-dossier pour les monorepos. Le plus spécifique complète le plus général.

Activité (5 min) : projetez le constructeur de CLAUDE.md de la page web. Remplissez-le en direct avec la salle pour facturation-api. Générez le fichier, critiquez-le ensemble : qu’est-ce qui manque ? Qu’est-ce qui est trop vague ?

Question type certification : « Quelle section de CLAUDE.md a le plus d’impact sur la réduction des erreurs d’exécution de commandes ? » → Les commandes courantes exactes (l’agent n’a pas à deviner npm test vs pnpm test vs make test).

0:45 – 1:05 | Exercice 1 — Rédiger un CLAUDE.md

Voir feuille d’exercices. Les participants rédigent un CLAUDE.md complet pour un projet décrit dans l’énoncé (ou leur propre projet s’ils en ont un). Le constructeur web peut servir d’échafaudage, mais exigez une passe manuelle de densification.

Critères de correction (annoncez-les) :

Les 4 sections canoniques présentes.
Commandes copiables-collables, pas de pseudo-commandes.
Au moins 2 gotchas réels et spécifiques.
Moins de 100 lignes.

Circulation : repérez les fichiers « génériques » (qui pourraient décrire n’importe quel projet) et challengez : « si je donne ce fichier à un autre binôme, saura-t-il que ce n’est pas son projet ? Si non, tout est à réécrire. »

1:10 – 1:30 | Partie C — Permissions & outils intégrés : la cage

C’est la partie la plus importante de la session. Ralentissez.

Concepts clés :

Le catalogue d’outils intégrés (Chapitre 13). Faites construire le tableau avec la salle, par niveau de risque croissant :

Outil	Fonction	Risque	Permission typique
`Read`	Lire un fichier	Faible (fuite d’info possible)	Souvent auto-accepté
`LS`	Lister un répertoire	Faible	Auto-accepté
`Glob`	Trouver des fichiers par motif	Faible	Auto-accepté
`Grep`	Chercher dans les contenus	Faible	Auto-accepté
`TodoRead` / `TodoWrite`	Gérer la liste de tâches interne	Négligeable	Auto-accepté
`WebFetch`	Récupérer une page web	Moyen (exfiltration, contenu non fiable)	Validation recommandée
`Write`	Créer/écraser un fichier	Élevé	Validation
`Edit` / `MultiEdit`	Modifier un/plusieurs fichiers	Élevé	Validation ou motifs ciblés
`Bash`	Exécuter une commande shell	Critique	Validation systématique ou liste blanche fine
`mcp__*`	Outils MCP externes (serveurs Model Context Protocol)	Variable — dépend du serveur	Au cas par cas

Le modèle allow/deny. Dans .claude/settings.json, la clé allowedTools définit ce qui est autorisé sans confirmation. La granularité descend jusqu’au motif de commande : Bash(npm test) autorise exactement npm test, Bash(git diff:*) autorise les variantes de git diff. Tout ce qui n’est pas explicitement permis déclenche une demande de confirmation interactive — ou un refus en mode headless (point crucial pour la Partie E).
Exemple canonique à projeter :

{
  "permissions": {
    "allow": [
      "Read", "Glob", "Grep", "LS",
      "Bash(npm test:*)",
      "Bash(git diff:*)",
      "Bash(git log:*)",
      "Edit"
    ],
    "deny": [
      "Bash(rm:*)",
      "Bash(git push:*)",
      "WebFetch"
    ]
  }
}

⚠ La syntaxe exacte du fichier de settings évolue avec les versions de Claude Code — vérifiez la documentation officielle avant la session et adaptez la slide si nécessaire. La logique (allow explicite, deny prioritaire, motifs par préfixe) est stable et c’est elle qui est testée en certification.

Principe d’architecte : le deny l’emporte toujours sur le allow. On raisonne en trois cercles : lecture libre (explorer ne coûte rien), écriture surveillée (modifications validées ou ciblées), exécution verrouillée (le shell est une surface d’attaque totale — Bash non contraint équivaut à donner un accès SSH).
Ce que Claude Code ne peut PAS faire : sortir du répertoire de travail sans permission, exécuter quoi que ce soit sans passer par ses outils déclarés, masquer une action (tout appel d’outil est visible et journalisable via hooks). Mais rappelez le vecteur d’attaque n°1 : l’injection de prompt via le contenu lu (un commentaire de code malveillant, une page WebFetch piégée peuvent contenir des instructions). Les permissions sont la défense : même manipulé, l’agent ne peut pas exécuter ce qui est refusé.

Activité (5 min) : configurateur de permissions de la page web. Scénario : « Claude Code doit faire de la revue de code en CI, lecture seule + commentaires ». La salle choisit les outils, la page génère le settings.json. Réponse attendue : Read/Glob/Grep/LS seulement, tout le reste en deny.

Question type certification : « Un pipeline CI utilise Claude Code en headless pour générer des tests. Quel ensemble minimal d’outils faut-il autoriser ? » → Read, Glob, Grep, LS (exploration), Write ou Edit (créer les fichiers de test), Bash(pytest:*) ou équivalent (vérifier que les tests passent). Rien d’autre. Chaque outil superflu est un point perdu.

1:30 – 1:45 | Partie D — Hooks : les caméras de surveillance

Concepts clés :

Définition. Un hook est un script à vous que Claude Code exécute automatiquement à des moments précis du cycle de vie. Contrairement au prompt (que le modèle peut mal interpréter), un hook est déterministe : il s’exécute toujours, exactement comme écrit.
Les quatre événements :
- PreToolCall — avant chaque appel d’outil. Peut bloquer l’appel (garde-fou). Ex. : refuser tout Bash contenant DROP TABLE.
- PostToolCall — après chaque appel d’outil. Ne bloque pas, mais observe et réagit. Ex. : lancer le formateur de code après chaque Edit.
- Notification — quand Claude Code a besoin d’une attention humaine (demande de permission, question). Ex. : envoyer un message Slack.
- Stop — quand l’agent termine sa réponse/sa tâche. Ex. : jouer un son, déclencher la suite du pipeline, archiver le journal de session.
Cas d’usage d’architecte (les trois familles) :
- Garde-fous (PreToolCall) : politiques de sécurité inviolables, complémentaires aux permissions — les permissions disent quels outils, les hooks disent quelles utilisations de ces outils.
- Automatisation qualité (PostToolCall) : lint/format automatique, vérification que les fichiers modifiés compilent.
- Observabilité (tous) : journal d’audit complet de chaque action de l’agent — exigence fréquente en environnement régulé. Reliez au contexte des participants : dans une banque, ce journal est ce que l’auditeur demandera.
Sémantique de blocage : un hook PreToolCall qui sort avec un code d’échec (et/ou un message) empêche l’appel et renvoie l’explication au modèle, qui peut ajuster sa stratégie. C’est un dialogue, pas juste un mur.

À dire :

« Retenez la division du travail : CLAUDE.md = ce que l’agent devrait faire (persuasion). Permissions = ce qu’il peut faire (capacité). Hooks = ce qui se passe quand il agit (contrôle et réaction). Un architecte certifié sait choisir le bon niveau : on ne met pas dans le prompt ce qui doit être un hook, et on ne met pas dans un hook ce qui doit être une permission. »

Question type certification : « L’équipe sécurité exige qu’aucune commande contenant curl vers un domaine externe ne soit jamais exécutée, même si l’utilisateur l’approuve. Prompt, permission ou hook ? » → Hook PreToolCall (inspection du contenu de la commande + blocage inconditionnel). Une permission deny Bash(curl:*) est aussi défendable — excellente occasion de débattre : la permission bloque tout curl, le hook permet une logique fine (curl interne OK, externe non).

1:45 – 2:00 | Exercice 3 (démarrage) — Concevoir un système de hooks

Voir feuille d’exercices. Travail sur papier/éditeur : concevoir les hooks d’un environnement régulé. Pas besoin d’exécuter — l’exercice évalue le design : choix de l’événement, logique de filtrage, action.

Circulation : l’erreur classique est de tout mettre en PreToolCall. Poussez à justifier : « pourquoi ce contrôle avant plutôt qu’après ? Qu’est-ce que ça coûte en latence ? »

2:00 – 2:15 | Partie E — Mode headless & CI/CD : l’employé du pipeline

Concepts clés :

Le mode headless. claude -p "instruction" (ou --print) exécute la tâche sans interface interactive : Claude Code reçoit l’instruction, agit, imprime le résultat, se termine. Code de sortie exploitable par le pipeline.
Conséquence critique : en headless, personne ne clique sur “autoriser”. Toutes les permissions doivent être pré-accordées dans settings.json (ou via les flags de permission en ligne de commande). Un outil non autorisé = action refusée = tâche potentiellement incomplète. D’où la règle d’or : calibrer les permissions headless au strict nécessaire de la tâche, et rien de plus — c’est un agent sans surveillance humaine.
Les trois patterns d’intégration à connaître pour la certification :

a) Revue automatique de PR. Déclencheur : ouverture/mise à jour d’une PR. Le job checkout le code, lance claude -p "Révise ce diff : bugs, sécurité, conventions du CLAUDE.md. Formate en Markdown." avec des permissions lecture seule + Bash(git diff:*). La sortie est postée en commentaire de PR via l’API de la forge (GitHub/GitLab). Point d’architecte : la revue IA complète la revue humaine, elle ne la remplace pas — configurez-la comme non bloquante au début.

b) Génération de tests. Déclencheur : baisse de couverture ou demande manuelle. Permissions : lecture + Write (limité au dossier tests/ si possible via hook !) + Bash(pytest:*). Le job commit les tests sur une branche et ouvre une PR — jamais de push direct sur main. Voilà un mariage parfait permission + hook : Write autorisé, hook PreToolCall qui vérifie que le chemin commence par tests/.

c) Mise à jour de documentation. Déclencheur : merge sur main. Claude Code compare le code et la doc, met à jour les sections périmées, ouvre une PR de doc. Permissions : lecture + Edit sur docs/.
Gestion des coûts en CI :
- Chaque run consomme des tokens : suivez /cost en interactif, et en CI, plafonnez (limite de tours, timeout du job).
- Le prompt caching (mise en cache des préfixes de prompt) réduit fortement le coût des sessions longues : le CLAUDE.md et le contexte stable sont mis en cache, seul le nouveau contenu est facturé au tarif plein. ⚠ Les tarifs et taux de réduction du cache évoluent — donnez l’ordre de grandeur (« le token en cache coûte une fraction du token normal ») et renvoyez à la grille tarifaire du jour.
- /compact en session interactive longue : résume l’historique pour éviter l’engorgement du contexte (et la dégradation de qualité qui va avec).
Anti-pattern à clouer au mur : --dangerously-skip-permissions (ou tout équivalent « autorise tout ») dans un pipeline connecté à des secrets de production. Si vous devez l’utiliser, c’est dans un conteneur jetable, sans réseau sortant, sans secrets. Un architecte qui met « autorise tout » dans un runner CI avec des credentials AWS a raté sa certification et son audit de sécurité.

Activité (5 min) : concepteur de pipeline de la page web. Construisez en direct le flux PR → revue Claude → tests → déploiement, en configurant chaque étape (permissions, blocant/non-blocant).

Question type certification : « En mode headless, Claude Code s’arrête sans terminer car un outil est refusé. Cause la plus probable ? » → Permission manquante dans settings.json : en headless il n’y a pas de confirmation interactive possible.

2:15 – 2:25 | Exercice 2 (cadrage) — Pipeline CI/CD

Lancez l’exercice 2 : lecture de l’énoncé ensemble, choix du pattern par binôme, écriture du squelette de workflow. La finition (workflow YAML complet + settings.json + hook) se fait à la maison. Annoncez que les productions seront relues en début de Session 7.

2:25 – 2:30 | Clôture

Quiz éclair : 3 questions orales tirées du quiz (Q2, Q5, Q9 recommandées).
Exit ticket : chaque participant écrit une décision d’architecture de la session qu’il appliquerait dès demain dans son organisation.
Annonce Session 7 et rappel : Exercice 2 à terminer, il sera relu.

4. Questions fréquentes des participants (et réponses)

« Claude Code peut-il détruire mon dépôt ? » Avec des permissions par défaut : non — les actions d’écriture et d’exécution demandent confirmation, et Git vous protège (tout est réversible avant push). Avec « autorise tout » et sans Git : oui, comme n’importe quel script auquel vous donnez les clés. La réponse d’architecte : ce n’est pas une question de confiance dans le modèle, c’est une question de périmètre de permissions.

« Pourquoi ne pas tout mettre dans CLAUDE.md plutôt que dans des hooks ? » Parce que CLAUDE.md est de la persuasion : le modèle suit les instructions avec une très haute probabilité, mais pas une garantie. Un hook est du code : il s’exécute à 100 %. Les politiques de sécurité vont dans les hooks/permissions ; les préférences et conventions vont dans CLAUDE.md.

« Le mode headless est-il le même binaire ? » Oui — même outil, flag -p/--print. Ce qui change : pas d’interactivité, donc pas de confirmations, donc pré-configuration obligatoire.

« Que valent les revues de PR par IA ? » Excellentes pour : bugs évidents, incohérences de convention, oublis (gestion d’erreur, cas limites), fautes de documentation. Limitées pour : pertinence métier, choix d’architecture de fond. D’où la recommandation : non bloquantes, en complément de l’humain.

« Et les outils MCP (mcp__*) ? » Chaque serveur MCP connecté expose ses outils sous le préfixe mcp__nomserveur__nomoutil. Ils entrent dans le même modèle allow/deny. Règle d’architecte : auditer chaque serveur MCP comme une dépendance de sécurité (qui l’a écrit ? que fait-il vraiment ?) avant de l’autoriser — c’était l’objet de la Session 5.

5. Barème et corrigés synthétiques

Exercice 1 (CLAUDE.md) : /10 — 4 sections (4 pts), commandes exactes (2 pts), 2+ gotchas spécifiques (2 pts), concision < 100 lignes (2 pts).
Exercice 2 (CI/CD) : /15 — pattern correctement choisi et justifié (3 pts), workflow fonctionnellement plausible (4 pts), settings.json au moindre privilège (4 pts), gestion d’échec/coûts (2 pts), aucune faute de sécurité rédhibitoire (2 pts). Faute rédhibitoire = « autorise tout » avec secrets : plafonne la note à 7.
Exercice 3 (hooks) : /10 — bon événement pour chaque besoin (4 pts), logique de filtrage réaliste (3 pts), justification prompt vs permission vs hook (3 pts).
Quiz : /10, corrigé en annexe du quiz. Seuil indicatif de préparation certification : 8/10.

6. Pour aller plus loin (à mentionner en clôture)

Documentation officielle Claude Code (référence des settings, hooks et flags — à consulter à jour, l’outil évolue vite ⚠).
Guide de référence du cours, chapitres 5 et 13.
Exercice bonus : brancher un hook Notification sur le canal de messagerie de l’équipe et mesurer le temps de réaction moyen aux demandes de permission.