K-AI
FREN
Demander une démo
SolutionComment ça marcheImpactActualitésPartenaires
FREN
Demander une démo
← Toutes les actualités
Presse · 27 mai 2026 · 12 min de lecture

Le RAG ne résout pas l'hallucination, il la déplace : la contradiction inter-sources

Le RAG ne résout pas l'hallucination, il la déplace : la contradiction inter-sources

Le RAG est le dogme 2026 du déploiement IA en entreprise. Pourtant la production échoue en série — et la cause #1 n'est ni l'embedding ni le LLM.

Le pipeline RAG est devenu un dogme. La production lui répond mal

Quand je rencontre un CTO ou un CDO en 2026, je peux prédire 80 % de la conversation avant qu’elle ne commence. Le pilote LLM a fonctionné. La démo Copilot ou Glean a fait briller le COMEX. Puis l’équipe ingénierie a câblé un RAG « propre » sur le SharePoint, le Confluence, le Drive corporate. Et trois mois après, l’usage stagne. Les utilisateurs reviennent au moteur de recherche interne ou à leur propre extraction Excel. Pourquoi ?

La réponse habituelle, c’est le retrieval. Le chunking n’est pas le bon. L’embedding rate les nuances. Le reranker est trop agressif. Toutes ces hypothèses sont vraies, et elles ont toutes leur correctif. Et pourtant, même quand on les empile, la hallucination revient.

Un ingénieur senior basé à Berlin, Gabriel Anhaia, a publié fin avril une analyse qui agrège plusieurs études indépendantes : 70 à 80 % des déploiements RAG en entreprise n’atteignent jamais la production stable, et dans 73 % des cas l’erreur provient du retriever, pas du générateur. Cette statistique recoupe les chiffres macro de Gartner (au moins 30 % des projets d’IA générative abandonnés après proof of concept, notamment pour cause de qualité de données insuffisante), de Cloudera × HBR Analytic Services (seulement 7 % d’organisations déclarent leurs données « completely AI-ready », 27 % « not very or not at all ready ») et de la couche analyste BCG, S&P Global, McKinsey publiée ces six derniers mois. Le marché RAG enterprise file vers 40 milliards de dollars en 2026 ; il échoue en série.

Je pense qu’il y a une raison plus profonde que le chunking. Et que personne ne nomme.

Le mode de défaillance que les benchmarks ne mesurent pas

Les benchmarks RAG publics — RAGAS, HHEM de Vectara, SimpleQA, le leaderboard hallucination — partagent un présupposé silencieux. Ils évaluent la fidélité d’une réponse à un document. Vectara mesure la faithfulness d’un résumé à son article source. SimpleQA vérifie qu’un claim est ancré ou pas dans le contexte fourni. Ces benchmarks détectent admirablement la pathologie classique : un claim non supporté — l’hallucination canonique du LLM qui invente.

Mais ils ratent une seconde pathologie, plus toxique en production : un claim parfaitement supporté par le document A, et formellement contredit par le document B du même corpus. Vous interrogez un assistant interne sur la procédure de validation d’un contrat fournisseur. Il vous répond, citation à l’appui, en s’appuyant sur la version 2022 de la politique achats. Il a raison de citer ce document. Sauf qu’une circulaire émise en 2024 et restée dans le même répertoire a modifié le seuil. Le retriever ne sait pas que les deux documents se contredisent. Le LLM ne le sait pas non plus. Et l’utilisateur a maintenant entre les mains une réponse plausible, sourcée, et fausse.

Ce mode de défaillance circule depuis quelques semaines dans la communauté praticienne sous des étiquettes diverses — contradictory source amnesia, cross-source incoherence, corpus drift. Un post très diffusé attribue à un audit du 8 mai 2026 le chiffre de 70 % de RAG en production incapables de raisonner sur des paires de sources contradictoires. Nous n’avons pas pu confirmer la source primaire de cet audit côté MLCommons ; nous traitons donc le chiffre comme un signal communautaire qui mérite vérification, pas comme une étude indépendante validée. Mais la pathologie, elle, est réelle — et tous les responsables RAG enterprise que je rencontre la voient en production.

« Claim non supporté » et « claim contredit » : deux pathologies, deux traitements

La confusion entre les deux fait perdre du temps à tout le monde. Distinguons.

Un claim non supporté, c’est une affirmation que le LLM produit sans qu’aucun document du contexte ne l’ancre. C’est un défaut de génération ou un défaut de retrieval (le bon document n’a pas été retrouvé). Le correctif standard est connu : ré-ancrer le claim sur une citation, durcir le reranker, baisser la température, ajouter un garde-fou fact verification. C’est ce que Pryon décrit comme la self-verification loop et que Glean, Sinequa, Squirro vendent sous différents noms. Ça fonctionne. Pryon revendique 99 % d’accuracy sur contenu client quand le RAG est correctement architecturé. Ce n’est pas une fiction.

