Prendre rendez-vous

Développement sécurisé de logiciels & produits

De la première ligne de code à l’exploitation sur le terrain : Secure Coding, cycle de développement sécurisé (SSDLC), sécurité des pipelines et de la supply chain, sécurité des produits par type – CRA, IEC 62443, UN R155/R156 avec ISO/SAE 21434, MDR/IVDR.

Mise à jour: octobre 2026 · Valeri Milke, Lead Auditor ISO 27001 & ISO 42001

Le développement sécurisé de logiciels et de produits (Secure Software Development) consiste à appliquer des exigences de sécurité démontrables sur tout le cycle de vie d’un produit – de la conception au code, au build et à la release, jusqu’au traitement des vulnérabilités sur le terrain. Le cadre dépend du type de produit : le matériel et les logiciels comportant des éléments numériques relèvent du Cyber Resilience Act (CRA), composants industriels compris ; pour ceux-ci, l’IEC 62443 fait figure d’état de l’art, et le règlement Machines s’y ajoute pour les machines dès le 20 janvier 2027. L’homologation de type des véhicules exige UN R155 et R156, généralement mis en œuvre via ISO/SAE 21434. Les dispositifs médicaux relèvent du MDR et de l’IVDR (règlements sur les dispositifs médicaux et de diagnostic in vitro), avec l’IEC 81001-5-1 comme référence. Véhicules homologués et dispositifs médicaux sont exclus du CRA : leur propre droit sectoriel s’applique.

Thèmes & pages de savoir

Chaque thème mène à une page de savoir dédiée avec des approfondissements, des guides pratiques et les prestations correspondantes.

Sécurité des produits selon leur type

C’est le type de produit qui détermine les exigences de cybersécurité applicables. Les quatre types de produits en un coup d’œil – avec leur champ d’application, les normes de référence et les échéances ; là où un droit sectoriel propre s’applique, le CRA s’efface.

CRA – produits comportant des éléments numériques

Des obligations européennes transversales pour les fabricants de matériel et de logiciels connectés – de la planification et du développement jusqu’au traitement des vulnérabilités sur tout le cycle de vie.

Produits
Matériel et logiciels comportant des éléments numériques – de l’objet connecté domestique au routeur, du système d’exploitation à l’appli
Réglementation & normes
Cyber Resilience Act ; normes harmonisées (EN 40000, ETSI EN 304) en cours, aucune encore au JOUE ; plateforme de notification ENISA
Échéances
En vigueur 10/12/2024 · règles organismes notifiés 11/06/2026 · notification 11/09/2026 · application complète 11/12/2027

IEC 62443 – industrie & OT

Série de normes internationales pour des processus de développement, des composants et des systèmes sécurisés en automatisation industrielle – facultative, mais reconnue comme état de l’art et socle des futures normes harmonisées du CRA.

Produits
Composants et systèmes d’automatisation industrielle (OT), automates et machines – pour fabricants, intégrateurs et exploitants
Réglementation & normes
IEC 62443-4-1 (processus de développement), -4-2 (composants), -3-3 (systèmes), -2-1 (exploitants) ; CRA ; règlement Machines
Échéances
Règlement Machines dès le 20/01/2027 · adaptation d’EN IEC 62443-4-1/-4-2 au CRA en cours

Véhicules – UN R155/R156 & ISO/SAE 21434

La cybersécurité conditionne l’homologation de type : les constructeurs ont besoin d’un système de management de la cybersécurité (CSMS) certifié et d’une gestion encadrée des mises à jour logicielles.

Produits
Voitures, bus, camions (M, N), remorques (O) pour les mises à jour ; nouveaux types de deux-/trois-roues et quads (L) dès le 11/12/2027
Réglementation & normes
UN R155 (CSMS), UN R156 (mises à jour logicielles), ISO/SAE 21434 comme norme d’ingénierie ; exclus du CRA
Échéances
R155 : nouveaux types depuis 06/07/2022, tous véhicules neufs depuis 07/07/2024 (grande série) · R156 : types existants depuis 07/07/2026

