Le playbook de prompting Claude Code

La plupart des conseils sur le prompting sont une liste de bonnes et de mauvaises pratiques que vous ne pouvez pas vérifier. La version que les ingénieurs d’Anthropic utilisent eux-mêmes est différente : elle part des évals, traite un prompt comme du code que vous déboguez un échec à la fois, et sait reconnaître quand la réponse n’est pas du tout un meilleur prompt. Voici ce playbook, tel que je l’applique au travail LLM en production.

Deux situations couvrent presque tout : vous maintenez un prompt qui dérive (souvent après une migration de modèle), ou vous construisez un nouvel agent depuis zéro. Les techniques se recoupent, et ce sont les mêmes que celles derrière les pipelines de Geonimo.

Partez des évals, pas des opinions

Vous ne pouvez pas savoir si un changement de prompt a aidé tant que vous ne le mesurez pas. Donc avant de toucher à la formulation, construisez une petite suite d’évals. Elle a besoin de trois types de cas : un contrôle qui devrait toujours passer (sans ambiguïté, le modèle le gère facilement), des cas limites où vous avez déjà vu le modèle échouer (pour que les régressions ne puissent pas revenir en douce), et des limites de capacité, où le bon réflexe est de transférer à un humain ou de refuser purement et simplement. Avec cette suite, chaque changement devient une expérience mesurable au lieu d’une impression.

Faites le ménage avant d’optimiser

La plupart des prompts sous-performants s’améliorent rien que par l’hygiène. Les vrais prompts accumulent des scories : des instructions copiées d’un site web, une ligne qui dit au bot qu’il est humain, des rustines datant de trois modèles en arrière, le tout entassé dans un seul paragraphe. Corrigez d’abord la structure. Utilisez des balises XML pour séparer le rôle, les consignes, la politique, le ton et les données. Supprimez le texte redondant. La règle sur laquelle je reviens sans cesse : si vous lisez un prompt et que vous ne pouvez pas distinguer les consignes de la politique et des données, le modèle ne le peut pas non plus. Ajoutez ensuite un contrat de sortie, définissez le format de sortie et imposez-le dans le harness avec une séquence d’arrêt ou des sorties structurées quand le schéma est complexe.

Ciblez les modes de défaillance un par un

Avec un prompt propre et une éval qui échoue, corrigez un mode de défaillance à la fois. Trois schémas reviennent constamment :

Construire du neuf : c’est prompt, modèle et harness

Depuis zéro, le prompt n’est qu’un des trois leviers, le modèle et le harness comptent tout autant. Progressez par paliers sur les trois. Un exemple réel : un agent de planification échouait sur chaque cas avec un petit modèle et un prompt simple. Un modèle plus gros a réduit les erreurs mais échouait encore. Le modèle plus gros avec une réflexion adaptative a fini par passer, mais a triplé les tokens et la latence. Un modèle plus petit avec un bien meilleur prompt a réussi en partie. Ce qui a gagné, c’est de passer en mode agentique : découper la tâche en trois prompts simples, un générateur, un évaluateur qui rapporte des violations précises, et un réparateur qui les corrige, ce qui a résolu chaque cas avec un coût et une latence inférieurs à la force brute.

Cette boucle générer-évaluer-réparer a un bonus : vous pouvez injecter des contraintes souples à l’exécution (“garde Harry et Sally sur des créneaux différents”) sans réécrire le backend. Choisir entre le prompt, le modèle et le harness est une décision coût / latence / qualité, exactement le genre de compromis que je fais quotidiennement sur des pipelines en production, et le fil conducteur de ma façon de construire.

Cela va de pair avec les habitudes de l’équipe d’Anthropic et la façon de choisir entre outils, skills et subagents. Si vous voulez de l’aide pour rendre vos systèmes d’IA fiables en production, parlons-en.