title: "Scénarios de certification"
subtitle: "Applied AI — Niveau Avancé · Session 9"
author: "Yann Isola"
theme: "ink #1A2230 / teal #0F7A6C / copper #B4612A / light-teal #E9F6F3 / bg #F4F7F6"

Slide 1 — Titre

Scénarios de certification

Applied AI — Niveau Avancé · Session 9
Yann Isola · Préparation Claude Certified Architect

Notes : Rien de nouveau aujourd'hui — tout assembler sous l'angle exact de l'examen. Penser comme l'auteur des questions.

Slide 2 — Objectifs de la session

  • Maîtriser le format d'examen et la stratégie de temps
  • Cartographier les 5 domaines et leurs pondérations
  • Analyser les 8 scénarios : décisions attendues, pièges récurrents
  • Appliquer la grille de lecture des QCM (QCM = Questionnaire à Choix Multiples)
  • S'auto-évaluer et prioriser la révision par poids de domaine
  • S'entraîner en conditions chronométrées

Notes : Session de synthèse et d'entraînement. Insister : l'examen évalue le jugement d'architecte, pas la récitation.

Slide 3 — Le format, noir sur blanc ⚠

Paramètre Valeur ⚠
Questions 60
Durée 90 min (~90 s/question)
Type QCM 1/4 + questions basées sur scénarios
Seuil 720 / échelle 100–1000 (≈ 72 %)
Pénalité pour erreur Aucune
Scénarios 4 tirés parmi 8

Notes : ⚠ = chiffres volatils, vérifier la page officielle Anthropic avant de réserver. Trois conséquences au slide suivant.

