D2 · Claude Models, Prompting & Context Engineering

Ce domaine pèse 13 % – environ 8 des 63 items. Au niveau Professional, vous n’écrivez pas un seul prompt ; vous gérez un portefeuille de modèles et une bibliothèque de prompts gouvernés à l’échelle d’une organisation, avec le calcul de coût, le versionnement, le déploiement et la gestion des changements incompatibles. Les items récompensent l’option qui traite prompts, modèles et configuration du thinking comme des actifs conçus et versionnés aux arbitrages mesurables.

Objectifs d’apprentissage

À la fin de cette page, vous devriez savoir :

Sélectionner et router/mettre en cascade au sein du portefeuille de modèles (Fable 5.1, Opus 5, Sonnet 5, Haiku 4.5) avec un vrai calcul de coût.
Gérer les changements incompatibles entre versions de modèles (règles des thinking blocks, paramètres supprimés).
Traiter les system prompts, templates et garde-fous comme des actifs gouvernés et versionnés.
Appliquer les techniques de prompting (zero-shot, few-shot, CoT, thinking étendu/adaptatif, effort) à la bonne altitude.
Optimiser la fenêtre de contexte et les tokens.
Concevoir une architecture de caching (préfixe stable d’abord, prompts modulaires, Skills) et un processus de versionnement/déploiement.
Respecter les contraintes du harnais append-only de Fable 5.1.

2.1 The model portfolio and routing

Il n’y a pas de « meilleur » modèle unique — il y a un portefeuille, et le rôle de l’architecte est de router chaque requête vers le modèle le moins cher qui atteint sa barre de qualité.

Modèle	ID	Contexte / sortie max	In / out par MTok	Quand c’est le bon défaut
Fable 5.1	`claude-fable-5-1`	1M / 128k	$10 / $50	Raisonnement frontier ; thinking toujours actif ; harnais append-only ; rétention 30 jours
Opus 5	`claude-opus-5`	1M / 128k	$5 / $25	Coding agentique complexe et travail d’entreprise
Sonnet 5	`claude-sonnet-5`	1M / 128k	$2 / $10	Meilleur équilibre vitesse/intelligence ; défaut général
Haiku 4.5	`claude-haiku-4-5`	200k / 64k	$1 / $5	Le plus rapide/le moins cher ; tâches à fort volume, sensibles à la latence, étroites

Routage et cascades

Routage statique : règles par type de tâche/segment (extraction → Haiku, synthèse → Sonnet, coding le plus dur → Opus/Fable).
Cascade : essayer d’abord le moins cher ; escalader sur l’échec d’une vérification de validation/qualité, non sur la confiance auto-déclarée.

Signal d’examen

« Le coût est 4× le budget mais la qualité est bonne » → introduire une cascade (moins cher d’abord, escalade sur échec de vérification). « Il nous faut la capacité la plus récente et le coût est secondaire » → Opus 5 / Fable 5.1. Les distracteurs qui escaladent sur la confiance auto-déclarée sont faux (anti-patron n° 4).

Exemple chiffré de calcul de coût

100k requêtes/jour, ~3k d’entrée + 1k de sortie tokens chacune.

Stratégie	Coût quotidien (approx.)	Note
Tout Opus 5	100k × (3k×$5 + 1k×$25)/1e6 = 100k × $0.040 = $4,000	référence
Tout Sonnet 5	100k × (3k×$2 + 1k×$10)/1e6 = 100k × $0.016 = $1,600	60 % moins cher
Cascade : 80 % Haiku, 20 % Opus	80k×$0.008 + 20k×$0.040 = $1,440	qualité préservée sur les 20 % difficiles
Sonnet + cache (80 % de hit sur un préfixe de 2k)	~$960	lecture de cache ≈ 0,1× de l’entrée

2.2 Managing breaking changes across versions

Les ID de modèles à partir de 4.6 sont sans date mais restent des snapshots figés. Mettre à niveau un modèle peut changer le comportement et casser du code qui reposait sur des paramètres supprimés.

Changement	Concernés	Action de migration
`budget_tokens` supprimé (renvoie 400)	Fable 5.x, Opus 5, Sonnet 5, Opus 4.7–4.8	Utilisez `thinking: {"type": "adaptive"}` et `effort` ; seul Haiku 4.5 utilise encore `budget_tokens`
L’usage forcé d’outils renvoie 400 sur Fable 5.1	Fable 5.1	`tool_choice:"any"` / `{"type":"tool"}` forcé → utilisez `auto` + instruction, `strict:true`, ou les sorties structurées
Thinking blocks lisibles seulement par le modèle producteur ou plus récent	tous les modèles à thinking	Ne repliez jamais silencieusement vers un modèle plus ancien en cours de session
Opus 4.1 retiré le 2026-08-05	épinglé sur 4.1	Ré-épinglez et relancez la suite d’éval/régression

