5 Erreurs qui Font Échouer les Projets RAG en Entreprise

Un POC RAG (Retrieval-Augmented Generation) marche en deux semaines. Le mettre en production et le faire tenir six mois, c'est une autre histoire. Sur la trentaine de projets RAG pilotés ou audités à ce jour, les mêmes erreurs reviennent. Et elles ne sont presque jamais techniques.

Industrie, juridique, e-commerce, BTP : les contextes changent, les pièges restent les mêmes. On a vu des projets bien partis dérailler en cours de route, et des projets mal engagés se redresser après correction de trajectoire. Avec le recul, les causes d'échec sont prévisibles, à condition de savoir les chercher au bon endroit.

Ce sont des erreurs de posture, d'approche et de méthode. Voilà ce qu'on a observé, avec des exemples terrain, pour ne pas les reproduire.

Erreur n°1 : Croire que le RAG va répondre à n'importe quelle question

C'est l'erreur la plus répandue, et elle ne vient pas de l'équipe technique. Elle vient d'un décalage entre la perception de l'IA générative et la réalité du RAG.

Un système RAG fait une chose précise : quand un utilisateur pose une question, il récupère les passages pertinents dans une base documentaire, puis un modèle de langage formule une réponse à partir de ces passages. C'est puissant, mais c'est limité au périmètre des documents fournis. Si l'information n'est pas dans les documents, le système ne peut pas la produire. Il peut en revanche halluciner une réponse plausible, ce qui est pire qu'un simple "je ne sais pas".

Le problème, c'est que pour quelqu'un qui découvre l'IA générative, "une IA, ça comprend tout". L'image populaire de ChatGPT crée une attente démesurée. Résultat : quand on déploie un assistant RAG interne, les utilisateurs s'attendent à ce qu'il gère absolument tout, y compris des demandes qui sortent complètement du cadre.

La leçon est simple mais fondamentale : il faut communiquer clairement sur le périmètre du RAG dès le départ. Expliquer ce qu'il peut faire, ce qu'il ne peut pas faire, et donner des exemples concrets de questions qui fonctionnent et de questions qui ne fonctionneront pas.

Ce cadrage en amont change tout. Moins de frustration, moins de déception, et un projet qui part sur des bases saines. C'est moins spectaculaire qu'une démo "magique", mais c'est ce qui fait la différence entre un outil adopté et un outil abandonné.

Et soyons réalistes sur les chiffres. Un RAG n'a pas besoin d'atteindre 100 % de bonnes réponses pour être rentable. À 90 %, on traite déjà 9 demandes sur 10 sans intervention humaine, à condition de prévoir le circuit pour la dixième : un seuil de confiance en dessous duquel le système passe la main à un humain, au lieu de laisser sortir une réponse douteuse. C'est un gain de temps considérable, et c'est suffisant pour générer un ROI positif et mesurable.

Erreur n°2 : Penser que chaque nouveau projet RAG sera simple

Après un premier projet réussi, la tentation est grande de se dire que la méthode est acquise et que le prochain ira vite. C'est un piège classique, et on est tombés dedans nous aussi.

Chaque projet RAG est un projet en soi. Les données changent, les types de questions changent, les formats de documents changent. Ce qui fonctionnait parfaitement sur un corpus de fiches produits bien structurées ne marchera pas sur de la documentation technique avec des tableaux imbriqués dans des PDF.

Le vrai défi, c'est que la complexité n'évolue pas de façon linéaire. Passer de 100 à 1 000 documents, ce n'est pas "10 fois plus de travail", c'est un changement de nature. Le système de recherche doit être plus précis, le découpage des documents plus fin, et les cas limites se multiplient. C'est d'ailleurs ce qu'on détaille dans notre guide sur l'optimisation d'un RAG en production.

On voit régulièrement des entreprises venir nous consulter parce que leur RAG existant ne fonctionne pas. Quelqu'un leur avait promis un déploiement rapide, en quelques jours, sans se poser de questions sur les données. Résultat : des performances sous les 70 %, un outil inutilisé, et un projet à reprendre quasiment de zéro.

Il n'y a pas de raccourci. Un audit IA sérieux en amont, qui prend en compte la nature réelle des données, est le meilleur investissement pour éviter ce scénario.

Erreur n°3 : Sauter l'analyse des données et se lancer directement dans le code

C'est une erreur de développeur, et nous l'avons faite. On reçoit le brief, on connaît l'architecture RAG, on a envie d'avancer. Alors on fonce dans le pipeline : parsing, chunking, embeddings, retriever, prompt. Les habitudes sont là, le code aussi.

