Évaluer un LLM en entreprise : métriques, benchmarks et retour terrain

"Ce modèle score 90 % sur MMLU." C'est la phrase qu'on entend le plus souvent quand un fournisseur présente son LLM. Et c'est probablement la moins utile pour prendre une décision d'achat ou de déploiement.

Quand nous évaluons un LLM pour un client, les benchmarks publics sont notre point de départ, pas notre conclusion. Sur un projet de fine-tuning pour un éditeur médical, le modèle qui scorait le mieux sur MMLU n'était pas le plus performant sur notre tâche. L'écart ? 15 points de précision sur les questions métier. Un score académique brillant, mais des réponses cliniques dangereusement approximatives.

Cet article vous donne la méthode que nous appliquons chez Tensoria pour évaluer un LLM sur un cas d'usage réel : les métriques qui comptent, la construction d'un jeu de test pertinent, l'évaluation automatique vs humaine, et le monitoring post-déploiement que personne n'anticipe.

Pourquoi les benchmarks publics ne suffisent pas

Les benchmarks publics comme MMLU (Massive Multitask Language Understanding), HellaSwag (raisonnement de bon sens) ou HumanEval (génération de code) sont devenus la langue commune pour comparer les LLMs. Chaque fournisseur les affiche en première page de ses annonces. Le problème : ils ne mesurent pas ce qui compte pour votre entreprise.

Voici pourquoi ces scores sont trompeurs pour une décision d'entreprise :

• Les données de test sont publiques. Les modèles récents sont souvent entraînés (directement ou indirectement) sur des données qui incluent les questions des benchmarks. Le score reflète alors une forme de mémorisation, pas une réelle capacité de raisonnement.
• Les tâches sont génériques. MMLU teste 57 domaines académiques (histoire, physique, droit américain). Aucun de ces domaines ne correspond à "extraire les clauses de pénalité d'un CCTP" ou "classifier les tickets SAV d'un éditeur logiciel".
• Le format est standardisé. La plupart des benchmarks utilisent des QCM. En entreprise, vous attendez du texte libre, des tableaux structurés, des résumés calibrés. La capacité à choisir entre A, B, C et D ne prédit pas la qualité d'une synthèse de 500 mots.
• Les conditions de test sont idéales. Pas de bruit dans les données, pas de contexte ambigu, pas de pression de latence. En production, les requêtes sont imparfaites, les documents bruités, et le temps de réponse compte.

Les benchmarks publics restent utiles pour un premier tri. Si un modèle est médiocre sur MMLU, il a peu de chances d'exceller sur votre cas d'usage. Mais le classement entre modèles qui scorent entre 80 et 90 % ne vous dit rien de fiable sur les performances réelles sur votre métier. Pour prendre une vraie décision, il faut construire votre propre évaluation.

Les métriques qui comptent en entreprise

En évaluation LLM pour l'entreprise, il existe deux familles de métriques : les métriques de qualité du texte et les métriques opérationnelles. Les deux sont nécessaires. Un modèle qui donne des réponses parfaites en 30 secondes par requête est inutilisable en production. Un modèle ultra-rapide qui hallucine une fois sur cinq est dangereux.

Métriques de qualité du texte

Métriques opérationnelles

Ces métriques sont souvent oubliées dans les comparatifs, mais elles font la différence entre un prototype convaincant et un système viable en production :

• Latence (temps de réponse) : en millisecondes. Pour un chatbot interne, 2 à 5 secondes est acceptable. Pour une API temps réel intégrée à un workflow, vous visez moins de 500 ms.
• Coût par requête : en centimes d'euro. Avec des volumes de 10 000 requêtes/jour, la différence entre GPT-4o (environ 1,5 ct/requête) et un modèle open source déployé en interne (0,1 ct/requête) change complètement l'équation économique.
• Débit (throughput) : nombre de requêtes traitées simultanément. Un modèle hébergé en interne sur un seul GPU peut saturer rapidement si 50 utilisateurs l'interrogent en même temps.
• Taux de refus : % de requêtes où le modèle refuse de répondre (garde-fous trop agressifs) ou produit une réponse vide. Un taux de refus de 5 % peut sembler faible. Sur 1 000 requêtes par jour, c'est 50 utilisateurs frustrés.

