Evaluations continues

Mettre en place un cycle d’évaluation continue en production pour piloter simultanément l’évolution du système, le monitoring des performances et la satisfaction des utilisateurs

Une fois l’assistant déployé en production, les besoins d’évaluation évoluent. Il ne s’agit plus uniquement de valider la faisabilité ou la qualité initiale du système, mais de piloter sa performance dans la durée, d’accompagner la montée en charge et de garantir une valeur constante pour les utilisateurs.

Nous pouvons donc distinguer deux catégorie d'évaluations :

• les évaluations off-line dans lesquelles s'inscrivent les évaluations par les référents métier et les évaluations automatisées présentées dans les pages précédentes. La matière première est le jeu de données de référence en phase de développement, puis peut devenir les traces en phase de production.
• les évaluations on-line (en temps réel) dont la matière première correspond aux interactions des utilisateurs avec l'application en production

Ce guide vous accompagne dans les premières étapes de la conception de votre assistant conversationnel, fondé sur une architecture RAG. Il propose des éléments clés pour structurer un cycle complet d’évaluation et de monitoring de l’outil, sans entrer dans les détails techniques lors d'un passage à l'échelle.

Tout au long du cycle, vous surveillez des alertes sur les métriques critiques (baisse de performance, augmentation de latence, diminution de la satisfaction utilisateurs) et maintenez un tableau de bord avec l'évolution des indicateurs clés dans le temps.

D'une manière générale, les évaluations en production incluent automatisation et humains :

• Automatique : métriques continues sur le jeu de données de référence, qui peuvent être approfondies après les premières phases de construction. 🏗️​Évaluations automatisées
• Humain : une équipe de référents vérifie ponctuellement / régulièrement un échantillon de résultats récents, notamment pour les cas de "référence" ou les cas problématiques identifiés par le monitoring
• Retours utilisateurs : métriques d'usage et satisfaction des utilisateurs

Il s'agit de créer un compromis : pas d'humain à chaque itération (trop coûteux), mais pas d'absence totale (trop risqué).

Illustration des évaluations selon la phase de développement

Déroulé du cycle d'évaluations continues

• Observer et collecter des données de performance : Feedbacks utilisateurs, conversations, signaux d’adoption.
• Mesurer automatiquement : qualité RAG (retrieval & génération), performances, conformité.
• Analyser et qualifier : revue humaine ciblée des cas en échec ou à risque.
• Décider : Ajustement du corpus, des prompts, du modèle ou des règles.
• Tester et déployer : évaluations en pré-production, puis monitoring post-déploiement.
• Enrichir : jeux de données de références, métriques, process

Le cycle se répète en continu, en intégrant progressivement les nouveaux usages dans le référentiel d’évaluation.

Collecter -> Mesurer -> Analyser -> Prioriser -> Développer -> Tester -> Déployer -> Enrichir

Observer et collecter des données de performance

Le cycle démarre par la collecte de signaux issus de l’utilisation réelle de l’assistant :

• conversations utilisateurs (les requêtes posées, les documents retrievés, les réponses générées)
• feedbacks explicites (notes, commentaires, signalements) ;
• données d’usage (fréquence, récurrence, abandons).

Au-delà des métriques spécifiques à l’IA (fidélité, précision du retrieval, hallucinations, etc.), les indicateurs produit classiques jouent également un rôle déterminant. Le taux d’adoption, la fréquence d’usage, la récurrence des utilisateurs, la durée des sessions ou encore le taux d’abandon fournissent des informations précieuses sur la valeur réelle perçue par les agents. Un assistant techniquement performant mais peu utilisé révèle souvent un problème de positionnement, d’ergonomie ou de confiance. Croiser métriques IA et métriques produit permet ainsi d’obtenir une vision complète : qualité technique d’un côté, utilité et appropriation de l’autre.

L'objectif est donc de collecter les informations nécessaires pour comprendre comment le système est réellement utilisé, identifier les cas utiles, les irritants et les zones de risque.

Mesurer de manière automatique

En parallèle, des évaluations automatisées sont exécutées de manière régulière ou déclenchées par un événement (nouvelle version, mise à jour documentaire).

Elles s’appuient sur :

• le jeu de données de référence ;
• les métriques RAG couvrant les métriques définies pour le système :

  • la recherche documentaire (ex. Recall@k, Precision@k) ;
  • la génération (fidélité aux sources, pertinence) ;
  • la performance technique (latence, taux d’erreur, coût).
  • la satisfaction utilisateur (basée sur les feedbacks explicites ou implicites)