Un claim contredit, c’est autre chose. Le claim est ancré — souvent sur une citation impeccable. Sauf qu’un autre document du même corpus, parfois dans le même répertoire, dit l’inverse. Le retriever ne voit pas la contradiction parce qu’il optimise la similarité requête-document, pas la cohérence inter-documents. Le LLM ne la voit pas non plus parce qu’on lui injecte le document A, pas la paire (A, B). Aucune boucle de self-verification au runtime ne va spontanément aller chercher B. Le système est conçu pour répondre, pas pour douter.

Le seul moment où la contradiction (A, B) peut être détectée, c’est avant le pipeline RAG. Sur le corpus statique. Comme une propriété mesurable.

Détecter une contradiction documentaire à l’échelle exige autre chose qu’un cosine

C’est là que les méthodes habituelles touchent leur plafond. Un cosine entre embeddings repère des documents similaires, pas des documents en conflit. Deux versions d’une politique achats vont être hyper-similaires sémantiquement — elles parlent de la même chose — mais leur point critique (le seuil de signature passé de 50k€ à 100k€, par exemple) sera noyé dans le bruit vectoriel. La contradiction est dans le détail, pas dans la sémantique globale.

Détecter ce type de divergence demande deux choses qu’aucun stack RAG vanille ne fournit nativement : une extraction structurée de claims atomiques (et pas de chunks de 512 tokens), et un graphe sémantique qui relie ces claims entre eux pour qu’on puisse interroger, à l’échelle du corpus, l’ensemble des paires (claim_A, claim_B) où A et B portent sur la même entité et divergent sur la valeur. C’est ce que K-AI appelle son Neural Semantic Graph, et c’est précisément ce que nous instruisons en amont du déploiement RAG d’un client. Sur le seul premier diagnostic d’un référentiel documentaire d’un grand groupe européen, nous remontons typiquement plusieurs centaines de conflits inter-documents que le client n’avait jamais vus, dont une fraction non triviale porte sur des données critiques (seuils, signatures, périmètres de responsabilité, dates d’effet).

Cette détection n’a pas vocation à remplacer le retrieval — elle le précède. C’est de l’audit corpus, pas de l’audit pipeline. Et tant que cette pré-condition n’est pas instruite, on patche au runtime un problème qui n’est pas au runtime.

Auditer le corpus, ce n’est pas auditer le pipeline

C’est probablement le point le plus mal compris du marché 2026. La quasi-totalité des annonces concurrentes des dernières semaines — Glean ADLC (Enterprise Agent Development Lifecycle, 12 mai), Camunda ProcessOS (20 mai), Pinecone Nexus, ServiceNow Otto AI Control Tower — durcissent la couche d’orchestration et de gouvernance d’agents. Ils mesurent le comportement d’un agent en production, ils journalisent ses appels, ils rejouent ses traces. C’est utile et nécessaire. Ce n’est pas suffisant.

Aucun de ces outils n’audite le corpus statique avant que les agents ne tournent dessus. La question « combien de contradictions internes contient mon corpus, et lesquelles sont critiques ? » n’a pas de réponse dans Glean ADLC, dans ServiceNow AI Control Tower, dans Camunda ProcessOS. Elle est en dehors de leur périmètre. Le RAG vanille ne se la pose pas davantage. Cette question relève d’une couche distincte — celle que nous avons appelée Document Knowledge Platform — qui se loge entre les sources documentaires et les couches Knowledge AI (Copilot, Glean, Rovo) qui s’en servent.

Start Clean, Stay Clean : ce que ça veut dire concrètement pour un CTO en 2026

Je ne crois pas qu’on règle un problème de corpus avec un patch runtime. Je ne crois pas non plus qu’on l’éradique une fois pour toutes en faisant un audit one-shot et en passant à autre chose. Un corpus enterprise vit. Les versions s’accumulent, les politiques sont mises à jour sans déprécier explicitement les anciennes, les contributeurs partent et leurs documents restent. La dette documentaire se reconstitue.

Pour un CTO qui prend en main un programme RAG en 2026, je vois trois actions concrètes. La première, c’est l’audit corpus en pré-condition. Pas une checklist de conformité, un diagnostic mesurable — combien de paires contradictoires sur les entités métier critiques, combien de doublons divergents, combien de documents obsolètes non marqués comme tels. La méthode, nous l’avons publiée en six axes il y a deux semaines ; le deuxième axe traite précisément des conflits inter-documents. La deuxième action, c’est le monitoring continu — Stay Clean — qui détecte automatiquement les contradictions au moment où elles entrent dans le corpus, pas six mois après. La troisième, c’est de positionner cette couche dans la pile architecturale du programme IA, comme un composant à part entière entre les sources et les consumers, avec son budget et son ownership. Pas un pré-requis flou, un composant.

