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 :

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.
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 %).
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.
Appliquer la grille de lecture « cause racine → moindre effort → garantie exigée » pour éliminer les distracteurs d’un QCM de certification.
Auto-évaluer sa couverture des 5 domaines et construire un plan de révision priorisé par pondération.
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 :

Aucune pénalité → on ne laisse jamais une question vide. Même au hasard, c’est 25 % d’espérance de gain.
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.
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 :

Situation — un système en production avec un symptôme mesuré (« dans 12 % des cas, l’agent saute get_customer… ») ;
Question — presque toujours une variante de « quel changement est le plus efficace ? » ou « quelle est la première étape ? » ;
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 :

Quelle est la cause racine ? (pas le symptôme — relire la situation, les données chiffrées pointent la cause)
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)
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 :

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é).
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.
Parallélisme : plusieurs appels Task dans un seul tour du coordinateur engendrent des sous-agents parallèles. Les allowedTools du coordinateur doivent inclure "Task".
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 :

# 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 :

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.
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.
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.
Re-exécution après nouveaux commits : inclure les résultats de revue antérieurs pour ne signaler que le nouveau/non corrigé.
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

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.
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.
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é.
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.
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.
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é :

Ouvrir la page web de la session, onglet Simulateur d’examen. 12 questions, 18 minutes chronométrées (rythme réel : 90 s/question).
Chaque participant travaille seul, en conditions d’examen (pas de documentation).
À 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)

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.
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.
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.
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 :

Déterministe vs probabiliste : règle métier critique (argent, identité, conformité) → hooks/préconditions, jamais le prompt seul.
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.
Sous-agents = contexte isolé. Rien n’est hérité ; tout se passe explicitement dans le prompt.
Décomposition trop étroite : quand la couverture d’un rapport est partielle, suspecter le coordinateur, pas les sous-agents.
Erreur structurée > statut générique ; échec d’accès ≠ résultat vide valide ; ne jamais masquer un échec en succès.
-p / --print pour le headless ; --output-format json + --json-schema pour la CI. CLAUDE_HEADLESS, --batch : n’existent pas ⚠.
.claude/commands/ = équipe (versionné) ; ~/.claude/commands/ = personnel. Même logique pour .mcp.json (projet) vs ~/.claude.json (utilisateur).
.claude/rules/ + motifs glob quand les conventions s’appliquent par type de fichier à travers toute la base de code.
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.
Batch : −50 % ⚠, ≤ 24 h ⚠, pas de SLA → jamais pour du bloquant ; custom_id pour corréler ; re-soumettre seulement les échecs.
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.
Sentiment ≠ complexité ; confiance auto-évaluée ≠ fiable. Escalade sur critères explicites ; demande humaine explicite = escalade immédiate.
Résumé progressif dilue les chiffres → bloc « case facts » persistant hors résumé.
Métriques agrégées mentent → stratifier par type de document et par champ ; confiance au niveau du champ.
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.