RAG isn’t Dead, Yours is!

Toutes les démos de RAG fonctionnent.

C’est en production que la plupart échouent.

Connecter un grand modèle de langage à un petit corpus de documents bien choisis est simple.
Les réponses sont fluides, l’expérience est impressionnante, et les premiers retours très positifs.

Les problèmes commencent lorsque le RAG sort de l’environnement de démonstration.

À l’échelle, la réalité est tout autre :

• des millions de documents
• des sources de données multiples et hétérogènes
• des mises à jour et des versions en continu
• des utilisateurs aux droits et responsabilités différents

C’est là que la majorité des systèmes RAG commencent à se dégrader. Les réponses deviennent obsolètes, la pertinence baisse, la latence augmente et la confiance s’érode.

À ce stade, le diagnostic habituel passe à côté du problème. Le modèle est rarement en cause. Les LLM modernes sont déjà suffisamment performants. Ce qui échoue en production, c’est l’infrastructure de données sous-jacente, pensée pour des démos contrôlées, pas pour la complexité opérationnelle des grandes organisations.

Le RAG n’échoue pas parce qu’il ne sait pas générer. Il échoue parce qu’il ne sait pas récupérer et maintenir la connaissance de manière fiable à grande échelle.

Pourquoi la plupart des pipelines RAG cassent en production

De l’extérieur, les architectures RAG se ressemblent. À l’intérieur, elles s’effondrent pour des raisons très prévisibles.

Ingestion ponctuelle au lieu d’extraction continue

La plupart des pipelines ingèrent les données une seule fois, ou par lots périodiques.

Résultat : des réponses techniquement correctes, mais opérationnellement obsolètes. Dans des organisations en mouvement constant, une connaissance périmée est pire qu’une connaissance absente.

Une confiance fragile à l’échelle

Une seule réponse erronée ou dépassée suffit à faire chuter la confiance. Lorsqu’elle se répète, l’adoption s’arrête. À l’échelle, les erreurs de pertinence ne sont pas des cas limites : elles sont structurelles.

La sécurité devient un point de blocage

Les systèmes RAG qui ignorent les contrôles d’accès, ou les appliquent de façon approximative, sont rapidement bloqués par les équipes sécurité. Si la récupération ne respecte pas strictement les permissions, le projet n’atteint jamais la production.

Explosion de la latence et des coûts

Ce qui fonctionne avec quelques centaines de documents s’effondre avec des milliers. Les stratégies d’indexation, le découpage en chunks et les couches de recherche qui semblaient suffisantes deviennent des goulets d’étranglement. Ce schéma révèle presque toujours un problème d’architecture plus profond.

Le RAG n’est pas une fonctionnalité. C’est une infrastructure.

La plupart des projets RAG en entreprise sont traités comme des fonctionnalités produit : une couche de recherche ajoutée par-dessus, avec l’espoir qu’elle se comporte comme n’importe quelle autre capacité applicative. Cette vision est l’une des principales raisons des échecs en production.

Le RAG est une infrastructure. Il se situe sous les applications d’IA et hérite directement de toutes les contraintes de l’entreprise :

• l’échelle
• l’hétérogénéité des données
• la sécurité
• la gouvernance
• le changement continu

Des architectures pensées comme des fonctionnalités peuvent fonctionner en isolation, mais elles cèdent face aux conditions opérationnelles réelles.

Cette distinction est cruciale. Une infrastructure doit être fiable par défaut, observable en production et sécurisée en permanence. Dans les systèmes RAG, la génération reçoit souvent toute l’attention, alors que le G ne fait qu’amplifier ce que le R fournit.

Quand la récupération est incomplète, obsolète ou mal alignée avec les droits d’accès, la génération produit avec assurance des réponses fausses ou dangereuses.

Un RAG réellement industriel nécessite donc un changement de posture : non pas comment ajouter du RAG à une application, mais comment construire et opérer une couche de récupération et d’extraction capable de soutenir des usages IA dans la durée.

Les contraintes qui font échouer le RAG à l’échelle

Lorsque les systèmes RAG échouent en production, les causes sont rarement spectaculaires. La dégradation est progressive : la pertinence diminue, les réponses vieillissent et la confiance disparaît.

