Votre premier prompt marche rarement. Le deuxième non plus. La question, ce n’est pas si vous allez itérer. La question, c’est si vos itérations vont vraiment vous faire avancer ou juste cramer des crédits pendant que vous vous persuadez que vous progressez.

La plupart des guides de prompt engineering traitent l’itération comme une vertu en soi, comme si le fait d’ajuster et de tester garantissait mécaniquement une amélioration. Mais parlez à quelqu’un qui a vraiment passé des heures à affiner des prompts pour des systèmes en production et vous entendrez une autre histoire. Parfois, l’itération s’additionne et paye. Parfois, elle part en vrille. Savoir faire la différence, c’est ce qui sépare le raffinement stratégique de la frustration coûteuse.

La mécanique d’une itération utile

Chaque itération de prompt change quelque chose. Les utiles changent les bonnes choses.

Quand une sortie rate la cible, votre réflexe peut être d’ajouter plus d’instructions, plus d’exemples, plus de contraintes. Mais l’accumulation n’est qu’un outil parmi d’autres. Comme l’a décrit un développeur sur Hacker News : “every time the model does something undesired, even minor I add an explicit rule in the system prompt” (minimaxir, Hacker News). Cette approche marche, mais il notait aussi que les règles accumulées peuvent “balloon quickly” à mesure que des problèmes surgissent pendant les tests.

L’approche inverse marche aussi. Parfois, enlever des instructions produit de meilleurs résultats qu’en ajouter. Un praticien observait : “Sometimes even giving them ‘drunken’ prompts with just a few keywords is enough… If you specify too much they tend to hyperfixate on things” (birracerveza, Hacker News). Des contraintes trop serrées peuvent pousser un modèle à se focaliser à l’excès, au point de rater l’objectif réel.

Alors, on va dans quel sens ? Ça dépend du mode d’échec.

Diagnostiquer avant de changer

Sortie trop générique ? Ajoutez de la précision. Trop littérale ? Enlevez des contraintes. Incohérente ? Ajoutez une structure. Répétitive ? Réduisez les exemples.

Faites correspondre l’échec au correctif. Des changements au hasard produisent des résultats au hasard, et des résultats au hasard ne vous apprennent rien sur ce qui a vraiment fait bouger l’aiguille.

Ceux qui deviennent bons à ça traitent l’itération comme un test d’hypothèses, pas comme du tâtonnement. Chaque modification teste une supposition précise sur la raison pour laquelle la sortie précédente a échoué. Ce cadrage mental compte, parce qu’il vous force à formuler ce que vous pensez s’être mal passé avant de changer quoi que ce soit.

Quand itérer… et quand repartir de zéro

Itérer suppose que votre prompt actuel a une base qui mérite qu’on construise dessus. Cette hypothèse n’est pas toujours vraie.

Il y a un schéma classique : des gens raffinent un prompt moyen pendant quinze itérations, ajoutent des sous-clauses, des exemples, des contraintes, jusqu’à obtenir un nœud de rustines accumulées. Ils finissent avec quelque chose qui marche… à peu près… parfois. Mais ils seraient allés plus vite en jetant l’original et en reprenant le problème à frais.

Le biais des coûts irrécupérables frappe fort en prompt engineering. Vous avez déjà passé vingt minutes sur ce prompt. Il presque marche. Un petit ajustement de plus, et c’est bon. Sauf que si votre cadrage était mauvais dès le départ, aucune quantité de raffinement ne corrige ça.

Repartez de zéro quand :

• Votre prompt dépasse deux paragraphes d’instructions
• Vous ajoutez des exceptions pour gérer des exceptions
• La description du cœur de la tâche ne ressemble plus à votre objectif réel
• Les sorties empirent, pas l’inverse, malgré des changements logiques

Un développeur sur Hacker News l’a dit sans détour : “I realized the real problem was that I hadn’t figured out what I wanted in the first place” (Kiyo-Lynn, Hacker News). Avant d’itérer, vous devez savoir à quoi ressemble la réussite. Si vous ne pouvez pas décrire clairement la sortie idéale, votre prompt ne le peut pas non plus.

Le protocole du redémarrage

Quand vous repartez de zéro, ne supprimez pas tout pour réécrire au hasard. D’abord, extrayez ce qui a marché dans vos tentatives ratées.

