--- 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 ```bash # 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.