Model risk : quand votre IA se trompe avec assurance

Dans une biotech de taille moyenne, un système de surveillance a un jour repéré une hausse d'événements indésirables « légers » et l'a classée automatiquement sans suite pendant deux semaines. Le modèle de triage faisait exactement ce pour quoi il avait été entraîné. Simplement, il n'avait pas été entraîné sur la nouvelle formulation de dosage déployée ce trimestre-là. Personne ne s'en est aperçu jusqu'à ce qu'un relecteur humain remarque le schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → à la main. Le modèle n'était pas cassé. Il se trompait avec assurance, ce qui est pire.

C'est cela, le model risk : la possibilité qu'un système d'IA en production produise des sorties incorrectes ou trompeuses, en silence, tout en paraissant fonctionner normalement. En pharma, où les modèles interviennent désormais dans la pharmacovigilance (la science de la détection et du suivi des effets indésirables des médicaments), l'appariement de patients aux essais cliniques et les soumissions réglementaires, ce risque est aussi sérieux que le risque clinique ou financier. Il occupe simplement beaucoup moins de temps de parole en comité de direction.

Trois modes de défaillance à nommer avant qu'ils ne vous nomment

Le drift

Le drift, c'est quand le monde réel change mais pas le modèle. Un modèle entraîné sur les rapports d'événements indésirables de 2023 présuppose la formulation du médicament, la population de patients et les schémas de déclaration de cette période. Modifiez le procédé de fabricationfabricationUne hallucination, c'est lorsqu'un modèle d'IA produit une réponse fluide et assurée mais factuellement fausse, inventée, ou non étayée par ses données sources.Voir la définition complète →, ajoutez une nouvelle indication, ou étendez-vous à la population de patients d'un nouveau pays, et les hypothèses du modèle deviennent silencieusement obsolètes.

Deux variantes méritent d'être distinguées :

