Recherche dans les connaissances d’entreprise : ce qui la rend fiable

01Le piège de la démonstration

La plupart des assistants documentaires suivent le même schéma, appelé génération augmentée par la recherche (ouvre un site externe) (RAG) : retrouver les passages qui correspondent à une question, puis demander à un modèle de langage de rédiger une réponse fondée sur ces passages. Sur un dossier soigneusement choisi de cinquante documents, le résultat convainc en une semaine.

En production, le décor change. Vingt ans de partages réseau, de wikis, de tickets, de contrats et de procédures, souvent en double, obsolètes ou confidentiels. Dans ce contexte, l’assistant échoue de deux façons. Il donne une mauvaise réponse, et plus personne ne l’utilise. Ou, pire, il donne une mauvaise réponse avec aplomb, et quelqu’un agit en conséquence.

Une recherche fiable dans les connaissances internes dépend donc moins du modèle que de cinq propriétés du système qui l’entoure. Chacune peut être conçue et, surtout, testée.

02Droits d’accès : ne retrouver que ce que l’utilisateur peut lire

La règle est simple : l’assistant ne doit jamais montrer à quelqu’un un passage qu’il ne pourrait pas ouvrir dans le système source. Tout se joue sur le point d’application. Si un passage parvient au modèle, partez du principe qu’il peut apparaître dans la réponse. Les droits doivent donc être appliqués avant la génération, au moment de la recherche, pour l’utilisateur qui pose la question.

L’OWASP classe à la fois la divulgation d’informations sensibles (ouvre un site externe) et les faiblesses des vecteurs et des embeddings (ouvre un site externe), y compris les fuites entre périmètres d’habilitation, parmi les principaux risques des applications de modèles de langage. Concrètement, cela se traduit par quatre exigences.

• Stockez les droits d’accès de chaque document source avec chacun de ses fragments dans l’index, repris du système source plutôt que redéfinis à la main.
• Filtrez sur ces droits au moment de la requête, à partir de l’identité de l’utilisateur connecté, avant le classement et la génération.
• Synchronisez les changements de droits au moins aussi vite que les changements de contenu, et convenez du délai dans lequel un droit retiré doit prendre effet.
• Testez avec de vrais rôles. « Un stagiaire peut-il retrouver les grilles salariales ? » a sa place dans la batterie de tests, pas dans l’analyse post-incident.

03Traçabilité : des citations vérifiables

Chaque affirmation d’une réponse doit renvoyer au passage dont elle provient : titre du document, version ou date, responsable, et un lien qui s’ouvre au bon endroit. Affichez le passage lui-même, pas seulement le nom du document, pour que le lecteur voie en quelques secondes si la citation étaye bien la phrase.

Concevez le format de réponse de sorte que le texte non étayé saute aux yeux. Si aucun passage retrouvé ne soutient une phrase, le système doit l’omettre ou la signaler. Vérifiez-le ensuite automatiquement : comparez chaque passage cité avec l’affirmation qu’il est censé soutenir, et soumettez un échantillon des résultats à une relecture humaine. Des citations présentes mais qui ne prouvent rien sont une défaillance fréquente et silencieuse.

04Fraîcheur et source de référence

Les connaissances d’une organisation ont des versions. L’ancienne et la nouvelle politique de déplacements répondent toutes deux à la question « puis-je voyager en classe affaires ? », et elles ne donnent pas la même réponse. Indexez les métadonnées qui les distinguent : date d’effet, statut (brouillon, approuvé, remplacé) et responsable. Classez d’abord les documents en vigueur et approuvés, excluez les versions remplacées sauf si l’utilisateur demande l’historique, et affichez la date dans chaque citation.

Décidez, sujet par sujet, quelle source fait foi. La politique RH vient du portail RH, pas d’un e-mail qui en cite la version de l’an dernier. Fixez un rythme de réindexation par source, du quasi temps réel pour les données de dossiers au quotidien pour un wiki, et surveillez-le : un index périmé produit des réponses qui ont l’air justes et ne le sont pas.

05Lacunes assumées : « je n’ai pas trouvé »

Souvent, la réponse la plus utile consiste à reconnaître une lacune. Les modèles de langage peuvent produire des affirmations fluides que rien ne soutient, ce que le NIST appelle confabulation (ouvre un site externe) dans son profil consacré à l’IA générative. L’ancrage dans les passages retrouvés réduit ce phénomène ; il ne le supprime pas. L’OWASP traite la conséquence en aval, des personnes qui agissent sur la base d’informations fausses, comme un risque à part entière sous l’intitulé désinformation (ouvre un site externe) (misinformation).

Fixez un seuil de pertinence en dessous duquel le système indique qu’il n’a trouvé aucune source fiable, et suggère à qui s’adresser. Pour les questions portant sur des règles, des droits ou des obligations, ne laissez pas le modèle combler les vides avec des connaissances générales. Suivez ensuite le taux de non-réponse par sujet. Les premiers mois, cette liste est souvent le résultat le plus précieux du projet : elle montre aux responsables de contenu exactement où la documentation fait défaut.

06L’architecture derrière les cinq propriétés

Rien de tout cela n’exige une pile technique exotique. Il faut en revanche que les droits d’accès, les métadonnées et les contrôles soient des éléments à part entière de la chaîne de traitement, et non des fonctions ajoutées après la démonstration.

Les données personnelles méritent une attention explicite. Indexer des documents reste un traitement des données personnelles qu’ils contiennent : les principes de limitation des finalités et de minimisation des données (ouvre un site externe) du RGPD (article 5) s’appliquent. Écartez les sources dont le cas d’usage n’a pas besoin, assurez-vous que les suppressions dans un système source se répercutent dans l’index, et incluez l’index lorsque vous répondez à une demande d’accès.

07Une qualité mesurée, avant et après la mise en production

On ne juge pas de la fiabilité en essayant quelques questions en réunion. Convenez de critères de qualité avec les responsables des contenus et mesurez chaque couche séparément, pour savoir où corriger un problème.

Construisez le jeu de test à partir de vraies questions : journaux de recherche, tickets du support, questions des nouveaux collaborateurs. Quelques centaines de questions, avec des réponses validées par les responsables de contenu, constituent un point de départ réaliste. Rejouez l’ensemble à chaque changement, qu’il s’agisse d’un nouveau modèle, d’une nouvelle stratégie de découpage ou d’une nouvelle source. La qualité dérive sans bruit quand les contenus évoluent, et seul un jeu de test stable rend cette dérive visible.

08La fiabilité, vue par l’utilisateur

Pour ceux qui l’utilisent, tout cela se résume à quelques comportements observables. L’assistant ne répond qu’à partir de documents qu’ils ont le droit de lire. Chaque affirmation s’accompagne d’une citation qu’ils peuvent ouvrir. Ils voient l’ancienneté d’une source. On leur dit clairement quand il n’existe pas de réponse fiable. Et ils savent que quelqu’un mesure la qualité, puisqu’ils peuvent signaler une réponse erronée et la voir corrigée.

Les résultats d’une IA peuvent rester faux, et certaines questions méritent une personne plutôt qu’une recherche. Le prévoir ouvertement n’est pas une faiblesse du système. C’est ce qui donne envie de s’y fier pour tout le reste.