Loi européenne sur la cyberrésilience : quelles notifications à partir de septembre 2026 ?

La loi européenne sur la cyberrésilience (Cyber Resilience Act, CRA) n’a pas commencé à s’appliquer dans son ensemble le 11 septembre 2026. Cette date marque le début de ses obligations de notification : à compter de cette date, les fabricants concernés doivent signaler certaines vulnérabilités activement exploitées et les incidents graves qui ont une incidence sur la sécurité de leurs produits comportant des éléments numériques. L’application générale du règlement est prévue pour le 11 décembre 2027. Il s’agit de deux étapes distinctes ; les confondre peut conduire à croire à tort que toutes les obligations de la loi s’appliquent déjà ou, à l’inverse, qu’aucune n’est encore en vigueur.

Le texte est le règlement (UE) 2024/2847. Son champ d’application couvre les produits matériels et logiciels comportant des éléments numériques mis sur le marché de l’Union, y compris certains composants commercialisés séparément. Il ne s’agit pas d’une obligation universelle imposée à toute personne qui découvre une faille : les principales obligations de notification de l’article 14 incombent aux fabricants lorsque les critères prévus par le règlement sont remplis. La Commission décrit la CRA comme un cadre horizontal d’exigences de cybersécurité applicables à ces produits ; pour trancher des cas particuliers, il faut toutefois consulter le texte juridique et déterminer si le produit et l’entité relèvent de son champ d’application. Commission européenne : présentation de la CRA et texte du règlement.

L’obligation de notification n’est déclenchée ni par toute vulnérabilité potentielle ni par tout incident informatique survenu dans une entreprise. Selon les orientations de la Commission, elle concerne les vulnérabilités activement exploitées et les incidents graves ayant une incidence sur la sécurité d’un produit comportant des éléments numériques. L’évaluation exige donc de distinguer un problème connu ou théorique d’un problème qui fait l’objet d’une exploitation, puis d’établir si l’incident affecte la sécurité du produit. Les orientations résument le régime ; elles ne remplacent pas les définitions, les conditions et les exceptions du règlement. Commission européenne : obligations de notification.

L’acteur principalement soumis à l’obligation est le fabricant, et non automatiquement chaque utilisateur, chercheur ou distributeur qui signale une faille. La loi prévoit également des obligations pour les open-source software stewards, mais selon une disposition et un calendrier différents : la Commission indique qu’elles s’appliquent à partir du 11 décembre 2027, conformément à l’article 24, paragraphe 3, et à l’article 71, paragraphe 2. Cela ne signifie pas que tout projet open source est déjà soumis, du seul fait de son caractère ouvert, aux mêmes obligations qu’un fabricant. La qualification de l’entité et son rôle précis dans le cycle de vie du produit comptent ; en cas de doute, il ne faut pas trancher uniquement en fonction d’une appellation commerciale ou du fait que le code soit ouvert.

Les délais commencent lorsque le fabricant prend connaissance de l’événement concerné. Les orientations de la Commission fixent une alerte initiale dans un délai maximal de 24 heures, puis une notification plus complète dans un délai maximal de 72 heures. Pour une vulnérabilité activement exploitée, le rapport final doit être transmis au plus tard 14 jours après la mise à disposition d’une mesure corrective. Dans le cas d’un incident grave, le rapport final doit être remis dans le mois suivant la notification à 72 heures. Ces délais sont distincts et ne doivent pas être ramenés à un seul délai de réponse.

Le tableau récapitule les délais publiés par la Commission, mais ne remplace pas l’article 14 et ne reprend pas tous les détails de chaque procédure. Les entreprises doivent notamment distinguer la catégorie d’événement signalée et documenter la date à laquelle elles en ont pris connaissance ainsi que celle à laquelle la mesure corrective est devenue disponible. Les orientations officielles détaillent ces délais dans le cadre du régime de notification de la CRA. Source.

La Commission indique que les fabricants effectuent une seule notification au moyen de la Single Reporting Platform (SRP), plateforme commune au régime de la CRA. La notification est adressée à l’équipe de réponse aux incidents de sécurité informatique (CSIRT) correspondant au lieu où le fabricant a son établissement principal. La Commission précise également que, sauf circonstances exceptionnellement particulières, les informations sont communiquées aux autres autorités concernées. Ainsi, « une seule fois » décrit le canal de transmission indiqué ; cela ne garantit pas l’absence d’échanges ultérieurs avec les autorités.

ENISA publie la page consacrée à la SRP et des ressources d’accompagnement, notamment une foire aux questions et des guides d’utilisation. Ces ressources permettent de comprendre le canal et ses fonctions ; elles ne changent pas, à elles seules, les personnes tenues de notifier, les faits qui déclenchent l’obligation ni les délais légaux. Pour les organisations concernées, il est utile d’identifier à l’avance le responsable interne, la procédure d’escalade des événements et les informations nécessaires pour déposer puis mettre à jour une notification. La plateforme fait partie du processus de signalement, mais elle ne remplace ni la gestion technique de la vulnérabilité ni l’obligation de prendre des mesures correctives. ENISA : Single Reporting Platform.

Pour les fabricants, la date de septembre 2026 justifie de vérifier si leurs produits relèvent du champ de la CRA et si leurs procédures leur permettent de réagir dans les délais. La préparation peut comprendre une procédure d’enregistrement de l’heure de prise de connaissance, de classification de l’événement, de coordination des équipes techniques et juridiques et de préparation des communications successives. Il convient également d’examiner les produits déjà commercialisés : les orientations de la Commission fixent la date et les catégories à signaler, tandis que le texte juridique doit être consulté pour déterminer les dispositions de champ d’application et de transition qui s’appliquent au cas concerné.

Pour les personnes qui achètent ou utilisent des appareils et des logiciels, cette date ne signifie ni qu’elles doivent déposer ces rapports ni que tous les produits ont soudain reçu une nouvelle certification. La CRA introduit aussi des exigences applicables aux fabricants en matière de conception, de développement et de maintenance sécurisés, mais l’application générale du règlement commence en décembre 2027. Dans la pratique, les utilisateurs peuvent demander à leur fournisseur des renseignements sur les mises à jour, l’assistance et la gestion des vulnérabilités, sans supposer que le début de l’obligation de signalement garantit à lui seul qu’un produit est exempt de failles. Signaler un problème et le supprimer sont des tâches liées, mais distinctes.

La conclusion vérifiable est circonscrite : au 3 octobre 2026, les obligations de signalement de la CRA s’appliquent depuis le 11 septembre aux fabricants et aux événements décrits par la Commission ; l’application générale du règlement suit un autre calendrier, et l’obligation spécifique des open-source software stewards commence en décembre 2027. La Commission désigne la SRP comme canal de notification et publie les principaux délais. Ces éléments suffisent à corriger l’idée que le changement n’est encore qu’une perspective future, mais pas à trancher la situation de chaque entreprise ou produit.

Il convient de préserver certaines limites. Cette explication s’appuie sur le règlement, les orientations publiques de la Commission et les ressources opérationnelles d’ENISA ; elle ne comprend ni entretiens ni conseil juridique individuel et ne vise pas à déterminer si un produit particulier est couvert ou si un incident atteint les seuils légaux. Les réponses dépendent des faits et de la lecture du texte complet, y compris de ses définitions et exceptions. En situation réelle, les organisations devraient vérifier le règlement (UE) 2024/2847 et la documentation SRP en vigueur, et solliciter un conseil spécialisé lorsque la qualification de l’événement ou de l’acteur n’est pas claire.