Points clés
- Classifiez tôt. La classe de sécurité logicielle IEC 62304 (A/B/C) détermine la rigueur de conception et de vérification due — décidez-la avant d’écrire du code.
- La documentation est le produit. DHF, DMR, dossiers de V&V et fichier de risque ISO 14971 sont des livrables, pas des ajouts.
- La cybersécurité est désormais pré-commercialisation. La FDA 524B attend un SBOM, du firmware signé et un chemin de correctif gouverné pour les appareils déployés.
- C’est en post-commercialisation que les dispositifs échouent. Il faut des OTA gouvernées et une piste d’audit pour mettre à jour une flotte en sécurité.
- Le bilinguisme compte. Les contextes de Santé Canada et du Québec exigent souvent une documentation bilingue et auditable.
Commencez par classifier le dispositif
L’erreur la plus coûteuse en IoT médical est d’écrire du code avant de classifier le logiciel. Sous IEC 62304, la classe de sécurité logicielle reflète le pire préjudice qu’une défaillance pourrait causer :
| Classe | Pire préjudice | Ce qu’elle exige |
|---|---|---|
| A | Aucune blessure possible | Processus de cycle de vie + exigences + vérification |
| B | Blessure non grave possible | + Architecture logicielle, tests d’intégration |
| C | Décès ou blessure grave possible | + Conception détaillée, vérification unitaire avec preuve de couverture |
La classe — établie avec l’analyse de risque ISO 14971 — détermine votre budget, votre échéancier et la profondeur documentaire. Nous la chiffrons avant toute ligne de code pour un coût prévisible.
Les cadres réglementaires à maîtriser
- IEC 62304 — cycle de vie du logiciel de dispositif médical (classes A/B/C).
- ISO 13485 — système de management de la qualité des dispositifs médicaux.
- ISO 14971 — application de la gestion des risques aux dispositifs médicaux.
- IEC 60601-1 (et collatéraux) — sécurité électrique des équipements médicaux.
- FDA 21 CFR Part 820 — contrôles de conception.
- FDA 524B (Omnibus 2023) — cybersécurité pré-commercialisation.
- RDM UE 2017/745 — pour le marché européen.
- HL7 FHIR R4 — interopérabilité des données de santé.
- Santé Canada — parcours de Licence d’instrument médical (LIM).
Une méthode d’ingénierie qui produit la preuve d’audit
Un développement conforme aligne le modèle en V sur IEC 62304, pour que la documentation soit un sous-produit du travail et non une course avant la soumission :
- Cadrage et classification IEC 62304 + analyse de risque ISO 14971.
- Spécification des exigences logicielles (SRS) + document d’architecture (SAD).
- Développement avec traçabilité : exigences ↔ code ↔ tests.
- Vérification (unitaire, intégration, système) avec couverture documentée.
- Validation en environnement représentatif (clinique si requise).
- Transfert en production + plan de surveillance et de maintenance post-commercialisation.
La cybersécurité fait désormais partie de l’autorisation (FDA 524B)
Depuis l’Omnibus 2023, la FDA attend une preuve de cybersécurité avant la mise en marché : nomenclature logicielle (SBOM), firmware signé, démarrage sécurisé là où le matériel le permet, et un plan de surveillance et de correctifs pour les appareils déployés. Un plan 524B n’est crédible que si vous pouvez réellement pousser une mise à jour gouvernée et auditée vers une flotte sur le terrain — une décision d’architecture prise au départ, pas un document écrit à la fin.
Des preuves, pas des adjectifs : le cas Zillia
Amotus a développé le firmware, le support matériel et l’infrastructure connectée du dispositif de diagnostic oculaire connecté de Zillia — un client médical réel et nommé. Des études de cas détaillées (défi, stack, approche de vérification, résultats) ancrent notre travail en santé dans le fait plutôt que dans des affirmations génériques. Voir les études de cas et la pratique santé.
Où Fundamentum entre en jeu
Un dispositif médical connecté tient ou échoue sur le contrôle post-commercialisation : qui peut pousser du firmware, vers quels appareils, avec quelle preuve d’audit. Fundamentum donne aux équipes médicales l’identité des appareils, des OTA signées et gouvernées, des accès par rôle et une piste d’audit immuable, dans le périmètre SOC 2 Type II du Groupe Vectanor — la traçabilité que présupposent les attentes post-commercialisation de la FDA 524B. Il peut se connecter au nuage existant d’un hôpital (AWS, Azure) pour l’échange de données au besoin, tout en gardant un plan de contrôle gouverné et sensible à la résidence. Voir comment Fundamentum gouverne les OTA →
Foire aux questions
Quelle est la différence entre IEC 62304 classe A, B et C ?
La classe reflète le pire préjudice qu’une défaillance logicielle pourrait causer. Classe A : aucune blessure possible. Classe B : blessure non grave possible. Classe C : décès ou blessure grave possible. La classe détermine l’ampleur de la documentation d’architecture, de la conception détaillée et de la rigueur de vérification exigées — la C est la plus exigeante.
Combien coûte un firmware classe B vs classe C ?
Le coût dépend de la profondeur de documentation et de vérification, pas du nombre de lignes de code. Un dispositif de classe C ajoute généralement une conception logicielle détaillée, une vérification au niveau unitaire avec preuve de couverture et une traçabilité de risque plus stricte qu’en classe B — souvent une hausse notable d’heures d’ingénierie. Nous le chiffrons à l’étape de classification IEC 62304, avant toute ligne de code, pour un budget prévisible.
Êtes-vous certifiés ISO 13485 ?
Nous développons dans un processus qualité aligné sur ISO 13485 et livrons les artéfacts d’historique de conception (DHF) et de dossier maître (DMR) dont votre SMQ a besoin. La certification du fabricant légal demeure celle du fabricant, mais nos livrables sont conçus pour être auditables à l’intérieur. Demandez-nous notre statut de certification courant lors de la qualification.
Pouvez-vous soutenir un dépôt FDA 510(k) ou une licence Santé Canada ?
Oui — nous produisons la preuve d’ingénierie sur laquelle s’appuient ces dépôts : exigences logicielles, architecture, dossiers de V&V, fichier de gestion des risques (ISO 14971) et documentation de cybersécurité (FDA 524B). Nous travaillons aux côtés de votre responsable réglementaire plutôt que de le remplacer, et structurons les livrables pour les parcours FDA et la Licence d’instrument médical de Santé Canada.
Comment gérez-vous la cybersécurité post-commercialisation (FDA 524B) ?
Nous concevons pour elle : nomenclature logicielle (SBOM), firmware signé, démarrage sécurisé là où le matériel le permet, et un chemin OTA gouverné pour corriger une flotte déployée avec preuve d’audit. Fundamentum fournit l’identité des appareils, les OTA gouvernées et la piste d’audit qui rendent un plan post-commercialisation 524B exécutable plutôt qu’aspirationnel.
Travaillez-vous avec des startups med-tech pré-revenu ?
Oui. Beaucoup de nos clients médicaux démarrent en phase pré-soumission. Nous aidons à classifier le dispositif tôt (IEC 62304, classe de risque), à bâtir un MVP démontrable qui n’aura pas à être réarchitecturé pour la conformité plus tard, et à étager la documentation réglementaire pour qu’elle grandisse avec le produit au lieu d’être ajoutée à la hâte avant un 510(k).
À lire aussi
Parlez à un ingénieur IoT — gratuitement
Réservez un appel-conseil GRATUIT de 30 minutes avec notre équipe. Pas de diapositives, aucune obligation — une vraie séance de travail sur vos questions de connectivité, de plateforme ou de conformité.