Choisir les bonnes métriques selon votre cas d'usage

Comment construire un golden dataset pour votre cas d'usage

Le golden dataset est la pierre angulaire de toute évaluation LLM sérieuse. C'est un jeu de données de référence composé d'exemples représentatifs de votre cas d'usage réel, avec les réponses attendues validées par vos experts métier.

Nous construisons systématiquement un golden dataset de 200 à 500 exemples avec le client avant tout déploiement. Voici comment procéder.

Étape 1 : identifier vos cas d'usage réels

Ne partez pas de ce que le modèle pourrait faire, mais de ce que vos utilisateurs lui demandent réellement. Collectez les 50 à 100 requêtes les plus fréquentes sur les 3 derniers mois (si le système est déjà en place) ou demandez à 5 à 10 futurs utilisateurs de formuler leurs questions types. Classez-les par fréquence et criticité.

Étape 2 : rédiger les réponses de référence

Pour chaque exemple, un expert métier rédige la réponse idéale. C'est la partie la plus longue et la plus coûteuse du processus, mais c'est elle qui conditionne la fiabilité de toute l'évaluation. Une réponse de référence mal calibrée invalide l'intégralité de l'évaluation sur cet exemple.

Quelques règles pratiques :

• Deux experts minimum valident chaque réponse sur les cas critiques.
• Incluez des cas limites : questions ambiguës, données incomplètes, requêtes hors périmètre. Le modèle doit savoir dire "je ne sais pas" quand c'est la bonne réponse.
• Documentez le raisonnement attendu, pas seulement la réponse finale. Cela permet d'évaluer la qualité du raisonnement, pas uniquement le résultat.

Étape 3 : structurer le dataset

Chaque exemple doit contenir au minimum :

• L'entrée (requête utilisateur + contexte fourni au modèle)
• La sortie de référence (réponse idéale)
• La catégorie du cas d'usage (classification, extraction, rédaction, etc.)
• Le niveau de difficulté (facile, moyen, difficile, cas limite)
• Les critères d'évaluation spécifiques : quels éléments de la réponse sont non négociables

Étape 4 : séparer train / test / validation

Si vous utilisez ce dataset pour du fine-tuning, séparez impérativement les données en trois ensembles : entraînement (70 %), validation (15 %), test (15 %). Le jeu de test ne doit jamais être vu par le modèle pendant l'entraînement. Si vous ne faites que de l'évaluation comparative (sans fine-tuning), l'intégralité du dataset sert de jeu de test.

Évaluation automatique vs évaluation humaine : quand utiliser quoi

C'est l'un des dilemmes les plus concrets de l'évaluation LLM. L'évaluation automatique est rapide et reproductible, mais elle rate des nuances. L'évaluation humaine capture la qualité réelle, mais elle est lente et coûteuse. La bonne réponse : les deux, mais pas dans les mêmes proportions ni aux mêmes moments.

Quand privilégier l'évaluation automatique

• Comparaison rapide entre modèles. Vous testez 5 modèles candidats sur 300 exemples. L'évaluation humaine prendrait des semaines. Les métriques automatiques (ROUGE, BERTScore, F1, taux d'hallucination automatisé) donnent un premier classement en quelques heures.
• Tests de régression. Après chaque mise à jour du modèle, du prompt ou de la pipeline RAG, vous relancez l'évaluation automatique sur le golden dataset pour détecter des régressions. C'est un filet de sécurité permanent.
• Tâches à réponse déterministe. Classification, extraction d'entités, réponses factuelles courtes : la sortie est soit correcte, soit incorrecte. L'automatisation est fiable.

Quand l'évaluation humaine est indispensable

• Génération de texte long. La qualité d'un rapport de 500 mots ne se réduit pas à un score BLEU. Le ton, la logique argumentative, la pertinence des nuances : seul un humain évalue cela de façon fiable.
• Cas d'usage à fort enjeu. Dans le médical, le juridique ou la finance, une erreur factuelle peut avoir des conséquences graves. L'évaluation humaine est non négociable sur un échantillon représentatif.
• Calibration du LLM-as-a-judge. Avant de faire confiance à un évaluateur automatique basé sur un LLM, vous devez vérifier qu'il est aligné avec le jugement humain sur au moins 50 à 100 exemples.

