Le piège du nettoyage : arrêtez de demander au RAG de corriger de mauvaises données
Le fournisseur technologique se retrouve pris dans un cycle coûteux : depuis deux ans, des millions de dollars ont été investis dans des projets pilotes d'intelligence artificielle générative en entreprise, mais la plupart s'arrêtent avant d'atteindre la production. Quand un projet échoue, les responsables techniques accusent d'abord le modèle : fenêtre de contexte trop limitée, latence excessive, capacités de raisonnement insuffisantes. Mais les ingénieurs data qui construisent l'infrastructure de ces systèmes observent une autre réalité : c'est le pipeline de données, et non le modèle, qui porte généralement la responsabilité de l'échec. L'auteur nomme ce phénomène le "piège du nettoyage" (Cleanup Trap), soit la croyance erronée qu'une organisation peut injecter des données legacy fragmentées, incohérentes et non gouvernées dans un orchestrateur de grand modèle de langage (LLM) et se contenter de les "nettoyer" ou de les corriger au niveau de la couche de récupération, la fameuse retrieval-augmented generation (RAG).
Ce constat a des conséquences concrètes pour toute entreprise qui déploie du RAG. Lorsqu'un modèle d'embedding reçoit des données brutes et non validées directement issues de silos opérationnels, l'espace vectoriel résultant hérite du bruit structurel, des doublons et des états contradictoires présents dans les systèmes sources. Si le pipeline sous-jacent souffre d'une dégradation silencieuse, dérive de schéma, champs manquants, synchronisation retardée du change-data-capture (CDC), cette dégradation se propage directement dans la base vectorielle. Un modèle ne peut pas produire une intelligence client fiable si les profils qu'il reçoit sont périmés ou contradictoires selon les couches de stockage. Aucun réglage de prompt, aucun reranking sémantique, aucun ajustement des hyperparamètres vectoriels ne peut compenser un pipeline d'ingestion défaillant. Si la base est compromise, l'application finit par halluciner, exposer du contexte non autorisé, ou simplement échouer à fournir une valeur fiable et reproductible.
Pour sortir de ce piège, l'auteur appelle les équipes data à cesser de traiter la qualité des données comme une étape de post-traitement, et à lui appliquer la même rigueur qu'au traitement transactionnel classique. Cela suppose un virage architectural vers une ingestion de données "zero-trust", des cadres de validation structurés et une détection automatisée d'anomalies avant même que les données n'atteignent la couche d'orchestration IA. Concrètement, cela passe par le durcissement du pipeline d'ingestion, avec des contrôles de schéma appliqués dès l'entrée en flux ou à la couche bronze d'une architecture medallion, plutôt que lors de traitements batch nocturnes tardifs. Cela implique aussi une validation algorithmique à plusieurs niveaux, combinant vérifications structurelles, valeurs nulles, conformité de type, avec un profilage statistique capable de détecter une dérive des données dans le temps. L'enjeu dépasse la seule performance des modèles : il s'agit de repenser la gouvernance des données comme un prérequis, non un correctif, à l'ère de l'IA générative en entreprise.
Ce papier met le doigt sur un mensonge qu'on se raconte depuis deux ans : non, le RAG n'est pas une lessive magique qui rattrape des données pourries. Le vrai goulot d'étranglement des projets IA en entreprise, ce n'est pas la fenêtre de contexte du modèle, c'est la plomberie data en amont, souvent bancale depuis dix ans et jamais traitée comme un sujet sérieux. C'est le genre de vérité qu'on préfère ignorer parce que corriger un pipeline coûte plus cher et prend plus de temps que de changer de modèle.
Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.