Slide 4 — Trois conséquences pratiques

  1. Aucune pénalité → jamais de question vide (25 % d'espérance même au hasard)
  2. 4 scénarios sur 8, tirage aléatoire → aucune impasse possible
  3. Seuil ≈ 72 % → droit à ~16 erreurs sur 60

67 % de l'examen = Domaines 1 + 3 + 4. Solides là-dessus = marge confortable.

Notes : Dédramatiser le seuil, dramatiser l'impasse. Le tirage aléatoire des scénarios est l'argument massue contre la révision sélective.

Slide 5 — Les 5 domaines et leur poids

Domaine Poids ≈ Q/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

Notes : D1 pèse presque le double de D5 — une heure de révision D1 « rapporte » plus. Mais les domaines s'entrecroisent dans les scénarios.

Slide 6 — Anatomie d'une question d'examen

  1. Situation — système en production, symptôme chiffré (« dans 12 % des cas… »)
  2. Question — « quel changement est le plus efficace ? » / « quelle est la première étape ? »
  3. 4 options — 1 correcte, 3 distracteurs construits selon des recettes

Les mots « le plus », « d'abord », « au moindre effort » ⇒ plusieurs options techniquement valables — on départage au rapport coût/impact.

Notes : Lire la question AVANT la situation pour savoir quoi chercher. Les chiffres de la situation pointent la cause racine.

Slide 7 — Les 4 familles de distracteurs

Famille Signature
🪄 Prompt magique Résoudre par prompt ce qui exige une garantie déterministe
🏗️ Sur-ingénierie Classificateur ML / couche de routage pour un problème simple
👻 Fonctionnalité inventée CLAUDE_HEADLESS=true, --batch, .claude/config.json
🎭 Symptôme, pas la cause Correction plausible… d'un autre problème

Notes : Faire remplir le tableau par la salle avec les exemples des sessions précédentes. Chacun a un biais dominant — le quiz de fin le révélera.

Slide 8 — La grille de lecture en 3 questions

  1. Quelle est la cause racine ? (relire les chiffres de la situation)
  2. Garantie déterministe exigée, ou probabiliste acceptable ?
    → déterministe : hooks / préconditions · probabiliste : prompt / few-shot
  3. Parmi les options qui traitent la cause : meilleur rapport effort/impact ?

Notes : Dérouler en démo sur la question canonique des préconditions de remboursement. La réponse sort en 30 s avec la grille.

Slide 9 — Correspondance scénarios × domaines

Scénario Dominante
S1 Support client D1 · D2 · D5
S2 Génération de code D3
S3 Recherche multi-agents D1 · D5
S4 Productivité dev D2 · D3
S5 Claude Code CI/CD D3 · D4
S6 Extraction structurée D4 · D5
S7 IA conversationnelle D5 · D1
S8 Outils agentiques D2 · D1

Notes : D1 et D3 sont partout. D2 se joue sur S1/S4/S8, D4 sur S5/S6, D5 culmine sur S7.

Slide 10 — Scénario 1 : agent de support client

Agent SDK + outils MCP : get_customer, lookup_order, process_refund, escalate_to_human
Objectif : résolution premier contact > 80 %, escalade appropriée

Décisions attendues :

  • Identité avant remboursement → précondition programmatique
  • Mauvais routage d'outils → enrichir les descriptions d'abord
  • Escalade mal calibrée → critères explicites + few-shot

Notes : MCP = Model Context Protocol. SDK = Software Development Kit. Trois pannes, trois réflexes — chacune est une question type.

Slide 11 — Scénario 1 : les pièges

  • 😡 Sentiment ≠ complexité — le sentiment module le ton, jamais la décision d'escalade
  • 🎲 Confiance auto-évaluée ≠ fiable — le modèle se trompe avec assurance
  • 👥 Plusieurs correspondances client → demander des identifiants, jamais deviner
  • 🙋 Demande explicite d'humain → escalade immédiate, sans investigation
  • 📋 Handoff = résumé structuré (ID, motif, tenté, recommandé), pas la conversation brute

Notes : L'analyse de sentiment est quasi systématiquement un distracteur sur ce scénario.

Slide 12 — Scénario 8 : outils d'IA agentique

Sélection · chaînage · récupération d'erreurs (recombinaison de D1 + D2)

  • Trop d'outils (18 vs 4-5) réduit la fiabilité de sélection → périmètre par rôle
  • Descriptions qui se chevauchent → réécrire/renommer (analyze_content → extract_web_results)
  • tool_choice : "auto" (texte possible) · "any" (outil obligatoire) · forcé ({"type":"tool","name":…})

Notes : Scénario moins documenté ⚠ mais entièrement couvert par D1/D2. « any » = sortie structurée garantie quand plusieurs schémas existent.

Slide 13 — Taxonomie des erreurs d'outil

Catégorie Exemple Réessayable ?
Transitoire timeout ✅
Validation mauvais format d'entrée ✅ après correction
Métier plafond de politique dépassé ❌ + explication
Permission accès refusé ❌ → escalade

Piège d'or : échec d'accès ≠ résultat vide valide. Masquer un échec en succès = anti-modèle certain.

Notes : errorCategory + isRetryable + message lisible. « Operation failed » générique empêche toute récupération intelligente.

Slide 14 — Scénario 3 : recherche multi-agents

Hub-and-spoke (architecture en étoile) — les invariants :

  1. Le coordinateur possède toute la communication (observabilité)
  2. Sous-agents = contexte isolé — rien n'est hérité, tout se passe dans le prompt
  3. Parallélisme = plusieurs Task dans un tour du coordinateur
  4. Prompts du coordinateur en objectifs + critères, pas en pas-à-pas

Notes : L'invariant n°2 est le plus testé de tout le Domaine 1. « En t'appuyant sur la phase 1 » ne transmet RIEN au sous-agent.

Slide 15 — Scénario 3 : trois pannes classiques

Symptôme Cause racine
Rapport à couverture partielle Décomposition trop étroite du coordinateur
Timeout → workflow entier échoue Propagation d'erreurs mal conçue → erreur structurée + résultats partiels
Latence +40 % en allers-retours → outil verify_fact limité à la synthèse (moindre privilège gradué)

Notes : Panne 1 : sous-agents corrects + couverture partielle = suspecter le donneur d'ordre. Panne 3 : 85 % de vérifications simples → outil local ; 15 % complexes → via coordinateur.

Slide 16 — Consensus et contradictions

Deux sources crédibles : 40 % (rapport gouv.) vs 12 % (étude sectorielle)

❌ Choisir heuristiquement · ❌ Bloquer tout · ❌ Transmettre sans marquage
✅ Conserver les deux + annoter le conflit + attribution + dates → le coordinateur réconcilie

Provenance : exiger des sous-agents les correspondances « affirmation → source » (URL, document, citation, date) — sinon l'attribution meurt au résumé.

Notes : Souvent la « contradiction » est une différence temporelle (2023 vs 2025). Le consensus par vote vaut pour les jugements, pas les faits sourcés.

Slide 17 — Scénario 7 : IA conversationnelle

Rappel n°1 (le plus testé) : l'API est sans état (stateless).
Pas de session côté serveur — l'historique est votre responsabilité applicative.

Stratégie mémoire Risque
Historique complet saturation + coût
Fenêtre glissante perte des engagements anciens
Résumé progressif dilution des chiffres, dates, montants
Hybride + « case facts » ✅ complexité assumée

Notes : Sessions avec état = SDK/Claude Code (--resume, fork_session), pas l'API Messages de base.

Slide 18 — Le patron « case facts »

Réponse-réflexe du Scénario 7 :

  • Faits transactionnels (montants, numéros, dates, engagements) → bloc persistant jamais résumé, injecté à chaque tour
  • Le résumé progressif ne s'applique qu'au reste
  • Effet « perdu au milieu » : réinjecter les contraintes critiques près de la fin du contexte
  • Structurer en XML (XML = eXtensible Markup Language) : système / données / instructions

Notes : Question type : « au 60ᵉ tour l'assistant se trompe sur la franchise annoncée au 5ᵉ tour » → case facts, pas « résumer moins fort ».

Slide 19 — Scénario 2 : configuration Claude Code

Mécanisme Emplacement Partagé (VCS) ?
CLAUDE.md utilisateur ~/.claude/CLAUDE.md ❌
CLAUDE.md projet racine / .claude/ ✅
CLAUDE.md répertoire sous-arbre ✅
Règles ciblées .claude/rules/ + paths: glob ✅ chargement conditionnel

Diagnostic type : « le nouveau n'a pas les conventions » → niveau utilisateur au lieu de projet.

Notes : VCS = Version Control System. Modularisation : syntaxe @path pour inclure des fichiers, rules thématiques vs CLAUDE.md monolithique.

Slide 20 — Commandes slash, Skills, mode plan

  • .claude/commands/ = équipe (versionné) · ~/.claude/commands/ = personnel
  • Skills : SKILL.md — context: fork (isolation), allowed-tools, argument-hint
  • Mode plan : gros changement + approches multiples + décisions architecturales
  • Exécution directe : correction simple, trace de pile claire, un fichier
  • ❌ Distracteur : « commencer direct, planifier quand ça coince » (réactif = reprise déjà payée)

Notes : Le sous-agent Explore isole la sortie verbeuse de découverte — protection du contexte pendant les tâches multi-phases.

Slide 21 — Scénario 4 : outils intégrés

Outil Usage
Grep chercher dans le contenu
Glob trouver des fichiers par nom/motif
Read/Write fichier entier
Edit modification par correspondance unique (sinon → Read+Write)

Exploration d'une base inconnue : Grep les points d'entrée → Read pour tracer → incrémental

Notes : Grep vs Glob = question quasi garantie. MCP : .mcp.json projet + ${TOKEN} en variable d'env, jamais de secret versionné.

Slide 22 — Scénario 5 : Claude Code en CI/CD

# Bloqué en CI ? Il manque -p :
claude -p "Analyse cette PR pour la sécurité" \
  --output-format json --json-schema review.json
  • -p / --print = headless documenté ⚠
  • 👻 Inventés : CLAUDE_HEADLESS=true, --batch
  • CLAUDE.md = contexte projet pour la CI (normes, fixtures, critères)

Notes : CI/CD = Continuous Integration/Continuous Deployment. PR = Pull Request. La sortie JSON schématisée alimente les commentaires inline de PR.

Slide 23 — Revue de PR : architecture

  1. Instance indépendante — la session qui a généré le code se relit mal
  2. Faux positifs : critères catégoriels explicites (signaler/ignorer) ≫ « sois conservateur »
  3. Catégorie bruyante → désactiver temporairement (elle sape la confiance des catégories fiables)
  4. Grande PR : passes par fichier + passe d'intégration — une fenêtre plus grande ne répare pas l'attention
  5. Re-run après commits : inclure la revue antérieure → ne signaler que le nouveau

Notes : Point 4 : distracteur récurrent « prendre un modèle à plus grande fenêtre » — c'est la dilution d'attention, pas la capacité, qui est en cause.

Slide 24 — Batch vs temps réel

Charge API
Vérification bloquante avant fusion Synchrone
Rapport de nuit, audit hebdomadaire Batches (−50 % ⚠, ≤ 24 h ⚠, pas de SLA)
  • custom_id pour corréler requêtes/réponses
  • Échec partiel → re-soumettre uniquement les échecs
  • Pas d'appels d'outils multi-tours dans une requête batch ⚠

Notes : SLA = Service Level Agreement. Question type : un manager veut tout passer en batch pour économiser 50 % → séparer bloquant/non bloquant.

Slide 25 — Scénario 6 : la pile d'extraction fiable

  1. tool_use + schéma JSON = syntaxe garantie
  2. ⚠ La sémantique ne l'est jamais : mauvais champ, totaux incohérents
  3. Champs nullable quand l'info peut être absente (requis = hallucination forcée)
  4. Enums avec "other" / "unclear" + champ de détail
  5. Auto-vérification : calculated_total vs stated_total
  6. Réessai avec feedback d'erreurs précises — inutile si l'info est absente de la source

Notes : JSON = JavaScript Object Notation. Les points 2, 3 et 6 sont chacun une question d'examen à part entière.

Slide 26 — Scénario 6 : calibrage & supervision humaine

« 97 % de précision globale » peut cacher 64 % sur le champ IBAN des scans.

  • Précision par type de document × par champ avant d'automatiser
  • Confiance au niveau du champ, calibrée sur un ensemble étiqueté
  • Routage en revue humaine : confiance faible, échec sémantique, source ambiguë
  • Échantillonnage aléatoire stratifié continu après automatisation

Notes : IBAN = International Bank Account Number. Séquence attendue : échantillon → itération → validation stratifiée → seuils calibrés → automatisation segmentée + surveillance.

Slide 27 — Stratégie de temps le jour J

  1. Passage 1 : répondre à tout ce qui sort en < 60 s, marquer le reste
  2. Passage 2 : les questions marquées
  3. Dernière minute : zéro question vide (pas de pénalité)
  4. Questions à scénario : lire la question avant la situation
  5. Après chaque erreur en entraînement : « quelle famille de distracteur m'a eu ? »

Notes : 90 s/question en moyenne, mais la distribution est inégale : les questions de configuration se règlent en 30 s, les scénarios multi-agents en 2-3 min.

Slide 28 — Simulateur d'examen (20 min)

Page web de la session → onglet « Simulateur »

  • 12 questions · 18 minutes · conditions réelles, sans documentation
  • Score individuel + correction collective des 3 questions les plus ratées
  • Objectif : identifier votre biais de distracteur dominant

Notes : Relever les scores à main levée pour la correction collective. La méthode compte plus que le score du jour.

Slide 29 — Plan de révision priorisé

Page web → onglet « Tracker de domaines » : auto-évaluation 🟢/🟡/🔴 par compétence, score pondéré par les poids d'examen

Règle de priorisation :

  1. Les 🔴 des domaines lourds (D1 27 % · D3 20 % · D4 20 %)
  2. Puis les 🟡
  3. Un 🔴 en D1 ≈ 4 questions perdues · en D5 ≈ 1,5

Notes : Chaque participant repart avec son plan. Vérifier la logistique d'examen sur la page officielle ⚠ (inscription, surveillance, repassage).

Slide 30 — Récapitulatif : les 8 réflexes

  1. Règle métier critique → hook, jamais le prompt seul
  2. Mauvais routage → descriptions d'outils d'abord
  3. Sous-agent = contexte isolé, tout passe dans le prompt
  4. Couverture partielle → suspecter la décomposition du coordinateur
  5. -p en CI · projet = versionné, utilisateur = personnel
  6. Schéma JSON = syntaxe, jamais la sémantique · nullable anti-hallucination
  7. Chiffres qui se diluent → bloc « case facts » persistant
  8. Métrique globale → stratifier type × champ avant d'automatiser

Exercices : architecture S1 · comparaison S3 · grille d'évaluation S6. Session 10 : examen blanc complet.

Notes : Clôture. Exit ticket : scénario le plus faible + créneau de révision planifié. Tous les chiffres ⚠ à re-vérifier avant l'examen réel.