L'objectif est de détecter rapidement des régressions, mesurer les gains ou pertes liés aux évolutions du système. Ces métriques peuvent être exécutées de manière hebdomadaire une fois l'assistant conversationnel en production dans l'optique d'être alerté spontanément en cas de régression du système.

Analyser les usages

L’analyse vise une compréhension approfondie des usages réels. Il s’agit d’examiner les informations collectées et / ou mesurer (conversations, les requêtes fréquentes ou atypiques, les abandons et les retours utilisateurs) afin d’identifier les besoins sous-jacents, explicites ou implicites.

Les métriques automatiques constituent un point d’alerte, mais leur interprétation doit s’appuyer sur une analyse humaine structurée : revue de conversations représentatives, compréhension métier des cas en difficulté, et distinction entre incident ponctuel et tendance significative. Cette approche permet de remonter aux causes profondes des défaillances — qu’elles relèvent du retrieval, de la génération, du corpus documentaire ou du cadrage produit — et d’orienter les priorités d’amélioration en cohérence avec les usages réels.

L’équipe doit donc régulièrement analyser un échantillon de questions-réponses en production pour comprendre comment l’assistant est réellement utilisé, dans quels contextes, et avec quelles attentes. Cette lecture qualitative permet de détecter des décalages entre le périmètre initial et les usages observés, de repérer des besoins émergents ou mal couverts, et d’identifier des zones de fragilité dans le système.

Alors que les projets numériques nécessitent souvent des enquêtes spécifiques pour identifier les besoins non couverts (interview utilisateur, sondage, retours utilisateurs), un assistant conversationnel offre un accès direct aux attentes des utilisateurs : chaque question posée reflète un besoin réel. Les données d’usage deviennent ainsi un levier central pour nourrir la feuille de route produit.

Décider et prioriser les améliorations

Sur la base de ces analyses, l'équipe définit et priorise les actions correctives ou évolutives :

• enrichissement ou nettoyage du corpus documentaire ;
• ajustement des paramètres de recherche ;
• évolution des prompts ou du modèle ;
• ajout de garde-fous ou règles de refus ;
• réflexion sur le périmètre du produit et priorisation des cas d'usage.

L'objectif est de concentrer les efforts là où l’impact utilisateur est le plus fort.

Rédaction d'un besoin fonctionnel

Dans le cadre d’un assistant conversationnel, les spécifications fonctionnelles gagnent à être formulées de manière très concrète, en s’appuyant sur la logique besoin = questions / réponses. Plutôt que de décrire uniquement des fonctionnalités, il est recommandé d’exprimer le besoin métier sous forme de situations réelles : - Quelles questions un utilisateur doit-il pouvoir poser ? - Dans quel contexte ? - Quel type de réponse est attendu (explication synthétique, référence réglementaire, procédure détaillée, renvoi vers une source) ? Cette approche permet d’ancrer les spécifications dans l’usage réel et de constituer progressivement un jeu de cas représentatifs. Les critères d’acceptation doivent ensuite être traduits en niveaux de qualité mesurables, adossés à des métriques dont il convient de préciser le niveau attendu. Pour chaque question représentative, on définit la réponse attendue et les indicateurs permettant d’évaluer objectivement si le système est conforme. Cette articulation entre cas d’usage concrets et métriques cibles facilite le pilotage des itérations et limite les débats subjectifs sur la “qualité” de l’assistant.

Tester les évolutions en pré-production

Avant déploiement, les modifications techniques sont évaluées en pré-production via les évaluations automatisées :

• exécution des évaluations automatiques sur le jeu de données de référence ;
• comparaison avec la version en production ;
• validation humaine sur un échantillon critique.

L'objectif est de s’assurer que l’évolution améliore le système sans introduire de nouveaux risques.

Déployer et monitorer

Le cycle recommence régulièrement (quotidien, hebdomadaire, mensuel selon l'évolution du système), permettant une amélioration incrémentale et adaptée à l'usage réel.

Une fois déployée, la nouvelle version est monitorée en continu :

• suivi des métriques clés ;
• observation de la satisfaction utilisateur ;
• surveillance des signaux de dérive ou de non-conformité.

L'objectif est de sécuriser la mise en production et détecter rapidement tout comportement inattendu.

Boucler et enrichir le référentiel d’évaluation

Enfin, le cycle se referme par :

• l’enrichissement du jeu de données de référence avec de nouveaux cas réels ;
• l’ajustement des métriques ou des seuils ;
• l’amélioration des processus d’évaluation eux-mêmes.

L'objectif est de faire évoluer le dispositif d’évaluation au même rythme que le système et ses usages.