search
Françaisexpand_more
Deutsch
English
Contactez-nous
search
FRA
Deutsch
English
Contactez-nous
  • Il n'y a aucune suggestion car le champ de recherche est vide
Blog Hero
Blog

Cinq lacunes en matière de conformité à l'IA qui font discrètement dérailler les équipes de développement de logiciels médicaux

L'écart entre « ça fonctionne » et « c'est conforme » est plus important que ne le pensent la plupart des équipes de développement logiciel, et il n'apparaît généralement qu'une fois que les corrections deviennent coûteuses. Vous trouverez ci-dessous cinq domaines de conformité en matière d'IA au regard des règlements MDR et IVDR de l'UE qui posent sans cesse des problèmes aux équipes, ainsi que des conseils pour commencer à y remédier.

Votre dispositif médical basé sur l’IA n’est pas un seul produit réglementé. Il en représente trois.

Un dispositif médical basé sur l’IA se situe à la croisée de trois domaines réglementés : les logiciels, les dispositifs médicaux et l’intelligence artificielle. Chacun d’entre eux est soumis à ses propres exigences réglementaires, et là où elles se recoupent, les obligations se cumulent, couvrant non seulement le produit fini, mais aussi le processus utilisé pour le fabriquer.

Comprendre où se situe un produit dans ce chevauchement, et quelles obligations se superposent, constitue le point de départ de tout ce qui suit.

Lacune n° 1 : considérer la conformité comme une étape et non comme un élément de conception

« Nous nous occuperons de la conformité plus tard. »

Les fabricants qui considèrent la conformité comme une étape ultérieure en arrivent généralement à ce « plus tard » après avoir déjà collecté des données d’entraînement sans provenance documentée et mis en place une architecture qui ne prend pas en charge l’explicabilité ni la surveillance. À ce stade, l’usage prévu est généralement déjà figé, tout comme une classe de risque pour laquelle le fabricant n’a pas préparé de preuves.

Par où commencer : définissez l’objectif visé et déterminez la classification avant de finaliser l’architecture du modèle. Ces décisions déterminent quelles preuves cliniques et techniques sont nécessaires, ce qui, à son tour, façonne la stratégie en matière de données. Considérez le parcours réglementaire comme une feuille de route dès le premier jour, et non comme une liste de contrôle à remplir à la fin.

Lacune n° 2 : vos résultats de test valident votre modèle, pas votre dispositif

« Notre modèle a une précision de 98 %. »

Un score élevé sur l’ensemble de test montre que le modèle fonctionne bien sur les données. Il ne montre pas que le dispositif fonctionne bien dans des flux de travail cliniques réels, avec des patients, entre les mains de ses utilisateurs visés. Les performances analytiques ne sont pas synonymes de performances cliniques. Les recommandations de l’IMDRF sur les bonnes pratiques en matière d’apprentissage automatique indiquent clairement que ce qui importe, ce sont les performances en conditions réelles de l’équipe composée d’humains et d’IA, et non l’algorithme pris isolément.

Par où commencer : planifiez une validation clinique qui teste le dispositif dans son ensemble dans des conditions représentatives : des utilisateurs réels, des flux de travail réels et une population correspondant à la déclaration d’utilisation prévue.

Lacune n° 3 : vos données de performance prouvent que le logiciel est utile, mais pas que l’IA l’est

« Les cliniciens obtiennent des résultats supérieurs de 25 % grâce à notre dispositif. »

La réglementation n’exige pas seulement un bénéfice démontré ; elle exige qu’il soit comparé à l’état de l’art. Les logiciels existants sans noyau d’IA peuvent déjà apporter de réels avantages, tels que des flux de travail numériques, des données structurées et une aide à la décision. L’IA comportant un risque supplémentaire, son utilisation doit être justifiée par un bénéfice démontré par rapport à un comparateur pertinent, et non adoptée uniquement en raison de l’engouement médiatique dont elle fait l’objet. Des clients affichant des chiffres impressionnants ont eu du mal à prouver que l’IA elle-même avait fait la différence une fois le bon comparateur appliqué.

Par où commencer : effectuez une comparaison avec la norme de soins réelle, y compris tout logiciel non basé sur l’IA déjà utilisé. Assurez-vous que l’essai isole la valeur ajoutée de l’IA et la justifie par rapport au risque supplémentaire.

Lacune n° 4 : vos données ne résisteront probablement pas à un examen du dossier technique

« Nos données d’entraînement sont de bonne qualité. »

L’histoire derrière les données importe autant que les résultats des tests eux-mêmes. Les autorités de réglementation s’attendent à voir :

  • La provenance des données et la traçabilité de leurs sources
  • Les critères d’inclusion/d’exclusion et la méthodologie d’étiquetage
  • La répartition démographique et l’analyse de la représentativité
  • L’identification des biais et les mesures d’atténuation
  • Le contrôle des versions des ensembles de données avec historique des modifications, dans le cadre de la configuration du dispositif

Par où commencer : commencez dès maintenant à documenter les décisions relatives aux données, et non lors de la préparation de la soumission. Consignez la logique d’inclusion/exclusion, le protocole d’étiquetage et la répartition démographique, et mettez en place un système de gestion des versions de l’ensemble de données dès le départ.

Lacune n° 5 : la loi sur l’IA est déjà d’actualité

« La loi sur l’IA ne s’applique pas encore à nous. »

Les règles relatives aux risques élevésde la loi sur l’IA ne sont pas encore en vigueur, mais ses principes définissent déjà ce que les organismes notifiés considèrent comme l’état de l’art. Une grande partie de ce contenu figure déjà dans le questionnaire Team-NB/IG-NB sur l’IA, le document utilisé par les organismes notifiés pour évaluer l’IA dans les dispositifs médicaux.

Concept de la loi sur l’IA

Questionnaire Team-NB sur l’IA

Supervision humaine (art. 14)

L'utilisateur prévu/le contexte d'utilisation nécessite un « niveau de supervision humaine » (6.1.2)

Données et gouvernance des données (art. 10)

Correspondance étroite avec les attentes de la section 6.3

Précision, robustesse, cybersécurité (art. 15)

Les cyberattaques spécifiques à l’IA sont qualifiées de « fondamentalement différentes » des menaces conventionnelles (6.2.4)

 

Par où commencer : évaluer les lacunes de la documentation technique MDR/IVDR à l’aune du questionnaire Team-NB sur l’IA et des principales dispositions de la loi sur l’IA. Un examen précoce permet de pérenniser le processus.

La solution ne consiste pas à travailler plus dur, mais à anticiper plus tôt.

Chaque lacune de cette liste devient moins coûteuse, plus rapide et plus facile à combler si elle est traitée le plus tôt possible. Une conformité intégrée dès le processus de développement, plutôt que mise en place a posteriori, permet une mise sur le marché plus rapide, coûte moins cher à maintenir et résiste mieux aux contrôles.

Comment Qserve peut vous aider avec votre dispositif médical intégrant l’IA

  • Évaluation de la stratégie réglementaire et clinique
  • Évaluation des lacunes de conformité et mise en place de mesures correctives
  • Développement, mise en œuvre et audit du système de gestion de la qualité
  • Accompagnement en matière de gestion des risques de sûreté et de sécurité
  • Accompagnement en ingénierie de l'ergonomie
  • Accompagnement à l’évaluation clinique