CRA, article 14 : ce qu’un éditeur doit signaler depuis le 11 septembre 2026

Sources vérifiées le 31 octobre 2026. Prochaine revue le 11 décembre 2026. Temps de lecture : 12 minutes.

RégulationMémoire

Pour l’ensemble du texte : notre dossier de référence sur le Cyber Resilience Act, tenu à jour.

Sommaire

1. Qui doit signaler ?
2. Qu’est-ce qu’une vulnérabilité activement exploitée ?
3. Qu’est-ce qu’un incident grave ?
4. Quels délais, et à qui ?
5. Faut-il prévenir vos clients ?
6. Quelles sanctions, et à partir de quand ?
7. Et si vous êtes aussi soumis à NIS2 ?
8. Comment on en est arrivé là
9. Ce que cela change pour une ETI
10. Notre lecture
11. Ce que nous ne savons pas encore
12. Questions fréquentes
13. Ce qui a changé depuis la publication
14. Sources

Prenons un éditeur de 120 salariés, construit pour l’exemple, dont les décisions de cybersécurité se prennent à Lyon. Il vend un logiciel de sauvegarde : un agent installé sur les serveurs de ses clients, piloté par une console en ligne qu’il développe lui-même et sans laquelle l’agent ne peut pas planifier ses sauvegardes. Le logiciel est vendu depuis 2023. Un mardi à 9 heures, un client l’appelle : un attaquant semble avoir utilisé une faille de l’agent pour désactiver les sauvegardes avant de chiffrer ses serveurs.

Si l’éditeur établit ce matin-là, après une première analyse, que la faille a bien été exploitée, il doit envoyer l’alerte précoce sans retard injustifié et au plus tard mercredi à 9 heures, la notification au plus tard vendredi à 9 heures, et le rapport final au plus tard 14 jours après la mise à disposition d’un correctif ou d’une mesure d’atténuation. Il doit aussi informer ses clients. La date de vente du logiciel n’y change rien.

Qui doit signaler ?

Le fabricant d’un produit comportant des éléments numériques : la personne qui développe ou fabrique ce produit, ou le fait concevoir ou fabriquer, et le commercialise sous son nom ou sa marque, à titre onéreux, monétisé ou gratuit (article 3, point 13). Le produit est défini comme un produit logiciel ou matériel « et ses solutions de traitement de données à distance » (article 3, point 1). Il doit avoir une connexion de données, directe ou indirecte, à un appareil ou à un réseau (article 2, paragraphe 1). Plusieurs catégories sont exclues parce que d’autres règles les couvrent, notamment les dispositifs médicaux, les véhicules, l’aviation et les équipements marins (article 2).

Une solution de traitement de données à distance est un traitement dont le logiciel est conçu et développé par le fabricant, ou sous sa responsabilité, et dont l’absence empêcherait le produit de remplir une de ses fonctions (article 3, point 2). La console de notre éditeur, qu’il développe et sans laquelle l’agent ne planifie plus rien, en est une : elle fait partie du produit. Ici, la faille se trouve dans l’agent, qui est un produit de toute façon ; la console compterait si la faille s’y trouvait.

Un service en nuage fourni seul, comme un logiciel en SaaS, est hors du champ du CRA. Le considérant 12 rappelle que ces services relèvent de la directive NIS2, laquelle ne vise toutefois leurs fournisseurs qu’à partir de la taille d’une entreprise moyenne. Beaucoup d’offres présentées comme SaaS comprennent pourtant une application mobile, un client installé ou une extension : le considérant 11 cite l’application mobile qui accède à une interface ou à une base de données du fabricant. Pour ces composants installés, l’éditeur est fabricant au sens du CRA.

Les obligations de l’article 14 s’appliquent à tous les produits du champ, y compris ceux mis sur le marché avant le 11 décembre 2027 (article 69, paragraphe 3), et l’article 14 s’applique depuis le 11 septembre 2026 (article 71). Le reste du règlement, lui, ne vise les produits déjà sur le marché qu’en cas de modification substantielle à partir du 11 décembre 2027 (article 69, paragraphe 2).

Qu’est-ce qu’une vulnérabilité activement exploitée ?

C’est une vulnérabilité pour laquelle il existe « des preuves fiables qu’elle a été exploitée par un acteur malveillant » dans un système, sans l’autorisation de son propriétaire (article 3, point 42). Une faille découverte par vos tests, ou signalée par un chercheur sans trace d’exploitation, n’entre pas dans cette catégorie. Dans notre cas, les constats faits chez le client peuvent constituer cette preuve, une fois vérifiés.

