Prompting pour développeurs

Le « prompt engineering » a fait deux dégâts : faire croire qu’il existe des formules magiques, et faire croire que c’est un métier.

Pour un développeur, la réalité est plus simple et plus exigeante. Un prompt, c’est une spécification adressée à un exécutant rapide, large, et statistique. Les compétences requises, vous les avez déjà : écrire un ticket précis, définir une interface, poser des critères d’acceptation.

Le prompt est une spécification

Les guides précédents ont posé la mécanique : le modèle continue votre texte (guide 01), avec un budget d’attention limité (guide 02), et ne sait de votre projet que ce qui est dans le contexte (guide 03). La conséquence est directe : tout ce que vous ne spécifiez pas sera comblé par la continuation la plus probable. Autrement dit, par la moyenne statistique du corpus. Pas par vos intentions.

Quand vous écrivez « ajoute la validation sur ce formulaire », vous déléguez au corpus le choix de la bibliothèque, des règles, des messages d’erreur et de la gestion des cas limites. Parfois la moyenne vous convient. Quand elle ne vous convient pas, le problème n’est pas que le modèle est mauvais : c’est que la décision n’était écrite nulle part.

L’ambiguïté d’un prompt n’est pas un défaut de style. Comme dans un CLAUDE.md, c’est de la dette qui s’exécute.

Spécifier le quoi, contraindre le comment

Une bonne demande à un agent ressemble à un bon ticket : un objectif vérifiable, des contraintes explicites, un périmètre fermé.

L’objectif, en termes de comportement observable. « Corrige le bug » est une intention. « La soumission avec un email invalide doit afficher l’erreur sous le champ sans recharger la page » est une spécification.
Les contraintes qui ferment l’espace des solutions. Bibliothèques imposées ou interdites, interfaces à respecter, style du code existant. Le modèle ne devine pas vos conventions : il les lit ou il les ignore.
Le périmètre, surtout en négatif. « Ne touche pas au schéma de la base », « pas de nouvelle dépendance », « uniquement le module de facturation ». Les agents débordent par défaut. L’enthousiasme statistique du corpus penche vers « refactorer au passage ».

Le tips Craftomancer

Les adjectifs ne contraignent rien. « Code propre, robuste et maintenable » ne change pas la distribution de sortie : tout le corpus se croit propre, robuste et maintenable. Une contrainte vérifiable (« aucune fonction de plus de 30 lignes », « gère explicitement le cas où l’API renvoie 429 ») change la sortie. Si vous ne pouvez pas vérifier une exigence, le modèle ne peut pas la suivre.

Fournir le critère de vérification

La différence entre déléguer et espérer, c’est le critère de fin. Le guide 01 l’a posé : la sortie d’un modèle n’a pas besoin d’être digne de confiance, elle a besoin d’être vérifiable à bas coût. Mettez donc la vérification dans la demande :

Donnez la commande qui fait foi. « La tâche est finie quand pnpm test passe » transforme une génération en boucle d’essai-erreur qui converge.
Pour une tâche non triviale, écrivez (ou faites écrire et validez) les tests d’abord. Un test est la forme la plus dense et la moins ambiguë de spécification qu’un modèle puisse recevoir.
Exigez la preuve, pas la déclaration : « montre la sortie des tests », pas « dis-moi quand c’est bon ». Un modèle optimise la vraisemblance, y compris celle d’un rapport de succès.

Les patterns qui marchent, et pourquoi

Quelques patterns survivent à l’épreuve du temps parce qu’ils s’appuient sur la mécanique, pas sur la superstition :

Un exemple vaut mieux que trois paragraphes. Montrer une entrée/sortie attendue, ou un fichier du projet au bon style, ancre la continuation bien plus fort que des consignes abstraites.
Pour les tâches larges, plan d’abord. Demander un plan et le valider avant l’implémentation coûte un aller-retour. Découvrir le malentendu après huit cents lignes de diff coûte beaucoup plus.
Découper plutôt qu’empiler. Trois demandes successives et nettes battent un méga-prompt qui essaie de tout prévoir. Chaque étape garde un contexte propre et un critère de fin clair (guide 02 : l’attention se dilue).
Itérer plutôt que peaufiner à l’aveugle. Le premier prompt n’a pas à être parfait. Il a à être assez précis pour que l’écart entre la sortie et l’attente vous apprenne ce qui manquait à la spécification.

Quant aux patterns cargo-cult (promettre un pourboire, menacer le modèle, « agis comme un développeur 10x »), c’est du folklore. Si un effet existe, il est marginal et instable d’un modèle à l’autre. Investissez dans la précision, pas dans l’incantation.

En pratique

Relisez votre prompt comme un ticket confié à un prestataire inconnu, compétent et ultra-littéral : qu’est-ce qui reste à sa discrétion ?
Toute exigence doit être vérifiable. Remplacez chaque adjectif par une contrainte mesurable, ou supprimez-le.
Fermez le périmètre en négatif : ce qui ne doit pas bouger se dit explicitement.
Donnez la commande qui fait foi et exigez sa sortie comme preuve de fin.
Si la sortie déçoit, cherchez d’abord ce que votre spécification ne disait pas. C’est presque toujours là.

Vérifiez votre modèle

Quatre questions pour voir si ça tient. Cliquez une réponse : le verdict s’affiche.

Auto-évaluation 0 / 4

01 Vous écrivez « ajoute la validation sur ce formulaire » sans rien préciser de plus. Le choix de la bibliothèque et des messages d’erreur, c’est…

02 Vous demandez du « code propre, robuste et maintenable ». Sur la sortie, ça produit quoi ?

03 Pour qu’une demande devienne une boucle d’essai-erreur qui converge, le critère de fin le plus utile, c’est…

04 Promettre un pourboire, menacer le modèle, « agis comme un développeur 10x » : ces patterns, vous en faites quoi ?