Monitoring continu et réponse aux incidents

Le scan qui a dérivé

En 2021, des chercheurs ont documenté un phénomène qui empêche les équipes d'IA en radiologie de dormir : un modèle de radiographie thoracique entraîné dans un hôpital a perdu en précision lorsque l'hôpital a changé de fournisseur de scanner. Pour un humain, les pixels semblaient identiques. Pour le modèle, le monde avait basculé. Rien n'a échoué bruyamment. La sensibilité s'est simplement érodée en silence, un scan après l'autre.

C'est le problème central de l'IA en medtech. Un médicament, une fois approuvé, ne change pas de chimie. Un modèle d'IA se dégrade dès que la réalité s'éloigne de ses données d'entraînement. C'est pourquoi les régulateurs traitent l'IA déployée comme un système vivant à surveiller en continu, et non comme un produit qu'on livre et qu'on oublie.

Cette leçon construit la boucle de surveillance post-market : détection de drift, audit trails, rollback, et les rapports réglementaires que vous déposez quand les choses tournent mal.

Pourquoi les modèles dérivent après le déploiement

Le « drift » signifie que la relation statistique apprise par le modèle ne tient plus. Deux formes comptent :

• Data drift : les entrées changent. Nouveau scanner, nouvelle population de patients, une mise à jour logicielle qui modifie le contraste des images.
• Concept drift : la relation entre les entrées et la bonne réponse change. Un nouveau variant de la maladie, une recommandation diagnostique révisée.

Exemple concret : un modèle de prédiction du sepsis déployé dans des hôpitaux américains s'est révélé, lors d'une validation externe de 2021 (publiée dans JAMA Internal Medicine), bien moins performant que ce que promettait son marketing, en partie parce que les populations locales différaient du set de développement. Le contexte de déploiement n'est pas un détail. C'est tout l'enjeu.

Le cadre réglementaire dans lequel vous opérez

Vous ne pouvez pas concevoir un monitoring sans savoir ce que vous devez déclarer. Nommons les vrais organismes :

• La FDA américaine régule les dispositifs médicaux dotés d'IA comme des SaMD (Software as a Medical Device). La FDA maintient une liste publique des dispositifs médicaux dotés d'IA, qui a dépassé les 1 000 dispositifs autorisés (chiffre FDA, fin 2024). Les obligations post-market passent par le MDR (Medical Device Reporting) : les événements indésirables graves et les dysfonctionnements de dispositifs doivent être déclarés, généralement sous 30 jours.
• Le framework Predetermined Change Control Plan (PCCP) de la FDA (guidance finalisée en 2024) permet de pré-autoriser certaines mises à jour du modèle, afin de réentraîner sans nouvelle soumission, à condition d'avoir défini le protocole de mise à jour en amont.
• Europe : les dispositifs médicaux à base d'IA relèvent du MDR (Medical Device Regulation 2017/745) et de l'EU AI Act (en vigueur depuis 2024, obligations pour les systèmes à haut risque échelonnées jusqu'en 2026 et 2027). La plupart des IA diagnostiques sont classées high-risk, ce qui déclenche des obligations de post-market monitoring, de logging et de supervision humaine. Les Notified Bodies (organismes privés d'évaluation de la conformité, par exemple TÜV SÜD) auditent votre système qualité.

Ce qu'il faut en retenir : le monitoring continu n'est pas une bonne pratique. C'est une obligation légale sur les deux marchés.

Construire la boucle de surveillance

Quatre étapes reliées : détecter, investiguer, agir, déclarer.

1. Détecter : les alertes de drift

Vous surveillez deux choses : les entrées et les sorties.

Le monitoring des entrées compare les distributions de données live à votre baseline d'entraînement. Un outil statistique courant est le Population Stability Index (PSI), qui mesure de combien une distribution s'est déplacée.

import numpy as np

