Évaluer les outputs : comment savoir si ça marche ?
Vous avez construit un outil qui résume les avis clients. Vous l'avez testé deux fois, ça avait l'air très bien, vous l'avez mis en production. Trois semaines plus tard, quelqu'un vous montre un résumé qui qualifie un avis cinq étoiles de « négatif ». Depuis combien de temps cela se produisait-il ? Vous n'en avez aucune idée, parce que vous ne l'avez jamais mesuré.
C'est le piège. « Ça avait l'air correct » est une impression, pas une métrique. Pour améliorer un système d'IA, il vous faut une façon de le noter qui ne dépende pas de votre humeur de l'après-midi.
Cet outil s'appelle un eval (pour « evaluation ») : un test reproductible qui mesure à quel point votre IA remplit une tâche précise.
Pourquoi « ça a l'air correct » ne tient pas
Les grands modèles de langage sont non déterministes. Cela signifie que le même prompt peut donner des réponses légèrement différentes à chaque fois. Vérifier un output ne vous dit donc presque rien sur les cent suivants.
Vous modifiez aussi les choses en permanence : vous ajustez un prompt, vous passez de GPT-4o à un modèle moins cher, vous ajoutez une instruction. Chaque changement peut aider un cas et en casser un autre en silence. Sans score, vous volez à l'aveugle.
Un eval règle ce problème. Vous construisez une fois un petit jeu de cas de test, puis vous le lancez chaque fois que vous changez quelque chose. Le score monte ou descend. Là, vous pouvez vraiment progresser.
L'idée centrale : un jeu de test
Un jeu de test est un ensemble d'inputs d'exemple associés à ce à quoi ressemble un bon output. Pour un outil de résumé, la version la plus simple est un ensemble de paires question-réponse.
Voilà l'astuce. Au lieu d'essayer de noter un résumé entier (difficile et flou), vous écrivez des questions précises auxquelles un résumé correct doit pouvoir répondre.
Disons que vous résumez cet avis produit :
« Le blender est puissant et broie la glace facilement, mais il est extrêmement bruyant et le couvercle fuit si on le remplit au-delà de la moitié. La livraison a pris deux semaines. »
Vous écrivez des questions dont les réponses devraient survivre au résumé :
| Question | Réponse attendue |
|---|---|
| Le blender est-il puissant ? | Oui |
| Quelle est la principale plainte sur le bruit ? | Il est bruyant |
| Le couvercle pose-t-il un problème ? | Oui, il fuit quand on remplit trop |
| La livraison a-t-elle été rapide ? | Non, deux semaines |
Si le résumé vous permet de répondre correctement aux quatre, il a conservé les faits importants. S'il laisse tomber la fuite du couvercle, vous le détectez.
Cela transforme une question vague (« est-ce un bon résumé ? ») en une question concrète et quantifiable (« combien de ces faits a-t-il préservés ? »).
Construire un vrai eval, étape par étape
Construisons-en un minuscule. Il vous faut trois choses :
- Des inputs : une poignée d'avis (commencez par 10 à 20, pas 1 000).
- Des vérifications : des paires question-réponse pour chaque input.
- Un scorer : quelque chose qui décide si c'est réussi ou raté.
Étape 1 : rassembler les inputs et les faits attendus
Stockez-les comme de simples données. Aucune base en code n'est nécessaire pour lire ceci :
test_cases = [
{
"review": "The blender is powerful and crushes ice easily, "
"but it is extremely loud and the lid leaks if you "
"fill it past the halfway line. Shipping took two weeks.",
"must_include": ["loud", "leak", "powerful"],
},
{
"review": "Battery lasts all day and the screen is bright. "
"Setup was confusing and customer support never replied.",
"must_include": ["battery", "setup", "support"],
},
]La liste must_include est une version simplifiée de vos « réponses » : les faits clés que le résumé doit mentionner.
Étape 2 : générer les résumés
Ici on appelle un modèle. Cet exemple utilise l'APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → OpenAI, mais le principe est identique pour Claude ou Gemini.
from openai import OpenAI
client = OpenAI()
def summarize(review):
response = client.chat.completions.create(
model="gpt-4o-mini",
messages=[
{"role": "system", "content": "Summarize this product review in one sentence. Keep the key pros and cons."},
{"role": "user", "content": review},
],
)
return response.choices[0].message.contentÉtape 3 : le noter
Le scorer le plus simple possible : le résumé contenait-il chaque mot-clé requis ?
def score(summary, must_include):
hits = [word for word in must_include if word.lower() in summary.lower()]
return len(hits) / len(must_include)
total = 0
for case in test_cases:
summary = summarize(case["review"])
s = score(summary, case["must_include"])
total += s
print(f"Score: {s:.2f} | {summary}")
print(f"\nAverage score: {total / len(test_cases):.2f}")Lancez-le. Vous obtiendrez peut-être une moyenne de 0,83. Ce chiffre est votre baseline. Maintenant, changez votre prompt, relancez, et regardez le chiffre bouger. Vers le haut, c'est bien. Vers le bas, c'est que vous venez de casser quelque chose, et vous l'avez vu avant vos utilisateurs.
La correspondance de mots-clés est grossière. Ce n'est pas grave pour démarrer.
Chercher le mot « fuit » rate un résumé qui dit « le couvercle laisse passer du liquide ». Le scoring par mots-clés est brut, mais il est gratuit, rapide, et attrape les régressions évidentes. Commencez là.
Quand cela ne suffira plus, l'étape suivante est le LLM-as-judge : vous demandez à un second modèle d'IA de noter l'output. Vous lui donnez l'avis, le résumé et une grille, et vous demandez un score.
def judge(review, summary):
prompt = f"""Original review: {review}
Summary: {summary}
Does the summary capture the main pros AND cons?
Answer only PASS or FAIL."""
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": prompt}],
)
return response.choices[0].message.content.strip()Cela capte le sens, pas seulement les mots exacts. Le hic : le juge est aussi une IA, il peut donc se tromper. Vérifiez ses notes par échantillonnage face à votre propre jugement sur quelques cas avant de lui faire confiance.
Vérification des acquis
1. Quel est l'objectif central d'un « eval » tel que décrit dans la leçon ?
2. Pourquoi se fier à « ça avait l'air correct » ne fonctionne-t-il pas pour juger un système d'IA ?
3. Pourquoi la leçon recommande-t-elle d'écrire des paires question-réponse précises plutôt que de noter directement un résumé entier ?
4. Sélectionnez TOUTES les raisons données par la leçon pour lesquelles un eval devient précieux quand vous modifiez votre système. (Sélectionnez TOUTES les bonnes réponses)
Sélectionnez toutes les réponses correctes.
5. Pour un jeu de test d'outil de résumé, qu'est-ce qui fait une bonne paire question-réponse selon la leçon ? (Sélectionnez TOUTES les bonnes réponses)
Sélectionnez toutes les réponses correctes.
Lire ses scores sérieusement
Un chiffre unique est un début, mais la façon de le regarder compte.
Suivez-le dans le temps. Enregistrez la moyenne de chaque run. Un tableur suffit. Quand le score passe de 0,85 à 0,72 après avoir « amélioré » le prompt, vous revenez en arrière.
Regardez les échecs, pas la moyenne. La moyenne de 0,83 cache quels cas ont échoué. Lisez toujours les pires. C'est là que vous apprenez où votre IA galère : avis longs, sarcasme, plusieurs langues.
Ajoutez des cas difficiles délibérément. Quand un utilisateur signale un mauvais résumé, ne le corrigez pas simplement. Ajoutez-le à votre jeu de test comme cas permanent. Votre eval devient plus intelligent chaque fois que quelque chose se passe mal. Cette collection est parfois appelée golden set : votre réserve d'exemples de confiance.
Fixez votre seuil de réussite. Est-ce que 0,83 suffit pour partir en production ? Cela dépend de l'enjeu. Résumer des mèmes : d'accord. Résumer des instructions médicales : absolument pas. Vous fixez le seuil selon le coût de l'erreur.
Un mot sur l'état d'esprit
Les evals ressemblent à du travail en plus quand on a hâte de livrer. Ce n'est pas de la surcharge. C'est ce qui vous permet d'aller vite sans casser des choses en silence.
Voyez ça comme la cuisine. Goûter le plat une fois, c'est « ça avait l'air correct ». Une recette avec des quantités mesurées et un minuteur, c'est un eval. La recette est ce qui vous permet de refaire le même bon plat cent fois, et de l'améliorer volontairement.
Commencez de façon absurdement petite. Dix cas de test et une vérification de mots-clés valent mieux que zéro. Vous pourrez toujours l'étoffer.
Si vous voulez un guide plus approfondi mais toujours lisible, la documentation OpenAI Evals explique comment lancer des evals structurés avec leur outillage, et les concepts se transposent à n'importe quel modèle.
Comment cela se place avec ChatGPT, Claude et Gemini
Vous n'avez pas toujours besoin de code. Si vous prototypez dans l'interface de chat, vous pouvez faire un eval léger à la main :
- Collez votre prompt de résumé.
- Donnez-lui vos 10 avis de test un par un.
- Pour chacun, posez-vous les paires question-réponse et comptez les réussites/échecs.
Les trois outils majeurs (ChatGPT, Claude et Gemini) vous permettent aussi d'uploader un fichier d'exemples et de demander au modèle de noter son propre lot selon une grille que vous écrivez. C'est un LLMLLMUn Large Language Model est un système d'IA entraîné sur d'énormes volumes de texte pour prédire et générer du langage, ce qui permet de rédiger, résumer ou répondre à des questions.Voir la définition complète →-as-judge manuel. C'est plus lent que du code mais ne demande aucune installation, et c'est une très bonne façon de démarrer avant d'automatiser.
L'état d'esprit est le même partout : définir ce que « bon » veut dire en termes concrets et vérifiables avant de faire confiance à l'output.
Points clés
- Remplacez « ça a l'air correct » par un chiffre. Construisez un petit jeu de test d'inputs, avec les faits qu'un bon output doit contenir, puis notez par rapport à cela.
- Commencez minuscule et grossier. Dix cas de test avec une simple correspondance de mots-clés valent infiniment mieux qu'aucun eval. Vous l'étofferez ensuite.
- Relancez votre eval après chaque changement de prompt ou de modèle, et suivez le score dans le temps pour attraper les régressions silencieuses.
- Lisez les échecs, pas seulement la moyenne. Ajoutez chaque mauvais cas réel à votre golden set pour que votre eval s'affine avec le temps.
- Alignez votre seuil de réussite sur l'enjeu. Un résumé de mèmes et un résumé de posologie ne méritent pas le même seuil.
À faire, tiré de cette leçon
Ces actions sont compilées dans le plan d'action du rôle.
- Annoter 100 exemples réels à la main et évaluer les résultats face à ces annotations
- Relancez votre eval après chaque changement de prompt ou de modèle
Articles liés
Les articles récents du blog qui s'appuient sur cette leçon.
- IA600 millions de raisons de comprendre d'où vient le vibe codingLovable dépasse 600 millions de dollars de revenus annualisés et ses applications totalisent près d'un milliard de vues mensuelles. Pour comprendre ce que cela signifie vraiment, il faut remonter à l'époque où écrire du code était le seul moyen de construire un logiciel.
- IALa dépense IA par employé recule : alerte ou ajustement normal ?En août 2026, les dépenses IA par employé ont chuté dans plusieurs grandes entreprises, au moment même où les hyperscalers misaient sur une adoption en accélération. Avant de conclure à un essoufflement, il faut regarder ce que ces chiffres mesurent réellement, et ce qu'ils occultent.
- IAROI de l'IA : le guide de terrain des références qui comptentMesurer le retour sur investissement de l'IA reste l'un des exercices les plus mal balisés du management moderne. Ce guide passe en revue les acteurs, chercheurs et cas d'usage dont les approches méritent d'être connus de quiconque veut chiffrer sérieusement l'impact de l'IA dans son organisation.