Vos pilotes IA brillent en démo et déçoivent en production ? Le coupable est rarement le modèle. Voici les cinq signes qui trahissent une base de connaissances pas prête pour le RAG — et comment y remédier.
La plupart des projets IA d'entreprise échouent non pas à cause du modèle, mais à cause de la couche de données. Vous pouvez brancher le meilleur LLM du marché, ajouter un reranker Cohere Rerank 3 et un index HNSW parfaitement réglé : si la base que vous lui donnez à lire est sale, périmée ou pleine de trous, votre agent répondra avec assurance des bêtises. C'est le piège classique du RAG en production — on soigne la récupération et la génération, on néglige la matière première.
La bonne nouvelle, c'est que les symptômes d'une base « pas prête » sont reconnaissables. Voici les cinq plus fréquents, ceux qu'on retrouve dans presque chaque audit. Pour chacun : pourquoi c'est un poison pour un RAG, à quoi ça ressemble concrètement, et comment y remédier sans tout reconstruire.
Un RAG n'invente pas la qualité. Il amplifie ce que vous lui donnez. Une base médiocre produit un assistant médiocre, en plus rapide et plus assuré.
Les décisions importantes, les exceptions, les contournements opérationnels — tout cela vit dans des threads. « On a décidé de ne plus facturer les frais de port pour les clients Gold, valable jusqu'à nouvel ordre » : cette phrase n'existe nulle part dans une procédure officielle. Elle est dans un canal #ops entre deux blagues et un GIF.
Pourquoi c'est un problème pour un RAG. La connaissance dans Slack est non structurée, contextuelle et éphémère. Un message dépend des dix messages précédents pour avoir un sens ; isolé en chunk, il devient ambigu ou trompeur. Pire : Slack contient des décisions contradictoires empilées dans le temps, sans marqueur indiquant laquelle fait foi aujourd'hui. Si vous ingérez tout, vous injectez du bruit ; si vous n'ingérez rien, votre agent ignore des règles métier réelles que vos équipes appliquent au quotidien.
Exemple concret. Un agent support interrogé sur la politique de frais de port répond « 4,90 € quelle que soit la commande » en citant un PDF de 2022, alors que la règle vivante — exonération pour les clients Gold — n'a jamais quitté un thread. Le client Gold est facturé à tort, le conseiller fait confiance à l'agent, l'incident remonte.
Comment y remédier.
- Mettez en place une gouvernance de promotion : tout ce qui sort d'une conversation et devient une règle doit être promu dans une source documentée (page de procédure, base de décisions). Slack est un lieu de débat, pas une source de vérité.
- Ingérez les canaux Slack de façon sélective et enrichie : ne prenez que les canaux à valeur documentaire, et utilisez une technique de type contextual retrieval (préfixer chaque chunk d'un court contexte généré par LLM résumant le fil) pour qu'un message isolé reste interprétable.
- Datez et tracez : chaque élément ingéré depuis Slack doit porter sa date et son auteur, pour permettre l'arbitrage en cas de contradiction.
La version officielle de votre politique de remboursement date de 2021. Personne ne sait si elle est encore valide. Elle dort dans un dossier Drive/Juridique/Définitif/. Votre agent va la citer comme parole d'évangile.
Pourquoi c'est un problème pour un RAG. Un système de récupération n'a aucune notion native de « périmé ». Un chunk de 2021 et un chunk de 2025 ont la même apparence dans l'espace vectoriel ; si le document obsolète est mieux rédigé ou plus proche sémantiquement de la question, il sera récupéré et cité en priorité. La fraîcheur n'est pas une dimension que l'embedding capture — c'est une métadonnée que vous devez gérer explicitement.
Exemple concret. Une entreprise migre vers un nouveau barème tarifaire en janvier. L'ancienne grille, en PDF, reste dans la base. Pendant six mois, l'agent commercial cite tantôt l'ancienne, tantôt la nouvelle, selon la formulation de la question. Les devis partent faux. Personne ne comprend pourquoi avant l'audit.
Comment y remédier.
- Attachez à chaque document des métadonnées de cycle de vie : date de création, date de dernière revue, date d'expiration, propriétaire responsable.
- Mettez en place une revue périodique : tout document non revu depuis N mois est signalé comme « fraîcheur non garantie » et peut être déclassé ou exclu de la récupération.
- Exploitez ces métadonnées dans le pipeline : filtrez ou pénalisez les chunks périmés au moment du retrieval, et faites afficher la date de la source dans la réponse de l'agent pour que l'utilisateur puisse juger.
La pertinence sémantique ne dit rien de la validité temporelle. Un RAG qui ne gère pas la fraîcheur cite le passé avec l'assurance du présent.
« PolitiqueRHv3FINAL.docx », « PolitiqueRHv3FINALREVISEE.docx », « PolitiqueRHv3FINALOKOK.docx ». Lequel est la vérité ? Vous ne le savez pas, et votre système d'ingestion encore moins.
Pourquoi c'est un problème pour un RAG. La duplication quasi-identique est l'un des pires ennemis de la récupération. Plusieurs versions d'un même texte saturent le top-k : sur les cinq chunks récupérés, trois disent la même chose avec des variations mineures, et l'agent croit voir une convergence forte alors qu'il regarde le même document recopié. Pire, deux versions peuvent diverger sur un point clé (préavis de 2 mois vs 3 mois), et le modèle, voyant les deux, hallucine un compromis ou choisit au hasard.
Exemple concret. Un salarié demande à l'assistant RH le préavis de démission. La base contient trois versions de la politique. L'une dit 2 mois, une autre 3 mois, la dernière ne mentionne rien. L'agent répond « entre 2 et 3 mois selon les cas » — une réponse inventée qui ne figure dans aucun document, née de la collision de versions.
Comment y remédier.
- Établissez une source unique de vérité par sujet : un seul document canonique par politique, par procédure, par contrat-type. Tout le reste est archive, hors périmètre d'ingestion.
- Mettez en place un versioning réel (et non une convention de nommage de fichiers) : un identifiant stable, un numéro de version, un statut (brouillon, publié, obsolète). Seul le statut publié entre dans l'index.
- Détectez la quasi-duplication au moment de l'ingestion (similarité élevée entre chunks) et déduplicquez : conservez la version canonique, écartez les copies.
Notion pour les processus, Drive pour les contrats, SharePoint pour les rapports, Confluence pour la tech, Slack pour les décisions, GitHub pour le code. Chaque outil a ses droits d'accès, ses formats, son rythme de mise à jour. Aucun agent ne va vous offrir une vue unifiée sans un travail d'ingestion préalable.
Pourquoi c'est un problème pour un RAG. Une question métier réelle traverse les silos : « Quel est le processus d'onboarding d'un client Entreprise ? » mobilise une procédure Notion, un contrat-type Drive, une checklist Confluence et un script GitHub. Si votre RAG n'indexe qu'une source, il répond partiellement et avec aplomb. La fragmentation crée aussi des incohérences de format (un même concept nommé différemment selon l'outil) qui dégradent la récupération sémantique.
Exemple concret. L'agent onboarding décrit parfaitement les étapes documentées dans Confluence mais ignore la clause de réversibilité qui ne vit que dans le contrat-type Drive. Le commercial promet une chose, le contrat en dit une autre. La fragmentation a créé un angle mort invisible.
Comment y remédier.
- Mettez en place une ingestion multi-sources unifiée : des connecteurs vers chaque outil (Notion, Drive, SharePoint, Confluence, Slack, GitHub) qui normalisent les contenus dans un format commun, avec métadonnées de provenance.
- Préservez les droits d'accès à l'ingestion : la couche de connaissance doit respecter le périmètre de chaque utilisateur, pas tout aplatir en accès public.
- Standardisez le vocabulaire et les métadonnées : un schéma commun (sujet, propriétaire, date, statut) à travers les sources, pour que la récupération hybride (BM25 + dense, fusion RRF) fonctionne sur un corpus cohérent plutôt que sur six îlots disparates.
Un agent ne vaut que par l'étendue de ce qu'il peut atteindre. Six silos, c'est six fois l'occasion de répondre à moitié.
Quelle proportion des questions que se posent vos collaborateurs trouvent une réponse dans votre base ? Si vous n'avez pas la réponse, votre agent ne le saura pas non plus — et il comblera le vide en inventant.
Pourquoi c'est un problème pour un RAG. Un RAG sans mesure de couverture est aveugle à ses propres trous. Quand aucune source pertinente n'existe, un système mal conçu ne dit pas « je ne sais pas » : il récupère les chunks les moins éloignés, même médiocres, et génère une réponse plausible mais infondée. Les hallucinations les plus dangereuses ne viennent pas d'un mauvais modèle, mais d'une lacune documentaire que personne n'a cartographiée.
Exemple concret. Les utilisateurs posent régulièrement des questions sur la procédure de remboursement à l'international. Aucun document ne la couvre. L'agent, plutôt que d'avouer son ignorance, extrapole depuis la procédure domestique et invente des délais. Personne ne s'en rend compte tant que les requêtes utilisateurs ne sont pas analysées.
Comment y remédier.
- Constituez un golden set de questions réelles (issues du support, des requêtes utilisateurs, des entretiens métier) et mesurez le taux de réponse correcte avec un cadre comme RAGAS (notamment context recall et answer relevancy).
- Analysez les requêtes utilisateurs en production : les questions à faible score de récupération signalent les lacunes prioritaires à combler par de la documentation.
- Faites de la couverture une métrique suivie dans le temps, pas un audit ponctuel. Chaque nouvelle source ajoutée, chaque document retiré déplace votre couverture — il faut la surveiller comme un indicateur de qualité.
Aucun de ces cinq signes n'est rédhibitoire en soi. Pris ensemble, ils expliquent pourquoi tant de pilotes IA impressionnent en démo et déçoivent en production : le modèle est bon, la donnée ne l'est pas. La bonne séquence n'est pas « choisir un LLM puis brancher la donnée », mais « auditer la donnée, la gouverner, puis brancher un LLM ». Gouvernance, source unique de vérité, versioning, ingestion multi-sources, mesure de couverture : ce sont des chantiers de fond, pas des réglages d'hyperparamètres.
Faire cet inventaire à la main est fastidieux. C'est précisément ce que Knowledge Pulse automatise : il analyse votre base, détecte ces cinq familles de problèmes, et restitue un score de maturité 0-100 avec les dimensions évaluées et des recommandations priorisées. 60 secondes, gratuit — de quoi savoir où vous en êtes avant d'investir dans la couche IA.
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é.
Chaque requête utilisateur révèle ce qui manque dans votre base. Détecter les lacunes (vs simples problèmes de récupération), diagnostiquer les 3 causes et fermer la boucle pour un corpus vivant piloté par l'usage.
Démarrez gratuitement. Premier audit Knowledge Pulse en 60 secondes.
Démarrer gratuitement