Notre recommandation pratique

Sur un projet d'évaluation typique, nous appliquons cette répartition :

• 100 % du golden dataset évalué automatiquement (métriques + LLM-as-a-judge)
• 20 à 30 % du golden dataset évalué par des experts humains (en priorité : les cas difficiles et les cas critiques)
• Corrélation systématique entre scores automatiques et scores humains. Si la corrélation est inférieure à 0,7, les métriques automatiques ne sont pas fiables pour votre cas d'usage et doivent être recalibrées.

LLM-as-a-judge et frameworks d'évaluation

L'approche LLM-as-a-judge est devenue incontournable. Le principe : utiliser un modèle puissant (GPT-4o, Claude 3.5 Sonnet) pour évaluer les sorties d'un autre modèle selon des critères définis. C'est un compromis intelligent entre la vitesse de l'automatique et la nuance de l'humain.

Comment mettre en place un LLM-as-a-judge efficace

1. Définir des critères d'évaluation précis. Ne demandez pas au juge "est-ce que cette réponse est bonne ?". Demandez-lui d'évaluer séparément : la fidélité factuelle (1 à 5), la complétude (1 à 5), le respect du format (oui/non), le ton (approprié/inadéquat). Plus les critères sont décomposés, plus l'évaluation est fiable et exploitable.
2. Fournir des exemples de scoring. Incluez dans le prompt du juge 3 à 5 exemples de réponses avec leur note et la justification. Cela ancre l'échelle de notation et réduit la variabilité.
3. Calibrer sur des évaluations humaines. Faites évaluer 50 à 100 exemples par des humains ET par le LLM-juge. Mesurez l'accord inter-annotateur (Cohen's Kappa ou corrélation de Spearman). Un accord inférieur à 0,65 signifie que le juge n'est pas encore fiable.
4. Alterner les modèles juges. Un biais connu : un modèle tend à mieux évaluer ses propres sorties. Utilisez un modèle juge différent du modèle évalué. Si vous évaluez GPT-4o, utilisez Claude comme juge, et inversement.

Frameworks d'évaluation à connaître

Plusieurs outils open source facilitent la mise en place d'une évaluation structurée :

• RAGAS : spécialisé pour l'évaluation de systèmes RAG. Mesure la fidélité, la pertinence du contexte, et la qualité de la réponse. Indispensable si vous déployez un assistant RAG.
• DeepEval : framework Python complet pour l'évaluation LLM avec des métriques pré-construites (hallucination, toxicité, cohérence) et un support LLM-as-a-judge intégré.
• OpenAI Evals : le framework d'évaluation d'OpenAI, extensible pour définir vos propres benchmarks et métriques.

Le choix du framework dépend de votre stack technique et de votre cas d'usage. Pour un système RAG, RAGAS est le point de départ naturel. Pour une évaluation plus généraliste, DeepEval offre la plus grande flexibilité.

Monitoring en production : détecter la dérive de qualité

L'évaluation ne s'arrête pas au moment du déploiement. C'est même là que le plus gros du travail commence. Un LLM en production subit des dérives que vous ne verrez jamais dans un benchmark statique :

• Dérive des données d'entrée. Les requêtes des utilisateurs évoluent avec le temps. De nouveaux sujets apparaissent, le vocabulaire change, les cas d'usage se diversifient. Le modèle qui scorait 92 % à la mise en production peut tomber à 78 % trois mois plus tard sans que vous le sachiez.
• Mise à jour silencieuse du fournisseur. Si vous utilisez un modèle via API (OpenAI, Anthropic, Mistral), le fournisseur peut mettre à jour le modèle sans préavis. En janvier 2025, une mise à jour de GPT-4o a modifié le comportement de certaines sorties structurées, cassant silencieusement des workflows en production chez plusieurs de nos clients.
• Évolution du contexte documentaire (RAG). Si vous ajoutez de nouveaux documents dans votre base RAG, la qualité des réponses peut changer : nouveaux conflits entre documents, passages mal indexés, métadonnées incohérentes.

Mettre en place un monitoring LLM efficace

Voici les trois piliers d'un monitoring que nous recommandons systématiquement :

