Ingénierie du prompt et du contexte

Le cadrage d’Anthropic, que l’examen a absorbé en entier : l’ingénierie de prompt a grandi en ingénierie de contexte. L’unité de conception n’est plus l’instruction — c’est tout ce que le modèle voit dans une requête : prompt système, définitions d’outils, documents retrouvés, images, tout l’historique de conversation, et la réponse elle-même, qui devient l’entrée du tour suivant.

Comment lire cette page, parce qu’elle vous dit ce qu’il faut mémoriser : le numéro du domaine et la pondération de 11 % viennent tout droit du guide officiel de l’examen, et les idées exigibles sont rassemblées dans l’encadré à la fin de chaque section. Les faits propres aux modèles ont été vérifiés auprès de la documentation officielle en septembre 2026 — ceux susceptibles de changer entre deux éditions sont estampillés « à jour de septembre 2026 », et ce sont les seuls qui valent la peine d’être revérifiés la semaine où vous le passez.

01La fenêtre est un budget, pas un seau

Tout dans la requête s’impute sur la fenêtre : le prompt système, chaque message, résultats d’outils compris, les définitions d’outils, les images et documents (jusqu’à 600 pages d’image ou de PDF par requête sur les modèles à 1M de tokens, 100 sur ceux à 200K — les limites de taille de requête peuvent mordre avant les limites de tokens), la sortie, tokens de réflexion compris — et — le fait que l’on refuse de croire — les préfixes mis en cache.

Le cache change ce que vous payez, pas ce qui compte : 2 000 tokens frais plus 180 000 tokens lus dans le cache sur un modèle 200K, et la fenêtre est presque pleine.

Pourquoi ne pas la remplir ? Le context rot : à mesure que le compte de tokens croît, l’attention s’étale plus finement (le nombre de relations par paires croît avec le carré de la longueur), et la précision et le rappel se dégradent graduellement.

Le mode d’échec sur le terrain est plus discret qu’une erreur de limite : un agent qui a lu quarante fichiers et s’est mis à répondre vaguement alors que la fenêtre était à moitié vide — résultats d’outils périmés et raisonnements finis qui se disputent l’attention bien avant qu’une limite ne soit atteinte. Traitez le contexte comme un budget à dépenser délibérément sur ce que le prochain tour exige vraiment.

02Gérer un contexte long

La boîte à outils a une partition nommée sur lequel l’examen s’appuie : l’élagage nettoie le contenu périmé après son arrivée ; l’isolation l’empêche d’arriver. Tous les outils en une comparaison — avec le détail que l’examen vérifie sur chacun :

Quand un scénario vous tend un symptôme et demande la stratégie, déroulez le cadre de décision le plus simple : la session est longue et doit continuer comme une seule conversation — compaction. Les anciens résultats d’outils et réflexions sont ce qui fait gonfler — édition de contexte. Le travail génère un bruit dont la conversation parent n’a jamais besoin — délégation ou appels d’outils programmatiques. La connaissance doit survivre à la session — l’outil mémoire.

03Blocs de réflexion : ce qui reste, ce qui repart

Que les anciens blocs de réflexion restent dans la fenêtre dépend du modèle — à jour de septembre 2026. Opus 4.5 et suivants et Sonnet 4.6 et suivants les gardent par défaut, où ils comptent comme entrée ordinaire à chaque requête suivante. Les Opus et Sonnet antérieurs, et tous les Haiku, les retirent automatiquement au renvoi.

Une règle mécanique du cycle d’utilisation d’outils s’applique dans tous les cas, sur chaque modèle : quand vous renvoyez un résultat d’outil, vous devez repasser le bloc de réflexion du modèle non modifié, signature comprise — l’altérer est une erreur d’API.

Et dans Claude Code, le hook PreCompact est l’endroit parfait pour archiver une transcription complète, non résumée, avant que la compaction ne jette du détail — une astuce pratique pour les vrais déploiements plutôt qu’une règle d’API exigible.

04Des prompts qui tiennent

Le modèle mental qui organise chaque technique ici : vous briefez un collègue nouveau et capable. Claude est fort et ne sait rien de vos normes, de votre audience, ni de votre définition du travail fini. Le test — un humain compétent, muni d’un contexte minimal, pourrait-il exécuter ce brief ? Sinon, le prompt est le problème.

De là découlent les pratiques que l’examen teste. Soyez explicite sur le périmètre quand vous voulez de l’ambition : « construis un tableau de bord » donne un tableau de bord ; demander chaque fonctionnalité et interaction pertinente donne cela à la place. Et expliquez les raisons derrière les règles plutôt que de les crier en capitales — « ce texte est lu à voix haute par un moteur TTS, donc pas de points de suspension » se généralise ; « JAMAIS de points de suspension », non.

Donnez des exemples — trois à cinq, choisis comme vous choisiriez une suite de tests : pertinents pour le cas d’usage réel, assez divers pour couvrir les cas limites (un jeu d’exemples quasi identiques enseigne un motif non voulu, des réponses toutes courtes et polites par exemple), et structurellement séparés des instructions par des balises example.

L’examen compte les exemples en shots — zéro-shot, instructions seules ; single-shot ajoute un exemple travaillé ; few-shot (aussi appelé multishot) en fournit plusieurs. Les exemples travaillés restent parmi les leviers les plus fiables sur le format, le ton et la structure de la sortie.