Relancez toujours la suite de régression (D4) avant de promouvoir un changement de modèle. Utilisez client.models.list() / .retrieve(id) pour confirmer les limites en vigueur.

2.3 Prompts and guardrails as governed assets

Au niveau Professional, un system prompt est un actif organisationnel partagé, non une chaîne dans le carnet de quelqu’un. Gouvernez-le comme du code.

Propriété	Pratique
Versionné	Stocké en VCS avec version sémantique ; changements revus
Testable	Chaque version tourne contre le golden eval set avant release
Modulaire	Composé de blocs stables (rôle, politique, format) + blocs volatils (tâche)
Doté de garde-fous	Règles de sûreté et métier en couches, non enfouies dans la prose
Déployé	Canary → pourcentage → complet, avec rollback

Anti-patron du prompt comme mécanisme d’application

Les règles métier critiques (« ne jamais émettre un remboursement supérieur à 500 $ ») doivent être appliquées programmatiquement (hooks de permission d’outil, validation), non par une phrase dans le system prompt. On peut convaincre un modèle de contourner des règles en prose ; pas un hook. Les options qui reposent sur la formulation du prompt pour appliquer une règle ferme sont fausses (anti-patron n° 3).

2.4 Prompting techniques at the right altitude

Technique	À utiliser quand	Note coût/latence
Zero-shot	La tâche est courante et bien spécifiée	Le moins cher
Few-shot	La forme/le format de sortie doit être fixé ; cas limites montrés	Ajoute des tokens d’entrée (cachez les exemples)
Chain-of-thought	Le raisonnement doit être explicite (modèles anciens/sans thinking)	Plus de tokens de sortie
Thinking étendu / adaptatif	Raisonnement difficile ; `thinking:{"type":"adaptive"}` sur les modèles actuels	Tokens de thinking facturés comme sortie
Effort (`low\|medium\|high\|xhigh`)	Régler la profondeur de raisonnement vs le coût ; `xhigh` pour le coding/agentique le plus dur sur Opus 5 / Fable 5.1	Effort plus élevé = plus de tokens/latence
Fast mode	Usage sensible à la latence	Échange de la profondeur contre de la vitesse

Sur les modèles actuels, préférez le thinking adaptatif + effort aux budgets manuels. Seul Haiku 4.5 accepte encore budget_tokens et n’a pas de paramètre effort.

2.5 Context-window and token optimisation

Une fenêtre de 1M tokens est un budget, non une cible. La remplir augmente le coût et la latence et peut réduire la justesse (dégradation du needle-in-haystack).

Levier	Effet
Récupérer, ne pas bourrer	N’envoyer que les chunks pertinents (RAG, D3) plutôt que des corpus entiers
Prompt caching	Amortir le préfixe stable ; lecture de cache ≈ 0,1× de l’entrée
Context editing	Effacer les résultats d’outils périmés de la fenêtre
Compaction	Résumé côté serveur préservant le fil pour les longues sessions
Réduction de sortie	Demander le schéma nécessaire ; éviter la prose verbeuse
Sorties structurées	Moins de tokens gaspillés que la forme libre + re-parsing

2.6 Caching architecture: stable-prefix-first

Le prompt caching n’aide que si le préfixe de cache est stable. Ordonnez le contenu du plus stable d’abord : system prompt → outils → longs documents → exemples few-shot → tour utilisateur volatil. Marquez la frontière stable avec cache_control.

Écriture de cache ≈ 1,25× (TTL 5 min) ou 2× (TTL 1 h) ; lecture de cache ≈ 0,1× de l’entrée de base.
Préfixe minimal cachable ~1024 tokens (2048 sur Haiku).
Placer quoi que ce soit de volatil avant le contenu stable invalide le cache à chaque appel — une erreur classique.

Prompts modulaires + Skills : gardez les blocs de capacité réutilisables sous forme de Skills (SKILL.md, chargées progressivement à la demande) plutôt que de tout coller dans chaque prompt. Cela garde le préfixe cachable stable et le contexte allégé.

2.7 Prompt versioning and rollout

Traitez chaque prompt comme name@semver. Stockez-le en VCS. Consignez la version de modèle contre laquelle il a été validé — un prompt réglé pour Opus 5 n’est pas garanti de se comporter pareil sur Haiku 4.5. Étiquetez les scores d’éval atteints.

2.8 Fable 5.1 append-only harness constraints

Fable 5.1 a le thinking toujours actif, et ses thinking blocks ne sont lisibles que par le modèle producteur (ou un plus récent). Éditer, réordonner ou supprimer des tours antérieurs invalide les thinking blocks ultérieurs. Par conséquent, les harnais doivent être append-only.