def psi(expected, actual, bins=10):
    # expected = distribution d'entraînement, actual = données live
    e_pct, edges = np.histogram(expected, bins=bins)
    a_pct, _     = np.histogram(actual, bins=edges)
    e_pct = e_pct / e_pct.sum() + 1e-6
    a_pct = a_pct / a_pct.sum() + 1e-6
    return np.sum((a_pct - e_pct) * np.log(a_pct / e_pct))

# Seuils indicatifs (convention du secteur, pas une norme réglementaire) :
# PSI < 0.1  = stable
# 0.1 - 0.25 = décalage modéré, à investiguer
# > 0.25     = drift significatif, escalader
score = psi(training_pixel_intensity, live_pixel_intensity)

Pour un modèle de radiologie, vous pouvez suivre l'intensité moyenne des pixels, les métadonnées de résolution d'image et la répartition des fournisseurs de scanners. Si un nouveau scanner pousse le PSI au-dessus de 0,25, vous recevez une alerte avant que la précision ne chute visiblement.

Le monitoring des sorties observe le comportement du modèle lui-même : distribution de la confiance des prédictions, taux de positifs, et, là où vous disposez d'une vérité terrain, la performance réelle. Si votre modèle signale habituellement 8 % des scans thoraciques comme anormaux et en signale soudain 20 %, c'est un signal avant même que la pathologie ne confirme quoi que ce soit.

La difficulté en médecine : la vérité terrain arrive en retard. Vous ne savez souvent que le modèle s'est trompé qu'après une biopsie, un scan de suivi ou un diagnostic manqué qui remonte des semaines plus tard. Vous vous appuyez donc sur des signaux proxy (confiance, drift des entrées, taux de désaccord des radiologues) comme alertes précoces.

2. Investiguer : l'audit trail

Quand une alerte se déclenche, vous devez reconstituer exactement ce qui s'est passé. Votre audit trail doit capturer, pour chaque prédiction :

• La version et l'identifiant du modèle
• Le hash de l'entrée et les métadonnées clés (dispositif, timestamp, site)
• La sortie et le score de confiance
• Si un humain l'a validée ou l'a écartée

L'EU AI Act exige explicitement un logging automatique pour les systèmes high-risk, conservé pendant toute la durée de vie du dispositif. Ce n'est pas de la bureaucratie optionnelle. Quand un clinicien demande « pourquoi l'IA a-t-elle raté cette tumeur ? », vous devez pouvoir répondre avec la version exacte du modèle et les entrées. Si vous ne pouvez pas reproduire une décision, vous ne pouvez ni la défendre ni la corriger.

Le taux d'override des radiologues est l'un des signaux les plus riches. Si les overrides passent de 5 % à 15 % dans une clinique, cette clinique voit quelque chose que votre modèle gère mal. Loggez-le, segmentez par site, surveillez-le.

3. Agir : les protocoles de rollback

Quand un problème est confirmé, il vous faut une réponse rapide et répétée à l'avance. Empruntez au génie logiciel :

• Versionnez tout. Chaque modèle déployé porte un tag de version immuable. Vous n'écrasez jamais ; vous déployez à côté.
• Rollback = rebasculer le trafic vers la version précédente connue comme bonne. Cela doit prendre des minutes, pas un cycle de nouvelle soumission.
• Canary deployment : diffusez un nouveau modèle sur une petite part du trafic (disons un hôpital, ou 5 % des scans) et comparez son comportement à celui du modèle en place avant le déploiement complet.
• Fallback human-in-the-loop : si la confiance s'effondre, routez ces cas vers un radiologue plutôt que de produire un compte rendu automatique. Une IA dégradée qui délègue est plus sûre qu'une IA qui devine.

Définissez à l'avance votre trigger de décommissionnement : à partir de quelle baisse de performance mesurée retirez-vous complètement le modèle ? Écrivez-le avant la crise, pas pendant.

4. Déclarer : la notification réglementaire

Quand une défaillance de l'IA cause ou pourrait causer un préjudice au patient, la déclaration est obligatoire et encadrée dans le temps.