Peut-être que votre spécification de format était bonne, même si votre cadrage de la tâche était à côté. Peut-être que vos exemples montraient la mauvaise chose, mais que l’instruction de ton a bien pris. Sauvez les morceaux prometteurs. Jetez l’échafaudage construit autour d’erreurs.

Ensuite, écrivez votre nouveau prompt en partant de la sortie attendue. Commencez par exactement ce que vous voulez voir. Décrivez cette sortie en langage simple. Construisez des instructions qui produiraient ce résultat précis. Ce renversement donne souvent des prompts plus propres que d’essayer de spécifier la transformation de l’entrée vers la sortie.

Suivre ce qui marche (sans en faire une usine à gaz)

Il vous faut un système. Pas un système compliqué.

L’approche la plus simple : garder un document au fil de l’eau. Chaque tentative a un numéro, le texte du prompt, un exemple de sortie, et une évaluation en une ligne. “Meilleure structure, mais le ton conversationnel a disparu.” “Format parfait, mais contenu trop superficiel.” “Celui-ci a vraiment marché.”

Comme l’a noté un praticien expérimenté : “Practice. Keep notes on what works for you. Pay attention to what other people do and take the best ideas” (PaulHoule, Hacker News). L’habitude de prendre des notes compte plus que le format exact.

Ce qu’il faut noter

Pour chaque itération, capturez :

• Ce que vous avez changé par rapport à la version précédente
• Pourquoi vous pensiez que ce changement aiderait
• Ce qui a réellement changé dans la sortie
• Si le changement vous a rapproché ou éloigné de votre objectif

Ce dernier point est crucial. Parfois, une modification produit une sortie différente sans produire une meilleure sortie. Si vous n’évaluez pas explicitement la direction, vous pouvez itérer indéfiniment sans progrès : juste de la différence.

Le problème de la comparaison

Voici la vérité qui dérange : comparer des sorties de prompts est plus difficile que ça en a l’air. Le même prompt peut produire des sorties sensiblement différentes sur deux exécutions de suite, ce qui veut dire que l’amélioration que vous croyez voir n’est peut-être que de la variance.

Un commentateur résumait cette frustration : “if you’re ‘tweaking’ the prompt what you’re really doing is just re-rolling the dice until you land in a neighborhood closer” à ce que vous voulez (ianbicking, Hacker News). Selon lui, les techniques ne constituent un vrai progrès que lorsqu’elles marchent sur plusieurs cas de test, au lieu de produire une sortie réussie isolée.

Pour des prompts de production, c’est énorme. Un prompt qui marche brillamment une fois et échoue trois fois est pire qu’un prompt qui marche correctement à chaque fois. Tester sur un seul exemple ne vous dit rien sur la constance. Tester sur beaucoup d’exemples, si… mais ça prend plus de temps.

Le juste milieu : tester les changements sur vos trois entrées les plus représentatives. Si le changement améliore les trois, vous avez probablement trouvé quelque chose de réel. S’il en améliore une tout en dégradant une autre, vous êtes sans doute en train de déplacer la variance.

Le piège des rendements décroissants

Chaque prompt a un plafond. Le pousser au-delà, c’est optimiser du bruit.

Les premières itérations produisent généralement de grosses améliorations. Les prompts brouillons deviennent fonctionnels. Les prompts fonctionnels deviennent fiables. Mais à un moment, vos gains rétrécissent au point que vous ne pouvez plus distinguer le signal du hasard de façon fiable.

Un utilisateur de Hacker News décrivait avoir heurté ce mur en itérant avec des agents IA : ils “just spin and spin, burn 30 dollars for one prompt” (taosx, Hacker News). L’automatisation rend le piège pire. Quand itérer est gratuit, vous itérez pour toujours. Quand ça coûte de l’argent ou du temps, vous sentez les rendements décroissants dans votre portefeuille ou votre agenda.

Repérer le plafond

Vous avez atteint les rendements décroissants quand :

• Les changements produisent des sorties différentes, mais pas clairement meilleures
• Vous faites le même type de changement en boucle (plus spécifique, puis plus spécifique encore, puis encore plus spécifique)
• La qualité oscille au lieu de monter
• Vous passez plus de temps à décider si une sortie est meilleure qu’à tester des prompts

