Votre logiciel est utilisé en santé. Est-il pour autant un dispositif médical ?

Le lieu d'utilisation ne suffit pas

Un logiciel de rendez-vous et un module destiné à orienter une décision thérapeutique peuvent être utilisés sur le même ordinateur, dans le même service. Cela ne leur donne pas automatiquement le même statut réglementaire. Partir du secteur « santé » ou du nom commercial conduit facilement à analyser le mauvais périmètre.

La première discussion devrait porter sur la fonction : qu'entre-t-il dans le logiciel, qu'en sort-il et à quelle décision le résultat est-il destiné ? Il faut décrire le produit effectivement proposé, pas seulement sa technologie ou une ambition inscrite dans une présentation.

Commencer par la destination du fabricant

Le règlement (UE) 2017/745 définit le dispositif médical et la destination prévue par son fabricant. Les indications, la notice et les déclarations commerciales contribuent à cette appréciation. Une formulation très générale ne remplace donc pas une description cohérente des fonctions et de l'usage médical revendiqué.

Le guide MDCG 2019-11 révisé en juin 2025 aide à distinguer les logiciels concernés, leurs modules et leurs interfaces. C'est un document d'orientation, pas une décision individuelle de qualification ni un texte qui remplace le règlement. Un logiciel relevant du diagnostic in vitro doit aussi être examiné au regard du cadre IVDR approprié.

La règle 11 intervient après la qualification

Une fois le statut de dispositif établi, il faut examiner les règles de classification applicables. La règle 11 de l'annexe VIII distingue notamment les logiciels fournissant des informations destinées à des décisions diagnostiques ou thérapeutiques, la surveillance de processus physiologiques et les autres logiciels entrant dans son champ.

Les conséquences possibles des décisions et la nature des paramètres surveillés peuvent modifier la classe retenue. D'autres règles peuvent également s'appliquer ; il faut considérer l'ensemble pertinent, pas sélectionner une formule favorable. Les guides MDCG expliquent ces distinctions mais ne permettent pas d'attribuer une classe à partir du seul mot « IA ».

Le dossier doit aussi articuler les exigences liées au marquage CE avec celles du RGPD lorsque des données personnelles sont traitées. Si le logiciel répond à la définition d'un système d'IA, l'AI Act doit être examiné selon son usage, les rôles des acteurs et le calendrier applicable. La classe du dispositif médical et la qualification de l'IA à haut risque répondent à des critères distincts : ces deux analyses doivent être menées et reliées.

Préparer six éléments avant une revue réglementaire

Un premier dossier de cadrage gagne à réunir les éléments suivants. Cette liste prépare l'analyse ; elle ne constitue pas, seule, la documentation technique complète exigible.

• La destination précise, les utilisateurs et la population concernés.
• Les fonctions, données d'entrée, résultats produits et décisions influencées.
• Les modules médicaux et non médicaux, avec leurs dépendances et interfaces.
• Les conséquences envisageables d'un résultat incorrect ou indisponible.
• Le raisonnement de qualification puis de classification, avec les points à confirmer.
• Les versions du produit, des documents et les changements nécessitant une nouvelle revue.

Faire évoluer le dossier avec le produit

Ajouter une recommandation clinique à un outil documentaire peut changer les questions à examiner. De même, un nouveau public, une autre indication ou une modification de fonction peut remettre en cause des hypothèses antérieures. L'analyse doit suivre les changements pertinents du produit.

Dans une démonstration NELSPACE, partez de votre destination et demandez comment organiser les informations, les pièces, les responsabilités et les questions ouvertes. Le périmètre couvert doit être explicite. Un outil d'organisation réglementaire ne délivre pas à lui seul un marquage CE et ne se substitue pas aux intervenants requis pour l'évaluation de conformité.