La santé numérique face à la paperasserie : ce que l’industrie pharmaceutique peut apprendre du Software as a Medical Device

Pharma se précipite pour ajouter des composants numériques aux médicaments — applications complémentaires, plateformes de données, aide à la décision assistée par IA — mais le logiciel ne suit pas la même logique réglementaire que les comprimés et les injectables. Dans de nombreux projets, la partie logicielle relève du territoire des dispositifs médicaux réglementés (Software as a Medical Device, ou SaMD). Les équipes qui considèrent le logiciel comme une fonctionnalité secondaire découvrent tardivement qu’il comporte sa propre classification, ses exigences qualité et ses obligations post‑commercialisation. Cet article traduit le playbook SaMD pour les dirigeants pharmaceutiques afin que vous puissiez planifier les preuves, les échéances et le risque dès le premier jour.

Instantané du marché 2025 : pourquoi c’est important maintenant

La liste publique de la FDA comprend désormais plus de 1 000 dispositifs médicaux activés par AI/ML autorisés, homologués ou approuvés aux États‑Unis — une hausse marquée qui signale la rapidité avec laquelle les produits pilotés par logiciel entrent dans les parcours de soins.

Les outils de santé numériques continuent de proliférer, avec des centaines de milliers d’apps en circulation ; de plus en plus, la biopharma les utilise pour collecter des données du monde réel et soutenir l’observance, la surveillance de la sécurité et les résultats.

1) Qu’est‑ce que le SaMD — et pourquoi la pharma devrait s’en soucier

Le SaMD est un logiciel destiné à un usage médical sans faire partie d’un dispositif matériel. Les exemples incluent des algorithmes d’IA pour le diagnostic, des applications destinées aux patients qui guident la thérapie, et des outils d’aide à la décision pour les cliniciens. La pharma touche au SaMD lorsque :

• Des apps complémentaires sont appairées à des thérapies.
• Des plateformes de données du monde réel soutiennent des dossiers réglementaires ou HTA.
• Des algorithmes sont intégrés dans des combinaisons médicament‑dispositif (par ex., inhalateurs ou injecteurs connectés).

Si vous franchissez le seuil du SaMD, vous héritez des règles applicables aux dispositifs — classification, documentation du cycle de vie du logiciel, ingénierie de l’utilisabilité, gestion des risques et surveillance post‑commercialisation.

2) Le SaMD n’est pas « juste du logiciel » — c’est un produit réglementé

Les attentes fondamentales comprennent :

• Qualité et cycle de vie : ISO 13485 pour le SMQ et IEC 62304 pour le cycle de vie du logiciel.
• Utilisabilité : IEC 62366 preuves en facteurs humains lorsque les patients ou les professionnels de santé interagissent avec l’interface utilisateur.
• Risque : ISO 14971 gestion des risques liée à l’usage prévu et aux préjudices.
• Spécificités du marché : les voies préalables au marché basées sur le risque de la FDA (510(k), De Novo, PMA) et la classification MDR de l’UE (notamment la Règle 11 pour les logiciels). Planifiez-les dès le départ — les ajouter après coup provoque retards et reprises.

3) Perspective réglementaire mondiale en un coup d’œil

États‑Unis (FDA) : Voies préalables au marché basées sur le risque. Pour le SaMD activé par AI/ML, la FDA a finalisé des orientations sur les Predetermined Change Control Plans (PCCP), qui permettent aux titulaires de convenir à l’avance des modalités de mise à jour des modèles après l’autorisation/approbation. L’agence a également publié des Good Machine Learning Practice (GMLP) et des principes de transparence pour gérer le biais, la performance et la communication aux utilisateurs.

Union européenne (MDR) : La Règle 11 pousse beaucoup de logiciels d’aide à la décision clinique en classe IIa/IIb/III, déclenchant l’examen par un organisme notifié et des preuves cliniques robustes. Les directives mises à jour du MDCG clarifient la qualification et la classification des logiciels au titre du MDR/IVDR.

Loi sur l'IA de l'UE : L’IA utilisée dans les dispositifs médicaux sera généralement traitée comme « à haut risque », superposant des exigences spécifiques à l’IA (gouvernance des données, transparence, gestion des risques, supervision humaine) en plus du MDR/IVDR, mises en œuvre par phases après l’entrée en vigueur.

Spécifique à la pharma (PDURS) : L’orientation provisoire de la FDA sur le Prescription Drug Use‑Related Software (PDURS) explique comment les sorties logicielles diffusées par un titulaire de médicament peuvent être réglementées comme de l’étiquetage de médicament — pertinent lorsque votre logiciel est lié à un médicament plutôt que réglementé comme un dispositif.

4) Notes de cas : jumelages pharma‑numérique en pratique

