# The 6 Exam Scenarios Les six scénarios de référence dont le CCAR-F tire ses items — contexte métier, architecture de référence, décisions clés avec les réponses correctes à l’examen, anti-patterns distracteurs, et questions d’entraînement pour chacun. import { Accordions, AccordionItem } from '@prosefly/astro-components'; L’examen Architect – Foundations tire ses items de **4 de ces 6 scénarios**. Vous ne saurez pas lesquels à l’avance : préparez donc les six. Chaque scénario ci-dessous donne le contexte métier, une architecture de référence, les décisions architecturales clés avec la réponse **correcte à l’examen**, les anti-patterns qui apparaissent comme **distracteurs**, et trois questions d’entraînement. Les scénarios ne sont pas indépendants des domaines — ils sont la façon dont les domaines sont *testés*. Chaque question de ce cours est étiquetée à un scénario aussi bien qu’à un domaine. --- ## Scenario 1 · Customer Support Resolution Agent *(Agent de résolution du support client.)* **Contexte métier.** Une entreprise SaaS veut un agent qui résout de bout en bout les demandes de support courantes — statut de commande, remboursements, changements d’abonnement — par chat, ne passant la main à des humains que lorsque nécessaire. Construit sur l’**Agent SDK**, intégrant les systèmes backend via des **outils MCP**, avec un chemin d’**escalade**. ```text Customer ─► [Support Agent · Agent SDK loop] │ stop_reason-driven loop ├─ MCP tools: get_order_status, issue_refund(idempotency_key), │ update_subscription, search_kb ├─ PreToolUse hook: refund > $X requires human approval └─ escalate: explicit request → now; capability gap → after attempt │ [Human agent queue] (with correlation ID + transcript) ``` ### Décisions clés et la réponse correcte à l’examen | Décision | Réponse correcte à l’examen | | --- | --- | | Workflow ou agent ? | **Agent** — les résolutions sont ouvertes, les étapes varient par requête | | Comment la boucle se termine-t-elle ? | Sur **`stop_reason`** (`end_turn`/`tool_use`), avec un plafond comme filet de sécurité | | Quand escalader ? | **Demande explicite** (immédiatement) ou **lacune de capacité** (après avoir tenté) — jamais sentiment/auto-déclaration | | Comment imposer « les remboursements au-delà de $X nécessitent un humain » ? | **PreToolUse hook** (code de sortie 2), non une instruction de prompt | | Comment `issue_refund` évite-t-il les doubles remboursements au réessai ? | **Clé d’idempotence** | | Où vivent les intégrations backend ? | **Outils MCP**, 4 à 5 ciblés | ### Anti-patterns distracteurs - Escalader parce que le client « paraît frustré » (#5) ou que le modèle « signale une faible confiance » (#4). - Imposer la limite de remboursement via une ligne de system prompt (#3). - Donner 18 outils à l’agent « pour être complet » (#8). - `issue_refund` renvoyant vide/générique en cas d’échec (#6, #7). --- ## Scenario 2 · Code Generation with Claude Code *(Génération de code avec Claude Code.)* **Contexte métier.** Une équipe d’ingénierie se standardise sur Claude Code. Elle veut des conventions partagées, des permissions sûres, des barrières de qualité imposées, et des workflows de revue répétables à l’échelle de l’équipe. ```text Repo/ ├─ CLAUDE.md (checked in: build/test cmds, architecture, conventions) ├─ .claude/ │ ├─ settings.json (checked in: permissions allow/deny/ask, hooks, model) │ ├─ agents/security-reviewer.md (isolated context, tools allowlist, model) │ ├─ commands/review.md (/review $ARGUMENTS) │ └─ hooks/guard.sh (PreToolUse: block rm -rf; tests before commit) └─ .mcp.json (project-scope shared MCP servers) Managed policy (org) ──► overrides everything below ``` ### Décisions clés et la réponse correcte à l’examen | Décision | Réponse correcte à l’examen | | --- | --- | | Où vivent les conventions d’équipe ? | **`./CLAUDE.md` de projet**, versionné | | Où vivent les règles obligatoires et non contournables ? | **Managed policy** | | Imposer « les tests doivent passer avant le commit » ? | **PreToolUse hook** sortant en 2 | | Gros refactor inconnu — première étape ? | **Plan mode** (lecture seule, revoir le plan d’abord) | | Un prompt de revue répétable invoqué par son nom ? | **Slash command** avec `$ARGUMENTS` | | Garder CLAUDE.md peu coûteux ? | **Concis**, `@import` du matériel de référence | ### Anti-patterns distracteurs - Règle d’équipe placée dans `CLAUDE.local.md` ignoré par git. - Barrière de qualité imposée via la prose de CLAUDE.md (#3). - Exécution directe sur un gros refactor inconnu au lieu du plan mode. - Secrets stockés dans CLAUDE.md. --- ## Scenario 3 · Multi-Agent Research System *(Système de recherche multi-agents.)* **Contexte métier.** Un outil de recherche répond à des questions larges en les décomposant en sous-questions, en dispatchant des sous-agents pour enquêter en parallèle, et en synthétisant une réponse sourcée. Une **gestion d’erreurs** robuste et une conception **coordinateur/sous-agents** sont au centre. ```text Question ─► [Coordinator] plans sub-questions, aggregates, decides done │ explicit context passing (never inheritance) ┌───────────┼───────────────┐ [Subagent A] [Subagent B] [Subagent C] isolated contexts, own tools └── structured result {finding, sources, confidence} ──┐ aggregate + partial-failure handling ◄──────┘ (quorum? retry retryable? escalate?) provenance of gaps ``` ### Décisions clés et la réponse correcte à l’examen | Décision | Réponse correcte à l’examen | | --- | --- | | Patron ? | **Orchestrator-workers** — sous-tâches décidées à l’exécution | | Comment les sous-agents obtiennent-ils le contexte ? | **Passage explicite** dans le prompt de tâche ; pas d’auto-héritage | | Un sous-agent échoue — comportement du coordinateur ? | **Erreur structurée → réessayer le réessayable → continuer avec un quorum en notant la lacune, ou escalader** | | Comment protéger le contexte principal ? | **Isolation des sous-agents** — la matière brute reste dans les fenêtres des sous-agents | | Comment tracer une tâche en échec ? | **Traces par agent + identifiant de corrélation** | | Préoccupation de coût ? | Modèle par sous-agent (Haiku pour le simple), justifier le fan-out | ### Anti-patterns distracteurs - Supposer que les sous-agents héritent des découvertes du coordinateur. - Écarter en silence un sous-agent en échec et présenter le reste comme complet (#7). - Renvoyer un message générique « research failed » (#6). - Construire 8 sous-agents là où un workflow en 2 étapes atteint la barre (sur-conception). --- ## Scenario 4 · Developer Productivity *(Productivité des développeurs.)* **Contexte métier.** Les développeurs utilisent Claude pour explorer de grandes bases de code, exécuter des analyses et intégrer des systèmes internes. Le centre est sur les **outils intégrés/côté serveur** et les **serveurs MCP** pour l’exploration de code. ```text Developer ─► [Claude · Opus 5] ├─ server-side tools: web search, code execution ├─ MCP servers: internal docs, ticketing, code search │ (project .mcp.json; least-privilege scopes) └─ subagent for large codebase exploration (isolated context) ``` ### Décisions clés et la réponse correcte à l’examen | Décision | Réponse correcte à l’examen | | --- | --- | | Ancrer les réponses dans l’info actuelle avec citations ? | Outil côté serveur **web search** | | Exécuter du calcul/de l’analyse de données ? | Outil côté serveur **code execution** | | Intégrer des systèmes internes de façon réutilisable entre clients ? | **Serveurs MCP** (portée projet) | | Explorer une énorme base de code sans inonder le contexte ? | Isolation par **subagent** | | Étape déterministe que votre code peut faire lui-même ? | **API/CLI directe**, non un outil du modèle | | Combien d’outils par agent ? | **4 à 5 ciblés** ; tool search + `defer_loading` au-delà d’~10 | ### Anti-patterns distracteurs - Envelopper un appel déterministe en outil du modèle. - Surcharger l’agent d’outils (#8). - Choisir un Skill là où une intégration inter-clients a besoin d’un serveur MCP. --- ## Scenario 5 · Claude Code for CI/CD *(Claude Code pour la CI/CD.)* **Contexte métier.** Un pipeline exécute Claude Code en **headless** pour relire les PR, générer des notes de version et barrer les merges. L’accent est sur la **sortie structurée**, le **Batch API** et la **revue multi-passes** des grosses PR. ```text CI trigger ─► claude -p "review diff" --output-format json --allowedTools "Read,Grep,Bash(git diff:*)" --permission-mode acceptEdits │ parse JSON findings; gate pipeline on exit code Large PR ─► partition by module ─► review each pass/subagent ─► aggregate + rank Bulk jobs (release notes for 500 PRs) ─► Message Batches API (50% off, ≤24h) ``` ### Décisions clés et la réponse correcte à l’examen | Décision | Réponse correcte à l’examen | | --- | --- | | Comment exécuter en CI ? | **`claude -p` headless**, `--output-format json`, `--allowedTools` minimal, barrer sur le **code de sortie** | | Découvertes lisibles par machine ? | **Sortie structurée** (schéma JSON / structured outputs) | | Revue de grosse PR ? | **Multi-passes** : partitionner → relire → agréger | | Tâches de masse tolérantes à la latence ? | **Batch API** (réduction de 50 %, sous 24 h) | | Moindre privilège en CI ? | `--allowedTools` étroit + deny des opérations dangereuses ; non `bypassPermissions` | ### Anti-patterns distracteurs - `--permission-mode bypassPermissions` avec tous les outils en CI. - Relire une PR de 4 000 lignes en une seule passe de contexte. - Grep sur la prose au lieu de parser la sortie JSON. - Précision agrégée entre types de PR masquant un type faible (#10). --- ## Scenario 6 · Structured Data Extraction *(Extraction de données structurées.)* **Contexte métier.** Un pipeline extrait des enregistrements structurés de documents hétérogènes (factures, contrats, reçus) et alimente une base de données. L’accent est sur les **schémas JSON**, le **tool_use** et la **reprise sur validation**. ```text Document ─► classify type ─┬─ invoice schema ┐ ├─ contract schema ├─► extract (structured outputs / └─ receipt schema ┘ strict tool) ─► validate │ fail: feed error back, retry ▼ ok per-type metrics ─► DB (with provenance) ``` ### Décisions clés et la réponse correcte à l’examen | Décision | Réponse correcte à l’examen | | --- | --- | | Garantir une sortie conforme au schéma ? | **Structured outputs** (`output_config.format`) ou **strict tools** | | Sur Fable 5.1, forcer un outil ? | **Non** — `auto` + instruction / `strict` / structured outputs | | La validation échoue ? | **Renvoyer l’erreur spécifique** et réessayer ; parser défensivement | | Mesurer la qualité ? | **Par type de document**, barrer sur le pire type (non agrégé — #10) | | `max_tokens` sur un gros doc ? | Troncature — augmenter la limite ou découper ; non un achèvement | | Champ optionnel absent ? | Modéliser **nullable** dans le schéma, non une valeur hallucinée | ### Anti-patterns distracteurs - Forcer `tool_choice` sur Fable 5.1 (400). - Un unique chiffre de précision agrégé entre types (#10). - Traiter une sortie `max_tokens` tronquée comme complète. - Noter la qualité d’extraction dans la même session qui l’a produite (#9). --- ## Référence transversale des modes de défaillance Chaque scénario a une façon caractéristique de casser en production. Mémoriser la chaîne défaillance → cause racine → correctif est ce qui vous permet d’éliminer les distracteurs vite. | Scénario | Défaillance courante | Cause racine | Correctif correct à l’examen | | --- | --- | --- | --- | | S1 Support agent | La boucle ne s’arrête jamais / s’arrête trop tôt | Analyse de la prose pour la terminaison (#1) | Piloter depuis `stop_reason` | | S1 Support agent | Double remboursement au réessai | Écriture non idempotente réessayée | Clé d’idempotence | | S1 Support agent | Détourné par un contenu récupéré | Résultat d’outil traité comme des instructions | Frontières de contenu + moindre privilège + barrière humaine | | S2 Code gen | Règle non imposée | Application par prompt/CLAUDE.md (#3) | PreToolUse hook, exit 2 | | S2 Code gen | Le mauvais fichier détient un réglage | Confusion partagé/personnel ou indicatif/obligatoire | Mapping managed policy / project / local | | S3 Research | Le sous-agent ignore des découvertes connues | Contexte isolé, pas de passage explicite | Passer le contexte explicitement à chaque palier | | S3 Research | Rapport partiel livré comme complet | Suppression silencieuse (#7) | Erreur structurée + quorum/escalade | | S3 Research | Coût 12×, gain marginal | Topologie sur-conçue | La conception la plus simple qui atteint la barre + caching | | S4 Dev productivity | Mauvais outil appelé | Trop d’outils (#8) | 4-5 ciblés / tool search + defer_loading | | S4 Dev productivity | Étape déterministe instable | Enveloppée en outil du modèle | Appeler l’API/CLI directement | | S5 CI/CD | Build non barré | Grep sur la prose / ignorer le code de sortie | Sortie JSON + gating sur le code de sortie | | S5 CI/CD | Shell arbitraire depuis un diff | Permissions larges en CI | `--allowedTools` minimal, pas de bypass | | S6 Extraction | 400 sur Fable 5.1 | `tool_choice` forcé | auto+instruction / strict / structured outputs | | S6 Extraction | Livre de mauvais contrats à « 94 % » | Métrique agrégée (#10) | Métriques par type, barrer sur le pire | | S6 Extraction | JSON partiel persisté | `max_tokens` traité comme complet | Augmenter la limite / découper, ne jamais persister le partiel | --- ## Questions d’entraînement Cinq par scénario — 30 au total. Chacune est étiquetée avec son scénario et son domaine. A. Escalader immédiatement à cause du sentiment négatif. B. Résoudre la demande de statut de commande ; le sentiment seul n’est pas un déclencheur d’escalade. C. Escalader parce que la confiance du modèle est inférieure à 70 %. D. Plafonner la conversation à 3 tours puis escalader. **Réponse : B.** Le sentiment n’est pas un déclencheur (#5) ; la demande est dans le périmètre de capacité, donc résolvez-la. L’escalade fondée sur la confiance est le #4, et un plafond arbitraire n’est pas une règle d’escalade. A. Une phrase dans le system prompt de l’agent. B. Un PreToolUse hook sur `issue_refund` qui inspecte le montant et sort en 2 pour bloquer, aiguillant vers un humain. C. Demander au modèle de se revérifier. D. Une note dans CLAUDE.md. **Réponse : B.** Les règles critiques nécessitent des hooks déterministes (#3). Le texte de prompt/CLAUDE.md (A, D) et l’auto-vérification (C) sont probabilistes. A. Un backoff plus long. B. Une clé d’idempotence sur `issue_refund` pour que les réessais ne dupliquent pas l’effet. C. Ne jamais rien réessayer. D. Un modèle plus gros. **Réponse : B.** Les clés d’idempotence rendent sûrs les réessais d’écriture. Le backoff (A) n’empêche pas la duplication, ne jamais réessayer (C) est inutile, et la taille du modèle (D) est sans rapport. A. L’ajouter au CLAUDE.md de projet. B. Un PreToolUse hook versionné qui exécute les tests au commit et sort en 2 en cas d’échec. C. Demander à chaque développeur de s’en souvenir. D. Une slash command qui exécute les tests. **Réponse : B.** Un hook versionné l’impose de façon déterministe pour tous. CLAUDE.md (A) et la mémoire (C) sont probabilistes ; une slash command (D) est opt-in. A. Les commandes de build et de test de l’équipe. B. Les notes de travail personnelles d’un développeur et les chemins de sa machine locale. C. Les conventions d’architecture du repo. D. Une règle de sécurité obligatoire. **Réponse : B.** Les notes personnelles non partagées vont dans le fichier local ignoré par git. Les commandes/conventions d’équipe (A, C) vont dans le CLAUDE.md de projet ; les règles obligatoires (D) vont dans la managed policy. A. Exécution directe pour aller vite. B. Plan mode : exploration en lecture seule puis un plan relisible avant les éditions. C. Supprimer les tests en échec. D. Augmenter max_tokens. **Réponse : B.** Un travail volumineux, inconnu et multi-fichiers est le cas canonique du plan mode. L’exécution directe (A) saute la revue, supprimer les tests (C) est destructeur, et max_tokens (D) est sans rapport. A. Le sous-agent a besoin d’une plus grande fenêtre. B. Les contextes des sous-agents sont isolés et n’héritent pas des découvertes ; le coordinateur doit passer le contexte explicitement. C. Le sous-agent a utilisé le mauvais modèle. D. Le thinking était désactivé. **Réponse : B.** Les contextes isolés n’auto-héritent jamais. La taille de fenêtre (A), le modèle (C) et le thinking (D) ne fournissent pas un contexte jamais passé. A. Présenter les trois résultats comme la réponse complète. B. Enregistrer des erreurs structurées (timeout, réessayable), réessayer les réessayables, puis continuer avec un quorum en notant la lacune ou escalader. C. Tout jeter et relancer. D. Renvoyer « research failed ». **Réponse : B.** Erreurs structurées plus décision explicite. Le rejet silencieux (A) est le #7, la relance (C) gâche du bon travail, et un message générique (D) est le #6. A. Passer à Haiku 4.5 pour une plus grande fenêtre. B. Faire renvoyer aux sous-agents uniquement des résultats distillés et structurés ; leurs contextes isolés détiennent la matière brute. C. Désactiver le thinking. D. Supprimer la gestion d’erreurs. **Réponse : B.** L’isolation des sous-agents plus des retours distillés gardent la fenêtre principale petite. Haiku 4.5 (A) a une fenêtre plus petite (200k), et C/D sont sans rapport ou nuisibles. A. Code execution. B. Outil côté serveur web search. C. Memory tool. D. Computer use. **Réponse : B.** Le web search ancre avec des citations. Code execution (A) exécute du code, memory (C) persiste l’état, computer use (D) pilote un bureau. A. Trois outils personnalisés séparés. B. Un serveur MCP exposant la capacité, connecté par chaque host et via le connecteur MCP de la Messages API. C. Une slash command. D. Une note dans CLAUDE.md. **Réponse : B.** MCP fournit une intégration inter-clients unique et réutilisable. Trois outils (A) dupliquent le travail ; une slash command (C) et CLAUDE.md (D) sont des artefacts Claude Code, non des intégrations. A. Oui, par cohérence. B. Non — appelez l’API/CLI directement ; l’envelopper en outil du modèle ajoute inutilement latence, coût et non-déterminisme. C. Oui, exposez-la comme une resource MCP. D. Seulement si elle est sur Fable 5.1. **Réponse : B.** Les étapes déterministes que votre code possède devraient être appelées directement. L’envelopper (A, C) est de la sur-conception ; la version modèle (D) est sans rapport. A. `claude -p "…" --output-format json --allowedTools "Read,Grep,Bash(git diff:*)"`, parser le JSON, barrer sur le code de sortie. B. `claude` interactif, copier les résultats à la main. C. `--permission-mode bypassPermissions` avec tous les outils. D. `claude -p` simple et grep sur la prose. **Réponse : A.** Sortie JSON headless, allowlist minimale, gating sur le code de sortie. L’interactif (B) n’automatise pas, contourner les permissions (C) est dangereux, et grep sur la prose (D) n’est pas fiable. A. Messages API en temps réel à forte concurrence. B. La Message Batches API — 50 % de réduction, résultats sous 24 h, tolérante à la latence. C. Une seule requête géante avec les 500 diffs. D. Forcer tool_choice sur Fable 5.1. **Réponse : B.** Le Batch API convient au travail de masse tolérant à la latence à demi-tarif. La forte concurrence (A) risque les limites et coûte plus, une seule requête (C) ne rentrera pas, et forcer tool_choice sur Fable 5.1 (D) renvoie 400. A. Tronquer à 500 lignes. B. Multi-passes : partitionner par module, relire chacune dans sa propre passe/subagent, puis agréger et classer les découvertes. C. Un seul prompt géant avec tout le diff. D. Sauter la revue. **Réponse : B.** Partitionner-relire-agréger préserve la qualité. La troncature (A) manque du code, un prompt géant (C) dégrade la qualité, et sauter (D) est inacceptable. A. Réessayer avec backoff. B. Utiliser `tool_choice: 'auto'` avec une instruction d’appeler l’outil, des schémas `strict: true`, ou des structured outputs. C. Utiliser `tool_choice: 'any'`. D. Baisser max_tokens. **Réponse : B.** Fable 5.1 interdit le tool choice forcé ; utilisez auto+instruction, strict, ou structured outputs. Le backoff (A) ne corrige pas un 400, `any` (C) est aussi bloqué, et max_tokens (D) est sans rapport. A. Augmenter la taille d’échantillon. B. Reporter la précision par type de document et barrer sur le pire type. C. Augmenter la température pour les contrats. D. Moyenner plus d’exécutions. **Réponse : B.** Les métriques agrégées masquent un type défaillant (#10) ; les métriques par type l’exposent. De plus grands échantillons (A) agrègent encore, la température (C) ne corrige pas la précision, et moyenner (D) masque davantage le problème. A. Plus de réessais aveugles. B. Renvoyer l’erreur de validation spécifique au modèle et exiger un JSON valide correspondant au schéma ; parser défensivement. C. Utiliser `eval()` pour parser. D. Noter la sortie dans la même session qui l’a produite. **Réponse : B.** Un retour d’erreur spécifique pilote l’auto-correction. Les réessais aveugles (A) aident rarement, `eval()` (C) est dangereux, et la notation en même session (D) est le #9. A. Retirer le timeout pour que les appels lents finissent par revenir. B. Fixer un timeout de frontière ; en cas de timeout renvoyer une erreur structurée `{category:'timeout', retryable:true}` pour que l’agent puisse réessayer, continuer en notant la lacune, ou escalader. C. Attraper le timeout et renvoyer un succès vide. D. Utiliser un modèle plus gros pour que l’outil réponde plus vite. **Réponse : B.** Les timeouts de frontière plus une erreur structurée gardent l’agent réactif et honnête. Aucun timeout (A) laisse un outil bloqué figer l’agent, un succès vide (C) est le #7, et la taille du modèle (D) ne change pas la latence d’un outil en aval. A. Un seuil de confiance sur le modèle. B. Un PreToolUse hook déterministe sur l’outil de transfert qui inspecte le montant et sort en 2 au-dessus du seuil, ignorant toute « pré-approbation » injectée. C. Escalader seulement si le client paraît anxieux. D. Une instruction de system prompt pour demander avant les gros transferts. **Réponse : B.** Les actions irréversibles à forte valeur nécessitent une barrière déterministe calée sur le montant, immunisée contre l’injection. La confiance (A) est le #4, le sentiment (C) est le #5, et une règle de prompt (D) est le #3. A. PostToolUse pour bloquer le commit ; PreToolUse pour linter. B. PreToolUse sur le commit (exécuter les tests, sortir en 2 en cas d’échec) et PostToolUse sur Edit pour linter. C. UserPromptSubmit pour les deux. D. SessionStart pour linter et Stop pour exécuter les tests. **Réponse : B.** Le blocage se fait avant l’action (PreToolUse, exit 2) ; le linting réagit après l’édition (PostToolUse). A intervertit les événements, C utilise un événement de prompt, et D se déclenche aux mauvais moments. A. Haiku 4.5 (user est le plus personnel). B. Sonnet 5 — la managed policy ne peut être surchargée. C. Opus 5 (project est le plus proche du code). D. Le fichier changé en dernier. **Réponse : B.** La managed policy surcharge local, project et user. A et C inversent la précédence ; D n’est pas la façon dont la résolution fonctionne. A. Compaction, parce qu’elle résume tout. B. Édition de contexte pour effacer les résultats d’outils périmés tout en préservant la trame narrative ; la compaction serait fausse ici car elle résume le dialogue au lieu de cibler les sorties d’outils volumineuses. C. Passer à Haiku 4.5 pour sa plus grande fenêtre. D. Augmenter max_tokens. **Réponse : B.** Effacer des résultats d’outils volumineux et périmés est l’édition de contexte, qui garde le dialogue. La compaction (A) cible la trame narrative, Haiku 4.5 (C) a une fenêtre plus petite de 200k, et max_tokens (D) est sans rapport. A. Les workers ont besoin de plus grandes fenêtres. B. Le contexte est isolé à chaque palier ; chaque niveau doit passer explicitement le contexte pertinent au suivant — l’héritage ne se produit jamais à aucune profondeur. C. La racine devrait utiliser Opus 5. D. Le thinking est désactivé au palier des workers. **Réponse : B.** L’isolation s’applique à chaque palier, donc le contexte doit être tissé explicitement jusqu’en bas. La taille de fenêtre (A) et le modèle (C) ne fournissent pas un contexte non passé ; le thinking (D) est sans rapport. A. Les deux comme des Tools. B. La politique comme une Resource (données contrôlées par l’application) et `search_orders` comme un Tool (action contrôlée par le modèle). C. Les deux comme des Prompts. D. La politique comme un Tool et `search_orders` comme une Resource. **Réponse : B.** Les données de référence fournies par l’app sont une Resource ; une action invoquée par le modèle est un Tool. Faire de la politique un Tool (A, D) ajoute des décisions inutiles au modèle ; les Prompts (C) sont des gabarits invoqués par l’utilisateur. A. Toutes les portées OAuth pour qu’il ne manque jamais d’une capacité. B. Cadrer son octroi OAuth 2.1 sur un accès en lecture seule aux commandes (le moindre privilège appliqué à l’auth). C. Intégrer une clé API admin dans le prompt. D. Utiliser stdio pour qu’aucune auth ne soit nécessaire. **Réponse : B.** Le moindre privilège s’applique à l’auth MCP. Toutes les portées (A) élargissent le rayon d’impact, les clés intégrées au prompt (C) sont peu sûres, et stdio (D) est un transport local, non une option pour un serveur distant partagé. A. `--output-format text`, puis grep pour « HIGH ». B. `--output-format json`, parser les découvertes, et faire échouer sur un code de sortie non nul et toute découverte de sévérité élevée. C. `--output-format stream-json` et ignorer le code de sortie. D. Mode interactif avec un humain lisant la sortie. **Réponse : B.** Un résultat JSON unique plus un gating code-de-sortie-et-découvertes est correct pour une tâche courte. Grep sur la prose (A) n’est pas fiable, ignorer le code de sortie (C) manque les échecs, et le mode interactif (D) n’automatise pas. A. Mettre en cache le préfixe stable system + schéma pour que les lectures coûtent ~0,1×. B. Utiliser la Message Batches API pour l’exécution de masse (50 % de réduction, ≤24 h). C. Appeler l’API temps réel à concurrence maximale. D. Utiliser Fable 5.1 à $10/$50 pour chaque document. E. Randomiser le prompt à chaque appel. **Réponse : A et B.** Mettre en cache le préfixe fixe plus le Batch API réduisent fortement le coût pour un travail de masse tolérant à la latence. La concurrence temps réel (C) est à plein tarif et sujette aux limites, le modèle le plus cher (D) augmente le coût, et randomiser (E) détruit le préfixe cachable. A. Un objet lâche unique avec tout optionnel. B. Une union discriminée (`oneOf` avec un discriminateur `const` `doc_type`) pour que chaque branche impose ses propres champs requis. C. Trois endpoints sans rapport et sans contrat partagé. D. Un unique champ chaîne contenant du texte JSON brut. **Réponse : B.** Une union discriminée impose les exigences par type dans un seul schéma. A relâche tout, C perd un contrat partagé, et D abandonne les garanties de schéma. A. Écrire l’objet partiel ; il est presque complet. B. Traiter `max_tokens` comme une troncature : augmenter la limite ou découper le document (ou borner les tableaux avec `maxItems`), puis réessayer — ne jamais persister la sortie partielle. C. Renvoyer un objet vide pour que le pipeline continue. D. Demander au modèle dans la même session s’il a terminé. **Réponse : B.** `max_tokens` est une troncature, non un achèvement. Persister le partiel (A) corrompt les données, vide (C) est le #7, et l’auto-vérification en même session (D) ne traite pas la troncature.