# 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 : 1. **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é. 2. **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. 3. **Configurer le répertoire `.claude/`** : `settings.json` (outils autorisés via `allowedTools`), commandes personnalisées (`.claude/commands/`), hooks. 4. **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. 5. **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. 6. **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). 7. **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. 8. **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. 9. **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 :** 1. **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. 2. **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). 3. **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`). 4. **É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. 5. **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 :** 1. **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. 2. **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 ». 3. **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. 4. **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é. 5. **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 :** 1. **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 | 2. **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). 3. **Exemple canonique à projeter :** ```json { "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.* 4. **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). 5. **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 :** 1. **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. 2. **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. 3. **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. 4. **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 :** 1. **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. 2. **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. 3. **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/`. 4. **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). 5. **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.