Une base de connaissances RAG d’entreprise, ce n’est pas « verser tout le disque partagé dans une base vectorielle ». C’est une couche d’ingénierie en quatre parties : sources sélectionnées, découpage correct des documents, recherche hybride avec reclassement et application des permissions. Selon les rapports d’éditeurs publiés en 2026, entre 70 % et 80 % des projets RAG en entreprise n’atteignent jamais la production, et la plupart des échecs proviennent des couches d’ingestion et de recherche plutôt que du modèle. Ce guide décompose les quatre couches et propose un plan à 90 jours.
Pourquoi la plupart des projets RAG meurent avant la production
Le schéma se répète. Une équipe construit un pilote en deux semaines, la démonstration impressionne, puis le système rencontre la réalité de l’organisation et s’effondre. Une étude MLOps Community de 2026 portant sur 143 déploiements RAG en entreprise a relevé que 73 % ont connu au moins une défaillance critique lors de leur premier trimestre en production, et que 41 % de ces défaillances n’ont jamais été signalées par les suites d’évaluation standard.
La cause n’est presque jamais le choix du modèle. L’estimation la plus souvent citée dans le secteur veut que 80 % des échecs RAG remontent à la couche d’ingestion et de découpage. Autrement dit : lorsque le système renvoie une mauvaise réponse, c’est le plus souvent parce qu’on a fourni au modèle le mauvais passage dès le départ. Cette distinction compte, car elle déplace le budget – non pas vers une montée en gamme du modèle, mais vers l’ingénierie de la recherche.
Ce que cela implique pour le budget : en 2026, le RAG n’est pas un problème de modèle, c’est un problème d’ingénierie de la recherche. Améliorer le découpage et le reclassement produit un gain de précision supérieur au passage à un modèle plus coûteux, pour un coût de fonctionnement bien moindre. Si vous suivez l’économie unitaire d’un projet d’IA, c’est la différence entre un coût variable qui croît avec l’usage et un investissement ponctuel en infrastructure.
Les quatre couches d’une base de connaissances d’entreprise
| Couche | Ce qu’elle fait | Échec courant |
|---|---|---|
| Sources et métadonnées | Quels documents entrent, qui en est propriétaire, quand ils ont été mis à jour pour la dernière fois | Tout ingérer d’un coup, versions périmées et brouillons compris |
| Découpage | Diviser les documents en passages que le modèle reçoit comme contexte | Une seule règle de découpage pour tous les types de documents, qui casse tableaux et sections |
| Recherche et classement | Trouver les passages pertinents et renvoyer les meilleurs | S’appuyer uniquement sur la recherche vectorielle, sans correspondance par mots-clés |
| Permissions | Garantir qu’un utilisateur ne voie que ce à quoi il a droit | Permissions vérifiées dans l’interface plutôt qu’au moment de la recherche |
Comment découper les documents correctement
Le découpage est la décision qui influence le plus la précision, et c’est aussi celle que la plupart des équipes prennent par défaut. Trois familles de méthodes comptent en 2026 :
| Méthode | Convient le mieux à | Taille de segment recommandée |
|---|---|---|
| Découpage récursif à taille fixe | Prose courante, documents de politique interne, descriptions de processus | 256 à 512 tokens pour les questions-réponses factuelles |
| Découpage sémantique | Documents techniques, spécifications, documentation produit | 512 à 1 024 tokens pour les tâches analytiques |
| Découpage tardif (late chunking) | Documents longs dont le contexte traverse les frontières de section | Le document entier est d’abord vectorisé, puis découpé |
Une règle pratique : un segment doit contenir une réponse complète à une seule question. Si l’on remettait ce passage sur papier à un collaborateur, pourrait-il répondre sans rien consulter d’autre ? Si non, le segment est trop court. Si le passage couvre trois sujets différents, il est trop long et la recherche vectorielle peinera à le cibler.
Deux erreurs récurrentes : couper les tableaux en plein milieu, ce qui transforme les données chiffrées en bruit, et perdre le titre hiérarchique. Le correctif pour la seconde est peu coûteux : ajouter en tête de chaque segment une ligne de contexte avec le nom du document, la section et la date.
Recherche hybride et reclassement
La recherche vectorielle seule passe à côté de ce que les organisations demandent précisément : références de pièces, noms de clients, codes d’erreur, clauses contractuelles. Ce sont des chaînes exactes que le plongement sémantique estompe. C’est pourquoi la recherche hybride, qui combine plongements denses et correspondance par mots-clés de type BM25, continue de surpasser la recherche purement dense sur la plupart des types de documents d’entreprise.
La structure devenue un point de départ courant : récupérer 20 candidats, les reclasser avec un modèle de reranking et transmettre les cinq meilleurs au LLM. Le reclassement est l’étape au meilleur rapport rendement-effort, car il corrige les erreurs de recherche sans toucher à la couche de découpage.
Permissions : la couche que tout le monde repousse
C’est là que meurent les pilotes. Dans un pilote, tout le monde voit tout ; puis vient le moment où un agent du support ne doit pas voir les documents de paie. Si les permissions ne sont appliquées que dans l’interface, la recherche lit quand même le document et le modèle peut encore le citer. L’application doit se faire au moment de la recherche, sous forme de filtre sur les métadonnées, avant que les passages n’atteignent le modèle.
En pratique : chaque segment porte les identifiants de groupe autorisés à le voir, et la requête filtre dessus. C’est aussi ce qui rend le système auditable, puisque vous pouvez montrer exactement quels documents ont alimenté chaque réponse.
Comment mesurer que le système fonctionne
Environ 70 % des équipes qui exploitent du RAG en production ne mesurent pas systématiquement la qualité de la recherche. C’est pour cela que les défaillances passent inaperçues. Le cadre admis est la « triade RAG », trois axes que vous pouvez exécuter automatiquement sur un jeu de questions fixe :
| Axe | La question qu’il teste | Que faire quand il est bas |
|---|---|---|
| Pertinence du contexte | La recherche a-t-elle trouvé les bons documents ? | Corriger le découpage, ajouter la recherche hybride |
| Ancrage dans les sources | La réponse est-elle réellement étayée par les passages récupérés ? | Resserrer le prompt, exiger la citation des sources |
| Pertinence de la réponse | La réponse traite-t-elle bien de la question posée ? | Décomposer les questions à sauts multiples |
Un point faible connu : 71 % des systèmes RAG en production échouent sur les questions à sauts multiples, celles qui exigent de combiner des informations issues de deux documents différents. Si c’est votre cas d’usage principal, construisez le jeu d’évaluation autour de lui dès le premier jour, plutôt qu’autour de questions factuelles simples qui passent toujours.
Ce qui distingue les équipes qui livrent : un jeu d’évaluation documenté, versionné et exécuté automatiquement chaque nuit. Sans lui, chaque modification du découpage ou du prompt est un pari, et vous ne pouvez pas savoir si vous avez amélioré les choses ou tout cassé.
Un plan à 90 jours
Jours 1 à 30 : choisissez un cas d’usage avec un public défini. Cartographiez uniquement les 50 à 200 documents pertinents, purgez les versions périmées et attribuez à chaque document un propriétaire et une date de dernière mise à jour. En parallèle, rédigez 40 questions réelles que l’équipe pose vraiment, avec des réponses validées. C’est votre jeu d’évaluation.
Jours 31 à 60 : construisez le pipeline – découpage, plongements, recherche hybride, reclassement, filtre de permissions. Exécutez le jeu d’évaluation et enregistrez un score de référence sur les trois axes. Améliorez le découpage et le classement jusqu’à ce que la pertinence du contexte se stabilise.
Jours 61 à 90 : ouvrez à un vrai groupe pilote, journalisez chaque question avec les passages récupérés et ajoutez un bouton de retour. Les questions en échec viennent enrichir le jeu d’évaluation. N’élargissez à d’autres sources qu’après deux semaines consécutives de métriques stables.
Si vous construisez cela pour la première fois, lisez aussi comment mesurer sa visibilité dans les moteurs de réponse IA – la même discipline de mesure s’applique du côté externe. Et lorsque vous arrivez au déploiement organisationnel, notre pratique d’implémentation de l’IA commence précisément par cet exercice de cartographie.
Questions fréquentes
Combien de documents faut-il pour démarrer un projet RAG en entreprise ?
Bien moins qu’on ne l’imagine. Un seul cas d’usage est largement couvert par 50 à 200 documents propres et à jour. Ingérer des dizaines de milliers de documents dès le départ fait baisser la précision, car les versions périmées et les brouillons se disputent les mêmes emplacements de recherche.
Quelle taille de segment est recommandée ?
Entre 256 et 512 tokens pour les questions factuelles, et entre 512 et 1 024 tokens pour les tâches analytiques. La règle pratique : un segment doit contenir une réponse complète à une seule question, sans casser les tableaux et sans perdre le titre de section.
Pourquoi la recherche vectorielle seule ne suffit-elle pas ?
Parce qu’elle estompe les chaînes exactes comme les références de pièces, les codes d’erreur et les noms de clients. La recherche hybride, qui combine plongements et correspondance par mots-clés de type BM25, donne de meilleurs résultats sur presque tous les types de documents d’entreprise.
Comment garantir qu’un utilisateur ne voie jamais un document interdit ?
Appliquez les permissions au moment de la recherche plutôt que dans l’interface. Chaque segment porte les identifiants de groupe autorisés à le voir, et la requête filtre dessus avant qu’aucun passage n’atteigne le modèle.
Combien de temps faut-il pour atteindre la production ?
Un cas d’usage unique et ciblé peut atteindre un vrai pilote en environ 90 jours : un mois pour cartographier les sources et bâtir un jeu d’évaluation, un mois pour construire et régler le pipeline, et un mois de pilote avec de vrais retours.