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 franchement 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.

Pourquoi un prompt est une spécification ?

Parce que 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.

Les Étapes précédentes ont posé la mécanique : le modèle continue votre texte, avec un budget d’attention limité, et ne sait de votre projet que ce qui est dans le contexte. La conséquence est immédiate.

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 très bien. 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 fichier d’instructions, c’est de la dette qui s’exécute.

Que doit contenir une bonne demande ?

Un objectif vérifiable, des contraintes explicites, un périmètre fermé. Exactement ce que contient un bon ticket.

L’objectif, en 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.

Comparez ces deux demandes, et demandez-vous laquelle laisse le moins de place au corpus :

Ajoute la validation sur ce formulaire, avec du code propre

Valide l'email côté client avec la lib déjà utilisée dans
`packages/forms`. Erreur affichée sous le champ, sans rechargement.
Pas de nouvelle dépendance, ne touche pas au schéma.

LE 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.

Comment donner un critère de fin ?

En mettant la vérification dans la demande. C’est toute la différence entre déléguer et espérer. Ce que le modèle sait l’a posé : la sortie d’un modèle n’a pas besoin d’être digne de confiance, elle a besoin d’être réfutable à bas coût.

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 toute seule.
Écrivez les tests d’abord sur une tâche non triviale (ou faites-les écrire, et validez-les). 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 », jamais « dis-moi quand c’est bon ». Un modèle optimise la vraisemblance, y compris celle d’un rapport de succès.

Quels patterns marchent vraiment ?

Ceux qui s’appuient sur la mécanique, et pas sur la superstition. Il y en a quatre que j’utilise tous les jours.

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, 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 demande garde un contexte propre et un critère de fin clair — plus la fenêtre grossit, plus l’attention se dilue.
Itérer plutôt que peaufiner à l’aveugle. Ce n’est pas un conseil de patience : la sortie est tirée, et aucune formulation ne la rend déterministe. Votre premier prompt n’a donc 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. Mettez cette énergie dans la précision, ça paie beaucoup mieux.

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.

Vérifiez votre modèle

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

RUN · VI 0 / 4

jack in — choisissez votre réponse

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…

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

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

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