Avant de lancer un RAG documentaire en entreprise, il faut préparer quatre choses : un inventaire des documents qui font foi (et de ceux qu'on écarte), une conversion de ces documents en texte propre et versionné, une règle de découpage assortie de métadonnées, et une matrice de droits d'accès qui reproduit celle du système d'origine. Sans ces quatre livrables, l'assistant répond à côté, cite une procédure périmée ou montre un contrat à quelqu'un qui n'y a pas droit. Chaque étape renvoie vers l'article qui la détaille.
Sur les missions RAG qu'on livre, la préparation de la base prend souvent plus de temps que le développement lui-même, et bien plus que le choix du modèle.
Que faut-il préparer avant de lancer un RAG documentaire en entreprise ?
Il faut préparer un corpus, pas un dossier partagé. Un corpus, c'est un ensemble de documents dont on sait pour chacun qui en est propriétaire, quelle version fait foi, qui a le droit de le lire et à quelle date il devient obsolète. Le dossier partagé ne répond à aucune de ces questions : il contient trois versions du même mode opératoire, des brouillons et des scans jamais relus.
Résumé de la vidéo : Google Cloud Tech explique en anglais, en quelques minutes, comment un RAG va chercher les passages utiles dans les documents de l'entreprise avant de faire répondre le modèle, et pourquoi la qualité de la base préparée décide de celle des réponses. C'est le mécanisme que les six étapes ci-dessous préparent.
Le RAG (retrieval-augmented generation) fonctionne en deux temps : une recherche qui remonte les passages les plus proches de la question, puis un modèle de langage qui rédige une réponse à partir de ces passages. Si la recherche remonte un passage périmé, le modèle le reformule avec aplomb. La préparation vise un seul objectif : des passages justes, à jour et autorisés. Une question à trancher avant : le RAG est-il le bon outil ? Quand la donnée est tabulaire (tarifs, stocks, commandes), une requête SQL ou une connexion directe à l'outil métier fait mieux, on l'explique dans MCP ou RAG, lequel choisir.
Inventorier, trier et convertir : ce qui entre dans la base
La règle qui marche : on ne commence pas par tout indexer, on commence par les 200 à 500 documents que les équipes ouvrent réellement. Le journal d'accès de la GED donne cette liste en une heure. C'est ce noyau qu'on indexe d'abord.
Pour chaque document retenu, l'inventaire note cinq champs : propriétaire métier, date de dernière validation, statut (en vigueur, remplacé, brouillon), population autorisée, format source. Un tableur suffit. On écarte les brouillons, les courriels exportés, les présentations sans date et tout document sans propriétaire : personne ne pourra dire si son contenu est encore vrai. Quels documents donner à un RAG détaille les familles à privilégier.
Côté formats, le RAG ne lit que du texte. Les fichiers Word, Markdown, HTML et les PDF natifs passent sans traitement. Les PDF scannés, les images et les plans exigent une reconnaissance de caractères, avec relecture sur un échantillon : un OCR à 95 % de précision sur une notice de sécurité, c'est une ligne fausse sur vingt. Les tableurs sont un cas à part : les tableaux perdent leur structure à l'extraction, mieux vaut les convertir en Markdown avec leurs en-têtes, ou les laisser hors du RAG et les interroger directement en langage naturel sur une base SQL. Les plans techniques demandent un pipeline dédié, décrit dans notre retour sur l'indexation de plans techniques dans un RAG industriel.
Nettoyer les doublons et fixer les versions
Le nettoyage consiste à garantir qu'une question n'a qu'une seule réponse dans la base. Le guide RAG de la Direction générale des Entreprises (novembre 2024) place en tête des prérequis la suppression des doublons, la correction des erreurs et la mise en cohérence du corpus. En pratique, trois opérations couvrent l'essentiel.
- Dédoublonner par contenu, pas par nom de fichier. Deux PDF nommés différemment avec 95 % de texte commun sont un même document ; on garde la version validée la plus récente.
- Retirer le bruit d'extraction : en-têtes et pieds de page répétés, numéros de page, mentions légales dupliquées sur chaque page, tables des matières.
- Fixer une règle de version : un document remplacé sort de l'index le jour où son successeur y entre. Sinon le RAG cite l'ancien tarif avec la même assurance que le bon.
Cette règle tient sur une page : qui valide un ajout, qui retire un document, à quelle fréquence on repasse sur les fichiers de plus de douze mois. Le nettoyage est un rythme, pas une opération unique.
Découper (chunking) et enrichir avec des métadonnées
Le découpage transforme chaque document en passages de quelques centaines de tokens, parce que la recherche compare la question à des passages, pas à des documents entiers. La documentation OpenAI fixe par défaut des passages de 800 tokens avec un chevauchement de 400, réglables entre 100 et 4 096 tokens. Bon point de départ pour des procédures ; pour des contrats ou des clauses courtes, on descend vers 300 à 500 tokens.
Faut-il découper « sémantiquement », en suivant les titres et paragraphes, plutôt qu'à taille fixe ? Une étude publiée sur arXiv en octobre 2024, Is Semantic Chunking Worth the Computational Cost?, conclut que le gain du découpage sémantique n'est pas constant et ne justifie pas toujours son coût de calcul face à un découpage à taille fixe. Notre lecture : découpez sur les titres quand le document en a de propres, à taille fixe sinon, et ne réglez pas ce paramètre pendant des jours avant d'avoir mesuré.
Le levier qui pèse le plus lourd est ailleurs : le contexte ajouté à chaque passage. Dans sa méthode de contextual retrieval (septembre 2024), Anthropic ajoute devant chaque passage 50 à 100 tokens qui rappellent de quel document et de quelle section il provient. Résultat mesuré : le taux d'échec de récupération baisse de 35 % avec les embeddings seuls, de 49 % en combinant avec une recherche lexicale BM25, et de 67 % avec un reclassement. Un passage qui dit « le délai est de 30 jours » devient « Contrat cadre fournisseur X, article 12 : le délai est de 30 jours ». S'y ajoutent les métadonnées structurées (type, service, date de validation, confidentialité) qui filtrent la recherche avant de comparer les textes.
Droits d'accès et confidentialité : qui peut lire quoi ?
Le RAG doit hériter des droits du système source, document par document, et les vérifier au moment de chaque requête. Un assistant qui a tout lu et répond à tout le monde est une fuite de données organisée : demandez-lui le salaire du directeur commercial pour tester la faille. Le filtrage se fait sur les métadonnées, avant la recherche.
Trois points à régler avant la mise en ligne. D'abord, les documents contenant des données personnelles (dossiers RH, réclamations clients nominatives) relèvent du RGPD : les fiches pratiques IA de la CNIL, mises à jour en juillet 2025, imposent de définir la finalité, la base légale et la minimisation des données avant tout traitement ; le plus simple est souvent de laisser ces documents hors du corpus. Ensuite, l'hébergement : la DGE recommande que seules des données chiffrées quittent l'enceinte de l'entreprise ; pour une base qui contient du savoir-faire industriel ou des contrats, on héberge en France ou en Europe et on refuse que les documents servent à entraîner un modèle tiers. Enfin, la journalisation : chaque réponse doit pouvoir être reliée aux passages qui l'ont produite et à l'utilisateur qui a posé la question. Le détail des menaces propres aux bases documentaires (injection par document, exfiltration via les réponses) est traité dans sécuriser une base documentaire RAG.
Comment évaluer la base avant la mise en ligne ?
On évalue avec un jeu de 50 à 100 questions réelles, avec leur réponse attendue et le document qui la contient, écrit par les métiers avant que le RAG existe. Ce jeu sert de contrat : le système est prêt quand il remonte le bon passage dans les cinq premiers résultats sur plus de 90 % des questions, et quand les réponses fausses sont identifiées et expliquées. Sans ce jeu, la recette se fait au ressenti en démonstration et les erreurs apparaissent trois semaines après la mise en production.
Deux mesures suffisent au départ : le rappel de la recherche (le bon passage est-il remonté ?) et la fidélité de la réponse (le modèle dit-il ce que le passage dit, sans ajouter ?). Les indicateurs plus fins sont détaillés dans les métriques d'évaluation d'un RAG. On relance le même jeu à chaque ajout massif de documents et à chaque changement de découpage.
Les erreurs fréquentes, et le plan de travail étape par étape
Quatre erreurs reviennent dans presque tous les projets qu'on reprend. Indexer tout le serveur de fichiers le premier jour : personne ne sait plus ce qui fait foi. Ignorer les scans : le RAG répond « je ne trouve pas » sur les notices les plus anciennes, celles que personne ne connaît par cœur. Ne nommer aucun propriétaire par famille de documents : six mois plus tard, la base n'a pas bougé. Et tester sur cinq questions choisies par l'équipe projet plutôt que cinquante posées par les utilisateurs.
| Étape | Livrable | Effort indicatif |
|---|---|---|
| Inventaire et tri | Tableur des documents retenus avec propriétaire, statut, droits | 2 à 5 jours, métiers et DSI |
| Conversion des formats | Corpus texte, OCR relu sur échantillon | 1 à 3 jours, plus par plan ou scan complexe |
| Nettoyage et versions | Corpus dédoublonné, règle de retrait écrite | 2 à 4 jours |
| Découpage et métadonnées | Index avec contexte par passage et champs de filtrage | 2 à 3 jours, puis réglages après mesure |
| Droits d'accès | Matrice utilisateurs × documents, filtrage à la requête | 1 à 3 jours selon l'annuaire |
| Évaluation | Jeu de 50 à 100 questions, rappel et fidélité mesurés | 2 jours métiers, puis à chaque itération |
Comptez trois à quatre semaines de préparation pour un premier périmètre de quelques centaines de documents, en parallèle du développement. C'est ce calendrier qui permet une mise en production en 4 à 8 semaines.
Ce que JUWA fait sur la préparation d'une base documentaire
Nous commençons par l'inventaire avec les métiers et par le jeu de questions, avant d'écrire une ligne de code. Chez une PME industrielle centenaire, nous avons indexé 2 000 documents techniques dans un assistant documentaire hébergé en France ; le temps de recherche du SAV a baissé de 55 %, et les notices scannées ont été absorbées après une passe d'OCR relue par les techniciens. Cadre habituel : validation humaine sous seuil de confiance dès la première version, chef de projet nommé, point hebdomadaire.
Si votre besoin est un assistant qui répond aux équipes ou aux clients à partir de vos propres documents, notre offre de chatbot IA professionnel sur base documentaire couvre la préparation décrite ici, le développement et l'hébergement. On refuse de brancher un RAG sur un serveur de fichiers non trié : ce serait une démonstration convaincante suivie de six mois de réponses fausses.
