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 la méthode qu’on applique chez Kezify 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 :
- 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.
- É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é.
- Cas tordus en prod — votre dataset de test couvre 80 % des cas. Les 20 % bizarres tombent en prod et le LLM hallucine sans alerte.
- 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 6-18 mois trop tard, quand un client vous appelle pour signaler un bug majeur.
Les 5 dimensions d’évaluation d’un LLM en prod
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 acceptable : > 0,95 sur dataset de test. < 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 acceptable : > 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 acceptables : 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épend de votre cas (chat = p95 < 4 sec, batch = pas de contrainte forte). 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.
La méthode de mise en place — 6 étapes
É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 : 2-4 jours de travail produit + expert métier pour 100 cas. 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, $25-99/mois SaaS | Observabilité prod + eval |
| Helicone | SaaS | $25-200/mois | Observabilité prod + eval |
| RAGAS | Open source | Gratuit | Métriques RAG spécifiques |
| LangSmith | SaaS LangChain | $39-199/mois | 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. Stack gratuite, 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
Les 5 anti-patterns courants
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.
Le coût de l’évaluation continue
Pour un projet IA PME 50 k€-150 k€ devis initial, budget eval :
- Mise en place initial dataset + outil + seuils : 8-15 k€ (5-10 jours)
- Maintenance mensuelle (revue + ajustement) : 1-2 k€/mois
- Outil monitoring (Langfuse / Helicone) : 0-200 € / mois
Total annuel : 15-30 k€. C’est ~10 % du budget projet, mais c’est ce qui distingue un projet qui dure 3 ans d’un projet qui meurt à 18 mois.
Le combo recommandé chez Kezify
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
Stack quasi-gratuite (€0-200/mois), complète, EU-compatible. Pas d’excuse pour ne pas le faire.
Pour votre projet
Si vous démarrez ou opérez un projet LLM en prod en France et vous voulez mettre en place une évaluation sérieuse, 30 minutes au téléphone suffisent. On vous donne le squelette dataset + Promptfoo + Langfuse à reproduire. C’est l’investissement à plus haut ROI long terme : ne pas découvrir 18 mois 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.