Respiratoire connecté : Les capteurs et apps de Propeller Health ont été appairés avec de grandes marques d’inhalateurs pour soutenir l’observance et le suivi des symptômes.

Écosystèmes diabète : L’acquisition de mySugr par Roche a intégré la gestion du diabète centrée sur l’app dans un large portefeuille pharma/dispositif, mêlant logiciel, lecteurs et services.

Leçons de la pilule numérique : ABILIFY MYCITE (Otsuka + Proteus) a montré comment des combinaisons médicament‑dispositif‑logiciel peuvent obtenir une approbation mais rester confrontées à des défis d’adoption, de confidentialité et de valeur.

Thérapeutiques numériques sur prescription : Les partenariats autour de traitements logiciels (par ex., reSET/reSET‑O) ont illustré à la fois la viabilité réglementaire et les vents contraires commerciaux.

5) Cinq leçons pratiques que la pharma devrait emprunter au développement SaMD

1. Classifiez tôt. Appliquez les critères de la FDA et la Règle 11 du MDR dès la phase conceptuelle ; consignez l’usage prévu et les décisions cliniques que votre logiciel influence.

2. Bâtissez l’ossature SMQ. Mettez en place les contrôles de conception, les dossiers de risque et les processus du cycle de vie logiciel avant de coder au‑delà d’un prototype.

3. Traitez l’utilisabilité comme une sécurité. Planifiez des tests formatifs et sommatifs ; liez les décisions d’interface aux contrôles de risque et aux risques résiduels dans votre dossier ISO 14971.

4. Validez votre pipeline de données. Documentez les sources de données, la qualité, la représentativité et les garanties de confidentialité ; cela soutient à la fois la sécurité de l’IA et la confiance.

5. Concevez pour les mises à jour. Pour l’AI/ML, anticipez les mises à jour de modèles avec des protocoles clairs de changement (par ex., PCCP aux États‑Unis) et un plan de surveillance post‑commercialisation.

6) IA/ML : Les modes de défaillance à anticiper

Dérive algorithmique : les performances en conditions réelles peuvent se dégrader lorsque les populations, les pratiques ou les capteurs évoluent. Surveiller et réentraîner selon un plan contrôlé.

Biais et représentativité : des données d’entraînement non représentatives peuvent nuire à des sous‑populations. Définir des métriques de biais, pré‑spécifier des mesures d’atténuation et être transparent sur les limites.

Explicabilité et transparence : fournir aux utilisateurs des informations claires sur l’utilisation prévue, les entrées, les sorties et les modes de défaillance connus ; s’aligner sur les principes publiés de transparence.

Collaboration humain‑IA : définir ce que l’humain décide vs. ce que le logiciel suggère ; concevoir des interfaces qui réduisent, et non qui augmentent, la charge cognitive.

7) Après le lancement : cycle de vie, cybersécurité et surveillance

• EU MDR post‑market : Maintenir un plan de PMS ; pour les classes IIa/IIb/III, préparer des Periodic Safety Update Reports (PSUR) qui synthétisent les données de sécurité et de performance.

• Attentes aux États‑Unis : surveiller les performances en conditions réelles ; pour les dispositifs liés à la cybersécurité, traiter la conception sécurisée, la gestion des vulnérabilités, la divulgation coordonnée et fournir un software bill of materials (SBOM) conforme aux attentes actuelles de la FDA.

• Gestion des mises à jour : lier les correctifs logiciels et les mises à jour de modèles à l’évaluation des risques, à la vérification/validation et aux communications aux utilisateurs. Documenter tout.

8) Éthique, confidentialité et confiance des patients

Être explicite sur les données que vous collectez, pourquoi et comment elles sont protégées. Assurer l’alignement GDPR/HIPAA, minimiser les données quand c’est possible et communiquer clairement les bénéfices et les risques. La confiance est un choix de conception — intégrez‑la dans l’onboarding, les flux de consentement et l’étiquetage.

9) Une checklist pour les équipes pharma entrant dans le SaMD

Conclusion

Le logiciel fait désormais partie de la thérapie. Les équipes qui considèrent le SaMD comme un produit réglementé dès le départ — avec une classification claire, des preuves adaptées à l’usage et un plan pour les mises à jour et la surveillance — livreront plus rapidement et avec moins de surprises.

Références

1. FDA – Liste des dispositifs médicaux activés par AI/ML ; orientation PCCP ; GMLP et principes de transparence.

2. UE – Règle 11 du MDR et orientations du MDCG sur les logiciels ; EU AI Act (obligations pour les systèmes à haut risque).

3. Notes de cas – Otsuka/Proteus ABILIFY MYCITE ; partenariats Propeller Health ; acquisition par Roche de mySugr ; analyses de marché sur l’adoption de la santé numérique.