Règle	Conséquence si violée
Figer `system` et `tools` après le démarrage de la session	Les éditer invalide le thinking en aval
Placer les changements en cours de session dans un message `role: "system"` (ajouter, ne pas éditer)	Réécrire l’historique casse la boucle
Élaguer côté serveur via context editing / compaction, non en supprimant des tours côté client	La suppression côté client invalide les thinking blocks
Ne jamais forcer l’usage d’outils (`tool_choice:"any"` / outil forcé) — renvoie 400	La requête échoue ; utilisez `auto` + instruction / `strict` / sorties structurées
Ne jamais replier silencieusement vers un modèle plus ancien	Le modèle plus ancien supprime les thinking blocks

Sonnet 5 diffère

Sonnet 5 ne prend pas en charge les messages système en cours de conversation et n’a pas de budgets de tâche. Ne supposez pas que l’astuce d’ajout de message système de Fable fonctionne à l’identique sur Sonnet 5 — l’examen teste ces différences par modèle.

2.9 Arithmétique du coût du prompt caching

Le caching ne paie que lorsque vous pouvez le quantifier. Lecture ≈ 0,1× de l’entrée de base ; écriture ≈ 1,25× (TTL 5 min) ou 2× (TTL 1 h) ; préfixe minimal cachable ~1024 tokens (2048 sur Haiku).

Exemple chiffré. Sonnet 5, préfixe stable de 4 000 tokens ($2/MTok en entrée), tour volatil de 500 tokens, 10 000 requêtes/jour, taux de cache-hit de 90 % après le warm-up.

Signal d’examen

Le caching aide proportionnellement à la taille du préfixe × le taux de hit. Un préfixe minuscule ou un taux de hit faible (parce qu’un token volatil se trouve dans le préfixe) rend le caching inutile. Si un énoncé dit « le taux de hit est proche de zéro », cherchez un élément volatil avant la frontière de cache — non « désactiver le caching ».

Symptôme	Cause	Correctif
Taux de hit proche de zéro	Contenu volatil avant la frontière ; timestamp/user-id par requête dans le préfixe	Déplacer le contenu volatil après la frontière `cache_control`
Le coût d’écriture domine	Le préfixe est rarement réutilisé dans le TTL	Utiliser le TTL 1 h, ou ne pas cacher les préfixes à faible réutilisation
Aucun effet sur Haiku	Préfixe sous le minimum de 2048 tokens	Consolider le contexte stable ou accepter l’absence de caching

2.10 Structured outputs and schema enforcement

Au niveau Professional, « parser la prose » n’est jamais la réponse. Utilisez output_config.format avec un JSON schema et strict: true pour que la sortie du modèle soit conforme par construction, et réservez la validation-retry au rare raté.

Approche	Fiabilité	Quand
Texte libre + regex/parsing	Fragile	Jamais pour des données structurées
Prompt « renvoyer du JSON » seul	Mieux, mais faillible	Chemins legacy/non pris en charge
JSON schema `strict` (sorties structurées)	Conforme par construction	Défaut pour la sortie consommée par machine
Schéma d’outil avec `strict: true`	Arguments d’outil imposés	Quand un outil a besoin d’arguments typés

Signal d’examen

Sur Fable 5.1, vous ne pouvez pas forcer l’usage d’outils (tool_choice:"any" → 400). Pour garantir une forme, utilisez les sorties structurées / le schéma strict ou auto + instruction — l’examen associe le besoin de « JSON garanti » à la contrainte « pas d’outils forcés sur Fable ».

2.11 Context editing vs compaction

Les sessions de longue durée débordent la fenêtre. Deux outils côté serveur la gèrent, et ils ne sont pas interchangeables.

Technique	Ce qu’elle fait	À utiliser quand	Risque en cas de mauvais usage
Context editing	Retire/efface les résultats d’outils et blocs périmés de la fenêtre	Les sorties d’outils sont volumineuses et devenues inutiles	Éditer des tours antérieurs invalide les thinking blocks de Fable 5.1 — éditez les résultats d’outils, pas le raisonnement
Compaction	Résumé côté serveur préservant le fil narratif	Sessions très longues où l’historique doit être conservé en substance	La sur-compaction perd du détail nécessaire plus tard
Memory tool	Persiste des faits durables hors de la fenêtre	Les faits doivent survivre entre sessions	Stocker des secrets/PII de façon inappropriée

Préférez l’élagage côté serveur (context editing / compaction) à la suppression côté client des tours, qui casse les invariants du harnais append-only (2.8). Le hook PreCompact vous permet de capturer l’état avant l’exécution de la compaction.

2.12 Scénario détaillé : maîtriser une facture de prompt-et-modèle emballée