Sauf que la première chose à faire, avant d'écrire une seule ligne de code, c'est d'ouvrir les documents du client et de les regarder.

Combien d'estimations complètement fausses on a vues parce que personne n'avait pris le temps d'explorer les données ? On estime "3 semaines" sur la base d'un brief qui dit "on a des PDF". Et quand on ouvre les PDF, on découvre des scans de mauvaise qualité, des tableaux imbriqués, des en-têtes incohérents, des documents de 200 pages sans structure.

La connaissance interne d'une entreprise est souvent dispersée entre des formats hétérogènes, des documents obsolètes, des doublons, des pages contradictoires. On demande ensuite au système de répondre proprement à partir d'un ensemble qui n'a jamais été structuré pour cela.

Une étude de McKinsey sur l'IA générative en entreprise confirme ce que nous observons sur le terrain : la qualité des données est le facteur n°1 de succès ou d'échec des projets d'IA. C'est encore plus vrai pour le RAG, où les données représentent 80 % du travail.

Si les documents sont propres, bien structurés, avec du texte exploitable, le RAG sera relativement simple à mettre en place. Si c'est un mélange de formats hétérogènes, aucun framework ni aucune technologie ne résoudra le problème à votre place.

Ce qu'on fait systématiquement avant de coder

Chez Tensoria, avant chaque projet RAG, nous consacrons au minimum une demi-journée à cette exploration :

• Ouvrir un échantillon représentatif des documents du client
• Identifier les formats (PDF, Word, Excel, HTML, images, scans)
• Vérifier la qualité du texte extractible : un PDF "texte" et un PDF "scan" sont deux problèmes complètement différents
• Repérer les cas problématiques : tableaux, schémas, annotations manuscrites
• Estimer la volumétrie et la fréquence de mise à jour
• Comprendre quelles questions les utilisateurs vont réellement poser, et non celles qu'on imagine qu'ils poseront

C'est cette étape qui permet d'estimer correctement un projet. C'est aussi cette étape que la plupart des équipes sautent. Un premier résultat sur des données qu'on n'a pas comprises ne vaut rien. C'est d'ailleurs l'un des premiers points qu'on aborde dans notre guide de diagnostic IA interne.

Erreur n°4 : Dépendre entièrement d'un framework sans maîtriser le pipeline

LangChain, LlamaIndex, Haystack… les frameworks RAG ne manquent pas. Et ils ont une vraie valeur : ils accélèrent le prototypage et permettent de monter une démo fonctionnelle rapidement.

Le piège, c'est de les utiliser en production sans comprendre ce qui se passe derrière chaque abstraction.

Quand un RAG ne répond pas bien à une question, la première chose à faire est de comprendre pourquoi. Pour cela, il faut remonter chaque étape : le parsing a-t-il bien extrait l'information ? Le découpage a-t-il placé la bonne information dans le bon morceau ? Le retriever a-t-il trouvé les bons passages ? Le prompt était-il bien formulé ?

Quand chaque étape est encapsulée dans une couche d'abstraction, déboguer devient un cauchemar. On passe un temps disproportionné à naviguer dans la documentation du framework, à chercher comment personnaliser un comportement, à contourner des limitations.

Les frameworks sont précieux quand ils encapsulent des calculs complexes qu'on ne veut pas recoder (le deep learning, par exemple). Mais un pipeline RAG repose sur des étapes conceptuellement simples : parser un document, le découper, le vectoriser, chercher les plus proches voisins, construire un prompt. Coder ce pipeline soi-même une première fois est un excellent exercice de compréhension, et cela change durablement la façon dont on approche les problèmes de retrieval.

Sur le long terme, c'est encore plus vrai. De nouvelles techniques sortent régulièrement dans le monde du RAG. Quand on veut les tester, on reste dépendant du framework et de sa capacité à s'adapter. Or, comme le souligne cette synthèse de la recherche sur le RAG publiée sur arXiv, le domaine évolue si vite que les frameworks peinent à suivre le rythme.

Ce conseil s'applique aussi aux agents IA : plus on maîtrise les briques fondamentales, plus on est libre et rapide pour s'adapter.

Erreur n°5 : Ne pas mesurer la performance du RAG dès le début

C'est l'erreur silencieuse. Le RAG est en place, il tourne, les utilisateurs posent des questions, et on a l'impression que "ça marche". Mais est-ce que ça marche vraiment ? À quel point ? Personne ne le sait, parce que rien n'a été mis en place pour mesurer.

