> For the complete documentation index, see [llms.txt](https://guides.ia.numerique.gouv.fr/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guides.ia.numerique.gouv.fr/guides/guide-de-construction-dun-assistant-conversationnel-base-sur-du-rag/evaluations-continues.md).
# Evaluations continues
{% hint style="info" icon="arrows-to-circle" %}
**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**
{% endhint %}
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
{% hint style="info" %}
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.
{% endhint %}
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**](/guides/guide-de-construction-dun-assistant-conversationnel-base-sur-du-rag/jeu-de-donnees-de-reference.md) ;
* les [**métriques RAG**](/guides/guide-de-construction-dun-assistant-conversationnel-base-sur-du-rag/evaluations-automatisees.md) 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.
{% hint style="info" %}
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.
{% endhint %}
## 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**.
{% hint style="info" %}
#### 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.
{% endhint %}
## Tester les évolutions en pré-production
Avant déploiement, les modifications techniques sont évaluées en pré-production via les [évaluations automatisées](/guides/guide-de-construction-dun-assistant-conversationnel-base-sur-du-rag/evaluations-automatisees.md) :
* 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.**
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://guides.ia.numerique.gouv.fr/guides/guide-de-construction-dun-assistant-conversationnel-base-sur-du-rag/evaluations-continues.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