Scénario. Un produit d’analyse de documents exécute chaque requête sur Opus 5 avec effort: xhigh, un system prompt de 9k tokens dupliqué par appel, et l’usage forcé d’outils. La dépense mensuelle est 5× le budget ; l’équipe vient aussi d’échouer un pilote Fable 5.1 avec des erreurs 400. La qualité est acceptable ; la latence n’est pas le grief — c’est le coût.

Trace de raisonnement d’expert.

Dimensionner correctement le modèle. La qualité est déjà acceptable sur Opus 5, donc l’essentiel du trafic peut tourner sur Sonnet 5 avec une cascade escaladant vers Opus 5 seulement sur l’échec d’une vérification de validation. Cela seul réduit le tarif par requête de ~60 %.
Corriger l’effort. xhigh partout est du gaspillage ; passez à high/medium et relancez la suite de régression par segment pour confirmer l’absence de baisse.
Cacher le préfixe. Le system prompt de 9k tokens est stable → marquez une frontière cache_control ; déplacez le document par requête après lui. Les lectures à 0,1× rendent le préfixe quasi gratuit à un taux de hit élevé.
Modulariser avec des Skills. Le texte de capacité dupliqué appartient à des Skills chargées à la demande, gardant le préfixe caché allégé et stable.
Expliquer les 400 de Fable. L’usage forcé d’outils n’est pas pris en charge sur Fable 5.1 ; passez à auto + instruction ou aux sorties structurées. Notez toutefois que le tarif $10/$50 de Fable en fait de toute façon le mauvais choix de coût ici.
Re-valider et déployer. Régression offline par segment → canary → montée en charge, version antérieure à chaud pour rollback.

Pourquoi les alternatives tentantes sont fausses : « tout passer sur Haiku » risque la barre de qualité ; « escalader sur la confiance auto-déclarée » est l’anti-patron n° 4 ; « acheter simplement un budget plus gros » ignore le calcul ; « continuer à forcer les outils et réessayer » ne peut pas corriger un 400.

2.13 Common misconceptions

Idée reçue	Réalité	Pourquoi c’est important à l’examen
« `budget_tokens` est la façon standard de contrôler le thinking. »	Supprimé sur les modèles actuels (400) ; seul Haiku 4.5 l’utilise encore. Utilisez le thinking adaptatif + `effort`.	Un énoncé « 400 après mise à niveau » teste exactement ceci.
« Une phrase forte du system prompt applique une règle métier. »	Les prompts sont de l’orientation ; les règles fermes nécessitent des hooks/validation.	Le prompt comme mécanisme d’application est une mauvaise réponse récurrente.
« Un effort plus élevé signifie toujours de meilleures réponses. »	Au-delà du besoin de la tâche, cela ajoute juste tokens/latence/coût.	Les distracteurs « xhigh partout » surdépensent.
« Le caching économise automatiquement de l’argent une fois activé. »	Seulement si le préfixe est stable et réutilisé au-dessus de la taille minimale.	Les énoncés à préfixe volatil rendent le caching inutile.
« Forcer l’usage d’outils fonctionne sur tout modèle. »	Fable 5.1 renvoie 400 sur l’usage forcé d’outils.	Les énoncés de forme garantie s’associent aux sorties structurées.
« Un prompt réglé sur Opus se comporte pareil sur Haiku. »	Le comportement diffère par modèle ; re-validez par modèle.	La réutilisation cross-model sans ré-éval est le piège.
« On peut élaguer une longue session en supprimant les anciens tours côté client. »	Sur les modèles à thinking cela invalide les thinking blocks ultérieurs ; élaguez côté serveur.	Les règles du harnais append-only sont testées par modèle.

Pièges de l’examen dans ce domaine

Piège	Pourquoi c’est faux
Utiliser le modèle le plus cher pour chaque requête	Ignore le routage/les cascades ; fait exploser le budget de coût
Escalader dans une cascade sur la confiance auto-déclarée	L’auto-déclaration n’est pas fiable (anti-patron n° 4) ; escaladez sur l’échec de validation
Appliquer une règle métier ferme via le system prompt	Prompt comme mécanisme d’application (anti-patron n° 3) ; utilisez hooks/validation
Fixer `budget_tokens` sur Opus 5 / Sonnet 5 / Fable 5.1	Supprimé ; renvoie 400 — utilisez le thinking adaptatif + effort
Forcer l’usage d’outils sur Fable 5.1	Renvoie 400 ; utilisez `auto`+instruction, `strict`, ou sorties structurées
Éditer des tours antérieurs dans une session Fable 5.1	Invalide les thinking blocks ultérieurs ; le harnais doit être append-only
Replier silencieusement vers un modèle plus ancien en cours de session	Supprime les thinking blocks ; corrompt la session
Placer le tour utilisateur volatil avant le préfixe caché	Invalide le cache à chaque appel
Remplir la fenêtre de 1M « parce qu’elle est disponible »	Augmente coût/latence ; peut réduire la justesse ; récupérez plutôt
Supposer qu’un prompt réglé sur un modèle se comporte à l’identique sur un autre	Doit être re-validé par version de modèle
Parser la prose en texte libre pour des données structurées au lieu d’un schéma `strict`	Fragile ; les sorties structurées sont conformes par construction
Supprimer les anciens tours côté client pour élaguer une session à thinking	Invalide les thinking blocks ultérieurs ; utilisez context editing/compaction
Supposer que le caching économise quelle que soit la taille du préfixe ou le taux de hit	Économie ∝ taille du préfixe × taux de hit ; un préfixe volatil donne ~0
Stocker secrets/PII dans le memory tool ou le contexte persisté	Risque d’exfiltration/conformité ; gardez les secrets dans des gestionnaires de secrets
Monter l’`effort` à `xhigh` pour « améliorer la qualité » sans preuve	Ajoute tokens/latence/coût au-delà du besoin de la tâche

