En 2023 et 2024, des dizaines de laboratoires pharmaceutiques ont lancé des POC IA sur leurs corpus de pharmacovigilance. Le scénario type : une démonstration impressionnante, des commentaires enthousiastes. Puis, au moment de passer à la production, le dossier arrive sur les bureaux du DPO et de la Direction Médicale.

Fin de l'enthousiasme. Début des questions.

"Vos données cliniques transitent par quels serveurs ? Dans quel pays ? Sous quelle juridiction ?"

"Si l'IA produit un signal de pharmacovigilance erroné, qui est responsable ?"

"Comment je prouve à un auditeur GxP que cette réponse vient bien du dossier XYZ, section 4.3 ?"

Aucun éditeur RAG cloud n'a de réponse satisfaisante à ces trois questions. Et l'industrie pharmaceutique ne peut pas se permettre de les ignorer.

Le double verrou : souveraineté et opposabilité

Verrou 1 — La souveraineté des données cliniques

Les données issues d'essais cliniques, les rapports de pharmacovigilance, les dossiers AMM — ces données sont couvertes par des obligations RGPD (données de santé), des exigences GxP, des réglementations FDA (21 CFR Part 11) et ICH. Les envoyer vers une API cloud, même avec un DPA signé, crée une chaîne de responsabilité juridique que la quasi-totalité des Directions Juridiques pharmaceutiques refuse d'assumer.

Ce n'est pas de la paranoïa. C'est de la gestion du risque.

Verrou 2 — L'opposabilité réglementaire

Une réponse produite par un RAG générique n'est pas opposable face à l'ANSM ni à l'EMA. Pour qu'une réponse IA soit exploitable en pharmacovigilance, elle doit satisfaire deux conditions :

  1. Provenir exclusivement de documents vérifiés et sourcés
  2. Être reproductible — si je rejoue la même requête demain, j'obtiens la même réponse

Aucun RAG classique ne satisfait ces deux conditions de manière fiable.

Pourquoi 38 % d'hallucinations sur un corpus pharmacovigilance

Un grand groupe pharma européen a partagé les résultats d'un benchmark interne : 38 % de réponses partiellement ou totalement incorrectes de leur système RAG sur des questions de pharmacovigilance. Le projet a été stoppé. Ce chiffre n'est pas une anomalie.

38 % taux d'erreur RAG sur corpus pharmacovigilance — benchmark interne
100 % des réponses traçables au document source avec un réseau de connaissances
ALCOA+ conformité native — attributable, legible, contemporaneous, original, accurate

Trois problèmes structurels expliquent ce résultat :

Problème 1 — La granularité sémantique

En pharmacovigilance, "effet indésirable grave" et "effet indésirable" sont des concepts juridiquement distincts. Pourtant, leurs représentations vectorielles sont très proches — le RAG les confond. "Effet indésirable grave inattendu" (SUSAR) a des obligations de déclaration sous 7 jours. "Effet indésirable non grave" peut attendre le rapport périodique. Confondre les deux dans une réponse IA, c'est un risque réglementaire direct.

Problème 2 — La chronologie des cas cliniques

Un dossier de pharmacovigilance a une structure temporelle critique : une réaction survenue à J+14 ne peut pas être attribuée à la prise de médicament de J+2. La chronologie n'est pas un détail — elle est la causalité. Le découpage en fragments brise cette chronologie : deux fragments d'un même cas peuvent être traités indépendamment, et la relation temporelle qui faisait la preuve de causalité disparaît.

Problème 3 — La connaissance pré-entraînement comme source de contamination

Quand le système RAG ne trouve pas l'information dans les fragments récupérés, le modèle "complète" avec sa connaissance issue de publications scientifiques publiques, de notices médicales, de bases de pharmacovigilance publiques. Cette connaissance est antérieure à votre AMM, à vos études cliniques propriétaires, à votre PSUR. Elle ne reflète pas vos données. Elle les remplace — sans le signaler.

La caractéristique la plus dangereuse : ces hallucinations sont rédigées avec la même confiance que les réponses correctes. Il n'y a aucun signal qui distingue une réponse fondée d'une réponse inventée dans la sortie d'un système RAG.

L'architecture qui satisfait les trois parties prenantes

La solution n'est pas un RAG "amélioré". C'est une architecture fondamentalement différente, reposant sur un principe simple : le modèle de langage traduit la question — le réseau de connaissances (Knowledge Graph) produit la réponse.

Concrètement :

  1. Structuration du corpus. Vos données (AMM, PSUR, études cliniques, signaux PV, données de visite médicale) sont modélisées dans un réseau de connaissances. Chaque entité — molécule, indication, population, événement indésirable, temporalité, décision réglementaire — est un nœud. Chaque relation est un arc typé, traçable à sa source documentaire. La hiérarchie SUSAR → SUSAR grave → SUSAR grave inattendu est encodée explicitement.
  2. Traduction en requête formelle. "Y a-t-il eu des cas d'élévation des transaminases chez des patients > 65 ans sous molécule X depuis 2020 ?" — le modèle transforme cette question en requête formelle sur le réseau, pas en génération de texte.
  3. Extraction factuelle. La requête est exécutée. Les résultats sont extraits directement depuis les nœuds et relations du réseau — pas générés. Chaque résultat est accompagné de sa source : document, section, paragraphe, version, date.

Réponse aux trois questions posées en introduction :

DPO Les données restent 100 % on-premise. Aucun transit vers un tiers. Aucune API externe. Aucune chaîne de responsabilité tierce.
Dir. Médicale Chaque réponse est traçable au paragraphe source. Reproductible. Auditable. La requête peut être relancée et donnera le même résultat.
Auditeur GxP L'architecture est conforme ALCOA+ — Attributable, Legible, Contemporaneous, Original, Accurate. La traçabilité est native, pas ajoutée après coup.

Les cas d'usage qui justifient le ROI en 6 mois

  • Signal de pharmacovigilance — identification automatique d'un pattern dans les déclarations, requête croisée avec l'historique des essais cliniques. Résultat en minutes, traçable, prêt pour l'équipe médicale.
  • Préparation des réponses ANSM / EMA — consolidation automatique des éléments nécessaires depuis le corpus documentaire. L'ossature, les références et les extraits pertinents en quelques minutes plutôt qu'en plusieurs jours.
  • Recherche de précédents — "A-t-on déjà eu un signal similaire sur une molécule de la même classe thérapeutique ?" → le réseau répond en secondes, avec les dossiers pertinents cités.
  • Cohérence dossiers successifs — détection automatique d'incohérences entre le PSUR de l'année N et les données publiées dans les études de l'année N-1. L'EMA exige la soumission du PSUR dans les 70 jours suivant le data lock point — chaque semaine gagnée sur la consolidation compte.

Pour les organisations qui veulent tester sans risquer

Le premier obstacle à l'adoption est souvent : "Comment tester sans exposer nos données réelles ?" Notre approche : nous démarrons avec un corpus représentatif fourni sous NDA, ou avec des données publiques de référence (publications EMA, notices européennes) pour calibrer l'architecture sur votre domaine. La preuve de concept se fait en environnement contrôlé, avec vos équipes, avant tout accès à des données propriétaires.

NDA mutuel possible dès le premier contact.