Vous connaissez le timing? Mercredi soir votre modèle fonctionne. Jeudi matin vous changez un prompt « légèrement » meilleur. Samedi vous découvrez que vous dégradez de 15%. Et vous l'aviez pas vu parce qu'il n'y avait rien pour vous alerter.
C'est exactement ce qui se passe dans les orga qui déploient sans évaluations formalisées. Anthropic (2025) rapporte que cette dégradation silencieuse atteint 15-20% de qualité en six mois. C'est insidieux parce que ça progresse doucement, invisiblement. Personne ne dit « eh, c'est dégradé ». Puis un jour un utilisateur cligote sur Twitter, et là vous comprenez.
Les evals sont votre filet de sécurité.
Trois types d'évals indispensables
Il faut combiner trois approches. Aucune ne suffit seule.
Les evals offline d'abord : jeux de test statiques avec réponses de référence. Ils tournent automatiquement à chaque changement. Prompt modifié? Test. Modèle mis à jour? Test. Données contextuelles changées? Test. Ils capturent les régressions avant la production. C'est le filet de sécurité niveau 1.
Les evals online ensuite : monitoring temps réel en production. Taux de feedback négatif utilisateur. Hallucinations détectées. Latence. Taux de retry. Ce qui se passe vraiment quand les utilisateurs interagissent avec votre système. C'est le filet de sécurité niveau 2.
Les evals humaines enfin : une évaluation périodique d'un échantillon par des experts métier. Notées sur des critères explicites - pertinence, exactitude, ton, complétude. C'est le filet de sécurité niveau 3, l'assurance que vos métriques automatisées sont bien corrélées à la réalité métier.
Parce qu'une métrique peut monter alors que la qualité réelle dégringole. D'où l'importance de vérifier.
Le dataset d'évaluation: le fondement
La qualité de vos evals dépend à 90% de votre dataset de test. Construire celui-ci est du travail partagé entre data scientists et experts métier.
Couvrez les cas nominaux - les questions qui arrivent tous les jours. Intégrez les edge cases - ambiguïtés, complexité. Incluez les cas adverses - les pièges, les injections de prompt, les demandes hors périmètre. Et les cas métier spécifiques - terminologie exacte, règles business bizarres.
Recommandation concrète : 100 à 200 cas soigneusement annotés pour démarrer. Puis enrichissez continuellement à partir des erreurs détectées en prod. Un dataset de 500 cas bien construits vaut mieux que 10 000 générés automatiquement. C'est une question de densité, pas de quantité.
LLM-as-a-judge: c'est le scaling play
Comment évaluer à grande échelle sans 50 évaluateurs humains? Vous utilisez un modèle puissant pour évaluer un autre modèle. GPT-4. Claude. Ces modèles évaluent selon des critères pré-définis. Exactitude factuelle. Pertinence. Exhaustivité. Absence d'hallucination. Respect du ton.
L'important : calibrer votre judge sur les annotations humaines. Vérifier la corrélation. Un taux de concordance >85% entre le juge LLM et les humains, c'est un bon seuil.
Après ça, vous avez un test automatisé fiable. Vous pouvez évaluer 10 000 réponses par jour. Ça change complètement le jeu.
Pipeline automatisé = confiance en production
L'objectif : automatiser le pipeline entier. À chaque modification - prompt, modèle, données - les evals offline tournent automatiquement via CI/CD. Si la qualité chute sous un seuil prédéfini, le déploiement est bloqué. Exactement comme les tests unitaires bloquent un merge.
Les outils pour ça : LangSmith (LangChain), Braintrust, Ragas pour les evals automatisées. GitHub Actions ou GitLab CI pour l'orchestration. Dashboard de suivi des métriques dans le temps.
C'est du software engineering appliqué à la GenAI. Point.
De l'évaluation à l'amélioration en boucle
Les evals ne servent pas juste à détecter. C'est le moteur de l'amélioration continue. Vous analysez vos erreurs les plus fréquentes. Vous les clustérisez. Vous identifiez les causes racines - prompt insuffisant, contexte manquant, limite du modèle. Vous itérez. Vous validez avec les evals. Vous ajoutez les cas d'erreur au dataset pour éviter les régressions.
Ce cycle répété hebdomadairement produit une amélioration continue. Les meilleures équipes automatisent même l'analyse d'erreurs avec Braintrust ou des scripts custom.
L'infrastructure qui dépend d'evals robustes
En production, vous vous reposez sur vos evals pour :
- Valider les changements avant go-live.
- Détecter les dérives avant les utilisateurs.
- Arbitrer les décisions - ce prompt est meilleur selon quels critères?
- Documenter la qualité - hier ça valait 82%, aujourd'hui 84%.
- Justifier les investissements - on a amélioré la qualité de 8%, voilà pourquoi c'était utile.
Sans evals, vous naviguez au sentiment. Avec evals, c'est de l'opérationnel. De la vraie production. Les meilleurs systèmes GenAI en 2026? Ils ont tous un système d'évaluation obsessif.
C'est pas glamour. C'est fondamental.