> 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-referents-metier.md).
# Evaluations référents métier
{% hint style="info" icon="arrows-to-circle" %}
**Assurer l’évaluation de la qualité métier du système RAG par une mobilisation progressive et structurée de testeurs métiers engagés**
{% endhint %}
Contrairement aux modèles de langage classiques, qui génèrent des réponses à partir de patterns appris, les systèmes RAG s'appuient sur des sources externes (base de connaissance) pour enrichir leurs réponses. Cela introduit une complexité supplémentaire : la **qualité de la réponse** dépend non seulement de la capacité du modèle à **générer un texte cohérent**, mais **aussi de sa capacité à identifier, extraire et synthétiser les informations pertinentes** à partir de documents parfois volumineux et hétérogènes.
Une évaluation purement automatique [Évaluations automatisées](/guides/guide-de-construction-dun-assistant-conversationnel-base-sur-du-rag/evaluations-automatisees.md), basée sur des métriques comme la précision ou le rappel, ne suffit pas. Elle ne peut pas juger de la pertinence contextuelle des sources, de la fluidité de la synthèse, ... C'est là que l'évaluation humaine intervient, en apportant une dimension qualitative et critique indispensable.
## Concevoir des protocoles de test adaptés
L’évaluation d’un système RAG doit s’appuyer sur des **protocoles de test différenciés selon les phases du projet**. Les objectifs, les critères d’évaluation et les profils mobilisés ne sont pas les mêmes selon que l’on se situe dans une phase de validation métier ou dans une phase d’usage opérationnel.
### Distinguer les phases d’évaluation
💡 Lors des premières phases d’évaluation de l'assistant conversationnel, en cas d’absence de référents métiers, l’équipe projet peut porter un regard critique «naïf» sur les réponses produites par l’assistant conversationnel.
Sans disposer d’une connaissance experte de la réponse attendue, l’équipe est généralement en capacité d’identifier les réponses manifestement incorrectes, incohérentes ou hors sujet. Cette première analyse permet ainsi de disposer d’une autonomie initiale dans les phases amont de l’évaluation.
La mobilisation des référents métiers intervient alors de manière plus ciblée, lorsque l’équipe estime que la majorité des réponses n’est plus clairement erronée mais potentiellement correcte, et que l’enjeu porte désormais sur la justesse fine, la conformité métier et la valeur d’usage.
**Phase 1 – Évaluations métiers**
Les premières évaluations, ou les évaluations liées aux évolutions du système, doivent être menées par des experts métiers (sachants). Leur rôle est de valider la qualité métier du moteur en cours de construction, indépendamment des conditions réelles de déploiement.
Ces tests visent notamment à :
* vérifier la pertinence fonctionnelle des réponses ;
* contrôler l’exactitude et la fiabilité des informations produites ;
* identifier les lacunes documentaires ou les défauts de raisonnement du système.
**Phase 2 – Tests utilisateurs (beta-tests)**
Une fois la qualité métier jugée satisfaisante par les sachants, des tests utilisateurs élargis pourront être engagés. Ils impliquent un cercle plus diversifié d’agents publics, représentatif des futurs utilisateurs finaux.
Cette phase vise à évaluer :
* l’impact réel de l’outil sur les pratiques professionnelles ;
* l’appropriation par les équipes ;
* la compréhension des réponses et la confiance accordée au système.
## Tester dans des conditions proches de l’usage réel
Pour évaluer un système RAG, il est essentiel de **simuler des questions réelles d'utilisation**. Cela peut inclure :
* Des **questions types** représentatives des cas d'usage (ex. : questions techniques pour un assistant juridique, demandes grand public pour un chatbot usager).
* Des **scénarios de "stress test"** :
* des questions comportant des ambiguïtés, des fautes d’orthographe ou une formulation imprécise ;
* Questions pièges pour évaluer la robustesse (ex. : "Quelle est la capitale de la France en 2050 ?").
* Questions liées à l'éthique, à la discrimination, et aux biais
Lors de la session d'évaluation, les référents métiers formulent le plus souvent des questions directement issues de leur **expérience professionnelle et de situations concrètes rencontrées**** au quotidien**. Ces questions spontanées constituent une source précieuse d’évaluation, car elles reflètent fidèlement les usages réels et les attentes opérationnelles.
En complément, l’équipe projet peut **préparer en amont un ensemble de questions types**, organisées par thématiques ou par cas d’usage. Cette préparation permet de structurer les séances d’évaluation, de garantir une couverture homogène des principaux scénarios et de faciliter la comparaison des résultats dans le temps.
La combinaison de questions spontanées issues du terrain et de scénarios préparés en amont offre ainsi un **équilibre efficace entre réalisme, exhaustivité et reproductibilité** dans l’évaluation de l’assistant conversationnel.
Afin d’harmoniser et de rendre exploitables les retours des référents métiers et des testeurs, il est recommandé d’utiliser une **grille d’évaluation standardisée et la possibilité de compléter la notation par une annotation**, dont on propose des exemples ci-dessous :
| **Critère** | **Description** |
| ------------------------------- | ---------------------------------------------------------------------------------------- |
| **Pertinence des sources** | Les documents récupérés sont-ils adaptés à la question et à jour ? |
| **Exactitude des informations** | Les informations extraites et générées sont-elles correctes ? |
| **Fidélité à la génération** | La réponse reflète-t-elle fidèlement les sources, sans déformation ni hallucination ? |
| **Transparence** | Le système cite-t-il clairement ses sources et indique-t-il ses limites ? |
| **Fluidité de la réponse** | La réponse est-elle naturelle, bien structurée et facile à comprendre ? |
| **Robustesse aux ambiguïtés** | Le système gère-t-il les questions mal formulées ou complexes de manière satisfaisante ? |
| **Absence de biais** | Les sources et la réponse sont-elles exemptes de biais (culturels, idéologiques, etc.) ? |
Illustration des critères d'évaluation dans l'outil
**Annoter les réponses pour une analyse fine**
L'annotation manuelle des réponses est une mine d'or pour l'équipe. Elle permet d'identifier des **patterns d'erreurs** ou des **points forts** récurrents. Les référents peuvent, par exemple :
* Surligner les passages **fidèles aux sources** et ceux qui sont **générés ou extrapolés ;**
* Signaler les **incohérences**, imprécisions ou manques de clarté ;
* Identifier un besoin de précision sur les acronymes.
Cette même grille peut s'appliquer pour les premières expériences de beta-tests afin de bien comprendre dès le départ les forces et les limites de l'outil.
## Impliquer des référents métiers et testeurs engagés
> Des utilisateurs métiers motivés, critiques et engagés sont un levier clé pour améliorer la qualité et la pertinence d’un moteur d’IA dans la durée.
Pour couvrir tous les angles, selon la phase d'évaluations, il est important de faire appel à des référents aux profils variés :
* **Référents métiers** pour évaluer la **pertinence métier** des réponses.
* **Utilisateurs finaux** pour tester la **clarté** et l'**utilisabilité**.
Cette diversité permet de recueillir des retours complets et de s'assurer que le système est **robuste** dans différents contextes.
**Cibler les bons profils dès le départ**
L’implication de profils métiers dans l’évaluation d’un moteur d’IA représente un réel challenge. Cela leur demande un investissement en temps sur leurs horaires professionnels, un temps dont les agents publics ne disposent pas toujours. Par ailleurs, si les améliorations du moteur ne sont pas perçues comme suffisamment rapides ou qualitatives, un risque de démobilisation progressive peut apparaître.
Dans ce contexte, il est recommandé de **limiter volontairement le nombre de participants lors des premières phases**. Un cercle restreint permet de mieux valoriser les contributions, de maintenir l’engagement et de piloter plus efficacement les retours.
**Sélectionner des personnes motivées et lucides sur les limites de l’IA générative. Il est essentiel d’identifier des profils :**
* **volontaires et impliqués**, prêts à consacrer du temps à l’expérimentation ;
* disposant d’une **expertise métier avérée**, leur permettant d’évaluer la pertinence fonctionnelle, la justesse des réponses et l’adéquation aux usages réels pour les phases d'évaluation de la qualité métier de l'outil ;
* **conscients des limites** de l’IA générative, afin de formuler des retours réalistes et exploitables ;
* **motivés par l’amélioration de leurs pratiques professionnelles**, même s’ils ne sont pas experts de la technologie.
Ces personnes ne sont pas nécessairement déjà convaincues ou technophiles. Elles peuvent se montrer sceptiques ou interrogatives, ce qui constitue un atout : leurs retours sont souvent plus exigeants, plus concrets et plus proches des usages réels que ceux de profils déjà acquis à la technologie.
Selon les phases du projet, l’ensemble de ces critères n’est pas nécessairement requis. Le prérequis essentiel reste de s’appuyer sur des personnes motivées et engagées, faisant preuve d’enthousiasme et prêtes à s’investir dans la démarche.
Ces profils sont généralement capables de dégager du temps pour participer activement aux travaux d’évaluation et sont souvent directement confrontés aux problématiques identifiées lors de la phase d’investigation, ce qui rend leurs retours particulièrement pertinents et actionnables.
| | **Profils** |
| --------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| **Phase 1 – Évaluations métier** |
- volontaires et impliqués - sachants - conscients des limites
- volontaires et impliqués - motivés par l’amélioration de leurs pratiques professionnelles
|
## Alléger et structurer l’effort d’évaluation
Les agents publics mobilisés comme testeurs ne disposent pas toujours, dans leur quotidien professionnel, du temps nécessaire pour contribuer régulièrement aux travaux d’évaluation. Cette participation peut alors être perçue comme une charge mentale supplémentaire : *« Il faut que j’évalue, quand vais-je trouver le temps ? »*, *« J’ai oublié »*, etc. Cette difficulté est particulièrement marquée lors de la constitution du jeu de données de référence, une activité exigeante, répétitive et souvent peu valorisante.
Pour limiter ces freins, il est recommandé de mettre en place un accompagnement rapproché des phases de participation. L’objectif est de faciliter la collecte des retours tout en réduisant la dépendance à la disponibilité individuelle et aux contraintes organisationnelles des agents.
Il est ainsi préférable de **privilégier des temps d’évaluation formalisés et organisés**, en bloquant des créneaux dédiés dans les agendas des participants. Il est en effet plus simple et moins contraignant pour un testeur de savoir, par exemple, que mardi de 10 h à 11 h est consacré aux évaluations, plutôt que de devoir intégrer cette tâche de manière diffuse dans son emploi du temps. Cette organisation contribue à alléger la charge mentale et à sécuriser la participation.
La mise en place de sessions collectives et l’animation d’un véritable cercle de testeurs constituent des leviers efficaces d’engagement. Des temps partagés avec d’autres testeurs apportent une dimension plus conviviale et stimulante, en rupture avec le quotidien de travail, ce qui favorise la motivation et la régularité des contributions.
Il est important d’anticiper que les premiers testeurs et expérimentateurs pourront, à terme, jouer un **rôle clé de relais**. En partageant leur retour d’expérience, en expliquant les objectifs et les bénéfices du projet, ils pourront devenir de véritables ambassadeurs au sein de leurs équipes et faciliter l’appropriation du dispositif à plus grande échelle
---
# 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-referents-metier.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.
