Points clés
- L’IEC 62304 régit le cycle de vie du logiciel, pas tout le dispositif — associez-la à l’ISO 13485 et à l’ISO 14971.
- Les classes de sécurité A / B / C dépendent du préjudice qu’une défaillance peut causer, après maîtrise des risques.
- Les classes B et C exigent architecture détaillée, vérification unitaire et traçabilité complète ; la classe A est plus légère.
- La norme attend une classification de sécurité logicielle, un plan de cycle de vie et un processus de résolution de problèmes.
- La traçabilité exigence → conception → test est le livrable que les auditeurs vérifient en premier.
Ce que couvre réellement l’IEC 62304
L’IEC 62304 définit le cycle de développement logiciel du logiciel de dispositif médical, que le logiciel soit le dispositif (SaMD) ou un firmware embarqué à l’intérieur. Elle ne remplace pas votre système qualité : l’ISO 13485 régit le système de management de la qualité autour, et l’ISO 14971 régit la gestion des risques qui alimente la classification de sécurité logicielle. Voyez les trois comme une pile — l’ISO 13485 c’est l’entreprise, l’ISO 14971 c’est le risque, l’IEC 62304 c’est le code.
La norme est basée sur les processus. Elle vous dit quels processus et enregistrements il faut — planification, analyse des exigences, conception architecturale, implémentation, vérification, livraison, maintenance et résolution de problèmes — sans prescrire de méthodologie précise. Agile, cycle en V ou incrémental sont tous acceptables si les enregistrements existent.
La classification de sécurité : A, B, C
Avant d’écrire une ligne de code de production, vous classez chaque élément logiciel selon le pire préjudice plausible qu’une défaillance pourrait causer, une fois les mesures externes de maîtrise des risques considérées :
| Classe | Préjudice possible d’une défaillance | Rigueur exigée |
|---|---|---|
| A | Aucune blessure ni atteinte à la santé n’est possible | La plus légère : enregistrements de cycle de vie, mais ni architecture détaillée ni vérification unitaire imposées |
| B | Une blessure non grave est possible | Architecture logicielle détaillée, vérification unitaire, tests d’intégration, traçabilité complète |
| C | Un décès ou une blessure grave est possible | Tout ce qui est en B, plus le détail de conception, la vérification et la documentation les plus exhaustifs |
Un levier d’ingénierie courant : si l’architecture ségrègue une fonction à haut risque de sorte qu’une défaillance ne peut atteindre le patient, vous pouvez justifier une classe plus basse pour le reste du logiciel. Cette ségrégation doit elle-même être documentée et vérifiée. Voyez notre analyse de coût classe B vs C pour son impact budgétaire.
Les processus du cycle de vie et leurs livrables
Planification et exigences
Vous produisez un plan de développement logiciel et un ensemble versionné d’exigences logicielles dérivées des exigences système et des mesures de maîtrise des risques. Chaque exigence reçoit un identifiant unique pour être tracée en aval.
Architecture et conception détaillée (classe B/C)
Pour les classes B et C, vous documentez l’architecture logicielle — éléments, interfaces et réalisation des mesures de maîtrise des risques. La classe C ajoute la conception détaillée la plus poussée. La classe A est exemptée de l’exigence d’architecture détaillée.
Implémentation, vérification et intégration
Le code est implémenté selon la conception, puis vérifié. Les classes B et C exigent une vérification unitaire par rapport à des critères d’acceptation documentés et des tests d’intégration des éléments assemblés. Les résultats sont enregistrés, pas seulement exécutés.
Livraison, maintenance et résolution de problèmes
La livraison exige que les activités planifiées soient achevées et les anomalies connues évaluées. Un processus de résolution de problèmes doit capturer, investiguer et suivre chaque défaut tout au long de la vie du produit — cela se relie directement aux obligations post-commercialisation.
La traçabilité, le livrable qui fait échouer les audits
L’artefact le plus vérifié est la traçabilité bidirectionnelle : chaque exigence logicielle trace vers sa conception, sa vérification et la mesure de maîtrise des risques qu’elle réalise — et inversement. Si un évaluateur choisit une exigence au hasard et ne peut la suivre jusqu’à un test réussi, le dossier est incomplet, peu importe la qualité du code. Construisez la matrice de traçabilité dès le premier jour ; la reconstruire à la fin est là où les projets perdent du calendrier.
Où l’IEC 62304 s’insère avec les autres normes
L’IEC 62304 voyage rarement seule. Pour l’accès au marché, vous satisfaites aussi l’ISO 13485 (système qualité), l’ISO 14971 (risque), l’IEC 60601 pour la sécurité électrique des dispositifs alimentés, et de plus en plus les attentes de cybersécurité de la FDA 524B pour les dispositifs connectés. Notre guide cybersécurité 524B couvre la surcouche des dispositifs connectés, et le carrefour IoT médical conforme cartographie tout le paysage. En Amérique du Nord comme à l’international, la discipline du cycle de vie est la même ; seule l’enveloppe de soumission diffère selon le marché.
Où Fundamentum entre en jeu
L’IEC 62304 exige des enregistrements de cycle de vie traçables et des livraisons gouvernées. Fundamentum, notre plateforme IoT canadienne, donne aux dispositifs médicaux connectés un firmware signé, des OTA gouvernées et une piste d’audit complète dans un périmètre SOC 2 Type II — pour que la discipline post-commercialisation attendue par la norme soit intégrée, pas greffée. Elle peut s’interfacer à AWS, Azure ou Google Cloud si votre architecture l’exige. Voir la plateforme →
Foire aux questions
Quelles sont les classes de sécurité logicielle de l’IEC 62304 ?
Il y en a trois : classe A (aucune blessure possible), classe B (blessure non grave possible) et classe C (décès ou blessure grave possible). La classe dépend du pire préjudice plausible qu’une défaillance pourrait causer après maîtrise des risques, et elle fixe l’ampleur de conception, vérification et documentation à produire.
L’IEC 62304 est-elle la même chose que l’ISO 13485 ?
Non. L’IEC 62304 régit le cycle de développement logiciel ; l’ISO 13485 régit le système de management de la qualité autour, et l’ISO 14971 régit la gestion des risques. Elles fonctionnent ensemble : la 13485 est le système d’entreprise, la 14971 alimente la classification de sécurité, et la 62304 couvre le cycle de vie du code.
La classe A demande-t-elle vraiment moins de travail ?
Oui. La classe A est exemptée des exigences d’architecture détaillée et de vérification unitaire qui lient les classes B et C. Vous conservez des enregistrements de cycle de vie, mais le fardeau documentaire et de vérification est nettement plus léger — d’où la ségrégation architecturale comme levier de coût fréquent.
Pourquoi la traçabilité est-elle si importante ?
La traçabilité est la première chose que les évaluateurs vérifient. Chaque exigence logicielle doit tracer vers sa conception, sa vérification et la mesure de maîtrise des risques qu’elle réalise — et inversement. Si une exigence ne mène pas à un test réussi, le dossier est incomplet, peu importe la qualité du code. Construisez la matrice dès le premier jour plutôt que de la reconstruire à la fin.
L’IEC 62304 couvre-t-elle la cybersécurité ?
En partie seulement. L’IEC 62304 ancre le cycle de vie et se relie au risque, mais les dispositifs connectés exigent désormais un dossier de cybersécurité dédié — notamment sous la FDA 524B — couvrant SBOM, firmware signé et correctifs post-commercialisation. Voyez les deux comme des couches complémentaires du même dossier d’ingénierie.
À 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é.
