Dans cet article
- Pourquoi l'évaluation de votre chatbot n'est pas facultative
- Étape zéro : définir ce que « réussir » veut dire pour vous
- Constituer un « jeu de données de référence »
- Que mesurer exactement ? Les dimensions essentielles
- Les trois méthodes d'évaluation
- Évaluation hors ligne et évaluation en ligne
- Un processus pratique pour lancer l'évaluation
- Les erreurs courantes qui rendent l'évaluation inutile
- Les outils qui aident
- Le rôle d'Origami
Pourquoi l'évaluation de votre chatbot n'est pas facultative
Lancer un chatbot IA est facile aujourd'hui ; savoir s'il est réellement bon, c'est la partie difficile. Les modèles de langue sont probabilistes par nature : une même question peut produire deux réponses différentes, et « je l'ai essayé et ça avait l'air bien » sur une poignée de consignes ne veut pas dire qu'il est prêt pour des milliers de clients. L'évaluation est la manière systématique de répondre à une question : le bot fait-il son travail avec précision, en toute sécurité et de façon constante, avant sa mise en production et après chaque modification ?
La règle est simple : on ne peut pas améliorer ce que l'on ne mesure pas. Sans système d'évaluation, chaque retouche de consigne ou changement de modèle devient un pari où vous ne savez pas si vous avez amélioré quelque chose ou discrètement cassé autre chose.
Étape zéro : définir ce que « réussir » veut dire pour vous
Avant tout indicateur, répondez à cette question : quelle tâche le bot est-il censé accomplir ? Un bot d'assistance réussit lorsqu'il résout le problème ou l'oriente correctement. Un bot commercial réussit lorsqu'il qualifie le prospect et recueille les bonnes données. Un bot interne destiné aux employés réussit lorsqu'il répond avec exactitude, en s'appuyant sur vos règles. Reliez l'évaluation à un objectif métier, et non à une vague impression que la réponse se lit bien.
Constituer un « jeu de données de référence »
Le fondement de toute évaluation sérieuse est un ensemble fixe d'exemples sur lequel vous testez à chaque fois. Constituez-le à partir de trois sources :
- De vraies questions tirées des journaux de conversation réels (après suppression des données personnelles).
- Des cas limites : questions vagues, incomplètes ou hors périmètre, ou formulées dans différents dialectes.
- Des cas adverses : tentatives de pousser le bot au-delà de ses limites ou de lui faire divulguer des informations.
Commencez par 50 à 100 exemples qui couvrent vos scénarios les plus importants, plutôt que par des milliers d'exemples pris au hasard. Pour chacun, définissez autant que possible la réponse de référence ou le critère qui rend une réponse correcte.
Que mesurer exactement ? Les dimensions essentielles
« Qualité » est un mot flou ; décomposez-le donc en dimensions mesurables :
- Succès de la tâche : l'utilisateur a-t-il réellement atteint son objectif ? L'indicateur le plus important et le plus proche de la valeur métier.
- Fidélité (absence d'hallucination) : dans les systèmes ancrés dans vos sources (RAG), la réponse repose-t-elle uniquement sur les documents récupérés, ou le bot a-t-il inventé quelque chose ?
- Pertinence : la réponse traite-t-elle vraiment la question de l'utilisateur, ou se contente-t-elle de tourner autour du sujet ?
- Qualité de la recherche : en RAG, le système a-t-il extrait les bons passages de votre base de connaissances (précision et rappel du contexte) ? La plupart des échecs en RAG viennent d'une mauvaise recherche, et non du modèle lui-même.
- Exactitude : la réponse correspond-elle à une référence connue ?
- Sécurité et conformité : refuse-t-il les demandes dangereuses ? Protège-t-il les données personnelles ? Respecte-t-il le ton et les règles de la marque ? Résiste-t-il aux tentatives de contournement (jailbreak) ?
- Coût et latence : une excellente réponse qui prend 30 secondes ou coûte trop cher par conversation peut être un échec commercial. Mesurez toujours les jetons et le temps.
Les trois méthodes d'évaluation
- L'évaluation humaine : la référence absolue pour la qualité, mais lente, coûteuse et difficile à passer à l'échelle. Utilisez-la pour construire votre référence et calibrer les méthodes automatisées.
- Le LLM comme juge : vous utilisez un modèle puissant pour noter les réponses du bot selon une grille claire, ou en comparant deux réponses. Rapide et capable de passer à l'échelle, c'est l'approche la plus courante aujourd'hui, à condition de la calibrer par rapport au jugement humain et de surveiller ses biais (comme la préférence pour la réponse la plus longue).
- Les indicateurs automatisés fondés sur une référence : comme la correspondance exacte pour les questions à réponse fermée, ou la similarité sémantique au moyen d'embeddings. Peu coûteux et instantanés, mais limités pour les réponses ouvertes.
En pratique : combinez les trois. Des indicateurs automatisés rapides comme premier filet, un LLM juge pour les dimensions qualitatives, et une relecture humaine périodique d'un échantillon.
Évaluation hors ligne et évaluation en ligne
Il existe deux types complémentaires, et il vous faut les deux :
- Hors ligne : vous faites tourner le bot sur votre jeu de données de référence à chaque modification, idéalement dans un pipeline CI/CD, pour qu'aucune mise à jour n'atteigne la production si les scores baissent. C'est le test de non-régression qui vous empêche de casser ce qui fonctionnait déjà.
- En ligne : auprès des vrais utilisateurs, avec des tests A/B entre deux versions, un bouton de retour (👍/👎) et des indicateurs de garde-fou (taux de transfert vers un humain, questions répétées, abandon de conversation). Surveillez la production en continu, car le comportement réel des utilisateurs révèle ce qu'aucun jeu de test ne peut montrer.
Un processus pratique pour lancer l'évaluation
- Définissez les 3 à 5 dimensions qui comptent vraiment pour vous (par exemple le succès de la tâche, la fidélité et la sécurité).
- Constituez un jeu de référence petit mais représentatif (50 à 100 cas).
- Rédigez une grille de notation claire pour chaque dimension : ce qui mérite un 5 et ce qui mérite un 1.
- Automatisez l'exécution : un script qui fait tourner le bot sur le jeu et calcule les scores (humain + LLM juge).
- Intégrez-le au pipeline de déploiement : tout score inférieur au seuil bloque la mise en production.
- Ajoutez une boucle de production : collectez les retours des utilisateurs et les cas d'échec, et ajoutez-les continuellement à votre jeu de référence.
Les erreurs courantes qui rendent l'évaluation inutile
- Ne tester que le scénario idéal et ignorer les cas limites et adverses.
- Un jeu de test trop petit ou non représentatif de vos vrais utilisateurs.
- Se fier à un LLM juge sans l'avoir calibré par rapport au jugement humain.
- Ignorer le coût et la latence pour se concentrer uniquement sur la qualité.
- Évaluer une seule fois au lancement au lieu d'en faire un processus continu à chaque mise à jour.
La valeur ne consiste pas à livrer un bot qui parle, mais à disposer d'un système qui vous dit, chiffres à l'appui, s'il s'est amélioré ou dégradé après chaque modification.
Les outils qui aident
Des outils open source et commerciaux permettent de raccourcir la construction d'un pipeline d'évaluation, notamment Ragas et DeepEval pour les systèmes RAG ; LangSmith, Braintrust et Arize Phoenix pour la supervision et l'évaluation ; et OpenAI Evals et promptfoo pour l'écriture de tests. Choisissez l'outil qui correspond à votre environnement technique, mais n'oubliez pas que la méthode compte davantage que l'outil.
Le rôle d'Origami
Chez Origami, nous sommes une société technologique qui construit des systèmes d'IA et les mesure avant de les livrer : nous concevons un jeu de données de référence adapté à votre domaine, construisons un pipeline d'évaluation automatisé intégré au déploiement et ajoutons une supervision en production qui détecte tôt les régressions et maîtrise les coûts. L'objectif est un bot dont vous pouvez croire les chiffres, et pas seulement une démonstration.
Sources
- Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (Zheng et al., 2023) : arxiv.org/abs/2306.05685
- Documentation de Ragas sur les indicateurs d'évaluation RAG (fidélité, pertinence, qualité du contexte) : docs.ragas.io
- Documentation de LangSmith sur l'évaluation : docs.smith.langchain.com
- OpenAI Evals : github.com/openai/evals
- Recommandations d'Anthropic pour construire des évaluations : docs.anthropic.com
Questions fréquentes
Quelle est la différence entre l'évaluation hors ligne et l'évaluation en ligne ?
L'évaluation hors ligne fait tourner le bot sur un jeu de données de référence fixe à chaque modification, idéalement dans votre pipeline CI, pour détecter les régressions avant la mise en production. L'évaluation en ligne se fait auprès des vrais utilisateurs, au moyen de tests A/B, de boutons de retour et d'indicateurs de garde-fou. Il vous faut les deux : l'évaluation hors ligne vous protège avant la livraison, tandis que l'évaluation en ligne révèle ce que seul l'usage réel met en évidence.
Combien d'exemples me faut-il dans mon jeu de test ?
Commencez par 50 à 100 exemples bien choisis qui couvrent vos scénarios les plus importants et les plus risqués, plutôt que des milliers d'exemples pris au hasard. Un petit jeu représentatif et bien annoté vaut mieux qu'un grand jeu bruité, et vous l'enrichissez au fil du temps en y ajoutant les vrais échecs observés en production.
Puis-je compter sur un modèle d'IA pour s'évaluer lui-même ?
Le LLM comme juge est rapide, passe à l'échelle et est largement utilisé, mais il comporte des biais (comme une préférence pour les réponses plus longues) et doit être calibré par rapport au jugement humain sur un échantillon. Utilisez-le pour les dimensions qualitatives, maintenez une relecture humaine périodique, et ne considérez jamais sa note comme une vérité établie sans vérification.
Par quel indicateur commencer ?
Le succès de la tâche, c'est-à-dire le fait que l'utilisateur a réellement atteint son objectif, car c'est l'indicateur le plus proche de la valeur métier. Pour les systèmes ancrés dans vos documents (RAG), ajoutez la fidélité pour éviter les hallucinations, puis ajoutez progressivement la sécurité, le coût et la latence.
À quelle fréquence faut-il réévaluer ?
À chaque modification significative (une retouche de consigne, un changement de modèle ou une mise à jour de la base de connaissances) et en continu en production. L'évaluation n'est pas un contrôle ponctuel au lancement ; c'est un processus continu qui vous dit si chaque changement a aidé ou nui.
Suivez Origami sur Google
Ajoutez Origami à vos sources préférées : nos articles apparaîtront en premier pour vous dans la recherche Google et les actualités à la une.








