Pourquoi 90 % des projets RAG échouent ?
Le RAG s’est imposé comme l’une des architectures les plus utilisées pour connecter un modèle de langage à une base de connaissances. Sur le papier, la promesse est séduisante : fournir au LLM des documents externes pour améliorer la pertinence, limiter certaines hallucinations et produire des réponses mieux contextualisées.
Dans la pratique, beaucoup de projets RAG ne dépassent pas le stade de la démo convaincante. Ils fonctionnent bien sur quelques questions préparées, puis montrent rapidement leurs limites dès qu’ils sont confrontés à des usages métier réels. Réponses partielles, mauvais extraits remontés, sources contradictoires, coûts mal anticipés, corpus mal structuré : l’échec vient rarement d’un seul facteur.
Le problème n’est donc pas seulement technologique. Un projet RAG n’est pas qu’un sujet de modèle. C’est un sujet de qualité de donnée, de recherche d’information, de gouvernance documentaire, d’orchestration et de fiabilité opérationnelle.
Le RAG échoue souvent parce que la base documentaire est mauvaise
Avant même de parler de LLM, de vectorisation ou de prompt, il faut regarder la matière première du système : les documents. C’est là que beaucoup de projets se fragilisent dès le départ.
Dans de nombreuses entreprises, la connaissance interne est dispersée entre des PDF mal extraits, des documents obsolètes, des doublons, des pages contradictoires, des conventions de nommage incohérentes ou des contenus sans hiérarchie claire. On demande ensuite au système de répondre proprement à partir d’un ensemble qui, lui, n’a jamais été structuré pour cela.
Le RAG ne transforme pas magiquement un chaos documentaire en base de connaissance fiable. Il exploite ce qu’on lui donne. Si la documentation est floue, fragmentée ou incohérente, la réponse finale héritera forcément de cette faiblesse. Le système pourra sembler crédible dans la forme tout en étant fragile dans le fond.
Le vrai problème vient souvent du retrieval, pas du modèle
Quand une réponse RAG est mauvaise, beaucoup d’équipes accusent immédiatement le modèle. Elles changent alors de LLM, ajustent le prompt ou tentent d’optimiser la température. Pourtant, dans un grand nombre de cas, le problème se situe plus en amont : le système n’a tout simplement pas retrouvé les bons extraits.
Le retrieval est la colonne vertébrale du RAG. Si les passages remontés sont incomplets, trop faibles, trop génériques ou noyés dans du bruit, le modèle ne peut pas produire une réponse réellement fiable. Même un très bon LLM ne compense pas un contexte médiocre. Il reformule ce qu’il reçoit, mais il n’invente pas la bonne information.
C’est ce qui rend de nombreux POC trompeurs. Sur un petit jeu de tests, avec un corpus propre et des questions préparées, le système paraît robuste. Dès qu’on passe sur des formulations naturelles, des requêtes plus ambiguës ou des questions transverses, les failles du retrieval apparaissent très vite.
Un mauvais chunking dégrade tout le pipeline
Le chunking est encore trop souvent traité comme un simple paramètre technique, alors qu’il influence directement la qualité du retrieval et donc la qualité des réponses.
Découper trop petit fait perdre le contexte. Découper trop large ajoute du bruit. Découper sans logique métier mélange des éléments qui n’auraient jamais dû être rapprochés. Dans tous les cas, le système devient moins précis.
Il faut garder une idée simple en tête : le modèle ne lit pas vos documents dans leur ensemble. Il lit uniquement les fragments qui lui sont envoyés. Si ces fragments sont mal construits, mal contextualisés ou mal délimités, le RAG devient instable. Il peut sembler correct sur quelques cas simples, tout en restant structurellement fragile.
Beaucoup de projets RAG sont pensés comme des démos, pas comme des produits
Un projet RAG impressionne vite. C’est d’ailleurs l’une des raisons pour lesquelles il est souvent adopté trop rapidement. Une démo bien mise en scène suffit à donner l’impression que le problème est presque résolu.
Mais un usage métier réel n’a rien à voir avec une démonstration. Les utilisateurs posent des questions incomplètes, approximatives, implicites, parfois contradictoires. Ils utilisent un jargon interne. Ils attendent du système qu’il comprenne le contexte. Ils demandent parfois une réponse là où les documents ne permettent en réalité qu’une hypothèse.
C’est à ce moment-là que le projet révèle sa maturité réelle. Un système pensé pour impressionner en atelier ne tient pas forcément la charge en production. Il commence à mélanger des sources incompatibles, à répondre avec trop d’assurance ou à mal gérer l’incertitude. Beaucoup de projets échouent précisément parce qu’ils ont été conçus pour une démonstration, et non pour un usage robuste dans le temps.
Sans évaluation, un projet RAG avance à l’aveugle
L’un des échecs les plus fréquents consiste à évaluer un RAG au ressenti. On teste quelques réponses, on trouve le résultat plutôt convaincant, puis on considère que le système progresse. C’est insuffisant.
Un projet RAG doit être piloté comme un système mesurable. Il faut suivre la qualité des documents remontés, la pertinence des extraits, la qualité des citations, la capacité du système à dire qu’il ne sait pas, la stabilité face aux reformulations, la latence, le coût par requête et la robustesse après mise à jour du corpus.
Sans cadre d’évaluation, on ne sait pas ce qui s’améliore réellement. On ne sait pas si le gain vient du modèle, du retrieval, du reranking ou simplement d’un cas de test plus favorable. On ne sait pas non plus quand le système commence à se dégrader. C’est pour cela que beaucoup de projets semblent prometteurs au départ puis s’essoufflent rapidement.
Le coût réel du RAG est souvent sous-estimé
Le RAG est parfois présenté comme une approche plus pragmatique qu’un fine-tuning. C’est parfois vrai. Mais cela ne signifie pas qu’il est simple ou peu coûteux à industrialiser.
Le coût réel ne se limite pas aux appels au modèle. Il faut intégrer la préparation documentaire, le nettoyage des contenus, les embeddings, l’indexation, les réindexations, la gestion des droits d’accès, l’observabilité, les tests, la maintenance des pipelines et la supervision continue.
Beaucoup d’organisations découvrent trop tard qu’un assistant documentaire n’est pas un simple module additionnel. C’est un système vivant, qui dépend de la qualité de la connaissance, de sa mise à jour et de sa gouvernance. Si cela n’a pas été anticipé dès le départ, le projet devient vite trop coûteux, trop flou ou trop difficile à maintenir.
Un mauvais cadrage métier condamne souvent le projet dès le début
Le RAG est parfois choisi par réflexe, parce qu’il est devenu une référence du moment. Pourtant, toutes les problématiques ne relèvent pas d’une architecture RAG.
Dans certains cas, un moteur de recherche mieux conçu suffit. Dans d’autres, il faut un workflow métier, des règles explicites, une base structurée ou un agent capable d’utiliser des outils. Le vrai sujet n’est pas de mettre du RAG partout. Le vrai sujet consiste à choisir la bonne architecture pour le bon problème.
Quand ce cadrage n’est pas fait sérieusement, le projet devient vite fragile. Il accumule de la complexité sans produire une valeur claire. Il paraît innovant, mais reste difficile à défendre économiquement ou opérationnellement.
Le vrai sujet n’est pas l’IA, c’est la fiabilité
C’est probablement le point le plus important. Un projet RAG n’échoue pas parce que l’IA serait inutile ou immature. Il échoue parce qu’il est traité comme une brique de démonstration au lieu d’être conçu comme un système de production fiable.
Un RAG robuste repose sur plusieurs fondations : une donnée propre, une stratégie documentaire cohérente, un retrieval précis, un chunking bien pensé, une évaluation continue, une gouvernance claire et un objectif métier bien défini. Si l’une de ces briques est faible, l’ensemble perd rapidement en crédibilité.
Le RAG fonctionne très bien quand il est abordé comme une architecture de connaissance. Il échoue presque toujours lorsqu’il est vendu comme un simple add-on d’IA générative branché à la va-vite sur des documents internes.
éviter de se précipiter
Si autant de projets RAG échouent, ce n’est pas parce que la promesse est mauvaise. C’est parce que beaucoup d’entreprises abordent le sujet par le mauvais bout. Elles pensent d’abord au modèle, alors qu’elles devraient commencer par la donnée, la structure documentaire, le retrieval et la fiabilité.
Le vrai critère de réussite n’est pas de produire une réponse impressionnante en démo. C’est de produire une réponse utile, traçable, stable et défendable en production. Toute la différence est là.
Entre un gadget qui parle bien et un système qui apporte une vraie valeur métier, l’écart n’est pas dans le prompt. Il est dans l’architecture.
FAQ sur les RAG
-
Parce qu’il dépend de plusieurs couches techniques et documentaires à la fois : qualité de la donnée, retrieval, chunking, évaluation, gouvernance et cadrage métier. Si une seule de ces briques est faible, la fiabilité globale chute rapidement.
-
Pas toujours. Dans beaucoup de cas, le modèle n’est pas la principale faiblesse. Le problème vient surtout du contexte fourni au modèle, donc de la qualité du retrieval et des documents remontés.
-
Non. Le RAG est utile quand il faut exploiter une base de connaissances évolutive et contextualiser les réponses. Mais certains besoins relèvent davantage d’un fine-tuning, d’un moteur de recherche optimisé, d’un système à règles ou d’une architecture hybride.
-
Il faut commencer par assainir la base documentaire, définir un vrai cas d’usage métier, concevoir une stratégie de retrieval solide, structurer le chunking, mesurer les performances et traiter le projet comme un produit fiable, pas comme une simple expérimentation IA.
