Mesurer les résultats et conduire l'évaluation post-déploiement

Un service d'urgences déploie un outil IA de détection précoce du sepsis. Six mois plus tard, les infirmières ont discrètement commencé à ignorer ses alertes. Personne ne l'a signalé. Le modèle se déclenche toujours, les dashboards restent au vert, et la facture du fournisseur est toujours payée. L'IA est techniquement « en production » et cliniquement morte.

C'est le mode de défaillance le plus fréquent de l'IA hospitalière : pas une erreur spectaculaire, mais une dégradation lente que personne ne surveille. Cette leçon vous montre comment construire le système de monitoring et d'évaluation qui la détecte.

Pourquoi l'évaluation post-déploiement est différente en santé

Dans la plupart des secteurs, si un modèle se dégrade vous perdez de l'argent. À l'hôpital, vous pouvez nuire à un patient. Cela relève le niveau d'exigence en matière d'évaluation continue, et c'est de plus en plus une attente réglementaire.

Aux États-Unis, la FDA (Food and Drug Administration) réglemente de nombreux outils IA comme SaMD (Software as a Medical Device). Pour les modèles adaptatifs, elle promeut le PCCP (Predetermined Change Control Plan), en substance un plan pré-approuvé décrivant comment un modèle peut se mettre à jour et comment vous allez le surveiller. En Europe, l'EU AI Act (en vigueur depuis 2024, avec des obligations pour les systèmes à haut risque échelonnées jusqu'en 2026 et 2027) classe la plupart des IA d'aide à la décision clinique comme « à haut risque », imposant une surveillance après mise sur le marché et une supervision humaine.

Traduction : l'évaluation continue n'est pas un bonus. C'est le postulat du législateur.

Les trois choses que votre dashboard doit suivre

Un bon dashboard d'IA hospitalière répond à trois questions d'un seul coup d'œil :

1. Est-ce que ça marche cliniquement ? (résultats)
2. Est-ce que les gens l'utilisent ? (adoption)
3. Le modèle est-il toujours valide ? (drift)

Oubliez-en une et vous obtenez l'histoire du sepsis ci-dessus.

1. Impact clinique

Suivez le résultat que l'IA a été achetée pour changer, pas seulement la précision du modèle. La précision est un intrant. Le résultat pour le patient est la finalité.

Exemple : un outil d'alerte sepsis. Ne vous contentez pas de rapporter « AUROC 0,85 ». (AUROC = Area Under the Receiver Operating Characteristic curve, un score de 0 à 1 mesurant la capacité du modèle à séparer les malades des non-malades ; 0,5 équivaut à un tirage à pile ou face, 1,0 est parfait.) Rapportez :

• Le délai entre l'alerte et l'administration des antibiotiques
• La mortalité liée au sepsis par rapport à la baseline
• Les transferts en USI (unité de soins intensifs)

Comparez toujours à une baseline. Bonne pratique : un groupe de contrôle concomitant ou une période pré-déploiement propre. Sans point de comparaison, une baisse du taux de mortalité peut être saisonnière, et non due à votre IA.

2. Adoption

Une IA que les cliniciens contournent ou ignorent ne délivre aucune valeur, quelle que soit sa précision.

Métriques clés :

• Taux d'acceptation des alertes : quelle part des alertes débouche sur une action clinique
• Taux d'override : à quelle fréquence le personnel écarte l'outil
• Volume d'alertes par clinicien et par garde : votre signal précoce de fatigue d'alerte

La fatigue d'alerte est le tueur silencieux de l'IA clinique. Si une infirmière reçoit 40 alertes par garde et que 35 sont du bruit, elle finira par ignorer les 5 qui comptent. Un taux d'override en hausse est souvent le premier signe que votre outil est en train de devenir invisible.

3. Drift du modèle

Le drift signifie que le monde a changé mais pas le modèle. Deux variantes :

• Data drift : les données d'entrée se déplacent. Vous avez installé un nouvel analyseur de laboratoire, et les valeurs de crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éatinine sont rapportées sur une échelle légèrement différente. Le modèle continue de se fier à l'ancienne échelle.
• Concept drift : la relation entre les entrées et le résultat se déplace. Un nouveau protocole de traitement change ce à quoi ressemble un « haut risque ».

Un déclencheur concret : votre hôpital change de fournisseur d'EHR (Electronic Health Record). Les mappings de champs changent du jour au lendemain. Les modèles entraînés sur l'ancien flux peuvent silencieusement se mettre à recevoir n'importe quoi.

Voici un contrôle de drift minimal comparant la distribution des données en production à celle de l'entraînement :

from scipy.stats import ks_2samp

# entraînement vs 30 derniers jours de données live, une variable (ex. âge du patient)
stat, p_value = ks_2samp(train_feature, live_feature)

# Test de Kolmogorov-Smirnov : p_value faible = distributions différentes = drift possible
if p_value < 0.05:
    alert_ml_team("Data drift detected on feature: age")

Exécutez ceci variable par variable, chaque nuit. C'est une assurance bon marché. Pour un traitement open-source plus complet du monitoring de drift, la documentation Evidently AI est un bon point de départ gratuit.

Du pilote à l'échelle : l'échelle d'évaluation

Ne passez pas de la démo au déploiement dans tout l'hôpital. Utilisez des étapes avec des portes, et définissez les critères de sortie de chaque étape *avant* de commencer.

Étape 1 : Pilote silencieux (shadow mode)