Questions d’entraînement

Q1 · Un pipeline route tout vers Opus 5. Le coût est 4× le budget ; la qualité est acceptable. Quel changement réduit le mieux le coût tout en préservant la qualité sur les cas difficiles ? (Sélectionnez une réponse)

A. Déplacer tout le trafic vers Haiku 4.5. B. Construire une cascade : Haiku 4.5 / Sonnet 5 d’abord, escalader vers Opus 5 seulement quand une vérification de validation de sortie échoue, et cacher le préfixe stable. C. Escalader vers Opus 5 chaque fois que le modèle déclare une faible confiance dans sa propre réponse. D. Augmenter l’effort à xhigh partout.

Réponse : B. Le moins cher d’abord avec escalade sur l’échec de validation préserve la qualité sur les cas difficiles tandis que l’essentiel du trafic tourne à bas coût ; le caching amortit le préfixe stable. Haiku partout (A) sacrifie la qualité. La confiance auto-déclarée (C) est un anti-patron. Monter l’effort partout (D) augmente le coût.

Q2 · Une équipe migre d’Opus 4.6 vers Opus 5 et ses requêtes renvoient désormais des erreurs 400. Les requêtes fixent `budget_tokens` pour le thinking. Quel est le correctif ? (Sélectionnez une réponse)

A. Ajouter plus de retries. B. Remplacer budget_tokens par thinking: {'type': 'adaptive'} et contrôler la profondeur via effort, puisque budget_tokens est supprimé sur Opus 5. C. Rétrograder définitivement vers Haiku 4.5. D. Supprimer entièrement le thinking.

Réponse : B. budget_tokens est supprimé sur Opus 5 (et Sonnet 5 / Fable 5.x) et renvoie 400 ; le thinking adaptatif plus effort est le remplacement pris en charge. Les retries (A) ne corrigeront pas un 400. Haiku (C) est le seul modèle utilisant encore budget_tokens mais n’est pas un équivalent pour les charges Opus. Supprimer le thinking (D) élimine le raisonnement nécessaire.

Q3 · Un agent de remboursement ne doit jamais émettre de remboursements supérieurs à 500 $. Où cette règle doit-elle résider ? (Sélectionnez une réponse)

A. Comme une phrase fermement formulée dans le system prompt. B. Comme un hook programmatique de permission d’outil / une validation qui rejette tout remboursement supérieur à 500 $ avant exécution. C. Comme un exemple few-shot montrant un gros remboursement refusé. D. Dans le budget de thinking du modèle.

Réponse : B. Les règles métier fermes exigent une application programmatique — un hook ou une validation que le modèle ne peut pas contourner par le discours. La formulation du prompt (A) et les exemples few-shot (C) sont des anti-patrons du prompt comme mécanisme d’application. Le budget de thinking (D) est sans rapport.

Q4 · Le prompt caching est activé mais le taux de hit est proche de zéro. Le prompt place d’abord la question de l’utilisateur, puis le system prompt et les documents de référence. Pourquoi, et quel est le correctif ? (Sélectionnez une réponse)

A. Le caching est cassé ; désactivez-le. B. Le tour utilisateur volatil se trouve avant le contenu stable, donc le préfixe caché change à chaque appel — réordonnez en stable-d’abord (system → outils → docs) puis le tour utilisateur, et marquez la frontière stable avec cache_control. C. Les documents sont trop courts. D. Haiku ne prend pas en charge le caching.

Réponse : B. Le caching s’appuie sur un préfixe stable ; placer le tour utilisateur changeant en premier l’invalide à chaque appel. Le préfixe stable d’abord avec une frontière cache_control corrige cela. Le caching n’est pas cassé (A) ; la longueur du document (C) ne compte que pour le minimum de ~1024 tokens ; Haiku prend en charge le caching (D) avec un minimum de 2048 tokens.

