Évaluer un LLM en production, c'est mesurer en continu si votre système répond correctement, et le prouver avant chaque mise à jour. Concrètement, vous constituez un jeu de cas représentatifs (le dataset d'évals), vous définissez des critères de succès objectifs, puis vous exécutez ces évals automatiquement à chaque changement de prompt, de modèle ou de code. Sans cette discipline, vous pilotez à l'aveugle.
En 2026, le sujet n'est plus la qualité brute des modèles. Claude Opus 4.7, GPT-5.5 ou Mistral Medium 3.5 produisent des réponses excellentes sur des benchmarks génériques. Le problème, c'est que votre cas d'usage n'est pas un benchmark générique. Un agent qui répond parfaitement en démo peut régresser de 15 % du jour au lendemain après une simple mise à jour de modèle côté fournisseur, ou après un ajustement de prompt qui semblait anodin.
Cet article décrit la méthode que nous appliquons chez Genee pour fiabiliser les automatisations à base d'IA : comment construire un dataset d'évals, quelles métriques choisir, comment utiliser un modèle comme juge, et comment intégrer tout cela dans une chaîne de non-régression. L'objectif : ne jamais découvrir une régression par un client mécontent.
Pourquoi les evals sont le vrai différenciateur
Le prompt est facile à copier. Le modèle est accessible à tout le monde. Ce qui distingue un système IA fiable d'un prototype, c'est sa capacité à mesurer sa propre qualité. Une équipe qui dispose de 200 cas d'évals documentés et automatisés détient un actif que ses concurrents n'ont pas : la certitude qu'une modification n'a rien cassé.
Trois forces rendent les evals indispensables en 2026 :
- Les modèles changent sous vos pieds. Les fournisseurs mettent à jour leurs modèles, parfois sans changement de version visible. Un comportement stable hier peut dériver aujourd'hui. Sans évals, vous ne le voyez pas.
- Les systèmes sont devenus des chaînes. Un agent moderne enchaîne RAG, appels d'outils, validations. Une régression peut surgir à n'importe quel maillon. Tester le LLM seul ne suffit plus.
- Le coût d'une erreur a augmenté. Quand l'IA écrit dans votre CRM, envoie des emails ou prend des décisions de tri, une réponse fausse a des conséquences métier réelles.
Une équipe sans evals confond « ça marchait quand je l'ai testé » avec « ça marche ». Ce sont deux affirmations radicalement différentes.
Construire un dataset d'évals représentatif
Un dataset d'évals est une collection de cas d'entrée associés à un résultat attendu ou à des critères de réussite. C'est la fondation : un dataset médiocre produit des évals trompeuses. Voici comment le bâtir.
Partez du réel, pas de l'imaginaire. Les meilleurs cas viennent de la production : logs de vraies requêtes, tickets de support, conversations passées. Anonymisez-les, sélectionnez-en une centaine qui couvrent la diversité réelle des situations.
Couvrez quatre catégories. Les cas nominaux (le comportement attendu), les cas limites (entrées ambiguës, longues, mal formulées), les cas adverses (tentatives d'injection de prompt, demandes hors périmètre) et les cas de régression connue (toute erreur déjà rencontrée devient un cas permanent).
Documentez le résultat attendu. Pour chaque cas, précisez ce qui constitue une bonne réponse. Parfois c'est une valeur exacte (extraction d'un montant, classification dans une catégorie), parfois c'est un ensemble de critères qualitatifs (la réponse cite ses sources, reste polie, ne s'invente pas de faits).
Taille raisonnable. 50 à 100 cas bien choisis valent mieux que 1000 cas redondants. Commencez petit, enrichissez à chaque incident. Le dataset est un organisme vivant : chaque bug corrigé doit y laisser une trace pour ne jamais réapparaître silencieusement.
Quelles métriques pour quel cas d'usage
Il n'existe pas de métrique universelle. Le choix dépend de la nature de la tâche.
Tâches déterministes (extraction, classification, routage). Là, le résultat est vérifiable mécaniquement. Utilisez l'exactitude (accuracy), la précision et le rappel. Exemple : un agent qui classe des emails entrants dans 8 catégories doit atteindre un seuil mesurable, par exemple 95 % d'exactitude sur le dataset d'évals.
Tâches génératives (rédaction, résumé, réponse client). Le résultat n'a pas de vérité unique. On combine des vérifications déterministes (la réponse contient-elle l'information clé ? respecte-t-elle le format ? la longueur ?) et des jugements qualitatifs.
Tâches agentiques (enchaînement d'outils). Mesurez le taux de complétion de la tâche de bout en bout, le nombre d'appels d'outils, le respect des validations humaines obligatoires. Une réponse correcte obtenue après 12 appels d'outils inutiles est un problème de coût et de latence.
Des critères transverses s'appliquent à presque tous les cas : absence d'hallucination (la réponse ne s'appuie que sur des faits fournis), sécurité (pas de fuite de données, résistance aux injections), et conformité au format attendu. Pour fiabiliser ces aspects, reliez vos évals à la même rigueur que celle décrite dans notre guide de création d'agent IA.
LLM-as-judge : puissant mais à encadrer
Pour les tâches génératives, noter manuellement 100 réponses à chaque changement est intenable. La solution courante en 2026 : utiliser un LLM comme juge. Vous demandez à un modèle (idéalement différent ou plus puissant que celui évalué) de noter la réponse selon une grille précise.
Ce qui marche. Un prompt de jugement explicite, avec une grille de critères chiffrée (« note de 1 à 5 la fidélité aux sources : 5 = chaque affirmation est sourcée, 1 = invention manifeste »), et des exemples de notation. Le juge doit justifier sa note avant de la donner, ce qui améliore nettement sa fiabilité.
Les pièges à connaître. Un LLM-juge a des biais : il favorise les réponses longues, celles formulées comme la sienne, et peut être incohérent d'un appel à l'autre. Trois garde-fous : calibrez le juge sur un échantillon noté par des humains pour mesurer son taux d'accord ; utilisez des comparaisons par paires (A est-elle meilleure que B ?) plutôt que des notes absolues quand c'est possible ; et fixez la température basse pour limiter la variance.
Règle d'or. Le LLM-juge accélère l'évaluation, il ne remplace pas le jugement humain sur les cas critiques. Réservez une revue humaine périodique sur un échantillon, sinon vous risquez d'optimiser pour plaire au juge plutôt que pour servir l'utilisateur.
Tests de non-régression et intégration continue
Une eval qui ne tourne qu'une fois est inutile. Sa valeur vient de l'automatisation. L'objectif : exécuter le dataset complet à chaque modification, et bloquer toute mise en production qui dégrade les scores.
Concrètement, intégrez vos évals dans votre chaîne d'intégration continue, au même titre que les tests unitaires :
- À chaque changement de prompt, de code ou de version de modèle, lancez le dataset entier.
- Comparez aux scores de référence (baseline). Si l'exactitude passe sous le seuil, ou si un cas de régression connue échoue à nouveau, la chaîne échoue.
- Conservez l'historique. Vous devez pouvoir tracer l'évolution de chaque métrique dans le temps et corréler une baisse à un commit précis.
Ce mécanisme transforme la mise à jour de modèle d'un saut dans l'inconnu en une décision documentée. Quand un nouveau modèle sort, vous le faites passer sur le dataset, vous comparez, et vous décidez sur des chiffres. C'est précisément ce qui rend le découplage du modèle possible : si vos évals sont solides, changer de fournisseur devient une opération de routine au lieu d'un risque.
Côté outillage, gardez les choses simples au début : un script qui lit le dataset, appelle le système, applique les vérifications et produit un rapport suffit. Les frameworks d'évals spécialisés ne deviennent utiles qu'au-delà de quelques centaines de cas.
Un détail qui change tout : fixez la température basse, voire à zéro, pendant les évals. Un modèle qui répond différemment au même prompt rend toute comparaison impossible. Vous voulez isoler l'effet de votre changement, pas le bruit aléatoire. Pensez aussi à figer la version de modèle testée : comparer deux exécutions sur deux versions différentes sans le savoir fausse vos conclusions. Enfin, lancez chaque cas plusieurs fois pour les tâches non déterministes et raisonnez sur la moyenne plutôt que sur un tirage unique.
Monitoring en production et détection de dérive
Les évals hors ligne valident avant déploiement. Mais la production réserve toujours des surprises : nouvelles formulations, cas non anticipés, dérive lente. Vous avez besoin d'un second filet.
Loggez tout, intelligemment. Pour chaque interaction en production, conservez l'entrée, la sortie, les outils appelés, la latence et le coût. C'est votre matière première pour enrichir le dataset et investiguer les incidents.
Évaluez un échantillon en ligne. Faites passer un pourcentage du trafic réel par votre LLM-juge, en continu. Une baisse de la note moyenne signale une dérive avant que les plaintes n'arrivent.
Surveillez les signaux indirects. Un taux d'escalade vers un humain qui grimpe, des réponses qui s'allongent anormalement, une latence qui dérape : autant d'indicateurs qu'il se passe quelque chose. Si vous supervisez déjà votre infrastructure, branchez ces métriques sur les mêmes tableaux de bord.
Bouclez le cycle. Chaque incident remonté en production devient un nouveau cas dans le dataset d'évals. C'est cette boucle entre production et évals qui fait progresser la qualité au fil des mois plutôt que de la laisser stagner.
Les evals, votre assurance de pérennité
Au-delà de la qualité immédiate, les évals sont le pilier de la pérennité d'un système IA. Voici pourquoi.
Elles découplent votre produit du modèle. Le paysage des modèles bouge vite. Sans évals, migrer d'un fournisseur à un autre est un pari. Avec un dataset solide, c'est une comparaison de scores. Vous restez libre de choisir le meilleur rapport qualité/coût à tout moment, qu'il s'agisse d'un modèle propriétaire ou d'un modèle open-weight déployé via vLLM ou Ollama.
Elles protègent vos données et votre savoir-faire. Un dataset d'évals construit sur vos cas réels est un actif que vous possédez. Combiné au protocole MCP pour connecter proprement vos sources, il vous permet de garder la maîtrise de votre architecture sans dépendre d'une boîte noire.
Elles documentent la définition même de la réussite. Le dataset d'évals est la spécification exécutable de ce que votre IA doit faire. Quand un développeur part, quand un prestataire change, cette spécification reste. C'est de la connaissance institutionnalisée, pas de la magie dans la tête d'une personne.
Investir dans les évals dès le premier jour coûte du temps. Ne pas le faire coûte bien plus cher : des régressions invisibles, une dépendance totale à un fournisseur, et l'impossibilité de prouver que votre système fonctionne. Si vous voulez bâtir une IA qui dure, parlons de votre cas.
FAQ — Évaluer un LLM en production : evals et tests de non-régression
Combien de cas faut-il dans un dataset d'évals pour démarrer ?
50 à 100 cas bien choisis suffisent pour démarrer un système en production. L'important n'est pas le volume mais la représentativité : couvrez les cas nominaux, les cas limites, les cas adverses et les régressions déjà rencontrées. Le dataset s'enrichit ensuite à chaque incident.
Peut-on faire confiance à un LLM pour en évaluer un autre ?
Oui, à condition de l'encadrer. Un LLM-juge accélère l'évaluation des tâches génératives, mais il a des biais (préférence pour les réponses longues, variance). Calibrez-le sur un échantillon noté par des humains, utilisez des grilles de notation explicites et conservez une revue humaine sur les cas critiques.
Quelle différence entre evals et tests de non-régression ?
Les evals mesurent la qualité d'un système IA sur un dataset. Les tests de non-régression exécutent ces evals automatiquement à chaque modification et bloquent toute mise en production qui dégrade les scores. Les evals sont la mesure ; la non-régression est le mécanisme qui les rend utiles dans la durée.
À quelle fréquence faut-il lancer les evals ?
À chaque changement de prompt, de code ou de version de modèle, via la chaîne d'intégration continue. En complément, évaluez en continu un échantillon du trafic réel en production pour détecter les dérives lentes que les évals hors ligne ne capturent pas.
En quoi les evals aident-elles à changer de modèle LLM ?
Un dataset d'évals solide transforme une migration de modèle en simple comparaison de scores. Vous faites passer le nouveau modèle sur le dataset, vous comparez aux résultats actuels et vous décidez sur des chiffres. C'est ce qui rend le découplage du fournisseur réellement possible.