Cyber Resilience Act : ce qui change pour les éditeurs depuis septembre 2026
Le Cyber Resilience Act (CRA) poursuit son déploiement et franchit une étape importante. Depuis le 11 septembre 2026, les éditeurs de logiciels et les entreprises commercialisant des produits numériques concernés par le règlement doivent signaler certaines vulnérabilités exploitées et certains incidents de sécurité graves.
Derrière cette nouvelle échéance réglementaire se dessine un enjeu plus large : mieux protéger les produits numériques, renforcer la confiance de leurs utilisateurs et encourager les entreprises à inscrire la cybersécurité dans la durée.
Le Cyber Resilience Act entre dans sa phase opérationnelle
Adopté en 2024, le Cyber Resilience Act a pour ambition de renforcer la sécurité des produits comportant des éléments numériques, qu’il s’agisse de logiciels, d’applications ou d’équipements connectés.
L’idée est simple : faire de la cybersécurité une préoccupation à part entière, dès la conception d’un produit et tout au long de son cycle de vie.
Le règlement s’adresse notamment aux éditeurs de logiciels et aux entreprises qui développent ou commercialisent des produits numériques sous leur propre nom ou marque, lorsqu’ils répondent à la définition de « fabricant » au sens du texte européen. Si la majorité des exigences du CRA entrera en application le 11 décembre 2027, certaines obligations sont d’ores et déjà effectives.
Depuis le 11 septembre 2026, les entreprises concernées doivent en effet signaler les vulnérabilités activement exploitées ainsi que les incidents graves ayant un impact sur la sécurité de leurs produits. Cette première échéance donne une dimension très concrète au règlement et invite les acteurs du numérique à faire évoluer leurs pratiques.
Des vulnérabilités à signaler dans des délais stricts
L’un des premiers changements concerne le signalement des failles de sécurité et des incidents. Lorsqu’un éditeur ou un fournisseur de solution numérique concerné découvre une vulnérabilité activement exploitée affectant son produit, ou prend connaissance d’un incident grave ayant un impact sur sa sécurité, il doit désormais réagir dans des délais précis :
- Sous 24 heures : transmettre une première alerte après avoir pris connaissance de la vulnérabilité ou de l’incident.
- Sous 72 heures : apporter des informations complémentaires à travers une notification plus détaillée.
- Dans les délais réglementaires suivants : remettre un rapport final, au plus tard 14 jours après la disponibilité d’une mesure corrective ou d’atténuation pour une vulnérabilité activement exploitée, ou dans le mois suivant la notification à 72 heures pour un incident grave.
Ces déclarations passent par une plateforme européenne unique de signalement mise en place par l’ENISA, l’Agence de l’Union européenne pour la cybersécurité.
Rassurons-nous toutefois sur un point : il ne s’agit pas de déclarer chaque faille identifiée dans un logiciel. Les obligations portent sur les vulnérabilités faisant l’objet d’une exploitation active, ainsi que sur les incidents répondant aux critères de gravité prévus par le règlement. Autre élément à garder à l’esprit : ces dispositions concernent également les produits numériques déjà présents sur le marché européen, dès lors qu’ils entrent dans le champ du CRA.
Une responsabilité qui s’inscrit désormais dans le quotidien des éditeurs
Pour les éditeurs de logiciels et les entreprises qui développent des solutions numériques, ces nouvelles obligations vont au-delà d’une simple formalité administrative. Elles supposent de pouvoir détecter rapidement un incident, en comprendre les conséquences et disposer des bonnes informations pour agir dans les délais impartis.
Car identifier une faille est une chose. Savoir précisément quels produits sont concernés, quelles versions sont affectées et quels composants sont en cause en est une autre. Cela implique de bien connaître son environnement logiciel : les versions déployées, les composants utilisés, les dépendances techniques ou encore les modalités de suivi et de mise à jour.
Cette visibilité est d’autant plus importante que les logiciels s’appuient aujourd’hui sur des écosystèmes technologiques de plus en plus riches, intégrant parfois de nombreuses solutions tierces ou des composants open source.
Bien connaître son patrimoine logiciel devient ainsi un véritable atout pour réagir efficacement, limiter les risques et aborder plus sereinement les nouvelles exigences réglementaires.
Sécurité et continuité numérique : deux enjeux qui se rejoignent
Au-delà des obligations de signalement, le Cyber Resilience Act invite à porter un regard plus global sur la vie des produits numériques. La cybersécurité ne se joue pas uniquement au moment de leur conception ou de leur commercialisation. Elle se construit aussi dans le temps, au fil des évolutions technologiques, des mises à jour et des nouvelles vulnérabilités qui peuvent apparaître.
Cette réalité soulève une question importante : comment assurer la continuité d’exploitation d’une solution logicielle stratégique lorsque celle-ci dépend d’un éditeur ou d’un prestataire externe ?
Une entreprise peut en effet s’appuyer quotidiennement sur un logiciel essentiel à son activité sans pour autant disposer de toutes les ressources nécessaires pour intervenir dessus. Que se passe-t-il alors si l’éditeur rencontre des difficultés, si le support technique s’interrompt ou si certaines compétences deviennent indisponibles ? Dans ces situations, la capacité à faire évoluer une solution, à corriger une vulnérabilité ou simplement à en assurer la continuité peut être fragilisée.
Anticiper ces risques passe aussi par une meilleure connaissance et une maîtrise renforcée de ses actifs logiciels. Conserver une documentation technique à jour, identifier les composants critiques, mieux connaître ses dépendances et anticiper les conditions de réversibilité sont autant de bonnes pratiques pour gagner en autonomie et en sérénité.
L’escrow agreement (ou entiercement logiciel) s’inscrit pleinement dans cette démarche. Sans constituer à lui seul une réponse aux obligations du Cyber Resilience Act, il contribue à préparer certaines situations de défaillance d’un fournisseur et à préserver, dans les conditions contractuelles prévues, les moyens nécessaires à la continuité d’exploitation de solutions logicielles essentielles. L’enjeu est finalement de ne pas attendre qu’une difficulté survienne pour se poser la question de la continuité.
Décembre 2027 : une échéance à préparer dès maintenant
Si septembre 2026 marque une première étape, le Cyber Resilience Act prévoit une autre date importante : le 11 décembre 2027, à partir de laquelle ses principales exigences deviendront applicables. Celles-ci porteront notamment sur la sécurité dès la conception, la gestion des vulnérabilités, la documentation technique, l’évaluation de conformité et le marquage CE des produits concernés.
Pour les éditeurs et les entreprises commercialisant des solutions numériques, il est donc préférable d’anticiper dès aujourd’hui plutôt que d’attendre cette prochaine échéance. Cela peut passer par une meilleure organisation des processus de développement, un suivi renforcé des composants logiciels ou encore une réflexion sur les dépendances technologiques et les risques associés.
Si la démarche peut sembler exigeante, elle représente aussi une occasion de prendre du recul sur ses pratiques et de renforcer progressivement la fiabilité de ses solutions. Car au-delà de la conformité réglementaire, c’est bien la confiance des clients, des partenaires et des utilisateurs qui est en jeu.
