Le règlement européen sur la cyberrésilience : 77 jours pour se préparer avant l'échéance de septembre 2026

Le compte à rebours a déjà commencé

Le règlement européen sur la cyberrésilience (CRA) n'est plus une perspective réglementaire lointaine — c'est un compte à rebours. Le 11 septembre 2026, la première échéance clé du CRA entre en vigueur : les fabricants et développeurs de produits comportant des éléments numériques devront notifier les vulnérabilités activement exploitées à l'ENISA et aux CSIRT nationaux. Soit dans 77 jours.

Si votre organisation développe des logiciels, commercialise du matériel connecté ou intègre des composants numériques tiers dans des produits distribués sur le marché européen, cette échéance vous concerne. Le CRA introduit des obligations qui s'étendent à votre pipeline de développement, à vos relations fournisseurs, à votre processus de réponse aux incidents et à votre gouvernance exécutive.

Ce guide explique ce que l'échéance de septembre impose, qui est dans le périmètre, quelles pénalités s'appliquent et les étapes pratiques à mettre en œuvre dès maintenant — avant que les régulateurs commencent à poser des questions.

Qu'est-ce que le règlement européen sur la cyberrésilience ?

Le CRA est entré en vigueur en décembre 2024 à l'issue d'années de travaux législatifs, déclenchés par une série d'incidents — SolarWinds, Log4Shell, MOVEit — qui ont mis en évidence le risque systémique des chaînes d'approvisionnement logicielles non sécurisées. Contrairement au RGPD (qui régit les données) ou à NIS2 (qui régit les opérations), le CRA cible les produits eux-mêmes : il impose des exigences de cybersécurité obligatoires à tout produit comportant des éléments numériques (PEN) mis sur le marché européen, couvrant l'intégralité du cycle de vie — de la conception jusqu'à la fin de vie.

Le principe central du CRA est la sécurité par défaut : les produits doivent être livrés sécurisés, sans que le client n'ait à configurer la sécurité séparément. Cette responsabilité remonte donc vers les développeurs et fabricants, plutôt que d'être laissée à l'utilisateur final.

Distinction clé : Le RGPD protège les données. NIS2 protège les opérations. Le CRA protège les produits logiciels et matériels eux-mêmes, du moment de leur conception jusqu'à leur décommissionnement.

L'échéance du 11 septembre 2026 : ce qui change

Le CRA est déployé par phases. Le 11 septembre 2026 active les obligations de notification des vulnérabilités — l'exigence opérationnellement la plus urgente pour la plupart des organisations aujourd'hui. À partir de cette date, toute vulnérabilité activement exploitée affectant votre produit déclenche une cascade de notifications stricte.

Deux aspects de ce calendrier méritent une attention particulière. Premièrement, la fenêtre de 24 heures commence dès le moment où votre organisation prend connaissance de l'exploitation active — et non à partir de l'attribution d'un CVE ou de la divulgation publique. La détection des menaces et l'alerte interne deviennent donc des contrôles de conformité à part entière. Un délai de détection se traduit directement en exposition juridique.

Deuxièmement, cette obligation s'applique à toute vulnérabilité activement exploitée — sans seuil de sévérité. Un bug de faible sévérité activement exploité doit être notifié dans les 24 heures. Une vulnérabilité critique non encore exploitée ne déclenche pas l'horloge. Le déclencheur est l'exploitation, pas la sévérité.

Qui est dans le périmètre ?

Le périmètre du CRA est intentionnellement large. Les catégories d'organisations suivantes sont directement concernées.

Fabricants

Toute organisation qui conçoit, développe ou produit des produits comportant des éléments numériques et les place sur le marché européen. Cela inclut les logiciels d'entreprise, les applications grand public, le matériel connecté, les systèmes de contrôle industriel, les micrologiciels embarqués et les équipements réseau.

Fournisseurs de logiciels en tant que service (SaaS)

Le CRA traite explicitement des produits numériques fournis à distance. Les fournisseurs SaaS entrent dans le périmètre lorsque leurs services comprennent des composants qualifiés de produits comportant des éléments numériques — notamment lorsque ces composants peuvent être téléchargés, installés ou mis à jour sur les systèmes du client. Si votre offre SaaS inclut un agent desktop, une application mobile, un connecteur sur site ou un SDK, ces composants relèvent du CRA.

Importateurs et distributeurs

