Avant un projet RAG, préparez vos documents

L'infrastructure n'est plus le sujet

Monter une IA capable de chercher une réponse dans un ensemble de documents d'entreprise, une pratique désormais courante sous le nom de RAG (retrieval augmented generation), ne demande plus une expertise technique rare. Des plateformes assemblent aujourd'hui un tel système en moins d'une heure, sans écrire une ligne de code. Cette facilité crée une attente compréhensible mais trompeuse chez un dirigeant qui découvre le sujet : si l'outil se monte aussi vite, la difficulté du projet doit être ailleurs, ou n'existe plus vraiment.

La difficulté n'a pas disparu, elle a changé de nature. Elle ne se trouve plus dans l'assemblage technique du système, mais dans l'état réel des documents qu'on lui donne à lire. Un système RAG ne fait rien d'autre que retrouver un passage de texte pertinent puis le reformuler, il ne corrige jamais la qualité de ce texte, il l'hérite intégralement, y compris ses contradictions et ses erreurs.

Cette bascule change complètement la nature du travail à prévoir. Il y a encore deux ans, un projet de recherche documentaire IA demandait plusieurs semaines de développement pour assembler l'indexation, la recherche et la génération de réponse. Aujourd'hui, cette brique s'achète ou se configure en quelques heures. Le budget et le temps qui n'ont plus besoin d'être consacrés à cet assemblage ne disparaissent pas pour autant, ils doivent simplement être redirigés vers un travail différent, moins visible, sur la matière première documentaire elle-même.

Pourquoi un outil fiable produit quand même des réponses fausses

La plupart des déceptions sur un projet RAG ne viennent pas d'un défaut de l'outil, elles viennent de ce que l'outil retrouve fidèlement dans un fonds documentaire qui n'a jamais été nettoyé. Trois versions d'une même procédure coexistent depuis deux ans dans le même dossier, sans qu'aucune n'ait été supprimée après sa remise à jour. Le système retrouve l'une des trois, souvent la plus ancienne parce qu'elle a été consultée et donc indexée plus de fois, et la présente avec la même assurance que s'il s'agissait de la version en vigueur.

Un deuxième problème s'ajoute au premier : le découpage d'un document long en fragments exploitables par l'IA, une étape technique appelée chunking, produit des résultats très différents selon la façon dont le document source est structuré à l'origine. Un contrat découpé au mauvais endroit peut séparer une clause de son exception, et le système retrouvera la clause seule, sans jamais savoir qu'une exception existait juste après dans le document d'origine.

Un troisième problème, plus discret, touche les documents qui se ressemblent sans être identiques : deux modèles de contrat presque semblables, l'un pour un client particulier, l'autre générique, dont seule une clause diffère. Un système de recherche qui ne dispose d'aucune indication sur le contexte d'usage de chaque document mélangera les deux avec la même confiance apparente, produisant une réponse qui semble complète tout en combinant des éléments qui ne devraient jamais coexister dans une même réponse.

« Pour moi, le seul point essentiel dans tout ça, c'est la nomenclature des documents, pour standardiser ce que c'est qu'un document dans le système. Vous pourriez tout enlever autour, ce n'était pas mal d'avoir au moins ça comme base de discussion. »

La couche de contexte appliquée à vos documents

Ce principe rejoint un chantier que nous avons déjà détaillé pour l'intégration de l'IA en général : formaliser une couche de contexte avant de brancher un système intelligent sur son activité. Appliqué aux documents, ce principe prend une forme précise. Avant de chercher un outil RAG, une entreprise gagne à répondre à des questions bien plus simples, mais rarement posées : quels documents sont réellement à jour, lesquels doivent être archivés plutôt que supprimés pour garder une trace, et quelle nomenclature permet de savoir, au premier coup d'œil, ce que contient un fichier sans avoir à l'ouvrir.

Cette formalisation ne demande pas de compétence en intelligence artificielle. Elle demande de l'attention et du temps de la part des personnes qui connaissent déjà le métier, souvent plus de temps que la mise en place technique du système elle-même. C'est précisément cette asymétrie, un travail long et peu spectaculaire d'un côté, un assemblage rapide et démonstratif de l'autre, qui pousse tant d'entreprises à sauter la première étape pour se précipiter sur la seconde.

