Surveillance de l’IA médicale : organiser le suivi après le déploiement

Lorsqu’un système d’IA est un dispositif médical, la surveillance commence chez le fabricant. Le document MDCG 2025-6, adopté en juin 2025 par les groupes européens des dispositifs médicaux et de l’IA, rappelle que le règlement sur les dispositifs médicaux (article 83) et le règlement sur l’IA (article 72) imposent tous deux au fabricant un système de surveillance après mise sur le marché : collecter et analyser de façon systématique les données de performance et de sécurité, évaluer et déclarer les événements indésirables, prendre les mesures correctives nécessaires. Le règlement sur l’IA y ajoute un plan de surveillance qui collecte activement les données de performance pendant toute la durée de vie du système, proportionné à la technologie et à ses risques.

L’établissement n’en est pas dispensé. Le même document précise que les déployeurs doivent surveiller le fonctionnement du système et, le cas échéant, informer le fabricant. Le guide de la HAS et de la CNIL, « Accompagner le bon usage des systèmes d’intelligence artificielle en contexte de soins » (document de travail de février 2026), est explicite : le marquage CE n’exonère pas le déployeur de son obligation de mettre en place une surveillance locale et continue du système en conditions réelles d’utilisation. Il ne dispense pas d’un devoir de vigilance sur place.

Le fabricant voit l’ensemble de ses installations ; l’établissement voit sa population, ses appareils, ses flux et ses équipes. Les deux surveillances se complètent, et la responsabilité ne peut pas se dissoudre entre fournisseur et établissement.

Avant tout tableau de bord, la tâche doit être documentée : ce que fait le système, pour quelle population, à quel moment du parcours, avec quelles entrées et quelle décision humaine à la suite. Cette fiche d’usage est celle qui sert aussi à juger les explications d’un outil, détaillée dans notre article sur l’IA explicable en santé.

Pour la surveillance, elle sert surtout à hiérarchiser. Deux modèles de même précision moyenne peuvent présenter des risques très différents. Un faux négatif dans un outil de tri peut retarder une prise en charge ; un faux positif répété peut saturer l’équipe et entraîner des examens inutiles. La fréquence, la gravité et la détectabilité de l’erreur déterminent ce qu’on suit, à quel rythme et avec quelle réactivité.

Les données d’entrée

Suivez les variables qui conditionnent la sortie : taux de données manquantes, unités, formats, appareils, protocoles, population et provenance. Un changement de capteur, un nouveau site, une mise à jour du dossier patient ou une évolution épidémiologique peuvent éloigner les données de production de celles sur lesquelles le modèle a été testé. Cette dérive des données, et la documentation des jeux de données qui permet de la repérer, sont l’objet de notre article sur la qualité des données de santé.

Les indicateurs doivent rester liés au modèle : mesurer chaque champ disponible crée du bruit. Identifiez les entrées critiques, et les changements connus avant leur mise en production.

La performance du modèle

Lorsque la vérité de référence devient disponible, calculez les métriques adaptées à la tâche, par site, appareil et sous-groupe pertinent, avec des effectifs suffisants et des intervalles d’incertitude. Discrimination, calibration et seuils sont détaillés dans notre article sur la stratification du risque patient.

Le délai d’obtention de la vérité compte. Un diagnostic final peut n’être connu que plusieurs semaines après la prédiction. Le tableau de bord distingue donc les signaux précoces, comme la distribution des scores, des mesures confirmées plus tard. Le guide HAS-CNIL recommande des audits réguliers des cas que le système n’a pas détectés : les faux négatifs sont ceux qu’une surconfiance dans l’outil laisse passer.

L’usage humain

Un outil peut rester techniquement stable et devenir dangereux si les professionnels le suivent aveuglément, l’ignorent ou l’utilisent hors indication. Mesurez l’exposition, le taux d’acceptation, les annulations, les contournements, le temps ajouté et les retours qualitatifs. Le guide HAS-CNIL cite parmi ses exemples d’indicateurs le taux de faux positifs corrigés par l’humain et le taux d’utilisation effective, et demande que le bilan du déploiement repère les contournements, c’est-à-dire l’usage de l’outil pour autre chose que ce qui était prévu.

Le biais d’automatisation et le rejet systématique se cherchent tous les deux. Quand l’outil produit des alertes, leur volume et leur taux de contournement relèvent aussi de la fatigue d’alerte clinique.

L’effet sur le parcours

La performance algorithmique ne prouve pas un bénéfice clinique. Suivez les décisions, délais, examens supplémentaires, événements indésirables, ruptures de suivi et charge de travail, et comparez à une période ou un groupe pertinent lorsque c’est possible. Un gain apparent peut n’être qu’une charge déplacée vers une autre équipe.

C’est la distinction que nous tenons avec MyTwin pour les cliniciens. Le jumeau numérique du patient est analysé en continu et n’alerte le médecin que lorsque c’est nécessaire : il produit un signal, le professionnel prend la décision, et le résultat clinique se mesure à part.

Pour chaque indicateur, fixez une zone attendue, une zone de vigilance et un seuil d’escalade. Décrivez qui vérifie, dans quel délai, avec quelles données, et les options possibles : enquête, restriction d’usage, retour à une version antérieure ou suspension.