On voit trop de projets où la mesure ne commence que quand les retours négatifs arrivent. À ce stade, il n'y a aucune baseline, aucun historique, aucun moyen de savoir si les choses se sont dégradées ou si elles n'ont jamais été bonnes.

Sans mesure, on ne détecte pas non plus les hallucinations. Le retriever remonte des passages même quand aucun n'est pertinent, et le modèle génère alors une réponse confiante mais fausse. Ce phénomène passe inaperçu si on ne le cherche pas activement. C'est pour cela qu'en production, la mesure va de pair avec un garde-fou actif : quand la confiance est trop basse, le système préfère dire qu'il ne sait pas et escalader vers un humain, plutôt que de servir une réponse inventée à l'utilisateur.

Le dataset d'évaluation, l'outil que personne ne construit

La mesure doit commencer dès le premier jour. Pas besoin d'un outil sophistiqué. Un simple jeu de 30 à 50 questions-réponses de référence, passé régulièrement sur le système, suffit à avoir une vision claire de la performance.

Sans ce dataset, chaque modification devient un pari. On change le découpage, on change le modèle d'embeddings, on ajuste le prompt, et on n'a aucun moyen objectif de savoir si c'est mieux ou pire. On se fie au ressenti, à quelques tests manuels. Ce n'est pas suffisant.

Ce qu'on recommande concrètement

• Constituer un dataset d'évaluation dès le début du projet, avec des questions représentatives et les réponses attendues
• Le passer après chaque modification du système pour vérifier qu'on progresse sans rien casser
• Logger les interactions en production pour identifier les vrais cas d'usage et les vrais problèmes
• Suivre un score simple (pourcentage de bonnes réponses) dans le temps
• Tester les cas hors périmètre pour mesurer le taux d'hallucinations et mettre en place des garde-fous si nécessaire

C'est basique, mais c'est ce qui fait la différence entre un projet RAG qui s'améliore dans le temps et un projet qui stagne sans qu'on comprenne pourquoi. C'est aussi ce qui permet de justifier l'investissement auprès de la direction, un sujet qu'on aborde en détail dans notre article sur la mesure du ROI des projets IA.

Selon Gartner, les organisations qui mettent en place des métriques de performance dès le lancement ont un taux de succès significativement plus élevé sur leurs projets d'IA. Ce qu'on ne mesure pas, on ne l'améliore pas.

En résumé : la technique ne suffit pas pour réussir un projet RAG

Ces cinq erreurs, nous les avons toutes commises. L'IA générative donne une impression de magie, et avec cette impression vient la conviction que tout est réalisable rapidement. Même avec des années de pratique, on n'est pas à l'abri de mal estimer un projet, de vouloir aller trop vite, ou d'oublier de mesurer.

Le schéma se répète souvent dans le même ordre :

1. On se lance trop vite sans cadrer le périmètre
2. On ne communique pas assez sur les limites auprès des utilisateurs
3. On sous-estime la complexité et la qualité des données
4. On s'enferme dans un framework sans comprendre le pipeline
5. On oublie de mesurer, et les hallucinations passent inaperçues

Un système RAG n'est pas un produit qu'on installe et qu'on oublie. C'est un système vivant qui demande de la rigueur, de la patience, et surtout une bonne compréhension des données et du besoin métier. La technique vient après. La maintenance d'une solution IA après la livraison est une dimension à anticiper dès le cadrage du projet.

Si vous envisagez un projet RAG ou si vous avez un système qui ne donne pas satisfaction, le bon point de départ est souvent un audit IA pour poser un diagnostic clair avant d'investir davantage.

Questions fréquentes

Pour aller plus loin

• RAG : le guide complet pour l'IA en entreprise
• Optimiser un RAG : de la démo à la production
• RAG vs Chatbot simple : lequel choisir ?
• 3 cas d'usage RAG en entreprise avec résultats concrets
• Lancer un projet IA en entreprise : le guide réaliste
• Cas client : assistant IA industriel avec RAG
• RAG souverain avec Mistral : architecture sécurisée pour données sensibles, 100% hébergée en France.
• Fine-tuner Mistral sur vos données : quand le RAG ne suffit pas et qu'il faut spécialiser le modèle.
• Coût d'un projet RAG en entreprise : budgétiser correctement pour éviter les mauvaises surprises.
• Agentic RAG : l'évolution agentique du RAG pour les cas d'usage complexes.