L’ISO/TS 24971-2:2026 est un guide d’application de l’ISO 14971 pour les dispositifs médicaux intégrant du machine learning. Le processus de gestion des risques ne change pas, mais il doit être appliqué en tenant compte de risques spécifiques aux données, aux modèles, à la relation homme-machine et au maintien des performances en vie réelle.

L’ISO/TS 24971-2 explique comment utiliser l’ISO 14971 correctement lorsqu’un dispositif apprend à partir de données plutôt que de fonctionner uniquement avec des règles déterministes.

Quels dispositifs sont concernés ?

Le guide vise les MLMD (machine learning-enabled medical devices), c’est-à-dire les dispositifs médicaux utilisant le machine learning. Un MLMD peut embarquer un ou plusieurs modèles et un ou plusieurs algorithmes de machine learning.

Le machine learning désigne une fonctionnalité permettant à un système d’apprendre à partir de données d’entrée, au lieu de suivre strictement des instructions figées. En pratique, le système détecte des patterns dans les données pour, par exemple, produire une prédiction, une classification, une segmentation, une détection ou une recommandation.

Exemples typiques d’applications médicales

• Analyse d’images : détection de rétinopathie, cancer, AVC, pneumothorax
• Aide au diagnostic : classification de lésions cutanées ou histologiques
• Triage clinique : priorisation d’examens radiologiques suspects
• Prédiction de risque : sepsis, détérioration clinique, événement cardiaque
• Segmentation : contourage automatique d’organes ou de tumeurs

Notions IA / machine learning à comprendre

L’ISO/TS 24971-2 introduit un vocabulaire qu’il faut maîtriser, car ces notions deviennent elles-mêmes des objets de risque, de validation et de surveillance.

Notion	Explication utile en gestion des risques
Algorithme de machine learning	méthode qui ajuste les paramètres d’un modèle à partir de données selon un critère donné
Modèle de machine learning	représentation logique qui produit des résultats à partir de données d’entrée ; il est issu de l’entraînement
Entraînement (training)	processus d’ajustement du modèle à partir de données d’entraînement
Données d’entraînement	données utilisées pour construire ou ajuster le modèle
Données de test	données distinctes des données d’entraînement, utilisées pour évaluer les performances du modèle
Biais	différence systématique de traitement entre objets, personnes ou groupes ; dans un DM, c’est un sujet de sécurité et de performance clinique, pas seulement de statistique
Overfitting / surapprentissage	modèle trop ajusté aux données d’entraînement, qui semble performant en développement mais généralise mal sur des données nouvelles
Underfitting / sous-apprentissage	modèle trop simple ou insuffisamment entraîné, incapable de capturer correctement les relations utiles dans les données
Transparence	mise à disposition d’informations appropriées sur le système : performances, limites, hypothèses, sources de données, risques résiduels, protocoles d’étiquetage, etc.
Explicabilité	capacité du système à exprimer, de manière compréhensible, les facteurs importants ayant influencé un résultat ; elle répond à la question « pourquoi ? »

Deux idées doivent être retenues :

1. un modèle ML ne “comprend” pas la clinique ; il apprend à partir des données qu’on lui fournit ;
2. la performance observée pendant le développement ne garantit pas la performance en conditions réelles.

Les axes pour l’analyse des risques des MLDM

Le guide insiste sur plusieurs axes distinctifs pour réaliser l’analyse des risques :

Axe	Impact
Les données deviennent un objet direct de risque	qualité, représentativité, intégrité, anonymisation, stockage, transmission et traçabilité des données ont un impact direct sur la sécurité
Le modèle devient une source de défaillance	surapprentissage, sous-apprentissage, faible robustesse, manque de généralisabilité ou problèmes d’optimisation peuvent conduire à des sorties cliniquement dangereuses
Le biais devient un risque clinique	un modèle peut être moins performant pour certaines populations ou certains contextes d’usage
L’interface homme-machine devient critique	surconfiance, mauvaise interprétation des sorties, charge cognitive, dépendance excessive ou confiance mal calibrée peuvent créer des situations dangereuses
Le dispositif peut évoluer	surveillance des performances, mises à jour, réentraînement et retour à une version antérieure doivent être prévus
Le post-market doit suivre la performance réelle	il ne suffit pas de collecter les incidents ; il faut surveiller la stabilité des performances en usage réel