Les seuils ne sont pas seulement statistiques. Un incident grave unique peut justifier une action immédiate, quand une variation faible demande une analyse de tendance. La gouvernance distingue aussi les circuits : alerte technique, incident de sécurité, réclamation d’un utilisateur, événement de vigilance réglementaire. Le guide HAS-CNIL rappelle qu’un incident grave lié à un système qui a le statut de dispositif médical se déclare obligatoirement à l’ANSM, et recommande de désigner précisément qui, dans la structure, est chargé de ces déclarations. Pour les systèmes qui n’ont pas ce statut, il propose un circuit de signalement vers le fournisseur et, lorsque le risque clinique est important, une procédure interne d’« algorithmovigilance ».

Prévoir l’arrêt sûr

Le même guide recommande de prévoir la désactivation rapide ou l’arrêt immédiat du système en cas d’incident grave, avec des procédures établies de retour en mode dégradé, qui peuvent être simulées. Les professionnels doivent savoir comment signaler un doute et comment travailler sans l’outil. Une dépendance organisationnelle trop forte peut empêcher la suspension au moment où elle devient nécessaire.

Pour le guide HAS-CNIL, un contrôle local reste pertinent même pour un système marqué CE, afin de repérer des biais propres à la population ou à la configuration technique de l’établissement. Il recommande au minimum un test d’utilisation sur un jeu de données local, avec des cas représentatifs de la population de patients et des cas cliniques atypiques, et de standardiser ces tests pour pouvoir les rejouer, par exemple après une mise à jour conséquente du modèle. Pour un modèle non figé et auto-apprenant, ces contrôles sont à mener de manière régulière, afin de repérer une éventuelle dérive.

Côté organisation, le guide recommande de désigner pour chaque système un référent local chargé du suivi, de la collecte des retours de terrain et du lien avec la gouvernance. Autour de lui, un comité resserré réunit un responsable clinique, un référent qualité ou risques, l’équipe technique et, selon le sujet, le délégué à la protection des données, la pharmacie, le biomédical ou le laboratoire. Chaque indicateur a un propriétaire nommé.

La fréquence de revue dépend du risque et du volume : plus resserrée pour un signal critique ou pendant un pilote, plus espacée une fois l’usage stabilisé. Une mise à jour majeure, un changement d’appareil ou une extension à une nouvelle population déclenchent une réévaluation.

Une performance ne s’interprète pas si l’on ignore ce qui a changé. Conservez la version du modèle, des paramètres, des données de référence, de l’interface et du protocole clinique, et précisez si le modèle apprend après déploiement ou reste figé. Le guide HAS-CNIL recommande une traçabilité complète des mises à jour (date, version, finalité, résultats attendus), accessible aux utilisateurs comme à la direction, des notes de version transmises à l’avance par le fournisseur, un environnement de test si nécessaire, et un contrôle des performances après une mise à jour importante du modèle pour repérer d’éventuelles régressions.

Les plans de changement prédéterminés

Certaines évolutions d’un modèle peuvent être prévues et validées dès l’autorisation. Aux États-Unis, la FDA a publié un guide final, dans sa version d’août 2025, sur ces plans de contrôle des changements prédéterminés pour les fonctions logicielles de dispositifs médicaux reposant sur l’IA : le plan décrit les modifications prévues, la méthode pour les développer, les valider et les mettre en œuvre, et l’évaluation de leur impact. En Europe, le document MDCG 2025-6 indique que des changements prédéterminés par le fabricant et évalués lors de l’évaluation de conformité initiale ne constituent pas une modification substantielle au sens du règlement sur l’IA.

Un tel plan encadre les changements ; il ne remplace pas la surveillance. Les principes communs de la FDA, de Santé Canada et de la MHRA demandent d’ailleurs qu’il prévoie des mécanismes pour détecter, puis annuler ou stopper, un changement qui ne satisfait pas aux critères de performance fixés.

La surveillance mobilise souvent des données de santé. Définissez la base juridique, la finalité, les accès, la durée de conservation et les mesures de sécurité. Utilisez des données agrégées lorsque cela suffit, mais gardez une voie contrôlée pour analyser un incident individuel.

Une surveillance par sous-groupes peut être nécessaire pour repérer des écarts de performance. Elle doit être justifiée, proportionnée et sécurisée. L’absence d’une variable sensible ne garantit pas l’absence de biais, car une variable de substitution peut le reproduire. Dans une étude publiée dans Science, un algorithme sous-estimait les besoins des patients noirs parce qu’il prédisait les dépenses de santé plutôt que la maladie : à besoins égaux, on dépensait moins pour eux.

Ne réutilisez pas silencieusement les données de surveillance pour réentraîner le modèle. La CNIL distingue le développement d’un système d’IA, son déploiement et l’évaluation de son impact une fois déployé, et rappelle que cette évaluation demande des démarches préalables, comme une déclaration de conformité à une méthodologie de référence ou une demande d’autorisation. Des données conservées au-delà de l’étude pour d’autres projets font requalifier le traitement en entrepôt de données de santé.

Un tableau de bord minimal peut contenir :

• le volume d’utilisation, la population et le site ;
• le taux de données manquantes ;
• la distribution des sorties ;
• les faux positifs et faux négatifs confirmés ;
• la performance par sous-groupe pertinent ;
• le taux d’annulation humaine ;
• les incidents et les délais ;
• la version en service ;
• un commentaire sur les changements de contexte.

Chaque indicateur doit répondre à trois questions : que signifie une variation ? Qui vérifie ? Quelle action est possible ? S’il n’y a pas de réponse, l’indicateur est probablement décoratif.