Évaluation continue : le chaînon manquant des projets IA

C'est ce qui le rend difficile à exploiter. Un service classique s'arrête, renvoie une erreur, déclenche une alerte : la panne est un événement.

Un système d'IA générative, lui, continue de répondre. Il répond simplement moins bien. La dégradation n'a pas de signal, et elle se manifeste plusieurs semaines plus tard, sous la forme d'un désengagement des utilisateurs que personne ne relie à une cause technique.

Ce n'est pas un banc d'essai académique. C'est un fichier de trente à cent cas réels, chacun avec sa question, le contexte attendu et une réponse de référence validée par le métier.

Trois propriétés le rendent utilisable. Il est stable : on n'ajoute pas de cas sans raison, sinon on ne compare plus rien. Il est représentatif : il contient les cas tordus, pas seulement les cas de démonstration. Et il est rejouable en une commande : si l'exécution demande une demi-journée de préparation, elle ne sera pas faite.

C'est la difficulté propre à l'IA générative, et il n'existe pas de solution parfaite. En pratique, trois niveaux se combinent bien.

Le premier est factuel et automatique : la réponse cite-t-elle le bon document, contient-elle le bon montant, la bonne date, la bonne référence. C'est binaire, donc fiable, et cela couvre déjà une grande partie des régressions graves.

Le deuxième fait juger la réponse par un autre modèle, sur des critères écrits. C'est utile pour détecter une dérive de ton ou une réponse hors sujet, mais cela ne remplace pas le troisième : une relecture humaine périodique sur un échantillon, qui reste le seul juge dont la mesure fait autorité.

Constituer un premier jeu de tests demande environ deux jours de travail métier. L'automatiser en demande un ou deux de plus.

En face, cela permet de changer de modèle en connaissance de cause plutôt qu'à l'aveugle, un exercice qui revient plusieurs fois par an, et de répondre par des chiffres à la question qui décide du renouvellement du budget. Je considère aujourd'hui qu'un système sans évaluation continue n'est pas en production : il est en démonstration prolongée.

Quatre décisions qui prenaient des semaines se prennent en deux heures : changer de modèle, descendre de palier, modifier le prompt, arbitrer entre récupération et fenêtre longue. C'est ce qui justifie la journée d'investissement.

Ces quatre décisions reviennent en permanence sur un système en exploitation, à raison de plusieurs fois par an chacune.

Une équipe qui les traite en deux heures avance ; une équipe qui les traite en réunion recule, parce que la discussion se conclut au grade plutôt qu'aux chiffres. Le protocole de bascule est détaillé dans choisir le palier, pas le modèle.

Toute réponse fausse signalée devient une ligne du jeu de tests, le jour même, sans analyse ni réunion. C'est la seule discipline nécessaire, et elle suffit.

Deux effets en découlent. Le jeu grossit exactement là où le système est faible, ce qui est la seule croissance utile. Et il devient impossible de réintroduire une erreur déjà corrigée, ce qui est le bénéfice le plus sous-estimé.

J'ajoute une limite haute : au-delà de cent cinquante cas, le jeu devient long à relancer et cesse d'être utilisé. Il faut alors le scinder par famille de tâches, comme décrit dans construire un jeu de tests en une journée.

« Nos réponses ne sont pas vérifiables automatiquement » confond vérification automatique et vérification rapide. L'objection est fausse dans la quasi-totalité des cas.

Beaucoup de réponses ne se comparent pas caractère par caractère. Presque toutes se vérifient en dix secondes par quelqu'un qui connaît le domaine. Trente cas relus en cinq minutes constituent un jeu parfaitement exploitable.

L'intermédiaire utile consiste à vérifier automatiquement ce qui l'est, le document cité, la présence d'un chiffre, l'absence de refus, et à relire le reste. Le suivi dans le temps se construit comme décrit dans ce qui occupe l'équipe la deuxième année.