06 · Les scénarios d'examen : méthode, les 6 scénarios, questions et exercices

Version : 1.0 · Date : 2026-10-21 · Chapitre transversal : les 5 domaines

En une phrase : l'examen ne demande pas de réciter la doc, il pose un problème de production dans l'un des 6 scénarios officiels et vérifie que vous choisissez la correction proportionnée qui traite la cause racine : ce chapitre entraîne exactement ce réflexe.

Ce que ce chapitre apporte#

1. La méthode de l'examen#

1.1 Le format#

1.2 Lire un scénario en quatre temps#

1. Le contexte (Agent SDK, Claude Code, CI, extraction) dit quels outils existent. Une réponse qui sort de ce cadre est rarement juste.
2. Le symptôme : « dans 12 % des cas », « le rapport ne couvre que les arts visuels », « le job attend une saisie ». Le chiffre ou le détail des logs pointe la cause.
3. La cause racine : demandez-vous où le problème naît (le coordinator ou le subagent ? la description de l'outil ou le prompt ?). Les corrigés officiels écartent toujours les options qui « réparent en aval ».
4. La correction proportionnée : la plus petite intervention qui traite la cause. « First step », « most effective », « most maintainable » sont des indices : ils écartent l'infrastructure lourde.

1.3 Les distracteurs qui reviennent#

1.4 Le temps et l'écart guide / produit#

• 2 minutes par question : lisez d'abord la question, puis le scénario utile, puis les options. L'examen mesure chacun par rapport à un standard fixe, pas par rapport aux autres candidats (« criterion-referenced », guide § 10) : ne restez pas bloqué sur une question au détriment des suivantes.
• On répond selon le guide v1.0, même quand le produit a évolué (outil Task devenu Agent, allowed-tools qui pré-approuve, tool_choice forcé refusé par les modèles les plus récents, slash commands fusionnées dans les skills). Chaque chapitre donne les deux, dans les encadrés « Réponse d'examen / État actuel » ; le récapitulatif est au chapitre 05, § 8.

2. Les 6 scénarios officiels#

Contextes reformulés d'après le guide (§ 5). Pour chacun : l'architecture attendue, les task statements mobilisés et les pièges.

2.1 Scénario 1 : Customer Support Resolution Agent#

Contexte : un agent de support construit avec le Claude Agent SDK traite des demandes ambiguës (retours, litiges de facturation, comptes) via des outils MCP get_customer, lookup_order, process_refund, escalate_to_human. Objectif : 80 % de résolution au premier contact, en sachant quand escalader. Domaines principaux : 1, 2, 5.

Pièges : « mettre la règle dans le prompt » pour une obligation financière ; escalader sur le sentiment ou sur un score de confiance auto-déclaré ; choisir un client par heuristique quand plusieurs correspondent (il faut demander un identifiant).

2.2 Scénario 2 : Code Generation with Claude Code#

Contexte : l'équipe utilise Claude Code pour générer, refactorer, déboguer et documenter, avec des slash commands, une configuration CLAUDE.md, et doit savoir quand choisir le plan mode ou la direct execution. Domaines principaux : 3, 5.

Pièges : un CLAUDE.md par sous-dossier pour des tests éparpillés partout (les rules avec paths sont la bonne réponse) ; un skill quand il faut un chargement automatique (le skill est à la demande) ; commencer en direct execution « et voir » sur un chantier dont la complexité est déjà connue.

2.3 Scénario 3 : Multi-Agent Research System#

Contexte : un coordinator (Agent SDK) délègue à des subagents spécialisés : recherche web, analyse de documents, synthèse, génération de rapport. Le système produit des rapports complets et cités. Domaines principaux : 1, 2, 5.

Pièges : accuser la recherche ou la synthèse alors que les logs du coordinator montrent la cause ; laisser les subagents se parler directement (tout passe par le coordinator) ; un « search unavailable » générique.

2.4 Scénario 4 : Developer Productivity with Claude#

Contexte : un agent (Agent SDK) aide les ingénieurs à explorer des bases de code inconnues, comprendre du legacy, générer du boilerplate et automatiser des tâches, avec les built-in tools (Read, Write, Bash, Grep, Glob) et des serveurs MCP. Domaines principaux : 2, 3, 1.

Pièges : écrire un serveur MCP maison pour Jira alors qu'un serveur communautaire existe ; mettre un secret en clair dans .mcp.json ; agrandir la fenêtre de contexte au lieu de structurer l'exploration.

2.5 Scénario 5 : Claude Code for Continuous Integration#

Contexte : Claude Code tourne dans la CI/CD : revues automatiques, génération de tests, retours sur les PR. Les prompts doivent donner un retour actionnable et peu de faux positifs. Domaines principaux : 3, 4.

Pièges : « sois prudent » ou « ne signale que ce dont tu es sûr » au lieu de critères ; exiger que les développeurs découpent leurs PR ; voter à deux sur trois exécutions (supprime des vrais bugs détectés par intermittence).

2.6 Scénario 6 : Structured Data Extraction#

Contexte : un système extrait des informations de documents non structurés, valide la sortie avec des JSON schemas, garde une précision élevée, gère les cas limites et alimente des systèmes aval. Domaines principaux : 4, 5.

Pièges : croire que le schéma garantit le sens ; rendre tous les champs obligatoires ; couper la revue sur la foi d'une précision globale.

3. Les 12 questions d'exemple officielles commentées#

Le guide (§ 9) publie 12 questions tirées de son test d'entraînement, avec leur corrigé. Elles sont résumées ici (lisez-les en entier dans le guide officiel), puis commentées.

État actuel : Q4, les commandes sont aujourd'hui fusionnées dans les skills (.claude/skills/review/SKILL.md), mais .claude/commands/ fonctionne toujours : la réponse d'examen reste A. Q9, l'outil Task s'appelle Agent dans le produit. Voir les encadrés des chapitres 03 et 01.

La leçon commune aux 12 corrigés : la bonne réponse traite la cause avec le mécanisme prévu pour cela (code pour une garantie, description pour le choix d'outil, critères pour la précision, découpage pour l'attention), au coût le plus faible.

4. Questions d'entraînement#

25 questions originales, réparties comme l'examen : domaine 1 (7), domaine 2 (4), domaine 3 (5), domaine 4 (5), domaine 5 (4). Répondez sans regarder le corrigé. Sauf mention, une seule réponse.

Domaine 1 · Agentic Architecture & Orchestration#

E1 (scénario 1) Votre boucle s'arrête dès que la réponse contient un bloc texte, alors que Claude voulait encore appeler un outil. Que corriger ? A. Augmenter le nombre maximal d'itérations. B. Continuer tant que stop_reason vaut "tool_use" et s'arrêter sur "end_turn". C. Chercher le mot « terminé » dans le texte de la réponse. D. Demander au modèle d'écrire « DONE » à la fin.

E2 (scénario 3) Le coordinator lance la recherche web, attend, puis lance l'analyse de documents au tour suivant. Les deux sont indépendantes. Comment réduire la latence ? A. Fusionner les deux subagents en un seul. B. Passer au modèle le plus rapide pour les subagents. C. Émettre les deux appels Task dans une seule réponse du coordinator. D. Lancer un second coordinator en parallèle.

E3 (scénario 3) Le rapport final n'a plus aucune citation, alors que le subagent de recherche avait trouvé des sources. Les logs montrent que le coordinator transmet à la synthèse un résumé en prose des findings. Cause la plus probable ? A. Les métadonnées (URL, document, date) ont été perdues au passage de contexte : il faut transmettre des findings structurés. B. Le prompt de la synthèse ne demande pas de citations. C. Le subagent de recherche n'a pas assez de résultats. D. La fenêtre de contexte de la synthèse est trop petite.

E4 (scénario 1) Aucun remboursement au-dessus de 500 USD ne doit partir sans un humain, sans exception. Quelle solution ? A. Écrire la règle en majuscules dans le system prompt. B. Ajouter trois exemples few-shot de refus. C. Vérifier après coup les remboursements dans un rapport quotidien. D. Un hook PreToolUse sur process_refund qui refuse au-delà de 500 USD et oriente vers escalate_to_human.

E5 (scénario 1) Trois outils MCP renvoient des dates en Unix, en ISO 8601 et en JJ/MM/AAAA ; Claude confond le jour et le mois. Que faire ? A. Expliquer les trois formats dans le system prompt. B. Un hook PostToolUse qui normalise toutes les dates avant que Claude lise le résultat. C. Demander à Claude de redemander la date au client. D. Retirer deux des trois outils.

E6 (scénario 4) Hier, une session a analysé un module ; ce matin, trois fichiers de ce module ont changé. Que faire ? A. Créer un fork de la session d'hier. B. Relancer une exploration complète dans une nouvelle session, sans contexte. C. Reprendre la session (--resume) en indiquant les trois fichiers modifiés pour une ré-analyse ciblée. D. Reprendre la session sans rien dire : l'agent relira ce qu'il faut.

E7 (scénario 4) Tâche : « ajoute des tests complets à ce dépôt legacy ». Quelle décomposition ? A. Cartographier la structure, repérer les zones à fort impact, établir un plan priorisé qui s'adapte aux dépendances découvertes. B. Un pipeline fixe : un fichier après l'autre par ordre alphabétique. C. Une seule requête avec tout le dépôt en contexte. D. Un subagent par fichier lancé d'emblée, sans plan.

Domaine 2 · Tool Design & MCP Integration#

E8 (scénario 3) analyze_content et analyze_document ont des descriptions presque identiques ; les pages web partent vers le mauvais outil. Correction la plus directe ? A. Ajouter une règle de routage dans le coordinator. B. Renommer analyze_content en extract_web_results avec une description propre au web. C. Supprimer analyze_document. D. Passer tool_choice en "any".

E9 (scénario 1) lookup_order renvoie « Operation failed » pour un timeout comme pour une commande inexistante ; l'agent relance sans fin les commandes inexistantes. Que changer ? A. Limiter l'agent à trois appels par outil. B. Renvoyer un texte d'erreur plus long. C. Faire échouer toute la conversation sur une erreur d'outil. D. Des erreurs structurées (errorCategory, isRetryable) et un résultat vide valide pour « aucune commande trouvée ».

E10 (scénario 4) L'équipe veut un serveur MCP Jira partagé, authentifié par un token. Bonne configuration ? A. Un serveur communautaire déclaré dans le .mcp.json du dépôt, token passé par ${JIRA_TOKEN}. B. Le token en clair dans .mcp.json pour que tout marche au clone. C. Le serveur dans ~/.claude.json de chaque développeur. D. Un serveur maison écrit pour l'occasion.

E11 (scénario 4) Edit échoue : le texte à remplacer apparaît trois fois dans le fichier. Repli recommandé par le guide ? A. Recommencer Edit jusqu'à ce qu'il passe. B. Utiliser Bash avec sed sur tout le fichier. C. Read du fichier complet, puis Write du contenu modifié. D. Abandonner la modification.

Domaine 3 · Claude Code Configuration & Workflows#

E12 (scénario 2) Un nouvel arrivant ne reçoit pas les conventions que le lead obtient. Cause la plus probable ? A. Le nouvel arrivant n'a pas la bonne version de Claude Code. B. Les conventions sont dans le ~/.claude/CLAUDE.md du lead, non versionné. C. Le CLAUDE.md du projet est trop long. D. Le plan mode est désactivé chez le nouvel arrivant.

E13 (scénario 2) Les conventions Terraform doivent s'appliquer seulement quand on modifie des fichiers sous terraform/. Quoi utiliser ? A. Un fichier .claude/rules/terraform.md avec paths: ["terraform/**/*"]. B. Une section Terraform dans le CLAUDE.md racine. C. Un skill /terraform à lancer à la main. D. Un hook qui ajoute les conventions à chaque prompt.

E14 (scénario 2) Le skill /analyse produit une analyse très longue qui encombre ensuite la conversation. Que faire ? A. Le transformer en CLAUDE.md. B. Lancer /compact après chaque appel. C. Le déplacer dans ~/.claude/skills/. D. Ajouter context: fork dans son frontmatter.

E15 (scénario 5) Après chaque nouveau commit, la revue en CI recommente les mêmes problèmes. Correction ? A. Ne lancer la revue qu'une fois par PR. B. Supprimer les anciens commentaires avant chaque revue. C. Fournir les constats précédents et demander de ne signaler que les nouveaux ou ceux encore non corrigés. D. Baisser la sévérité de tous les constats.

E16 (scénario 2) Une transformation de données décrite en prose donne des résultats différents à chaque essai. Technique la plus efficace ? A. Réécrire la description plus longuement. B. Donner 2 ou 3 exemples concrets d'entrée et de sortie attendues. C. Passer en plan mode. D. Augmenter la température.

Domaine 4 · Prompt Engineering & Structured Output#

E17 (scénario 5) La revue signale tant de détails de style que les développeurs ignorent aussi les vrais bugs. Premier geste ? A. Des critères explicites (signaler bugs et sécurité, ignorer le style) et couper la catégorie style le temps de la corriger. B. Ajouter « sois prudent, ne signale que l'important ». C. Ne garder que les constats à confiance supérieure à 0,9. D. Passer à un modèle plus grand.

E18 (scénario 6) Le modèle remplit due_date alors que la facture n'en contient pas. Correction du schéma ? A. Ajouter une valeur par défaut « 30 jours ». B. Ajouter un exemple few-shot avec une date. C. Rendre le champ nullable pour que le modèle puisse renvoyer null. D. Rendre le champ obligatoire.

E19 (scénario 6) Trois outils d'extraction existent (facture, contrat, bon de commande) et le type de document est inconnu. Il faut une sortie structurée à coup sûr. Réponse attendue à l'examen ? A. tool_choice: "auto". B. Forcer l'outil facture. C. Demander du JSON dans le texte. D. tool_choice: "any".

E20 (scénario 6) La sortie respecte le schéma, mais les lignes ne font pas le total indiqué. Que faire ? A. Rendre le schéma plus strict. B. Extraire calculated_total à côté de stated_total, signaler l'écart et relancer avec l'erreur précise. C. Arrondir automatiquement les montants. D. Rejeter tous les documents concernés.

E21 (scénario 6) 10 000 documents d'archive à traiter d'ici la semaine prochaine, budget serré. Stratégie ? A. Message Batches API, prompt mis au point sur un échantillon, resoumission des seuls échecs par custom_id. B. Appels synchrones en parallèle maximum. C. Un seul appel avec tous les documents. D. Message Batches API sans test préalable, puis tout relancer en cas d'erreur.

Domaine 5 · Context Management & Reliability#

E22 (scénario 1) Après un long échange résumé au fil de l'eau, l'agent ne sait plus le montant exact promis au client. Que faire ? A. Augmenter la taille du résumé. B. Repartir d'une nouvelle conversation. C. Garder un bloc « case facts » (montants, dates, IDs, statuts) inclus à chaque requête, hors de l'historique résumé. D. Demander au client de répéter.

E23 (scénario 1) Pour un problème simple, le client écrit : « je veux parler à un humain ». Que fait l'agent ? A. Il escalade tout de suite. B. Il résout d'abord, puis propose l'humain. C. Il mesure le sentiment pour décider. D. Il demande au client de noter sa confiance.

E24 (scénario 6) Précision globale de 97 % ; on veut supprimer la revue humaine. Préalable ? A. Aucun : 97 % suffit. B. Monter le seuil de confiance à 0,99. C. Passer à un modèle plus grand. D. Mesurer la précision par type de document et par champ, avec un échantillonnage stratifié des extractions à forte confiance.

E25 (scénario 3, 2 réponses) Deux sources fiables donnent des chiffres différents pour la même statistique. Que faire ? A. Garder la valeur de la source la plus citée. B. Conserver les deux valeurs, chacune avec sa source. C. Exiger la date de publication ou de collecte de chaque valeur. D. Publier la moyenne des deux.

5. Les 4 exercices officiels, guidés#

Le guide (§ 8) recommande quatre exercices. Voici comment les mener, avec les labs des chapitres qui en couvrent une partie. Clé API de test via ANTHROPIC_API_KEY, jamais en dur ; un modèle économique (Claude Haiku 5.5) suffit pour la plupart des étapes ; budget : quelques dollars par exercice.

5.1 Exercice 1 : un agent multi-outils avec escalade (domaines 1, 2, 5)#

1. Définir 3 à 4 outils MCP (par exemple get_customer, lookup_order, lookup_invoice, process_refund), dont deux proches (commande et facture), avec des descriptions qui donnent formats, exemples et limites (02, § 2).
2. Écrire la boucle pilotée par stop_reason (tool_use → exécuter, end_turn → répondre) (01, lab 1).
3. Renvoyer des erreurs structurées : errorCategory (transient, validation, permission), isRetryable, message lisible ; vérifier que l'agent relance un timeout et explique une erreur métier (02, lab 2).
4. Ajouter un hook qui bloque un remboursement au-dessus d'un seuil et redirige vers l'escalade (01, lab 3).
5. Tester un message à plusieurs sujets (« ma commande est en retard et j'ai été facturé deux fois ») : l'agent doit traiter chaque point puis répondre de façon unifiée.

Résultat attendu : bon outil choisi entre commande et facture, aucun remboursement non conforme, erreurs traitées selon leur type.

5.2 Exercice 2 : Claude Code pour une équipe (domaines 3, 2)#

Couvert par le lab 1 du chapitre 03, qui en est une version guidée :

1. CLAUDE.md du projet avec les standards et les conventions de test ; vérifier qu'ils s'appliquent à tous (/memory).
2. .claude/rules/ avec paths: ["src/api/**/*"] et paths: ["**/*.test.*"] : vérifier qu'elles ne se chargent que sur les fichiers concernés.
3. Un skill de projet avec context: fork et allowed-tools : vérifier qu'il tourne isolé.
4. Un serveur MCP dans .mcp.json avec ${VAR}, plus un serveur personnel dans ~/.claude.json : les deux visibles en même temps.
5. Comparer plan mode et direct execution sur un bug d'un fichier, une migration multi-fichiers, une fonctionnalité à plusieurs approches (03, lab 4).

Résultat attendu : configuration partagée par le dépôt, rules conditionnelles, plan mode utile seulement sur les deux derniers cas.

5.3 Exercice 3 : un pipeline d'extraction structurée (domaines 4, 5)#

1. Outil d'extraction avec champs obligatoires et optionnels, enum "other" + détail, champs nullable ; vérifier null sur les informations absentes (04, lab 2).
2. Boucle validation-retry (Pydantic) : renvoyer document, extraction ratée et erreur précise ; noter ce qu'un retry corrige (format) et ce qu'il ne corrige pas (information absente).
3. Few-shot sur des structures variées (citations en ligne ou bibliographie, texte ou tableau).
4. Lot de 100 documents en Message Batches API : reprise par custom_id, découpe des documents trop longs, calcul du délai par rapport au SLA (04, lab 3).
5. Confiance par champ et routage vers la revue humaine ; analyser la précision par type de document et par champ (05, lab 3).

Résultat attendu : aucune valeur inventée, retries ciblés, revue humaine concentrée sur les cas incertains.

5.4 Exercice 4 : un pipeline de recherche multi-agents (domaines 1, 2, 5)#

1. Coordinator avec deux subagents (recherche web, analyse de documents) ; allowedTools contient "Task" (état actuel : "Agent") et chaque subagent reçoit ses données dans son prompt (01, lab 2).
2. Appels parallèles dans une seule réponse ; mesurer le gain de latence par rapport au séquentiel.
3. Findings structurés : affirmation, extrait, source, date ; vérifier que la synthèse garde l'attribution.
4. Simuler un timeout : le coordinator reçoit type d'échec, requête, résultats partiels, et annote les trous de couverture (05, lab 2).
5. Deux sources contradictoires : les deux valeurs conservées, sections « établi » et « contesté » (05, lab 5).

Résultat attendu : un rapport complet, sourcé, qui dit ce qu'il n'a pas pu couvrir.

6. Fiche à retenir globale#

• 60 questions, 4 scénarios sur 6, 120 minutes, 720 sur 1 000 ; on répond selon le guide v1.0.
• Règle à respecter à 100 % → code (hook, gate) ; préférence → prompt.
• Mauvais outil choisi → d'abord la description ; trop d'outils → jeu restreint par rôle.
• Erreurs : isError, catégorie, isRetryable ; vide valide ≠ échec d'accès ; jamais masquer, jamais tout arrêter.
• Un pan du sujet manque → décomposition du coordinator ; citations perdues → métadonnées perdues au passage de relais.
• Subagents : contexte explicite dans le prompt, appels parallèles dans une réponse, tout passe par le coordinator.
• Partagé = dans le dépôt ; personnel = ~/.claude/ ; conventions par type de fichier = rules avec paths.
• Tâche architecturale = plan mode ; changement simple = direct ; découverte verbeuse = Explore subagent.
• CI : -p, --output-format json, --json-schema, constats précédents fournis, instance indépendante.
• Précision : critères explicites, pas « sois prudent » ; 14 fichiers = passes par fichier + intégration.
• Schéma : syntaxe garantie, sens non ; nullable contre l'invention ; retry inutile si l'info est absente.
• Batch : -50 %, jusqu'à 24 h, pas de SLA, custom_id ; jamais pour un check bloquant.
• Longues conversations : case facts ; demande d'un humain = escalade immédiate ; ni sentiment ni confiance auto-déclarée.
• 97 % global ne suffit pas : mesurer par type et par champ, échantillonnage stratifié.
• Sources en conflit : garder les deux valeurs, sources et dates.

7. Corrigé des questions d'entraînement#

Références#

Lues le 21/10/2026 :

• Claude Certified Architect – Foundations Exam Guide v1.0 (juillet 2026), § 3 (format), § 5 (scénarios), § 8 (exercices), § 9 (questions d'exemple), § 14 (confidentialité)
• Anthropic Partner Academy, page de la certification
• claudecertificationguide.com, base des leçons du cours
• Sources techniques : voir les références des chapitres 01 à 05