Dispositifs médicaux – MDR & IVDR

La sécurité informatique fait partie des exigences générales en matière de sécurité et de performances du MDR et de l’IVDR – à démontrer avant la mise sur le marché, puis à maintenir par la surveillance après commercialisation et la maintenance sur le terrain.

Produits
Dispositifs médicaux et de diagnostic in vitro, y compris le logiciel dispositif médical ; exclus du CRA
Réglementation & normes
MDR/IVDR, MDCG 2019-16 Rev. 1, IEC 81001-5-1 (référence reconnue, non harmonisée), AI Act pour les dispositifs médicaux à IA, Data Act pour les produits connectés
Échéances
MDR depuis le 26/05/2021 · IVDR depuis le 26/05/2022 · obligations haut risque de l’AI Act pour les dispositifs à IA dès le 02/08/2028
Conseil · AI Code Security

Quand les règles ne suffisent plus : la sécurité du code à l'ère de l'IA

Les scanners à base de règles trouvent de façon fiable les erreurs de syntaxe. L'autorisation cassée, la logique métier et les permissions supposées à tort n'ont, elles, aucune signature. Nous mettons règles, raisonnement IA et validation d'exploitabilité dans un ordre exploitable par vos équipes.

  • Architecture de scanning couches 1–3
  • Introduire et calibrer l'AI SAST
  • Validation d'exploitabilité
  • Responsabilité & remédiation
  • Preuves pour CRA et NIS2
Découvrir AI Code Security

Prestation de conseil — les pages de connaissance ci-dessus restent en accès libre.

Analyses approfondies

Des pages de connaissances approfondies sur les sujets qui soulèvent actuellement le plus de questions — avec des sources vérifiées et des mesures concrètes.

Gestion des risques IA en santé

Comment hôpitaux, cabinets et laboratoires exploitent l’IA en sécurité : obligations des déployeurs selon l’AI Act, lien avec le MDR, responsabilité partagée avec le fournisseur, modèle de menaces pour l’IA médicale, évaluation des risques et preuves solides.

Accéder à la page de connaissances

Maintenance des dispositifs médicaux

Comment fabricants et hôpitaux sécurisent les dispositifs médicaux connectés sur le terrain : inventaire et SBOM, triage clinique, correctifs maîtrisés, signalements de vulnérabilités organisés et circuits de notification coordonnés.

Accéder à la page de connaissances

Data Act & dispositifs médicaux

Comment les fabricants peuvent concevoir l’accès aux données des appareils exigé par la loi sans compromettre la sécurité des patients, les données de santé ni les secrets d’affaires – avec modèle de menaces, test d’intrusion et système de management intégré.

Accéder à la page de connaissances

Slopsquatting et agents de codage

Les modèles d’IA suggèrent des paquets qui n’existent pas — et des attaquants peuvent enregistrer précisément ces noms. Les agents de codage dotés d’un accès au terminal installent ce qu’ils jugent bon. Ce dossier relie typosquatting et slopsquatting dans npm et PyPI à un modèle de sécurité pour les agents de codage et leur harness : chaîne d’attaque, cinq couches de protection, obligations au titre du CRA, de NIS2 et de DORA, autoévaluation et livre blanc CISO (en allemand).

Accéder à la page de connaissances

Automotive Threat Matrix

Comment la matrice de l'Auto-ISAC décrit le comportement des attaquants sur le véhicule – et comment elle donne un langage commun à la TARA selon l'ISO/SAE 21434, à la démonstration de conformité selon l'UN R155, aux catalogues de tests de l'OWASP et au Vehicle SOC.

Accéder à la page de connaissances

Secure Coding

Comment prévenir systématiquement les vulnérabilités : la cartographie actuelle issue du CWE Top 25 et de l'OWASP Top 10:2025, l'ASVS 5.0 comme référentiel d'exigences et les pratiques qui font la différence dans le quotidien du développement.

Accéder à la page de connaissances
FAQ

Questions fréquentes sur la sécurité des produits par type

