English

Slides — Session 6 : Claude Code & CI/CD

Programme : Applied AI — Niveau Avancé — Instructeur : Yann Isola
Format : 30 slides. Chaque slide comporte le contenu projeté puis les notes orateur.
Palette : encre #1A2230, sarcelle #0F7A6C, cuivre #B4612A, sarcelle claire #E9F6F3, fond #F4F7F6.

Slide 1 — Titre

Claude Code & CI/CD

L'agent dans votre terminal — puis dans votre pipeline, la nuit, sans vous

Applied AI — Niveau Avancé — Session 6 — Yann Isola

Slide 2 — Rappel express : Session 5

  • MCP (Model Context Protocol, protocole de contexte de modèle) : brancher des outils externes standardisés
  • Un serveur MCP = une dépendance de sécurité à auditer
  • La boucle agentique : planifier → agir → observer → corriger

Slide 3 — Objectifs & enjeu certification

À la fin de ces 2 h 30, vous saurez :

  1. Structurer un CLAUDE.md qui change tout
  2. Verrouiller les permissions outil par outil (settings.json)
  3. Concevoir des hooks (PreToolCall, PostToolCall, Notification, Stop)
  4. Intégrer Claude Code headless dans un pipeline CI/CD
  5. Maîtriser coûts et sessions longues (/cost, /compact, caching)

🎓 Domaine fortement pondéré à l'examen Claude Certified Architect

Slide 4 — Claude Code, c'est quoi ?

Un assistant de codage agentique dans le terminal

  • Il ne parle pas de votre code : il agit dessus
  • Boucle : lire → planifier → modifier → exécuter → observer → corriger
  • Instructions en langage naturel : « corrige le bug de TVA et ajoute un test »
  • Éditions multi-fichiers : raisonne à l'échelle du dépôt

Slide 5 — La métaphore en 4 temps (fil rouge de la session)

Composant Rôle Métaphore
CLAUDE.md Ce qu'il devrait faire 🧠 Le cerveau contextuel
settings.json Ce qu'il peut faire 🔒 La cage
Hooks Ce qui se passe quand il agit 📹 Les caméras
Mode headless Travail sans surveillance 🏭 L'employé du pipeline

Slide 6 — Il explore, il ne « voit » pas tout

  • Claude Code ne charge pas tout le dépôt en mémoire
  • Il explore à la demande : Glob (motifs de fichiers), Grep (recherche), Read (lecture)
  • Le contexte se construit incrémentalement
  • Seule exception : CLAUDE.md, chargé systématiquement

Slide 7 — Slash commands : le poste de pilotage

  • /init — inspecte le dépôt, génère un brouillon de CLAUDE.md
  • /review — lance une revue de code
  • /compactcompresse l'historique (résumé) → libère du contexte
  • /cost — consommation de tokens et coût de la session
  • Personnalisées : .claude/commands/deploy-check.md/deploy-check

Slide 8 — Démo live 🎬

Projet fil rouge : facturation-api

  1. claude puis /init → CLAUDE.md généré
  2. « Liste les fichiers de test et dis-moi ce qui n'est pas couvert »
  3. Observer : demandes de permission à chaque action sensible

Slide 9 — CLAUDE.md : le cerveau contextuel

  • Fichier Markdown à la racine, chargé à chaque session
  • = message système du projet, versionné avec le code, partagé par l'équipe
  • Analogie : le document d'onboarding d'un nouveau dev…
    …qu'il relirait intégralement chaque matin, sans jamais rien oublier

Slide 10 — La structure canonique

# facturation-api

## Vue d'ensemble
API REST de facturation — Python 3.12 / FastAPI / PostgreSQL.

## Conventions
- Docstrings en français, identifiants en anglais
- Montants TOUJOURS en centimes (entiers), jamais en flottants

## Commandes courantes
- Tests : poetry run pytest
- Lint : poetry run ruff check .

## Pièges connus
- tests/integration/ exige : docker compose up -d db
- NE JAMAIS éditer app/migrations/ à la main (Alembic)

Slide 11 — Anti-patterns du CLAUDE.md

  • ❌ Le roman de 800 lignes — consomme du contexte, dilue le critique. Cible : < 150 lignes
  • ❌ Les généralités — « écris du code propre » = zéro information
  • ❌ Le fichier périmé — commandes cassées = temps perdu à chaque session
  • ✅ Traitez-le comme du code : revue, mise à jour, propriétaire désigné