Sur la méthode complète pour construire cette couche de contexte à l'échelle de toute une activité, et pas seulement pour un fonds documentaire, notre article dédié détaille pourquoi cette étape conditionne la fiabilité de n'importe quel projet IA, RAG ou non.

Trois questions à trancher avant de choisir un outil

Trois vérifications suffisent à révéler l'état réel d'un fonds documentaire avant de se lancer. Combien de versions différentes existent pour vos cinq documents les plus consultés, et lesquelles peuvent être supprimées sans risque. Existe-t-il une convention de nom qui permette de distinguer un document à jour d'un brouillon sans l'ouvrir. Et surtout, une personne de l'équipe pourrait-elle, aujourd'hui, retrouver la bonne version d'une procédure en moins d'une minute. Si la réponse est non pour un humain, un système RAG rencontrera la même difficulté, avec en plus l'assurance trompeuse d'une réponse rédigée avec fluidité.

Ces trois vérifications ont un avantage que beaucoup de dirigeants sous-estiment : elles produisent de la valeur même si le projet RAG est finalement repoussé ou abandonné. Un fonds documentaire nettoyé, avec une nomenclature cohérente et sans doublon, rend service à toute personne qui cherche une information, IA ou pas. Ce n'est donc jamais un investissement perdu, contrairement à un abonnement à un outil qui reste sous-utilisé faute d'avoir résolu le problème en amont.

Cette exigence de tri rejoint une question déjà traitée pour l'automatisation de processus métier plus largement : un système ne peut pas deviner une règle qui n'a jamais été rendue explicite, il ne peut qu'hériter du flou existant et le reproduire avec assurance. Sur la méthode pour faire remonter ces règles avant de les confier à un système automatisé, notre article sur les règles métier implicites dans un projet SI détaille une méthode transposable directement à un fonds documentaire.

Ce que cette préparation ne remplace pas

Préparer ses documents ne dispense pas de choisir une architecture technique adaptée à l'usage réel qu'on attend du système. Une bonne partie des échecs de projets RAG vient aussi d'un décalage d'usage : les utilisateurs traitent le système comme un assistant généraliste capable de converser sur n'importe quel sujet, alors qu'il reste, par construction, un spécialiste de la recherche dans un périmètre documentaire précis. Cette confusion d'attente déçoit même un système parfaitement alimenté par des documents propres.

Le travail de préparation documentaire et le choix de l'architecture technique avancent donc en parallèle, jamais l'un après l'autre. Mais entre les deux, seul le premier reste entièrement sous le contrôle du dirigeant, sans dépendre d'un choix de prestataire ou d'outil. C'est aussi le seul des deux qui, mal fait, rendra décevant n'importe quel outil choisi ensuite, aussi sophistiqué soit-il.

Cette répartition du contrôle change aussi la façon d'évaluer un prestataire qui propose de mettre en place un tel système. Un prestataire sérieux commence par poser des questions sur l'état de vos documents avant de parler d'architecture ou de modèle de langage à utiliser. Un prestataire qui propose directement un calendrier de mise en production sans avoir examiné un échantillon réel de votre fonds documentaire prend le risque de découvrir les vrais problèmes après la signature, au moment où ils coûtent le plus cher à corriger.

La bonne nouvelle, dans ce constat, est que le travail le plus déterminant reste accessible sans compétence technique particulière. Trier, nommer et éliminer les versions obsolètes d'un fonds documentaire est un travail que n'importe quelle équipe métier peut mener elle-même, sans attendre un budget dédié à un projet IA. C'est même la meilleure façon de découvrir, avant d'investir dans un outil, si le problème que l'on cherchait à résoudre par la technologie n'était pas d'abord un problème d'organisation documentaire non traité.

Avant de comparer des plateformes RAG entre elles, ouvrez le dossier partagé de votre équipe et comptez combien de versions différentes de votre procédure la plus consultée s'y trouvent encore. Ce chiffre, plus que n'importe quelle démonstration commerciale, vous dira si vous êtes prêt à lancer ce projet ou si le vrai chantier commence avant, sur ce que vous avez déjà.