Évaluation des LLMs en production en 2026 — quelles métriques mesurer vraiment

Mettre un LLM en production sans système d’évaluation, c’est comme déployer du code sans tests. La différence : avec du code classique, vous voyez vite que ça plante. Avec un LLM, ça “fonctionne” mais ça hallucine, dérive, perd en qualité, sans signal visible. Voici une méthode pour évaluer un LLM en prod, avec les outils 2026 et un dataset minimum de 50 cas.

Pourquoi votre LLM dérive sans que vous le sachiez

Un LLM en prod connaît plusieurs sources de dérive invisible :

1. Mise à jour modèle silencieuse — le provider change le modèle backing (GPT-4o → GPT-4.1, Claude Sonnet 4 → Sonnet 4.5) sans préavis. Comportement subtil change.
2. Évolution de la donnée d’entrée — vos utilisateurs envoient des questions différentes 6 mois après le lancement. Le prompt calibré au départ devient inadapté.
3. Cas tordus en prod — votre dataset de test ne couvre pas tous les cas. Les cas bizarres tombent en prod et le LLM hallucine sans alerte.
4. Qualité humaine qui baisse — les utilisateurs s’habituent et arrêtent de signaler les erreurs. La qualité réelle baisse mais le NPS reste stable.

Sans évaluation continue, vous découvrez la dérive trop tard, quand un client vous appelle pour signaler un bug majeur.

1. Faithfulness — fidélité aux sources

C’est la métrique critique en RAG. Question : “ce que dit le LLM est-il fidèle aux sources qu’il cite ?” Si le LLM répond “selon le contrat, le délai de paiement est 30 jours” mais que le contrat dit 45 jours, c’est une faillite de faithfulness.

Comment mesurer : pour chaque output LLM avec sources, comparer chaque affirmation à la source citée. Un LLM evaluator (Claude Opus, GPT-4) peut le faire avec un score 0-1 par paragraphe. RAGAS et Promptfoo proposent ces métriques out-of-the-box.

Seuil à fixer en équipe sur votre dataset de test. Exemple de départ, notre choix d’auteur et non un standard publié : > 0,95 acceptable, < 0,90 à corriger d’urgence.

2. Answer Relevancy — pertinence de la réponse

Question : “la réponse du LLM correspond-elle à la question posée ?” Beaucoup de LLMs répondent à côté, surtout sur des questions composées (“explique X et donne 3 exemples Y”).

Comment mesurer : LLM evaluator qui note 0-1 si la réponse traite vraiment la question. Promptfoo + Langfuse ont des plugins natifs.

Seuil à fixer en équipe (exemple de départ, notre choix d’auteur) : > 0,90.

3. Context Precision / Recall — qualité du retrieval RAG

Si vous faites du RAG, ces deux métriques sont critiques :

• Context Precision : parmi les chunks retournés, combien sont pertinents ?
• Context Recall : parmi tous les chunks pertinents qui existent, combien le retrieval a trouvé ?

Comment mesurer : sur 50-200 questions avec ground truth (les chunks qu’un humain identifierait comme pertinents), mesurer Precision@k et Recall@k. Faisable avec RAGAS ou code custom.

Seuils à fixer en équipe (exemple de départ, notre choix d’auteur) : Precision > 0,80, Recall > 0,75.

Si Recall est faible : votre indexation ou votre embedding n’est pas adaptée. Voir comparatif vector databases 2026.

4. Toxicity, Bias, PII Leak

Trois risques distincts :

• Toxicity : le LLM produit-il du langage toxique, agressif, inapproprié ?
• Bias : le LLM exprime-t-il des biais (genre, origine, religion, opinion politique) inacceptables pour votre marque ?
• PII Leak : le LLM divulgue-t-il des données personnelles (nom, email, téléphone, IBAN) qui devraient être anonymisées ?

Comment mesurer : detect.dev, Detoxify (open source), Azure AI Content Safety. PII : Microsoft Presidio, Anthropic Claude classifier custom. Promptfoo intègre plusieurs de ces detectors.

Seuil acceptable : 0 cas en prod. Tout cas détecté = alerte immédiate + correction prompt.

5. Latency, Cost, Throughput

Métriques opérationnelles :

• Latency p50, p95, p99 : 50 % / 95 % / 99 % des requêtes répondent en moins de combien de ms ?
• Cost-per-task : coût LLM moyen par requête utilisateur
• Throughput max : combien de requêtes par seconde votre système peut soutenir avant dégradation ?

Comment mesurer : Langfuse, Helicone, OpenLIT, Datadog APM. Tous tracent en natif.

Seuils acceptables : dépendent de votre cas et se fixent avec les utilisateurs (un chat interactif exige une réponse plus rapide qu’un traitement par lots). Cost-per-task : à comparer au gain métier. Si le LLM coûte 0,05 € par requête mais génère 0,02 € de valeur, vous brûlez de l’argent (exemple d’illustration).

Étape 1 — Constituer un dataset de référence (50-200 cas réels)

Le piège : utiliser un dataset synthétique généré par GPT. Ça ne couvre pas la diversité réelle. Méthode : prendre 50-200 vraies questions / inputs utilisateurs des 3 derniers mois, anonymiser, annoter manuellement la “bonne réponse” attendue.

Pour un RAG : ajouter pour chaque question les chunks ground truth (les sources qu’un expert pointerait).

Pour une génération : ajouter la “réponse attendue type” + critères d’acceptation explicites.

Effort : il dépend du nombre de cas et du temps de l’expert métier. C’est l’investissement obligatoire.

