Ingénierie de prompts et sortie structurée

La version filière développeur de ce sujet, c’est « écrire un bon prompt ». La version architecte — cet examen — c’est « concevoir un système qui produit une sortie dependable ». La différence est une discipline : des critères explicites sur lesquels le modèle peut être contrôlé, des exemples qui enseignent les cas limites, un schéma qui rend le format non négociable, une boucle qui corrige les violations, et une couche économique (lots, budgets multi-passe) qui garde l’ensemble abordable. Les six sous-domaines sont cette phrase, déployée.

01Critères explicites : le brief, pas la vibration

Un prompt est un brief pour un collègue compétent mais nouveau. Ce cadrage traverse toutes les questions de ce sous-domaine parce qu’il tranche quel genre d’écriture est un prompt : pas une incantation, pas une persuasion — un ordre de travail. Il énonce le rôle (le rôle que Claude endosse : le paramètre system de premier niveau, stable d’une requête à l’autre), la tâche (la demande volatile, dans le tour user), le périmètre (ce qui est dedans, ce qui est explicitement dehors), et — la signature de l’architecte — des critères d’acceptation explicites : à quoi ressemble une sortie correcte, énoncée en conditions vérifiables plutôt qu’en adjectifs. « Signale les clauses risquées » est une vibration ; « signale les clauses qui limitent la responsabilité, transfèrent des données hors de l’UE ou se reconduisent sans préavis — citez-les verbatim — produisez un objet JSON par clause avec clause_id, category, severity » est un brief. Le symptôme récurrent de l’examen, « trop de faux positifs », est presque toujours un problème de critères : on n’a jamais dit au modèle quoi ne pas matcher.

La structure est la seconde moitié de la discipline. Les balises de style XML (<instructions>, <example>, <documents>) donnent au modèle des ancres sans ambiguïté sur qui-est-quoi, et les propres conseils de prompting d’Anthropic s’y appuient ; le rôle stable vit dans le prompt système là où le prompt caching peut le figer, et le matériel volatile arrive dans le tour user ; les entrées longues se découpent et s’étiquetent plutôt que de s’entrelacer avec les instructions. Le test pour tout brief, prêt pour l’examen en une ligne : un humain compétent pourrait-il produire la sortie visée à partir de ce brief seul, sans rien vous demander ? Sinon, le brief n’est pas fini — et aucune qualité de modèle ne le finira à votre place.

02Few-shot : des exemples qui enseignent la frontière

Le prompting few-shot consiste à inclure des exemples travaillés dans le prompt pour que le modèle imite le motif plutôt que de l’inférer. La version examen de « combien et lesquels » : trois à cinq, choisis pour leur diversité — pas cinq variations du cas facile, mais un éventail qui couvre la frontière : un positif évident, un négatif évident, un cas réellement ambigu avec sa résolution. Les exemples sont le bord de la spécification, démontré. Un prompt de classification dont les exemples sont tous manifestement positifs enseigne au modèle que tout est positif ; le taux de faux positifs était écrit dans les exemples.

Trois mises en garde de conception portent des points. Le format : les exemples démontrent la forme exacte de sortie — si la cible est JSON, les exemples sont JSON, formatés précisément comme vous voulez le retour (few-shot et sortie structurée se composent : le schéma impose, les exemples démontrent). La cohérence : des exemples contradictoires — deux formats pour le même travail — produisent une sortie instable pire que pas d’exemples du tout. Et le coût : les exemples sont des tokens à chaque requête, ce qui en fait une décision de prompt caching — les exemples stables appartiennent au préfixe cacheable (le prompt système), les démonstrations volatiles avec la requête, pour que les exécutions répétées réutilisent les tokens d’exemples au dixième du prix au lieu de les repayer. Sur plusieurs modèles actuels, les réglages non par défaut de température et de leurs cousins d’échantillonnage sont rejetés d’office dans les contextes structurés — le rappel de l’examen que « la variété » n’est pas un bouton à tourner pour réparer un problème d’exemples.

03Sortie structurée : le schéma est le contrat

