Cyber Resilience Act : l'obligation de signalement est entrée en vigueur le 11 septembre

Depuis le 11 septembre 2026, tout fabricant d'un produit comportant des éléments numériques vendu dans l'Union européenne doit signaler les vulnérabilités activement exploitées et les incidents graves qui touchent la sécurité de ce produit. Le rythme est serré : une alerte précoce sous 24 heures, une notification sous 72 heures, un rapport final ensuite. L'obligation vaut aussi pour les produits déjà sur le marché, et son non-respect expose à une amende pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial.

Presque tout ce qui a été écrit sur le Cyber Resilience Act parle de décembre 2027. C'est exact pour l'essentiel du texte, mais le chronomètre du signalement tourne depuis quatre jours. Et la vraie question, pour la plupart des entreprises qui nous interrogent, n'est pas le délai : c'est de savoir si elles sont fabricant au sens du règlement. Un SaaS pur accessible dans un navigateur ne l'est généralement pas. Une application mobile adossée à votre propre backend, en revanche, l'est très probablement.

Ce qui s'applique depuis le 11 septembre

Le règlement (UE) 2024/2847, dit Cyber Resilience Act, est entré en vigueur le 10 décembre 2024. Son article 14, consacré aux obligations de signalement, s'applique depuis le 11 septembre 2026. Le même jour, l'ENISA a mis en service sa plateforme unique de signalement, par laquelle passent toutes les notifications.

Le principe est de ne signaler qu'une fois. Le fabricant dépose sa notification sur la plateforme, qui la transmet au CSIRT désigné comme coordinateur dans l'État membre de son établissement principal et la rend simultanément disponible pour l'ENISA. Le CSIRT se charge ensuite de diffuser l'information aux autres États membres concernés.

Point décisif, souvent manqué : l'article 69 déroge explicitement au calendrier général. Les obligations de l'article 14 s'appliquent à tous les produits entrant dans le champ du règlement, y compris ceux mis sur le marché avant le 11 décembre 2027. Il n'y a donc pas de clause du grand-père pour le signalement : votre application publiée il y a trois ans est concernée au même titre qu'une nouveauté.

Le calendrier complet, pour s'y retrouver

Le règlement s'applique par étapes, et c'est ce découpage qui entretient la confusion. D'après la synthèse publiée par la Commission, les jalons sont les suivants.

• 10 décembre 2024 : entrée en vigueur du règlement.
• 11 juin 2026 : application du chapitre sur la notification des organismes d'évaluation de la conformité.
• 11 septembre 2026 : application des obligations de signalement de l'article 14 pour les fabricants.
• 11 décembre 2027 : application complète, avec les exigences essentielles de cybersécurité, les obligations des fabricants et le marquage CE, ainsi que le signalement pour les gestionnaires de logiciels libres.

Entre-temps, la Commission a publié le 27 juillet 2026 des lignes directrices non contraignantes sur l'application du texte. Elles portent sur le périmètre, les solutions de traitement de données à distance, le logiciel libre, la notion de modification substantielle, la période de support et le signalement, et comportent 67 exemples pratiques pensés pour les micro, petites et moyennes entreprises.

Suis-je fabricant ? Le périmètre, là où tout se joue

Le règlement vise les produits comportant des éléments numériques mis à disposition sur le marché, dont l'usage prévu ou raisonnablement prévisible inclut une connexion de données, directe ou indirecte, à un appareil ou à un réseau. Un produit comportant des éléments numériques y est défini comme un produit logiciel ou matériel et ses solutions de traitement de données à distance.

Tout tient dans cette dernière notion. Une solution de traitement de données à distance est un traitement conçu et développé par le fabricant ou sous sa responsabilité, et dont l'absence empêcherait le produit de remplir l'une de ses fonctions. Les considérants du texte précisent que les solutions cloud ne relèvent du règlement que si elles répondent à cette définition, et que les sites web qui ne soutiennent pas la fonctionnalité d'un produit restent hors champ.

Traduit en cas concrets, cela donne un paysage assez lisible. Un logiciel installé que vous vendez ou distribuez est dans le champ. Un objet connecté et le service cloud dont il a besoin pour fonctionner sont dans le champ, ensemble. Une application mobile publiée sur les stores et qui s'appuie sur une API que vous avez développée est dans le champ, et son backend avec elle. À l'inverse, un SaaS utilisé uniquement dans un navigateur, sans produit installé qui en dépende, n'est en général pas un produit au sens du règlement. Un site vitrine non plus.

