Comment savoir si une IA fait bien son travail : les évals

Une éval, c'est un jeu de cas de test associés à un critère de réussite clair, qu'on fait passer à une IA pour mesurer sa qualité au lieu de se fier à l'impression « ça a l'air bien ». Tu donnes une entrée (une vraie question), tu connais la bonne réponse attendue, et tu vérifies si le modèle l'atteint. Répété sur vingt ou cent cas, ça transforme un ressenti vague en un score que tu peux suivre.

Le mot vient de l'anglais evaluation. Dans le monde de l'IA, une éval désigne ce protocole de mesure, pas une opinion. C'est la différence entre « j'ai testé trois prompts ce matin, le deuxième me plaît bien » et « le deuxième prompt réussit 17 cas sur 20, contre 12 pour le premier ».

Pourquoi « ça a l'air bien » ne suffit pas

Un assistant ou un agent IA produit du texte fluide, même quand il se trompe. C'est précisément le piège. Une réponse bien tournée peut contenir une erreur de prix, inventer une politique de retour qui n'existe pas, ou répondre à côté. Le coup d'œil humain attrape les ratés grossiers, pas les fautes discrètes répétées à l'échelle.

Tester à la main marche pour trois exemples. Dès que tu changes un prompt, mets à jour le modèle, ou ajoutes une règle, tu ne peux pas rejouer tous les cas de tête. Et tu n'as aucune trace : impossible de dire si la version d'aujourd'hui est meilleure que celle de la semaine dernière.

C'est pour ça que les équipes traitent désormais l'éval comme un contrôle de passage avant déploiement, au même titre qu'un test logiciel. Une réponse qui régresse est repérée avant qu'un client ne la voie, pas après.

Ce qu'une éval mesure

Tout dépend de la tâche. Voici les angles les plus utiles à couvrir.

• Exactitude : la réponse est-elle juste sur les faits ? Le bon prix, la bonne procédure, la bonne date.
• Respect du format : si tu attends un JSON, parse-t-il sans erreur ? Si tu veux trois phrases, en a-t-il trois ?
• Ton : la réponse reste-t-elle dans la voix voulue, polie et claire, sans dériver vers le jargon ou la familiarité ?
• Refus des demandes hors cadre : l'assistant décline-t-il poliment une question qui sort de son rôle, plutôt que d'inventer ?
• Robustesse : tient-il le coup face à une question mal formulée, avec des fautes de frappe ou un détail piège ?

Tu ne mesures pas tout à la fois. Tu choisis les deux ou trois critères qui comptent vraiment pour ton usage, et tu les rends vérifiables. Pour ça, deux familles de vérification se complètent. Les contrôles déterministes répondent par oui ou non en une fraction de seconde : le texte contient-il un numéro de téléphone, le JSON est-il valide, le libellé renvoyé fait-il partie des étiquettes prévues. Pour les jugements plus fins comme le ton ou la pertinence, on s'appuie sur un relecteur humain ou, de plus en plus, sur un autre modèle qui note la réponse selon une grille (l'approche dite LLM-as-judge).

Commencer simple : vingt cas réels

Pas besoin d'outillage sophistiqué pour démarrer. La méthode tient en trois gestes.

1. Rassemble vingt cas réels. De vraies questions posées par des clients ou des collègues, pas des exemples inventés. Les vrais cas portent les formulations bancales et les pièges que tu n'aurais pas imaginés.
2. Écris la bonne réponse attendue pour chacun, ou au moins le critère qui dit « réussi ». Parfois c'est un fait exact à retrouver, parfois c'est juste « doit refuser et rediriger vers le service compétent ».
3. Rejoue ce jeu à chaque changement. Nouveau prompt, nouveau modèle, nouvelle règle : tu repasses les vingt cas et tu compares le score. Une baisse, et tu sais que ton changement a cassé quelque chose.

Ce jeu de cas grandit avec toi. Chaque fois qu'une erreur passe en production, tu l'ajoutes comme nouveau cas. Ton éval devient la mémoire de tous les ratés que tu as déjà vus, pour ne pas les revivre.

Éval maison contre benchmark public

On confond souvent les deux. Un benchmark est une épreuve standardisée, publique, qui classe les modèles sur des capacités générales (raisonnement, code, lecture). Utile pour choisir entre deux modèles au départ. Mais il ne dit rien de ta tâche précise. Pour creuser, vois à quoi servent vraiment les benchmarks LLM.

Une éval maison, elle, mesure ton besoin réel, avec tes cas et ton critère. C'est elle qui tranche.

	Benchmark public	Éval maison
Mesure	Capacité générale du modèle	Ta tâche précise
Cas de test	Standardisés, partagés	Tes vraies questions
Sert à	Comparer deux modèles	Valider avant de déployer
Verdict	« Ce modèle est bon en général »	« Ce modèle fait MON travail »

Un modèle peut dominer un benchmark et rater ton cas d'usage, parce que tes données et tes contraintes ne ressemblent à aucune épreuve standardisée.

Un exemple chez Maisons&Mobilia

Pierre, qui dirige Maisons&Mobilia (M&M), veut ouvrir un assistant IA au service après-vente pour répondre aux messages des clients sur les livraisons et les retours. Avant de le brancher en direct, Sophie monte une éval.

Elle exporte vingt messages clients réels du mois passé : un retard de canapé, un meuble arrivé abîmé, une demande de facture, une question de garantie, et un client qui demande poliment un remboursement total non prévu par la politique. Pour chacun, elle note la bonne réponse, ou le bon comportement attendu (« sur le remboursement hors politique, l'assistant doit refuser avec ménagement et proposer un avoir »).

Premier passage : l'assistant réussit 14 cas sur 20. Il invente une fenêtre de retour de 60 jours alors que M&M en accorde 30, et il accepte le remboursement total qu'il aurait dû décliner. Sophie corrige le prompt avec les vraies règles, rejoue les vingt cas, et remonte à 19 sur 20. Le cas qui résiste, un message très ambigu, part dans la file humaine. C'est seulement là que Pierre autorise la mise en service. Sans l'éval, les deux fautes seraient parties chez de vrais clients.

Cette discipline vaut encore plus pour un agent qui agit (émettre un avoir, créer un ticket), où une erreur a des conséquences. C'est le rôle des garde-fous des agents IA : l'éval mesure, les garde-fous limitent les dégâts.

Aller plus loin

Une éval est l'antidote concret au risque que l'IA affirme du faux avec aplomb, ce qu'on appelle l'hallucination : tes cas de test la rendent visible et chiffrable. Si tu construis un agent IA pour le service client, commence par les vingt cas avant d'écrire la moindre automatisation. Et si tu pars d'un assistant IA monté sans coder, la même règle tient : vingt vrais cas, un critère clair, un score que tu surveilles à chaque changement.

Dans l'app saisir.ai, plusieurs modules te font manipuler ces idées sur des cas concrets, pour passer de « ça a l'air bien » à « voilà mon score ».