Quand du code en aval consomme la sortie, la prose est un passif et le contrat est un schéma. Le mécanisme d’imposition de l’API, c’est l’usage d’outils, pris de biais : définissez un outil dont le schéma d’entrée a la forme de sortie voulue, forcez-le avec tool_choice pointé sur cet outil, et « l’appel d’outil » du modèle est votre résultat structuré — du JSON conforme au schéma, parce que le schéma est ce que l’appel devait satisfaire. Avec la sortie structurée imposée ainsi, les sorties invalides sont rejugées côté serveur contre le schéma : l’imposition est contractuelle, pas consultative. (La même idée alimente les pipelines d’extraction : « l’outil » existe pour être appelé avec des données, pas pour faire un travail.)

La conception du schéma est là que les points se cachent. Déclarez ce qui est vrai : required pour chaque champ dont le pipeline a réellement besoin ; des enums pour les vocabulaires fermés (severity: low | medium | high — pas du texte libre où le modèle invente des adverbes) ; des types honnêtes et étroits ; et, là où la plateforme offre un mode strict, servez-vous-en — en mode strict, les champs hors schéma sont refusés plutôt que tolérés. Les mauvaises réponses classiques sont la sous-spécification (tout optionnel, « string » partout) et la sur-machinerie (des tableaux imbriqués trois niveaux là où un enregistrement plat suffirait). Une composition de plus : un préfill côté assistant peut lancer la sortie sur le chemin exact du format — et le préfill se compose avec l’usage d’outils comme aide au formatage, même si, avec l’imposition par schéma, le format est déjà le contrat.

04Validation, reprise et boucles de retour

L’imposition à la génération couvre la forme ; la boucle couvre la vérité. Le motif examiné est valider → renvoyer l’erreur → reprendre : votre code contrôle la sortie (la conformité au schéma, que la plateforme peut déjà garantir, plus les contrôles de contenu — clause_id existe dans le document, les dates sont réelles, les totaux tombent juste, la citation est verbatim), et quand un contrôle échoue, la reprise renvoie l’erreur avec la sortie fautive pour que le modèle se corrige. Ce message de retour est une erreur d’outil du domaine 2 en habits d’ingénieur de prompt : ce qui a échoué, pourquoi, et ce qui passerait. « Le modèle a renvoyé severity “critical”, qui n’est pas dans l’enum ; utilisez low, medium ou high » — un tour, auto-corrigé.

La boucle exige les mêmes garde-fous que toute boucle. Un plafond de reprises (deux ou trois, pas « jusqu’à ce que ça marche ») pour qu’un malentendu systématique remonte au lieu de tourner ; un traitement idempotent pour qu’une requête renvoyée ne facture ou n’écrit pas deux fois ; et un chemin d’échec conçu, pas découvert — après le plafond, router vers une file de revue humaine ou un défaut conservateur, et consigner ce qui a échoué. Les signatures de scénario de l’examen : « échoue toujours pareil » → le brief ou les exemples sont faux (réparez la spécification, pas la boucle) ; « produit parfois un champ mal formé » → reprise avec retour ; « jamais mal formé mais parfois faux » → ce n’est pas le problème de la validation, c’est celui de l’évaluation (la calibration du domaine 5, ou les exemples limites du few-shot).

05Le traitement par lots

Le volume change l’économie, et l’API a une réponse dédiée : la Message Batches API — asynchrone, à 50 % du prix synchrone, avec des résultats garantis sous 24 heures (typiquement bien plus vite). Envoyez des milliers de requêtes en un lot ; sondez ou faites-vous notifier ; collectez les résultats par requête, chacun individuellement réussi ou échoué. L’examen mappe mécaniquement les scénarios : priorité coût + peut attendre = Batches ; la latence compte = synchrone (avec streaming si un humain attend une sortie progressive). Deux notes du domaine voisin : les lots ne portent pas chaque fonctionnalité (le fast mode y est indisponible, à jour de septembre 2026), et un lot plafonne à 256 Mo là où un message seul en fait 32.