Structurez les prompts longs avec des balises XML — instructions, contexte, documents, entrées dans des sections étiquetées séparées, et quand plusieurs documents voyagent, imbriquez-les avec des attributs index pour que le modèle garde ses sources en ordre. Mettez le rôle stable dans le paramètre system (même une phrase de rôle focalise le ton) et la demande volatile dans le tour utilisateur. Et définissez le contrat de sortie explicitement : JSON à clés nommées et valeurs énumérées, ou un gabarit qui fixe la forme et la longueur de chaque champ.

Une règle propre au modèle qui apparaît en question de fait — à jour de septembre 2026 : sur Claude Sonnet 5, régler temperature, top_p ou top_k à des valeurs non par défaut est rejeté avec une erreur 400. Contrôlez le ton et la variété par le prompt système à la place.

05Sorties structurées et tool use strict

L’ancienne manière d’obtenir du JSON était de demander poliment et d’écrire un parseur défensif. La manière actuelle est le décodage contraint : fournissez un JSON Schema et l’échantillonnage du modèle se limite aux sorties qui y correspondent — structurellement valide à chaque fois, aucun retry pour syntaxe mal formée. Deux fonctions indépendantes livrent cela, et vous pouvez utiliser l’une, l’autre ou les deux :

• —JSON outputs — réglez output_config.format sur votre schéma et le JSON arrive dans le bloc de contenu texte de la réponse. Les SDK rendent cela agréable : passez un modèle Pydantic ou un schéma Zod aux helpers parse et recevez en retour un objet typé et validé.
• —Tool use strict — réglez strict: true sur une définition d’outil et les appels d’outil du modèle ont la garantie de porter un nom d’outil valide et des arguments conformes à votre input_schema.

Deux mentions en petits caractères qui méritent un vrai temps d’étude. Premièrement : l’API ne prend en charge qu’un sous-ensemble de JSON Schema. Les helpers du SDK comblent l’écart en retirant des contraintes comme minimum, maximum et limites de longueur, en les réexprimant dans les descriptions de champs, et en ajoutant additionalProperties: false — puis en validant la réponse par rapport à votre schéma d’origine dans votre code. La contrainte est imposée, juste pas par le décodage.

Deuxièmement : le mode strict a ses limites. Les jeux d’outils computer-use et browser-use le refusent net, et ses schémas compilent en grammaires mises en cache — donc les PHI restent hors des identifiants de schéma, des valeurs d’énumération et des patterns, dans les messages seulement.

La règle empirique pour les questions de scénario : réponse finale lisible par machine, JSON outputs ; arguments de fonction correctement typés, tool use strict ; les deux à la fois, c’est permis.

06Une page pour réviser

Cinq sections de prose se trouvent au-dessus de cette ligne. Voici le même domaine compressé : les deux fonctions de sortie structurée côte à côte, et les cinq lignes à emporter plus bas. Le tableau de la boîte à outils des contextes longs, section 02, est l’autre moitié de votre relecture de la veille — si vous ne relisez que deux choses, relisez ce tableau-là et celui-ci.

Une ligne à tracer à travers le domaine, la même que pour chaque page de cette série : les idées sont stables, les détails produit ne le sont pas. Le cadrage budget-pas-seau, l’élagage contre l’isolation, les raisons contre les capitales, le vocabulaire des shots, le décodage contraint — tout cela survivra à n’importe quel changement de produit. Les listes de modèles ici — lesquels gardent les blocs de réflexion, lesquels reçoivent les balises de conscience du contexte, la restriction d’échantillonneur de Sonnet 5, le plancher de modèles de la compaction — ont été vérifiées auprès de la documentation officielle en septembre 2026 et peuvent changer entre deux éditions. Tout ce qui est estampillé « à jour de » tombe dans ce second groupe ; revérifiez-le auprès de la documentation vivante la semaine où vous passez l’examen.

07Les pièges de ce domaine

• —« Le cache libère de l’espace de fenêtre » — les tokens mis en cache comptent toujours ; le cache change le coût, pas la capacité.
• —« Une fenêtre d’un million de tokens veut dire : remplissez-la » — le context rot dégrade la précision à mesure que le contenu croît.
• —« Le modèle connaît son budget restant, donc il libérera de l’espace » — la conscience du contexte laisse le modèle se caler sur l’espace restant ; elle ne crée aucun espace.
• —« L’édition de contexte va désynchroniser mon historique client » — le client garde l’historique complet non édité ; il n’y a rien à synchroniser.
• —« Un sous-agent partage la fenêtre du parent » — l’isolation est le but : il tourne dans sa propre fenêtre et ne renvoie que son message final.
• —« Retirer le bloc de réflexion avant de renvoyer le résultat d’outil » — repassez-le non modifié, signature comprise ; l’altérer est une erreur d’API.
• —« Répéter la règle plus fort » — expliquez la raison à la place ; le modèle généralise à partir des raisons.
• —« Des exemples quasi identiques sont la bonne pratique » — la diversité et les cas limites sont ce qui enseigne.
• —« Le décodage contraint impose mes bornes Pydantic » — le SDK les retire, les documente, et votre code valide.
• —« strict: true marche sur tout outil » — les jeux d’outils computer et browser le refusent.

08Vérifiez vos acquis

Quatre questions de scénario, à peu près dans le registre de l’examen. Chacune se déplie pour montrer la réponse et — plus utilement — pourquoi les mauvaises options sont mauvaises.