Cyber Resilience Act : ce qui devient obligatoire le 11 septembre 2026

Le 11 septembre 2026, le Cyber Resilience Act (CRA) franchit sa première étape opérationnelle. Ce n’est pas une date symbolique de plus dans le calendrier réglementaire européen. C’est le moment où la sécurité des produits numériques cesse d’être une bonne pratique pour devenir une obligation vérifiable.

Ce qui devient applicable le 11 septembre

À cette date, les fabricants de produits comportant des éléments numériques devront signaler les vulnérabilités activement exploitées, ainsi que certains incidents graves affectant la sécurité de leurs produits. Le signalement se joue dans des délais courts. C’est la première brique d’un dispositif qui montera en charge jusqu’à son application pleine et entière en décembre 2027.

L’ANSSI le rappelle : le CRA couvre l’ensemble du cycle de vie du produit. Identification des composants, gestion des vulnérabilités, correctifs, tests de sécurité, divulgation coordonnée, distribution sécurisée des mises à jour. La sécurité n’est plus un état à démontrer au moment de la mise sur le marché. C’est un processus à tenir dans la durée.

Ce que l’échéance change concrètement

Jusqu’ici, en cas d’alerte, un éditeur pouvait se donner le temps de découvrir qu’une bibliothèque vulnérable se trouvait « quelque part » dans son produit. À partir du 11 septembre, ce temps n’existe plus.

Il faudra être capable de dérouler rapidement toute la chaîne :

CVE → composant → SBOM → versions du produit → clients exposés → qualification → notification.

Chaque flèche de cette chaîne est un endroit où l’on perd aujourd’hui des heures, parfois des jours. Or l’obligation de signalement, elle, se compte en heures.

De la bonne pratique DevSecOps à la capacité de conformité

C’est là le vrai basculement. Le CRA transforme progressivement quatre disciplines, jusqu’ici réservées aux équipes matures, en capacités de conformité opposables :

le SBOM (Software Bill of Materials, la nomenclature exhaustive des composants d’un logiciel) ;
le SCA (Software Composition Analysis, l’analyse continue de ces composants) ;
le PSIRT (Product Security Incident Response Team, la fonction qui traite les incidents de sécurité produit) ;
la sécurité de la chaîne d’approvisionnement logicielle au sens large.

Ces pratiques existaient déjà. La nouveauté, c’est qu’elles deviennent exigibles. Ne pas les avoir n’est plus un simple retard technique. C’est un défaut de conformité.

Trois questions à se poser dès maintenant

La question n’est plus « avons-nous un SBOM ? », mais « à partir d’un simple identifiant de vulnérabilité, à quelle vitesse sommes-nous capables de dire quels produits, quelles versions et quels clients sont exposés ? ».

Le SBOM est-il vivant ? Est-il généré automatiquement à chaque build, tenu à jour, et interrogeable par requête ? Un SBOM produit une fois par an dans un tableur ne sert à rien sous pression.
La chaîne « vulnérabilité → clients exposés » est-elle outillée et testée, ou repose-t-elle sur la mémoire de deux personnes ?
Le processus de notification existe-t-il vraiment ? Qui décide, qui rédige, vers quelle autorité, dans quel délai ? Et surtout : a-t-il déjà été joué au moins une fois ?

Comme pour tout dispositif de crise, connaître la procédure ne suffit pas. Il faut l’avoir répétée avant d’en avoir besoin.

Comment SCAFE accompagne cette mise en conformité

Chez SCAFE, nous abordons le CRA non pas comme une contrainte administrative de plus, mais comme la formalisation de ce qu’une chaîne de fabrication logicielle maîtrisée devrait déjà faire.

Notre accompagnement s’appuie sur trois leviers :

La gestion outillée des vulnérabilités (SecureVul) pour construire et maintenir la visibilité « composant → produit → client exposé », et réduire le délai entre la publication d’une vulnérabilité et sa qualification.
La sécurisation de la chaîne de développement (DevSecOps et SecureApp) : génération automatique du SBOM, analyse de composition logicielle, intégration des contrôles de sécurité dans le pipeline, et durcissement des environnements de build.
La distribution sécurisée des mises à jour, appuyée sur une infrastructure de Cloud de confiance (OVH, Scaleway, IONOS), pour répondre à l’exigence de correctifs livrés de bout en bout dans des conditions maîtrisées.

L’objectif n’est pas de cocher une case réglementaire. C’est de doter vos équipes de la capacité à répondre vite, et à le prouver, le jour où une vulnérabilité activement exploitée touchera l’un de vos composants.

Le 11 septembre n’est qu’une première marche

Les obligations complémentaires du CRA entreront pleinement en application en décembre 2027. Les organisations qui prennent de l’avance maintenant ne le font pas pour la forme. Elles le font parce que la capacité à répondre rapidement à une vulnérabilité exploitée est, de toute façon, une compétence de survie.

La vraie question, à quelques semaines de la première échéance : si une vulnérabilité activement exploitée touchait un de vos composants demain matin, combien de temps vous faudrait-il pour savoir qui est exposé, et pour le notifier ?

Sources : CERT-FR (CERTFR-2026-CTI-002) et cadre réglementaire du Cyber Resilience Act, cyber.gouv.fr / ANSSI.

Image générée par Intelligence Artificielle