Le délai de déclaration prévu par la loi européenne sur la cyber-résilience commence le 11 septembre 2026
Découvrez quels logiciels open source en fin de vie vous exposent à des risques, puis veillez à les maintenir à jour et conformes avant que le compte à rebours ne commence.
Cette disposition s'applique à toute entreprise qui commercialise des produits sur le marché de l'Union européenne, quel que soit le lieu où se trouve son siège social.
Les obligations de déclaration prennent effet à partir du
00
JOURS
00
HORAIRES
00
MIN
00
SEC
Date limite : 11 septembre 2026
Avant le 11 septembre, sachez sur quoi vous vous tenez.
Seize questions réparties en quatre domaines, chacune étant liée au texte législatif correspondant. Découvrez votre score, vos lacunes par section et les points à améliorer en priorité. Aucune inscription n'est nécessaire pour consulter vos résultats.
16 questions
4 sections
environ 4 minutes
Votre rapport d'état de préparation à l'ARC
Conformément au règlement (UE) n° 2024/2847. Cet outil fournit des orientations générales et ne constitue ni un conseil juridique ni une attestation de conformité.
Cette liste de contrôle vous donne des indications sur votre processus. Voyez maintenant ce que contient réellement votre code.
Les questions ci-dessus visent à déterminer si vous disposez d'un processus : une politique, un point de contact, un engagement en matière de durée de support. Elles ne permettent pas de savoir si les composants open source intégrés à votre produit sont déjà en fin de vie à ce jour. Il s'agit là d'une question différente, plus concrète, et c'est celle qui donne le plus souvent lieu à une vulnérabilité devant être signalée en vertu de l'article 14.
Le délai de déclaration prévu par la loi sur la cyber-résilience commence à courir, et il est mesuré en heures, et non en trimestres.
Les fabricants de « produits comportant des éléments numériques » doivent signaler les vulnérabilités activement exploitées et les incidents graves via la nouvelle plateforme unique de signalement de la CRA. Dès qu’un fabricant constate qu’un produit présente une vulnérabilité activement exploitée (ou subit un incident de sécurité grave), un délai en trois étapes commence à courir :
Alerte précoce
Au sein de
24 heures
Notification initiale à votre CSIRT national via la plateforme unique de signalement de l'ENISA (visible simultanément par l'ENISA)
Notification complète
Au sein de
72 heures
Un rapport complet contenant les informations connues à ce jour et les mesures correctives prises.
Rapport final - Vulnérabilité exploitée
Au sein de
14 jours
Un rapport final dans les 14 jours suivant la mise à disposition d'une solution corrective.
Rapport final - Incident
Au sein de
1 mois
Un rapport final doit être remis dans un délai d'un mois en cas d'incident de sécurité grave.
Cela ne concerne pas uniquement les nouveaux produits.
L'obligation de déclaration s'applique aux produits déjà présents sur le marché de l'UE, y compris les logiciels existants. L'argument « Nous nous en occuperons avant notre prochaine version » ne tient pas. Vous ne pouvez pas simplement attendre que cela passe.
Le compte rendu passe avant tout, le reste vient ensuite.
L'ensemble des exigences essentielles (sécurité dès la conception, SBOM, marquage CE) s'appliquera ultérieurement, à compter du 11 décembre 2027. L'obligation de déclaration, qui entrera en vigueur en septembre 2026, constitue la mesure incitative à court terme.
Les sanctions, en toute clarté.
Le non-respect des obligations fondamentales peut entraîner des amendes pouvant aller jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu.
Guide de référence rapide
Date limite de remise des rapports
11 septembre 2026
Cela s'applique-t-il aux anciens produits ?
Oui
Uniquement les entreprises de l'UE ?
Non
Peine maximale
15 millions d'euros / 2,5 % du chiffre d'affaires
Exigences essentielles complètes
11 décembre 2027
Il n'est pas nécessaire d'être établi en Europe pour être concerné.
Le champ d'application dépend de la présence sur le marché, et non de la localisation du siège social. « Cela ne concerne que les entreprises de l'UE » est l'interprétation erronée la plus courante – et potentiellement la plus coûteuse – de la CRA. Cela vous concerne si l'une des situations suivantes s'applique à vous :
Vous êtes un éditeur de logiciels ou un éditeur indépendant de logiciels (ISV) qui commercialise ses produits dans l'Union européenne
Même indirectement, même par l'intermédiaire d'un partenaire de distribution, vous êtes considéré comme un « fabricant » au sens de la loi, que vous vous considériez comme tel ou non.
Vous avez des clients dans l'UE, une filiale ou une seule référence commercialisée dans l'UE
Il suffit qu'un seul produit soit mis sur le marché de l'UE. Le lieu d'implantation de votre siège social n'y change rien.
Vous êtes un responsable de la sécurité ou de la conformité et vous devez déjà répondre à des demandes concernant les SBOM et les audits
Vous devez désormais respecter un calendrier de reporting externe strict, qui s'ajoute aux cadres réglementaires auxquels vous êtes déjà soumis.
Vous savez qu'il y a des composants open source non pris en charge dans la pile, mais vous ne pouvez pas en rendre pleinement compte
Vous savez qu'il y a des composants open source non pris en charge dans la pile, mais vous ne pouvez pas en rendre pleinement compte
Ce n'est pas la date limite qui pose problème.
C'est plutôt de savoir ce que vous devrez déclarer.
Vous ne pouvez pas respecter un délai de signalement de 24 heures pour une vulnérabilité dans un composant dont vous ignoriez l'existence, mais vos auditeurs s'attendront à ce que vous le fassiez. Les logiciels open source en fin de vie et qui ne bénéficient plus d'aucun support sont précisément ceux qui passent inaperçus jusqu'à ce qu'il soit trop tard. Dès qu'un framework ne reçoit plus de mises à jour officielles, personne ne le surveille, à l'exception de HeroDevs.
EOL n'est pas un CVE
C'est simplement parce que personne ne corrige les nouvelles vulnérabilités. Votre scanner CVE n'est pas conçu pour signaler que « personne ne corrigera désormais les nouvelles vulnérabilités de ce composant ». Le fait qu'aucun CVE n'apparaisse lors des analyses des logiciels en fin de vie ne signifie pas qu'il n'y en a pas, mais simplement que votre scanner n'a pas une vue d'ensemble de la situation.
Il se cache dans les dépendances transitives
Les composants en fin de vie (EOL) qui risquent le plus de vous poser problème sont ceux que vous n'avez pas choisis directement, c'est-à-dire les dépendances de vos dépendances.
Rien de défendable à signaler
Même si vous repérez le problème à temps, aucune correction n'est prévue en amont ; vous ne pouvez donc pas présenter de solution concrète en guise de réponse de bonne foi, et vous n'avez plus le temps de vous lancer dans une mise à jour ou une migration de dernière minute.
COMMENT SE PRÉPARER AVANT SEPTEMBRE
Deux étapes : identifiez vos fondements, puis assurez-vous qu'ils soient solides.
HeroDevs comble ces deux lacunes — le problème de visibilité et celui de la correction — afin que vous puissiez signaler les problèmes en toute bonne foi, selon votre propre calendrier et non celui du framework.
Étape 1 · Visibilité
EOL Dataset vous indique lesquels de vos composants open source ont déjà atteint leur fin de vie et ne bénéficient plus d'aucun support — un risque que votre scanner CVE n'est pas conçu pour détecter. Il fonctionne en complément de vos outils SCA existants, et non en opposition à ceux-ci : ces derniers vous signalent les CVE connus ; EOL DS, quant à lui, vous montre ce qui est tombé dans l'oubli.
Identifie les dépendances abandonnées, en fin de vie ou sur le point d'arriver en fin de vie — y compris les dépendances transitives que la plupart des inventaires ne détectent pas.
Quatre statuts bien distincts, pour que vous puissiez distinguer ce qui n'est déjà plus pris en charge de ce qui le sera prochainement.
Un inventaire fiable que vous pouvez transmettre au service chargé de la conformité — un élément indispensable à toute déclaration.
S'appuyant sur des données relatives au cycle de vie de plus de 19 millions de paquets open source, la réponse concernant un composant donné est déjà disponible, ce qui évite à votre équipe d'avoir à effectuer des recherches.
Étape 2 · Remédiation
Never-Ending Support (NES)
Une fois que vous savez quels sont les produits en fin de vie (EOL), NES les maintient à jour, y compris les nouveaux CVE découverts après la fin de vie officielle d'un framework, afin que vous disposiez toujours d'informations fiables à communiquer. Des solutions de remplacement sécurisées et prêtes à l'emploi, selon votre calendrier, une résolution immédiate, sans compromis ni perturbations.
Les responsables initiaux de ces frameworks font partie de notre équipe: AngularJS, Spring, Vue, Bootstrap et bien d'autres encore.
Statut CNA — HeroDevs est en mesure de détecter et de corriger les vulnérabilités (CVE) de manière proactive, et ne se contente pas de réagir aux divulgations publiques.
Corrections pour tous les niveaux de gravité, installation prête à l'emploi — aucune modification susceptible d'affecter le fonctionnement de votre application, correction immédiate.
Lettres d'attestation — le document qu'un responsable de la conformité peut remettre à un auditeur.
Les premières questions que nous posent les équipes
Obtenez des réponses à certaines de nos questions les plus fréquemment posées.
Bien entendu, si vous ne trouvez pas la réponse que vous cherchez, n'hésitez pas à nous contacter.
Quelles sont exactement les dispositions que la NES abroge, renforce ou laisse inchangées ?
Considérez ce document comme un outil d'évaluation et non comme une garantie de conformité. Un composant en fin de vie non maintenu constitue un manquement grave à plusieurs dispositions, tandis que le support commercial permet de remédier à ces manquements. Pour d'autres dispositions, il ne fait que renforcer la conformité, tandis que pour certaines, il n'a aucune incidence.
NES comble directement le fossé
Un composant en fin de vie (EOL) est considéré ici comme un échec définitif. NES le convertit en « réussi », car le fournisseur propose à nouveau des correctifs.
Traiter et corriger sans délai les vulnérabilités, notamment en fournissant des mises à jour de sécurité.
L'ajustement le plus optimal : c'est littéralement ce que fait la méthode NES.
Gérer les vulnérabilités visées à l'annexe I, partie II, pendant toute la durée de la période de prise en charge déclarée, soit au minimum cinq ans.
La clause d'ancrage. La norme NES vous permet de définir une période de prise en charge de plus de 5 ans pour une pile contenant des composants en fin de vie.
Produit mis sur le marché sans vulnérabilités exploitables connues.
Une dépendance en fin de vie (EOL) comportant un CVE non corrigé correspond à une vulnérabilité exploitable connue au moment de son intégration. NES fournit le correctif rétroporté.
Les failles de sécurité peuvent être corrigées grâce à des mises à jour de sécurité.
Si le dépôt en amont est hors service, il n'y a aucun moyen de mise à jour. NES en rétablit un via npm, Maven ou PyPI.
Des mises à jour de sécurité diffusées sans délai et gratuitement, accompagnées de messages d'information.
L'absence de responsable signifie l'absence de diffusion. Le NES fournit à la fois l'artefact et l'avis.
Divulgation publique des vulnérabilités corrigées dès qu'une mise à jour est disponible.
Les avis de sécurité et les entrées du répertoire des vulnérabilités de HeroDevs fournissent ces informations pour ce composant.
Chaque mise à jour de sécurité reste disponible pendant au moins 10 ans, ou jusqu'à la fin de la période de support.
Vous ne pouvez pas conserver des mises à jour qui n'ont jamais été publiées. NES génère les artefacts ; la conservation reste de votre ressort.
NES renforce sa position, mais l'obligation vous incombe toujours
Vérification préalable des composants tiers
Obtenir un soutien commercial pour une dépendance en fin de vie (EOL) constitue un acte de diligence raisonnable pouvant être documenté — c'est l'élément le plus solide dont vous disposez pour vous défendre.
Prévenir le responsable de la maintenance du composant
Lorsqu'il n'y a pas de marché en amont, il n'y a pas de contrepartie. NES vous en propose une.
Déclarations toutes les 24 heures, toutes les 72 heures et tous les 14 jours
Le NES ne vous dispense pas de cette obligation. Il vous fournit une mesure corrective à laquelle vous pouvez vous référer, ce qui permet d'aboutir à un rapport final concret plutôt qu'à un simple aveu sans suite.
Nomenclature logicielle
NES ne génère pas votre SBOM : il modifie le contenu de celle-ci.
Divulgation coordonnée des vulnérabilités
HeroDevs applique une politique pour ce composant ; la politique au niveau du produit reste toutefois la vôtre.
Informations sur la période de prise en charge pour les utilisateurs
C'est le NES qui confère toute sa crédibilité à une date de fin de prise en charge annoncée.
NES n'apporte aucune solution à ces problèmes, et nous n'allons pas prétendre le contraire.
La classification des produits (articles 6 à 8), les modifications substantielles (article 20), la déclaration de conformité de l'UE (article 22), les procédures d'évaluation de la conformité (article 24), le marquage CE (article 30) et l'article 13, paragraphe 1, dans la mesure où il s'applique à votre propre code source. Si vous avez du retard dans l'évaluation de la conformité, NES n'est pas la solution à ce problème.
En un mot : NES transforme une non-conformité à l'article 13, paragraphe 8, en conformité à cet article, et change un rapport au titre de l'article 14 ne comportant aucune mesure corrective en un rapport assorti d'une mesure corrective. Pour tout le reste, il prend en charge les éléments mais ne les résout pas.
Avant le 11 septembre, sachez sur quoi vous vous tenez.
Identifiez les logiciels open source en fin de vie dont vous n'avez pas connaissance, et veillez à ce que les autres soient correctement mis à jour et prêts pour un audit — avant que le délai de déclaration ne commence à courir.