RAG en Santé : pourquoi la qualité des données fait la différence

L'essor des assistants médicaux pilotés par RAG

Les hôpitaux et cliniques multiplient les expérimentations autour de l'IA générative. Assistant clinique, aide au diagnostic, génération automatisée de comptes rendus, chatbot patient — les cas d'usage ne manquent pas. Derrière ces promesses se cache une architecture devenue standard : le RAG (Retrieval-Augmented Generation).

Le principe est simple : plutôt que de laisser un LLM répondre de mémoire (avec les hallucinations que l'on connaît), on lui fournit un contexte documentaire issu d'une base de connaissance — protocoles cliniques, comptes rendus, référentiels médicaux — et on lui demande de répondre à partir de ces seules sources. En théorie, le RAG élimine le principal défaut des grands modèles de langage : leur tendance à inventer des réponses.

En pratique, le RAG ne vaut que ce que valent les données qu'il indexe. C'est là que le bât blesse dans le contexte hospitalier.

Le maillon faible du RAG en santé : des données fragmentées et non fiables

Une architecture RAG typique repose sur trois étapes : ingestion (collecte et vectorisation des documents), retrieval (recherche du contexte pertinent), generation (production de la réponse). Si l'une de ces étapes est compromise par une donnée de mauvaise qualité, c'est tout le pipeline qui produit un résultat douteux.

En milieu hospitalier, les données souffrent de problèmes bien identifiés :

• Complétude : des champs manquants dans les dossiers patients, des examens non renseignés
• Cohérence : un même concept codé différemment entre deux services (voire entre deux praticiens)
• Actualité : des protocoles obsolètes toujours en ligne, des référentiels non mis à jour
• Traçabilité : des données dont on ignore l'origine, la date de mise à jour ou les transformations subies

Quand un assistant RAG pioche dans un document dont la date de validité est expirée ou dont le contenu est partiellement erroné, il ne le sait pas. Il génère une réponse présentée avec assurance — et c'est cette assurance qui est dangereuse.

Comme le rappelle la Haute Autorité de Santé dans son cadre d'évaluation des dispositifs médicaux numériques, la fiabilité des données sources est un prérequis à toute certification d'outil d'aide à la décision clinique. De même, la stratégie du Espace Européen des Données de Santé (EHDS) insiste sur l'interopérabilité et la qualité des données comme conditions de la réutilisation secondaire pour la recherche et l'innovation.

Trois angles morts critiques

1. La qualité sémantique : des codes qui ne veulent pas dire la même chose

Un même patient peut être codé en CIM-10 dans le DPI, en SNOMED CT dans le laboratoire, et en texte libre dans un compte rendu opératoire. Le RAG indexe ces trois représentations comme des blocs indépendants. Résultat : un assistant qui ne fait pas le lien entre "diabète de type 2", "E11" et "DT2" produit des réponses lacunaires ou contradictoires.

2. La gouvernance des sources : qui décide ce qui entre dans la base ?

Sans politique claire de sélection et de validation des documents alimentant le RAG, le risque est de voir des notes informelles, des projets de protocole ou des données non validées concurrencer des sources officielles. Le standard FHIR (HL7) fournit un cadre de structuration, mais encore faut-il que les données qui y sont conformes soient aussi des données approuvées.

3. L'obsolescence silencieuse

Un protocole clinique mis à jour tous les ans. Une recommandation de la HAS qui évolue. Des référentiels de codage qui changent. Sans système de monitoring de la qualité en continu, la base de connaissance du RAG devient progressivement un mélange de données valides, obsolètes et contradictoires — sans que personne ne s'en rende compte avant l'incident.

Un cadre d'action en quatre temps

Pour qu'un projet RAG en santé tienne ses promesses, la qualité des données doit être traitée comme un prérequis — pas comme un sujet technique relégué à la fin du projet.

Étape 1 — Cartographier les sources

Avant d'ingérer, inventorier : quelles bases, quels formats, quels propriétaires, quels cycles de mise à jour ? Sans cette cartographie, le RAG indexe dans le vide.

Étape 2 — Qualifier les données

Appliquer des règles de qualité systématiques : complétude, conformité aux référentiels, date de validité, origine tracée. Éliminer ou flaguer les données non conformes avant l'indexation.

Étape 3 — Monitorer en continu

La qualité n'est pas un état stable. Un pipeline de data observability (contrôles automatisés, alertes sur dérive) garantit que la base de connaissance reste fiable dans le temps.

Étape 4 — Tracer la provenance

Quand le RAG produit une réponse, l'utilisateur doit pouvoir remonter à la source exacte. C'est non seulement une exigence de confiance, mais aussi un impératif dans le cadre du RGPD et des obligations de traçabilité des décisions médicales assistées par IA.

Ce que cela change concrètement

Prenons un cas réel : un assistant RAG destiné à aider les urgentistes à retrouver des protocoles de prise en charge. Si la base inclut un document de 2019 non mis à jour, et que le protocole a changé en 2023, le RAG ne le sait pas. Il renvoie la procédure obsolète avec le même degré de confiance que pour la procédure correcte.

Un système de data quality pipeline en amont du RAG aurait : marqué le document 2019 comme "obsolète" au moment de l'ingestion, exclu du contexte retrieval les documents hors validité, et alerté l'équipe data qu'un protocole n'a pas été mis à jour dans la base.

C'est exactement le genre de scénario que QALITA adresse : automatiser les contrôles de qualité sur les données de santé, à la source et en continu, pour que les couches applicatives (RAG, reporting, interopérabilité) puissent faire leur travail sur une base fiable.

Donnée fiable, IA digne de confiance

Le RAG en santé n'est pas une question de modèle — c'est une question de confiance dans les données. Sans qualité des données actionnable, industrialisée et suivie dans le temps, l'assistant RAG reste une boîte noire dont on ne sait pas pourquoi, un jour, elle donnera une réponse dangereuse.

Les établissements qui prendront le temps de bâtir une fondation solide — gouvernance, qualité, observabilité — seront ceux pour qui l'IA clinique sera un atout, pas un risque.

Vous déployez ou explorez l'IA générative dans votre établissement ? La question de la qualité des données en amont est souvent le facteur qui distingue un projet pilote réussi d'un échec silencieux. Échangeons sur votre cas d'usage.

Sources

• Espace Européen des Données de Santé (EHDS) — Commission Européenne
• HAS — Cadre d'évaluation des dispositifs médicaux numériques
• HL7 FHIR — Standard d'interopérabilité des données de santé
• CNIL — Règlement Général sur la Protection des Données
• Gartner — Why Data Quality Is Key to AI Success
• Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (arXiv)