Auteur : \u00e9quipe de contenu de TJC Group<\/p>\n\n
\u00c0 partir du 11e<\/sup><\/strong> septembre 2026, les fabricants de produits comportant des \u00e9l\u00e9ments num\u00e9riques couverts par la loi europ\u00e9enne sur la cyber-r\u00e9silience (CRA)<\/a> feront face \u00e0 une nouvelle obligation de notification.<\/strong> Lorsqu’ils prennent connaissance d’une vuln\u00e9rabilit\u00e9 activement exploit\u00e9e ou d’un incident de s\u00e9curit\u00e9 grave r\u00e9pondant aux crit\u00e8res de l’article 14, la premi\u00e8re notification doit \u00eatre soumise dans les 24 heures.<\/p>\n\n Pour les d\u00e9veloppeurs de logiciels, y compris les entreprises qui cr\u00e9ent des produits pour les environnements SAP, il est d\u00e9sormais obligatoire de savoir ce qui doit \u00eatre signal\u00e9 et comment les informations requises parviennent aux autorit\u00e9s dans les d\u00e9lais impartis. Lorsque les clients identifient de tels probl\u00e8mes, ils doivent en informer le fournisseur. <\/p>\n\n La loi sur la cyber-r\u00e9silience (CRA)<\/a><\/strong> est un r\u00e8glement de l’UE con\u00e7u pour renforcer la cybers\u00e9curit\u00e9 des produits mat\u00e9riels et logiciels comportant des \u00e9l\u00e9ments num\u00e9riques mis \u00e0 disposition sur le march\u00e9 europ\u00e9en.<\/p>\n\n La Commission europ\u00e9enne a propos\u00e9 la l\u00e9gislation le 15 septembre 2022. Le r\u00e8glement final est entr\u00e9 en vigueur le 10e<\/sup> d\u00e9cembre 2024, tandis que la plupart des dispositions deviendront pleinement applicables \u00e0 partir du 11e<\/sup><\/strong><\/strong> d\u00e9cembre 2027<\/strong>. Les exigences de notification de l’article 14<\/strong> arrivent plus t\u00f4t, \u00e0 partir du 11e<\/sup> septembre 2026.<\/strong> <\/p>\n\n La CRA vise \u00e0 \u00e9tablir des exigences de cybers\u00e9curit\u00e9 pour le d\u00e9veloppement et la maintenance des produits num\u00e9riques, tout en fournissant aux utilisateurs de meilleures informations sur la s\u00e9curit\u00e9 des produits qu’ils ach\u00e8tent et utilisent.<\/p>\n\n Les responsabilit\u00e9s en mati\u00e8re de cybers\u00e9curit\u00e9 ne s’arr\u00eatent pas lorsque le logiciel est publi\u00e9. Les fabricants doivent \u00e9galement mettre en place les processus appropri\u00e9s pour identifier les vuln\u00e9rabilit\u00e9s, g\u00e9rer les incidents de s\u00e9curit\u00e9, maintenir les produits et fournir des mises \u00e0 jour de s\u00e9curit\u00e9 tout au long du cycle de vie pertinent du produit. <\/p>\n\n L’article 14 ajoute une obligation de notification urgente \u00e0 cette responsabilit\u00e9 plus large.<\/p>\n\n Pour les d\u00e9veloppeurs de logiciels dans l’\u00e9cosyst\u00e8me SAP, la CRA devient particuli\u00e8rement pertinente lorsqu’ils d\u00e9veloppent et mettent sur le march\u00e9 de l’UE leurs propres produits comportant des \u00e9l\u00e9ments num\u00e9riques.<\/p>\n\n L’article 14 se concentre sur deux types sp\u00e9cifiques d’\u00e9v\u00e9nements de s\u00e9curit\u00e9.<\/p>\n\n Une vuln\u00e9rabilit\u00e9 activement exploit\u00e9e<\/strong> est une vuln\u00e9rabilit\u00e9 pour laquelle il existe des preuves fiables qu’un acteur malveillant l’a exploit\u00e9e dans un syst\u00e8me sans l’autorisation du propri\u00e9taire du syst\u00e8me.<\/p>\n\n Cela ne signifie pas que chaque vuln\u00e9rabilit\u00e9 d\u00e9couverte dans un produit logiciel devient un rapport de l’article 14. La distinction d\u00e9pend de la preuve d’exploitation plut\u00f4t que de la simple d\u00e9couverte de la vuln\u00e9rabilit\u00e9. <\/p>\n\n Par exemple, une \u00e9quipe de d\u00e9veloppement peut identifier une faiblesse lors de tests internes et la corriger avant qu’il n’y ait de preuve d’exploitation malveillante. La vuln\u00e9rabilit\u00e9 n\u00e9cessite toujours un traitement appropri\u00e9, mais elle ne r\u00e9pond pas \u00e0 la d\u00e9finition de l’article 14 d’une vuln\u00e9rabilit\u00e9 activement exploit\u00e9e simplement parce qu’elle existe. <\/p>\n\n Ce n’est pas la m\u00eame chose que de simplement d\u00e9couvrir une CVE ou une vuln\u00e9rabilit\u00e9. Une CVE affectant UI5, Node.js, Java, une d\u00e9pendance SAP BTP ou un composant ABAP n’est pas automatiquement signalable en vertu de l’article 14. Il en va de m\u00eame pour un exploit publi\u00e9 sur GitHub, une conclusion de test d’intrusion, une preuve de concept d\u00e9montr\u00e9e par un chercheur autoris\u00e9 ou un rapport de prime aux bogues sans preuve d’utilisation malveillante. La FAQ du CRA Hub<\/a> distingue sp\u00e9cifiquement la recherche en s\u00e9curit\u00e9 de bonne foi de l’exploitation malveillante. <\/p>\n\n L’article 14 couvre \u00e9galement les incidents graves ayant un impact sur la s\u00e9curit\u00e9 d’un produit comportant des \u00e9l\u00e9ments num\u00e9riques.<\/p>\n\n L’ENISA d\u00e9crit un incident affectant la s\u00e9curit\u00e9 d’un produit comme un incident qui affecte n\u00e9gativement, ou est susceptible d’affecter n\u00e9gativement, la capacit\u00e9 du produit \u00e0 prot\u00e9ger la disponibilit\u00e9, l’authenticit\u00e9, l’int\u00e9grit\u00e9 ou la confidentialit\u00e9 de ses donn\u00e9es ou fonctions. L’article 14 \u00e9tablit ensuite le seuil \u00e0 partir duquel cet incident est consid\u00e9r\u00e9 comme grave. <\/p>\n\n L’article 14 de la CRA<\/a> d\u00e9finit un incident grave comme un incident qui peut affecter des donn\u00e9es ou fonctions sensibles\/importantes, ou lorsqu’il a conduit ou pourrait conduire \u00e0 l’introduction\/ex\u00e9cution de code malveillant dans le produit ou le r\u00e9seau de l’utilisateur.<\/p>\n\n La d\u00e9finition sous-jacente d’un \u00ab incident \u00bb provient de la directive NIS2<\/a>, et elle fait r\u00e9f\u00e9rence \u00e0 \u00ab un \u00e9v\u00e9nement compromettant la disponibilit\u00e9, l’authenticit\u00e9, l’int\u00e9grit\u00e9 ou la confidentialit\u00e9 \u00bb. En d’autres termes, une vuln\u00e9rabilit\u00e9 purement th\u00e9orique n’est pas en soi un incident. <\/p>\n\n Une erreur logicielle de routine ou un probl\u00e8me technique mineur ne doit pas automatiquement \u00eatre trait\u00e9 comme un \u00e9v\u00e9nement de l’article 14. Le fabricant doit \u00e9valuer la nature de l’incident et son impact r\u00e9el ou potentiel sur la s\u00e9curit\u00e9. <\/p>\n\n Le processus de notification commence lorsque le fabricant prend connaissance<\/strong> de la vuln\u00e9rabilit\u00e9 activement exploit\u00e9e ou de l’incident de s\u00e9curit\u00e9 grave.<\/p>\n\n Cela rend l’escalade interne particuli\u00e8rement importante.<\/p>\n\n Une pr\u00e9occupation de s\u00e9curit\u00e9 peut d’abord atteindre un d\u00e9veloppeur, une \u00e9quipe de support, un employ\u00e9 en contact avec les clients ou un sp\u00e9cialiste de la cybers\u00e9curit\u00e9. Si l’organisation n’a pas de voie claire pour faire remonter les \u00e9v\u00e9nements potentiels de l’article 14, une partie de la fen\u00eatre de notification peut s’\u00e9couler avant que la bonne \u00e9quipe ne soit impliqu\u00e9e. <\/p>\n\nPrincipaux points \u00e0 retenir<\/h2>\n\n
\n
Qu’est-ce que la loi europ\u00e9enne sur la cyber-r\u00e9silience ?<\/h2>\n\n
Que requiert l’article 14 de la CRA ?<\/h2>\n\n
Vuln\u00e9rabilit\u00e9s activement exploit\u00e9es<\/h3>\n\n
Incidents de s\u00e9curit\u00e9 graves<\/h3>\n\n
Quand le d\u00e9lai de notification commence-t-il ?<\/h2>\n\n
Calendrier de notification de l’article 14<\/h2>\n\n