1. Métriques automatiques en continu. Échantillonnez 5 à 10 % des requêtes en production et évaluez-les automatiquement (LLM-as-a-judge sur des critères pré-définis). Tracez ces scores sur un tableau de bord avec des seuils d'alerte. Si le score moyen descend sous le seuil, une alerte se déclenche avant que les utilisateurs ne remontent le problème.

2. Feedback utilisateur structuré. Intégrez un système de feedback simple dans l'interface (pouce haut/bas, bouton "signaler une erreur"). Ce n'est pas du NPS : c'est un signal brut qui vous indique les réponses problématiques en temps réel. Analysez les signalements chaque semaine.

3. Réévaluation périodique sur le golden dataset. Toutes les 4 à 6 semaines, relancez l'évaluation complète sur votre golden dataset. Comparez les résultats avec l'évaluation initiale. Toute baisse significative (plus de 3 points) déclenche une investigation : est-ce le modèle, les données, le prompt ou le contexte qui a changé ?

Retour d'expérience : comment nous évaluons les LLMs chez Tensoria

Notre méthodologie s'est construite sur des dizaines de projets d'évaluation et de déploiement. Voici les principes que nous appliquons systématiquement, et les leçons que nous avons tirées de nos erreurs.

Le processus en 4 phases

Phase 1 : cadrage et golden dataset (1 à 2 semaines). Nous travaillons avec les experts métier du client pour définir les cas d'usage prioritaires et construire un golden dataset de 200 à 500 exemples. C'est la phase la plus importante. Un golden dataset mal construit invalide tout le reste. Nous imposons un taux de validation croisée de 90 % minimum (deux annotateurs s'accordent sur 90 % des réponses de référence).

Phase 2 : évaluation comparative (3 à 5 jours). Nous testons systématiquement 3 à 5 modèles candidats sur le golden dataset. GPT-4o, Claude 3.5 Sonnet, Mistral Large, et un ou deux modèles open source candidats au fine-tuning. Pour chaque modèle, nous mesurons toutes les métriques pertinentes (qualité + opérationnelles) et produisons un rapport comparatif factuel.

Phase 3 : évaluation humaine ciblée (1 semaine). Les experts métier du client évaluent un échantillon de 20 à 30 % du golden dataset sur les 2 ou 3 modèles les plus prometteurs. Nous mesurons la corrélation avec les scores automatiques. Si la corrélation est bonne (supérieure à 0,7), les scores automatiques sont fiables pour le monitoring futur. Sinon, nous ajustons les critères du LLM-as-a-judge.

Phase 4 : déploiement et monitoring (continu). Le modèle retenu est déployé avec un monitoring intégré dès le premier jour. Pas de "on verra plus tard". Le monitoring est une composante du livrable, au même titre que l'API ou l'interface utilisateur.

Les erreurs qu'on ne fait plus

• Évaluer uniquement sur les cas faciles. Les premiers golden datasets que nous avons construits étaient trop "propres". En production, les requêtes sont ambiguës, mal formulées, hors périmètre. Depuis, nous imposons 20 % de cas difficiles et 10 % de cas limites dans chaque golden dataset.
• Faire confiance au LLM-as-a-judge sans calibration. Sur un projet juridique, le LLM-as-a-judge (GPT-4) notait systématiquement trop bien les réponses de GPT-4 par rapport au jugement des avocats. Le biais d'auto-évaluation est réel. Nous utilisons maintenant systématiquement un modèle juge différent du modèle évalué.
• Négliger la latence et le coût. Un modèle qui score 95 % de fidélité mais coûte 3 centimes par requête n'est pas forcément le bon choix si votre volume est de 50 000 requêtes par mois. Nous intégrons systématiquement le coût total de possession (TCO) dans l'analyse comparative, pas seulement les métriques de qualité.

Un cas concret : évaluation pour un éditeur de logiciel médical

Le client avait besoin d'un assistant RAG pour son support utilisateur. Objectif : répondre aux questions techniques sur leur logiciel à partir de la documentation interne. Les résultats de notre évaluation comparative :

Le modèle avec le meilleur score MMLU (GPT-4o) avait le pire taux d'hallucination sur cette tâche. Le modèle fine-tuné sur les données métier, avec un score MMLU très inférieur, surpassait tous les autres sur les métriques qui comptaient réellement : fidélité factuelle et taux d'hallucination. Et il coûtait 18 fois moins cher par requête.

C'est exactement pour cela que nous recommandons toujours de commencer par un audit IA qui inclut une évaluation comparative sur vos données, avant de choisir un modèle.

Table comparative des métriques par type de projet

Ce tableau synthétise les métriques prioritaires selon le type de projet IA. Utilisez-le comme grille de décision pour cadrer votre propre évaluation :

Par où commencer : votre plan d'action en 5 étapes

Si vous envisagez de déployer un LLM en entreprise, ou si vous avez déjà un modèle en production sans évaluation structurée, voici par où commencer :

1. Identifiez votre cas d'usage principal. Pas "l'IA en général". Un cas d'usage précis : "répondre aux questions techniques sur notre logiciel", "classifier les demandes entrantes", "rédiger des synthèses de réunion". Plus c'est précis, plus l'évaluation est exploitable.
2. Construisez un golden dataset de 200 exemples. Avec vos experts métier. C'est un investissement de 3 à 5 jours, et c'est ce qui vous permettra de prendre des décisions factuelles au lieu de vous fier à l'intuition ou au marketing.
3. Évaluez 3 modèles candidats. Pas 15. Trois modèles bien choisis (un premium, un mid-range, un open source), évalués rigoureusement, valent mieux que quinze modèles testés superficiellement.
4. Mettez en place le monitoring dès le jour 1. Pas "quand on aura le temps". Un monitoring minimal (50 requêtes/jour évaluées automatiquement + feedback utilisateur) prend 2 jours à mettre en place et vous évitera des semaines de diagnostic en aveugle.
5. Réévaluez tous les mois. Le paysage LLM bouge vite. Un modèle optimal aujourd'hui peut être surpassé par une nouvelle version dans 6 semaines. Votre golden dataset vous permet de réévaluer en quelques heures au lieu de recommencer de zéro.

Si ce processus vous semble lourd à mettre en place seul, c'est exactement ce que nous faisons avec nos clients lors d'un accompagnement LLM. De la construction du golden dataset au monitoring en production, en passant par l'évaluation comparative et le choix du modèle.

Pour aller plus loin

• Notre expertise LLM et NLP : accompagnement de bout en bout, de l'évaluation au déploiement.
• Fine-tuning LLM en PME : quand ça vaut le coup : quand et comment adapter un modèle à vos données métier.
• Optimiser un système RAG : les leviers d'amélioration quand votre assistant ne donne pas les bonnes réponses.
• Les erreurs qui font échouer les projets RAG : dont plusieurs sont liées à un manque d'évaluation.
• Lancer un projet IA en entreprise : le guide réaliste pour passer de l'idée au déploiement.
• Budget IA pour PME : intégrer le coût de l'évaluation dans votre enveloppe projet.
• RAG vs fine-tuning : comment choisir : un arbre de décision pour choisir la bonne architecture avant d'évaluer.
• Déployer un LLM en production : infrastructure, coûts GPU et monitoring post-déploiement.
• Embeddings et recherche sémantique : comprendre la brique fondamentale derrière le RAG et la recherche.
• Prompt engineering avancé : les techniques qui peuvent rendre un fine-tuning inutile.

En résumé

Évaluer un LLM en entreprise ne se réduit pas à comparer des scores MMLU. C'est un processus structuré qui commence par la construction d'un golden dataset représentatif de votre réalité métier, se poursuit par une évaluation comparative rigoureuse (automatique et humaine), et ne s'arrête jamais grâce au monitoring en production.

Les entreprises qui réussissent leurs projets LLM sont celles qui investissent autant dans l'évaluation que dans le développement. Un golden dataset de 300 exemples et un monitoring minimal coûtent l'équivalent de 2 à 3 jours de consulting. L'absence d'évaluation, elle, peut coûter des mois de corrections, de la confiance utilisateur perdue et un ROI qui ne se matérialise jamais.

Le classement des modèles change tous les trimestres. Votre golden dataset, lui, reste valide tant que votre cas d'usage ne change pas fondamentalement. C'est votre actif le plus précieux pour prendre des décisions factuelles dans un marché où le marketing des fournisseurs IA n'a jamais été aussi bruyant.

Questions fréquentes