À l’horizon 2027 : préparez vos logiciels critiques aux changements

Temps de lecture : 8 minutes

Dans un monde où les logiciels critiques se multiplient (dispositifs médicaux, systèmes embarqués automobiles, architectures « software-defined », mises à jour OTA, intelligence artificielle) les exigences réglementaires et normatives évoluent fortement.

Deux révisions majeures pointent à l’horizon :

• L’édition 2 de la norme IEC 62304 pour les logiciels de santé / dispositifs médicaux, qui élargit le périmètre aux « health software » et intègre des considérations liées à l’IA.
• La future édition 3 de la norme ISO 26262, pour mieux prendre en compte les véhicules modernes (zonal, hiérarchies logicielles, OTA, IA/ML, architectures complexes).

Pour les organisations concernées (développement logiciel, R&D, cybersécurité, qualité, conformité), l’enjeu est de taille : il s’agit de préparer dès aujourd’hui leur trajectoire de conformité, non seulement pour répondre aux exigences réglementaires, mais aussi pour rester compétitives et fiables dans un marché très exigeant.

Cet article passe en revue les changements attendus, les impacts pratiques, et ce qu’il faut anticiper tant pour le secteur médical que pour l’automobile, voire les produits logiciels plus larges soumis à des contraintes sécurité / cybersécurité.

Pourquoi une mise à jour ?
Historiquement, la norme IEC 62304 définissait les exigences du cycle de vie pour les logiciels intégrés dans des dispositifs médicaux (ou pour des logiciels constitutifs d’un dispositif médical).

Mais l’écosystème logiciel de santé a changé : explosion des SaMD (Software as Medical Device), des applications de santé, des plateformes de télésanté, des logiciels SaaS santé, parfois basés sur de l’IA/ML. Pour rester pertinent, la norme doit évoluer.

Ainsi la version 2 vise à étendre le périmètre à l’ensemble des « logiciels de santé », pas seulement les logiciels embarqués dans un dispositif.

Ce qui change : les principaux points

• Remplacement des classes A/B/C par des « Rigor Levels » (I & II) : la classification par risque devient un modèle de niveaux de rigueur de processus. Cela simplifie la classification mais peut déplacer des produits (ex. beaucoup de B → niveau supérieur), donc potentiellement plus d’exigences documentaires pour certains logiciels.
• Périmètre élargi : l’édition 2 couvrira les logiciels de santé autonomes (SaMD), les applications de santé, les plateformes, en plus des logiciels embarqués. 
• Prise en compte de l’IA / ML dans le contexte des logiciels médicaux : un projet de norme compagnon, IEC 63521 (Machine Learning–enabled Medical Device – Performance Evaluation Process), a été ouvert en 2025 pour encadrer l’évaluation des performances des logiciels médicaux intégrant de l’IA. 
• Renforcement des exigences de maintenance, traçabilité, gestion des risques logiciel : l’édition 2 reprend et clarifie les processus de développement, maintenance, gestion de configuration, gestion des risques, résolution de problèmes. 
• Conjugaison avec d’autres normes : IEC 62304 ne peut plus être utilisée seule. Pour un logiciel de santé ou un dispositif médical, il faut aussi intégrer des normes de gestion des risques (ISO 14971), de qualité (ISO 13485), éventuellement des normes de sécurité électrique ou d’interface (selon le type de matériel). 
• Préparation à la conformité à venir : selon plusieurs sources, la publication finale de l’édition 2 de IEC 62304 pourrait survenir autour de 2027.

Impacts pratiques & recommandations
Pour les acteurs du secteur santé / MedTech :

• Il faut cartographier dès maintenant vos produits logiciels : quels sont ceux qui tombent sous la nouvelle définition « health software » (SaMD, applications, plateformes), et anticiper la classification.
• Mettre en place un système qualité + gestion des risques + traçabilité, s’articulant autour de IEC 62304 + ISO 13485 + ISO 14971, voire d’autres normes selon le cas.
• Si vous utilisez (ou prévoyez d’utiliser) de l’IA dans un logiciel de santé : suivre de près l’évolution d’IEC 63521, prévoir un plan d’évaluation des performances, des tests, une documentation et un monitoring post‑market adaptés.
• Préparer la documentation de maintenance, mises à jour, gestion des versions, configuration : la maintenance logicielle sera un point clé pour la conformité.
• Si vous utilisez des outils comme CI/CD, DevOps, workflows agiles : il faudra adapter vos processus pour garantir la qualité, la traçabilité, la conformité à IEC 62304. L’utilisation d’un outil de gestion projet/qualité comme Polarion peut aider.

