# Guide du formateur — Niveau Avancé, Session 9
# « Scénarios de certification »

**Programme :** Applied AI — Yann Isola
**Public :** Architectes solutions préparant la certification *Claude Certified Architect*
**Durée :** 2 h 00 (+ 10 min de pause recommandée à mi-parcours)
**Prérequis :** Sessions 1 à 8 du niveau avancé (API Claude, tool use, MCP, Claude Code, prompt engineering avancé, contexte & fiabilité). Cette session **ne présente aucune notion nouvelle** : elle assemble tout ce qui a été vu, sous l'angle exact de l'examen.
**Matériel :** page web interactive de la session (`webpage/index.html` — analyseur de scénarios, tracker de couverture des domaines, simulateur d'examen chronométré), projecteur, feuille de score par participant.

---

## Objectifs pédagogiques

À la fin de la session, chaque participant sait :

1. **Décrire** le format de l'examen : 60 questions, 90 minutes ⚠, QCM (QCM = Questionnaire à Choix Multiples) et questions basées sur des scénarios, seuil de réussite 72 % ⚠ (soit 720 sur une échelle de 100 à 1000), 4 scénarios tirés parmi 8, aucune pénalité pour une mauvaise réponse.
2. **Cartographier** les 5 domaines de l'examen et leur pondération : Architecture & orchestration d'agents (27 %), Conception d'outils & intégration MCP (18 %), Configuration & workflows Claude Code (20 %), Prompt engineering & sortie structurée (20 %), Gestion du contexte & fiabilité (15 %).
3. **Analyser** chacun des 8 scénarios de l'examen : identifier les décisions d'architecture attendues, les pièges récurrents et les domaines convoqués.
4. **Appliquer** la grille de lecture « cause racine → moindre effort → garantie exigée » pour éliminer les distracteurs d'un QCM de certification.
5. **Auto-évaluer** sa couverture des 5 domaines et construire un plan de révision priorisé par pondération.
6. **Gérer** le temps d'examen : 90 secondes par question en moyenne ⚠, stratégie de marquage et de second passage.

> ⚠ **Convention de la session :** tous les chiffres marqués ⚠ (format d'examen, nombre de questions, durée, seuil, pondérations) sont **volatils**. Ils reflètent le guide d'examen au moment de la rédaction. Réflexe absolu : vérifier la page officielle de la certification Anthropic avant de réserver l'examen.

---

## Plan minuté

| Bloc | Durée | Contenu |
|------|-------|---------|
| 0. Ouverture | 5 min | Format d'examen, règles du jeu, méthode de la session |
| 1. La grille de lecture des QCM | 10 min | Anatomie d'une question de certification, méthode d'élimination |
| 2. Scénarios 1 & 8 — Support client & outils agentiques | 20 min | Routage, escalade, préconditions, sélection et chaînage d'outils |
| 3. Scénarios 3 & 7 — Multi-agents & IA conversationnelle | 20 min | Coordinateur/sous-agents, consensus, sessions avec état, mémoire |
| **Pause** | 10 min | |
| 4. Scénarios 2, 4 & 5 — Claude Code (dev, productivité, CI/CD) | 25 min | CLAUDE.md, commandes slash, mode plan, headless, revue de PR |
| 5. Scénario 6 — Extraction de données structurées | 15 min | Schémas JSON, validation, cas limites, calibrage de confiance |
| 6. Simulateur d'examen | 20 min | Mini-examen chronométré (page web), correction collective |
| 7. Plan de révision & clôture | 5 min | Tracker de domaines, priorisation, logistique d'examen |

---

## Bloc 0 — Ouverture (5 min)

**Message d'accroche :** « Vous avez huit sessions de matière dans la tête. L'examen ne vous demandera pas de la réciter : il vous mettra dans la peau d'un architecte face à un système qui dysfonctionne, avec quatre corrections plausibles — dont trois sont des pièges bien construits. Aujourd'hui, on apprend à penser comme l'auteur de la question. »

### Le format, noir sur blanc

Projeter et commenter ce tableau (chiffres volatils ⚠) :

| Paramètre | Valeur ⚠ |
|---|---|
| Nombre de questions | 60 |
| Durée | 90 minutes (soit 90 s/question en moyenne) |
| Type | QCM, 1 bonne réponse sur 4 + questions basées sur des scénarios |
| Notation | Échelle 100–1000, seuil **720** (≈ 72 %) |
| Pénalité pour erreur | **Aucune** — répondre à toutes les questions, toujours |
| Scénarios | 4 tirés aléatoirement parmi 8 |

**Trois conséquences pratiques à marteler :**

1. **Aucune pénalité** → on ne laisse jamais une question vide. Même au hasard, c'est 25 % d'espérance de gain.
2. **4 scénarios sur 8** → on ne peut pas faire d'impasse. Chaque scénario doit être maîtrisé, car on ne sait pas lesquels tomberont.
3. **72 % de seuil** → on a droit à ~16 erreurs sur 60. C'est confortable si les 3 domaines les plus lourds (27 + 20 + 20 = 67 % de l'examen) sont solides.

### Les 5 domaines et leur poids

| Domaine | Pondération | ≈ Questions sur 60 ⚠ |
|---|---|---|
| 1. Architecture & orchestration d'agents | 27 % | ~16 |
| 2. Conception d'outils & intégration MCP | 18 % | ~11 |
| 3. Configuration & workflows Claude Code | 20 % | ~12 |
| 4. Prompt engineering & sortie structurée | 20 % | ~12 |
| 5. Gestion du contexte & fiabilité | 15 % | ~9 |

**Point de stratégie :** le Domaine 1 pèse presque le double du Domaine 5. Une heure de révision sur l'orchestration d'agents « rapporte » statistiquement plus qu'une heure sur la gestion de contexte — mais attention, les domaines s'entrecroisent dans les scénarios : une question « support client » peut évaluer le Domaine 5 (escalade).

---

## Bloc 1 — La grille de lecture des QCM (10 min)

### 1.1 Anatomie d'une question de certification

Chaque question suit le même squelette :

1. **Situation** — un système en production avec un symptôme mesuré (« dans 12 % des cas, l'agent saute `get_customer`… ») ;
2. **Question** — presque toujours une variante de « quel changement est **le plus efficace** ? » ou « quelle est la **première** étape ? » ;
3. **Quatre options** — une correcte, trois distracteurs construits selon des recettes identifiables.

**Insister sur les mots-pièges de l'énoncé :** « le plus efficace », « la première étape », « au moindre effort », « le mieux ». Ce ne sont pas des ornements : ils signifient que **plusieurs options peuvent être techniquement valables**, et qu'on départage par le rapport coût/impact ou par l'ordre logique d'intervention.

### 1.2 Les quatre familles de distracteurs

Faire construire ce tableau avec la salle (elle a vu assez de questions dans les sessions précédentes pour le remplir) :

| Famille de distracteur | Signature | Exemple type |
|---|---|---|
| **Le prompt magique** | Résoudre par le prompt ce qui exige une garantie déterministe | « Améliorer le prompt système » face à une règle métier critique |
| **La sur-ingénierie** | Un composant lourd (classificateur ML, couche de routage) pour un problème simple | « Entraîner un classificateur séparé » quand des critères explicites suffisent |
| **La fonctionnalité inventée** | Un drapeau, une variable ou un fichier qui n'existe pas | `CLAUDE_HEADLESS=true`, `--batch`, `.claude/config.json` |
| **Le symptôme, pas la cause** | Une correction plausible qui traite un autre problème | « Analyse de sentiment » pour un problème de calibrage d'escalade |

### 1.3 La grille de lecture en trois questions

À appliquer systématiquement, dans l'ordre :

1. **Quelle est la cause racine ?** (pas le symptôme — relire la situation, les données chiffrées pointent la cause)
2. **La règle exige-t-elle une garantie déterministe ou une conformité probabiliste suffit-elle ?** (déterministe → hooks/préconditions programmatiques ; probabiliste → prompt/few-shot)
3. **Parmi les options qui traitent la cause, laquelle a le meilleur rapport effort/impact ?** (la certification récompense la correction la plus simple qui règle le problème)

**Démo au tableau** avec la Question 1 du guide d'examen (préconditions bloquant `process_refund`) : dérouler la grille pas à pas. La réponse A (précondition programmatique) sort en 30 secondes, car la situation dit « remboursements incorrects » = règle métier critique = garantie déterministe exigée = les options prompt (B, C) tombent d'office.

---

## Bloc 2 — Scénarios 1 & 8 : Support client & outils agentiques (20 min)

### 2.1 Scénario 1 — Agent de support client

**L'énoncé du guide :** agent construit avec le Claude Agent SDK (SDK = Software Development Kit, kit de développement logiciel) pour gérer retours, litiges de facturation et problèmes de compte. Outils MCP (MCP = Model Context Protocol, protocole de contexte de modèle) : `get_customer`, `lookup_order`, `process_refund`, `escalate_to_human`. Objectif : résolution au premier contact > 80 % avec escalade appropriée.

**Domaines convoqués :** 1 (orchestration, préconditions), 2 (descriptions d'outils, erreurs structurées), 5 (escalade, ambiguïté).

**Les décisions d'architecture attendues — à dérouler au tableau :**

| Problème dans le scénario | Réponse d'architecte attendue | Pourquoi pas les alternatives |
|---|---|---|
| L'agent saute la vérification d'identité avant un remboursement | **Précondition programmatique** (hook) qui bloque `process_refund` tant que `get_customer` n'a pas renvoyé un ID vérifié | Le prompt = conformité probabiliste ; l'argent exige du déterministe |
| Mauvais routage entre `get_customer` et `lookup_order` | **Enrichir les descriptions d'outils** : formats d'entrée, exemples, limites, quand utiliser l'un vs l'autre | Les descriptions sont le mécanisme n°1 de sélection ; le few-shot vient après |
| Escalade mal calibrée (escalade les cas simples, garde les cas complexes) | **Critères d'escalade explicites + exemples few-shot** dans le prompt système | La confiance auto-évaluée est peu fiable ; le sentiment ≠ complexité |
| Plusieurs correspondances client pour un nom | **Demander des identifiants supplémentaires** à l'utilisateur | Jamais de supposition heuristique sur l'identité |
| Demande explicite de parler à un humain | **Escalade immédiate**, sans investigation préalable | Retarder une demande explicite dégrade la satisfaction et viole le contrat d'escalade |

**Point d'attention sentiment :** le scénario mentionne l'analyse de sentiment. À l'examen, elle apparaît presque toujours en **distracteur** : le sentiment (colère, frustration) est un signal de ton, pas un indicateur fiable de complexité du cas ni un critère d'escalade en soi. Un client furieux peut avoir un problème trivial ; un client calme, un cas d'exception de politique inextricable. La bonne pratique : le sentiment peut moduler le **ton** de la réponse, mais l'escalade se décide sur des **critères de politique explicites**.

**Protocole de transfert (handoff) :** lors de l'escalade, produire un résumé structuré — ID client, motif, actions déjà tentées, action recommandée. Une question d'examen classique oppose « transférer la conversation brute » (mauvais : l'humain doit tout relire) à « résumé structuré » (bon).

### 2.2 Scénario 8 — Outils d'IA agentique

**Contexte honnête à donner :** ce scénario est signalé par des candidats mais moins documenté dans les guides communautaires ⚠. Il recouvre trois compétences transverses : **sélection d'outils, chaînage, récupération d'erreurs**. Bonne nouvelle : tout est déjà couvert par les Domaines 1 et 2 — c'est une recombinaison.

**Sélection d'outils — les règles à connaître par cœur :**

- Trop d'outils par agent **réduit** la fiabilité de la sélection (l'exemple canonique : 18 outils au lieu de 4-5). La réponse d'examen : restreindre l'ensemble d'outils au périmètre du rôle.
- Des descriptions ambiguës ou qui se chevauchent → mauvais routage. Première correction : réécrire/renommer (`analyze_content` → `extract_web_results`).
- `tool_choice` : `"auto"` (le modèle peut répondre en texte), `"any"` (doit appeler un outil, n'importe lequel), `{"type": "tool", "name": "..."}` (outil forcé). Question type : « garantir une sortie structurée quand plusieurs schémas existent » → `"any"` ; « garantir un outil précis en premier » → sélection forcée.

**Chaînage — deux patrons :**

- **Chaînage imposé par le logiciel** (préconditions, hooks) quand l'ordre est une règle métier ;
- **Chaînage guidé par le prompt** quand l'ordre est une préférence. L'examen teste la capacité à choisir le bon.

**Récupération d'erreurs — la taxonomie à réciter :**

| Catégorie d'erreur | Exemple | Réessayable ? | Bonne réponse de l'outil |
|---|---|---|---|
| Transitoire | timeout, service indisponible | Oui | `errorCategory: "transient"`, `isRetryable: true` |
| Validation | format d'entrée invalide | Oui, après correction de l'entrée | Message précisant le format attendu |
| Métier | remboursement au-dessus du seuil de politique | **Non** | `retryable: false` + explication lisible |
| Permission | accès refusé | Non (escalader) | Distinguer d'un résultat vide valide |

**Le piège d'or du Domaine 2 :** distinguer « échec d'accès » (il faut décider de réessayer ou d'escalader) de « résultat vide valide » (la recherche a fonctionné, il n'y a juste aucune correspondance). Un outil qui renvoie un ensemble vide en cas de timeout **masque un échec en succès** — anti-modèle certain à l'examen.

---

## Bloc 3 — Scénarios 3 & 7 : Multi-agents & IA conversationnelle (20 min)

### 3.1 Scénario 3 — Système de recherche multi-agents

**L'énoncé du guide :** coordinateur qui délègue à des sous-agents spécialisés (recherche web, analyse de documents, synthèse, génération de rapports). Sortie : rapports complets **avec citations**.

**Domaines convoqués :** 1 (lourdement — c'est le cœur des 27 %), 2 (allocation d'outils), 5 (propagation d'erreurs, provenance).

**L'architecture en étoile (hub-and-spoke) — les invariants :**

1. **Le coordinateur possède toute la communication** inter-agents : décomposition, délégation, agrégation, gestion d'erreurs. Les sous-agents ne se parlent pas directement (observabilité).
2. **Les sous-agents ont un contexte isolé** : ils n'héritent **pas** de l'historique du coordinateur. Tout contexte nécessaire doit être **explicitement inclus dans leur prompt**. Question d'examen récurrente : un sous-agent produit un résultat hors sujet → cause probable : le contexte des phases précédentes ne lui a pas été transmis.
3. **Parallélisme** : plusieurs appels `Task` dans un seul tour du coordinateur engendrent des sous-agents parallèles. Les `allowedTools` du coordinateur doivent inclure `"Task"`.
4. **Prompts du coordinateur en objectifs et critères de qualité**, pas en instructions pas-à-pas (sinon on perd l'adaptativité qui justifie le multi-agents).

**Les trois pannes classiques du scénario 3 — et leur diagnostic :**

| Symptôme | Cause racine | Correction |
|---|---|---|
| Le rapport ne couvre qu'une partie du sujet | **Décomposition trop étroite par le coordinateur** (il a découpé « industries créatives » en 3 sous-thèmes visuels) | Revoir le prompt de décomposition du coordinateur — les sous-agents ont bien exécuté ce qu'on leur a demandé |
| Timeout d'un sous-agent → tout le workflow échoue ou statut générique | Propagation d'erreurs mal conçue | **Contexte d'erreur structuré** : type d'échec, requête tentée, résultats partiels, alternatives — le coordinateur décide |
| Latence +40 % à cause d'allers-retours de vérification | La synthèse repasse par le coordinateur pour chaque vérification simple | **Moindre privilège gradué** : donner à la synthèse un outil `verify_fact` limité pour les 85 % de cas simples, garder le chemin coordinateur pour le complexe |

**Consensus et contradictions — le patron attendu :** deux sources crédibles donnent des chiffres contradictoires (40 % vs 12 %). La bonne réponse d'examen n'est **jamais** de choisir heuristiquement, ni d'escalader en bloquant tout, ni de transmettre sans marquer le conflit. C'est : **conserver les deux valeurs, annoter explicitement le conflit avec attribution des sources, et laisser le coordinateur réconcilier**. Ajouter les dates de publication (une « contradiction » est souvent une différence temporelle).

**Citations et provenance :** l'attribution se perd au résumé si on ne préserve pas les correspondances « affirmation → source ». Exiger des sous-agents une sortie structurée : affirmation, URL/nom du document, citation, date. Renvoyer à la session 8 pour la chaîne de provenance complète.

### 3.2 Scénario 7 — Modèles d'architecture d'IA conversationnelle

**L'énoncé du guide :** systèmes conversationnels multi-tours — gestion de la fenêtre de contexte, persistance des instructions au fil des tours, stratégies de mémoire, conception d'outils pour exécution sûre, entrées ambiguës ou contradictoires.

**Domaines convoqués :** 5 (lourdement), 1, 4.

**Le rappel structurant n°1 (le plus testé) :** l'API est **sans état** (stateless). Chaque requête doit renvoyer tout l'historique nécessaire. Il n'y a pas de « session côté serveur » dans l'API Messages de base. Les sessions avec état sont une **responsabilité applicative** (ou une fonctionnalité du SDK/Claude Code : `--resume`, `fork_session`).

**Stratégies de mémoire — le tableau de décision :**

| Stratégie | Principe | Quand | Risque |
|---|---|---|---|
| Historique complet | Tout renvoyer à chaque tour | Conversations courtes | Saturation + coût quadratique |
| Fenêtre glissante | Ne garder que les N derniers tours | Sessions où le passé lointain n'importe pas | Perte d'engagements pris tôt |
| Résumé progressif | Résumer les tours anciens | Sessions longues | Les **valeurs numériques, dates, montants** se diluent en résumés vagues |
| Hybride (résumé + verbatim récent + bloc de faits) | Résumé ancien + N tours verbatim + **« case facts » persistant** hors résumé | Production sérieuse | Complexité d'implémentation |

**Le patron « case facts » est la réponse-réflexe :** extraire les faits transactionnels (numéro de commande, montants, décisions prises, engagements) dans un bloc persistant **jamais résumé**, injecté à chaque tour. C'est la parade au risque n°1 du résumé progressif.

**Persistance des instructions :** les instructions du prompt système se diluent dans les très longues conversations (effet « perdu au milieu » : le modèle traite bien le début et la fin, moins le milieu). Parades : réinjecter les contraintes critiques près de la fin du contexte, structurer avec des balises XML (XML = eXtensible Markup Language, langage de balisage extensible) séparant système / données / instructions.

**Entrées ambiguës ou contradictoires :** demander une clarification quand l'ambiguïté porte sur une action irréversible ; pour les demandes multi-aspects, décomposer explicitement en éléments distincts et les traiter un par un.

---

## Bloc 4 — Scénarios 2, 4 & 5 : Claude Code (25 min)

C'est le bloc le plus dense : trois scénarios pour le Domaine 3 (20 %) plus une partie du Domaine 1. Annoncer la structure : configuration (S2) → productivité (S4) → CI/CD (S5).

### 4.1 Scénario 2 — Génération de code avec Claude Code

**Les quatre mécanismes de configuration — hiérarchie à connaître par cœur :**

| Mécanisme | Emplacement | Portée | Partagé via VCS (VCS = Version Control System, système de gestion de versions) ? |
|---|---|---|---|
| CLAUDE.md utilisateur | `~/.claude/CLAUDE.md` | Toutes les sessions de **cet utilisateur** | **Non** |
| CLAUDE.md projet | `CLAUDE.md` racine ou `.claude/CLAUDE.md` | Toute l'équipe sur ce dépôt | **Oui** |
| CLAUDE.md répertoire | sous-répertoire du projet | Fichiers de ce sous-arbre | Oui |
| Règles ciblées | `.claude/rules/*.md` avec frontmatter `paths:` (motifs glob) | Chargées **uniquement** en éditant des fichiers correspondants | Oui |

**Le diagnostic d'examen classique :** « un nouveau membre de l'équipe n'a pas les conventions » → elles sont au niveau **utilisateur** au lieu du niveau **projet**. Variante : « les conventions de test doivent s'appliquer aux fichiers `**/*.test.tsx` éparpillés partout » → `.claude/rules/` avec motif glob, **pas** un CLAUDE.md par répertoire (les fichiers concernés sont dans trop de répertoires), **pas** tout dans le CLAUDE.md racine (charge du contexte en permanence).

**Modularisation :** syntaxe `@path` (`@./standards/coding-style.md`) pour inclure des fichiers externes ; `.claude/rules/` thématiques (testing.md, api-conventions.md) plutôt qu'un CLAUDE.md monolithique.

**Commandes slash et Skills :**

- Commandes de **projet** : `.claude/commands/` (versionnées, toute l'équipe) ; commandes **personnelles** : `~/.claude/commands/`.
- Skills : `.claude/skills/` avec frontmatter `SKILL.md` — `context: fork` (exécution dans un contexte isolé, ne pollue pas la session principale — réponse-réflexe pour les skills verbeux), `allowed-tools` (restriction d'outils), `argument-hint` (guidage des paramètres).

**Mode planification vs exécution directe — la règle de décision :**

- **Mode plan** : changements importants, plusieurs approches viables, décisions architecturales (restructurer un monolithe, migration touchant des dizaines de fichiers). Permet l'exploration sûre avant modification.
- **Exécution directe** : changement simple et bien compris (une validation à ajouter, un bug avec trace de pile claire dans un seul fichier).
- Le sous-agent **Explore** isole la sortie verbeuse de découverte (protection du contexte).
- La réponse « commencer en direct et passer en plan quand ça coince » est un distracteur : c'est réactif, on paie déjà la reprise.

### 4.2 Scénario 4 — Outils de productivité pour développeurs

**Les outils intégrés — qui fait quoi (question d'examen quasi garantie) :**

| Outil | Usage | Ne pas confondre avec |
|---|---|---|
| **Grep** | Chercher dans le **contenu** des fichiers (noms de fonctions, messages d'erreur, imports) | Glob (noms de fichiers) |
| **Glob** | Trouver des fichiers par **motifs de nom/extension** | Grep (contenu) |
| **Read / Write** | Lecture / écriture de fichier entier | Edit (modification ciblée) |
| **Edit** | Changement précis par correspondance de texte **unique** ; si non unique → échec → repli Read + Write | |
| **Bash** | Commandes shell (tests, build, git) | |

**Le patron d'exploration d'une base de code inconnue :** Grep les points d'entrée → Read pour tracer les flux → construire la compréhension **incrémentalement**. À l'examen : « l'agent doit comprendre comment la fonction X est utilisée à travers des modules wrappers » → Grep sur le nom, puis Read des call sites.

**MCP dans Claude Code :**

- Portée **projet** : `.mcp.json` (partagé, pour l'équipe) ; portée **utilisateur** : `~/.claude.json` (expériences personnelles).
- Secrets : substitution de variables d'environnement dans `.mcp.json` (`${GITHUB_TOKEN}`) — **jamais** de token en clair dans un fichier versionné.
- Les **ressources MCP** servent de « catalogues de contenu » (schémas de base de données, résumés) pour éviter des appels d'outils exploratoires répétés.
- Préférer les serveurs MCP **communautaires** aux serveurs maison pour les intégrations standard (GitHub, bases de données).

### 4.3 Scénario 5 — Claude Code pour l'intégration continue

**Le mode headless (headless = sans tête, non interactif) — les drapeaux exacts :**

```bash
# Le pipeline reste bloqué ? Il manque -p (--print) :
claude -p "Analyse cette pull request pour les problèmes de sécurité"

# Sortie structurée exploitable par le pipeline :
claude -p "Revue de sécurité de ce diff" \
  --output-format json \
  --json-schema review_schema.json
```

Distracteurs récurrents : `CLAUDE_HEADLESS=true`, `--batch`, redirection stdin — **fonctionnalités inexistantes ou contournements**. La réponse documentée est `-p` / `--print` ⚠.

**Architecture d'une revue de PR (PR = Pull Request, demande de fusion) automatisée :**

1. **Instance indépendante pour la revue** : la session qui a généré le code est moins efficace pour le réviser (elle garde son contexte de raisonnement et ne remet pas en question ses propres décisions). Réviser = nouvelle instance sans contexte de génération.
2. **CLAUDE.md comme contexte CI** : normes de test, critères de revue, fixtures disponibles — c'est ce qui rend la revue pertinente pour CE projet.
3. **Minimiser les faux positifs** : critères **explicites et catégoriels** (« signaler : bugs, sécurité ; ignorer : style mineur ») plutôt que « sois plus conservateur » (guidage générique inefficace). Les taux de faux positifs élevés dans une catégorie sapent la confiance dans toutes les autres → désactiver temporairement les catégories bruyantes.
4. **Re-exécution après nouveaux commits** : inclure les résultats de revue antérieurs pour ne signaler que le nouveau/non corrigé.
5. **Grandes PR** : passes par fichier + passe d'intégration inter-fichiers (dilution de l'attention en passe unique — cf. session 8). Le distracteur : « prendre un modèle à plus grande fenêtre de contexte » — une fenêtre plus grande ne corrige pas la qualité de l'attention.

**Batch vs temps réel en CI :** vérification **bloquante** avant fusion → API synchrone (les développeurs attendent) ; rapport de **nuit** (dette technique, audit hebdomadaire) → Message Batches API (−50 % ⚠, fenêtre de traitement jusqu'à 24 h ⚠, pas de SLA de latence — SLA = Service Level Agreement, engagement de niveau de service). La Batch API ne prend pas en charge les appels d'outils multi-tours dans une requête ⚠ ; corrélation par `custom_id` ; en cas d'échec partiel, ne re-soumettre que les éléments échoués.

---

## Bloc 5 — Scénario 6 : Extraction de données structurées (15 min)

**L'énoncé du guide :** extraire des informations de documents non structurés (factures, contrats, documents semi-structurés), valider par schémas JSON (JSON = JavaScript Object Notation, notation d'objets JavaScript), maintenir une haute précision, gérer les cas limites.

**Domaines convoqués :** 4 (lourdement), 5 (calibrage de confiance, supervision humaine).

### 5.1 La pile d'extraction fiable — de bas en haut

1. **`tool_use` + schéma JSON** = le moyen le plus fiable de garantir une sortie conforme au schéma. Élimine les erreurs de **syntaxe** JSON. Avec `tool_choice: "any"` ou forcé, le modèle ne peut pas répondre en texte libre.
2. **Mais le schéma n'empêche pas les erreurs sémantiques** : totaux qui ne se réconcilient pas, valeur dans le mauvais champ. Point d'examen certain : « nous avons un schéma strict, pourquoi y a-t-il encore des erreurs ? » → le schéma valide la **forme**, pas le **sens**.
3. **Conception du schéma contre l'hallucination :** champs **optionnels/nullable** quand la source peut ne pas contenir l'information (un champ requis force le modèle à inventer) ; enums avec `"other"`/`"unclear"` + champ de détail pour l'extensibilité.
4. **Auto-vérification sémantique :** extraire à la fois `calculated_total` (somme des lignes) et `stated_total` (total affiché) pour détecter les écarts par comparaison programmatique.
5. **Réessai avec feedback d'erreur :** renvoyer le document original + l'extraction incorrecte + les **erreurs de validation précises**. Limite absolue : le réessai est **inefficace si l'information est absente de la source** (elle est dans un document externe) — la détecter et router en revue humaine, pas boucler.
6. **Few-shot pour les cas ambigus :** 2-4 exemples montrant l'extraction correcte sur des documents de **structures différentes** — le few-shot réduit les hallucinations d'extraction.

### 5.2 Calibrage et supervision humaine (Domaine 5 dans le scénario 6)

**Le piège des métriques agrégées :** « 97 % de précision globale » peut masquer 60 % sur un type de document minoritaire ou sur un champ précis. Réponses d'examen :

- **Échantillonnage aléatoire stratifié** des extractions à haute confiance (détecter les nouveaux motifs d'erreur) ;
- **Précision par type de document et par champ** avant d'automatiser quoi que ce soit ;
- **Scores de confiance au niveau du champ**, calibrés sur un ensemble de validation étiqueté ;
- **Routage en revue humaine** des extractions à faible confiance ou à source ambiguë.

**Séquence de mise en production attendue :** échantillon → itération de prompt sur l'échantillon → validation stratifiée → seuils de confiance calibrés → automatisation avec échantillonnage continu. Toute option d'examen qui automatise à 100 % dès « la précision globale est bonne » est un distracteur.

---

## Bloc 6 — Simulateur d'examen (20 min)

**Déroulé :**

1. Ouvrir la page web de la session, onglet **Simulateur d'examen**. 12 questions, 18 minutes chronométrées (rythme réel : 90 s/question).
2. Chaque participant travaille seul, en conditions d'examen (pas de documentation).
3. À la fin : score individuel + correction collective des 3 questions les plus échouées (la page affiche les statistiques de la salle si le formateur relève les scores à main levée).

**Pendant la correction, marteler la méthode, pas la réponse :** pour chaque question ratée, faire verbaliser : « quelle famille de distracteur m'a eu ? » (prompt magique / sur-ingénierie / fonctionnalité inventée / symptôme). L'objectif est que chacun reparte avec la conscience de **son** biais dominant.

**Stratégie de temps à transmettre :**

- Premier passage : répondre à tout ce qui sort en < 60 s, **marquer** le reste ;
- Second passage : les questions marquées, avec le temps restant ;
- Dernière minute : **aucune question vide** (pas de pénalité) ;
- Les questions basées sur scénario sont plus longues à lire : lire la **question** avant la situation pour savoir quoi chercher.

---

## Bloc 7 — Plan de révision & clôture (5 min)

1. **Tracker de domaines** (page web, onglet dédié) : chaque participant s'auto-évalue sur les compétences des 5 domaines avec un niveau de confiance (🟢 maîtrisé / 🟡 à revoir / 🔴 lacune). La page calcule un score de préparation **pondéré par les poids d'examen**.
2. **Règle de priorisation :** réviser d'abord les 🔴 des domaines lourds (D1 27 %, D3 20 %, D4 20 %), puis les 🟡. Un 🔴 en D1 coûte statistiquement ~4 questions ; un 🔴 en D5, ~1,5.
3. **Logistique :** vérifier sur la page officielle Anthropic ⚠ les modalités à jour (inscription, surveillance, langue, politique de repassage). Rappeler que **tous les chiffres de cette session sont volatils**.
4. **Exit ticket :** chaque participant note son scénario le plus faible et son créneau de révision. Annoncer les exercices (conception d'architecture S1, comparaison d'approches S3, grille d'évaluation S6) et la session 10.

---

## Pièges de certification — antisèche du formateur

À distribuer ou projeter en fin de session. Les « quirks » les plus rentables :

1. **Déterministe vs probabiliste** : règle métier critique (argent, identité, conformité) → hooks/préconditions, jamais le prompt seul.
2. **Descriptions d'outils** = mécanisme n°1 de sélection. Première correction en cas de mauvais routage, avant few-shot ou couche de routage.
3. **Sous-agents = contexte isolé.** Rien n'est hérité ; tout se passe explicitement dans le prompt.
4. **Décomposition trop étroite** : quand la couverture d'un rapport est partielle, suspecter le coordinateur, pas les sous-agents.
5. **Erreur structurée > statut générique** ; échec d'accès ≠ résultat vide valide ; ne jamais masquer un échec en succès.
6. **`-p` / `--print`** pour le headless ; `--output-format json` + `--json-schema` pour la CI. `CLAUDE_HEADLESS`, `--batch` : n'existent pas ⚠.
7. **`.claude/commands/`** = équipe (versionné) ; **`~/.claude/commands/`** = personnel. Même logique pour `.mcp.json` (projet) vs `~/.claude.json` (utilisateur).
8. **`.claude/rules/` + motifs glob** quand les conventions s'appliquent par type de fichier à travers toute la base de code.
9. **Schéma JSON = syntaxe garantie, sémantique non garantie.** Champs nullable contre l'hallucination ; réessai inutile si l'info est absente de la source.
10. **Batch** : −50 % ⚠, ≤ 24 h ⚠, pas de SLA → jamais pour du bloquant ; `custom_id` pour corréler ; re-soumettre seulement les échecs.
11. **Auto-revue faible** : instance indépendante pour réviser ; passes par fichier + passe d'intégration pour les grandes PR ; « plus grande fenêtre de contexte » ne répare pas l'attention.
12. **Sentiment ≠ complexité ; confiance auto-évaluée ≠ fiable.** Escalade sur critères explicites ; demande humaine explicite = escalade immédiate.
13. **Résumé progressif dilue les chiffres** → bloc « case facts » persistant hors résumé.
14. **Métriques agrégées mentent** → stratifier par type de document et par champ ; confiance au niveau du champ.
15. **Aucune pénalité à l'examen** → répondre à tout, toujours.

---

## Annexe — Correspondance scénarios × domaines

| Scénario | D1 (27 %) | D2 (18 %) | D3 (20 %) | D4 (20 %) | D5 (15 %) |
|---|---|---|---|---|---|
| S1 Support client | ●● | ●● | | ● | ●● |
| S2 Génération de code | ● | | ●●● | ● | |
| S3 Recherche multi-agents | ●●● | ● | | | ●● |
| S4 Productivité dev | ● | ●● | ●● | | ● |
| S5 Claude Code CI/CD | | | ●●● | ●● | ● |
| S6 Extraction structurée | | ● | | ●●● | ●● |
| S7 IA conversationnelle | ●● | ● | | ● | ●●● |
| S8 Outils agentiques | ●● | ●●● | | ● | ● |

(●●● = domaine dominant, ●● = fortement présent, ● = présent)

**Lecture stratégique :** D1 et D3 sont partout — impossible d'y être faible. D2 se concentre sur S1/S4/S8. D4 se joue surtout sur S5/S6. D5 est diffus mais culmine sur S7.