# Exercices — Niveau Avancé, Session 9 # « Scénarios de certification » **Programme :** Applied AI — Yann Isola **Public :** Architectes solutions — préparation *Claude Certified Architect* **Durée totale estimée :** 3 h à 4 h (travail individuel ou en binôme ; l'exercice 2 gagne beaucoup à être fait en binôme contradictoire) **Prérequis :** sessions 1 à 8 du niveau avancé. Aucune clé API n'est indispensable (exercices de conception sur papier/Markdown), mais une clé Anthropic permet de valider les points marqués *(optionnel : valider par le code)*. > ⚠ Tous les paramètres d'examen cités (60 questions, 90 minutes, seuil 72 %, pondérations des domaines) sont **volatils** : vérifier la page officielle de la certification avant l'examen. Les noms de modèles dans les exemples de code sont également volatils. --- ## Exercice 1 — Concevoir l'architecture complète du Scénario 1 : agent de support client (75-90 min) ### Contexte Vous êtes l'architecte d'un agent de support client pour un e-commerçant (500 000 commandes/an). L'agent, construit sur le **Claude Agent SDK** (SDK = Software Development Kit, kit de développement logiciel), doit gérer : retours produits, litiges de facturation, problèmes de compte. Il dispose des outils MCP (MCP = Model Context Protocol) : `get_customer`, `lookup_order`, `process_refund`, `escalate_to_human`. **Objectifs contractuels :** - Résolution au premier contact > 80 % - Zéro remboursement sans identité vérifiée (exigence de l'équipe fraude — **non négociable**) - Remboursements > 200 € : validation humaine obligatoire (politique interne) - Demande explicite d'un humain : transfert < 30 secondes C'est **exactement** le périmètre du Scénario 1 de l'examen. Votre production servira aussi de fiche de révision. ### Travail demandé Produisez un document d'architecture (`architecture-s1.md`) contenant les 6 sections suivantes. **1. Diagramme de flux (en texte ou Mermaid).** Le parcours d'une demande, de la réception à la résolution ou l'escalade. Faites apparaître explicitement : le point de vérification d'identité, le point de décision d'escalade, la boucle agentique (`stop_reason: "tool_use"` → exécution → renvoi des résultats). **2. Contrats d'outils.** Pour chacun des 4 outils, rédigez la **description complète** telle qu'elle sera fournie au modèle : rôle, format d'entrée avec exemples, ce que l'outil renvoie, quand l'utiliser **et quand ne pas l'utiliser** (différenciation explicite `get_customer` vs `lookup_order`), cas limites. Contrainte : un relecteur qui ne lit QUE les 4 descriptions doit pouvoir prédire quel outil l'agent choisira pour 5 demandes types que vous fournirez. **3. Garanties déterministes vs guidage probabiliste.** Classez chacune des 4 exigences contractuelles dans l'une des deux colonnes, et justifiez : | Exigence | Mécanisme (hook/précondition programmatique OU prompt/few-shot) | Justification | |---|---|---| | Zéro remboursement sans identité vérifiée | ? | ? | | Validation humaine > 200 € | ? | ? | | Résolution premier contact > 80 % | ? | ? | | Transfert < 30 s sur demande explicite | ? | ? | Puis écrivez le **pseudo-code du hook** `PreToolUse` qui bloque `process_refund` si (a) aucun `customer_id` vérifié n'existe dans la session, ou (b) le montant dépasse 200 € — avec dans ce cas redirection vers `escalate_to_human` accompagnée d'un motif structuré. *(optionnel : valider par le code — implémentez le hook réel dans le SDK.)* **4. Politique d'escalade.** Rédigez la section « escalade » du prompt système : critères explicites (au moins 4 déclencheurs), 3 exemples few-shot dont **1 cas où il ne faut PAS escalader** malgré un client mécontent, et le **format du résumé de transfert** (handoff) : ID client, motif, actions tentées, action recommandée. Interdiction d'utiliser l'analyse de sentiment ou la confiance auto-évaluée comme critère d'escalade — expliquez pourquoi en 3 lignes (c'est une question d'examen). **5. Gestion d'erreurs des outils.** Définissez le format de réponse d'erreur de vos outils MCP : `errorCategory` (transient / validation / business / permission), `isRetryable`, message lisible. Donnez un exemple JSON complet pour chaque catégorie, dont le cas piège : `lookup_order` qui ne trouve **aucune commande** (résultat vide valide — comment le distinguer d'un échec d'accès ?). **6. Auto-attaque.** Rédigez 3 questions de certification (situation + 4 options + réponse justifiée) qui piègent VOTRE architecture. Au moins une doit utiliser un distracteur de la famille « prompt magique » et une de la famille « sur-ingénierie ». ### Critères de réussite - [ ] Le diagramme montre la précondition d'identité **avant** tout remboursement, hors du chemin « prompt » - [ ] Les 4 descriptions d'outils permettent la prédiction du routage sur les 5 demandes types - [ ] Le tableau déterministe/probabiliste est correctement rempli (exigences fraude et 200 € → hooks ; taux de résolution et ton → prompt) - [ ] Le pseudo-code du hook gère les deux conditions et produit un motif structuré - [ ] La politique d'escalade contient le contre-exemple « mécontent ≠ escalade » - [ ] Les 4 catégories d'erreur sont illustrées, résultat vide ≠ échec d'accès - [ ] Les 3 questions d'auto-attaque respectent le format d'examen ### Piège à éviter Mettre la règle « zéro remboursement sans identité » dans le prompt système « parce qu'on a aussi le hook, ceinture et bretelles ». C'est acceptable en pratique — mais à l'examen, si la question demande « quel mécanisme **garantit** la règle », la seule réponse valable est le mécanisme programmatique. Le prompt ne garantit rien : il rend probable. --- ## Exercice 2 — Comparer trois approches pour le Scénario 3 : recherche multi-agents (60-75 min, binôme recommandé) ### Contexte Un cabinet d'analyse doit produire des rapports de veille sur des questions larges (« impact de la réglementation MiCA sur les émetteurs de stablecoins européens », « adoption de l'IA générative dans le secteur bancaire »). Chaque rapport exige : couverture complète du sujet, **citations pour chaque affirmation**, gestion des sources contradictoires, délai < 2 h. Trois architectures sont sur la table. Votre travail : les comparer **rigoureusement**, comme le ferait une question d'examen à tiroirs. **Approche A — Agent unique outillé.** Un seul agent avec recherche web, lecture de documents et rédaction. Pas de sous-agents. **Approche B — Pipeline fixe (chaînage de prompts).** Quatre étapes séquentielles codées en dur : (1) recherche web exhaustive → (2) analyse des documents collectés → (3) synthèse → (4) mise en forme du rapport. Chaque étape est un appel indépendant recevant la sortie de la précédente. **Approche C — Coordinateur + sous-agents dynamiques (hub-and-spoke).** Un coordinateur décompose le sujet, engendre des sous-agents de recherche parallèles (via `Task`), évalue la couverture, relance des sous-agents sur les lacunes, puis délègue la synthèse. ### Travail demandé **1. Grille de comparaison.** Remplissez (avec justification d'une phrase par cellule) : | Critère | A (agent unique) | B (pipeline fixe) | C (coordinateur dynamique) | |---|---|---|---| | Couverture des sujets larges | | | | | Risque de saturation de contexte | | | | | Latence (parallélisme possible ?) | | | | | Préservation de la provenance (affirmation → source) | | | | | Récupération après échec d'un composant | | | | | Coût en tokens | | | | | Observabilité / débogage | | | | | Complexité d'implémentation | | | | **2. Les trois pannes, trois diagnostics.** Pour chaque incident ci-dessous, indiquez quelle(s) approche(s) y est (sont) le plus vulnérable(s), la cause racine, et la correction — au format réponse d'examen (2-4 phrases) : - **Incident 1 :** le rapport sur « l'IA dans le secteur bancaire » ne couvre que les chatbots de service client, en ignorant la détection de fraude, le scoring de crédit et la conformité. - **Incident 2 :** au 60ᵉ appel d'outil, l'agent commence à se référer à des « pratiques typiques du secteur » au lieu des documents réellement collectés, et deux citations pointent vers des documents jamais ouverts. - **Incident 3 :** un timeout de la recherche web à l'étape 1 fait échouer tout le rapport, alors que 80 % des sources étaient déjà collectées. **3. La question du consensus.** Dans l'approche C, deux sous-agents renvoient des chiffres contradictoires (adoption IA : 40 % selon un rapport gouvernemental de 2025, 12 % selon une étude sectorielle de 2023). Rédigez la **règle de réconciliation** que vous donnez au coordinateur (5-8 lignes de prompt). Elle doit couvrir : conservation des deux valeurs, attribution, prise en compte des dates, et ce qui apparaît dans le rapport final. Puis expliquez en 3 lignes pourquoi « faire voter 3 sous-agents et prendre la majorité » est un faux consensus pour des **faits documentaires** (indice : le consensus vaut pour les jugements, pas pour les faits sourcés — 3 agents peuvent lire la même mauvaise source). **4. Verdict argumenté.** Recommandez une approche (ou un hybride) pour ce cabinet, en 10 lignes max, au format : recommandation → 3 arguments → 1 risque résiduel assumé → confiance (🟢/🟡/🔴). En binôme : l'un défend B, l'autre C, 10 minutes de contradictoire avant de rédiger le verdict commun. ### Critères de réussite - [ ] La grille est remplie avec des justifications, pas des impressions (« C parallélise via plusieurs `Task` dans un tour » et non « C est plus rapide ») - [ ] Incident 1 → décomposition trop étroite (C) ou prompt de recherche trop vague (A/B) — le diagnostic pointe le **donneur d'ordre**, pas les exécutants - [ ] Incident 2 → dégradation/saturation de contexte (surtout A) ; correction : sous-agents à contexte isolé + scratchpad + citations structurées obligatoires - [ ] Incident 3 → propagation d'erreurs (surtout B, pipeline sans récupération) ; correction : contexte d'erreur structuré + résultats partiels - [ ] La règle de réconciliation conserve les deux valeurs avec attribution et dates - [ ] Le verdict distingue faits sourcés (provenance) et jugements (consensus possible) ### Piège à éviter Conclure « C est toujours meilleur ». Le pipeline fixe B est la **bonne** réponse d'examen quand les étapes sont prévisibles et identiques d'une exécution à l'autre (revue multi-aspects standardisée). C se justifie quand la décomposition **dépend de ce qu'on découvre**. Une question d'examen peut parfaitement faire de B la réponse correcte. --- ## Exercice 3 — Grille d'évaluation pour le Scénario 6 : extraction de données structurées (60 min) ### Contexte Votre entreprise déploie un pipeline d'extraction sur 3 types de documents : **factures fournisseurs** (PDF natifs et scans), **contrats de prestation** (10-40 pages) et **bons de livraison** (semi-structurés, formats hétérogènes). Volume : 12 000 documents/mois. La direction demande : « à partir de quand peut-on automatiser sans revue humaine ? » Votre travail d'architecte : construire la **grille d'évaluation** qui répond à cette question — c'est-à-dire définir ce qu'on mesure, comment, avec quels seuils, et ce qui déclenche une revue humaine. C'est le cœur du Domaine 5 appliqué au Scénario 6. ### Travail demandé **1. Schéma d'extraction annoté.** Définissez le schéma JSON de l'extraction de **factures** (8-12 champs : fournisseur, numéro, dates, lignes, totaux HT/TVA/TTC, devise, IBAN — IBAN = International Bank Account Number). Pour chaque champ, annotez : - requis / optionnel / **nullable** (et pourquoi — rappel : un champ requis sur une info parfois absente force l'hallucination) ; - type de validation **syntaxique** (regex IBAN, format date) vs **sémantique** (Σ lignes = total HT ; HT + TVA = TTC) ; - criticité métier (une erreur d'IBAN ≠ une erreur de libellé). Incluez les champs d'auto-vérification `calculated_total` / `stated_total` et expliquez en 2 lignes leur rôle. **2. Jeu d'évaluation.** Spécifiez la composition d'un jeu de test de 150 documents étiquetés. Contraintes : - stratification par **type de document** (3 types) et par **difficulté** (natif propre / scan dégradé / cas limite) ; - au moins 15 **cas limites nommés** : facture multi-devises, avoir (montant négatif), TVA multiple, facture sans IBAN, document illisible, facture en anglais, doublon de numéro, total incohérent volontaire, champ « au verso » absent du scan, etc. — complétez la liste ; - pour chaque cas limite : le **comportement attendu** (extraire, extraire avec `null`, marquer `unclear`, rejeter en revue humaine). **3. Métriques et seuils.** Définissez la grille de décision : | Métrique | Définition précise | Seuil d'automatisation proposé | Justification | |---|---|---|---| | Précision par champ (par type de doc) | | | | | Rappel des champs critiques (IBAN, TTC) | | | | | Taux de `null` corrects vs hallucinations | | | | | Taux de réconciliation sémantique (totaux) | | | | | Taux de routage en revue humaine | | | | Règle imposée : **aucun seuil global unique**. Expliquez en 5 lignes pourquoi « 97 % de précision globale » est un critère piégeux (masquage des types de documents minoritaires et des champs faibles — c'est LA question d'examen du Domaine 5). **4. Politique de confiance et de routage.** Concevez le mécanisme : - scores de confiance **au niveau du champ** (comment les obtenir : auto-évaluation calibrée sur l'ensemble étiqueté — et pourquoi l'auto-évaluation brute non calibrée ne suffit pas) ; - 3 règles de routage en revue humaine (ex. : confiance champ critique < seuil ; échec de réconciliation sémantique ; type de document jamais vu) ; - la boucle de réessai avec feedback : quand elle s'applique (erreur de validation corrigeable) et quand elle est **inutile** (information absente de la source) — donnez un exemple de chaque ; - l'**échantillonnage stratifié continu** post-automatisation : quoi échantillonner, à quelle fréquence, pour détecter quoi (dérive des formats fournisseurs). **5. Restitution à la direction.** Rédigez la réponse à « à partir de quand automatise-t-on ? » en 10 lignes : critères d'entrée en automatisation par segment (type de doc × criticité de champ), part résiduelle en revue humaine assumée, et dispositif de surveillance. Format décision, pas format cours. ### Critères de réussite - [ ] Le schéma distingue nullable/requis avec justification anti-hallucination - [ ] Validation syntaxique et sémantique clairement séparées (le schéma garantit la syntaxe, jamais la sémantique) - [ ] Le jeu de test est stratifié et les 15 cas limites ont chacun un comportement attendu - [ ] Aucun seuil global unique ; métriques par type × champ - [ ] La politique de routage couvre confiance faible, échec sémantique et nouveauté - [ ] Le cas « réessai inutile » est correctement identifié (info absente ≠ extraction ratée) - [ ] La restitution est une décision segmentée, pas un oui/non global ### Piège à éviter Proposer « on réessaie 3 fois puis on escalade » comme politique universelle. Le réessai avec feedback d'erreur corrige les extractions **mal faites** ; il ne fera jamais apparaître une information **absente du document**. Une question d'examen typique vous tend ce piège avec une mention du type « la date d'échéance figure uniquement dans les conditions générales, document séparé ». --- ## Livraison Déposez `architecture-s1.md`, `comparaison-s3.md` et `evaluation-s6.md` dans le dossier partagé de la session. Correction croisée en ouverture de la session 10 : chaque binôme relit la production d'un autre binôme avec la grille de critères ci-dessus, au format revue de certification (ce qui est signalé, ce qui est ignoré, gravité).