15 mai 2026
Comment évaluer un modèle IA en production : métriques, evals et pièges à éviter
Un cadre concret pour évaluer un système LLM en production sans se tromper de métriques, ni confondre benchmark, qualité réelle et valeur métier.
L'accuracy seule rassure, mais elle ment vite
Beaucoup d'équipes évaluent un système IA comme un classifieur classique : un score d'accuracy sur un jeu de test, puis validation. Avec un LLM, ce raccourci casse vite. Un assistant peut faire 88 % sur un dataset propre et devenir pénible dès qu'il voit des requêtes ambiguës, des documents obsolètes ou une forte charge. En production, on ne juge pas une performance abstraite, mais un service dans un workflow réel.
Sur un copilote support, la question n'est pas seulement "a-t-il raison ?". Il faut aussi regarder le temps de réponse, la stabilité de sortie, la part de réponses inventées et le taux de drafts acceptés sans réécriture lourde. Une accuracy correcte peut cacher un système lent, instable ou trop risqué. La vraie question est : améliore-t-il le travail sans créer un nouveau coût de contrôle ?
Le bon cadre d'eval : mesurer le système, pas juste le modèle
Un cadre d'évaluation utile couvre plusieurs dimensions. D'abord la latence, en p50 et p95, parce qu'un outil à huit secondes n'est pas adopté. Ensuite la consistance : à entrée équivalente, le système garde-t-il le même niveau de prudence et de structure ? Ensuite le taux d'hallucination, c'est-à-dire la fréquence des affirmations non soutenues par les sources. Puis viennent les métriques métier : taux de résolution, temps économisé, taux d'escalade ou distance d'édition.
Il faut surtout découper la chaîne. Sur un assistant documentaire, je sépare retrieval, qualité de réponse, qualité de citation, capacité à dire "je ne sais pas" et signal utilisateur final. Si vous mélangez tout dans une note globale, vous ne savez pas où agir. Une bonne eval n'est pas un trophée ; c'est un outil de diagnostic.
Offline evals et online evals : deux boucles différentes
Les evals offline servent à tester hors production, sur des cas connus. Elles permettent de comparer un prompt, une version de modèle ou une stratégie RAG avant release. Elles sont indispensables pour attraper les régressions, mais elles restent une photo partielle de la réalité. Un bon test set vieillit vite dès que les formulations changent ou que de nouveaux cas apparaissent.
Les evals online montrent ce qui se passe vraiment : shadow mode, A/B tests, rollouts progressifs, revue humaine, signaux d'acceptation, clics sur régénération, corrections manuelles, taux d'escalade. L'offline sert de garde-fou avant release. L'online sert de vérité opérationnelle après release. Les équipes sérieuses ont besoin des deux.
Les pièges classiques qui faussent tout
Premier piège : sur-optimiser son benchmark interne. On écrit cinquante cas, on tune le prompt, on annonce victoire. En réalité, on a surtout appris à gagner son propre examen. Deuxième piège : ignorer les changements de distribution. En production, les entrées bougent sans arrêt. Troisième piège : ne pas avoir de baseline. Sans comparaison avec le process humain, une règle simple ou la version précédente, impossible de dire si l'IA améliore quoi que ce soit.
J'ajouterais un piège très courant avec les LLM : ne pas mesurer les bons refus. Un système utile doit parfois s'abstenir. Un assistant qui répond partout avec assurance peut paraître fort en démo et être intenable en prod. Sans baseline, sans cas frais et sans revue régulière des échecs, vous n'évaluez pas un produit. Vous entretenez un benchmark décoratif.
Par où commencer : une boucle minimale en trois étapes
Point de départ simple. Étape 1 : choisissez une tâche étroite et écrivez un premier set d'eval réaliste, même petit. Trente à cinquante exemples bien choisis suffisent. Pour chaque cas, définissez ce qu'est une bonne sortie, une sortie acceptable, une sortie dangereuse et quand l'abstention est la bonne réponse. Étape 2 : instrumentez la production dès le départ. Loggez entrées, sorties, latence, version du prompt ou du modèle, et un signal utilisateur simple : accepté, modifié, rejeté, escaladé.
Étape 3 : imposez un rituel court. Avant chaque release, passez le set offline. Après release, revoyez chaque semaine un échantillon de sorties réelles et ajoutez les échecs importants au test set. C'est la boucle minimale qui marche : un baseline, un jeu de tests vivant et des signaux production reliés au workflow métier. Ce n'est pas spectaculaire, mais c'est ce qui transforme un prototype convaincant en système exploitable.