Biotech & MedTech · Valider les produits médicaux intégrant de l'IA

En 2020, un modèle d'IA censé détecter le COVID-19 sur des radiographies thoraciques affichait une précision quasi parfaite dans une étude publiée. Il a échoué sur le terrain. La raison : le modèle avait appris à reconnaître quel hôpital avait réalisé l'examen, pas la maladie. Les patients les plus gravement atteints venaient de certains hôpitaux, et l'IA s'est appuyée sur les artefacts des scanners et les marqueurs textuels dans les coins de l'image. Changez d'hôpital, et le modèle s'effondre.

C'est le problème central de la validation des produits médicaux intégrant de l'IA. Un chiffre qui paraît excellent dans un tableur peut masquer un produit qui n'aide personne, ou pire, qui nuit aux patients.

Pourquoi la précision rétrospective trompe

La plupart des validations d'IA commencent de façon rétrospective : vous prenez un jeu de données historique de cas labellisés (disons 50 000 mammographies avec issues connues) et vous mesurez la qualité de prédiction du label par le modèle.

La métrique mise en avant est souvent l'AUC (Area Under the Curve), un chiffre unique allant de 0,5 (hasard) à 1,0 (parfait) qui résume la capacité d'un modèle à séparer les cas positifs des négatifs. Une IA diagnostique annonçant une AUC de 0,95 impressionne.

Mais l'AUC rétrospective est fragile pour trois raisons.

1. Le modèle peut tricher en prenant des raccourcis

Comme dans l'exemple du COVID, les modèles s'accrochent à des corrélations fallacieuses : des caractéristiques qui suivent l'issue dans vos données sans être la maladie. Une IA de dermatologie a un jour appris que les lésions cutanées photographiées avec une règle à côté étaient plus souvent malignes, parce que les médecins marquaient les lésions suspectes pour les mesurer. C'était la règle, pas la lésion, qui guidait la prédiction.

2. Votre jeu de test n'est pas le monde réel

Les jeux de données rétrospectifs sont sélectionnés. Ils excluent souvent les cas ambigus, les images de mauvaise qualité ou les présentations rares, précisément les cas qui font trébucher les cliniciens et où l'IA est censée aider. La performance sur des données propres surestime la performance dans le désordre de la clinique.

3. La précision masque qui est lésé

Un modèle peut être précis à 95 % globalement et rester dangereux pour un sous-groupe. Les métriques agrégées diluent les échecs concentrés sur des populations spécifiques.

Validation prospective : le test plus dur, plus vrai

La validation prospective consiste à tester l'IA sur de nouveaux patients au fil de leur arrivée, dans le workflow clinique réel, avant de connaître l'issue. C'est le gold standard.

La différence est nette. Une étude sur l'oxymétrie de pouls fournit une analogie utile : des dispositifs validés majoritairement sur des patients à peau claire ont ensuite été trouvés surestimer l'oxygène sanguin chez les patients à peau foncée, un écart que les données rétrospectives de laboratoire masquaient et que l'usage prospectif en conditions réelles a révélé. La FDA a depuis publié un projet de guidance sur la précision des oxymètres de pouls selon la pigmentation cutanée.

Pour l'IA, la FDA distingue les preuves rétrospectives et prospectives dans son examen du Software as a Medical Device (SaMD) : un logiciel destiné à remplir une fonction médicale sans faire partie d'un dispositif matériel. Les données prospectives pèsent bien plus lourd pour une autorisation.

À quoi ressemble un essai diagnostique prospectif

Prenons une IA hypothétique qui signale une rétinopathie diabétique (atteinte oculaire liée au diabète) à partir de photos rétiniennes :

1. Recruter une cohorte prospective. De vrais patients dans de vraies cliniques, photographiés avec les appareils de la clinique, pas un dispositif de qualité recherche.
2. Verrouiller le modèle. Pas d'ajustement des poids après avoir vu les résultats. Le modèle est figé avant l'essai (un algorithme verrouillé).
3. Définir le standard de référence. Qu'est-ce qui compte comme vérité terrain ? Souvent un panel de spécialistes, parfois avec arbitrage en cas de désaccord.
4. Mesurer sensibilité et spécificité, pas seulement l'AUC. La sensibilité est la part des vrais cas détectés. La spécificité est la part des patients sains correctement écartés. Un outil de dépistage qui rate la maladie (faible sensibilité) est dangereux ; un outil qui sur-signale (faible spécificité) submerge les spécialistes de fausses alertes.
5. Rapporter par sous-groupe. Ventilé par âge, sexe, origine, type d'appareil et site.

C'est à peu près le chemin suivi par la première IA autonome de rétinopathie diabétique pour obtenir son autorisation FDA : une étude prospective sur des sites de soins primaires, pas une extraction rétrospective de dossiers.

Analyse par sous-groupe : là où les produits cassent

Les chiffres agrégés mentent par omission. L'analyse par sous-groupe décompose la performance par population pour repérer les échecs cachés.

