Auteur : équipe de contenu de TJC Group
À partir du 11e septembre 2026, les fabricants de produits comportant des éléments numériques couverts par la loi européenne sur la cyber-résilience (CRA) feront face à une nouvelle obligation de notification. Lorsqu’ils prennent connaissance d’une vulnérabilité activement exploitée ou d’un incident de sécurité grave répondant aux critères de l’article 14, la première notification doit être soumise dans les 24 heures.
Pour les développeurs de logiciels, y compris les entreprises qui créent des produits pour les environnements SAP, il est désormais obligatoire de savoir ce qui doit être signalé et comment les informations requises parviennent aux autorités dans les délais impartis. Lorsque les clients identifient de tels problèmes, ils doivent en informer le fournisseur.
Principaux points à retenir
- Les obligations de notification de l’article 14 de la CRA s’appliquent à partir du 11 septembre 2026.
- La CRA s’applique aux produits matériels et logiciels pertinents comportant des éléments numériques mis à disposition sur le marché de l’UE.
- Les fabricants doivent signaler certaines vulnérabilités activement exploitées et incidents de sécurité graves affectant les produits comportant des éléments numériques.
- Une alerte précoce initiale est requise sans retard injustifié et dans les 24 heures suivant la prise de connaissance.
- Une notification plus détaillée suit dans les 72 heures.
- Toutes les vulnérabilités ne déclenchent pas l’article 14. L’exigence de notification pour les vulnérabilités s’applique lorsqu’il existe des preuves fiables d’exploitation malveillante.
- Les rapports sont soumis via la plateforme unique de notification CRA de l’Agence de l’Union européenne pour la cybersécurité (ENISA), le CSIRT concerné étant désigné comme coordinateur.
- Pour les partenaires SAP qui développent leurs propres produits logiciels, la préparation doit se concentrer sur l’évaluation rapide, la propriété définie, la documentation et l’escalade.
Qu’est-ce que la loi européenne sur la cyber-résilience ?
La loi sur la cyber-résilience (CRA) est un règlement de l’UE conçu pour renforcer la cybersécurité des produits matériels et logiciels comportant des éléments numériques mis à disposition sur le marché européen.
La Commission européenne a proposé la législation le 15 septembre 2022. Le règlement final est entré en vigueur le 10e décembre 2024, tandis que la plupart des dispositions deviendront pleinement applicables à partir du 11e décembre 2027. Les exigences de notification de l’article 14 arrivent plus tôt, à partir du 11e septembre 2026.
La CRA vise à établir des exigences de cybersécurité pour le développement et la maintenance des produits numériques, tout en fournissant aux utilisateurs de meilleures informations sur la sécurité des produits qu’ils achètent et utilisent.
Les responsabilités en matière de cybersécurité ne s’arrêtent pas lorsque le logiciel est publié. Les fabricants doivent également mettre en place les processus appropriés pour identifier les vulnérabilités, gérer les incidents de sécurité, maintenir les produits et fournir des mises à jour de sécurité tout au long du cycle de vie pertinent du produit.
L’article 14 ajoute une obligation de notification urgente à cette responsabilité plus large.
Pour les développeurs de logiciels dans l’écosystème SAP, la CRA devient particulièrement pertinente lorsqu’ils développent et mettent sur le marché de l’UE leurs propres produits comportant des éléments numériques.
Que requiert l’article 14 de la CRA ?
L’article 14 se concentre sur deux types spécifiques d’événements de sécurité.
Vulnérabilités activement exploitées
Une vulnérabilité activement exploitée est une vulnérabilité pour laquelle il existe des preuves fiables qu’un acteur malveillant l’a exploitée dans un système sans l’autorisation du propriétaire du système.
Cela ne signifie pas que chaque vulnérabilité découverte dans un produit logiciel devient un rapport de l’article 14. La distinction dépend de la preuve d’exploitation plutôt que de la simple découverte de la vulnérabilité.
Par exemple, une équipe de développement peut identifier une faiblesse lors de tests internes et la corriger avant qu’il n’y ait de preuve d’exploitation malveillante. La vulnérabilité nécessite toujours un traitement approprié, mais elle ne répond pas à la définition de l’article 14 d’une vulnérabilité activement exploitée simplement parce qu’elle existe.
Ce n’est pas la même chose que de simplement découvrir une CVE ou une vulnérabilité. Une CVE affectant UI5, Node.js, Java, une dépendance SAP BTP ou un composant ABAP n’est pas automatiquement signalable en vertu de l’article 14. Il en va de même pour un exploit publié sur GitHub, une conclusion de test d’intrusion, une preuve de concept démontrée par un chercheur autorisé ou un rapport de prime aux bogues sans preuve d’utilisation malveillante. La FAQ du CRA Hub distingue spécifiquement la recherche en sécurité de bonne foi de l’exploitation malveillante.
Incidents de sécurité graves
L’article 14 couvre également les incidents graves ayant un impact sur la sécurité d’un produit comportant des éléments numériques.
L’ENISA décrit un incident affectant la sécurité d’un produit comme un incident qui affecte négativement, ou est susceptible d’affecter négativement, la capacité du produit à protéger la disponibilité, l’authenticité, l’intégrité ou la confidentialité de ses données ou fonctions. L’article 14 établit ensuite le seuil à partir duquel cet incident est considéré comme grave.
L’article 14 de la CRA définit un incident grave comme un incident qui peut affecter des données ou fonctions sensibles/importantes, ou lorsqu’il a conduit ou pourrait conduire à l’introduction/exécution de code malveillant dans le produit ou le réseau de l’utilisateur.
La définition sous-jacente d’un « incident » provient de la directive NIS2, et elle fait référence à « un événement compromettant la disponibilité, l’authenticité, l’intégrité ou la confidentialité ». En d’autres termes, une vulnérabilité purement théorique n’est pas en soi un incident.
Une erreur logicielle de routine ou un problème technique mineur ne doit pas automatiquement être traité comme un événement de l’article 14. Le fabricant doit évaluer la nature de l’incident et son impact réel ou potentiel sur la sécurité.
Quand le délai de notification commence-t-il ?
Le processus de notification commence lorsque le fabricant prend connaissance de la vulnérabilité activement exploitée ou de l’incident de sécurité grave.
Cela rend l’escalade interne particulièrement importante.
Une préoccupation de sécurité peut d’abord atteindre un développeur, une équipe de support, un employé en contact avec les clients ou un spécialiste de la cybersécurité. Si l’organisation n’a pas de voie claire pour faire remonter les événements potentiels de l’article 14, une partie de la fenêtre de notification peut s’écouler avant que la bonne équipe ne soit impliquée.
Calendrier de notification de l’article 14
| Étape de notification | Vulnérabilité activement exploitée | Incident de sécurité grave |
|---|---|---|
| Alerte précoce | Dans les 24 heures suivant la prise de connaissance | Dans les 24 heures suivant la prise de connaissance |
| Notification détaillée | Dans les 72 heures suivant la prise de connaissance | Dans les 72 heures suivant la prise de connaissance |
| Rapport final | Au plus tard 14 jours après qu’une mesure corrective ou d’atténuation devient disponible | Dans un délai d’un mois après la notification de 72 heures |
La Commission européenne et l’ENISA confirment toutes deux ces étapes de notification.
Ce que l’article 14 signifie pour les développeurs de logiciels et les partenaires SAP
Pour les organisations développant des logiciels dans le paysage SAP, l’article 14 fait de la qualification des événements de sécurité un processus urgent.
Évaluation rapide des vulnérabilités
Les équipes de développement et de sécurité doivent faire la distinction entre :
- un défaut logiciel ordinaire ;
- une vulnérabilité nécessitant une correction ;
- une vulnérabilité activement exploitée ;
- un incident de sécurité ; et
- un incident suffisamment grave pour répondre aux critères de l’article 14.
L’objectif est de s’assurer que les événements potentiellement signalables atteignent les personnes appropriées assez rapidement pour qu’une décision puisse être prise.
Qui est responsable de la réponse ?
Les fabricants doivent désormais désigner la ou les personnes ou équipes responsables de :
- évaluer si l’incident doit être signalé ; et
- le signaler dûment à l’ENISA dans le délai de 24 heures
Conserver un enregistrement clair de la réponse
Un enregistrement fiable de la réponse doit également être conservé. Il doit être possible d’établir quand le problème a été identifié pour la première fois, quand le fabricant en a pris connaissance, quel produit et quelle version ont été affectés, quelles preuves étaient disponibles et comment l’évaluation initiale de la sécurité a été effectuée.
Les directives actuelles de la plateforme unique de notification de l’ENISA incluent des champs couvrant des domaines tels que le produit, la version du produit, l’heure de prise de connaissance, l’impact, l’atténuation et les informations spécifiques à l’événement.
Ce que l’article 14 signifie pour les clients SAP
Les clients SAP sont-ils obligés de signaler les vulnérabilités de produits activement exploitées ? La réponse est non. En vertu de l’article 14 de la loi européenne sur la cyber-résilience (CRA), un client SAP ordinaire n’est pas obligé de signaler les vulnérabilités des produits TJC Group ou SAP à l’ENISA ou à un CSIRT national. Néanmoins, les clients doivent informer les fournisseurs, tels que TJC Group, afin que nous puissions agir en conséquence.
L’article 14 place principalement les responsabilités de notification sur les fabricants, mais les clients ont également intérêt à comprendre comment leurs fournisseurs de logiciels gèrent les événements de sécurité graves.
Par ailleurs, les clients SAP peuvent avoir des obligations distinctes de notification d’incidents en vertu de législations telles que NIS2, DORA, le RGPD, des règles sectorielles spécifiques, etc.
Comment TJC Group se prépare-t-il à l’article 14 de la CRA ?
Nous avons examiné les exigences de l’article 14 de la CRA et mis en place les processus appropriés pour répondre dans le délai de 24/72 heures. Si TJC Group prend connaissance qu’une vulnérabilité dans un produit TJC a été activement exploitée de manière malveillante et que les critères décrits précédemment dans cet article sont remplis, nous le signalerons dûment à l’ENISA via la plateforme unique de notification CRA. Nous appliquons le même mécanisme lorsque nous identifions un problème dans nos systèmes internes.
Si votre organisation utilise un produit TJC Group et que vous souhaitez obtenir plus d’informations sur qui contacter au cas où l’article 14 devrait être activé, veuillez contacter votre représentant local TJC et nous vous contacterons rapidement.
TJC Group, certifié ISO 27001
TJC Group a obtenu la certification ISO 27001 en 2024 après avoir établi un système de gestion de la sécurité de l’information, ou SMSI, conforme aux exigences de la norme.
La norme ISO 27001 fournit un cadre internationalement reconnu pour gérer les risques de sécurité de l’information par le biais de politiques, de contrôles et de processus définis.
La certification de TJC Group reflète son engagement à protéger la confidentialité, l’intégrité et la disponibilité des informations sensibles et à maintenir et améliorer continuellement son SMSI.
La certification ISO 27001 ne remplace pas les obligations spécifiques introduites par la CRA, mais elle fournit une base structurée pour gérer les risques, les responsabilités et les processus de sécurité de l’information.
Cybersécurité dans le paysage SAP
La cybersécurité ne se limite pas à la réponse aux incidents. Elle couvre également la manière dont les produits sont développés, les vulnérabilités sont évaluées, l’accès est contrôlé, les systèmes sont maintenus et les informations sont protégées tout au long de leur cycle de vie.
Ces priorités plus larges sont explorées plus en détail dans le guide de TJC Group sur la sécurité des données en 2026.
La cybersécurité recoupe également la gestion des données SAP. Réduire l’exposition inutile, contrôler l’accès aux informations historiques et maintenir des environnements appropriés contribuent tous à une posture de sécurité plus forte. La relation entre l’archivage des données et la cybersécurité est particulièrement pertinente dans ce contexte.
Les applications plus anciennes peuvent également continuer à créer une exposition même lorsqu’elles ne sont plus activement développées, c’est pourquoi la sécurité des systèmes legacy reste pertinente parallèlement aux nouvelles obligations de la CRA.
Des conseils supplémentaires sont disponibles dans les ressources de cybersécurité de TJC Group.
Conclusion
L’article 14 de la CRA indique aux fabricants ce qu’ils doivent faire lorsqu’ils découvrent des problèmes graves de cybersécurité affectant leurs produits numériques. Un fabricant doit signaler les vulnérabilités activement exploitées affectant ses produits au CSIRT national concerné et à l’ENISA.
L’article 14 n’exige pas des fabricants qu’ils signalent chaque « vulnérabilité grave ». Il exige la notification de deux choses spécifiques :
- une vulnérabilité activement exploitée ; et
- un incident grave ayant un impact sur la sécurité du produit.
Les clients SAP peuvent signaler un incident grave au fabricant en contactant le point de contact désigné. Les clients SAP ne sont pas obligés de le faire ; cependant, il est dans leur meilleur intérêt d’informer le fabricant dès que possible afin que des mesures puissent être prises.
Si vous êtes client de TJC Group et avez des questions sur l’article 14 de la CRA, n’hésitez pas à nous contacter.
Sources d’information
Commission européenne : loi sur la cyber-résilience
Commission européenne : obligations de notification de la CRA
ENISA : FAQ de la plateforme unique de notification CRA
Questions fréquemment posées de l’ENISA
Article 14 de la loi sur la cyber-résilience
Guide de la loi sur la cyber-résilience pour les développeurs de logiciels
FAQ
Q1. Quand l'article 14 de la CRA s'applique-t-il ?
Answer:
Les obligations de notification de l’article 14 s’appliquent à partir du 11 septembre 2026. La plupart des exigences plus larges de la CRA deviennent pleinement applicables à partir du 11 décembre 2027.
Q2. Qu'est-ce qu'une vulnérabilité activement exploitée ?
Answer:
Il s’agit d’une vulnérabilité pour laquelle il existe des preuves fiables qu’un acteur malveillant l’a exploitée dans un système sans l’autorisation du propriétaire du système.
Q3. Qu'est-ce qui est considéré comme un incident de sécurité grave ?
Answer:
Un incident grave est évalué selon les critères de l’article 14. La définition sous-jacente couvre les incidents qui affectent négativement, ou sont susceptibles d’affecter négativement, la capacité d’un produit à protéger la disponibilité, l’authenticité, l’intégrité ou la confidentialité des données ou des fonctions.
Q4. Qui doit effectuer une notification en vertu de l'article 14 de la CRA ?
Answer:
Les obligations discutées ici s’appliquent aux fabricants de produits comportant des éléments numériques qui relèvent du champ d’application de la CRA.
Leur application à une entreprise de logiciels particulière dépend de son rôle et du produit concerné.
Q5. Dans quel délai un événement doit-il être signalé ?
Answer:
L’alerte précoce initiale doit être soumise sans retard injustifié et, en tout état de cause, dans les 24 heures suivant la prise de connaissance. Une notification plus détaillée suit dans les 72 heures.
Q6. Où les notifications de l'article 14 de la CRA sont-elles soumises ?
Answer:
Les notifications sont soumises via la plateforme unique de notification CRA de l’ENISA. Le fabricant sélectionne le CSIRT approprié désigné comme coordinateur lors de la soumission.
Q7. L'article 14 s'applique-t-il aux produits déjà sur le marché ?
Answer:
Oui. L’ENISA précise que les obligations de notification s’appliquent à partir du 11 septembre 2026 aux produits de l’UE comportant des éléments numériques relevant du champ d’application de la CRA, y compris les produits pertinents mis sur le marché avant que la CRA ne devienne pleinement applicable en décembre 2027.
Q8. Comment TJC Group se prépare-t-il à l'article 14 de la loi sur la cyber-résilience (CRA) ?
Answer:
Nous avons informé nos clients des mises à jour concernant l’article 14 de la loi sur la cyber-résilience et nous avons mis en place le mécanisme approprié pour agir en conséquence si nécessaire. TJC Group est déjà certifié ISO 27001, ce qui signifie qu’un système de gestion de la sécurité de l’information est en place pour gérer efficacement toute menace ou incident de cybersécurité dans le cadre d’une responsabilité opérationnelle continue
