# Quiz — Niveau Avancé, Session 9 # « Scénarios de certification » **Programme :** Applied AI — Yann Isola **Format :** 15 QCM (QCM = Questionnaire à Choix Multiples) au format exact de l'examen *Claude Certified Architect* — situation, question, 4 options, 1 seule bonne réponse **Durée :** 22 minutes (rythme d'examen : ~90 s/question) **Seuil :** 11/15 (≈ 72 %, aligné sur le seuil de certification ⚠) **Répartition par domaine (proportionnelle aux pondérations d'examen) :** D1 Architecture & orchestration ×4 · D2 Outils & MCP ×3 · D3 Claude Code ×3 · D4 Prompts & sortie structurée ×3 · D5 Contexte & fiabilité ×2 > ⚠ Les comportements d'API, drapeaux CLI, chemins de configuration et paramètres de la Batch API décrits reflètent la documentation au moment de la rédaction et sont **volatils** : vérifier la documentation officielle Anthropic. --- ## Domaine 1 — Architecture & orchestration d'agents (4 questions) ### Q1 — Arrêt de la boucle agentique (Scénario 8) **Situation :** Un agent autonome de traitement de dossiers boucle : appel API → exécution des outils demandés → renvoi des résultats. Le développeur a implémenté la condition d'arrêt ainsi : la boucle se termine quand le texte de l'assistant contient « tâche terminée », avec un garde-fou de 10 itérations maximum comme mécanisme d'arrêt principal. **Quel est le problème principal de cette conception ?** - A. Le garde-fou de 10 itérations est trop bas ; il faudrait 50 itérations - B. La condition d'arrêt doit s'appuyer sur `stop_reason` (`"end_turn"` vs `"tool_use"`), pas sur l'analyse du texte ni sur une limite d'itérations arbitraire comme mécanisme principal - C. Il faudrait analyser le texte avec une regex plus robuste que la recherche de sous-chaîne - D. La boucle devrait se terminer dès le premier appel d'outil réussi **Réponse : B.** Le contrat de la boucle agentique est piloté par `stop_reason` : `"tool_use"` → exécuter et continuer ; `"end_turn"` → le modèle a terminé. Analyser le texte de l'assistant pour détecter l'achèvement et utiliser une limite d'itérations comme mécanisme d'arrêt **principal** sont les deux anti-modèles canoniques (la limite reste utile en garde-fou secondaire). A et C raffinent l'anti-modèle au lieu de le corriger ; D casse la boucle. --- ### Q2 — Couverture partielle d'un rapport multi-agents (Scénario 3) **Situation :** Un système coordinateur + sous-agents recherche « l'impact de l'IA sur le secteur de la santé ». Le rapport final ne couvre que l'imagerie médicale et l'aide au diagnostic. Les journaux montrent que le coordinateur a créé trois sous-tâches : « IA en radiologie », « IA en analyse d'images pathologiques », « IA et diagnostic assisté ». Chaque sous-agent a produit un travail complet et correctement sourcé sur sa sous-tâche. **Quelle est la cause racine ?** - A. Les sous-agents de recherche n'ont pas cherché assez largement dans leurs domaines - B. L'agent de synthèse n'a pas détecté les lacunes de couverture avant la rédaction - C. Le coordinateur a décomposé le sujet de manière trop étroite : toutes les sous-tâches relèvent du diagnostic, en ignorant administration, recherche clinique, télémédecine - D. La fenêtre de contexte du coordinateur a été saturée par les résultats des sous-agents **Réponse : C.** Les journaux montrent des sous-agents qui ont exécuté **correctement** ce qui leur était demandé — le problème est en amont : la décomposition. « Santé » a été réduit au seul diagnostic. B est un filet de sécurité souhaitable mais pas la cause ; A contredit les journaux ; D n'est pas étayé par la situation. Réflexe d'examen : couverture partielle + sous-agents corrects = suspecter le **donneur d'ordre**. --- ### Q3 — Passage de contexte aux sous-agents (Scénario 3) **Situation :** Dans un pipeline de recherche, le coordinateur a mené une phase 1 d'analyse qui a produit des conclusions clés. Il engendre ensuite un sous-agent de rédaction via l'outil `Task` avec le prompt : « Rédige le rapport final en t'appuyant sur les conclusions de la phase 1 ». Le sous-agent produit un rapport générique sans lien avec les conclusions. **Pourquoi ?** - A. L'outil `Task` a un bug connu de transmission de contexte qu'il faut contourner avec `fork_session` - B. Les sous-agents opèrent avec un contexte isolé : ils n'héritent pas de l'historique du coordinateur ; les conclusions de la phase 1 devaient être incluses explicitement dans le prompt du sous-agent - C. Le sous-agent n'avait pas l'outil de recherche web dans ses `allowedTools` - D. Le prompt du sous-agent était trop long et a été tronqué **Réponse : B.** C'est l'invariant le plus testé du Domaine 1 : l'isolation de contexte des sous-agents. « En t'appuyant sur les conclusions de la phase 1 » ne transmet rien — le sous-agent n'a jamais vu ces conclusions. La correction : inclure les sorties complètes (ou un résumé structuré) des phases précédentes dans le prompt, idéalement avec un format structuré séparant données et instructions. A invente un bug ; C et D ne correspondent pas au symptôme (rapport générique = manque de matière, pas d'outil ni de troncature). --- ### Q4 — Ordre d'exécution garanti (Scénario 1) **Situation :** Un agent de support bancaire doit impérativement vérifier l'identité (`get_customer`) avant toute opération financière (`process_refund`). L'audit montre que dans 7 % des cas, l'agent traite le remboursement sans vérification préalable, malgré une instruction en majuscules dans le prompt système : « TOUJOURS VÉRIFIER L'IDENTITÉ D'ABORD ». **Quelle correction apporte une garantie ?** - A. Répéter l'instruction au début ET à la fin du prompt système pour contrer l'effet « perdu au milieu » - B. Ajouter 4 exemples few-shot montrant la séquence correcte - C. Implémenter un hook/une précondition programmatique qui bloque `process_refund` tant qu'aucun ID client vérifié n'est présent dans l'état de la session - D. Passer à un modèle plus capable qui suit mieux les instructions **Réponse : C.** Le mot-clé de la question est « **garantie** ». Le prompt (A, B) et le choix de modèle (D) améliorent la **probabilité** de conformité — ils peuvent faire passer 7 % à 1 %, jamais à 0 %. Une règle métier critique (opérations financières) exige une application **déterministe** : le logiciel bloque l'appel, quel que soit ce que le modèle « décide ». C'est la distinction structurante de tout l'examen : garanties déterministes (hooks, préconditions) vs conformité probabiliste (prompts). --- ## Domaine 2 — Conception d'outils & intégration MCP (3 questions) ### Q5 — Mauvais routage entre outils similaires (Scénario 1) **Situation :** Un agent dispose de `get_customer` (« Gets customer info ») et `lookup_order` (« Looks up orders »). Pour les questions sur les commandes, il appelle `get_customer` dans 30 % des cas. L'équipe hésite entre quatre corrections. **Laquelle appliquer en premier ?** - A. Ajouter une couche de classification en amont qui route la demande vers le bon outil - B. Fusionner les deux outils en un seul outil `customer_and_orders` avec un paramètre de mode - C. Enrichir chaque description : formats d'entrée avec exemples, ce que l'outil renvoie, quand l'utiliser et quand utiliser l'autre, cas limites - D. Ajouter des exemples few-shot de sélection d'outil dans le prompt système **Réponse : C.** Les descriptions d'outils sont le **mécanisme principal** de sélection du modèle ; ici elles sont minimales et quasi identiques — c'est la cause racine. L'enrichir est la correction au moindre effort et au plus fort impact. D peut aider **ensuite** (les few-shot coûtent des tokens et ne corrigent pas des descriptions vides) ; A est de la sur-ingénierie qui ajoute un composant à maintenir ; B dégrade la conception (outil fourre-tout avec contrat flou). --- ### Q6 — Taxonomie des erreurs d'outil (Scénario 8) **Situation :** L'outil MCP `process_refund` échoue de trois façons : (1) timeout de la passerelle de paiement, (2) montant dépassant le plafond autorisé par la politique interne, (3) format d'ID de transaction invalide. Actuellement, les trois renvoient `{"isError": true, "message": "Operation failed"}`. L'agent réessaie systématiquement les trois cas en boucle. **Quelle refonte des réponses d'erreur est correcte ?** - A. (1) `transient`/`isRetryable: true` ; (2) `business`/`retryable: false` + explication de la politique à transmettre à l'utilisateur ; (3) `validation`/réessayable après correction, avec le format attendu dans le message - B. Renvoyer le même message pour les trois mais ajouter un code numérique HTTP que l'agent apprendra à interpréter - C. (1), (2) et (3) : `isRetryable: true` avec backoff exponentiel — le réessai finit toujours par aboutir ou par épuiser le budget - D. Supprimer `isError` et renvoyer un résultat vide : l'agent conclura de lui-même à l'échec **Réponse : A.** La taxonomie transient / business / validation (+ permission) avec `isRetryable` explicite est ce qui permet à l'agent de **décider intelligemment** : réessayer le timeout, ne jamais réessayer une violation de politique (elle échouera toujours — il faut informer ou escalader), corriger l'entrée puis réessayer la validation. B laisse l'interprétation au hasard ; C fait boucler l'agent sur des erreurs non réessayables — exactement le symptôme constaté ; D masque l'échec, pire anti-modèle : un résultat vide « valide » et un échec doivent être **distinguables**. --- ### Q7 — Partage d'un serveur MCP en équipe (Scénario 4) **Situation :** Une équipe de 12 développeurs veut que le serveur MCP interne « catalogue-produits » soit disponible pour tous dès le clone du dépôt, avec authentification par token individuel. Un développeur propose d'ajouter le serveur avec son token dans `~/.claude.json` et de partager ce fichier sur le wiki. **Quelle est la bonne configuration ?** - A. Chaque développeur ajoute manuellement le serveur dans `~/.claude.json` avec son token en clair - B. Déclarer le serveur dans le fichier `.mcp.json` du projet (versionné), avec le token référencé par variable d'environnement (`${CATALOG_TOKEN}`) que chaque développeur définit localement - C. Déclarer le serveur dans le CLAUDE.md racine avec le token, puisque CLAUDE.md est versionné - D. Déclarer le serveur dans `.mcp.json` avec un token d'équipe partagé en clair dans le fichier **Réponse : B.** Deux règles se combinent : portée **projet** = `.mcp.json` versionné (disponible au clone pour toute l'équipe, contrairement à `~/.claude.json` qui est individuel et non partagé) ; **secrets** = substitution de variables d'environnement, jamais de token en clair dans un fichier versionné. A ne satisfait pas « disponible au clone » et duplique l'effort ; C confond instructions (CLAUDE.md) et configuration de serveurs ; D versionne un secret — faute de sécurité éliminatoire. --- ## Domaine 3 — Configuration & workflows de Claude Code (3 questions) ### Q8 — Conventions par type de fichier (Scénario 2) **Situation :** Un monorepo contient des conventions de test strictes qui s'appliquent à tous les fichiers `**/*.test.ts`, lesquels sont co-localisés avec le code source dans des dizaines de répertoires. Les développeurs veulent que Claude Code charge ces conventions **uniquement** quand il édite des fichiers de test, pour économiser le contexte. **Quelle configuration choisir ?** - A. Tout mettre dans le CLAUDE.md racine : c'est le seul fichier toujours chargé - B. Un CLAUDE.md dans chaque répertoire contenant des tests - C. Un fichier `.claude/rules/testing.md` avec un frontmatter YAML `paths: ["**/*.test.ts"]` - D. Un skill `.claude/skills/testing/` que les développeurs invoquent avant d'écrire des tests **Réponse : C.** Les règles à portée de chemin (`.claude/rules/` + motifs glob) se chargent **uniquement** lors de l'édition de fichiers correspondants — exactement le besoin (conditionnel + économie de contexte). A charge les conventions en permanence, tout le contraire ; B est inmaintenable quand les tests sont co-localisés dans des dizaines de répertoires (et c'est le critère de bascule : conventions par **type de fichier** dispersé → glob ; conventions par **sous-arbre** → CLAUDE.md de répertoire) ; D est manuel et à la demande — la situation exige de l'automatique. --- ### Q9 — Claude Code bloqué en CI (Scénario 5) **Situation :** Un job GitLab CI exécute `claude "Génère les tests manquants pour ce module"` et reste suspendu jusqu'au timeout du runner. Le même prompt fonctionne parfaitement sur le poste du développeur. **Quelle est la correction documentée ?** - A. Définir la variable d'environnement `CLAUDE_HEADLESS=true` dans le job - B. Utiliser `claude -p "Génère les tests manquants pour ce module"` (mode non interactif : traite le prompt, écrit sur stdout, quitte) - C. Utiliser le drapeau `--batch` pour l'exécution sans terminal - D. Rediriger l'entrée standard : `claude "..." < /dev/null` **Réponse : B.** `-p` (ou `--print`) est le mode headless documenté de Claude Code ⚠ : non interactif, adapté aux pipelines, combinable avec `--output-format json` et `--json-schema` pour une sortie structurée exploitable par le job. A et C sont des **fonctionnalités inventées** — la famille de distracteurs la plus fréquente sur ce scénario ; D est un contournement Unix qui ne correspond pas au mode d'exécution documenté. --- ### Q10 — Restructuration architecturale (Scénario 2) **Situation :** Vous confiez à Claude Code l'extraction d'un service de facturation hors d'un monolithe : ~45 fichiers touchés, plusieurs découpages possibles, des choix de frontières de service à arbitrer. Un collègue suggère : « lance-le en exécution directe avec des instructions très détaillées, tu passeras en mode plan si ça se passe mal ». **Quelle approche recommander ?** - A. Suivre la suggestion : l'exécution directe avec instructions détaillées est plus rapide, le mode plan en secours - B. Mode planification d'emblée : exploration de la base de code et des dépendances, conception de l'approche et des frontières de service, validation du plan, puis exécution - C. Exécution directe incrémentale, un fichier à la fois, pour limiter les dégâts - D. Découper soi-même le travail en 45 prompts indépendants, un par fichier **Réponse : B.** Les trois marqueurs du mode plan sont réunis : changement important (45 fichiers), **plusieurs approches viables**, **décisions architecturales** (frontières de service). Le mode plan permet l'exploration sûre avant toute modification. A est le distracteur classique « réactif » : quand « ça se passe mal », la reprise est déjà coûteuse ; C évite les catastrophes locales mais ne résout pas le problème central (les frontières de service sont une décision **globale**) ; D détruit la cohérence inter-fichiers de l'extraction. --- ## Domaine 4 — Prompt engineering & sortie structurée (3 questions) ### Q11 — Schéma strict, erreurs persistantes (Scénario 6) **Situation :** Un pipeline d'extraction de factures utilise `tool_use` avec un schéma JSON strict et `tool_choice` forcé. Le JSON produit est toujours syntaxiquement valide et conforme au schéma. Pourtant, 4 % des extractions contiennent des erreurs : montant HT placé dans le champ TTC, somme des lignes différente du total extrait. **Quelle analyse est correcte ?** - A. Le schéma est mal écrit : un schéma JSON correctement contraint (types, formats, bornes) élimine aussi ces erreurs - B. Le schéma garantit la syntaxe et la forme, pas la sémantique ; ajouter une validation programmatique de réconciliation (Σ lignes = total, HT + TVA = TTC) et une boucle de réessai avec les erreurs de validation précises en feedback - C. Remplacer `tool_use` par une consigne « réponds en JSON valide » avec un exemple, plus flexible pour les cas limites - D. Augmenter la température pour que le modèle explore d'autres lectures du document **Réponse : B.** C'est LA distinction du Domaine 4 : les schémas JSON stricts éliminent les erreurs de **syntaxe**, pas les erreurs **sémantiques** (mauvais champ, totaux non réconciliés). La parade est programmatique : validations de cohérence + réessai avec feedback d'erreur concret (document + extraction fautive + erreurs précises). A est faux — aucune contrainte de type n'empêche de mettre le bon nombre dans le mauvais champ ; C régresse (réintroduit les erreurs de syntaxe que `tool_use` éliminait) ; D augmente la variabilité, aggravant le problème. --- ### Q12 — Champs manquants et hallucination (Scénario 6) **Situation :** Le schéma d'extraction de contrats impose `date_resiliation` en champ **requis** de type chaîne. Sur les contrats à durée indéterminée — qui n'ont pas de date de résiliation — le modèle produit des dates plausibles mais inventées. L'équipe ajoute au prompt : « n'invente jamais de date », sans amélioration notable. **Quelle correction de fond ?** - A. Rendre le champ nullable/optionnel afin que l'absence d'information ait une représentation légitime dans le schéma, et documenter dans la description du champ quand renvoyer `null` - B. Renforcer l'instruction : « INTERDICTION ABSOLUE d'inventer des dates » en tête de prompt - C. Ajouter une étape de réessai : si la date extraite semble suspecte, redemander l'extraction - D. Post-traiter : supprimer les dates dont le format est improbable **Réponse : A.** Un champ **requis** sur une information parfois absente **force structurellement** le modèle à produire quelque chose — l'instruction contraire crée une injonction contradictoire que le schéma gagne. La correction est dans la conception du schéma : nullable/optionnel donne à « l'information n'existe pas » une sortie légitime. Même famille : enums avec `"other"`/`"unclear"` + champ de détail. B a déjà montré son inefficacité (le schéma prime) ; C réessaie sans changer la contrainte qui cause l'invention ; D ne détecte pas les dates inventées **plausibles** — c'est précisément le problème. --- ### Q13 — Faux positifs en revue de code automatisée (Scénario 5) **Situation :** Une revue de PR automatisée signale trop de faux positifs, concentrés sur les remarques de style et de nommage, ce qui fait que les développeurs ignorent aussi les alertes de sécurité — pourtant fiables. Le prompt actuel demande : « fais une revue approfondie et sois rigoureux ». **Quelle refonte du prompt est la plus efficace ?** - A. Ajouter « sois plus conservateur dans tes signalements et évite les faux positifs » - B. Définir des critères catégoriels explicites — signaler : bugs, vulnérabilités, erreurs de logique ; ignorer : style, nommage, préférences — avec un exemple par catégorie et des niveaux de gravité illustrés ; désactiver temporairement les catégories les plus bruyantes - C. Exécuter la revue trois fois et ne garder que les problèmes signalés au moins deux fois - D. Baisser la température à 0 pour des revues plus déterministes **Réponse : B.** Deux connaissances d'examen se combinent : (1) les **critères explicites et catégoriels** surpassent le guidage générique — « sois plus conservateur » (A) est précisément l'anti-exemple documenté ; (2) les faux positifs d'une catégorie bruyante **sapent la confiance dans les catégories fiables** — d'où la désactivation temporaire des catégories à fort taux de faux positifs. C (consensus par répétition) traite le bruit sans traiter la cause et triple le coût ; D réduit la variance entre exécutions, pas le biais de sur-signalement. --- ## Domaine 5 — Gestion du contexte & fiabilité (2 questions) ### Q14 — Résumé progressif et faits transactionnels (Scénario 7) **Situation :** Un assistant de gestion de sinistres mène des conversations de 100+ tours. Pour contenir le contexte, les tours anciens sont progressivement résumés. Les clients se plaignent : au 60ᵉ tour, l'assistant se trompe sur le montant de franchise annoncé au 5ᵉ tour et sur le numéro de dossier — les résumés successifs les ont transformés en « les conditions ont été discutées ». **Quelle correction architecturale ?** - A. Résumer moins agressivement : conserver 30 tours verbatim au lieu de 10 - B. Extraire les faits transactionnels (montants, numéros, dates, engagements) dans un bloc « case facts » persistant, jamais résumé, injecté à chaque tour — le résumé ne s'appliquant qu'au reste - C. Remplacer le résumé par une fenêtre glissante stricte des 20 derniers tours - D. Demander au modèle de « préserver les chiffres importants » dans ses résumés **Réponse : B.** Le risque documenté du résumé progressif est exactement celui-ci : les **valeurs numériques, dates et identifiants** se diluent en formulations vagues au fil des résumés successifs. La parade structurelle : un bloc de faits persistant **hors** du cycle de résumé. A et D ne font que retarder ou atténuer la dilution (D reste probabiliste, et chaque résumé de résumé recompresse) ; C est pire : la fenêtre glissante **supprime** purement le 5ᵉ tour, franchise comprise. --- ### Q15 — Automatiser sur la foi d'une métrique globale (Scénario 6) **Situation :** Un pipeline d'extraction affiche 97 % de précision globale sur l'ensemble de validation. La direction veut supprimer la revue humaine. Un audit par segments révèle : 99 % sur les factures natives (85 % du volume), mais 71 % sur les scans dégradés et 64 % sur le champ IBAN (IBAN = International Bank Account Number) des bons de livraison — champ utilisé pour les virements. **Quelle décision d'architecte ?** - A. Automatiser : 97 % dépasse le seuil de 95 % fixé par la direction - B. Maintenir la revue humaine sur 100 % des documents tant que chaque segment n'atteint pas 97 % - C. Automatiser par segment : les factures natives passent en automatique avec échantillonnage stratifié continu ; les scans dégradés et les champs critiques faibles (IBAN) restent en revue humaine avec routage par confiance au niveau du champ - D. Réentraîner le prompt sur davantage de scans dégradés, puis automatiser globalement dès que la précision globale atteint 98 % **Réponse : C.** La métrique agrégée **masque** les segments faibles — 97 % global est ici compatible avec 64 % sur un champ critique pour des virements. La réponse d'architecte est segmentée : automatiser là où la performance est démontrée **par type de document et par champ**, garder l'humain là où elle ne l'est pas, avec échantillonnage aléatoire stratifié continu pour détecter les dérives (nouveaux formats fournisseurs). A reproduit exactement le piège ; B sur-corrige et détruit la valeur sur 85 % du volume sans justification ; D améliore peut-être un segment mais reconduit le critère fautif (métrique globale). --- ## Barème et corrigé rapide | Q | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | |---|---|---|---|---|---|---|---|---|---|----|----|----|----|----|----| | Réponse | B | C | B | C | C | A | B | C | B | B | B | A | B | B | C | | Domaine | D1 | D1 | D1 | D1 | D2 | D2 | D2 | D3 | D3 | D3 | D4 | D4 | D4 | D5 | D5 | **Analyse recommandée après correction :** pour chaque erreur, identifier la **famille de distracteur** qui vous a piégé — prompt magique (Q4, Q12), sur-ingénierie (Q5, Q13-C), fonctionnalité inventée (Q9), symptôme au lieu de la cause (Q2, Q15). Votre biais dominant = votre axe de révision prioritaire.