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

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

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

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.

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

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.

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

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 ?

Slide 9 — Correspondance scénarios × domaines

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

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

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":…})

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.

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

Slide 15 — Scénario 3 : trois pannes classiques

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

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

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

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.

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)

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

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

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)

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

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

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

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

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 ? »

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

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

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.