• Data drift : les propriétés statistiques des données d'entrée changent (nouvelles données démographiques des patients, nouveaux équipements de laboratoire, nouveaux standards de codage comme les mises à jour MedDRA, le dictionnaire médical des affaires réglementaires utilisé pour classer les événements indésirables).
• Concept drift : la relation entre les entrées et les résultats change (une interaction médicamenteuse sans importance l'an dernier en prend une aujourd'hui, du fait d'un co-traitement nouvellement approuvé).

Ni l'un ni l'autre ne s'annonce. Les métriques de précision calculées sur d'anciens jeux de validation restent bonnes longtemps après que la performance réelle s'est dégradée.

L'hallucination

L'hallucination, terme emprunté à la recherche sur les large language models (LLMLLMUn Large Language Model est un système d'IA entraîné sur d'énormes volumes de texte pour prédire et générer du langage, ce qui permet de rédiger, résumer ou répondre à des questions.Voir la définition complète →), désigne une sortie fluide, précise et fausse. Dans la synthèse de narratifs d'événements indésirables, un LLM peut inventer un lien de causalité (« l'éruption cutanée du patient a probablement été causée par le médicament X ») que le rapport source n'étaye pas. Dans l'appariement de patients aux essais, un modèle peut citer un critère d'éligibilité qui ne figure pas au protocole.

C'est dangereux précisément parce que la sortie se lit comme un raisonnement humain soigneux. Un relecteur fatigué qui parcourt 200 résumés de cas générés par IA par jour ne repérera pas toujours un détail fabriqué noyé dans une prose fluide.

Le biais des données d'entraînement

Si les données d'entraînement sous-représentent une population, le modèle sous-performe pour cette population, en silence. Un schéma bien documenté : les jeux de données d'essais cliniques ont historiquement penché vers des participants masculins, blancs et plus jeunes par rapport à la charge de morbidité réelle (voir les recommandations de la FDA sur la diversité dans les essais cliniques pour la réponse réglementaire). Un modèle d'appariement de patients entraîné sur cet historique sera moins bon pour trouver des patients éligibles dans les groupes sous-représentés, et moins bon pour signaler des événements indésirables qui se présentent différemment selon les profils démographiques.

Le biais ne ressemble pas à un message d'erreur. Il ressemble à un taux d'appariement légèrement plus faible pour un sous-groupe, que personne ne remarque parce que personne n'a segmenté le dashboard de cette façon.

Là où ça fait le plus mal : deux cas d'usage

Le triage des événements indésirables (EI). Les équipes de pharmacovigilance utilisent l'IA pour classer les déclarations de cas entrantes par gravité et orienter les cas « graves » vers une déclaration réglementaire accélérée (aux États-Unis, les déclarations accélérées vont à la FDA au titre du 21 CFR 314.80 ; dans l'UE, à EudraVigilance, la base de données de sécurité de l'Agence européenne des médicaments). Un modèle affecté par du drift ou du biais peut classer des cas graves comme courants, retardant une déclaration que les régulateurs attendent sous 15 jours calendaires pour les réactions graves et inattendues. Ce n'est pas un problème d'efficacité. C'est un problème de conformité et de sécurité des patients.

L'appariement de patients aux essais. Des modèles d'IA parcourent les dossiers médicaux électroniques pour trouver les patients correspondant aux critères d'éligibilité d'un essai. Un modèle entraîné majoritairement sur des données structurées issues de centres hospitaliers universitaires peut mal performer sur les dossiers d'hôpitaux de proximité, à la documentation plus désordonnée, excluant systématiquement des patients qui auraient été éligibles et faisant dévier le recrutement des essais par rapport aux populations réelles.

La réponse en matière de gouvernance : nommer avant que cela n'arrive

Les régulateurs rattrapent leur retard. Le discussion paper de la FDA sur l'IA/ML dans le développement du médicament (2023) et, plus largement, son centre de santé numérique posent des attentes en matière de transparence, de monitoring et de supervision humaine, même si des règles contraignantes complètes et spécifiques à l'IA en pharma restent, début 2026, en cours d'élaboration plutôt que pleinement codifiées. Dans l'UE, l'AI Act (entré en vigueur en 2024, avec des obligations échelonnées jusqu'en 2027) classe de nombreux systèmes d'IA liés à la santé comme « à haut risque », ce qui déclenche des exigences de systèmes de gestion des risques, de gouvernance des données, de supervision humaine et de surveillance après mise sur le marché. L'IA de pharmacovigilance tombe vraisemblablement dans cette catégorie à haut risque, compte tenu de son lien avec la sécurité des patients.

La réponse pratique en matière de gouvernance, quel que soit le calendrier réglementaire exact, tient à quelques vérifications concrètes :

1. Model cards et documentation : une trace permanente des données ayant entraîné le modèle, de ses limites connues et de son usage prévu (voir la proposition originale de Model Cards de Google, le modèle sur lequel l'essentiel du secteur a convergé).
2. Monitoring du drift en production : des tests statistiques automatisés comparant les distributions des entrées en production aux distributions d'entraînement, avec alertes, et pas seulement une revue manuelle trimestrielle.
3. Validation human-in-the-loop : aucune classification de triage d'EI ni aucun appariement de patient ne devrait aboutir à une action réglementaire ou à un contact patient sans qu'un humain qualifié puisse la contredire.
4. Audits de performance par sous-groupe : précision, sensibilité et taux de faux négatifs rapportés par sous-groupe démographique, et pas seulement en agrégé.

Une vérification de drift simplifiée, du type de celle qu'une équipe data science ferait tourner chaque mois, ressemble à ceci :

from scipy.stats import ks_2samp

# Compare la distribution d'une variable clé (ex. l'âge des patients)
# entre les données d'entraînement et les données de production du mois dernier
statistic, p_value = ks_2samp(training_ages, production_ages_last_month)

if p_value < 0.01:
    print("Significant distribution shift detected: investigate before trusting outputs")

C'est le test de Kolmogorov-Smirnov, une méthode statistique standard pour comparer deux distributions. Il ne détectera ni l'hallucination ni le biais à lui seul, mais c'est un premier fil-piège peu coûteux contre le drift.

Construire la checklist avant déploiement

Avant qu'un modèle d'IA ne touche au triage d'EI ou à l'appariement de patients en production, une équipe soucieuse de gouvernance doit pouvoir répondre à :

• Provenance : quelles données ont entraîné ce modèle, et représentent-elles notre population de patients actuelle et la formulation actuelle du médicament ?
• Validation : la performance a-t-elle été testée sur un holdout set reflétant le désordre du monde réel (champs manquants, dossiers non anglophones, documentation d'hôpitaux de proximité), et pas seulement sur des données de benchmark propres ?
• Explicabilité : la sortie du modèle peut-elle être rattachée à des entrées précises, pour qu'un relecteur puisse vérifier la cohérence d'un cas signalé plutôt que de lui faire confiance aveuglément ?
• Voie d'escalade : existe-t-il un chemin clair et rapide pour qu'un humain contredise ou arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →ête le modèle si quelque chose semble anormal ?
• Cadence de monitoring : qui est responsable du monitoring du drift, et à quelle fréquence est-il réellement examiné, et pas seulement enregistré ?

Rien de tout cela n'élimine le model risk. L'objectif est de rendre les défaillances visibles et corrigeables rapidement, plutôt que silencieuses pendant deux semaines comme dans le cas de la biotech évoqué en ouverture de cette leçon.

🎬 [VIDEO: "The dangers of AI hallucinations in healthcare" - youtube.com - une courte explication de la façon dont l'IA générative produit du contenu clinique plausible mais faux, et des raisons pour lesquelles les experts métier doivent rester dans la boucle]

Points clés

• Le model risk en IA pharma se manifeste par le drift (le monde change, pas le modèle), l'hallucination (sortie fluide mais fabriquée) et le biais des données d'entraînement (sous-performance silencieuse pour les groupes sous-représentés).
• Le triage des événements indésirables et l'appariement de patients aux essais sont des cas d'usage à enjeux élevés, parce qu'une erreur y retarde une déclaration réglementaire ou fausse la population d'un essai, au lieu de simplement gêner un utilisateur.
• L'AI Act européen traite de nombreux systèmes d'IA de santé comme étant à haut risque, avec des exigences de gestion des risques et de supervision humaine ; côté américain, les attentes évoluent via les guidances de la FDA plutôt que par une règle contraignante unique, à date de 2026.
• Des garde-fousgarde-fousRègles et contrôles qui maintiennent un système d'IA dans des limites sûres, légales et conformes à la marque, en bloquant les sorties et actions hors cadre.Voir la définition complète → concrets existent et coûtent peu au regard du risque : model cards, monitoring automatisé du drift, validation humaine obligatoire et audits de performance au niveau des sous-groupes.
• La discipline centrale consiste à rendre la défaillance visible vite. Un modèle qui se trompe est gérable ; un modèle qui se trompe en silence ne l'est pas.