Introduction aux évaluations de prompts

Écrire un bon prompt n’est que le début. Pour construire une application fiable, il faut savoir mesurer ce que ce prompt produit, sur des cas variés, et comparer objectivement deux versions. Cette leçon ouvre la troisième section du cours : elle distingue ingénierie et évaluation de prompts, décrit les trois chemins qui s’offrent après un premier jet, et pose la démarche que les leçons suivantes outillent.

Ingénierie et évaluation : deux disciplines

L’ingénierie de prompts est votre boîte à outils pour écrire des prompts efficaces : exemples, balises XML, consignes claires et précises (section 4). L’évaluation de prompts mesure ce que ces prompts produisent vraiment, par des tests automatisés : comparer les sorties à des réponses attendues, confronter deux versions d’un même prompt, repérer les erreurs. L’une sans l’autre ne mène pas loin : un prompt qui « a l’air bien » peut s’effondrer sur des cas limites, et un pipeline d’évaluation sans travail sur le prompt ne produit que des scores bas.

Trois chemins après un premier jet

Le cours officiel décrit les trois options qui s’offrent une fois un prompt rédigé.

1. Le tester une fois et le juger suffisant. Le risque est grand de le voir casser en production, dès que les utilisateurs envoient des entrées imprévues.
2. Le tester quelques fois et le retoucher pour un ou deux cas limites. C’est mieux, mais les utilisateurs trouveront des entrées que vous n’avez pas envisagées, et vous testez inconsciemment les cas que votre prompt gère bien.
3. Le faire passer dans un pipeline d’évaluation, qui le note, puis l’améliorer d’après des mesures objectives. Plus de travail et un peu de coût, mais beaucoup plus de confiance dans sa fiabilité.

Les deux premiers sont des pièges dans lesquels tout le monde tombe, l’auteur du cours officiel compris : on sous-estime le nombre de cas limites que les vrais utilisateurs rencontreront. Le piège commence toujours par un succès. Le prompt marche sur deux ou trois exemples, on déploie ; puis arrivent les formulations ambiguës, les cas limites, les demandes hors périmètre ; on corrige à la main, en cassant au passage un comportement qui fonctionnait. À aucun moment on ne sait si le prompt s’améliore réellement.

La démarche « évaluation d’abord »

Le troisième chemin remplace « ça a l’air de marcher » par un score mesuré sur un jeu de cas représentatifs, avant la production. Il permet de repérer les faiblesses avant qu’elles ne deviennent des incidents, de comparer objectivement deux versions, d’itérer sur des améliorations mesurables. Il se décline en quatre temps :

• Définir ce qu’est une bonne réponse pour votre usage : exactitude, format, complétude, ton, refus des demandes hors périmètre.
• Réunir un jeu de test représentatif : les cas courants, les cas limites, les tentatives de détournement.
• Automatiser la notation, par du code, par un modèle ou, pour un échantillon, par une personne.
• Itérer : chaque modification du prompt est suivie d’une nouvelle évaluation. Le score monte, vous avez amélioré ; il baisse, vous avez cassé quelque chose.

Une précaution, que le cours officiel n’aborde pas : la même requête ne donne pas toujours la même réponse. Une évaluation sérieuse fait passer chaque cas plusieurs fois et regarde la dispersion des scores, pas un score isolé ; on ne peut plus, depuis 2026, fixer temperature à 0 pour figer les réponses (leçon 6).

Ce que la section va couvrir

1. Le workflow type d’une évaluation, en cinq étapes.
2. La génération de jeux de test avec Claude.
3. L’exécution de l’évaluation sur un prompt.
4. La notation par modèle, puis la notation par code.

Ce cours construit son propre pipeline en Python, pour en comprendre chaque pièce. Sur Google Cloud, il existe aussi un service géré : le service d’évaluation Gen AI d’Agent Platform sait évaluer les modèles partenaires comme Claude, à condition d’avoir activé le modèle dans Model Garden (leçon 2).

Pour aller plus loin, notre cours Évaluation de prompts reprend ces notions avec promptfoo, un juge à verdict structuré et l’évaluation en production.

À vous de jouer

Votre piège. Choisissez un prompt que vous utilisez déjà. Écrivez cinq entrées qu’un vrai utilisateur pourrait envoyer et que vous n’avez jamais testées : une ambiguë, une hors sujet, une très longue, une avec une faute de frappe, une qui tente de détourner l’assistant. Faites-les passer et notez combien de réponses vous livreriez.

Vos critères. Pour le même prompt, écrivez en une ligne chacun les trois critères qui définissent une bonne réponse. Ils serviront de grille à la leçon sur la notation par modèle.

Sources officielles : Prompt evaluation (Claude Academy) · Define success criteria and build evaluations (documentation Claude) · Gemini Enterprise Agent Platform partner models for MaaS (Google Cloud : évaluation des modèles partenaires)

Points clés à retenir

• L’ingénierie de prompts écrit, l’évaluation mesure ; il faut les deux.
• Tester une fois, ou quelques fois à la main, laisse passer les entrées réelles imprévues.
• Un pipeline d’évaluation note le prompt sur un jeu de cas et permet d’itérer sur des mesures.
• On définit d’abord ce qu’est une bonne réponse, puis on automatise la notation, et on répète les exécutions pour tenir compte de la variabilité.