Un pilote RAG connecté à Alfresco peut réussir une démonstration sans être prêt pour la production. Le cadrage vérifie que le cas d’usage, le corpus et la gouvernance sont pertinents ; la recette vérifie, sur des cas reproductibles, que les réponses sont fiables, traçables et conformes aux droits d’accès.
Pour décider objectivement du passage en production, il faut donc un jeu d’évaluation stable : des questions métier représentatives, des documents de référence identifiés, des profils d’accès réalistes et des seuils fixés avant les tests. Cette méthode complète notre cadre de déploiement d’un RAG sur Alfresco en se concentrant sur la recette.
Pourquoi une démonstration réussie ne suffit pas
Une démonstration utilise souvent un corpus propre et quelques questions connues à l’avance. Elle prouve que la chaîne technique fonctionne, mais pas qu’elle résistera aux usages réels. En production, les utilisateurs posent des questions incomplètes, emploient leur vocabulaire métier et attendent parfois une information qui n’existe pas dans leur périmètre autorisé.
Le risque est double : le système peut citer un document pertinent tout en formulant une conclusion incorrecte, ou produire une réponse plausible sans source suffisante. Dans les deux cas, la fluidité de la réponse masque le défaut de fiabilité.
Un jeu d’évaluation apporte un référentiel commun au métier, à l’équipe Alfresco et aux responsables du projet RAG. Il permet de rejouer les mêmes tests après une modification du corpus, du découpage des documents, du moteur de recherche ou du modèle de génération.
Définir un périmètre documentaire testable
Le premier jeu d’évaluation doit rester borné. Choisissez un domaine documentaire homogène : procédures qualité, documentation support, dossiers techniques ou référentiel de contrats, par exemple. Pour chaque document inclus, vérifiez au minimum :
- son statut et sa version dans Alfresco ;
- ses métadonnées utiles à la recherche ;
- son propriétaire métier ;
- sa date de validité ;
- ses règles d’accès ;
- la présence éventuelle de doublons ou de versions obsolètes.
Une réponse erronée peut venir du RAG, mais aussi d’un corpus contradictoire. L’évaluation doit permettre de séparer ces causes. Si deux procédures actives donnent des consignes différentes, corriger uniquement le moteur ne résoudra pas le problème documentaire.
Construire des questions à partir des usages réels
Un bon jeu de test ne se résume pas à une liste de mots-clés. Il reprend les formulations réellement utilisées par les équipes et couvre plusieurs niveaux de difficulté.
Commencez par réunir 30 à 50 questions issues de tickets support, de demandes adressées aux référents, de recherches fréquentes ou d’entretiens avec les utilisateurs. Classez-les ensuite en quatre familles :
- Questions factuelles simples, dont la réponse se trouve dans un passage unique.
- Questions de synthèse, qui exigent de rapprocher plusieurs passages ou documents.
- Questions ambiguës, qui nécessitent une demande de précision.
- Questions hors périmètre, auxquelles le système doit refuser de répondre ou déclarer qu’il ne dispose pas d’une source suffisante.
Pour chaque question, consignez la réponse attendue, le ou les documents de référence, leur version et les profils autorisés à les consulter. Cette « vérité terrain » doit être validée par un responsable métier, pas uniquement par l’équipe technique.
Gabarit d’un cas de test
| Champ | Contenu à consigner |
|---|---|
| Question et famille | Formulation réelle ; factuelle, synthèse, ambiguë ou hors périmètre |
| Vérité terrain | Réponse attendue validée par le métier |
| Sources attendues | Documents Alfresco, versions et passages de référence |
| Profil testé | Utilisateur, groupe et droits applicables |
| Résultat observé | Passages retrouvés, réponse, citations et temps de traitement |
| Verdict | Réussi, partiel ou échoué, avec cause et action corrective |
Mesurer séparément la recherche et la réponse
Une réponse RAG dépend de deux étapes. La recherche doit d’abord retrouver les bons passages dans Alfresco. Le modèle doit ensuite produire une réponse fidèle à ces passages. Les évaluer séparément accélère le diagnostic.
Pour la recherche, vérifiez notamment :
- si la bonne source apparaît parmi les premiers résultats ;
- si la version active est privilégiée ;
- si les métadonnées améliorent réellement la sélection ;
- si un document non autorisé reste exclu ;
- si le passage remonté contient assez de contexte pour répondre.
Pour la génération, contrôlez :
- la conformité de la réponse aux sources retrouvées ;
- la présence de citations consultables ;
- l’absence d’informations ajoutées sans preuve ;
- la clarté des réserves lorsque les sources sont incomplètes ;
- la capacité à s’abstenir quand aucune réponse fiable n’est disponible.
Cette séparation évite un faux diagnostic fréquent : changer de modèle alors que le document pertinent n’a jamais été retrouvé, ou retravailler l’indexation alors que la réponse déforme une source correcte.
Tester les droits Alfresco comme une exigence fonctionnelle
Les permissions ne doivent pas être ajoutées à la fin du pilote. Elles font partie du jeu d’évaluation. Créez plusieurs profils représentatifs : collaborateur, manager, référent métier, prestataire ou administrateur, selon votre organisation.
Rejouez les mêmes questions avec ces profils et vérifiez trois points :
- un utilisateur autorisé obtient bien les sources nécessaires ;
- un utilisateur non autorisé ne reçoit ni contenu, ni extrait, ni indice révélant l’existence d’un document sensible ;
- les citations ouvrent uniquement des documents accessibles dans Alfresco.
Le test doit porter sur toute la chaîne : extraction, indexation, recherche, génération et lien final. Un filtre appliqué uniquement dans l’interface ne suffit pas si le moteur intermédiaire a déjà exposé le contenu.
Définir les seuils avant de regarder les résultats
Les critères de passage en production doivent être fixés avant la recette. Sinon, l’équipe risque d’adapter son jugement aux réponses obtenues. Le tableau ci-dessous constitue un support de décision à compléter selon le niveau de risque métier.
| Indicateur | Seuil cible | Résultat | Décision |
|---|---|---|---|
| Source attendue dans les premiers résultats | À fixer avant la recette | À mesurer | Go / corriger |
| Réponses entièrement étayées | À fixer selon le risque | À mesurer | Go / corriger |
| Citations correctes et accessibles | À fixer avant la recette | À mesurer | Go / corriger |
| Abstention appropriée hors périmètre | À fixer avant la recette | À mesurer | Go / corriger |
| Incident de droits | 0 | À mesurer | Bloquant si supérieur à 0 |
| Temps gagné par rapport à la recherche habituelle | À fixer avec les utilisateurs | À mesurer | Go / ajuster |
Les seuils dépendent du risque métier. Un assistant destiné à orienter vers des procédures peut tolérer une reformulation imparfaite si la source est claire. Un usage lié à la conformité, à la sécurité ou à une décision contractuelle exige un niveau de contrôle plus élevé et, souvent, une validation humaine systématique.
Organiser la recette et traiter les échecs
Chaque résultat doit conserver la question, le profil utilisateur, les passages retrouvés, la réponse générée, les citations et le verdict du relecteur. Ajoutez une catégorie de cause pour chaque échec : document absent, version obsolète, métadonnée insuffisante, découpage inadapté, problème de droits, recherche imprécise ou génération non fidèle.
Cette classification transforme la recette en plan d’amélioration. Après chaque changement, rejouez l’ensemble du jeu de référence, pas seulement les questions précédemment en échec. Une amélioration locale peut dégrader d’autres cas.
Le jeu doit aussi évoluer avec le corpus. Lorsqu’une nouvelle procédure importante est publiée ou qu’un type de question apparaît dans les usages, ajoutez un cas de test. Conservez cependant un noyau stable pour comparer les versions du dispositif dans le temps.
Fonder la décision de production sur des preuves
Un RAG Alfresco est prêt à avancer lorsque ses limites sont aussi lisibles que ses réussites. L’objectif n’est pas d’obtenir une réponse à tout prix, mais de fournir une information utile à partir de documents autorisés, actuels et vérifiables.
Avant le passage en production, le décideur doit pouvoir répondre clairement à quatre questions :
- Sur quels corpus et pour quels utilisateurs le service est-il suffisamment fiable ?
- Dans quels cas doit-il s’abstenir ou demander une précision ?
- Comment les droits et les versions Alfresco sont-ils respectés de bout en bout ?
- Qui analyse les échecs et maintient le jeu d’évaluation après le pilote ?
Cette discipline réduit l’écart entre une preuve de concept séduisante et un service documentaire durable. Elle donne aussi à Rainbow Integration et aux équipes clientes une base concrète pour prioriser les améliorations, au lieu de piloter le projet sur des impressions.
Vous préparez un pilote RAG connecté à Alfresco ?
Rainbow Integration peut vous aider à cadrer le corpus, les profils d’accès, le jeu de questions et les critères de recette avant d’engager une mise en production.
Échanger sur votre pilote RAG Alfresco
Besoin d'un accompagnement pour votre projet GED ?
Réservez un diagnostic gratuit de 30 minutes avec notre expert Alfresco
Réserver mon diagnostic