Un RAG amplifie la qualité — ou la médiocrité — de son corpus. La méthode complète pour auditer sa base avant l'IA : inventaire, scoring autorité/fraîcheur, détection des contradictions et lacunes, Knowledge Ops et KPIs de santé.
Tout le monde se précipite sur le modèle, le pipeline, le reranking. Presque personne ne regarde ce qui détermine vraiment la qualité d'un assistant IA : le corpus qu'on lui donne à manger. Un RAG est un amplificateur. Donnez-lui une documentation claire, à jour et cohérente, il produira des réponses fiables. Donnez-lui un fatras de versions contradictoires, de documents périmés et de zones d'ombre, il produira des inexactitudes — avec aplomb, et à grande échelle. Avant de vectoriser quoi que ce soit, il faut auditer ce que l'on sait vraiment.
Ce guide propose une méthode complète d'audit de connaissances : inventorier, scorer, détecter les contradictions et les lacunes, gouverner, et mesurer. C'est le travail le moins glamour d'un projet RAG, et de loin le plus rentable. Vous pouvez changer d'embeddings, ajouter un reranker Cohere Rerank 3, passer à la recherche hybride : aucun de ces leviers ne corrigera un corpus qui ment, se contredit ou se tait. Le travail décrit ici n'est pas un prérequis qu'on coche une fois ; c'est une discipline qu'on installe et qu'on maintient. Comptez deux à quatre semaines pour un premier audit sérieux sur un périmètre métier, puis un effort récurrent bien plus léger une fois la gouvernance en place.
Pourquoi le RAG amplifie la qualité — ou la médiocrité
Un assistant IA ne « comprend » pas votre métier : il restitue, reformule et combine ce qu'il trouve dans votre corpus. Cette mécanique a une conséquence directe :
- une documentation excellente produit un assistant excellent ;
- une documentation médiocre produit un assistant qui répond avec assurance… des erreurs.
Le danger est insidieux : l'assistant ne signale pas qu'il s'appuie sur un document périmé ou contradictoire. Il répond, fluide et convaincant. C'est précisément cette fluidité qui rend une mauvaise base si dangereuse : elle maquille les défauts du corpus en réponses crédibles. Un humain qui consulte un wiki repère souvent qu'une page « sent le vieux » — couleurs datées, mention d'un outil disparu, nom d'un collègue parti depuis longtemps. Le RAG, lui, n'a aucun de ces signaux contextuels : il lit le texte, l'embedde, le ressort comme s'il faisait foi.
Il faut aussi comprendre ce que le pipeline ne corrige pas. Le reranking réordonne des passages selon leur pertinence à la question, pas selon leur véracité ni leur fraîcheur : un document périmé mais très pertinent sémantiquement remontera en tête. La recherche hybride (BM25 + dense) améliore le rappel, donc elle a même tendance à faire remonter davantage de documents médiocres. Le contextual retrieval (préfixer chaque chunk d'un court contexte généré par LLM) améliore la localisation de l'information, pas sa qualité intrinsèque. Aucune brique d'ingénierie ne sait distinguer « la procédure actuelle » de « la procédure de 2021 » si rien, dans le corpus, ne le dit.
Investir dans le pipeline avant d'auditer le corpus, c'est polir la lentille d'un appareil photo dont l'objectif est sale. La netteté ne viendra jamais de l'aval.
Étape 1 — Inventorier et cartographier
On ne peut auditer que ce que l'on connaît. Le premier travail est de cartographier le patrimoine informationnel :
- Quelles sources ? Bases de connaissances, wikis, lecteurs partagés, e-mails, tickets, fils de discussion, documents épars.
- Quel volume et quelle nature ? Documents structurés, textes libres, PDF scannés, tableaux, code.
- Qui produit et qui maintient ? Une source sans propriétaire est une source qui vieillit mal.
- Quelle est la sensibilité ? Données personnelles, confidentielles, réglementées — à traiter à part.
La méthode concrète
Ne commencez pas par la collecte des fichiers, commencez par les personnes. Identifiez 5 à 10 personnes qui produisent ou consomment beaucoup de connaissance dans le périmètre (support, produit, juridique, RH, terrain) et menez avec chacune un entretien de 30 minutes : où vont-elles chercher l'information ? quels documents ouvrent-elles dix fois par jour ? lesquels ne croient-elles plus ? Cet entretien révèle ce qu'aucun crawl automatique ne montre — la hiérarchie d'usage réelle et le savoir tribal.
Ensuite seulement, inventoriez les emplacements : espaces Confluence/Notion, dossiers SharePoint/Drive, dépôts Git pour la doc technique, file de tickets, anciens PDF figés dans un dossier « archives » que tout le monde consulte encore. Pour chaque source, remplissez une carte des sources.
Modèle de carte d'une source
Source : Espace "Support N1" (Confluence)
Propriétaire : Équipe Support (resp. : J. Martin)
Volume : ~420 pages, ~6 Mo de texte
Nature : texte libre + captures d'écran (faible valeur OCR)
Dernière revue d'ensemble : inconnue
Sensibilité : faible (aucune donnée perso), 3 pages avec captures à flouter
Statut d'ingestion proposé : OUI (sous-espace "FAQ" prioritaire)
Format : HTML export → Markdown
Agrégez ces cartes dans un tableau unique. Exemple :
| Source |
Propriétaire |
Volume |
Autorité |
Fraîcheur |
Sensibilité |
Ingérer ? |
| Confluence Support N1 |
Support |
420 p. |
Officielle |
Mitigée |
Faible |
Oui (partiel) |
| Drive "Procédures RH" |
RH |
1 200 fich. |
Mixte |
Variable |
Élevée |
Après tri |
| Wiki produit (Notion) |
Produit |
180 p. |
Officielle |
Bonne |
Faible |
Oui |
| Dossier "Archives 2019-2022" |
aucun |
3 400 fich. |
Inconnue |
Périmée |
Inconnue |
Non (archiver) |
| Boîte mail "support@" |
aucun |
~ illimité |
Aucune |
— |
Élevée |
Non |
Le livrable de cette étape est cette carte des sources : ce que vous avez, où, dans quel état, et sous quelle responsabilité. Elle sert ensuite de base à toutes les décisions d'ingestion. Un audit qui produit ce tableau a déjà créé de la valeur, même avant la première vectorisation.
Étape 2 — Scorer l'autorité et la fraîcheur
Tous les documents ne se valent pas. Deux dimensions structurent le tri :
L'autorité — ce document fait-il foi ? Est-il la source officielle, ou une note de travail oubliée ? Une politique validée, ou un brouillon ? Un RAG qui mélange documents officiels et notes informelles produit des réponses incohérentes.
La fraîcheur — quand a-t-il été mis à jour pour la dernière fois ? Un document de procédure non touché depuis trois ans est suspect par défaut. La date n'est pas une preuve d'obsolescence, mais c'est un signal fort.
Une grille de notation concrète
Notez chaque source (ou chaque famille de documents) sur deux axes de 1 à 5.
Autorité (1-5)
- 5 — Document officiel validé par un propriétaire identifié, statut « approuvé ».
- 4 — Document de référence largement utilisé, mais validation informelle.
- 3 — Contenu utile mais non validé (guide d'équipe, page wiki active).
- 2 — Note de travail, brouillon, contenu personnel partagé.
- 1 — Source inconnue, copie sans origine, contenu non attribuable.
Fraîcheur (1-5)
- 5 — Revu/mis à jour il y a moins de 6 mois.
- 4 — 6 à 12 mois.
- 3 — 12 à 24 mois.
- 2 — 24 à 36 mois.
- 1 — Plus de 36 mois, ou date inconnue.
Pondérez selon la volatilité du sujet : une tarification ou une procédure de conformité change vite (la fraîcheur compte double) ; une définition de concept métier vieillit lentement (la fraîcheur compte peu). Combinez ensuite en un score simple, par exemple score = autorité × fraîcheur (de 1 à 25), et fixez des seuils d'action.
Exemple chiffré
| Document |
Autorité |
Fraîcheur |
Score (A×F) |
Décision |
| Politique de remboursement v4 (approuvée, mars 2026) |
5 |
5 |
25 |
Ingérer, pondérer haut |
| FAQ Support (active, revue il y a 8 mois) |
4 |
4 |
16 |
Ingérer |
| Guide d'onboarding (utile, 20 mois) |
3 |
3 |
9 |
Ingérer après revue |
| Note Slack exportée « process remboursement » (2022) |
2 |
1 |
2 |
Écarter / archiver |
| PDF « tarifs » sans date |
3 |
1 |
3 |
Rafraîchir avant d'ingérer |
Règle d'arbitrage indicative : ≥ 16 entre directement dans le corpus servi ; 8-15 entre après une revue rapide par le propriétaire ; < 8 est écarté ou rafraîchi d'abord. Ces seuils sont à calibrer, mais l'important est qu'ils soient explicites et tracés : chaque décision d'inclusion doit pouvoir s'expliquer.
Mieux vaut un corpus restreint de documents qui font foi qu'un corpus exhaustif où le faisant-foi se noie dans le périmé. En matière de connaissances, la quantité nuit à la qualité au-delà d'un certain seuil.
Étape 3 — Détecter les contradictions
C'est le poison silencieux des bases de connaissances. Quand deux documents affirment des choses incompatibles — une ancienne politique de remboursement et la nouvelle, deux procédures divergentes — l'assistant n'a aucun moyen de savoir laquelle privilégier. Il peut citer l'une, l'autre, ou pire, mélanger les deux dans une même réponse fluide et fausse.
La méthode
- Regrouper par sujet. Utilisez le clustering d'embeddings (ou un simple tri par titre/tag) pour rassembler les documents qui parlent de la même chose. Deux à cinq documents sur un même sujet, voilà votre liste de candidats à la contradiction.
- Comparer les affirmations clés. Pour chaque cluster, extrayez les faits « durs » : montants, délais, seuils, conditions, dates d'effet. Une grille « sujet → ce que dit chaque document » fait sauter les écarts aux yeux.
- Demander à un LLM de jouer l'arbitre. Donnez-lui deux extraits et demandez-lui : « Ces deux passages sont-ils compatibles ? Si non, sur quel point divergent-ils ? » C'est une excellente première passe de détection, à valider ensuite par un humain.
- Tester avec des questions pièges. Interrogez l'assistant (ou la recherche brute) sur les sujets sensibles. Les incohérences remontent vite.
Exemples de questions pièges
- « Quel est le délai exact de remboursement ? » (révèle 14 j. vs 30 j. selon la version)
- « Faut-il l'accord du manager avant ou après la demande ? » (deux procédures RH divergentes)
- « Le plan Pro inclut-il le SSO ? » (page produit obsolète vs grille tarifaire à jour)
- « Quelle est la politique actuelle de télétravail ? » (note 2021 vs accord 2025)
Exemple concret
Deux documents sur le remboursement : Politique-remboursement-v4.pdf (mars 2026, « 14 jours ouvrés ») et une page wiki « Remboursements » (non datée, « sous 30 jours »). Le RAG interrogé sur le délai peut répondre « 30 jours », « 14 jours », ou pire « entre 14 et 30 jours ». Le remède : désigner la v4 comme source de vérité, mettre à jour ou rediriger la page wiki, et sortir du corpus servi toute version contradictoire (archivée à part, pas supprimée — la traçabilité a sa valeur).
Le remède général : une source de vérité unique par sujet, et l'archivage hors corpus des versions périmées.
Étape 4 — Détecter les lacunes
Une lacune est un sujet sur lequel votre base n'a rien, ou rien de satisfaisant — alors que vos utilisateurs vont immanquablement poser la question. Deux moments pour les détecter :
À froid, avant déploiement
Confrontez la carte des sources aux questions attendues. Construisez un jeu de 50 à 200 questions de référence (un golden set) à partir de trois matières : les tickets/e-mails les plus fréquents des 6 derniers mois, les questions récurrentes en réunion, et l'intuition des experts métier. Pour chaque question, vérifiez : un document fait-il foi sur ce point ? Les questions sans réponse documentée sont vos lacunes à froid. Ce golden set resservira pour l'évaluation continue (RAGAS : context recall, answer relevancy).
À chaud, en production
Exploitez les requêtes réelles, là où les utilisateurs vous disent eux-mêmes où sont les trous :
- requêtes à faible score de récupération (aucun chunk au-dessus du seuil de similarité) ;
- réponses non sourcées ou marquées « information non trouvée » ;
- « je ne sais pas » répétés sur des thèmes proches ;
- reformulations successives d'une même question (signe que l'utilisateur n'a pas eu sa réponse).
Agrégez ces signaux par thème, classez par fréquence, et vous obtenez une file de lacunes priorisée par la demande réelle — bien plus fiable que n'importe quelle devinette.
Les lacunes ne se devinent pas, elles se mesurent. Avant le lancement, par anticipation ; après, par l'écoute des requêtes réelles. Un corpus mûr est un corpus dont les lacunes se comblent au rythme des besoins.
Étape 5 — Gouverner : le Knowledge Ops
Un audit ponctuel ne tient pas : le corpus est vivant. La gouvernance — ce qu'on appelle parfois le Knowledge Ops — transforme l'audit en processus durable.
Les rôles
- Knowledge Owner (par domaine) — responsable de l'autorité et de la fraîcheur de son périmètre (support, produit, RH…). C'est lui qui valide qu'un document « fait foi ».
- Knowledge Steward / curateur — anime le processus transverse : tient la carte des sources, priorise la file, fait respecter les règles d'ingestion.
- Contributeurs — toute personne qui crée ou corrige du contenu, dans un cadre simple.
- Sponsor (CTO, Head of AI ou COO) — porte les arbitrages et les indicateurs au niveau direction.
Le cycle de revue
Calez la fréquence sur la volatilité du sujet :
- documents critiques et volatils (tarifs, conformité, sécurité) : revue trimestrielle ;
- documents de référence stables : revue annuelle ;
- au-delà du délai, le document passe en statut « à revoir » et, s'il n'est pas validé, sort automatiquement du corpus servi.
Le workflow
Création/correction (contributeur)
│
revue Knowledge Owner (autorité + fraîcheur)
│
statut "approuvé" + date de revue + propriétaire
│
ingestion dans le corpus servi
│
expiration auto à l'échéance ─► retour en revue
Les règles d'ingestion
Écrivez-les noir sur blanc. Exemple : entrent dans le corpus servi les documents au statut « approuvé », score ≥ 16, sans donnée personnelle non maîtrisée ; restent dehors les brouillons, les archives, les exports bruts de messagerie, et tout contenu sensible non traité (anonymisation, contrôle d'accès). Chaque source de la carte porte un statut d'ingestion explicite et révisable.
- Une propriété claire — chaque source a un responsable identifié, garant de sa qualité et de sa fraîcheur.
- Un cycle de revue — les documents critiques sont relus à intervalle défini ; les obsolètes sont archivés.
- Un workflow de contribution — créer ou corriger un document doit être simple, sinon la dette s'accumule.
- Une boucle avec l'usage — les lacunes et contradictions détectées en production alimentent une file de travail priorisée.
- Des règles d'ingestion — quels documents entrent dans le corpus servi, lesquels restent à l'écart.
Sources ─► audit (inventaire, scoring, contradictions, lacunes)
│
corpus servi (faisant-foi, frais, cohérent)
│
usage réel ─► détection lacunes/contradictions
│
file priorisée ─► création/correction ─► (boucle)
Étape 6 — Mesurer la santé du corpus
Ce qui ne se mesure pas ne s'améliore pas. Quelques indicateurs de santé du corpus, avec des cibles indicatives à calibrer selon votre maturité :
- Taux de couverture — part des questions du golden set couvertes par au moins une source faisant foi. Cible : > 90 %.
- Taux de fraîcheur — part des documents critiques revus dans la période définie. Cible : > 95 % dans les délais.
- Taux de contradictions résolues — sujets dotés d'une source de vérité unique vs sujets restés ambigus. Cible : 100 % sur les sujets sensibles identifiés.
- Taux de lacunes — part des requêtes de production sans réponse satisfaisante (faible score, non sourcé). Cible : tendance décroissante, < 5 % à maturité.
- Taux de réponses sourcées — l'indicateur de synthèse : part des réponses appuyées sur au moins une source faisant foi. Cible : > 85 %. S'il est élevé, votre corpus est en bonne santé.
Suivez aussi l'âge médian des documents servis et le nombre de documents en statut « à revoir » : deux signaux d'alerte avancés de dégradation. Ces métriques font de la qualité du corpus un objet pilotable, dont on peut justifier les progrès auprès de la direction — et non une intuition floue.
Un mini-cas de bout en bout
Une PME SaaS européenne déploie un assistant interne pour son support N1. Déroulé de l'audit :
- Inventaire — 6 sources cartographiées. Découverte clé : 70 % du volume vit dans un Drive « archives » que personne ne maintient mais que les agents consultent encore.
- Scoring — sur 1 100 documents, seuls 240 atteignent un score ≥ 16. Le reste est écarté ou mis en file de rafraîchissement. Le corpus servi initial passe de « tout » à 240 documents.
- Contradictions — le clustering révèle 3 sujets à double vérité (remboursement, SLA, conditions d'essai). Une source de vérité est désignée pour chacun ; 9 documents périmés sont archivés.
- Lacunes (à froid) — un golden set de 80 questions révèle 11 sujets non couverts (dont la facturation annuelle et le RGPD côté client). Tickets de rédaction créés.
- Knowledge Ops — chaque source reçoit un propriétaire ; revue trimestrielle pour le volatil, annuelle pour le stable ; règles d'ingestion écrites.
- Mesure — au lancement : couverture 86 %, réponses sourcées 78 %. Après deux mois d'écoute des requêtes réelles (lacunes à chaud comblées) : couverture 94 %, réponses sourcées 89 %.
Résultat : un corpus plus petit (240 vs 1 100 documents) mais plus sain, et un assistant qui répond juste et sourcé. La qualité n'est pas venue d'un meilleur modèle — elle est venue d'un meilleur corpus.
Les pièges de l'audit
- Tout ingérer « au cas où » — l'exhaustivité est l'ennemie de la pertinence. Auditez pour écarter, pas seulement pour collecter.
- Auditer une fois, puis oublier — sans Knowledge Ops, le corpus se redégrade en quelques mois.
- Confondre volume et valeur — 10 000 documents médiocres valent moins que 500 documents faisant foi.
- Ignorer le savoir tribal — les meilleures réponses sont parfois dans la tête des experts, jamais écrites. L'audit doit aussi révéler ce qui manque à l'écrit.
- Négliger la sensibilité — un audit est aussi l'occasion de repérer les données personnelles et confidentielles à traiter à part (voir nos articles RGPD).
- Croire que le pipeline rattrapera tout — reranking, hybride, contextual retrieval améliorent la récupération, jamais la véracité d'un document faux.
Conclusion
L'audit de connaissances est le travail invisible qui décide du succès visible de votre RAG. Avant d'optimiser le moindre paramètre de récupération, prenez le temps d'inventorier, de scorer, de purger les contradictions et de cartographier les lacunes — puis installez une gouvernance qui maintient cette qualité dans le temps. Un assistant IA ne sera jamais meilleur que la connaissance qu'on lui confie. La bonne nouvelle, c'est que ce chantier profite à toute l'organisation, bien au-delà de l'IA : une base de connaissances saine, c'est un actif en soi. L'IA n'en est que le révélateur le plus impitoyable.
Pour aller plus loin
- Détecter les lacunes de votre base avec les requêtes utilisateurs
- Support client augmenté par RAG : diviser le temps de résolution sans perdre en qualité
- RAG souverain et conforme RGPD : le guide complet 2026