IVDR et logiciels IVD : comment bien qualifier et classer votre logiciel ?

Depuis l’entrée en vigueur du Règlement (UE) 2017/746 (IVDR) en mai 2022, le monde du diagnostic in vitro a vu ses règles du jeu profondément évoluer. L’un des changements majeurs ? Le rôle désormais incontournable des organismes notifiés : on estime que près de 80 % des dispositifs IVD doivent désormais passer entre leurs mains pour obtenir le marquage CE.

Dans ce contexte, les logiciels utilisés en diagnostic in vitro suscitent de nombreuses interrogations :

• Sont-ils tous concernés ?
• Quand un logiciel doit-il être considéré comme un dispositif médical IVD ?
• Quelles erreurs éviter pour ne pas se retrouver bloqué au moment de l’évaluation ?

Cet article fait le point, en s’appuyant sur le Position Paper publié par Team-NB, l’association européenne des organismes notifiés, le 27 juin 2025.

1. Rappels réglementaires essentiels

Petit flash-back : avant le IVDR, la directive 98/79/CE prévoyait une évaluation relativement limitée par un ON. Avec le nouveau règlement, la classification des dispositifs repose sur les risques liés à la destination — et les logiciels sont particulièrement scrutés.

En 2019, le MDCG (Medical Device Coordination Group) a déjà publié une guidance (MDCG 2019-11) pour clarifier la qualification et la classification des logiciels sous MDR et IVDR. Problème : beaucoup de fabricants peinent encore à interpréter ces textes pour leur propre cas. D’où l’intérêt de ce Position Paper Team-NB, qui précise ce qu’attendent les organismes notifiés.

2. Qu’est-ce qu’un logiciel IVD au sens du IVDR ?

MDSW, ou Medical Device Software, désigne tout logiciel destiné à une finalité médicale au sens du règlement IVD :

• Seul (ex. appli d’analyse NGS autonome)
• Intégré dans un système (ex. firmware d’analyseur)
• Ou encore sous forme de module ou d’accessoire.

Point clé : certains logiciels peuvent combiner des modules à finalité médicale et d’autres sans finalité médicale (gestion de stock, archivage pur, etc.). Dans ce cas, chaque module doit être correctement délimité et documenté.

3. 3 scénarios pour qualifier votre logiciel

Le Position Paper propose un organigramme clair (flow-chart) pour prendre la bonne décision. En voici une version simplifiée :

➊ Logiciel qui pilote ou influence un dispositif

Ex. firmware, module de contrôle moteur… Ici, le logiciel est évalué comme partie intégrante du système IVD. Pas de classification séparée.

➋ Logiciel IVD indépendant

Ex. application NGS, logiciel d’analyse d’images pour le dépistage du cancer… Dans ce cas, le logiciel est un dispositif médical IVD à part entière. Il doit être classé selon son usage prévu et disposer de sa propre documentation technique.

➌ Logiciel accessoire

Ex. middleware, convertisseur de format image pour IA… Ici, le logiciel n’a pas de finalité médicale directe, mais assiste un dispositif IVD. Il est classé comme accessoire, et reste soumis aux exigences IVDR.

Attention : tout repose sur l’utilisation prévue, c’est votre fil rouge.

4. Cas pratiques : à quoi ça ressemble concrètement ?

Exemple 1

Un logiciel d’analyse de séquences NGS pour détecter des anomalies génétiques héréditaires. Ici, le logiciel fournit directement un résultat à valeur diagnostique : c’est un IVD à part entière.

Exemple 2

Une appli mobile qui exploite des données de glycémie pour générer des alertes et ajuster les doses d’insuline. Usage diagnostique ou thérapeutique → IVD MDSW.

Exemple 3

Un module middleware qui convertit des images de biopsie pour permettre leur exploitation par une IA. Il n’a pas de finalité médicale autonome, mais rend possible le traitement : c’est un accessoire.

5. Les erreurs à éviter

• Croire qu’un logiciel cloud ou un module de visualisation est toujours hors champ : tout dépend de la finalité.
• Mélanger des modules à finalité médicale et non médicale sans frontières claires : documentez la séparation.
• Oublier que la classification de l’ensemble prime sur le détail : un module intégré à un système doit suivre la classe du système.

6. FAQ — Vos questions fréquentes

Qu’est-ce qu’un logiciel non IVD ?

Ex. LIMS, ERP, gestion de stock : aucun traitement de données à des fins diagnostiques → hors champ IVDR.

Un LIMS est-il concerné par l’IVDR ?

Non, sauf si une partie du LIMS génère une interprétation diagnostique. Dans ce cas, ce module est à qualifier comme IVD MDSW.

Comment gérer un logiciel cloud ?

Peu importe l’emplacement (cloud, PC, mobile) : seul compte l’usage prévu.

Mon logiciel est vendu séparément : que dois-je faire ?

Vérifiez s’il est destiné à un usage autonome IVD ou à être intégré à un système. Cela conditionne la procédure d’évaluation.

Puis-je qualifier un module comme « non médical » ?

Oui, mais il faut démontrer qu’il n’a aucune interaction directe avec les données diagnostiques. Et bien délimiter ses interfaces.

7. Conclusion : la clé, c’est l’utilisation prévue

Pour éviter tout blocage lors de l’évaluation par l’organisme notifié, posez-vous toujours la question : « Quelle est l’utilisation prévue réelle ? » Rédigez-la clairement, justifiez vos choix, documentez vos modules. Et en cas de doute : ne prenez pas de risque inutile.

Vous avez un doute sur la qualification ou la classification de votre logiciel ? CSDmed vous accompagne pour sécuriser vos démarches IVDR et éviter les mauvaises surprises lors de l’évaluation CE.

Contactez-nous pour discuter de vos projets.

Cet article pourrait également vous intéresser : Nouveau guide MDCG 2025-4 : obligations pour les apps logicielles de dispositifs médicaux sur les plateformes en ligne