Le fabricant, lui, est la personne qui développe ou fait développer le produit et le commercialise sous son nom ou sa marque, contre paiement, monétisation ou gratuitement. Le critère n'est donc pas de savoir qui a écrit le code, mais qui met le produit sur le marché sous son nom. Si une agence développe une application que vous publiez sous votre marque, c'est vous le fabricant. Le cas du logiciel développé sur mesure pour un client unique est plus discuté : il dépend de la façon dont il est fourni, et c'est typiquement un sujet sur lequel les exemples des lignes directrices méritent d'être lus avant de trancher.

Plusieurs catégories sont exclues parce qu'un autre texte les couvre déjà : dispositifs médicaux et de diagnostic in vitro, véhicules à moteur, aviation civile, équipements marins, ainsi que les produits développés exclusivement pour la sécurité nationale ou la défense. Le logiciel libre développé hors de toute activité commerciale n'est pas visé, et les gestionnaires de logiciels libres n'auront à signaler qu'à partir du 11 décembre 2027.

Les délais, et ce qu'ils exigent vraiment

Pour une vulnérabilité activement exploitée, l'article 14 impose trois étapes, que la Commission rappelle dans sa page consacrée au signalement : une alerte précoce sans retard injustifié et au plus tard 24 heures après en avoir pris connaissance, une notification de la vulnérabilité sous 72 heures, puis un rapport final au plus tard 14 jours après la mise à disposition d'une mesure corrective ou d'atténuation.

Encore faut-il savoir ce qu'est une vulnérabilité activement exploitée. Le règlement la définit comme 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 de son propriétaire. Une faille découverte en audit, un bulletin de sécurité sur l'une de vos dépendances, une alerte d'un chercheur ne déclenchent pas à eux seuls l'obligation. C'est la preuve d'une exploitation réelle qui fait partir le compteur.

Pour un incident grave ayant un impact sur la sécurité du produit, le schéma est proche : alerte précoce sous 24 heures, notification sous 72 heures, rapport final dans un délai d'un mois. Un incident est considéré comme grave s'il affecte ou peut affecter 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 s'il a conduit ou peut conduire à l'introduction ou à l'exécution de code malveillant dans le produit ou dans les réseaux et systèmes d'information d'un utilisateur.

Enfin, le signalement aux autorités ne suffit pas. L'article 14 impose aussi au fabricant d'informer les utilisateurs touchés, et le cas échéant l'ensemble des utilisateurs, de la vulnérabilité ou de l'incident, ainsi que des mesures d'atténuation ou de correction à appliquer. C'est un message à préparer à froid, pas à rédiger dans l'urgence d'un vendredi soir.

Ce que coûte le non-respect

L'article 64 fixe trois paliers. Le manquement aux exigences essentielles de cybersécurité et aux obligations des articles 13 et 14, donc au signalement, est puni d'une amende administrative pouvant atteindre 15 millions d'euros ou, pour une entreprise, 2,5 % du chiffre d'affaires annuel mondial de l'exercice précédent, le montant le plus élevé étant retenu. Viennent ensuite un palier à 10 millions d'euros ou 2 % pour d'autres obligations, et un palier à 5 millions d'euros ou 1 % pour la fourniture d'informations inexactes aux autorités.

Le texte prévoit un aménagement pour les plus petites structures, qu'il faut lire précisément. Les microentreprises et petites entreprises ne peuvent pas être sanctionnées pour le seul non-respect du délai de 24 heures de l'alerte précoce, que ce soit pour une vulnérabilité ou pour un incident. Les délais de 72 heures et du rapport final, l'information des utilisateurs et le reste des obligations les concernent pleinement. Les gestionnaires de logiciels libres, eux, ne sont pas passibles d'amendes au titre du règlement.

CRA et NIS 2 : deux logiques qui se cumulent

La confusion entre les deux textes est fréquente, et elle est compréhensible puisqu'ils partagent le vocabulaire des CSIRT et des délais courts. Leur logique est pourtant différente. NIS 2 regarde l'entité : votre organisation, selon son secteur et sa taille, et la sécurité de ses propres systèmes. Le Cyber Resilience Act regarde le produit que vous mettez sur le marché, quelle que soit la taille de l'entreprise qui le commercialise.

