Écrire des prompts qui produisent du code utilisable

Quand le code produit ne convient pas, le réflexe est de blâmer le modèle ou de reformuler au hasard. Dans la grande majorité des cas, le problème est ailleurs : la demande ne contenait pas l'information nécessaire pour produire autre chose que ce qui est sorti.

Un prompt de code n'est pas une question, c'est une spécification. Tout ce que vous ne dites pas, le modèle le décide à votre place — et il le décide selon ce qui est statistiquement le plus courant, ce qui est rarement ce que vous vouliez.

L'anatomie d'un prompt qui fonctionne

Trois éléments manquent presque toujours, et ce sont eux qui font la différence entre du code jetable et du code exploitable.

1. Le contexte technique — la stack, les versions, les conventions du projet, ce qui existe déjà. Sans lui le modèle invente un environnement plausible qui n'est pas le vôtre.
2. Les contraintes — ce qu'il ne faut pas faire, quelles bibliothèques sont interdites, quelles valeurs ne doivent pas être inventées. L'interdiction produit plus d'effet que la demande.
3. Le critère de réussite — comment on saura que c'est bon. Sans lui, le modèle vise « ça compile », pas « ça résout mon problème ».

La même demande, deux résultats

Voici la version que tout le monde écrit, puis la même intention correctement spécifiée.

Fais-moi une fonction pour uploader un fichier.

Contexte : Next.js 16 (App Router), TypeScript strict, validation avec zod.
Les fichiers partent sur un stockage S3 déjà configuré dans lib/storage.ts,
qui expose putObject(key, buffer, contentType).

Écris un route handler POST qui reçoit un upload multipart.

Contraintes :
- accepte uniquement image/png, image/jpeg, image/webp
- refuse au-delà de 5 Mo, sans charger le fichier entier en mémoire d'abord
- le nom de fichier vient de l'utilisateur : ne jamais l'utiliser tel quel
  comme clé de stockage
- pas de nouvelle dépendance

Réussi si : un fichier de 6 Mo est refusé avec un 413, un .exe renommé
en .png est refusé, et deux uploads du même nom ne s'écrasent pas.

Le second prompt est cinq fois plus long et fait gagner beaucoup plus de temps qu'il n'en coûte. Surtout, la dernière ligne transforme la nature de l'échange : vous avez donné au modèle de quoi vérifier son propre travail.

Quatre prompts à reprendre

Ces formulations couvrent l'essentiel des situations quotidiennes. Elles sont volontairement génériques : remplacez ce qui est entre crochets.

Faire auditer du code

Tu es un attaquant qui cherche à exploiter ce code. Ton objectif est de
trouver un moyen concret de le faire échouer ou d'en extraire des données.

Pour chaque faille : l'entrée exacte qui la déclenche, ce que l'attaquant
obtient, et le correctif minimal.

Ne liste pas de bonnes pratiques générales. Si tu ne trouves rien
d'exploitable, dis-le plutôt que de meubler.

[coller le code]

Le rôle d'attaquant compte : demander « est-ce que ce code est sûr ? » produit une liste rassurante de généralités. Demander une exploitation concrète produit des trouvailles vérifiables.

Refactoriser sans casser

Refactorise ce fichier pour [objectif précis].

Contraintes absolues :
- le comportement observable ne change pas, y compris les cas d'erreur
- la signature publique des fonctions exportées ne change pas
- pas de nouvelle dépendance

Avant de produire le code, liste les comportements actuels que ton
refactor doit préserver. Si l'un d'eux te paraît être un bug, signale-le
mais ne le corrige pas dans le même passage.

[coller le code]

La demande de lister les comportements avant de refactoriser est le point important : elle force le modèle à lire réellement l'existant, et elle vous donne la liste de ce qu'il faut retester.

Déboguer

Symptôme : [ce qui se passe]
Attendu : [ce qui devrait se passer]
Ce que j'ai déjà vérifié : [pistes écartées]
Contexte : [stack, versions, depuis quand]

Propose les trois causes les plus probables, classées, avec pour chacune
la façon la plus rapide de la confirmer ou de l'écarter.

Ne propose pas de correctif tant que la cause n'est pas identifiée.

[coller le code et l'erreur complète]

Mentionner ce que vous avez déjà écarté évite les trois premiers échanges où le modèle propose les hypothèses évidentes. Interdire le correctif immédiat évite qu'il masque le symptôme.

Écrire des tests utiles

Écris des tests pour ce module avec [framework].

Ne teste pas les cas nominaux évidents. Concentre-toi sur :
- les valeurs limites et les entrées vides ou absentes
- les cas d'erreur et ce qui se passe quand une dépendance échoue
- les comportements dont dépend le reste de l'application

Pour chaque test, une phrase expliquant quelle régression il empêche.
Si un comportement te semble intestable en l'état, dis-le.

[coller le code]

Les formulations qui sabotent le résultat

Certaines habitudes de langage dégradent systématiquement la sortie.

• « Fais au mieux » ou « comme tu veux » — vous déléguez la décision d'architecture à quelque chose qui ne connaît ni vos contraintes ni votre avenir.
• « Simple » et « propre » — ces mots n'ont pas de sens partagé. Dites ce que vous voulez : moins de fichiers, moins de dépendances, moins d'abstractions ?
• Empiler plusieurs demandes dans un seul message — le modèle traite bien la première et bâcle les suivantes. Une intention par échange.
• Ne jamais dire non — si la première version ne convient pas, dire précisément ce qui cloche vaut mieux que reformuler la demande depuis zéro.

Corriger plutôt que redemander

Face à un résultat imparfait, la tentation est de reformuler la demande initiale et de tout relancer. C'est presque toujours une erreur : vous perdez la partie correcte et vous repartez d'un tirage différent, sans garantie qu'il soit meilleur.

La correction ciblée donne de bien meilleurs résultats. « La validation de taille se fait après avoir chargé le fichier en mémoire, ce qui annule la protection. Corrige uniquement ce point » produit un correctif précis, là où une reformulation produit un nouveau code avec de nouveaux défauts.