Concevoir des lots, c’est concevoir du débit. Découpez les gros corpus en requêtes qui tiennent confortablement ; gardez le préfixe stable (rôle, critères, exemples) octet pour octet identique d’une requête à l’autre pour que le prompt caching s’applique aussi dans le lot — les lectures de cache au dixième du prix d’entrée se composent avec le demi-tarif du lot. Surveillez les limites de débit (requêtes, tokens d’entrée et de sortie par minute — par paliers), respectez les 429 avec temporisation, et concevez le pipeline reprenable : un lot qui meurt à la requête 4 000 sur 10 000 doit reprendre à 4 001, pas recommencer — la même leçon d’état de session que le domaine 1, à l’échelle du pipeline. Et gardez un échantillon : une part des résultats de lot vérifiée par un humain à chaque exécution, parce qu’une sortie à demi-tarif qui dérive en silence est la chose la plus chère pas chère de ce domaine.

06Revue multi-instance et multi-passe

Le dernier sous-domaine relève le plafond de fiabilité en y consacrant davantage. Multi-instance : exécutez la même étape deux fois ou plus — avec le même prompt (consensus à la majorité) ou avec des cadrages différents (évaluations indépendantes et diverses) — puis agrégée : vote majoritaire pour la classification, intersection pour l’extraction à haute précision, union dédupliquée pour les balayages où le rappel est critique. Multi-passe : le même contenu à travers des passes séquentielles aux métiers différents — extraire, puis vérifier ; rédiger, puis critiquer ; traduire, puis relire contre la source. Générateur–critique est le motif nommé : une seconde instance (ou un second prompt) dont le seul métier est de trouver les défauts de la première, et de renvoyer les corrections — la boucle de retour du domaine 4, avec du personnel.

Les questions de l’architecte sont exactement celles de l’examen : quand le multiplicateur se justifie-t-il, et que fait l’agrégation au profil d’erreur ? Multiplier les instances multiplie le coût linéairement mais ne répare pas un angle mort partagé — trois lecteurs de la même clause ambiguë se trompent tous pareil ; le remède au biais partagé, ce sont des prompts divers ou un autre modèle, pas des copies. Le vote échange un type d’erreur contre un autre : la majorité écrase les ratés occasionnels (améliore la précision ou le rappel dans un sens) tout en enterrant les bonnes réponses minoritaires (l’autre sens) — choisissez la règle d’agrégation selon l’erreur qui coûte le plus au scénario. Et les passes de vérification sont une assurance bon marché rapportée au rayon d’action de ce qu’elles verrouillent : plus l’action en aval est grosse (l’échelle d’escalade du domaine 1, encore), plus l’économie justifie de passes.

07Les pièges de ce domaine

• —« Demander du JSON valide dans le prompt — voilà la sortie structurée. » Demander, c’est conseiller ; un outil à schéma forcé, c’est imposer. Le JSON demandé en prompt échoue au taux exact qui compte : parfois, en production, en silence.
• —« Plus d’exemples, c’est toujours mieux. » Trois exemples divers qui enseignent la frontière battent vingt variations du cas facile — et coûtent un vingtième des tokens à chaque relecture.
• —« Ça a échoué à la validation, donc relance la requête identique. » Sans l’échec renvoyé, le modèle n’a rien de neuf à se mettre sous la dent — une boucle d’agitation avec des étapes en plus. Renvoyez l’erreur, ou réparez le brief.
• —« Mettez tout en lot — c’est moitié prix. » Les lots achètent 50 % avec un plafond de 24 heures. Un humain qui attend ou une étape bloquante du pipeline rend ce troc absurde ; le travail sensible à la latence est synchrone, en streaming.
• —« Exécutez trois fois et prenez la majorité — fiabilité réglée. » Le vote écrase les erreurs occasionnelles et conserve les systématiques. Si le brief est faux, le vote est unanime.
• —« Réglez la température pour la cohérence. » Sur plusieurs modèles actuels, les réglages d’échantillonnage non par défaut sont rejetés d’office dans les contextes structurés — et la cohérence n’a jamais été un bouton d’échantillonnage : ce sont les critères, les exemples et les schémas.