Le fabricant, comme toute autre personne, peut aussi signaler volontairement d’autres vulnérabilités, des cybermenaces ou des incidents évités de justesse (article 15).

Qu’est-ce qu’un incident grave ?

Un incident ayant des répercussions sur la sécurité du produit (article 3, point 44) est grave lorsqu’il entache, ou est susceptible d’entacher, la capacité du produit à protéger la disponibilité, l’authenticité, l’intégrité ou la confidentialité de données ou de fonctions sensibles ou importantes, ou lorsqu’il a conduit, ou est susceptible de conduire, à l’introduction ou à l’exécution d’un code malveillant dans le produit ou dans le réseau et les systèmes d’information d’un utilisateur (article 14, paragraphe 5).

Le considérant 68 cite la compromission du canal de mise à jour. Si un attaquant avait utilisé le système de mise à jour de notre éditeur pour distribuer un agent piégé, ce serait un incident grave, même sans faille dans l’agent lui-même.

Quels délais, et à qui ?

Étape	Vulnérabilité activement exploitée	Incident grave
Alerte précoce	Sans retard injustifié et au plus tard 24 heures après en avoir eu connaissance (article 14, paragraphe 2, point a)	Sans retard injustifié et au plus tard 24 heures après en avoir eu connaissance (article 14, paragraphe 4, point a)
Notification	Sans retard injustifié et au plus tard 72 heures après en avoir eu connaissance (paragraphe 2, point b)	Sans retard injustifié et au plus tard 72 heures après en avoir eu connaissance (paragraphe 4, point b)
Rapport final	Au plus tard 14 jours après la mise à disposition d’une mesure de correction ou d’atténuation (paragraphe 2, point c)	Dans un délai d’un mois à compter de la notification (paragraphe 4, point c)

La notification et le rapport final ne sont pas dus lorsque les informations pertinentes ont déjà été communiquées (article 14, paragraphes 2 et 4). Les notifications passent par la plateforme unique de signalement établie par l’ENISA (article 16). Elles sont adressées au CSIRT désigné comme coordinateur de l’État membre de l’établissement principal du fabricant et mises en même temps à la disposition de l’ENISA, sauf circonstances exceptionnelles (article 14, paragraphes 1, 3 et 7). Pour la France, c’est le CERT-FR de l’ANSSI. La Commission indique que la plateforme est opérationnelle depuis le 11 septembre 2026.

L’établissement principal est l’État où sont principalement prises les décisions relatives à la cybersécurité des produits ; à défaut, celui qui compte le plus de salariés (article 14, paragraphe 7). Le CSIRT peut demander un rapport intermédiaire (article 14, paragraphe 6). Pour préciser ces obligations, la Commission renvoie à la section 9.1 de ses orientations sur le CRA et à la section 5 de sa foire aux questions.

Faut-il prévenir vos clients ?

Le fabricant doit les informer : après avoir eu connaissance d’une vulnérabilité activement exploitée ou d’un incident grave, il informe les utilisateurs touchés et, s’il y a lieu, tous les utilisateurs, de la vulnérabilité ou de l’incident et des mesures qu’ils peuvent prendre, si possible dans un format structuré et lisible par machine (article 14, paragraphe 8). S’il ne le fait pas en temps utile, les CSIRT coordinateurs notifiés peuvent informer eux-mêmes les utilisateurs, s’ils le jugent proportionné et nécessaire.

Pour notre éditeur, cela veut dire prévenir tous les clients qui utilisent la version vulnérable de l’agent, pas seulement celui qui a été attaqué, avec la conduite à tenir en attendant le correctif.

Quelles sanctions, et à partir de quand ?

Le règlement prévoit des amendes administratives pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial total, le montant le plus élevé étant retenu, notamment pour le non-respect des articles 13 et 14 (article 64, paragraphe 2). L’article 71 n’avance toutefois que l’application de l’article 14 et du chapitre IV : le régime de sanctions de l’article 64 ne s’applique qu’à partir du 11 décembre 2027. L’ANSSI indique par ailleurs que le règlement nécessite des mesures d’adaptation du droit national.

Les microentreprises et petites entreprises, au sens de la recommandation 2003/361/CE, ne peuvent pas recevoir d’amende administrative pour le seul non-respect du délai de 24 heures de l’alerte précoce (article 64, paragraphe 10) ; le considérant 120 ajoute qu’aucune autre sanction pécuniaire ne doit leur être infligée pour ce motif. Notre éditeur, avec 120 salariés, n’entre pas dans cette exception.