Étape 2 — Choisir l’outil d’évaluation

Outil	Type	Prix	Pour quoi
Promptfoo	Open source CLI	Gratuit	Eval batch sur dataset, A/B testing prompts
Langfuse	Open source + SaaS	Gratuit self-hosted ; Core 29 $, Pro 199 $ (langfuse.com/pricing, lu le 24/10/2026)	Observabilité prod + eval
Helicone	SaaS	Pro 79 $/mois (helicone.ai/pricing, lu le 24/10/2026)	Observabilité prod + eval
RAGAS	Open source	Gratuit	Métriques RAG spécifiques
LangSmith	SaaS LangChain	Plus 39 $ par siège et par mois (langchain.com/pricing, lu le 24/10/2026)	Observabilité + eval LangChain stack
OpenAI Evals	Open source	Gratuit	Eval simple OpenAI-compatible

Recommandation 2026 : Promptfoo pour les eval batch en CI/CD + Langfuse open source self-hosted pour l’observabilité prod. Côté logiciel, stack open source, complète, EU-friendly.

Étape 3 — Définir les seuils par métrique

Pour chaque métrique, définir :

• Seuil acceptable (au-dessus = OK)
• Seuil critique (en dessous = release bloquée, alerte immédiate)
• Métrique principale (la plus importante pour votre cas)

Exemple pour un RAG support client :

• Faithfulness : acceptable > 0,95, critique < 0,90
• Answer Relevancy : acceptable > 0,90, critique < 0,80
• Context Recall : acceptable > 0,75, critique < 0,60
• PII Leak : 0 cas (critique)
• p95 latency : < 4 sec (acceptable)

Étape 4 — Intégrer en CI/CD

Avant tout merge en main :

• Promptfoo run le dataset entier sur la nouvelle version du prompt
• Si une métrique passe sous le seuil critique → CI rouge, merge bloqué
• Si une métrique baisse de > 5 % vs main → review obligatoire
• Si tout est OK → merge autorisé

C’est la “regression test” pour LLM. Sans ça, vous mergez des dégradations silencieuses.

Étape 5 — Monitorer en prod en continu

Langfuse / Helicone trace 100 % des requêtes prod :

• Échantillon (10 %) passé en LLM evaluator pour scoring qualité
• Alertes seuils critiques (Slack / mail / PagerDuty)
• Dashboards quotidiens (qualité, coût, latence, volume)
• Annotation humaine des cas borderline (label “bon”, “moyen”, “mauvais”) pour enrichir le dataset

Étape 6 — Boucle d’amélioration continue

Tous les mois :

• Revue des cas annotés “mauvais” en prod
• Ajout des nouveaux cas tordus au dataset de référence
• Re-test prompts + comparaison avec baseline
• A/B testing de variantes prompts (Promptfoo facilite)
• Décision : on adopte la nouvelle version, on rollback, on continue à itérer

Anti-pattern 1 — “On testera quand on aura le temps”

Une équipe qui dit ça ne testera jamais. Mettre l’eval dès la phase POC, pas après la prod. Sinon dette technique impossible à rattraper.

Anti-pattern 2 — eval LLM jugé par LLM, sans étalonnage humain

LLM evaluator (Claude / GPT) peut être biaisé par lui-même. Recalibrer mensuellement avec annotation humaine sur 50-100 cas pour vérifier que le LLM evaluator note comme un humain expert.

Anti-pattern 3 — Dataset synthétique seul

Un dataset généré par GPT pour tester votre LLM = circular logic. Toujours mixer avec des cas réels prod.

Anti-pattern 4 — Mesurer une métrique sans seuil

Si vous mesurez la faithfulness mais ne savez pas si 0,87 est bon ou mauvais, vous ne pilotez rien. Définir les seuils ACCEPTABLE / CRITIQUE en équipe avant de mesurer.

Anti-pattern 5 — Ignorer la dérive temporelle

Vos seuils il y a 6 mois ne sont plus pertinents aujourd’hui. Re-calibrer trimestriellement. Vos cas réels évoluent, vos utilisateurs évoluent, le modèle évolue.

Ce qui fait le coût de l’évaluation continue

Trois postes : la mise en place (dataset, outil, seuils), la maintenance régulière (revue des cas annotés, ajustement des seuils) et l’outillage (voir les tarifs publics du tableau ci-dessus, plus les tokens du LLM-as-judge, calculés en FAQ). Le temps humain dépend de la taille du dataset et du nombre de cas d’usage. C’est ce poste qui distingue un projet suivi dans la durée d’un projet qui se dégrade sans signal.

Le combo recommandé

Pour un projet IA PME en 2026 :

• Eval batch en CI/CD : Promptfoo sur dataset 100-200 cas, run avant chaque merge prompt
• Observabilité prod : Langfuse self-hosted (gratuit) ou Helicone managed
• Métriques RAG : RAGAS pour faithfulness / context precision / context recall
• PII / toxicity : Microsoft Presidio + Detoxify
• Annotation humaine : 50 cas / mois minimum, rotative dans l’équipe

Côté logiciel, une stack open source et complète, compatible UE. Les coûts à prévoir sont l’hébergement, les tokens du juge et le temps humain.

Par où commencer

Rassemblez les questions réelles des derniers mois, annotez la bonne réponse attendue, lancez Promptfoo en CI et branchez Langfuse sur la production. C’est le moyen de ne pas découvrir trop tard que la qualité a dérivé.

Voir aussi : prompt engineering pour entreprise 2026, comparatif LangChain vs LlamaIndex vs Haystack, comment mesurer le ROI d’un projet IA PME 2026.