Agents documentaires : 3. Tester et évaluer
Concevoir et configurer l'agent n'est que le début. Un agent documentaire doit encore être préparé à un usage réel.
Avant publication, cela signifie anticiper la manière dont les utilisateurs vont interagir avec lui, définir à quoi doit ressembler une réponse utile et vérifier que son comportement correspond au service pour lequel il a été conçu.
Un agent documentaire ne doit pas être testé uniquement du point de vue de la personne qui l'a construit.
Il doit être testé du point de vue des personnes qui vont l'utiliser, avec des questions réalistes, une documentation réaliste et des attentes réalistes.
Un rédacteur technique expert est particulièrement bien placé pour cela : comprendre les audiences, les contextes d'usage, les difficultés récurrentes et les besoins en information fait déjà partie du métier.
Cela implique d'anticiper la manière dont les utilisateurs sont susceptibles d'interagir avec l'agent, ce qu'une réponse utile et fiable doit contenir, et comment vérifier que l'agent se comporte correctement — y compris lorsqu'il ne doit pas répondre.
Les tests ne constituent pas une simple vérification technique finale. Ils font partie de la conception du service.
Concevoir la réponse avant de tester l'agent
Un agent documentaire ne doit pas répondre de la même manière quel que soit le service qu'il fournit.
Un agent dédié à la qualité documentaire peut avoir besoin de produire des comparaisons, de signaler des problèmes détectés et de formuler des recommandations. Un agent de support peut devoir fournir une réponse directe, un guidage pas à pas et un parcours d'escalade.
Le format et la structure de la réponse doivent donc être définis avant le début des tests, car ils formalisent la façon dont la réponse est censée servir l'utilisateur et fournissent une référence à partir de laquelle l'agent peut être évalué.
Concevoir la réponse à travers son format, autour du service — et non autour du modèle.
Réfléchir à la réponse en amont poursuit deux objectifs : cela aide à anticiper la manière dont les utilisateurs vont interagir avec l'agent et rend la phase de test plus concrète en définissant à quoi doit ressembler une réponse réussie.
La structure crée la confiance
Une réponse fiable doit rendre immédiatement visibles trois éléments : d'où vient l'information, où se situent les incertitudes ou les limites, et ce que l'utilisateur peut faire ensuite en toute confiance.
Les références assurent la traçabilité. Les avertissements rendent l'incertitude visible. Des prochaines étapes claires rendent la réponse exploitable.
Les amorces de conversation font partie de la conception
Les amorces de conversation ne sont pas de simples suggestions d'interface.
Elles font partie du modèle d'usage.
C'est pourquoi elles doivent être conçues tôt, à partir des mêmes cas d'usage réels déjà identifiés lors de la définition du rôle et du prompt de l'agent.
Elles aident les utilisateurs à comprendre à quoi sert l'agent, quel type de questions il peut traiter et comment ces questions peuvent être formulées.
Des amorces typiques peuvent inclure :
- une demande d'explication ;
- une demande d'explication détaillée ou ciblée sur un vaste ensemble documentaire ;
- une question de terminologie.
Leur objectif n'est pas de montrer tout ce que l'agent pourrait théoriquement faire.
Elles fournissent aussi des exemples concrets aux utilisateurs qui ne savent pas immédiatement comment commencer à interagir avec l'agent — un bon moyen de réduire l'effet de « page blanche ».
S'il est difficile de formuler des amorces de conversation réalistes, cela peut indiquer que le rôle, l'audience ou le service attendu de l'agent restent encore trop vagues.
Construire des prompts de test avant publication
Une fois le prompt solide et les amorces de conversation alignées sur les cas d'usage visés, le processus sort du prompt lui-même pour entrer dans une phase de test dédiée avant publication.
Les prompts de test aident le concepteur à vérifier que l'agent se comporte comme prévu.
Plutôt que de tester l'agent à l'aide d'une collection aléatoire de questions, il est utile d'organiser les prompts de test en catégories et niveaux de criticité.
Construire une progression de scénarios de test
Le premier niveau valide les fondamentaux.
Les niveaux suivants testent progressivement des situations plus exigeantes, depuis la gestion d'informations contradictoires ou confidentielles jusqu'au refus de répondre ou à la gestion d'une escalade conformément aux instructions définies dans le prompt.
Tester les limites, pas seulement les cas idéaux
Les cas limites permettent de vérifier si l'agent sait respecter son périmètre, appliquer ses garde-fous, reconnaître des éléments insuffisants et éviter de générer une réponse simplement parce qu'une question a été posée.
D'après mon expérience, structurer les tests de cette manière a été particulièrement utile lors de la conception itérative, notamment en travaillant avec Copilot pour identifier les cas susceptibles de révéler des faiblesses du prompt ou du comportement de l'agent.
L'objectif de cette phase pré-publication est de détecter et corriger autant de problèmes que possible avant que l'agent soit mis à disposition des utilisateurs.
Évaluer les performances de l'agent
Une fois les premiers scénarios de test franchis, l'évaluation permet de rendre cette validation plus systématique et reproductible.
L'objectif est d'évaluer l'agent sur un ensemble de scénarios plus large ou plus ciblé et selon des critères de réussite ou d'échec définis.
Construire des jeux de données d'évaluation autour de critères de réussite et d'échec
Les jeux de données d'évaluation sont proches des prompts de test utilisés pendant la conception, mais ils facilitent une évaluation cohérente de l'agent et la comparaison des résultats dans le temps.
Ils peuvent couvrir un large éventail de questions représentatives ou se concentrer sur des zones précises : questions fréquentes, signaux forts ou faibles d'un comportement attendu, cas difficiles, demandes trompeuses ou scénarios qui doivent conduire à une clarification, une escalade ou un refus.
L'essentiel est de définir ce que signifient réussite et échec pour le service évalué.
Selon l'agent, la réussite peut signifier retrouver la bonne source, produire une synthèse fiable, respecter la terminologie, fournir une procédure exploitable ou refuser correctement une demande non étayée.
Dans Rovo Studio, l'évaluation des agents peut être effectuée à partir de jeux de données CSV contenant des prompts et, éventuellement, les réponses attendues.
Ces jeux de données permettent d'évaluer de manière répétée les agents publiés et d'examiner des métriques telles que le taux de résolution, tout en permettant aussi une revue manuelle des réponses individuelles.
Lorsque le prompt, la surface de connaissances, les skills ou la documentation sous-jacente évoluent, les mêmes jeux de données d'évaluation peuvent être réutilisés pour identifier des régressions ou des améliorations.
Ils constituent ainsi une base de référence réutilisable pour valider l'agent tout au long de son évolution.
Évaluer et itérer tout au long du cycle de vie de l'agent
Une fois l'agent utilisé en conditions réelles, l'évaluation passe d'une performance contrôlée à l'adoption, la pertinence et l'utilité réelles.
Les données d'usage peuvent alimenter les métriques et KPI définis par l'organisation, tandis que les statistiques fournies par la plateforme et les retours directs des utilisateurs montrent comment les personnes interagissent réellement avec le service.
Dans Rovo Studio, par exemple, Insights peut fournir des métriques d'usage telles que le nombre moyen d'utilisateurs quotidiens et le nombre total de conversations. L'analyse des conversations réelles apporte une autre perspective en révélant les questions récurrentes, les cas d'usage inattendus, les difficultés rencontrées ou les zones où l'agent peut encore nécessiter des ajustements.
Ces données quantitatives et ces retours qualitatifs permettent de maintenir la pertinence de l'agent après sa publication.
Alimenter l'amélioration de la documentation
L'utilisation de l'agent peut elle-même produire des informations précieuses sur la base de connaissances sous-jacente.
Les échecs récurrents, les questions difficiles, les demandes non résolues ou les schémas inattendus peuvent révéler une documentation manquante, des métadonnées faibles, une terminologie peu claire, des sources contradictoires ou de nouveaux besoins utilisateurs.
Ils peuvent donc déclencher des améliorations de la documentation elle-même.
Documentation → Utilisation de l'agent → Données d'usage et retours utilisateurs → Améliorations de la documentation → Nouvelle évaluation
Itérer sur l'agent
Les mêmes informations peuvent alimenter une seconde boucle centrée sur l'agent lui-même.
Utilisation de l'agent → Évaluation → Ajustements → Tests → Agent mis à jour
Les ajustements peuvent concerner le prompt, la surface de connaissances, les skills, le format des réponses, les cas d'usage ou d'autres éléments de conception de l'agent.
Cela crée un processus d'amélioration continue dans lequel l'agent évolue parallèlement à la documentation, aux utilisateurs et aux services qu'il prend en charge.
Dans mon propre projet, j'ai pu concevoir, configurer et tester les agents avant publication, mais ma mission s'est terminée avant que je puisse observer leur usage à long terme, recueillir des retours utilisateurs significatifs ou itérer à partir de données réelles d'adoption.
Savoir quand arrêter un agent
Gérer un agent dans le temps signifie aussi être prêt à remettre en question son utilité continue.
Un agent peut devoir évoluer à mesure que la documentation, le produit, les utilisateurs ou les besoins métier changent.
Et si le service pour lequel il a été conçu n'est plus utile, il doit être retiré plutôt que de devenir une couche obsolète supplémentaire dans l'écosystème de connaissances.
Gérer le cycle de vie d'un agent, c'est aussi savoir quand l'arrêter.
Un agent ne doit pas devenir un actif obsolète de plus que personne n'ose supprimer.
Bonus : techniques expérimentales pour favoriser l'adoption
Au-delà des tests et de l'évaluation formels, quelques techniques expérimentales peuvent contribuer à renforcer la confiance et à révéler des faiblesses.
Utiliser des indicateurs de confiance comme repères
Dans certains de mes agents, j'ai expérimenté des indicateurs de confiance ou de fiabilité pour aider les utilisateurs à évaluer avec quel degré de prudence interpréter une réponse.
Ces scores n'étaient pas des métriques scientifiques. Ils étaient conçus comme des signaux : pour accroître la transparence auprès des utilisateurs et mettre en évidence les zones de la documentation susceptibles de nécessiter l'attention des auteurs.
Rendre visibles les règles critiques
Mettre en évidence les comportements obligatoires dans le prompt.
L'utilisation de libellés tels que IMPORTANT ou Critical Rule peut aider à distinguer les comportements obligatoires des consignes générales.
Concevoir l'expérience du « non »
Prévoir comment l'agent doit refuser, demander une clarification ou déclencher une escalade.
Un refus contrôlé, une demande de clarification ou un parcours d'escalade peuvent être plus utiles qu'une réponse plausible mais non étayée.
Utiliser l'agent pour sonder la documentation
Des questions soigneusement choisies peuvent révéler un manque de contexte, des métadonnées faibles, des sources contradictoires ou des problèmes de terminologie dans la base de connaissances sous-jacente.
Découvrez l'approche complète des agents documentaires : Stratégie → Architecture → Tests et évaluation.
© Autrice : Florence Venisse, Experte en documentation technique & IA – Première version datée du 12 septembre 2026