À ce stade, vous avez trois options. Accepter que la sortie actuelle est « assez bien ». Changer totalement d’approche. Ou reconnaître que la tâche dépasse peut-être ce que le prompting, à lui seul, peut accomplir.

Quand s’arrêter

La compétence la plus difficile, en itération de prompts, c’est de savoir quand s’arrêter. Pas parce que vous avez atteint la perfection, mais parce qu’un raffinement supplémentaire n’améliorera pas réellement vos résultats.

Un autre commentateur disait avoir réussi en se fixant une limite explicite : “Instead of over optimizing my prompt I just try to find the minimal amount of representation to get the llm to understand my problem” (someoneontenet, Hacker News). Le minimum suffisant est souvent meilleur que le théoriquement optimal.

« Assez bien » a un avantage de productivité. Chaque heure passée à optimiser un prompt qui marche déjà est une heure que vous ne passez pas sur autre chose. Le prompt parfait compte moins que vous ne le pensez, surtout pour les tâches où vous relirez la sortie de toute façon.

Méta-prompting : faire itérer l’IA à votre place

Il existe un raccourci qui marche parfois mieux que l’itération manuelle.

Au lieu d’affiner directement votre prompt, décrivez votre objectif à une IA et demandez-lui de générer un prompt pour cet objectif. Puis utilisez ce prompt généré dans une nouvelle conversation, sans contexte sur la manière dont vous l’avez obtenu.

Un praticien a documenté cette approche : “Ask Claude to come up with LLM prompt to solve problem” d’abord, puis utiliser le prompt généré dans une nouvelle conversation. Il a vu une amélioration de 148 à 428 mots en utilisant seulement 27 mots de méta-instructions, plutôt que de raffiner le prompt original directement (slt2021, Hacker News).

Ça marche parce que les modèles d’IA structurent souvent les prompts différemment des humains. Ils peuvent inclure un cadrage ou des consignes qui ne vous viendraient pas à l’esprit. La nouvelle conversation compte parce qu’elle élimine la pollution de contexte qui s’accumule pendant l’itération manuelle.

Le méta-prompting n’est pas toujours meilleur. Mais quand vous êtes bloqué, il offre un angle d’attaque différent.

L’itération comme apprentissage

Les prompts que vous écrirez dans six mois seront meilleurs que ceux que vous écrivez aujourd’hui. Pas parce que vous aurez mémorisé de meilleurs modèles, mais parce que vous aurez internalisé des schémas par la répétition.

Chaque itération vous apprend quelque chose sur la façon dont les modèles de langage interprètent des consignes, même quand l’itération n’améliore pas votre sortie. Avec le temps, vous développez des intuitions sur le choix des mots, la structure, le niveau de précision, et les exemples qui rendent vos premiers jets meilleurs.

L’état d’esprit d’itération dépasse les prompts individuels. Chaque projet qui implique du prompting vous apprend quelque chose de transférable. Les schémas qui marchaient pour générer du texte marketing peuvent influencer votre manière d’aborder des prompts de revue de code. Les modes d’échec rencontrés dans un domaine réapparaissent dans d’autres.

Comme l’observait un commentateur : “just practice. With different systems; sd, mj, chatgpt, gpt3, gptj etc.” (anonzzzies, Hacker News). L’étendue de l’expérience compte autant que la profondeur sur un seul système, en partie parce que différents modèles révèlent différents aspects de la façon dont le prompting fonctionne.

Le prompt engineering est une discipline empirique déguisée en discipline linguistique. Vous apprenez en faisant et en observant, pas en lisant des règles et en les appliquant. Les itérations qui donnent l’impression d’être du temps perdu alimentent souvent des intuitions que vous utiliserez des années plus tard sur des problèmes complètement différents.

Alors itérez. Notez ce qui marche. Repérez quand vous tournez en rond. Recommencez quand il le faut.

Mais reconnaissez aussi que le but n’est pas d’avoir un prompt parfait. Le but, c’est une sortie qui accomplit ce dont vous aviez besoin. Parfois, « assez bien » est vraiment assez bien, et la meilleure itération, c’est celle où vous décidez d’arrêter.