Contexte & besoin de mise à jour
L’industrie automobile évolue rapidement : montée des architectures zonales, des calculateurs HPC, des mises à jour OTA, des fonctions d’aide à la conduite (ADAS), de plus en plus souvent basées sur l’IA/ML. Pour rester pertinent, le standard de sécurité fonctionnelle des véhicules, ISO 26262, doit évoluer.

L’édition 3 cherche à adapter le standard à ces réalités techniques modernes — en facilitant l’intégration de l’agile/DevOps, des mises à jour continues, des modèles de développement modernes, des architectures distribuées, et la gestion de la sécurité logicielle à long terme.

Changements majeurs

• Mise à jour du vocabulaire et de la structure : nouveaux concepts (zonal, fail‑operational, compute‑defined vehicles, etc.), meilleure organisation des work products, plus de souplesse pour des méthodes modernes de développement.
• Adaptation aux architectures modernes et à l’OTA / lifecycle logiciel : les mises à jour logicielles après livraison, les patchs, l’évolution continue (tout cela sera mieux encadré (safety case, validation, suivi, preuve)). 
• Prise en compte de l’IA / ML et des logiciels complexes : recommandations pour l’intégration des algorithmes, méthodes de validation adaptées, traçabilité, justification des choix d’architecture, etc. 
• Meilleur support pour les méthodes agiles / DevOps / CI‑CD : ce qui facilitera la convergence entre développement logiciel moderne et sécurité fonctionnelle.

Ce que cela implique pour les acteurs automobile & systèmes embarqués

• Dès maintenant, suivre les drafts officiels et la communication des comités standards (ISO/TC), pour anticiper les changements.
• Adapter les Safety Cases existants ou prévus : prendre en compte l’OTA, la maintenance, les mises à jour, les obligations de suivi post‑market, le monitoring, la traçabilité logicielle.
• Si utilisation d’IA/ML : prévoir des preuves spécifiques, des protocoles de validation, des stratégies de mitigation des risques, documentation, justification des algorithmes.
• Organiser la gouvernance : impliquer les équipes de sécurité fonctionnelle, cybersécurité, architecture logicielle, qualité, validation car les exigences sont de plus en plus transversales.

À l’aube d’un renouvellement majeur des cadres normatifs, IEC 62304 pour les logiciels de santé, ISO 26262 pour l’automobile, il est devenu primordial pour les équipes R&D / qualité / conformité / architecture / cybersécurité de prendre un peu d’avance.

Voici les recommandations stratégiques :

1. Lancer une analyse d’écart (gap analysis) dès aujourd’hui, en prenant comme base les drafts disponibles d’IEC 62304 édition 2 et les communications autour de ISO 26262 édition 3, pour identifier les écarts de vos processus, documentations, architecture, gouvernance, tests, maintenance.
2. Mettre en place une gouvernance transversale entre qualité, sécurité, cybersécurité, développement, data (si IA), produit et conformité : pour anticiper les exigences de plus en plus croisées et complexes.
3. Adopter un Système de Management de la Qualité (SMQ), basé sur ISO 13485 (pour le médical) ou des principes équivalents selon votre domaine, afin d’organiser les processus, la documentation, la traçabilité, les risques, les audits.
4. Préparer les preuves pour l’IA / ML / logicels complexes / maintenance / OTA / post‑market : documentation, validation, performances, suivi, mise à jour, plan de surveillance.
5. Surveiller les autres normes & régulations émergentes : pour le secteur médical (IEC 82304‑1, IEC 81001‑5‑1, ISO 14971, etc.), pour la cybersécurité logicielle et des produits connectés (CRA), pour la sûreté, pour la conformité réglementaire (MDR/IVDR, marquage CE), pour la traçabilité, le cycle de vie produit, la maintenance.
6. Anticiper l’organisation des audits / conformité / certification / marquage : impliquer tôt les équipes conformité, qualité, éventuellement notifier des organismes notifiés (« notified bodies »), lorsque requis (notamment si vous ciblez un marché européen).

Entre nouvelles normes, révisions majeures et réglementations européennes, les deux prochaines années vont profondément redessiner notre quotidien technique : Ces jalons ne sont pas que des dates, ce sont des opportunités d’améliorer vos pratiques, renforcer vos processus et garantir la conformité de vos systèmes embarqués.