La démo qui ment
Toutes les démos de génération augmentée par récupération marchent, et c'est exactement le problème. Vous téléversez dix PDF propres, posez une question, et l'IA répond avec une citation parfaite. La direction est convaincue. Le budget est validé. Six mois plus tard, le même système, désormais pointé sur dix mille documents réels, cite avec aplomb une politique abrogée en 2022 et rate celle qui s'applique vraiment.
Le RAG — le schéma consistant à récupérer des documents pertinents et à les fournir au modèle avant qu'il réponde — est l'une des techniques les plus utiles de l'IA appliquée. C'est aussi l'une des plus trompeuses à démontrer, parce que la démo teste le modèle alors que la production teste vos données. Le papier fondateur du RAG(lien externe, nouvel onglet) décrivait une architecture élégante. Ce qu'il ne pouvait pas décrire, c'est l'état réel des documents de votre entreprise.
Le RAG est un problème de données déguisé en IA
La qualité d'un système RAG est plafonnée par la qualité de ce qu'il récupère, et la qualité de récupération est plafonnée par vos données. Si le bon document existe en quatre versions légèrement différentes, si la moitié de votre savoir vit dans des fils Slack et des pages Confluence que personne n'a mises à jour depuis 2021, si les contrats scannés sont des images sans texte extractible — aucun modèle ne corrige ça. Il résume simplement la mauvaise source, avec fluidité.
Voilà pourquoi les projets RAG qui passent haut la main l'étape prototype calent en production. Le prototype tournait sur un corpus soigné que quelqu'un avait nettoyé à la main. La production tourne sur le vrai désordre. Un tutoriel RAG de LangChain(lien externe, nouvel onglet) vous donne un pipeline fonctionnel en un après-midi ; il ne vous donne pas des documents propres, dédoublonnés, respectueux des permissions et à jour. Cette partie-là est à vous, et c'est l'essentiel du travail.
Les pannes que personne ne démontre
Les vrais problèmes du RAG n'apparaissent qu'à l'échelle, et ils sont peu reluisants. Le découpage d'abord : découpez trop petit et vous perdez le contexte, trop grand et vous diluez la pertinence, et il n'existe pas de bonne réponse universelle — ça dépend de votre contenu. Vient ensuite le classement de récupération. Quand dix mille documents pourraient correspondre, amener les trois réellement pertinents dans la fenêtre de contexte est un problème de recherche, et la recherche est difficile d'une manière qu'une démo sur dix fichiers ne révèle jamais.
La fraîcheur est le tueur silencieux. Un modèle qui cite avec assurance le tarif de l'an dernier, une politique expirée ou une API dépréciée est pire qu'un modèle qui dit « je ne sais pas », parce qu'il blanchit des données périmées en réponse assurée. Et les permissions deviennent vite dangereuses : si la récupération ne respecte pas qui a le droit de voir quoi, votre assistant serviable devient une fuite de données qui exhibe joyeusement une grille de salaires à qui demande gentiment. Ce sont les mêmes réalités de production que je décrivais dans l'écart entre les démos d'IA agentique et la production — la démo prouve l'idée, pas le système.
Pourquoi cela se reproduit sans cesse
Les équipes sous-investissent dans le travail de données du RAG parce qu'il est invisible en démo et coûteux en réalité. Nettoyer les documents, construire un jeu d'évaluation, câbler les permissions dans la récupération et garder l'index frais sont autant de lignes ingrates que personne n'applaudit en comité. Alors on les saute, et le raccourci devient une dette qui s'accumule — la version à l'ère de l'IA de la dette technique qui se cache derrière la production rapide. Le système paraît fini parce qu'il répond. Savoir s'il répond correctement est une question que la démo n'a jamais posée.
Il y a aussi un trou de mesure. La plupart des équipes ne peuvent pas vous donner leur précision de récupération, parce qu'elles n'ont jamais construit de moyen de la mesurer. Sans ce chiffre, chaque amélioration est une supposition et chaque régression une surprise signalée par un utilisateur en colère.
Ce qui fait réellement marcher le RAG en production
Faire marcher le RAG, c'est surtout la discipline de traiter la récupération comme une surface produit mesurable, pas comme une boîte noire. Les équipes qui réussissent font bien quelques choses ingrates :
- Construire un jeu d'évaluation de vraies questions aux réponses connues, et mesurer la précision de récupération séparément de la qualité de génération — si le bon extrait n'a jamais été récupéré, le modèle n'avait aucune chance.
- Investir d'abord dans l'hygiène des données : dédoublonner, retirer les documents périmés et corriger l'extraction des sources scannées ou brouillonnes avant d'accuser le modèle.
- Appliquer les permissions au moment de la récupération, pour que le système ne puisse exposer que ce que l'utilisateur courant a le droit de voir.
- Suivre la fraîcheur explicitement, et expirer ou réindexer le contenu selon un calendrier au lieu d'espérer qu'il reste à jour.
C'est le cœur pratique de l'argument que je faisais dans l'IA générative pour les product owners : l'avantage concurrentiel, ce sont vos données proprement récupérables, pas le modèle que tout le monde loue aussi.
Le Takeaway
Avant d'approuver un nouveau projet RAG sur la foi d'une démo, posez une seule question : quelle est notre précision de récupération sur de vraies questions face à de vrais documents ? Si personne ne peut répondre, vous n'avez pas encore de produit RAG — vous avez une démo RAG, et la différence, ce sont les six mois de travail de données que tout le monde veut sauter.
