Anatomie d'un bon prompt de coding

Pourquoi le prompt est le levier le moins cher

Dans le Core Four (Model, Prompt, Context, Tools), le prompt est le levier que le developpeur controle le plus directement et qui coute zero token supplementaire a ameliorer. Avant de changer de modele, d’ajouter du contexte ou de brancher un nouvel outil, la premiere question est toujours : est-ce que ma demande est claire ?

Point cle : Un prompt precis reduit le nombre de tours de boucle agentique. Moins de tours = moins de tokens consommes, moins de risques de derive.

La regle de diagnostic du Core Four place le prompt en premier : Prompt, Context, Tools, Model. Si le resultat est mauvais, verifier d’abord la clarte de la demande.

Les 4 composantes d’un prompt de coding

1. L’intention (quoi)

Ce que le code doit faire, en termes fonctionnels. Pas “refactore ce code” mais “extrais la logique de validation dans une methode separee ValidateOrder”.

Piege : Decrire le “comment” avant le “quoi”. L’agent est meilleur que vous pour choisir l’implementation si l’objectif est clair.

2. Les contraintes (comment — le cadre)

Les regles non negociables : langage, framework, patterns a respecter ou eviter, limites de performance. Exemples : “en C# 12”, “sans dependance externe”, “garde l’API publique identique”.

3. Le contexte explicite (avec quoi)

Les informations que l’agent ne peut pas deviner : structure du projet, conventions d’equipe, cas limites connus. Le contexte peut etre dans le prompt, dans un fichier CLAUDE.md, ou dans les fichiers que l’agent lit — mais il doit etre accessible.

4. Le format de sortie (sous quelle forme)

Ce qu’on attend comme livrable : un fichier complet, un diff, un test, une explication. Preciser le format evite que l’agent devine et se trompe. Exemple : “ecris le test xUnit correspondant, un seul fichier, avec les using necessaires”.

Specificite vs sur-specification

Etre specifique, c’est poser un cadre clair. Sur-specifier, c’est dicter chaque ligne de code. La frontiere : si le prompt decrit l’implementation ligne par ligne, autant ecrire le code soi-meme.

Bon equilibre : Decrire le quoi et les contraintes avec precision, laisser le comment a l’agent. L’agent excelle a choisir une implementation quand l’objectif est sans ambiguite.

Piege : Un prompt trop vague (“ameliore ce code”) laisse l’agent choisir ses propres criteres d’amelioration. Un prompt trop precis (“renomme x en y, deplace la ligne 42 apres la ligne 58”) transforme l’agent en copiste sans valeur ajoutee.

Exemples concrets : avant / apres

Avant (vague) :

Refactore ce service.

Apres (precis) :

Dans OrderService.cs, extrais la logique de calcul du prix
dans une methode privee CalculateTotal(Order order).
Garde la signature publique de PlaceOrder identique.
Le projet utilise des decimal, pas des double.

Avant (sur-specifie) :

Ligne 12 : renomme 'x' en 'total'.
Ligne 13 : ajoute 'var tax = total * 0.2m;'
Ligne 14 : remplace 'return x;' par 'return total + tax;'

Apres (intention + contrainte) :

Ajoute le calcul de la TVA (20%) au total retourne
par CalculateTotal. Utilise le type decimal.

La regle du “premier tour reussi”

L’objectif d’un bon prompt est d’obtenir un resultat correct ou quasi-correct au premier tour de boucle. Chaque tour supplementaire consomme des tokens et augmente le risque de derive (l’agent “oublie” le contexte initial ou part dans une direction differente).

Point cle : Investir 2 minutes dans un prompt precis economise 10 minutes d’iterations correctives et des milliers de tokens.

Si l’agent produit regulierement des resultats hors-sujet, le probleme est presque toujours dans le prompt ou le contexte — pas dans le modele.