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