Il est facile de produire une démonstration impressionnante : déposer quelques PDF, poser une question et obtenir une réponse bien rédigée. Le vrai test commence lorsque cette réponse sert à préparer un dossier juridique, qualifier un appel d’offres ou retrouver une obligation contractuelle.
Dans ces situations, « la réponse semble plausible » n’est pas un critère suffisant. Il faut pouvoir retrouver la source, comprendre pourquoi elle a été sélectionnée et savoir ce que le système n’a pas trouvé.
Un RAG utile en entreprise est un produit de recherche et de preuve. Le modèle de langage n’en est qu’un composant.
1. Donner une identité stable à chaque document
Un fichier, son texte OCR, ses pages, ses fragments d’indexation et ses résumés sont des représentations différentes du même document. Le système doit conserver leur filiation.
Pour chaque source, je recommande au minimum :
- un identifiant stable, indépendant du nom du fichier ;
- la version, la date et le statut du document ;
- les droits d’accès et le périmètre métier ;
- le lien entre chaque fragment, la page et la zone d’origine ;
- l’empreinte du fichier pour détecter les doublons et les modifications.
Sans cette base, une réindexation peut casser les citations, une ancienne version peut apparaître comme actuelle et deux copies d’un même document peuvent artificiellement renforcer une réponse.
2. Traiter la mise en page comme une donnée
Extraire du texte ne suffit pas. Un tableau, une note de bas de page, un en-tête répété ou une colonne peuvent changer le sens. L’OCR ajoute ses propres erreurs : chiffres confondus, mots fusionnés et ordre de lecture incorrect.
Le pipeline doit donc séparer l’original, le rendu visuel, le texte brut et la structure reconstruite. Pour les documents importants, il est utile de conserver les coordonnées de chaque bloc. L’interface peut alors ouvrir directement la page et mettre en évidence l’extrait utilisé.
Cette étape paraît moins spectaculaire que le choix d’un modèle. Elle détermine pourtant la qualité maximale que le reste du système pourra atteindre.
3. Construire des fragments autour du sens et de la preuve
Découper tous les textes tous les 500 caractères est simple, mais rarement satisfaisant. Un bon fragment doit être assez petit pour être ciblé et assez complet pour rester compréhensible.
La stratégie dépend du corpus : paragraphes pour une doctrine, articles pour un texte juridique, clauses pour un contrat, cellules enrichies de leurs en-têtes pour un tableau. Un chevauchement peut préserver le contexte, mais il augmente les doublons dans les résultats.
Chaque fragment doit transporter ses métadonnées : titre, section, page, date, type, entité concernée et niveau d’accès. Elles serviront à filtrer la recherche et à produire une citation exploitable.
4. Combiner plusieurs modes de recherche
La recherche sémantique est forte pour retrouver une idée exprimée avec d’autres mots. Elle est moins fiable pour un numéro de dossier, une référence exacte, un nom rare ou une date. La recherche lexicale a le profil inverse.
Une architecture robuste combine généralement :
- des filtres structurés pour réduire le corpus autorisé ;
- une recherche lexicale pour les termes et références exacts ;
- une recherche vectorielle pour le sens ;
- un reclassement des candidats selon la question complète ;
- une règle de diversité pour éviter cinq fragments voisins du même passage.
Le poids de chaque signal doit pouvoir être observé. Sinon, lorsqu’une source pertinente disparaît, personne ne peut expliquer où elle a été perdue.
5. Faire de la citation un contrat produit
Une citation n’est pas un lien ajouté après la génération. La réponse doit être construite à partir d’unités de preuve identifiées avant l’appel au modèle.
Un contrat simple peut imposer que chaque affirmation factuelle contienne l’identifiant d’une source autorisée. Le serveur vérifie ensuite ces identifiants, reconstruit les liens et refuse ceux qui ne faisaient pas partie du contexte. L’interface affiche le titre, la version, la page et l’extrait exact.
La bonne interaction n’est pas seulement « ouvrir le PDF ». L’utilisateur doit pouvoir passer de l’affirmation à la zone précise qui la soutient, puis revenir à la réponse sans perdre son travail.
6. Prévoir l’absence de réponse
Un système professionnel doit savoir dire : « Je n’ai pas de source suffisante. » Cela nécessite une règle de sortie explicite, pas une simple instruction dans le prompt.
On peut combiner plusieurs signaux : score de récupération trop faible, sources contradictoires, information ancienne, corpus incomplet ou question hors périmètre. Le produit peut alors demander une précision, proposer les documents les plus proches ou transférer le cas à une personne.
L’incertitude doit produire une action utile. Un badge « confiance moyenne » sans conséquence n’aide personne.
7. Évaluer avec de vraies questions métier
Tester dix questions inventées par l’équipe technique mesure surtout sa connaissance du système. Il faut constituer un jeu d’évaluation à partir des recherches réelles : questions fréquentes, formulations ambiguës, références exactes, cas sans réponse et documents contradictoires.
Pour chaque question, conservez :
- les sources attendues ;
- les éléments que la réponse doit contenir ;
- les affirmations interdites faute de preuve ;
- la décision attendue en cas d’information insuffisante.
Il faut évaluer séparément la récupération et la génération. Si le bon passage n’entre jamais dans le contexte, changer de prompt ne résoudra pas le problème. Si le passage est présent mais mal utilisé, le travail porte sur l’instruction, le modèle ou la construction de la réponse.
8. Exploiter le système comme un produit vivant
En production, le corpus change. Des documents expirent, les droits évoluent et les utilisateurs découvrent de nouvelles formulations. Il faut suivre les questions sans résultat, les sources ouvertes, les corrections humaines, les temps de réponse et le coût par parcours.
La sécurité doit s’appliquer avant la récupération : un modèle ne doit jamais recevoir un extrait auquel l’utilisateur n’a pas accès. Les journaux doivent permettre l’analyse sans recopier inutilement des contenus sensibles.
Enfin, chaque changement de modèle, d’OCR, de découpage ou de classement doit être rejoué sur le jeu d’évaluation. Sans cette discipline, une amélioration visible sur trois exemples peut dégrader silencieusement vingt usages réels.
Une première version crédible
Le premier périmètre n’a pas besoin de couvrir toute l’entreprise. Un corpus clairement propriétaire, vingt à cinquante questions d’évaluation, une recherche hybride, des citations au niveau de la page et une boucle de retour utilisateur constituent déjà un produit sérieux.
C’est l’approche appliquée chez AI7 aux systèmes documentaires comme LegalAZ : partir du parcours de recherche, rendre la preuve navigable et mesurer séparément ce que le système retrouve et ce qu’il rédige. Le résultat n’est pas un chatbot universel. C’est un outil de travail délimité, contrôlable et améliorable.