Les organisations qui importent ou distribuent des produits comportant des éléments numériques sur les marchés européens doivent vérifier que les fabricants avec lesquels elles travaillent ont satisfait aux obligations du CRA. En cas de manquement du fabricant, les distributeurs et importateurs supportent des obligations résiduelles.

Projets open source

Les projets open source purement à but non lucratif sans activité commerciale sont généralement exemptés. En revanche, si votre organisation commercialise des logiciels open source — via des contrats de support, des services hébergés, des produits intégrés ou des SaaS construits sur des composants open source — vous n'êtes pas exempté.

Test pratique : Si votre organisation tire des revenus d'un produit qui inclut ou est construit sur des éléments numériques, et que ce produit est accessible à des clients européens, le CRA s'applique.

Les exigences de décembre 2027 : anticiper la deuxième vague

Le 11 septembre 2026 est la première vague. Le plein poids des obligations du CRA s'applique à partir du 11 décembre 2027. Les 18 mois séparant les deux échéances doivent être mis à profit pour les exigences structurellement plus complexes.

Nomenclature des composants logiciels (SBOM)

Les fabricants doivent maintenir et mettre à disposition une nomenclature des composants logiciels (Software Bill of Materials) — un inventaire lisible par machine de chaque composant, bibliothèque, dépendance et version inclus dans un produit. La SBOM doit être tenue à jour tout au long de la durée de vie supportée du produit.

Sécurité dès la conception

Les produits doivent être conçus avec la surface d'attaque minimale nécessaire, des configurations sécurisées par défaut, des contrôles d'accès appropriés, le chiffrement des données en transit et au repos, et la capacité à recevoir des mises à jour de sécurité tout au long de leur durée de vie supportée.

Programme de gestion des vulnérabilités

Les fabricants doivent opérer un programme formel de gestion des vulnérabilités : politiques d'identification, d'évaluation et de remédiation ; processus de divulgation coordonnée ; et enregistrements démontrant une gestion continue sur la durée de vie du produit.

Les pénalités : quels sont les enjeux

Les mécanismes d'application du CRA sont calibrés pour être significatifs :

• Jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial — pour manquement aux exigences essentielles de cybersécurité ou aux obligations de gestion des vulnérabilités
• Jusqu'à 10 millions d'euros ou 2 % du chiffre d'affaires annuel mondial — pour manquement aux obligations de notification des vulnérabilités activement exploitées
• Jusqu'à 5 millions d'euros ou 1 % du chiffre d'affaires annuel mondial — pour fourniture d'informations fausses ou trompeuses aux autorités de surveillance du marché

Au-delà des pénalités financières, les autorités nationales de surveillance du marché peuvent ordonner le retrait ou le rappel de produits non conformes. Pour les organisations dont le chiffre d'affaires dépend de l'accès au marché européen, il s'agit d'un risque existentiel pour la continuité d'activité.

Implication en matière de gouvernance : Comme pour NIS2 et DORA, les violations du CRA peuvent entraîner un examen des décisions exécutives. Les conseils d'administration doivent traiter la conformité au CRA comme une obligation fiduciaire.

Le CRA dans le contexte réglementaire plus large

Le CRA ne fonctionne pas de manière isolée. C'est l'un des trois grands règlements européens sur le numérique entrant en phase d'application active en 2026, aux côtés de NIS2 (qui émet désormais des sanctions administratives) et de DORA (appliqué au secteur financier depuis le 17 janvier 2025). Un seul incident peut déclencher des obligations simultanées sous plusieurs cadres.

Les interconnexions sont structurelles :

• Les mêmes CSIRT nationaux reçoivent à la fois les rapports de vulnérabilités du CRA et les notifications d'incidents NIS2. Pour les organisations dans le périmètre des deux cadres, le même événement d'exploitation pourrait déclencher des calendriers de notification parallèles.
• Les exigences de gestion des risques liés aux tiers ICT de DORA obligent les entités financières à évaluer le statut de conformité CRA de leurs fournisseurs. Si vous fournissez des logiciels ou des services technologiques à des clients du secteur financier, votre maturité CRA fait désormais partie de leur diligence raisonnable DORA.
• Les exigences de cybersécurité de la loi sur l'IA pour les systèmes d'IA à haut risque font référence aux exigences essentielles du CRA. Un produit d'IA qui ne satisfait pas à la conformité CRA peut également ne pas satisfaire à la conformité de la loi sur l'IA.

Votre checklist CRA en 10 étapes

