Caractériser les risques des logiciels médicaux : que faut-il retenir du guide IMDRF N81 (2025) ?

1. Un nouveau guide pour mieux cerner les risques logiciels

L’essor des logiciels médicaux – qu’ils soient indépendants (SaMD) ou embarqués dans un dispositif – impose une approche renouvelée de leur évaluation. Ce n’est plus simplement le dispositif qui soigne, mais l’information qu’il génère, filtre ou recommande. Et cette information peut elle-même devenir source de risque.

Pour accompagner les fabricants dans cette complexité croissante, l’IMDRF a publié en janvier 2025 un nouveau guide : IMDRF/SaMD WG/N81 FINAL:2025, sobrement intitulé Characterization Considerations for Medical Device Software and Software-Specific Risk.

Ce guide ne se contente pas de rappeler des évidences. Il propose un cadre structurant pour mieux décrire un logiciel médical, identifier les facteurs de risque spécifiques aux logiciels et appuyer les démarches de classification réglementaire ou de gestion des risques.

2. Ce que couvre (et ne couvre pas) le guide IMDRF N81

Le guide N81 se positionne comme un complément au guide IMDRF N12 de 2014, qui proposait un cadre de catégorisation des SaMD selon leur impact clinique. Mais ici, le champ est élargi : on ne parle plus seulement des SaMD, mais de tout logiciel qui relève de la définition de dispositif médical, y compris ceux embarqués dans du matériel.

Ce qu’il apporte :

• Une méthode pour décrire précisément un logiciel médical (utilisation prévue + description fonctionnelle)
• Une grille de lecture pour identifier les risques spécifiques liés au logiciel, notamment les risques informationnels
• Un langage commun pour discuter de la classification des risques logiciels entre acteurs réglementaires

Ce qu’il n’est pas :

• Un outil de classification
• Une norme de gestion des risques
• Une grille d’exigences à cocher

À retenir

Le guide N81 est un outil de caractérisation, pas un référentiel normatif. Il aide à structurer votre réflexion, pas à valider votre conformité.

3. Caractériser un logiciel médical : les dimensions à prendre en compte

3.1. L’utilisation prévue : les 7 éléments clés

Le guide propose une structuration claire de l’intended use / intended purpose, articulée autour de 7 éléments :

1.But médical (diagnostic, traitement, surveillance…)

2.Maladie ou condition visée (gravité, stade…)

3.Population cible (âge, vulnérabilité…)

4.Utilisateur visé (clinicien, patient, aidant…)

5.Environnement d’utilisation (domicile, cabinet, hôpital…)

6.Contre-indications (si pertinent)

7.Fonctions logicielles : inputs, outputs, et leur rôle dans le parcours de soin

Un modèle de rédaction est proposé en annexe A du guide, utile pour structurer les sections 1 et 3 de votre documentation technique.

3.2. La description logicielle : les 4 axes proposés

En complément, la description du logiciel doit couvrir 4 axes clés :

• Problème médical adressé (objectif du logiciel, niveau de gravité, population concernée)
• Contexte d’usage (type d’utilisateur, environnement, moment d’utilisation dans le parcours de soin)
• Fonction et usage du logiciel (type de sortie, source de données, niveau d’autonomie, explicabilité, destinataire)
• Gestion du changement (apprentissage, mise à jour, infrastructure, déploiement)

4. Caractériser les risques logiciels : les notions utiles

Le guide N81 rappelle un point fondamental : les risques logiciels ne sont pas toujours physiques. Ils peuvent être :

• Informationnels (données erronées, manquantes, mal interprétées)
• Indirects (mauvaise décision médicale basée sur une sortie logicielle)
• Liés à l’efficacité réduite (biais, perte d’interprétabilité, manque de fiabilité)

Exemple : un logiciel qui sur-interprète des données de capteurs peut conduire à des examens inutiles, voire à des traitements inadaptés.

Le guide insiste aussi sur le lien avec ISO 14971 : la méthodologie d’analyse de risque reste valide, mais il faut y intégrer les spécificités logicielles.

5. Cas pratiques : quand la caractérisation change le niveau de risque

5.1. Exemple 1 : diagnostic de prédiabète par un algorithme

Un logiciel analyse les dossiers patients pour détecter un prédiabète probable. Le guide montre que :

• Le risque est modéré car l’erreur n’entraîne pas de danger immédiat
• Mais l’exclusion de certains patients (non signalés par l’algorithme) constitue un point de vigilance
• L’autonomie de l’outil et la non-visibilité de certains seuils influent sur la perception du risque

Un bon exemple de risque informationnel indirect, mais réel

5.2. Exemple 2 : thérapie numérique contre la douleur

Deux scénarios sont comparés :

• Scénario 1 : le logiciel est utilisé en complément d’antalgiques
• Scénario 2 : le logiciel est la seule thérapie possible (patients intolérants aux médicaments)

Même fonction, même finalité, mais des niveaux de risque très différents. En cas d’échec, le second scénario présente un risque bien plus élevé pour le patient.

6. En pratique : comment utiliser ce guide en tant que fabricant

Le guide N81 peut vous aider à :

• Structurer votre dossier technique dès les premières phases de développement
• Enrichir vos analyses de risques ISO 14971, notamment pour les fonctions algorithmiques
• Clarifier votre positionnement réglementaire auprès des autorités ou des ON

Check-list à retenir

• Définir clairement l’utilisation prévue (avec les 7 éléments)
• Renseigner les 4 axes de description logicielle
• Identifier les dangers spécifiques à l’information et au contexte d’usage
• Évaluer les impacts de l’autonomie et de l’explicabilité
• Documenter la gestion des changements logiciels (MAJ, IA, personnalisations)

7. Mini FAQ

Ce guide remplace-t-il l’ISO 14971 ?

Non, il la complète. Il apporte des éléments spécifiques aux logiciels.

Est-il obligatoire de suivre les tableaux et check-lists du guide ?

Non, le guide n’a pas de valeur réglementaire contraignante. C’est un outil de structuration.

Peut-on l’utiliser pour des logiciels embarqués ?

Oui, le champ couvre tous les logiciels qui relèvent de la définition de DM.

Que faire si mon logiciel évolue continuellement ?

Le guide intègre un axe sur la gestion du changement. Il invite à caractériser le degré d’autonomie et la portée des mises à jour.

Le guide traite-t-il des algorithmes d’IA ?

Indirectement, oui. Notamment à travers les notions d’explicabilité, d’autonomie et de performances évolutives.

8. Conclusion

Le guide IMDRF N81 n’est ni une norme ni une réglementation. C’est un outil précieux de structuration, qui aide à penser et documenter les risques logiciels de manière fine et contextualisée.

Chez CSDmed, nous aidons les fabricants à intégrer ces bonnes pratiques dès les premières lignes de code, pour sécuriser le produit et fluidifier les échanges avec les autorités.

Besoin d’un accompagnement pour caractériser ou documenter votre logiciel médical ?

Contactez-nous. Nous parlerons usages cliniques, architecture logicielle… mais aussi stratégie réglementaire.

9. Ressources associées

• ISO 14971 et start-ups : comment débuter l’analyse des risques sans s’y perdre
• FDA vs MDR : 5 différences qui comptent pour un fabricant de DM
• ISO 13485 pour les start-ups : 3 approches réalistes

• Caractériser les risques des logiciels médicaux : que faut-il retenir du guide IMDRF N88 (2025) ?