Q5 · Quelles sont des raisons valables de NE PAS bourrer tout un corpus de 500k tokens dans la fenêtre de 1M à chaque requête ? (Sélectionnez deux réponses)

A. Coût en tokens et latence plus élevés par appel. B. Possible dégradation de la justesse pour localiser le needle pertinent. C. La fenêtre ne peut physiquement pas le contenir. D. Les sorties structurées sont désactivées au-dessus de 200k tokens. E. Le caching est interdit sur les grandes entrées.

Réponse : A et B. Le bourrage augmente coût et latence et peut nuire à la justesse de récupération dans un contexte énorme ; la récupération (RAG) n’envoie que les chunks pertinents. Cela tient dans la fenêtre (C est faux à 500k sur 1M), les sorties structurées ne sont pas bornées par la taille de cette façon (D), et le caching est autorisé sur les grandes entrées (E).

Q6 · Dans une session agentique Fable 5.1 active, l’équipe veut changer les instructions système en cours d’exécution. Quelle est la bonne approche ? (Sélectionnez une réponse)

A. Éditer le champ system original sur place. B. Ajouter le changement comme un nouveau message role: 'system', en laissant les tours antérieurs intacts, car le harnais doit être append-only. C. Supprimer les tours les plus anciens pour faire de la place. D. Réordonner les messages pour placer la nouvelle instruction en premier.

Réponse : B. Les thinking blocks de Fable 5.1 sont invalidés par l’édition/le réordonnancement/la suppression des tours antérieurs, donc les changements en cours de session sont ajoutés comme un nouveau message système. Éditer sur place (A), supprimer des tours (C) et réordonner (D) invalident tous les thinking blocks en aval.

Q7 · Une équipe veut forcer Fable 5.1 à toujours renvoyer un appel d’outil en fixant tool_choice à any. Cela renvoie 400. Que doit-elle faire ? (Sélectionnez une réponse)

A. Réessayer jusqu’à ce que ça marche. B. Utiliser tool_choice: 'auto' avec une instruction d’utiliser l’outil, fixer strict: true sur le schéma d’outil, ou utiliser les sorties structurées — car l’usage forcé d’outils n’est pas pris en charge sur Fable 5.1. C. Basculer définitivement vers Haiku 4.5. D. Supprimer tous les outils.

Réponse : B. L’usage forcé d’outils (any / outil forcé) renvoie 400 sur Fable 5.1 ; les chemins pris en charge sont auto + instruction, les schémas strict, ou les sorties structurées. Réessayer (A) ne corrigera pas un 400. Changer de modèle (C) ou supprimer les outils (D) abandonne l’exigence.

Q8 · Comment une nouvelle version de system prompt doit-elle être déployée en production ? (Sélectionnez une réponse)

A. La remplacer à l’échelle de l’organisation immédiatement pour aller vite. B. Valider offline contre le golden set, canary sur une petite tranche de trafic avec des garde-fous de régression, monter en charge par pourcentage, et garder la version antérieure à chaud pour un rollback instantané. C. Laisser chaque ingénieur éditer le prompt inline dans son propre service. D. La livrer et surveiller les plaintes clients.

Réponse : B. Les prompts sont des actifs gouvernés et versionnés : éval offline → canary → montée en charge → conserver la version antérieure pour rollback. Les remplacements à l’échelle de l’organisation (A) et la surveillance pilotée par les plaintes (D) sautent la validation. Les éditions inline par ingénieur (C) détruisent la gouvernance et la reproductibilité.

Q9 · Une sous-tâche d’extraction à fort volume alimente une étape de synthèse plus lente. Quelle affectation de portefeuille est la MEILLEURE ? (Sélectionnez une réponse)

A. Opus 5 pour les deux étapes. B. Haiku 4.5 pour l’extraction à fort volume ; Sonnet 5 ou Opus 5 pour la synthèse — en accordant le coût du modèle à la difficulté de chaque étape. C. Fable 5.1 pour les deux, pour une qualité maximale. D. Haiku 4.5 pour les deux, pour une économie maximale.

Réponse : B. Le routage de portefeuille affecte le modèle adéquat le moins cher par étape : Haiku pour l’extraction étroite à fort volume, un modèle plus fort pour la synthèse plus difficile. Opus/Fable pour les deux (A, C) surpaie ; Haiku pour les deux (D) risque la qualité de la synthèse.

Q10 · Des blocs de capacité réutilisables sont collés dans chaque prompt, gonflant le contexte et cassant le préfixe de cache. Quel est le meilleur patron ? (Sélectionnez une réponse)

A. Les packager comme des Skills (SKILL.md) chargées progressivement à la demande, gardant le préfixe cachable stable et allégé. B. Les dupliquer dans le prompt de chaque service. C. Les déplacer dans le tour utilisateur volatil. D. Augmenter la fenêtre de contexte.

