Introduction aux évaluations de prompts

Écrire un bon prompt n’est que le début. Pour construire des applications IA fiables, deux disciplines complémentaires doivent travailler de concert : l’ingénierie de prompt — écrire de meilleurs prompts — et l’évaluation de prompt — mesurer objectivement leur efficacité. La première sans la seconde revient à régler un moteur sans compte-tours : on modifie, on a une impression, mais on ne sait jamais si on a réellement progressé. Cette section construit l’instrument de mesure ; la section suivante s’en servira pour améliorer les prompts en connaissance de cause.

Trois options après avoir écrit un prompt

Une fois un prompt rédigé, trois chemins s’offrent à vous, du plus expéditif au plus rigoureux.

Option 1 : le tester une fois, constater que la réponse a l’air correcte, et décider que ça suffit. C’est rapide — et c’est un pari : une exécution unique ne dit rien de ce que produira le prompt sur les mille entrées différentes que la production lui enverra. Le risque de cassure sur des entrées inattendues est élevé.

Option 2 : le tester quelques fois, repérer un ou deux cas limites, ajuster. C’est mieux — le prompt a survécu à quelques variations — mais l’échantillon reste minuscule et choisi par vous, avec vos angles morts. Les utilisateurs réels apporteront des formulations, des langues, des cas tordus que vous n’avez pas imaginés.

Option 3 : passer le prompt dans un pipeline d’évaluation qui le note objectivement sur un jeu d’entrées représentatif, puis itérer sur la base de données concrètes. C’est plus coûteux au départ — il faut construire le pipeline —, mais c’est le seul chemin qui produise de la fiabilité mesurable.

Le piège du test manuel

Les options 1 et 2 sont des pièges dans lesquels tombent tous les développeurs, y compris expérimentés — précisément parce qu’elles semblent raisonnables sur le moment. Il est naturel d’écrire un prompt, de le tester deux ou trois fois, et de se dire « ça a l’air bon ». Le problème est que cette impression ne se transporte pas : elle vaut pour les trois entrées testées, pas pour la distribution réelle du trafic. En production, l’approche se solde par des sorties mal formatées qui cassent le parsing, des réponses à côté sur les cas non prévus, et des régressions silencieuses à chaque « petite amélioration » du prompt — puisque rien ne mesure ce que la modification a dégradé ailleurs.

La valeur de l’évaluation systématique

L’option 3 change la nature du travail : elle fournit des données objectives sur la performance. Au lieu de vous fier à l’intuition ou à une poignée d’essais, vous obtenez un score mesurable — et surtout comparable. Vous pouvez modifier votre prompt et voir immédiatement si le changement améliore ou dégrade la performance, sur l’ensemble du jeu de test et non sur l’exemple que vous aviez sous les yeux. C’est ce qui transforme l’ingénierie de prompt d’un art d’impressions en une boucle d’amélioration outillée : hypothèse, mesure, décision. Les prochaines leçons construisent ce pipeline pièce par pièce — jeu de données, exécution, notation — jusqu’à pouvoir chiffrer chaque idée d’amélioration.

Points clés à retenir

• Deux disciplines complémentaires : l’ingénierie écrit les prompts, l’évaluation mesure leur efficacité
• Tester une ou quelques fois ne renseigne que sur ces essais-là — pas sur la distribution réelle des entrées
• « Ça a l’air bon » est le piège classique : l’impression ne détecte ni les cas limites ni les régressions
• Un pipeline d’évaluation donne un score objectif et comparable entre versions d’un prompt
• Coût initial plus élevé, mais c’est le seul chemin vers une amélioration mesurée et sans recul caché