Le modèle tourne sur des données réelles mais ses sorties sont masquées aux cliniciens. Vous comparez ce qu'il *aurait* fait à ce qui s'est réellement passé.

Objectif : confirmer la performance technique sur *vos* patients. Un modèle entraîné à Boston peut sous-performer dans une clinique rurale avec une démographie différente. C'est là que vous le détectez à moindre coût, avec un risque patient nul.

Exemple de critère de sortie : AUROC à moins de 0,05 de la promesse du fournisseur sur vos données, sur 60 jours.

Étape 2 : Pilote live restreint

Une unité, de vraies alertes, une supervision humaine rapprochée. Vous mesurez maintenant l'adoption et l'intégration au workflow, ce que le shadow mode ne peut pas montrer.

À surveiller : volume d'alertes, taux d'override et retours des cliniciens. Un modèle peut être précis et échouer ici parce qu'il se déclenche au mauvais moment du workflow.

Exemple de critère de sortie : taux d'acceptation au-dessus d'un seuil convenu et aucun événement de sécurité inexpliqué sur 90 jours.

Étape 3 : Montée en charge par phases

Déployez unité par unité, pas tout d'un coup. Gardez le dashboard actif. Chaque nouvelle unité constitue de fait une mini-validation, car les populations diffèrent selon les services.

🎬 [VIDEO: "Monitoring Machine Learning Models in Production" - youtube.com - une présentation pratique et claire de la détection de drift et des concepts de monitoring ML en production, directement transposables aux déploiements cliniques]

Un contrôle de ROIROIReturn on Investment : le rapport entre le profit net et le coût d'un investissement. Un ROI de 300 % signifie que chaque dollar investi en rapporte 3.Voir la définition complète → simple qui reste honnête

Pas besoin de théorie financière ici. Vous devez savoir si le bénéfice clinique dépasse le coût total d'exploitation de l'IA.

Exemple chiffré (chiffres illustratifs, pas un benchmark) :

Un outil sepsis coûte, tout compris, environ 200 000 USD par an (licence, intégration, temps de l'équipe de monitoring ML). Supposons que votre évaluation attribue de façon crédible à l'outil une réduction de 15 décès par sepsis et 30 journées d'USI évitées par an.

• Coût par résultat suivi : 200 000 / 15 = environ 13 300 USD par décès évité
• Plus 30 journées d'USI libérées, à une estimation de coût américaine couramment citée d'environ 3 000 à 5 000 USD par journée d'USI (estimation, très variable) : 90 000 à 150 000 USD de capacité libérée

L'important n'est pas le chiffre exact. C'est la discipline : rattacher la dépense à un résultat mesuré et attribué, et refuser de compter des bénéfices que votre évaluation ne peut pas réellement soutenir. « Attribué » est le mot difficile. Si vous ne pouvez pas montrer que l'IA a causé l'amélioration (via un groupe de contrôle ou un pré/post avec traitement des facteurs de confusion), vous ne pouvez pas revendiquer le ROI.

Gouvernance : qui surveille le dashboard

Un dashboard sans propriétaire est une décoration. Attribuez la responsabilité explicitement.

• Responsable clinique : porte les métriques de résultats et de sécurité. A l'autorité de suspendre l'outil.
• Équipe data/ML : porte le drift et la performance technique.
• Comité de gouvernance : examine l'ensemble à une cadence fixe (mensuelle le plus souvent) et tranche entre maintien, réentraînement ou retrait.

Fixez des seuils qui déclenchent une action automatique, pas seulement un e-mail :

• Alerte de drift sur une variable clé : l'équipe ML investigue sous 48 heures
• Le taux d'override franchit le seuil : revue clinique du workflow
• Tout signal de sécurité inexpliqué : suspension immédiate en attendant la revue

Cela reproduit la logique de « surveillance après mise sur le marché » qu'attendent aussi bien l'EU AI Act que la FDA. Vous construisez une piste d'audit qui prouve que vous surveilliez.

La décision de retrait

Parfois la bonne réponse est d'éteindre l'IA. Un outil dont le taux d'acceptation s'est effondré, ou dont le drift ne peut pas être corrigé économiquement, est un passif. Décider de retirer un modèle sous-performant est le signe d'un programme mature, pas d'un échec. Intégrez cette option dans votre gouvernance dès le premier jour.

À retenir

• Surveillez trois dimensions ensemble : résultats cliniques, adoption (en particulier les signaux d'override et de fatigue d'alerte) et drift du modèle. Des métriques modèle au vert avec un taux d'override en hausse signifient que l'outil est en train de mourir discrètement.
• Ne revendiquez jamais des résultats que vous ne pouvez pas attribuer. Utilisez une baseline ou un groupe de contrôle ; une baisse du taux de mortalité ne prouve pas que votre IA en est la cause.
• Utilisez des étapes avec portes, du shadow mode à la montée en charge par phases, et définissez les critères de sortie avant le début de chaque étape. Le shadow mode détecte le « ça ne marche pas sur nos patients » avec un risque patient nul.
• Lancez chaque nuit des contrôles de drift automatisés peu coûteux, et routez les alertes vers un propriétaire nommé avec un délai de réponse défini, pas vers un dashboard que personne ne lit.
• Le monitoring post-déploiement est une attente réglementaire, pas une option : PCCP de la FDA pour les SaMD adaptatifs aux États-Unis, et surveillance après mise sur le marché au titre de l'EU AI Act pour l'IA clinique à haut risque en Europe.