Les deux peuvent donc s'appliquer en même temps à la même société, pour des raisons différentes et à propos d'événements différents. Un éditeur de logiciel peut n'être visé par aucune obligation NIS 2 et devoir malgré tout signaler une faille exploitée dans son application au titre du CRA. La bonne pratique consiste à construire une seule procédure de gestion des incidents, capable d'aiguiller vers l'un, l'autre ou les deux régimes.

Ce qu'il faut avoir en place cette semaine

Pas besoin d'un programme de conformité de six mois pour être prêt au signalement. Il faut en revanche quelques éléments très concrets, parce que 24 heures, c'est court quand personne ne sait qui décide.

D'abord, l'inventaire. Listez les produits que vous commercialisez sous votre nom et qualifiez-les : produit dans le champ, hors champ, à vérifier. Pour ceux qui sont dans le champ, identifiez les composants tiers et les dépendances. La nomenclature logicielle ne sera exigée qu'à partir de décembre 2027, mais c'est elle qui vous permettra de savoir en une heure, et non en trois jours, si une vulnérabilité exploitée dans une bibliothèque vous touche.

Ensuite, la chaîne de décision. Désignez qui qualifie une vulnérabilité comme activement exploitée, qui valide la notification et qui la dépose sur la plateforme de l'ENISA, avec un suppléant pour chaque rôle. Le délai court à partir du moment où le fabricant prend connaissance de l'exploitation, pas à partir du moment où la direction est disponible. La foire aux questions de la plateforme détaille les modalités pratiques de dépôt.

Puis les modèles. Préparez un gabarit d'alerte précoce, un gabarit de notification et un message type aux utilisateurs. Ces textes se rédigent en une matinée au calme, et ils font gagner des heures le jour où il faut les envoyer.

Enfin, la détection. Une obligation de signalement sans capacité de détection revient à ne rien savoir, donc à ne rien signaler, jusqu'au jour où quelqu'un d'autre le fait pour vous. Journalisation exploitable, alertes sur les comportements anormaux, veille sur les vulnérabilités de vos dépendances : ce sont les fondamentaux que nous rappelions après l'incident de fuite de données aux impôts, et que l'outillage d'analyse de code peut compléter, comme nous l'expliquions à propos de Claude Code Security.

Et en décembre 2027

Le signalement n'est que l'avant-garde. À partir du 11 décembre 2027, les produits dans le champ devront satisfaire les exigences essentielles de cybersécurité dès leur conception, faire l'objet d'une évaluation de conformité et porter le marquage CE. Le fabricant devra aussi fixer une période de support pendant laquelle il traite les vulnérabilités, d'au moins cinq ans sauf si le produit est prévu pour une durée d'utilisation plus courte, et chaque mise à jour de sécurité publiée devra rester disponible au moins dix ans ou jusqu'à la fin de la période de support si elle est plus longue.

Pour un produit existant, c'est souvent ce dernier point qui pèse le plus : maintenir un logiciel cinq ans, c'est un budget, une architecture maintenable et une dette technique maîtrisée. Si votre application a accumulé des années de correctifs empilés, un audit de dette technique est un bon point de départ pour chiffrer l'effort avant qu'il ne devienne une obligation.

Ce que nous en retenons

Le Cyber Resilience Act n'est plus un sujet de 2027. Depuis le 11 septembre 2026, un fabricant qui découvre qu'une faille de son produit est exploitée dispose de 24 heures pour lever l'alerte, y compris pour des produits commercialisés depuis des années, sous peine d'une amende pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial.

La première question à trancher reste celle du périmètre. Un SaaS consulté dans un navigateur en sort généralement, une application mobile ou un objet connecté adossés à votre backend y entrent. Une fois ce point établi, le travail utile tient en quatre chantiers : inventaire, chaîne de décision, modèles de notification, capacité de détection.

Nous accompagnons des éditeurs sur ces sujets dans le cadre de nos projets de modernisation applicative, de la qualification du périmètre à la mise en place de la détection. Si vous ne savez pas encore si vos produits sont concernés, parlons-en.