La première réponse n'est jamais la meilleure
Vous demandez une fonction à l'IA. Elle vous sort vingt lignes propres en apparence, vous dites « merci », et vous collez ça dans votre projet. Une semaine plus tard, un audit révèle une faille d'injection SQL et trois cas limites non gérés. L'IA pouvait faire mieux. Vous ne lui avez juste pas demandé.
Comme un humain qui relit sa copie après la pause, l'IA est bien meilleure pour critiquer un texte existant que pour le produire parfait du premier coup. La génération et l'évaluation sont deux modes de pensée différents. C'est tout l'intérêt du pattern évaluateur-optimiseur : on sépare les deux.
L'idée : au lieu d'accepter la première sortie, vous demandez à l'IA de noter son propre travail selon des critères explicites, puis d'améliorer ce qui est faible. Une passe critique fraîche attrape ce que la passe de génération a laissé filer.
La boucle générer → noter → améliorer
Le cœur du pattern est une boucle récursive :
- Générer : l'IA produit une première version.
- Noter : elle évalue cette version contre une grille de critères et attribue un score à chacun.
- Améliorer : elle corrige les points sous le seuil que vous avez fixé.
- Re-noter : on recommence, jusqu'à ce que les scores cessent de monter.
Concrètement, en deux prompts enchaînés :
Prompt 1 :
Note ce code de 1 à 10 sur 4 axes : lisibilité, sécurité,
performance, gestion d'erreurs. Donne une note par axe ET
explique chaque note avec un exemple précis tiré du code.
Prompt 2 :
Améliore tous les axes notés sous 8, sans toucher au reste.
Puis re-note le nouveau code sur les mêmes 4 axes.Vous verrez souvent les notes passer de 6/10 à 9/10 en une itération, parce que l'IA a enfin regardé son propre code au lieu de le cracher.
Écrire une grille qui veut dire quelque chose
« Est-ce que c'est bien ? » est une question inutile : l'IA répondra « oui, c'est bien ». Une grille efficace repose sur des axes concrets et mesurables, chacun avec une définition claire de ce que vaut un 10 :
- Lisibilité : noms explicites, fonctions courtes, pas de logique imbriquée à cinq niveaux.
- Sécurité : entrées validées, requêtes préparées, secrets non codés en dur.
- Performance : pas de requête dans une boucle, complexité raisonnable.
- Gestion d'erreurs : cas limites traités, échecs explicites, pas de
catchvide.
Toujours demander une note par axe, jamais une note globale. Une moyenne de 8/10 cache un 4/10 en sécurité. Le détail par critère est ce qui rend la boucle pilotable.
Savoir s'arrêter
La boucle a des rendements décroissants. Le passage de 6 à 8 transforme le code ; celui de 9,2 à 9,4 ne fait souvent que déplacer des virgules et ajouter des commentaires verbeux. Arrêtez-vous quand les scores plafonnent ou quand les changements deviennent cosmétiques.
L'IA est souvent trop sûre d'elle quand elle se note. Elle peut s'attribuer un 9/10 en sécurité sur du code vulnérable, parce que c'est elle qui l'a écrit. L'auto-évaluation est un outil pour itérer plus vite, pas un verdict : le jugement final reste le vôtre. Relisez le code, ne signez pas un chèque en blanc sur la note.
Astuce du « deuxième avis » : faites noter le code par un autre modèle que celui qui l'a écrit (par exemple Claude évalue ce que GPT a produit). Un évaluateur qui n'a pas d'ego dans le code repère des défauts que l'auteur s'auto-pardonne.
The first answer is never the best one
You ask the AI for a function. It produces twenty seemingly clean lines, you say "thanks", and you paste it into your project. A week later, an audit reveals a SQL injection flaw and three unhandled edge cases. The AI could have done better. You just did not ask it to.
Like a human re-reading their paper after a break, the AI is much better at critiquing existing text than producing it perfect on the first try. Generating and evaluating are two different modes of thinking. That is the whole point of the evaluator-optimizer pattern: you separate the two.
The idea: instead of accepting the first output, you ask the AI to score its own work against explicit criteria, then improve what is weak. A fresh critical pass catches what the generation pass missed.
The generate → score → improve loop
The heart of the pattern is a recursive loop:
- Generate — the AI produces a first version.
- Score — it evaluates that version against a rubric and gives each axis a score.
- Improve — it fixes the points below the threshold you set.
- Re-score — repeat, until the scores stop rising.
Concretely, in two chained prompts:
Prompt 1:
Score this code from 1 to 10 on 4 axes — readability, security,
performance, error handling. Give a score per axis AND explain
each score with a concrete example taken from the code.
Prompt 2:
Improve every axis scored below 8, without touching the rest.
Then re-score the new code on the same 4 axes.You will often see scores jump from 6/10 to 9/10 in one iteration, because the AI finally looked at its own code instead of spitting it out.
Writing a rubric that means something
"Is it good?" is a useless question: the AI will answer "yes, it is good". An effective rubric relies on concrete, measurable axes, each with a clear definition of what a 10 looks like:
- Readability — explicit names, short functions, no five-level nested logic.
- Security — validated input, prepared statements, no hardcoded secrets.
- Performance — no query inside a loop, reasonable complexity.
- Error handling — edge cases covered, explicit failures, no empty
catch.
Always ask for a score per axis, never a single overall score. An 8/10 average hides a 4/10 in security. The per-criterion detail is what makes the loop steerable.
Knowing when to stop
The loop has diminishing returns. Going from 6 to 8 transforms the code; going from 9.2 to 9.4 often just moves commas around and adds verbose comments. Stop when the scores plateau or when changes become cosmetic.
The AI is often over-confident when scoring itself. It may give itself a 9/10 on security for vulnerable code, because it wrote it. Self-evaluation is a tool to iterate faster, not a verdict: the final judgment stays yours. Re-read the code, do not sign a blank check on the score.
The "second opinion" trick: have the code scored by a different model than the one that wrote it (for example, Claude evaluates what GPT produced). An evaluator with no ego in the code spots flaws the author self-forgives.
Après avoir obtenu du code de l'IA, lancez la boucle d'auto-évaluation avec ce prompt :
Évalue le code que tu viens d'écrire. Note-le de 1 à 10 sur 4 axes : lisibilité, sécurité, performance et gestion d'erreurs. Pour chaque axe, donne la note ET justifie avec un exemple précis tiré du code. Ensuite, améliore tous les axes notés sous 8 sans dégrader les autres, puis re-note la nouvelle version sur les mêmes axes. Répète jusqu'à ce que les notes cessent de progresser, et dis-moi clairement quand tu atteins ce plateau.
Sans relire la leçon : explique avec tes mots la boucle générer → noter → améliorer, et pourquoi on demande une note par axe plutôt qu'une note globale.
Rédigez le prompt d'auto-évaluation que vous donneriez à l'IA. Il doit demander une note de 1 à 10 par axe (au moins lisibilité et sécurité), exiger une justification par note, et déclencher une amélioration des points faibles.
Vous demandez à l'IA de s'auto-évaluer. Voici sa réponse. Votre rôle de relecteur : l'accepter telle quelle ou la rejeter, et dire pourquoi.
Auto-evaluation du code :
Note globale : 9/10. Le code est propre et bien structure.
Quelques petits commentaires a ajouter, mais rien de bloquant.
Pret pour la production.Sans remonter dans la leçon : quelles sont les étapes de la boucle évaluateur-optimiseur, et à quel moment décide-t-on de s'arrêter ?
L'auto-évaluation reste limitée tant que l'IA ne voit pas le résultat réel. La prochaine leçon, donner des yeux à l'IA, montre comment lui fournir captures d'écran, logs et sorties concrètes pour qu'elle juge sur du visible, pas sur des suppositions.
Leçon 16 : Donner des yeux à l'IA →