• États-Unis (FDA MDR) : les fabricants déclarent les décès et blessures graves, ainsi que les dysfonctionnements susceptibles de causer un préjudice s'ils se reproduisent, généralement sous 30 jours calendaires. Les événements nécessitant une action corrective urgente ont une fenêtre de 5 jours. (Délais FDA, à jour en 2025.)
• UE (MDR) : les incidents graves doivent être signalés à l'autorité compétente, généralement sous 15 jours ; un décès ou une dégradation grave imprévue déclenche une fenêtre de 10 jours ; une menace grave et immédiate pour la santé publique impose une déclaration sous 2 jours. (Délais de l'article 87 du MDR.)

Un modèle qui dérive et provoque un diagnostic manqué est déclarable. Notez l'asymétrie : les délais UE peuvent être plus serrés que ceux de la FDA, donc un déploiement mondial s'aligne par défaut sur l'horloge la plus stricte.

Un exemple déroulé

Votre modèle de détection de nodules pulmonaires tourne dans 12 hôpitaux. Le monitoring montre :

• L'hôpital 7 a installé un nouveau scanner CT. Le PSI sur l'intensité des pixels grimpe à 0,31 (au-dessus du seuil de 0,25).
• Le taux d'override des radiologues à l'hôpital 7 passe de 6 % à 14 % en deux semaines.
• Un nodule manqué confirmé, rattrapé plus tard lors d'un suivi.

Séquence de réponse :

1. Alerte déclenchée sur le dépassement de PSI. Investigation via l'audit trail, isolement de l'hôpital 7 et du nouveau scanner.
2. Agir : router les scans de l'hôpital 7 vers une relecture humaine en première lecture (IA en second lecteur seulement). Pas besoin de rollback ailleurs ; le drift est localisé.
3. Déclarer : le nodule manqué est un incident grave. Sous MDR UE, déclaration sous 15 jours. Sous FDA MDR, sous 30.
4. Remédier : si votre PCCP couvre le réentraînement lié au changement de fournisseur de scanner, réentraînez et validez sur les données du nouveau scanner selon le protocole pré-autorisé.

Drift localisé, contenu rapidement, déclaré honnêtement. C'est la boucle qui fonctionne.

Modes d'échec courants

• Ne monitorer que la précision. Le temps que la précision baisse avec une vérité terrain confirmée, des patients ont déjà été affectés. Surveillez les entrées et les proxys.
• Pas de versioning. Vous ne pouvez pas revenir en arrière sur ce que vous ne pouvez pas nommer.
• Mises à jour automatiques silencieuses. Un changement de modèle non loggé est un trou de conformité et de sécurité.
• Ignorer les sous-groupes. Un modèle peut être stable globalement tout en se dégradant fortement pour un hôpital, une catégorie démographique ou un dispositif.

À retenir

• Les dispositifs à base d'IA se dégradent ; surveillez-les comme des systèmes vivants. Le drift (data ou concept) est le résultat par défaut, pas l'exception. La FDA comme l'EU AI Act imposent une surveillance post-market.
• Surveillez les entrées et les proxys, pas seulement la précision. Utilisez le PSI sur les distributions d'entrée, les taux de prédiction et les taux d'override des radiologues comme alertes précoces, car la vérité terrain arrive tard en médecine.
• Loggez tout, de façon immuable. Version du modèle, entrées, sorties, overrides humains. L'EU AI Act exige un logging sur toute la durée de vie, et vous ne pouvez ni corriger ni défendre ce que vous ne pouvez pas reconstituer.
• Répétez le rollback avant l'incident. Tags de version, canary releases, fallback human-in-the-loop et trigger de décommissionnement écrit à l'avance transforment une crise en procédure.
• Connaissez vos horloges de déclaration. MDR UE : incidents graves généralement sous 15 jours (2 jours pour les menaces de santé publique) ; FDA MDR : généralement 30 jours (5 en cas d'urgence). Les déploiements mondiaux s'alignent par défaut sur le délai le plus strict.