Quel cadre s’applique à quel produit – et où le Cyber Resilience Act ne s’applique-t-il pas ? Des réponses concises aux questions que posent souvent les fabricants et les responsables des affaires réglementaires.

Le Cyber Resilience Act s’applique-t-il aux dispositifs médicaux ?

Non. Les produits relevant du MDR ou de l’IVDR sont exclus du Cyber Resilience Act. Leur cybersécurité est encadrée par ces deux règlements sur les dispositifs médicaux ; le guide MDCG 2019-16 Rev. 1 et la norme IEC 81001-5-1, toujours non harmonisée, servent de référence. Les logiciels et équipements sans destination médicale – l’informatique hospitalière générale, par exemple – peuvent en revanche tout à fait relever du CRA.

Le CRA s’applique-t-il aux voitures et aux composants automobiles ?

Pas aux voitures, bus, camions et remorques homologués : ils relèvent de l’homologation de type de l’UE, qui encadre la cybersécurité par l’UN R155 et les mises à jour logicielles par l’UN R156. L’exclusion couvre en général aussi les systèmes et composants homologués pour ces véhicules. Depuis 2025, un acte délégué exclut en outre deux-roues, trois-roues et quads ; pour les nouveaux types de cette catégorie, l’UN R155 s’applique à partir du 11 décembre 2027. Produits de seconde monte, équipements de recharge ou applications hors homologation peuvent en revanche relever du CRA. Les cycles à pédales de la catégorie L1e restent également soumis au CRA.

L’IEC 62443 est-elle obligatoire ?

Non, l’IEC 62443 est une série de normes internationales, pas une loi. Elle fait toutefois figure d’état de l’art pour les composants industriels et est en cours d’adaptation au CRA – notamment par des amendements d’EN IEC 62443-4-1 et -4-2 et par des profils propres à certains produits. La présomption de satisfaire aux exigences légales (présomption de conformité) ne naît qu’une fois une version harmonisée citée au Journal officiel de l’UE ; en octobre 2026, ce n’est pas le cas.

Depuis quand l’obligation de notification du CRA s’applique-t-elle, et où notifier ?

Depuis le 11 septembre 2026, les fabricants doivent notifier les vulnérabilités activement exploitées et les incidents graves au CSIRT national compétent via la plateforme centrale de l’ENISA (Single Reporting Platform). Les délais : alerte précoce sous 24 heures, notification sous 72 heures, rapport final au plus tard 14 jours après la mise à disposition d’un correctif – pour les incidents, dans le mois qui suit la notification. L’obligation vaut aussi pour les produits mis sur le marché avant cette date.

Quelle est la différence entre l’UN R155 et l’ISO/SAE 21434 ?

L’UN R155 est un règlement d’homologation de type contraignant : sans système de management de la cybersécurité (CSMS) certifié, un type de véhicule n’est pas homologué. L’ISO/SAE 21434 est, elle, la norme d’ingénierie avec laquelle constructeurs et équipementiers mettent en œuvre les processus exigés, comme l’analyse des menaces et l’évaluation des risques (Threat Analysis and Risk Assessment, TARA). Elle n’est pas imposée par la loi, mais constitue la voie de preuve habituelle ; les lacunes, comme le catalogue de menaces de la R155, sont couvertes séparément.

Existe-t-il déjà des normes harmonisées pour le CRA ?

Pas encore. La demande de normalisation de la Commission porte sur 41 normes horizontales et spécifiques aux produits. Selon un projet de modification, non adopté en octobre 2026, les premières normes horizontales devraient être disponibles fin octobre 2026 et les normes spécifiques fin décembre 2026. Tant qu’aucune version n’est citée au Journal officiel, il n’y a pas de présomption de conformité : les fabricants justifient eux-mêmes le respect des exigences, et les produits importants de classe I doivent alors passer par un organisme notifié.

Faites de la sécurité une partie intégrante de votre développement

Lors du premier entretien, nous évaluons la maturité de votre SSDLC — et identifions les mesures qui offrent le plus grand levier dans le pipeline, le code et l’homologation produit.