Dans la majorité des déploiements en entreprise, ces échecs proviennent d’un petit nombre de contraintes structurelles systématiquement sous-estimées.

Hypothèses de données statiques

De nombreux pipelines RAG reposent sur une ingestion ponctuelle ou des mises à jour par lots. Cela suppose que les données d’entreprise sont relativement stables. Elles ne le sont pas.

Les documents évoluent, les procédures changent et de nouvelles versions apparaissent en permanence.

Quand l’extraction n’est pas synchronisée avec ces changements, la récupération se déconnecte de la réalité opérationnelle. Le système continue de répondre, mais sur une connaissance dépassée. À grande échelle, c’est un échec assuré.

Données multimodales et découpage

Les premières implémentations RAG fonctionnent sur du texte propre. La production, non.

La connaissance d’entreprise vit dans des scans, des PDF, des tableurs, des présentations, des images et des documents complexes.

Sans OCR et prétraitement adaptés, une grande partie des données reste invisible. Le découpage en chunks ajoute un autre point de rupture :

• trop petit, le contexte disparaît
• trop grand, la pertinence s’effondre

Le chunking n’est pas un simple réglage. C’est un choix d’architecture.

Contrôle d’accès et traçabilité

Le contrôle d’accès est souvent le point d’arrêt des projets RAG. Les moteurs de recherche vectorielle ne comprennent pas les permissions d’entreprise. Si les contraintes d’accès ne sont pas appliquées au moment de la requête, le système est dangereux.

La traçabilité est tout aussi essentielle. Les entreprises doivent savoir :

• d’où vient une réponse
• quels documents ont été utilisés
• quelle version a été consultée

Sans cela, la confiance ne survit pas à la production. Parmi toutes ces contraintes, l’ingestion statique est souvent le premier point de rupture.

De l’ingestion statique à l’extraction continue dans les systèmes RAG

La majorité des pipelines RAG sont construits autour de l’ingestion. Très peu sont conçus autour de l’extraction continue.

Les données d’entreprise sont vivantes :

• les documents évoluent
• de nouvelles versions apparaissent
• les droits d’accès changent
• le contenu croît en continu

Traiter l’extraction comme une étape unique garantit l’échec.

Une architecture RAG prête pour la production nécessite un pipeline :

• continu
• observable
• résilient
• aligné avec la gouvernance

Ce pipeline n’est pas une fonctionnalité, mais un système durable, qui évolue avec l’organisation.

Sécurité, contrôle d’accès et confiance ne sont pas optionnels

Le RAG en entreprise n’existe pas sans gouvernance. Les contrôles d’accès doivent être appliqués au moment de la requête, pas ajoutés après coup. Un système qui donne la bonne réponse au mauvais utilisateur crée du risque, pas de la valeur.

La traçabilité est tout aussi critique :

• D’où vient cette réponse ?
• Quels documents ont été utilisés ?
• Quelle version ?

Sans réponses claires, les systèmes RAG échouent aux audits de sécurité et perdent la confiance des utilisateurs.

En environnement entreprise, la confiance n’est pas émotionnelle. Elle est structurelle.

Comment LightOn construit une infrastructure RAG pensée pour la production, pas pour les démos

LightOn repose sur une observation simple : l’IA en entreprise ne fonctionne que si la recherche et l’extraction fonctionnent d’abord.

La plateforme est conçue comme une infrastructure, pas comme un assistant :

• extraction continue des données, tous formats confondus
• OCR et prétraitement natifs
• découpage sémantique aligné avec les documents d’entreprise
• indexation vectorielle à grande échelle
• contrôle d’accès strict, appliqué au moment de la requête
• reranking pour la précision et la confiance
• déploiement sous contraintes de souveraineté et de conformité

La recherche n’est pas un ajout, c’est la colonne vertébrale.

En plaçant l’extraction continue au cœur du système, LightOn permet de construire des RAG qui restent précis, sécurisés et utilisables lorsqu’ils passent du pilote à la production.

Si vous voulez arrêter de construire des démos RAG et commencer à bâtir une véritable infrastructure RAG 👉 Parlons-en.