C'est la question qui traverse tout usage professionnel de l'IA et à laquelle presque personne ne répond : comment savez-vous que ça marche ? Le plus souvent, la réponse est « les réponses ont l'air bien ». Ce n'est pas une mesure, c'est une impression, et elle se dégrade sans prévenir.
Définition
L'évaluation consiste à mesurer la qualité des sorties d'un système d'IA sur un ensemble de cas connus, de façon reproductible, pour pouvoir comparer deux versions.
Le mot important est comparer. Une évaluation ne sert pas à obtenir une note absolue, elle sert à répondre à une question précise : est-ce que ce changement a amélioré ou dégradé le résultat ?
Sans évaluation, chaque modification devient un pari. Vous changez une consigne, les trois réponses que vous testez semblent meilleures, vous déployez. Trois semaines plus tard, un cas que vous n'aviez pas regardé s'est mis à échouer, et personne ne sait quand.
Constituer un jeu de cas, la seule étape difficile
Une évaluation utile tient dans un tableau de vingt à cinquante lignes. Chaque ligne comporte une entrée réelle et ce que vous attendez en sortie.
Prenez de vrais cas. Vos vraies demandes clients, vos vrais documents. Des exemples inventés produisent une évaluation qui valide un système qui échouera en production.
Incluez ce qui rate. C'est le point décisif. Un jeu composé uniquement de cas faciles ne mesure rien. Les demandes ambiguës, hors périmètre ou mal rédigées sont celles qui font la différence entre deux versions.
Écrivez le critère de réussite. Pas « bonne réponse » mais quelque chose de vérifiable : contient le bon montant, cite le bon document, refuse de répondre, tient en trois phrases.
Gardez-le figé. Un jeu qu'on modifie à chaque test ne permet plus de comparer. Il évolue, mais délibérément, et on note quand.
Trois façons de juger, de la plus sûre à la plus souple
| Méthode | Quand l'utiliser | Limite |
|---|---|---|
| Vérification automatique | Le résultat est exact ou non | Ne convient qu'aux sorties factuelles |
| Relecture humaine | Qualité rédactionnelle, ton | Coûteuse, ne se rejoue pas souvent |
| Jugement par un modèle | Volume important, critères écrits | Le juge a ses propres biais |
La troisième mérite une précaution : un modèle qui juge des réponses produites par un modèle a tendance à préférer un certain style. Utilisez-la pour dégrossir, pas pour trancher un choix important.
Quand rejouer l'évaluation
À chaque changement de consigne. À chaque changement de modèle, y compris une mise à jour de version chez votre fournisseur, qui peut modifier le comportement sans que vous ayez rien touché. Et à intervalle régulier même sans changement, parce que vos données, elles, évoluent.
L'erreur classique consiste à évaluer sur les mêmes cas qui ont servi à écrire la consigne. Vous mesurez alors votre capacité à traiter ces cas précis, pas la qualité du système. Gardez un jeu de côté que vous n'utilisez jamais pour régler quoi que ce soit.
Questions fréquentes
Faut-il un outil dédié ?
Pas au début. Un tableur avec vos cas, un Workflow qui les rejoue et une colonne de résultat suffisent longtemps. Les outils spécialisés se justifient quand le volume de cas dépasse ce qu'un tableur rend lisible.
Combien de cas faut-il ?
Vingt bien choisis valent mieux que deux cents pris au hasard. La bonne mesure est la couverture : chaque type de demande que vous recevez doit apparaître au moins une fois, y compris les rares qui coûtent cher quand elles échouent.
Comment évaluer un système de RAG ?
Sur deux axes séparés, sinon vous ne saurez pas quoi corriger. D'abord la recherche : les bons extraits remontent-ils ? Ensuite la rédaction : la réponse s'appuie-t-elle vraiment sur ces extraits ? Un RAG peut échouer sur l'un sans échouer sur l'autre.
Par où commencer sans y passer une semaine ?
En notant pendant quinze jours les cas où le système vous a déçu : ce carnet devient votre premier jeu d'évaluation, et il est déjà représentatif. Notre formation Claude Cowork intègre cette pratique dès la mise en production plutôt qu'après.