Apports de l’ ISO 14971-2 par rapport à l’ISO 14971

1. Compétence du personnel

L’équipe de gestion des risques doit comprendre des compétences en :

Domaine	Attendu
Données	qualité, intégrité, confidentialité, représentativité, séparation des données d’entraînement et de test
Machine learning	bonnes pratiques ML, développement de modèles et d’algorithmes, compréhension des limites du modèle
Logiciel	validation, vérification, simulation et test des contrôles de risque
IT / cybersécurité	plateformes, systèmes connectés, confidentialité, intégrité, disponibilité
Usability	compréhension des risques liés à la confiance, à la lisibilité, à l’explicabilité et à la charge cognitive
Clinique	workflow clinique, environnement d’utilisation, signification clinique des entrées et sorties, interactions praticien/patient

2. Plan de gestion des risques

Le plan de gestion des risques doit déterminer si la sécurité dépend de :

Élément à planifier	Ce qui doit être défini
Surveillance de performance	méthodes, processus, indicateurs, données à collecter et à revoir
Mises à jour	conditions de déclenchement, portée, vérifications associées
Réentraînement	critères de déclenchement, fréquence de revue, données utilisées
Maintenance logicielle	modalités de mise en œuvre et de contrôle
Rollback	possibilité de revenir à une version antérieure si nécessaire

C’est un apport majeur du guide : il reconnaît qu’un MLMD peut rester conforme sur le papier tout en devenant moins sûr en pratique si ses performances se dégradent avec le temps ou changent avec de nouvelles données.

3. Contexte d’utilisation, autonomie et usage clinique

Le guide demande d’analyser comment et dans quel contexte le résultat du MLMD est utilisé :

Élément à considérer	Questions de gestion des risques
Population visée	le modèle est-il adapté aux patients réellement ciblés ?
Utilisateurs visés	spécialistes, généralistes, personnel peu formé, patients ?
Environnement d’utilisation	domicile, laboratoire, point of care, hôpital, intérieur, extérieur ?
Moment dans le parcours clinique	triage initial, étape intermédiaire, décision finale ?
Rôle de la sortie	information, recommandation, aide à la décision, action automatique ?
Infrastructure disponible	qualité des capteurs, équipements, réseau, systèmes IT ?

Le guide attire aussi l’attention sur le niveau d’autonomie du système :

Dimension	Exemples
Automatisation technique	manuel, semi-automatique, conditionnellement automatique, entièrement automatisé
Autonomie clinique	non autonome, supervisé, conditionnellement autonome, pleinement autonome

4. Données

Dans un MLMD, les données conditionnent directement la sécurité et les performances du dispositif.

Qualité des données

Les caractéristiques suivantes doivent être considérées :

Caractéristique	Pourquoi c’est critique
Exactitude / précision	une donnée erronée ou imprécise peut produire une sortie erronée
Complétude	des données incomplètes peuvent perturber la décision du modèle
Cohérence	des données incohérentes réduisent la fiabilité des sorties
Outliers / atypies	peuvent dégrader fortement le comportement du modèle
Interprétation subjective	particulièrement importante lorsque les données sont annotées par des experts

Gestion des données

Exemples de caractéristiques liées à la sécurité

• bases de données ;
• droits d’accès ;
• conservation et stockage ;
• usage du cloud ;
• anonymisation ;
• manipulation et transmission des données.

Une erreur consiste à traiter ces sujets comme de simples questions d’IT ou de conformité RGPD. Pour un MLMD, ce sont aussi des questions de sécurité du dispositif.

Représentativité et annotation

Un modèle peut être techniquement performant et pourtant cliniquement risqué si :

• les données ne représentent pas correctement la population cible ;
• certains sous-groupes sont sous-représentés ;
• les pratiques locales diffèrent de celles du jeu de données d’origine ;
• l’annotation contient des erreurs ou une subjectivité importante.

Le biais doit donc être analysé comme une possible source de mauvaise performance clinique, voire de dommage.

5. Modèle ML

L’ISO/TS 24971-2:2026 traite explicitement le modèle comme une source possible de risque :