Réponse : A. Les Skills chargent la capacité progressivement à la demande, gardant le contexte allégé et le préfixe de cache stable. La duplication (B) est ce qui a causé le gonflement ; les déplacer dans le tour volatil (C) aggrave le caching ; une fenêtre plus grande (D) ne traite ni le coût ni la stabilité du cache.

Q11 · Quel énoncé sur la configuration du thinking des modèles actuels est correct ? (Sélectionnez une réponse)

A. Tous les modèles actuels requièrent budget_tokens. B. Les modèles actuels utilisent thinking: {'type':'adaptive'} avec des niveaux d’effort low/medium/high/xhigh ; seul Haiku 4.5 utilise encore budget_tokens et n’a pas de paramètre effort. C. L’effort n’existe que sur Haiku 4.5. D. L’effort xhigh est le défaut sur tous les modèles.

Réponse : B. Le thinking adaptatif plus l’effort est standard sur les modèles actuels ; Haiku 4.5 est l’exception, utilisant encore budget_tokens et dépourvu d’effort. budget_tokens n’est pas universel (A) ; l’effort n’est pas propre à Haiku (C) ; high (pas xhigh) est le défaut (D).

Q12 · Un prompt validé sur Opus 5 est réutilisé tel quel sur Haiku 4.5 et la qualité chute. Quelle est la bonne leçon ? (Sélectionnez une réponse)

A. Haiku 4.5 est défectueux. B. Les prompts sont validés par version de modèle ; un prompt réglé pour un modèle doit être re-testé (et souvent ajusté) contre le golden set sur tout autre modèle avant usage. C. Toujours utiliser Opus 5. D. Les chutes de qualité sont inévitables et doivent être ignorées.

Réponse : B. Le comportement du modèle diffère au sein du portefeuille, donc les versions de prompt portent le modèle contre lequel elles ont été validées et doivent être ré-évaluées lors d’une réutilisation ailleurs. Haiku n’est pas défectueux (A) ; imposer Opus (C) ignore le coût ; ignorer les régressions (D) est une négligence.

Q13 · Un préfixe stable de 4 000 tokens sur Sonnet 5 est réutilisé avec un taux de cache-hit de 90 % à 10 000 req/jour. Qu’économise approximativement le caching sur le coût d’entrée ? (Sélectionnez une réponse)

A. Rien ; le caching n’aide jamais les grands préfixes. B. Environ 70 %, car une lecture de cache est ~0,1× de l’entrée, donc le préfixe de 4k devient ~400 tokens effectifs sur les hits. C. Exactement 50 %, la remise Batch. D. 100 % ; les requêtes cachées sont gratuites.

Réponse : B. Une lecture ≈ 0,1× de l’entrée transforme les 4 000 tokens du préfixe en ~400 sur les 90 % de hits ; le coût d’entrée quotidien tombe de ~$90 à ~$27, soit environ 70 %. Le caching aide bien les grands préfixes stables (A) ; 50 % est la remise Batch, pas le caching (C) ; les lectures cachées sont peu chères, pas gratuites (D).

Q14 · Un pipeline doit renvoyer un objet JSON strictement typé pour des systèmes en aval, et il tourne sur Fable 5.1 où forcer l’usage d’outils renvoie 400. Quelle est la MEILLEURE approche ? (Sélectionnez une réponse)

A. Forcer un appel d’outil avec tool_choice: 'any' et réessayer sur 400. B. Utiliser les sorties structurées avec un JSON schema strict (ou auto + instruction), ce qui garantit la forme sans forcer l’usage d’outils. C. Demander du JSON dans le prompt et regex-parser la prose. D. Passer au texte libre et re-parser.

Réponse : B. Les sorties structurées avec un schéma strict sont conformes par construction et n’exigent pas d’usage forcé d’outils, que Fable 5.1 rejette avec 400. Forcer les outils (A) échoue ; le JSON par prompt seul avec regex (C) et le re-parsing en texte libre (D) sont du parsing de prose fragile.

Q15 · Une longue session agentique sur un modèle à thinking déborde la fenêtre parce que les résultats d’outils sont énormes. Quelle technique est correcte, et que faut-il éviter ? (Sélectionnez une réponse)

A. Supprimer les tours utilisateur/assistant les plus anciens côté client. B. Utiliser le context editing pour effacer les résultats d’outils périmés côté serveur (et la compaction pour le fil narratif), en évitant les éditions côté client du raisonnement antérieur qui invalident les thinking blocks. C. Baisser la température pour rétrécir le contexte. D. Forcer le modèle à se résumer lui-même dans le même tour.

Réponse : B. Le context editing retire les résultats d’outils périmés côté serveur ; la compaction résume le fil narratif — les deux évitent d’invalider les thinking blocks. Supprimer des tours côté client (A) casse l’invariant append-only ; la température (C) n’affecte pas la taille du contexte ; l’auto-résumé dans le tour (D) ne récupère pas la fenêtre.

