Iterer sur un prompt

Le reflexe fondamental

Quand un agent de coding produit un resultat incorrect, deux reactions sont possibles. La mauvaise : corriger manuellement le code genere et passer a la suite. La bonne : analyser pourquoi l’agent s’est trompe, corriger le prompt, et relancer.

Corriger le code a la main resout le probleme immediat mais ne corrige pas la cause. Au prochain prompt similaire, l’agent reproduira la meme erreur. Corriger le prompt resout la classe entiere de problemes.

Point cle : Corriger le prompt est un investissement. Corriger le code genere est une depense. L’un ameliore toutes les interactions futures, l’autre ne corrige que l’instance courante.

L’ordre de diagnostic : Core Four

Face a un resultat incorrect, il faut diagnostiquer la cause avant de corriger quoi que ce soit. Le Core Four definit un ordre de priorite :

1. Prompt

La demande est-elle claire ? L’intention est-elle explicite ? Le critere de succes est-il defini ? Dans la grande majorite des cas, le probleme est la.

2. Context

L’agent a-t-il les informations necessaires ? Connait-il l’architecture du projet, les conventions, les fichiers pertinents ? Un prompt parfait avec un contexte insuffisant produit un resultat generique.

3. Tools

L’agent a-t-il acces aux bons outils ? Peut-il lire les fichiers, executer les tests, verifier son travail ? Sans outils de verification, il travaille en aveugle.

4. Model

Seulement en dernier recours : le modele est-il adapte a la tache ? Changer de modele sans avoir verifie les trois premiers leviers est presque toujours premature.

Attention : La tentation de sauter directement au Model (“c’est Claude qui est mauvais, essayons GPT”) est forte. Mais dans 90% des cas, le probleme se situe au niveau du Prompt ou du Context. Le Model est rarement en cause.

L’erreur comme information diagnostique

Le resultat incorrect de l’agent n’est pas juste un echec — c’est une source d’information. Ce que l’agent a produit “de travers” indique ce qu’il a compris de votre prompt.

• L’agent fait autre chose que ce qui etait demande : le prompt est ambigu. L’agent a interprete une formulation differemment de ce que vous vouliez.
• L’agent fait la bonne chose mais au mauvais endroit : le contexte est insuffisant. Il manque les conventions architecturales.
• L’agent fait la bonne chose mais de maniere incomplete : le prompt ne mentionne pas les criteres de succes ou les cas limites.
• L’agent produit du code syntaxiquement correct mais semantiquement faux : il manque du contexte metier ou des exemples du comportement attendu.

Point cle : Lire attentivement l’erreur avant de corriger. Le type d’erreur designe le levier a actionner : prompt, contexte, outils ou modele.

La boucle d’iteration

L’iteration sur un prompt suit un cycle precis en quatre etapes :

1. Executer

Envoyer le prompt a l’agent et observer le resultat complet, y compris les eventuelles erreurs de compilation ou de test.

2. Observer

Comparer le resultat au resultat attendu. Ne pas se contenter de “ca ne marche pas” — noter precisement ce qui differe.

3. Diagnostiquer

Utiliser l’ordre Core Four pour identifier la cause. Le resultat incorrect est l’indice principal.

4. Raffiner le prompt

Modifier le prompt en fonction du diagnostic. Ajouter une precision, reformuler une ambiguite, fournir du contexte manquant.

Puis relancer. Chaque iteration devrait reduire l’ecart entre le resultat obtenu et le resultat attendu.

Attention : Ne pas accumuler plus de 2-3 iterations dans la meme session. Si apres 3 essais le resultat n’est pas satisfaisant, reformuler le prompt depuis zero dans une session neuve plutot que d’empiler des corrections.

Raffiner vs repartir de zero

Deux strategies existent quand le prompt ne produit pas le bon resultat :

Point cle : Regle pratique : si la correction consiste a ajouter une phrase, raffiner. Si elle consiste a reecrire plus de la moitie du prompt, repartir de zero.

Ajouter du contexte vs simplifier le prompt

Face a un mauvais resultat, deux ajustements opposes sont possibles :

• Ajouter du contexte : quand l’agent fait la bonne chose mais dans le mauvais cadre (mauvais dossier, mauvais pattern, mauvaise convention). Il lui manque de l’information.
• Simplifier le prompt : quand l’agent semble confus, melange les sous-taches, ou produit un resultat incoherent. Le prompt contient trop de directives qui se contredisent ou se diluent mutuellement.

Le diagnostic repose sur le type d’erreur. Un resultat generique ou mal place pointe vers un manque de contexte. Un resultat incoherent ou partiellement correct pointe vers un prompt trop charge.

Le Closed-Loop Prompting

Le Closed-Loop Prompting consiste a integrer la boucle de verification directement dans le prompt. Au lieu de demander une tache puis de verifier manuellement, on demande a l’agent de verifier lui-meme son travail.

Implemente un endpoint POST /api/orders qui cree une commande.
Apres l'implementation :
1. Verifie que le code compile sans erreur.
2. Execute les tests existants et confirme qu'ils passent.
3. Si un test echoue, corrige le code et relance les tests.
4. Liste les cas limites non couverts par les tests actuels.

Le prompt inclut explicitement les etapes de verification et de correction. L’agent ne se contente pas de produire du code — il valide son propre resultat et itere si necessaire, sans intervention manuelle.

Point cle : Le Closed-Loop Prompting externalise la boucle d’iteration dans le prompt lui-meme. L’agent fait l’observation et le diagnostic a votre place.

Recapitulatif