Risque lié au modèle	Explication
Overfitting	le modèle mémorise trop les données d’entraînement et échoue sur des cas nouveaux
Underfitting	le modèle est trop simple ou mal entraîné, donc insuffisamment performant
Non-généralisabilité	le modèle ne conserve pas ses performances hors du contexte de développement
Manque de robustesse	petites variations d’entrée ou de contexte peuvent produire de grandes variations de sortie
Disparition / explosion de gradient	exemples cités dans les caractéristiques liées à la sécurité pour certains développements de modèles

La notion importante est la généralisabilité : le modèle doit rester fiable sur des données nouvelles.

6. Transparence, explicabilité et facteurs humains

Il faut que l’utilisateur puisse comprendre suffisamment ce que produit le système et agir de manière appropriée.

Le guide relie ces notions à l’aptitude à l’utilisation :

Notion	Enjeu pratique
Transparence	fournir des informations appropriées sur les performances, limites, hypothèses, risques résiduels et données utilisées
Explicabilité	aider l’utilisateur à comprendre les facteurs ayant influencé le résultat
Lisibilité / compréhensibilité	éviter les sorties ambiguës ou difficiles à interpréter
Confiance calibrée	éviter la sous-confiance autant que la surconfiance
Charge cognitive	ne pas surcharger l’utilisateur d’informations inutilisables

Il faut examiner :

• si la sortie est non expliquée, partiellement expliquée ou expliquée et comprise ;
• où, quand et comment l’information est affichée ;
• si l’information affichée soutient réellement une maîtrise du risque ;
• si l’utilisateur peut vérifier le résultat ;
• s’il existe un risque de surconfiance, de dépendance ou de mauvaise interprétation clinique.

7. Environnement d’exécution, interopérabilité et cybersécurité

Le guide rappelle que les caractéristiques de sécurité ne concernent pas seulement le modèle, mais aussi son environnement d’exécution.

Domaine	Exemples à prendre en compte
Environnement d’exécution	matériel, logiciel, bases de données, outils, pare-feu, LAN, WAN
Interopérabilité	échanges avec d’autres dispositifs, équipements ou systèmes d’information
Variabilité des entrées	différences liées à la technologie, au site, à l’utilisateur, au cas d’usage ou à l’environnement
Cybersécurité	confidentialité, intégrité, disponibilité des données et du système

Une atteinte à la cybersécurité peut dégrader la performance clinique du MLMD, il ne faut donc pas séparer artificiellement cybersécurité et sécurité du patient.

Le guide mentionne également la nécessité de considérer la protection contre des attaques malveillantes pouvant affecter la disponibilité et la performance du système.

8. Production et post-production

L’ISO/TS 24971-2 insiste fortement sur la surveillance post-market des MLMD. Il s’agit de suivre le maintien des performances en conditions réelles.

Les informations à surveiller peuvent inclure :

Type d’information	Finalité
Performance réelle	vérifier que le modèle reste compatible avec l’usage prévu
Écarts entre développement et terrain	détecter une perte de généralisabilité
Évolution des données d’entrée	identifier un changement de contexte d’utilisation
Signaux de biais	repérer une baisse de performance sur certaines populations
Retours utilisateurs	détecter surconfiance, incompréhension ou mauvais usage
Effets des mises à jour	confirmer que les changements améliorent ou maintiennent la sécurité

Le terme drift est souvent utilisé dans le domaine IA pour décrire ce type de dérive, le guide insiste sur la dégradation de performance en usage réel et sur le décalage entre données d’entraînement et nouvelles données.

En bref

L’ISO/TS 24971-2 complète l’application de l’ISO 14971 pour les dispositifs médicaux intégrant du machine learning.

La gestion des risques doit désormais traiter les données comme un objet direct de sécurité, en évaluant rigoureusement leur qualité, leur représentativité et leur annotation.

Le modèle lui-même devient une source spécifique de défaillance à travers des phénomènes comme le surapprentissage, le sous-apprentissage ou le manque de robustesse et de généralisabilité.

L’analyse ne peut se limiter à l’algorithme : l’usage clinique, le niveau d’autonomie, l’interface homme-machine, l’explicabilité et la calibration de la confiance de l’utilisateur sont des facteurs déterminants du risque.

Enfin, la surveillance post-commercialisation doit impérativement s’orienter vers le suivi continu des performances réelles pour détecter toute dérive ou dégradation face à de nouvelles données.