Q16 · Une équipe exécute chaque requête sur Opus 5 à `effort: xhigh` avec une qualité acceptable et 5× le budget ; le grief est le coût, non la latence. Quels DEUX changements réduisent le mieux le coût tout en préservant la qualité ? (Sélectionnez deux réponses)

A. Mettre en cascade l’essentiel du trafic vers Sonnet 5, en escaladant vers Opus 5 seulement sur l’échec d’une vérification de validation. B. Baisser l’effort à un niveau adéquat et relancer la suite de régression par segment. C. Escalader sur la confiance auto-déclarée du modèle. D. Déplacer tout le trafic vers Fable 5.1 pour la qualité. E. Supprimer la suite d’évals pour réduire le calcul.

Réponse : A et B. Une cascade moins-cher-d’abord et un effort correctement dimensionné (re-validé par segment) réduisent le coût tout en préservant la qualité sur les cas difficiles. L’auto-déclaration (C) est l’anti-patron n° 4 ; Fable 5.1 (D) est le modèle le plus cher ; supprimer les évals (E) retire la garde de qualité.

Q17 · Le caching est activé mais le taux de hit est de ~3 %. L’investigation montre qu’une chaîne `request_id` par requête est préfixée au system prompt. Quel est le correctif ? (Sélectionnez une réponse)

A. Désactiver le caching ; il ne fonctionne pas ici. B. Retirer le request_id volatil du préfixe (le journaliser séparément) pour que le préfixe soit stable au byte près, restaurant les cache hits. C. Raccourcir les documents. D. Augmenter la fenêtre de contexte.

Réponse : B. Un token par requête dans le préfixe le change à chaque appel, donc rien ne se cache ; le sortir restaure un préfixe stable. Le caching n’est pas cassé (A) ; la longueur du document (C) n’affecte que le minimum ; une fenêtre plus grande (D) est sans rapport.

Q18 · Un fait durable (le palier de contrat d’un client) doit persister entre des sessions séparées sans le renvoyer dans chaque prompt. Quel mécanisme convient, et quelle contrainte s’applique ? (Sélectionnez une réponse)

A. Coller le fait dans chaque system prompt. B. Utiliser le memory tool pour persister le fait entre sessions, mais ne jamais y stocker de secrets/PII de façon inappropriée et le tenir hors des logs visibles par le modèle. C. Le stocker dans CLAUDE.local.md. D. Augmenter la rétention pour le garder dans les logs du fournisseur.

Réponse : B. Le memory tool persiste des faits durables entre sessions ; la contrainte est de ne pas y stocker de secrets/PII de façon inappropriée. Coller par prompt (A) gonfle le contexte ; CLAUDE.local.md (C) est un fichier de développement de Claude Code, non un store runtime ; s’appuyer sur la rétention du fournisseur (D) n’est pas un mécanisme de mémoire et augmente le risque de conformité.

À retenir

Gérez un portefeuille : routez/mettez en cascade vers le modèle le moins cher qui franchit la barre de qualité ; escaladez sur l’échec de validation, non sur la confiance auto-déclarée.
Faites le calcul de coût — cascades et caching réduisent couramment la dépense de 60–75 % avec la qualité préservée sur les cas difficiles.
Gérez les changements incompatibles : budget_tokens supprimé (400) sauf sur Haiku 4.5 ; l’usage forcé d’outils échoue sur Fable 5.1 ; relancez les régressions avant de promouvoir un modèle.
Traitez prompts et garde-fous comme des actifs versionnés et gouvernés ; appliquez les règles fermes programmatiquement, jamais via la prose du prompt.
Utilisez le thinking adaptatif + effort ; réservez xhigh au travail Opus/Fable le plus dur.
Cachez le préfixe stable d’abord ; gardez les blocs réutilisables comme des Skills ; ne placez jamais de contenu volatil avant le préfixe caché.
Les harnais Fable 5.1 sont append-only : figez system/outils, ajoutez des messages système, élaguez côté serveur, ne forcez jamais les outils et ne rétrogradez jamais silencieusement.
Économie du caching ∝ taille du préfixe × taux de hit ; un token volatil dans le préfixe (timestamps, request IDs) fait tomber le taux de hit à ~0 — retirez-le, ne désactivez pas le caching.
Garantissez la forme de sortie avec les sorties structurées / schémas strict, surtout sur Fable 5.1 où l’usage forcé d’outils renvoie 400 — ne parsez jamais la prose.
Gérez les longues sessions avec le context editing (effacer les résultats d’outils périmés) et la compaction (résumer le fil narratif) côté serveur ; le memory tool persiste des faits durables (pas de secrets/PII).