Pour les contrôles, l’ANSSI indique qu’à partir de décembre 2027 les autorités de surveillance du marché opèrent des contrôles ; pour la France, c’est l’ANFR.

Et si vous êtes aussi soumis à NIS2 ?

Les deux textes ne visent pas le même objet. NIS2 vise les incidents importants qui touchent les services d’une entité essentielle ou importante (article 23 de la directive (UE) 2022/2555). Le CRA vise la sécurité d’un produit mis à disposition sur le marché de l’Union, quel que soit l’État membre où se trouvent les clients touchés. Un éditeur qui est aussi entité NIS2 peut devoir notifier le même événement au titre des deux textes.

Si des données personnelles sont touchées, le RGPD s’ajoute : le responsable du traitement, souvent le client, notifie la violation à l’autorité de contrôle ; l’éditeur qui agit comme sous-traitant en informe le responsable du traitement dans les meilleurs délais (article 33).

Pour savoir si votre entreprise relève de NIS2, voir notre analyse sur les infogéreurs et notre test du simulateur de l’ANSSI.

Mémoire

Comment on en est arrivé là

Avant le CRA, les obligations européennes de notification visaient surtout l’organisation touchée : la directive SRI de 2016 puis NIS2 pour les incidents des opérateurs et des entités, le RGPD depuis 2018 pour les violations de données personnelles. Le CRA ajoute une obligation attachée au produit : c’est son fabricant qui signale, quel que soit le client touché.

Le règlement, signé le 23 octobre 2024, est entré en vigueur le 10 décembre 2024. Il s’applique par étapes : le 11 juin 2026 pour les organismes d’évaluation de la conformité (chapitre IV), le 11 septembre 2026 pour l’article 14, le 11 décembre 2027 pour tout le reste (article 71).

Notre lecture

La date à retenir n’est pas décembre 2027 : l’article 69 applique l’obligation de signalement depuis septembre 2026, y compris à un logiciel vendu des années plus tôt. La frontière avec le SaaS demande, elle, une analyse produit par produit : la console qui fait fonctionner un logiciel installé entre dans le champ, l’application en ligne fournie seule n’y entre pas.

Pour une PME comme celle de notre cas, la liste à jour des clients par version installée conditionne l’information des utilisateurs touchés. Sans elle, cette information peut prendre des jours.

Ce que nous ne savons pas encore

• Comment les autorités apprécieront le moment où le fabricant a « eu connaissance » d’une exploitation, point de départ des délais, lorsque l’information arrive par un client ou par un tiers. La Commission en traite dans ses orientations, que nous n’avons pas pu consulter dans leur version officielle au 31 octobre 2026.
• Comment sera tranchée, dans les cas mixtes, la frontière entre SaaS autonome et solution de traitement de données à distance.
• Si un manquement à l’article 14 commis entre septembre 2026 et décembre 2027 pourra être sanctionné une fois le régime d’amendes applicable, et comment le droit français sera adapté.
• Le nombre de signalements reçus depuis le 11 septembre 2026 : ni la Commission, ni l’ENISA, ni l’ANSSI n’en publient à cette date, à notre connaissance.

Questions fréquentes

Un éditeur de SaaS doit-il signaler au titre du CRA ?

En principe non : un service en nuage fourni seul est hors du champ du CRA (considérant 12). Il en va autrement si le service est la solution de traitement de données à distance d’un produit, ou si l’offre comprend un logiciel installé, comme une application mobile (considérant 11).

Un logiciel vendu avant le 11 septembre 2026 est-il concerné ?

Oui. L’article 69, paragraphe 3, applique l’article 14 à tous les produits du champ mis sur le marché avant le 11 décembre 2027.

Une faille trouvée en interne doit-elle être signalée ?

Pas au titre de l’obligation de l’article 14, tant qu’il n’existe pas de preuve fiable de son exploitation par un acteur malveillant. Le signalement volontaire reste possible (article 15).

Les micro et petites entreprises sont-elles dispensées ?

Non. Elles ne peuvent pas recevoir d’amende pour le seul dépassement du délai de 24 heures de l’alerte précoce (article 64, paragraphe 10), mais les autres obligations de l’article 14 s’appliquent à elles. Le régime d’amendes ne s’applique de toute façon qu’à partir du 11 décembre 2027.

Ce qui a changé depuis la publication

31 octobre 2026 : publication.