Base de connaissances pour l’IA : préparer des documents qui donnent de bonnes réponses
Votre assistant IA répond avec assurance. Le problème, c’est qu’il cite une ancienne procédure, oublie une exception ou mélange deux offres commerciales. Avant de changer de modèle, regardez les documents qu’il consulte.
Une base de connaissances utile commence par des informations dont l’équipe connaît le périmètre, la validité et le responsable. Voici une méthode pour préparer ce socle, à partir d’un usage précis : aider une PME à répondre aux demandes de ses clients.
Partir des questions que votre équipe reçoit vraiment
Prenons un exemple fictif. Une entreprise de maintenance souhaite aider son équipe support à retrouver les conditions d’intervention. Elle possède des contrats, des fiches d’offres et plusieurs versions de ses procédures.
Son premier réflexe pourrait être de tout importer. Nous proposons de commencer par les questions qui reviennent au quotidien : une intervention le samedi est-elle incluse ? Qui valide un déplacement supplémentaire ? Quelles informations faut-il recueillir avant de planifier un technicien ?
Pour chacune, faites identifier la réponse et sa source par une personne du métier. Si personne ne sait quel document fait foi, inscrivez ce point parmi les décisions à prendre avant le test.
Cette liste définit le périmètre du premier assistant. Elle aide aussi à choisir les documents réellement nécessaires. Pour prioriser plusieurs usages possibles, vous pouvez reprendre la démarche de notre guide de l’audit IA en entreprise.
Choisir une version de référence pour chaque règle
Dans notre exemple, une brochure mentionne une assistance le samedi, tandis qu’une ancienne fiche réserve cette possibilité à une autre offre. Les deux documents semblent crédibles. Le support doit d’abord établir quelle règle s’applique à quel contrat.
Nous proposons un inventaire simple pour chaque source retenue : son titre, son emplacement, les offres concernées, sa date d’effet, son responsable et son statut. Le statut distingue notamment le contenu validé, le brouillon et l’archive.
Une ancienne version peut rester nécessaire pour répondre sur un contrat historique. Dans ce cas, son périmètre doit être explicite. Pour les questions sur l’offre actuelle, configurez la recherche afin qu’elle sélectionne les documents applicables.
Ces informations descriptives constituent les métadonnées. Microsoft explique qu’elles permettent d’enrichir les passages documentaires et de prendre en charge des recherches au-delà de la seule proximité de sens. Référence : enrichissement des contenus RAG, Microsoft Learn.
Rendre chaque procédure compréhensible isolément
Un assistant fondé sur le RAG recherche des passages dans des sources externes, puis les fournit au modèle pour préparer sa réponse. Il faut donc vérifier que les extraits conservés contiennent assez de contexte. Des passages trop courts peuvent perdre une condition essentielle ; des passages trop longs peuvent introduire des informations inutiles. Le découpage se teste selon les documents et les questions visées. Référence : découpage documentaire, Microsoft Learn.
Pour la rédaction, privilégiez des titres explicites, définissez les sigles internes et précisez les situations auxquelles chaque règle s’applique. Ces pratiques figurent dans les recommandations documentaires d’AWS pour les applications RAG. Référence : préparer les documents pour le RAG, AWS.
Voici un exemple fictif de réécriture.
Formulation initiale : « Pour les clients Premium, appliquer la procédure habituelle. Hors horaires, voir avec le responsable. »
Formulation clarifiée : « Cette procédure concerne les contrats Premium souscrits à partir du 1er septembre 2026. Les interventions incluses ont lieu du lundi au vendredi, de 9 h à 18 h. Pour une demande le samedi, le support sollicite la validation du responsable d’exploitation avant de confirmer un créneau. »
La seconde version indique le contrat concerné, la règle et l’action attendue. Le responsable métier doit évidemment valider ces précisions : une réécriture assistée par IA ne doit pas inventer les informations manquantes.
Vérifiez également le contenu obtenu après import. Un tableau de prestations reste-t-il associé aux bons noms d’offres ? Une réserve placée sous un tarif a-t-elle été conservée ? Comparez quelques extraits avec les originaux avant de tester les réponses.
Appliquer les droits d’accès avant de transmettre les documents au modèle
Un assistant interne et un chatbot public n’ont pas besoin des mêmes sources. Dans notre entreprise fictive, le premier peut consulter une procédure d’escalade ; le second doit s’appuyer sur les informations destinées aux clients.
Le contrôle appartient à l’application. Elle doit identifier l’utilisateur, vérifier ses autorisations et limiter les contenus transmis au modèle. Une instruction telle que « ne révèle pas les documents confidentiels » ne remplace pas ce contrôle. AWS décrit cette séparation entre autorisation et génération dans son guide consacré aux accès aux données des applications d’IA générative. Référence : autorisations et filtrage des données RAG, AWS.
Pour le pilote, testez une même question avec plusieurs profils. Vérifiez les extraits récupérés, les citations et la réponse finale. Ajoutez un cas où un accès vient d’être retiré : c’est une situation concrète que le système devra gérer.
Tester la recherche et la réponse séparément
Une réponse incorrecte peut avoir plusieurs causes : le bon document est absent, la recherche récupère une mauvaise version, ou le modèle interprète mal un passage pourtant pertinent. Examiner séparément la recherche et la réponse permet de mieux localiser le problème. Microsoft distingue notamment l’évaluation de la récupération documentaire, la fidélité au contexte et la pertinence de la réponse. Référence : évaluer un système RAG, Microsoft Learn.
Reprenez les questions collectées au départ. Nous suggérons d’y ajouter ces situations :
Question précise : « Mon contrat Premium de septembre inclut-il une intervention le samedi ? »
Question incomplète : « Vous pouvez intervenir ce week-end ? » La réponse doit demander les précisions nécessaires.
Information absente : « Quel technicien viendra ? » L’assistant doit signaler que la documentation ne permet pas de répondre.
Contrat historique : la réponse doit utiliser les conditions applicables à sa période.
Accès limité : un utilisateur externe ne doit pas obtenir une procédure réservée au support.
Pour chaque cas, notez la source attendue, le comportement attendu et le résultat observé. Vérifiez aussi que la citation soutient réellement la réponse : un lien vers le bon fichier ne suffit pas si le passage cité ne justifie pas l’affirmation.
Conservez quelques questions inédites pour la validation finale. Vous pourrez ainsi vérifier les améliorations sur des cas qui n’ont pas servi aux réglages. Fixez vos critères de réussite selon l’usage et les conséquences d’une erreur.
Organiser les mises à jour dès le pilote
Dans notre exemple, une nouvelle offre commerciale modifiera peut-être les conditions d’intervention. Prévoyez dès maintenant qui validera la fiche, comment la version précédente sera traitée et comment vérifier que l’assistant consulte la nouvelle.
Nous proposons un circuit court : validation métier, mise à jour de la source, actualisation de l’index de recherche, puis reprise des questions concernées. Une personne doit suivre ce circuit jusqu’à la vérification du résultat.
Les questions restées sans réponse alimentent ensuite le travail documentaire. Certaines révèlent une règle manquante ; d’autres montrent que la demande dépasse le périmètre prévu. Décidez avec l’équipe lesquelles méritent une nouvelle fiche.
Pour démarrer, réunissez le support autour d’un seul sujet, comme les conditions d’intervention. Identifiez les sources qui font foi, clarifiez les ambiguïtés et testez les réponses sur ce périmètre. Vous disposerez d’une base concrète pour décider de la suite.
Vous préparez un assistant pour vos équipes ou vos clients ? Présentez votre projet à Studio UNIQ pour cadrer les sources utiles et les critères de réussite du premier pilote.

