Introduction a l'evaluation de prompts

Prompt engineering vs prompt evaluation

Vous avez appris a ecrire des prompts efficaces. Mais comment savez-vous qu’un prompt est reellement meilleur qu’un autre ? C’est la que l’evaluation de prompts entre en jeu.

• Le prompt engineering consiste a ecrire et affiner des instructions pour Claude
• L’evaluation de prompts consiste a mesurer objectivement la qualite des reponses produites

L’un sans l’autre ne sert a rien. Un prompt qui “a l’air bien” peut s’effondrer sur des cas limites. Un pipeline d’evaluation sans bon prompt ne produira que des scores bas.

Les trois approches apres avoir ecrit un prompt

Quand vous avez redige un prompt, vous avez trois options :

1. Tester une seule fois

Vous envoyez une requete, la reponse semble correcte, vous deployez.

Le probleme : Claude est non-deterministe. Une seule reponse ne prouve rien. Votre prompt peut tres bien fonctionner sur “Quelle est la capitale de la France ?” et echouer lamentablement sur “Quel est le plus petit pays d’Europe par population ?“.

2. Tester quelques fois a la main

Vous essayez 5-10 requetes differentes, vous verifiez visuellement. C’est mieux, mais :

• Vous etes biaise : vous testez inconsciemment les cas que votre prompt gere bien
• Vous ne pouvez pas comparer deux versions de prompt objectivement
• Vous ne detectez pas les regressions quand vous modifiez le prompt

3. Passer par un pipeline d’evaluation

Vous creez un jeu de donnees de test, vous faites tourner votre prompt sur chaque cas, et vous notez automatiquement les resultats. C’est la seule approche qui fonctionne a grande echelle.

Pourquoi les developpeurs tombent dans le piege

Le piege classique :

1. Vous ecrivez un prompt
2. Vous testez sur 2-3 exemples, ca marche
3. Vous deployez en production
4. Des utilisateurs reels envoient des requetes inattendues
5. Le modele produit des reponses mediocres ou incorrectes
6. Vous corrigez le prompt a la main, en cassant autre chose au passage
7. Retour a l’etape 2

Ce cycle est frustrant et inefficace. L’evaluation systematique le brise.

L’approche evaluation-first

L’idee est simple : avant de toucher au prompt, definissez comment vous allez mesurer son succes.

Etape 1 : Identifier les criteres de qualite

Que signifie “bonne reponse” pour votre cas d’usage ?

• Exactitude : les faits sont-ils corrects ?
• Format : la sortie respecte-t-elle le format attendu ?
• Completude : tous les points demandes sont-ils couverts ?
• Ton : le style est-il adapte au contexte ?
• Securite : le modele refuse-t-il les requetes hors scope ?

Etape 2 : Creer un jeu de test representatif

Un ensemble de cas d’usage reels couvrant :

• Les cas normaux (80% du trafic)
• Les cas limites (edge cases)
• Les cas adverses (tentatives de contournement)

Etape 3 : Automatiser la notation

Utiliser un systeme de notation (code, modele AI, ou humain) pour evaluer chaque reponse sur vos criteres.

Etape 4 : Iterer avec confiance

Quand vous modifiez votre prompt, relancez l’evaluation. Le score monte ? Vous avez ameliore. Il baisse ? Vous avez casse quelque chose. Pas de doute, pas de debat — des chiffres.

Ce que cette section va couvrir

Dans les prochaines lecons, vous allez :

1. Mettre en place un workflow d’evaluation complet
2. Generer des jeux de test automatiquement avec Claude
3. Executer l’evaluation sur votre prompt
4. Implementer un systeme de notation par modele pour automatiser le scoring

A la fin de cette section, vous aurez un pipeline d’evaluation reutilisable pour n’importe quel projet avec Claude.