Prenez une IA de cancer de la peau entraînée surtout sur des peaux claires. La sensibilité globale peut afficher 90 %. En la décomposant, vous pourriez trouver une sensibilité élevée sur peau claire et bien plus faible sur peau foncée, où les images d'entraînement étaient rares. La moyenne masque une faille de sécurité pour toute une population.

Sous-groupes à toujours vérifier :

• Démographie : origine, sexe, âge.
• Appareil et site : différentes marques de scanners, hôpital vs cabinet.
• Sévérité de la maladie : fonctionne-t-il sur les cas précoces, subtils, ou seulement sur les cas évidents ?
• Comorbidités : patients cumulant plusieurs pathologies.

Une règle utile : si un fournisseur ne vous montre qu'un seul chiffre de précision, demandez la ventilation par sous-groupe. S'il ne peut pas la fournir, la validation est incomplète.

🎬 [VIDEO: "How AI Bias Happens in Healthcare" - youtube.com - une explication claire de la façon dont des données d'entraînement biaisées produisent une performance clinique inégale]

Dataset shift : le modèle qui vieillit mal

Même un modèle bien validé se dégrade avec le temps. Le dataset shift (ou data drift) désigne le cas où les données vues par le modèle en production diffèrent de celles sur lesquelles il a été entraîné.

Trois variantes comptent en medtech :

• Covariate shift : les entrées changent. Un hôpital achète de nouvelles IRM aux caractéristiques d'image différentes.
• Label shift : la prévalence de la maladie change. Un modèle de saison grippale se comporte différemment hors saison, ou un nouveau variant émerge.
• Concept shift : la relation elle-même change. Des recommandations cliniques mises à jour redéfinissent ce qui compte comme « positif ».

Un modèle de prédiction du sepsis déployé dans un système de santé a ensuite été évalué en externe et s'est révélé bien en dessous des chiffres annoncés, en partie parce que les pratiques et populations locales différaient du site de développement. Le modèle n'a pas changé ; le monde dans lequel on l'a déposé, si.

Surveiller le shift en production

Vous ne validez pas une seule fois. Vous surveillez en continu. Un contrôle simple au niveau de la population compare la distribution des entrées et sorties du modèle dans le temps.

# Simple drift check: compare score distributions across time windows
from scipy.stats import ks_2samp

# baseline_scores: sorties du modèle sur la période de validation
# current_scores: sorties du modèle sur les 30 derniers jours
statistic, p_value = ks_2samp(baseline_scores, current_scores)

if p_value < 0.01:
    print("Distribution shift detected: trigger clinical review")

Cela signale le moment où les prédictions du jour ne ressemblent plus à la baseline validée. Cela ne vous dit pas que le modèle a tort, mais cela vous dit d'aller regarder.

Les régulateurs l'attendent désormais. Le cadre de la FDA sur le Predetermined Change Control Plan (PCCP) permet aux fabricants de préspécifier comment un modèle d'IA peut être mis à jour et re-validé au fil du temps, en reconnaissant que ces produits ne sont pas statiques.

Synthèse : une checklist de validation

Quand vous évaluez un produit médical intégrant de l'IA, que ce soit comme acheteur, investisseur ou responsable produit, passez en revue ces questions :

1. Les preuves sont-elles prospectives ou rétrospectives ? Le rétrospectif est un point de départ, pas une preuve.
2. L'algorithme était-il verrouillé avant le test ? Un réglage a posteriori gonfle les résultats.
3. Quel est le standard de référence ? Une vérité terrain faible plafonne la confiance que vous pouvez accorder à n'importe quelle métrique.
4. Où est la ventilation par sous-groupe ? Exigez sensibilité et spécificité par population et par appareil.
5. La population d'entraînement correspond-elle à mes patients ? Un modèle validé en centres universitaires urbains peut ne pas se transférer aux cliniques rurales.
6. Existe-t-il un plan de monitoring du dataset shift ? Et un plan pour réentraîner ou retirer le produit s'il dérive ?

Un produit qui passe les six est rare. L'essentiel de la due diligence consiste à savoir quelles questions ont été escamotées et ce que cela implique dans votre contexte.

Points clés

• La précision rétrospective est la métrique la plus facile à truquer et la moins prédictive de la performance réelle. Les modèles exploitent les raccourcis, les données sélectionnées et les moyennes pour paraître meilleurs qu'ils ne sont.
• La validation prospective sur de vrais patients dans le workflow réel est le gold standard. Exigez un algorithme verrouillé et un standard de référence clairement défini.
• Les métriques agrégées masquent les échecs par sous-groupe. Décomposez toujours la performance par démographie, appareil, site et sévérité de la maladie avant de faire confiance à un chiffre unique.
• Les produits médicaux d'IA se dégradent. Le dataset shift lié à de nouveaux équipements, à une prévalence qui change ou à des recommandations révisées implique une validation continue, pas ponctuelle. Cherchez un plan de monitoring et de mise à jour.
• Faites correspondre la population d'entraînement à vos patients. Un modèle validé ailleurs est une hypothèse, pas une garantie, jusqu'à ce qu'il soit testé dans votre contexte.