Ce que j’observe sur le terrain, c’est que les programmes RAG qui passent réellement le cap de la production sont ceux dont le CTO et le CDO ont accepté que l’audit corpus n’est pas optionnel. Ils gagnent six à douze mois sur les autres. Pas parce qu’ils ont un meilleur modèle. Parce qu’ils ont un meilleur substrat.

Foire aux questions

Pourquoi un RAG hallucine-t-il malgré la récupération de documents ?

Parce qu’il existe au moins deux pathologies distinctes derrière le mot « hallucination ». La première est le claim non supporté : le LLM produit une affirmation sans qu’aucun document du contexte ne l’ancre. Les correctifs standards — reranking, fact verification, citations forcées — ciblent celle-là. La seconde est le claim contredit : le LLM s’ancre correctement sur un document du corpus, mais un autre document du même corpus le contredit. Ce mode-là n’est pas détectable au runtime parce qu’un seul des deux documents est injecté dans le contexte. Tant que le corpus contient des contradictions internes non instruites, le RAG continuera de produire des réponses plausibles, sourcées et fausses, quels que soient les correctifs aval.

Quelle différence entre une contradiction inter-sources et un claim non supporté ?

Un claim non supporté est une invention ou une déduction non ancrée. Le système répond ce qu’il croit savoir, sans citation valable. C’est un défaut de chaîne génération + retrieval. Une contradiction inter-sources est un défaut de cohérence du corpus lui-même : deux documents portent sur la même entité (même politique, même seuil, même responsable, même date d’effet) avec des valeurs divergentes. Le RAG ne distingue pas les deux situations parce qu’il optimise une métrique de similarité, pas une métrique de cohérence. Les traiter de la même manière revient à ignorer la moitié du problème.

Comment détecter automatiquement une contradiction documentaire à l’échelle ?

Une similarité vectorielle ne suffit pas : deux versions d’une même politique sont sémantiquement proches, c’est précisément leur point de désaccord (un chiffre, une date, un seuil) qui les sépare, et ce point est noyé dans le bruit du cosine. La détection passe par une extraction structurée de claims atomiques rattachés à des entités métier (politique, seuil, responsable, date), puis par l’interrogation systématique du graphe sémantique pour identifier toutes les paires de claims qui portent sur la même entité et divergent sur la valeur. C’est ce qu’instruit le Neural Semantic Graph de K-AI en amont du déploiement RAG. La sortie n’est pas une liste d’alertes brute : c’est un livrable priorisé selon la criticité métier — toutes les contradictions ne se valent pas.

Le RAG résout-il vraiment le problème de hallucination ou simplement le déplace ?

Le RAG résout une partie du problème — les claims non supportés — et il en déplace une autre. Quand un corpus contient des contradictions internes, le RAG les masque derrière une citation impeccable au lieu de les exposer. La dette documentaire est devenue invisible. C’est ce qui rend le mode de défaillance « contradiction inter-sources » plus toxique en production qu’une hallucination classique : l’utilisateur ne se méfie pas d’une réponse sourcée. Un programme RAG mature traite donc le corpus comme un actif à instruire en amont, pas comme un input passif.

Quels secteurs sont les plus exposés aux contradictions inter-sources ?

Les secteurs régulés et fortement documentés sont structurellement plus exposés, pour trois raisons. D’abord, ils accumulent des versions successives de politiques, procédures, circulaires sans toujours déprécier les anciennes — c’est le cas typique en banque, assurance, énergie, santé. Ensuite, leur charge réglementaire produit des documents redondants — un même seuil de signature peut apparaître dans la politique achats, le manuel de conformité interne, le code éthique, et un référentiel projet, avec des variantes mineures qui deviennent toxiques au moment du déploiement IA. Enfin, le coût d’une réponse fausse y est plus élevé : une mauvaise réponse sur une procédure de validation peut déclencher un incident réglementaire ou un litige.

Pour aller plus loin

Si vous instruisez un programme RAG ou Copilot dans un grand groupe et que vous voulez objectiver la qualité du corpus avant de scaler, nous proposons un diagnostic ciblé sur un référentiel échantillon. Pas une checklist. Un état des lieux mesurable des conflits, doublons divergents, obsolescences non marquées et zones de fraîcheur. Vous repartez avec un livrable utilisable — qu’on travaille ensemble ensuite ou non. Contact : contact@k-ai.ai.

Sources citées

Sur le même sujet

K-AI accompagne déjà CMA CGM, Veolia, PwC, BNP Paribas, TotalEnergies et CEVA Logistics. Partenaires : AWS, Snowflake, Microsoft, Wavestone, Devoteam.

Et chez vous, quel est votre patrimoine documentaire ?

30 minutes avec un fondateur. On audite gratuitement un échantillon de vos documents et on vous montre exactement ce que K-AI détecte.

Demander une démo → Lire d’autres articles