Slide 12 — Hiérarchie des CLAUDE.md

  • ~/.claude/CLAUDE.mdglobal (préférences personnelles, tous projets)
  • ./CLAUDE.mdprojet (l'essentiel)
  • ./services/api/CLAUDE.mdsous-dossier (monorepos)

Le plus spécifique complète le plus général.

Slide 13 — [Exercice 1] puis… la cage 🔒

Partie C — Permissions & outils intégrés

« La question n'est pas : peut-on faire confiance au modèle ?
La question est : quel périmètre lui a-t-on donné ? »

Slide 14 — Le catalogue des outils intégrés

Outil Fonction Risque
Read, LS, Glob, Grep Explorer, lire 🟢 Faible
TodoRead, TodoWrite Liste de tâches interne 🟢 Négligeable
WebFetch Récupérer une page web 🟠 Moyen
Write, Edit, MultiEdit Créer / modifier des fichiers 🟠 Élevé
Bash Exécuter du shell 🔴 Critique
mcp__* Outils MCP externes ⚪ Variable

Slide 15 — Les trois cercles de permission

  1. 🟢 Lecture libre — explorer ne coûte rien : Read, Glob, Grep, LS
  2. 🟠 Écriture surveillée — Write/Edit : validation ou motifs ciblés
  3. 🔴 Exécution verrouillée — Bash : liste blanche fine, commande par commande

Slide 16 — settings.json : allow / deny

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

⚠ Syntaxe exacte : voir doc officielle du jour — la logique est stable

Slide 17 — Ce que Claude Code ne peut pas faire

  • Sortir du répertoire de travail sans permission
  • Agir sans passer par un outil déclaré (tout est visible, journalisable)
  • Contourner un deny ou un hook bloquant

MAIS — le vecteur n°1 reste l'injection de prompt :
un commentaire de code ou une page web piégés peuvent contenir des instructions

Slide 18 — Atelier éclair : le configurateur 🔧

Scénario : revue de code en CI — lecture seule + commentaire

→ Quels outils dans allow ? Lesquels dans deny ?
(configurateur de permissions — page web)

Slide 19 — Hooks : les caméras 📹

Un hook = VOTRE script, exécuté automatiquement aux moments clés

  • Prompt → le modèle suit probablement
  • Hook → le code s'exécute à chaque fois, exactement comme écrit

Déterministe vs probabiliste : LA distinction d'architecte

Slide 20 — Les 4 événements du cycle de vie

Événement Quand Peut bloquer ? Exemple
PreToolCall Avant chaque appel d'outil ✅ Oui Refuser psql vers la prod
PostToolCall Après chaque appel ❌ Non Reformater après chaque Edit
Notification Besoin d'attention humaine ❌ Non Ping Slack
Stop Fin de la réponse/tâche ❌ Non Archiver le journal, notifier

Slide 21 — Les 3 familles de hooks

  1. Garde-fous (PreToolCall) — politiques inviolables
    permissions = QUELS outils · hooks = QUELLES utilisations
  2. Automatisation qualité (PostToolCall) — lint, format, vérif build
  3. Observabilité (tous) — journal d'audit complet de chaque action

Slide 22 — Persuasion, capacité, contrôle

Besoin Bon niveau
« Commente en français » CLAUDE.md (persuasion)
« Jamais de git push » Permission deny (capacité)
« psql OK sauf vers prod-db » Hook PreToolCall (contrôle fin)
« Reformater après édition » Hook PostToolCall (garantie)

Slide 23 — [Exercice 3] puis… l'employé du pipeline 🏭

Partie E — Mode headless & CI/CD

claude -p "Révise ce diff et liste les problèmes de sécurité"
  • -p / --print : pas d'interface, exécute, imprime, se termine
  • Code de sortie exploitable par le pipeline

Slide 24 — Headless : la règle d'or

En headless, personne ne confirme.

  • Outil non pré-autorisé → refus → tâche potentiellement incomplète
  • Donc : permissions pré-calibrées dans settings.json
  • Et : strict nécessaire de la tâche — c'est un agent sans surveillance

❌ Anti-pattern absolu : « autorise tout » sur un runner avec des secrets

Slide 25 — Pattern 1 : revue automatique de PR

PR ouverte → checkout → claude -p "revue du diff :
bugs, sécurité, conventions CLAUDE.md" → commentaire sur la PR
  • Permissions : lecture seule + Bash(git diff:*)
  • Non bloquante au lancement — complète l'humain, ne le remplace pas
  • Timeout sur le job = plafond de coût

Slide 26 — Patterns 2 & 3 : tests et documentation

Génération de tests (couverture en baisse)

  • Permissions : lecture + Write + Bash(pytest:*)
  • 💍 Mariage permission + hook : Write autorisé, hook PreToolCall vérifie que le chemin commence par tests/
  • Sortie : branche + PR, jamais de push direct sur main

Mise à jour de doc (après merge sur main)

  • Permissions : lecture + Edit limité à docs/
  • Sortie : PR de documentation

Slide 27 — Coûts : les trois réflexes

  1. /cost — visibilité : tokens et coût de la session
  2. /compact — compresser l'historique long (résumé) → contexte sain
  3. Prompt caching — les préfixes stables (CLAUDE.md, contexte) facturés à tarif réduit ⚠ taux : grille tarifaire du jour

En CI : timeout + limiter la taille des diffs + déclencheurs raisonnés

Slide 28 — Atelier : le concepteur de pipeline 🔧

Construisons le flux complet :

PR → Revue Claude Code → Tests → Déploiement

→ Pour chaque étape : permissions, bloquant/non-bloquant, timeout
(concepteur de pipeline — page web)

Slide 29 — La métaphore, bouclée

Composant Rôle Nature
🧠 CLAUDE.md Ce qu'il devrait faire Probabiliste (persuasion)
🔒 settings.json Ce qu'il peut faire Déterministe (capacité)
📹 Hooks Ce qui se passe quand il agit Déterministe (contrôle)
🏭 Headless Travail sans humain Pré-calibré, moindre privilège

Slide 30 — Quiz, exit tickets, Session 7

  • ✅ Quiz : 10 QCM — seuil certification : 8/10
  • 📝 Exit ticket : une décision d'architecture à appliquer dès demain
  • 🏠 À rendre : Exercice 2 complet (workflow + settings.json + note d'architecture)
  • 📅 Session 7 : (annoncer le thème du programme)

Notes orateur: Accueil. Teasing : « Aujourd'hui, on embauche un collègue. Il travaille dans votre terminal, il ne dort jamais, et à la fin de la session il sera salarié de votre pipeline CI/CD. La vraie question du jour : comment rédiger son contrat de travail. » Annoncer le poids certification de ce chapitre.

Notes orateur: 90 secondes. Question à la salle : « Qui exécute réellement un appel d'outil ? » Réponse attendue (Session 5 du niveau intermédiaire, rebrassée) : jamais le modèle, toujours votre code. Aujourd'hui, ce principe s'incarne dans un produit : Claude Code.

Notes orateur: Contrat clair. Précisez que l'examen teste le *jugement* (scénarios), pas les flags par cœur. Chaque partie se conclut par une question type certification.

Notes orateur: Insistez sur « agentique » : c'est la boucle de la Session 3, incarnée. Contre-exemple : l'autocomplétion suggère la ligne suivante ; Claude Code mène la *tâche* jusqu'au bout, tests compris.

Notes orateur: LA slide à mémoriser. Annoncez : « le plan de la session, c'est ce tableau, ligne par ligne ». Vous y reviendrez en clôture. À l'examen, beaucoup de questions se résument à : quel niveau (persuasion/capacité/contrôle) pour quel besoin ?

Notes orateur: Casse une idée reçue fréquente. Conséquence d'architecte : ce que vous voulez qu'il sache *toujours* doit être dans CLAUDE.md ; le reste, il le trouvera quand il en aura besoin.

Notes orateur: Sur les commandes personnalisées : un fichier Markdown = un prompt réutilisable versionné avec le projet. Exemples utiles : checklist de mise en prod, gabarit de revue, procédure de migration. C'est de l'outillage d'équipe, pas un gadget.

Notes orateur: 8 minutes max. Les demandes de permission qui apparaissent sont votre teaser de la Partie C : « notez que je dois approuver — qui décide de ce qui est approuvé d'office ? Nous, dans 30 minutes. » Si pas de réseau : captures d'écran de secours préparées.

Notes orateur: L'analogie onboarding fonctionne très bien. Chaque ligne investie dans CLAUDE.md économise des dizaines de corrections en aval — c'est le meilleur retour sur investissement de tout l'outillage.

Notes orateur: Les 4 sections : vue d'ensemble, conventions, commandes, gotchas. Insistez sur les commandes *exactes et copiables* : `poetry run pytest`, pas « lancer les tests ». Question certification : quelle section réduit le plus les erreurs d'exécution ? → les commandes exactes.

Notes orateur: Test du fichier générique : « si ce CLAUDE.md pouvait décrire n'importe quel projet, il ne décrit pas le vôtre. » Vous réutiliserez ce test en corrigeant l'Exercice 1.

Notes orateur: Cas d'usage monorepo : conventions différentes entre le front et le back. Transition exercice : « à vous — 20 minutes pour écrire le CLAUDE.md de facturation-api. Le constructeur web peut échafauder, mais la densification finale est manuelle. »

Notes orateur: Slide pivot après l'exercice et la pause. Annoncez : partie la plus importante de la session ET la plus piégeuse à l'examen. Ralentissez le rythme.

Notes orateur: Chapitre 13 du guide. Construisez le classement AVEC la salle avant d'afficher. `WebFetch` surprend en « moyen » : contenu web non fiable = vecteur d'injection de prompt, plus exfiltration possible. `Bash` non contraint = accès SSH donné à l'agent.

Notes orateur: Modèle mental simple qui résout 80 % des questions de scénario. Le moindre privilège de la Session 5, appliqué à un agent de codage.

Notes orateur: Trois règles : (1) motifs par préfixe de commande — `Bash(git diff:*)` couvre les variantes ; (2) le `deny` l'emporte TOUJOURS sur le `allow` ; (3) le non-listé → confirmation interactive… ou refus en headless. Cette troisième règle prépare la Partie E — plantez le décor maintenant.

Notes orateur: Le point rassurant ET le point inquiétant sur la même slide, volontairement. La défense contre l'injection n'est pas « le modèle est malin » mais « même manipulé, il ne PEUT pas exécuter ce qui est refusé ». Les permissions protègent contre la manipulation du modèle lui-même.

Notes orateur: 5 minutes, page web projetée, la salle vote. Réponse : Read/Glob/Grep/LS + `Bash(git diff:*)`, tout le reste refusé. Piège volontaire : quelqu'un proposera `Write` « pour écrire la revue » — non, la revue sort sur la sortie standard, c'est le pipeline qui poste le commentaire.

Notes orateur: Cette distinction revient à l'examen sous dix formes différentes. Formulation à faire noter : les politiques de sécurité vont dans les hooks/permissions (déterministe), les préférences et conventions dans CLAUDE.md (probabiliste).

Notes orateur: Faites verbaliser un cas d'usage par événement par la salle avant de montrer la colonne exemple. Subtilité PreToolCall : le blocage renvoie un *message* au modèle, qui ajuste sa stratégie — c'est un dialogue, pas un mur muet.

Notes orateur: La famille 3 parle aux participants en environnement régulé : le journal d'audit des actions de l'agent est ce que demandera l'auditeur. Un hook PostToolCall qui journalise outil + paramètres + résultat = auditabilité native.

Notes orateur: LA grille de lecture pour l'examen. Question type : « curl interdit vers l'externe mais autorisé en interne » → hook (logique conditionnelle), pas permission (trop binaire). Faites débattre 2 minutes puis lancez l'Exercice 3 (conception de hooks — 15 min de démarrage).

Notes orateur: Transition après l'exercice hooks. Le même binaire, un flag : l'agent devient un composant de pipeline. Posez la question qui tue : « qui clique sur "autoriser" à 3 h du matin dans un runner CI ? » → personne. Slide suivante.

Notes orateur: Question quasi certaine à l'examen (« le job s'arrête, outil refusé, cause ? » → permission manquante). Sur l'anti-pattern : si vous devez vraiment tout autoriser, c'est conteneur jetable + pas de réseau sortant + zéro secret. Sinon c'est une faille, pas un pipeline.

Notes orateur: Forces de la revue IA : bugs évidents, conventions, oublis de gestion d'erreur. Faiblesses : pertinence métier, architecture de fond. D'où « non bloquante » — on la durcit plus tard, données à l'appui, quand l'équipe lui fait confiance.

Notes orateur: Le « mariage permission + hook » est le pattern le plus élégant de la session : la permission ouvre la capacité, le hook la restreint finement. C'est exactement la question bonus de l'Exercice 2 — dites-le explicitement.

Notes orateur: Ordre de grandeur, sans chiffre gravé : « le token en cache coûte une fraction du token plein ». Le vrai levier CI n'est pas le tarif mais la discipline de déclenchement : reviser chaque push d'une PR de 40 commits = gaspillage ; réviser à l'ouverture + à la demande = raisonnable.

Notes orateur: 5 minutes en plénière avec la page web, puis lancez le cadrage de l'Exercice 2 (à terminer à la maison, relu en Session 7). Vérifiez que chaque binôme a choisi son pattern avant de les laisser partir.

Notes orateur: Retour à la slide 5, colonne « nature » en plus. Faites reformuler par un participant : « qu'est-ce qui va où ? » Sécurité → jamais dans le probabiliste. C'est la phrase à emporter pour l'examen.

Notes orateur: Quiz oral éclair recommandé : Q2, Q5, Q9. Ramassez les exit tickets — ils vous disent ce qui a marqué (et ce qui n'a pas imprimé). Rappelez que l'Exercice 2 sera relu en ouverture de Session 7 : la faute rédhibitoire « autorise tout + secrets » plafonne la note.