1. Cartographie du périmètre. Identifiez chaque produit que votre organisation conçoit, développe, importe ou distribue susceptible de constituer un produit comportant des éléments numériques. Incluez le matériel connecté, les logiciels, les systèmes embarqués, les SDK et les composants SaaS installés sur les systèmes clients.
2. Détection des menaces et alertes. Mettez en œuvre ou renforcez la surveillance pour détecter l'exploitation active des vulnérabilités connues affectant vos produits. La fenêtre de 24 heures commence dès que vous prenez connaissance de l'exploitation — votre infrastructure de détection est donc un contrôle de conformité.
3. Enregistrement CSIRT et contacts. Identifiez et documentez formellement les canaux de notification du CSIRT national et de l'ENISA pour chaque juridiction où vos produits sont commercialisés. Au Luxembourg, l'autorité principale est le CIRCL (Computer Incident Response Center Luxembourg).
4. Mise à jour du plan de réponse aux incidents. Révisez vos procédures de réponse aux incidents pour inclure les étapes de notification CRA. Définissez qui déclenche l'alerte précoce de 24 heures, qui approuve la notification de 72 heures et qui signe le rapport final de 14 jours.
5. Inventaire des composants. Commencez à cataloguer tous les composants logiciels, bibliothèques et dépendances dans vos produits. C'est le fondement de votre SBOM.
6. Révision des contrats fournisseurs. Examinez les contrats avec tous les fournisseurs de logiciels et de technologies dont les composants figurent dans vos produits. Ajoutez des clauses alignées CRA exigeant la divulgation rapide des vulnérabilités et l'engagement sur les délais de correction.
7. Base de documentation technique. Commencez à assembler la documentation technique requise par le CRA : descriptions d'architecture, modèles de menaces, résultats des tests de sécurité et enregistrements de gestion des vulnérabilités.
8. Formalisation du programme de gestion des vulnérabilités. Établissez ou formalisez votre politique de gestion des vulnérabilités, vos processus de triage, vos délais de remédiation et vos procédures de divulgation coordonnée.
9. Sélection et pilotage d'outils SBOM. Évaluez les outils de génération et de gestion de SBOM adaptés à votre stack technologique. Pilotez l'intégration dans le pipeline CI/CD d'au moins un produit avant la fin de l'année.
10. Formation des développeurs et des dirigeants. Assurez-vous que les équipes de développement comprennent les principes de sécurité dès la conception et que les dirigeants comprennent le cadre réglementaire et les dimensions de responsabilité personnelle.

Comment ObsidianCorps peut vous aider

Nos équipes accompagnent des organisations au Luxembourg et dans la Grande Région sur des programmes de conformité réglementaire depuis l'entrée en vigueur de NIS2. La préparation au CRA est une extension naturelle de ce travail — et pour beaucoup de nos clients, les bases sont déjà partiellement en place.

Voici comment nous pouvons accélérer votre programme d'ici le 11 septembre :

• Cartographie du périmètre et analyse d'écarts CRA. Nous examinons votre portefeuille de produits, vos pratiques de développement, vos relations fournisseurs et votre documentation de sécurité actuelle par rapport aux exigences du CRA. Vous recevez un rapport de maturité priorisé identifiant les lacunes à combler avant septembre et une feuille de route vers décembre 2027.
• Conception du programme de gestion des vulnérabilités. Nous vous aidons à construire ou formaliser les politiques, processus et outillages pour la détection, le triage, la divulgation et la notification des vulnérabilités.
• Tests d'intrusion et validation de sécurité. Des tests de sécurité indépendants de vos produits vous fournissent à la fois les preuves techniques nécessaires à la documentation de conformité et une visibilité précoce sur les vulnérabilités.
• Implémentation SBOM et intégration DevSecOps. Nos équipes de développement logiciel et DevSecOps vous aident à intégrer la génération de SBOM dans votre pipeline CI/CD.
• Préparation de la documentation technique. Nous vous aidons à assembler les descriptions d'architecture, les modèles de menaces et les enregistrements de sécurité requis pour l'évaluation de conformité au CRA.
• Formation des développeurs et des dirigeants. Nous proposons des programmes de formation adaptés aux obligations du CRA, incluant des exercices de simulation de divulgation de vulnérabilité sous les délais CRA.

Si vous n'êtes pas certain que vos produits entrent dans le périmètre, ou si vous avez identifié une lacune à combler avant le 11 septembre, nous proposons une consultation initiale sans engagement. Soixante-dix-sept jours suffisent pour progresser significativement — à condition de ne pas en perdre.

Contactez ObsidianCorps pour démarrer votre évaluation de maturité CRA.