Évaluer un LLM pour l'entreprise : benchmarks et méthodes 2026

Les limites des benchmarks publics

Les benchmarks académiques des LLM sont conçus pour mesurer des capacités génériques dans des conditions contrôlées. Ils ont une valeur réelle pour comparer les laboratoires d'IA entre eux — mais ils échouent systématiquement à prédire la performance dans des contextes d'entreprise pour plusieurs raisons :

La contamination des données d'entraînement

Les questions de MMLU, GSM8K, et HumanEval sont publiques depuis des années. Il est fortement probable que les modèles récents les ont vues (ou des variantes) dans leurs données d'entraînement — ce qu'on appelle la contamination. Un modèle peut obtenir 90% sur MMLU non pas parce qu'il raisonne mieux, mais parce qu'il a mémorisé les réponses. Ce phénomène est documenté et reconnu par les laboratoires eux-mêmes.

Les benchmarks ne mesurent pas ce qui compte en entreprise

MMLU mesure la connaissance encyclopédique en anglais. HumanEval mesure la génération de code Python court. GPQA mesure le raisonnement scientifique expert. Aucun de ces benchmarks ne mesure :

• La cohérence sur des documents longs en français
• La capacité à suivre des instructions système complexes et à les maintenir sur toute une conversation
• La pertinence des refus (refuser ce qui doit l'être, accepter ce qui est légitime)
• La qualité des extractions structurées sur des formats documentaires métier
• La fiabilité des citations de sources dans un contexte RAG

Les résultats ne sont pas reproductibles sans contrôle de température

Un LLM est stochastique — la même question peut donner des réponses légèrement différentes selon la température de sampling. Les benchmarks publics utilisent généralement une température de 0 (déterministe) alors que vos applications réelles tournent souvent à température 0.3-0.7. Les performances peuvent diverger significativement.

Axes d'évaluation métier : ce qui compte vraiment

Précision factuelle et hallucinations

Dans un contexte d'entreprise, une réponse fausse présentée avec confiance est pire qu'une réponse incertaine. L'évaluation de la précision factuelle doit distinguer :

• Hallucinations factuelles : le modèle invente des faits (chiffres, dates, références légales, noms)
• Hallucinations de citation : le modèle cite des sources qui n'existent pas ou attribue des propos incorrectement
• Erreurs de raisonnement : la chaîne logique est correcte mais aboutit à une conclusion fausse

Méthode de mesure : préparer un jeu de questions factuelles sur votre domaine dont vous connaissez les réponses exactes, et mesurer le taux de réponses correctes et le taux de confabulations détectables.

Cohérence et instructions système

Un LLM d'entreprise doit maintenir des instructions système complexes sur de longues conversations : ton, format de sortie, limites de scope (ne pas répondre hors du domaine), niveau de détail. Évaluez :

• Le modèle respecte-t-il les contraintes de format sur 100% des réponses ?
• Maintient-il le ton défini même sur des questions difficiles ou ambiguës ?
• Les contraintes de scope résistent-elles à des tentatives de contournement utilisateur ?

Refus appropriés (calibration)

Un modèle mal calibré refuse trop ou trop peu. Dans un contexte RH, un modèle qui refuse de rédiger une lettre de licenciement ("trop sensible") est inutilisable. Un modèle qui accepte de rédiger des clauses abusives sans avertissement est dangereux. Évaluez la calibration des refus sur des cas légitimes proches des limites de votre politique d'usage.

Performance en français

La majorité des benchmarks sont en anglais. Or la performance en français peut différer significativement — non pas en compréhension (la plupart des grands modèles comprennent bien le français) mais en qualité de génération : richesse lexicale, tournures naturelles, respect des conventions typographiques françaises, qualité des constructions complexes. Les modèles Mistral (français) surpassent systématiquement les modèles américains sur ce critère.

Latence et débit

La latence a deux composantes : le TTFT (Time To First Token — temps avant que la première réponse apparaisse) et le débit de génération (tokens/seconde). Pour les interfaces utilisateur, le TTFT est critique (ressenti de réactivité). Pour les pipelines batch, le débit total compte davantage. Mesurez les deux sur votre infrastructure cible — les performances API cloud varient selon les heures et la charge.

Coût par tâche

Le coût ne se mesure pas en $/million tokens (trop abstrait) mais en coût par tâche métier : combien coûte le traitement d'un contrat complet ? D'une semaine de tickets support ? D'un rapport d'analyse ? Ce calcul intègre le nombre de tokens consommés par tâche (input + output) et révèle des surprises — certains modèles "moins chers" consomment plus de tokens pour atteindre la même qualité.

Méthodes d'évaluation : du plus simple au plus rigoureux

LLM-as-judge : l'évaluation automatisée scalable

La méthode LLM-as-judge consiste à utiliser un LLM fort (GPT-4o, Claude Opus, ou un modèle local bien calibré) pour évaluer les réponses d'autres modèles selon des critères définis. Elle permet d'évaluer des milliers de cas sans annotation humaine.

Le protocole standard :

1. Préparer un prompt d'évaluation avec des critères explicites et un barème (1-5 ou binaire)
2. Soumettre la question + la réponse du modèle évalué au LLM-juge
3. Demander une note ET une justification (le raisonnement est plus fiable que la note seule)
4. Utiliser plusieurs LLM-juges et moyenner pour réduire les biais

Biais à connaître : les LLM ont tendance à préférer leurs propres sorties (biais d'auto-préférence), à privilégier les réponses longues (biais de verbosité), et à être influencés par l'ordre de présentation. Utilisez des évaluations en double aveugle et randomisez l'ordre.

Évaluation humaine : la référence incontournable

L'évaluation humaine par des experts métier reste la gold standard pour valider les résultats LLM-as-judge et pour les décisions finales de sélection de modèle. Elle est coûteuse et lente, mais irremplaçable pour :

• Valider la calibration de votre LLM-as-judge
• Évaluer des critères subjectifs (ton, pertinence contextuelle, style professionnel)
• Détecter des problèmes non anticipés (erreurs subtiles que le LLM-juge manque)

Recommandation pratique : faire évaluer par des humains un sous-ensemble de 50-100 cas, comparer avec le LLM-as-judge, et n'utiliser l'évaluation humaine complète que si la corrélation est insuffisante (<75%).

Évaluation par règles déterministes

Pour certains critères, des règles déterministes sont plus fiables que l'évaluation LLM :

• Format de sortie : le JSON est-il valide ? Le format attendu est-il respecté ?
• Longueur : la réponse respecte-t-elle les contraintes de longueur définies ?
• Mots interdits : le modèle évite-t-il les termes bannis dans votre politique ?
• Citations : les sources citées correspondent-elles réellement aux documents fournis ?

Ces métriques déterministes sont simples à implémenter, 100% reproductibles, et révèlent souvent des problèmes pratiques importants que les évaluations subjectives manquent.

Frameworks d'évaluation LLM

RAGAS — évaluation des systèmes RAG

RAGAS (Retrieval-Augmented Generation Assessment) est le framework de référence pour évaluer les systèmes RAG. Il mesure quatre métriques complémentaires :

• Faithfulness : la réponse est-elle fidèle aux documents récupérés ? (détection d'hallucinations par rapport au contexte)
• Answer Relevance : la réponse répond-elle réellement à la question posée ?
• Context Recall : les documents pertinents ont-ils été récupérés ? (évaluation du retriever)
• Context Precision : les documents récupérés sont-ils tous pertinents ? (signal/bruit du retriever)

RAGAS peut fonctionner avec des LLM locaux comme juge (via Ollama) — pas de dépendance à OpenAI obligatoire.

PromptBench — robustesse aux variations de prompt

PromptBench évalue la robustesse des modèles face aux variations de formulation : des questions légèrement reformulées (fautes de frappe, paraphrases, reformulations négatives) ne devraient pas produire des réponses radicalement différentes. Un modèle fragile aux variations de prompt est difficile à contrôler en production.

EleutherAI Eval Harness — le standard open-source

Le LM Evaluation Harness d'EleutherAI est l'outil le plus utilisé pour reproduire les benchmarks académiques sur vos propres modèles et vos propres datasets. Il supporte 200+ benchmarks standards et vous permet d'ajouter vos propres tâches d'évaluation. Compatible avec tous les modèles Hugging Face et les APIs standard.

Promptfoo — tests LLM en CI/CD

Promptfoo est un framework de tests pour LLM conçu pour s'intégrer dans vos pipelines CI/CD. Il permet de définir des suites de tests (assertions sur les sorties, comparaisons multi-modèles) qui s'exécutent automatiquement à chaque changement de prompt ou de modèle — essentiel pour détecter les régressions en production.

Framework	Usage principal	LLM local possible	CI/CD intégration
RAGAS	Évaluation systèmes RAG	Oui (Ollama)	Via Python SDK
PromptBench	Robustesse aux variations	Oui	Via Python SDK
EleutherAI Eval Harness	Benchmarks académiques custom	Oui (HuggingFace)	CLI + Python
Promptfoo	Tests LLM en dev/prod	Oui (Ollama, local)	Natif (YAML + CLI)
LangSmith	Évaluation + observabilité	Oui	SDK LangChain

Construire son eval set métier : guide pratique

Un eval set métier est votre outil le plus précieux pour sélectionner et suivre votre LLM dans le temps. Voici comment le construire rigoureusement.

Étape 1 : identifier les tâches critiques

Listez les 5-10 tâches pour lesquelles le LLM sera utilisé en production. Pour chaque tâche, identifiez :

• Les inputs typiques (format, longueur, langue)
• Les outputs attendus (format, critères de qualité)
• Les cas difficiles connus (edge cases, questions ambiguës, documents mal formatés)
• Les erreurs inacceptables (ce que le modèle ne doit jamais faire)

Étape 2 : collecter des cas réels

Les meilleurs cas de test sont issus de vos données réelles. Extrayez :

• Des exemples représentatifs des inputs que recevra le système en production
• Des cas difficiles identifiés par vos experts métier
• Des cas limites intentionnellement construits (inputs malformés, questions hors scope, données incomplètes)

Cible : 200 cas minimum pour un eval set statistiquement significatif (erreur standard <3.5% à 95% de confiance). 500 cas si vos tâches sont hétérogènes.

Étape 3 : définir les critères et les réponses de référence

Pour chaque cas, définissez :

• La réponse de référence (golden answer) — ce que le système devrait répondre idéalement
• Les critères d'évaluation pondérés (ex : précision factuelle 40%, format 20%, concision 20%, ton 20%)
• Les critères binaires éliminatoires (ex : ne cite pas une source qui n'existe pas)

Étape 4 : stratifier l'eval set

Un eval set bien stratifié représente la distribution réelle de vos données :

• Par type de tâche (si vous avez plusieurs usages)
• Par difficulté (facile / moyen / difficile)
• Par langue si vous êtes multilingue
• Par domaine si vous couvrez plusieurs métiers

Étape 5 : mettre à jour régulièrement

L'eval set n'est pas statique. Enrichissez-le des nouveaux cas difficiles rencontrés en production, des erreurs signalées par les utilisateurs, et des nouvelles tâches ajoutées au système. Un eval set qui grandit avec votre usage est votre meilleure garantie contre les régressions silencieuses.

Critères de sélection : LLM souverain vs LLM US

Au-delà de la performance brute, plusieurs critères distinguent les LLM souverains (modèles ouverts déployés en local, ou fournisseurs européens) des LLM US (OpenAI, Anthropic, Google).

Confidentialité et souveraineté des données

Avec un LLM US en SaaS, chaque requête envoie vos données vers des serveurs américains soumis au Cloud Act. Pour les données sensibles (R&D, stratégie, données clients, données médicales), ce transit est inacceptable. Un LLM open-source déployé on-premise traite vos données sur votre infrastructure — aucun transit externe.

Contrôle du modèle et évolution

Les LLM SaaS changent silencieusement. OpenAI a modifié le comportement de GPT-4 plusieurs fois sans préavis — des systèmes en production ont connu des régressions sans que leurs opérateurs comprennent pourquoi. Avec un modèle open-source, vous contrôlez la version exacte utilisée et pouvez décider du moment de toute migration.

Coût à l'échelle

Pour des volumes élevés (millions de tokens/jour), le coût des API cloud devient significatif. Un déploiement on-premise amortit le coût GPU sur 3-4 ans avec un coût marginal quasi nul. Le seuil de rentabilité est typiquement atteint entre 50 et 200 millions de tokens/mois selon le hardware choisi.

Tableau comparatif : Intelligence Privée vs GPT-4o vs Mistral Large

Critère	Intelligence Privée	GPT-4o (OpenAI)	Mistral Large 2
Performance française (rédaction)	Excellente	Très bonne	Excellente
Précision factuelle (domaine métier)	Élevée (RAG intégré)	Élevée	Bonne
Respect instructions système	Élevé	Très élevé	Élevé
Refus appropriés (calibration)	Bonne (configurable)	Parfois sur-censuré	Bonne
Latence (P50)	50-200ms (on-premise)	300-800ms (API)	200-500ms (API/local)
Coût/million tokens	Coût infra fixe	5-15€	2-8€
Souveraineté données	Totale (on-premise)	Nulle (US cloud)	Partielle (EU possible)
Conformité EU AI Act	Documentation fournie	Partielle	En cours
Cloud Act exposure	Aucune	Totale	Selon déploiement
Contrôle version modèle	Total	Aucun	Partiel (API/local)

Note : les performances varient selon les tâches et les évaluations. Ce tableau reflète des observations moyennées sur des cas d'usage enterprise B2B français. Construisez votre propre eval set pour une comparaison sur vos données.

Questions fréquentes sur l'évaluation des LLM

Combien de temps faut-il pour construire un eval set métier ?

Pour un premier eval set de 200 cas couvrant 3-5 tâches : comptez 2-4 semaines si vous partez de zéro, dont 1 semaine pour l'extraction et le nettoyage des données, 1 semaine pour la définition des critères avec les experts métier, et 1-2 semaines pour l'annotation des réponses de référence. Le LLM-as-judge peut accélérer l'annotation initiale — réservez l'évaluation humaine pour la validation finale. L'investissement initial est amorti rapidement : un eval set bien construit vous servira pour comparer chaque nouveau modèle qui sort, chaque changement de prompt, chaque mise à jour de votre RAG.

MMLU est-il vraiment inutile pour choisir un LLM d'entreprise ?

Pas entièrement — MMLU reste un indicateur utile de la capacité de raisonnement général du modèle. Un modèle très faible sur MMLU sera probablement faible sur des tâches de raisonnement complexe. Mais un modèle fort sur MMLU n'est pas nécessairement bon pour vos usages métier spécifiques. La règle pratique : utilisez MMLU (et MMLU-Pro, la version moins contaminée) comme filtre de présélection, puis évaluez les modèles présélectionnés sur vos données réelles.

Comment évaluer la performance en français spécifiquement ?

Plusieurs ressources utiles : FrenchBench (benchmark spécifique au français, maintenu par des chercheurs français), XENTROPE (évaluation multilingue incluant le français), et les leaderboards Open LLM Leaderboard filtrés sur les datasets français. Plus fiable encore : inclure des cas en français dans votre eval set métier et mesurer directement. Les modèles Mistral et les modèles CroissantLLM (spécifiquement entraînés sur du français) excellent sur ce critère.

Quel budget prévoir pour une évaluation LLM sérieuse ?

Les coûts d'une évaluation LLM sérieuse se décomposent en : (1) Temps humain : 2-4 semaines d'un data scientist / expert métier pour construire l'eval set (coût dominant) ; (2) Coûts API pour les inférences d'évaluation : 200 cas × 5 modèles × ~1000 tokens = 1M tokens, soit 5-15€ pour les modèles premium ; (3) LLM-as-judge : 200 évaluations × ~2000 tokens = 400k tokens supplémentaires. Au total, hors temps humain, le coût en tokens d'une évaluation complète est marginal (<100€). L'investissement principal est humain — mais il se rentabilise sur la durée de vie du système.

Comment détecter qu'un modèle en production se dégrade dans le temps ?

La dégrade silencieuse d'un LLM en production est un risque réel — les fournisseurs mettent à jour leurs modèles, les patterns de données changent, les prompts système vieillissent. Pour la détecter : (1) Monitoring continu des métriques automatiques (format, longueur, taux de refus) — des alertes sur des seuils anormaux ; (2) Évaluation périodique sur votre eval set (hebdomadaire ou mensuelle selon la criticité) ; (3) Feedback utilisateur capturé et analysé (pouces haut/bas ou formulaire court) ; (4) LLM-as-judge automatisé sur un échantillon aléatoire des conversations de production. Le framework Promptfoo permet d'automatiser les points 1 et 2 dans un pipeline CI/CD.

Un modèle open-source peut-il atteindre la performance de GPT-4o sur mes tâches métier ?

Sur des tâches bien définies et spécifiques (extraction structurée, classification, génération selon un template), un modèle open-source comme Mistral Large 2 ou Llama 3.3 70B, combiné avec du fine-tuning sur vos données et un RAG bien construit, peut atteindre et dépasser GPT-4o. Sur des tâches de raisonnement complexe et ouvert (analyse multi-documents, problèmes à plusieurs étapes), les écarts persistent — GPT-4o et Claude Opus gardent un avantage. La stratégie optimale : modèles open-source souverains pour les tâches structurées (90% des volumes), modèles premium pour les tâches complexes critiques si le cadre souverain le permet.