Cyber Resilience Act : ce que les éditeurs de logiciels doivent faire avant le 11 septembre 2026

Le 11 septembre 2026, la première obligation concrète du Cyber Resilience Act entre en application : tout fabricant de produit comportant des éléments numériques devra notifier les vulnérabilités activement exploitées et les incidents graves à l'ENISA et au CSIRT national, dans un délai de 24 heures. Pour les éditeurs de logiciels, les fabricants d'objets connectés et les distributeurs sous marque propre, l'échéance est imminente et les processus à mettre en place ne s'improvisent pas. Voici ce que le règlement impose, qui est concerné, et le plan d'action à dérouler avant septembre.

Le Cyber Resilience Act : la sécurité devient une exigence produit

Le règlement (UE) 2024/2847, dit Cyber Resilience Act ou CRA, a été adopté le 23 octobre 2024, publié au Journal officiel de l'Union européenne le 20 novembre 2024, et est entré en vigueur le 10 décembre 2024. C'est le premier cadre horizontal européen qui fait de la cybersécurité une exigence de mise sur le marché : comme la sécurité électrique ou la conformité CE d'un jouet, la sécurité numérique d'un produit devient une condition de sa commercialisation dans l'Union.

Le texte couvre les « produits comportant des éléments numériques » : matériels et logiciels mis à disposition sur le marché européen, qu'il s'agisse de produits finaux ou de composants commercialisés séparément. Un logiciel vendu en licence, un firmware, une application mobile, un objet connecté, une bibliothèque logicielle commerciale : tous entrent dans le champ. Les exigences couvrent l'ensemble du cycle de vie du produit : conception sécurisée, gestion des vulnérabilités, mises à jour de sécurité pendant une période de support, documentation technique et marquage CE.

Le calendrier d'application est échelonné :

• 11 juin 2026 : application du chapitre relatif à la notification des organismes d'évaluation de la conformité ;
• 11 septembre 2026 : application des obligations de notification de l'article 14 (vulnérabilités activement exploitées et incidents graves) ;
• 11 décembre 2027 : application générale du règlement, exigences essentielles et marquage CE compris.

Qui est concerné : bien plus large que les « fabricants » au sens industriel

Le CRA vise les fabricants, importateurs et distributeurs de produits comportant des éléments numériques. Trois cas méritent l'attention des entreprises françaises du numérique.

Les éditeurs de logiciels

Un éditeur qui commercialise un logiciel (licence on-premise, application mobile, logiciel embarqué) est un fabricant au sens du CRA. La question est plus nuancée pour le SaaS pur : le règlement vise les produits, et une solution de traitement de données à distance n'est couverte que lorsqu'elle est nécessaire au fonctionnement d'un produit comportant des éléments numériques. Un éditeur qui propose à la fois une application installable et un back-end cloud indissociable doit donc analyser finement son périmètre : la frontière entre le produit (soumis au CRA) et le service (relevant d'autres textes comme NIS2) se trace au cas par cas, produit par produit.

Les fabricants de produits connectés et logiciels embarqués

Tout objet connecté mis sur le marché européen est concerné, ainsi que ses composants logiciels. Les industriels qui intègrent du logiciel dans leurs produits doivent sécuriser contractuellement la chaîne de leurs fournisseurs de composants numériques, car c'est le fabricant du produit final qui porte la responsabilité de la conformité.

Les distributeurs sous marque propre

Point souvent ignoré : un distributeur ou un importateur qui commercialise un produit sous son propre nom ou sa propre marque est traité comme un fabricant, avec l'intégralité des obligations correspondantes. Une entreprise française qui fait fabriquer un objet connecté en Asie et le vend sous sa marque assume seule la conformité CRA du produit.

Le 11 septembre 2026 : l'obligation de notification de l'article 14

L'article 14 du CRA crée deux obligations de notification distinctes pour les fabricants, applicables dès le 11 septembre 2026, avant même le reste du règlement.

La première concerne les vulnérabilités activement exploitées : dès que le fabricant a connaissance d'une vulnérabilité de son produit activement exploitée par un attaquant, il doit la notifier. La seconde concerne les incidents graves ayant un impact sur la sécurité du produit. Dans les deux cas, le calendrier est serré :

• 24 heures pour transmettre une alerte précoce après la prise de connaissance ;
• 72 heures pour la notification complète, avec les informations disponibles sur la nature de la vulnérabilité ou de l'incident ;
• rapport final au plus tard 14 jours après la disponibilité d'une mesure corrective pour une vulnérabilité exploitée, et dans un délai d'un mois pour un incident grave.

La notification s'effectue en une seule fois via la plateforme unique de signalement (Single Reporting Platform) mise en place par l'ENISA, qui doit être opérationnelle au 11 septembre 2026 après une période de test. La notification est adressée au CSIRT de l'État membre où le fabricant a son établissement principal, l'information étant simultanément mise à disposition de l'ENISA. En France, c'est le CERT-FR, opéré par l'ANSSI, qui reçoit ces signalements, comme le précise la foire aux questions publiée par l'ANSSI sur l'application du CRA.

Conseil d'avocat : le délai de 24 heures ne se tient pas sans processus interne préétabli. Qui détecte, qui qualifie, qui décide de notifier, qui rédige, qui valide : si ces rôles ne sont pas attribués à l'avance avec des suppléants, le délai sera dépassé dès le premier incident réel.

Vulnérabilité exploitée, incident grave : savoir qualifier vite

La difficulté opérationnelle de l'article 14 tient à la qualification. Une vulnérabilité découverte en interne mais non exploitée ne déclenche pas la notification ; une vulnérabilité dont l'exploitation active est documentée, si. Un dysfonctionnement sans impact sur la sécurité du produit ne déclenche rien ; un incident qui compromet la sécurité du produit, si. Cette qualification doit être faite en quelques heures, sur la base d'informations souvent incomplètes.

C'est un travail conjoint entre l'équipe technique et le juriste : la première évalue l'exploitation et l'impact, le second sécurise la qualification et la rédaction de la notification, dont le contenu pourra être examiné ultérieurement par les autorités de surveillance du marché. Les fabricants qui gèrent déjà des notifications de violations de données personnelles à la CNIL sous 72 heures au titre du RGPD connaissent la mécanique : le CRA ajoute un canal parallèle, avec un déclencheur différent et un délai plus court encore. Les deux régimes peuvent d'ailleurs se cumuler sur un même incident, et il faut cartographier ces obligations croisées, comme pour la gestion juridique de la cybersécurité en général.

Micro et petites entreprises : une souplesse limitée

Le règlement prévoit un aménagement pour les plus petites structures : les fabricants qui sont des microentreprises ou petites entreprises ne peuvent pas être sanctionnés d'une amende pour le seul non-respect du délai de 24 heures de l'alerte précoce. Attention à la lecture : l'obligation de notifier demeure, seule la sanction du dépassement du premier délai est écartée. Une petite entreprise qui ne notifierait pas du tout resterait en infraction.

Décembre 2027 : les exigences essentielles à anticiper dès maintenant

Le reste du règlement s'applique le 11 décembre 2027, mais son contenu impose de commencer maintenant, car il touche à la conception même des produits :

• Sécurité dès la conception : les exigences essentielles de l'annexe I imposent notamment une surface d'attaque limitée, une configuration sécurisée par défaut et la protection des données traitées ;
• Gestion des vulnérabilités : processus de traitement documenté, politique de divulgation coordonnée, fourniture de mises à jour de sécurité pendant la période de support ;
• Documentation technique et évaluation de conformité : autoévaluation pour la majorité des produits, intervention d'un organisme notifié pour les produits importants et critiques, dont les catégories ont été précisées par le règlement d'exécution (UE) 2025/2392 du 28 novembre 2025 ;
• Marquage CE : le produit conforme porte le marquage, condition de sa libre circulation sur le marché européen.

Un produit conçu en 2026 sera commercialisé sous l'empire du CRA. Intégrer les exigences maintenant coûte beaucoup moins cher que remettre en conformité un produit fini. C'est le même apprentissage que le RGPD a imposé en 2018 : la conformité s'intègre dans la conception, elle ne se rattrape pas en aval. L'ANSSI le rappelle d'ailleurs expressément : la conformité s'impose sans attendre la publication des normes harmonisées.

Des sanctions alignées sur les standards européens récents

Le CRA prévoit des amendes administratives pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu, pour les manquements aux exigences essentielles de cybersécurité et aux obligations des articles 13 et 14. Les autres manquements sont sanctionnés par des plafonds inférieurs. À ces amendes s'ajoutent les pouvoirs des autorités de surveillance du marché : retrait ou rappel du produit, restriction de mise à disposition. Pour un éditeur, le risque le plus dissuasif n'est pas l'amende, c'est l'interdiction de commercialisation.

Plan d'action avant le 11 septembre 2026

Voici les chantiers à mener d'ici l'échéance, dans l'ordre :

1. Cartographier le périmètre produit : lister les produits comportant des éléments numériques mis sur le marché européen, qualifier les cas limites (SaaS, composants, marque propre) et documenter l'analyse ;
2. Construire le processus de notification : procédure interne 24h/72h/14 jours, rôles attribués, modèles de notification prérédigés, articulation avec les notifications RGPD et, le cas échéant, NIS2 ;
3. Se préparer à la plateforme ENISA : suivre l'ouverture de la période de test de la Single Reporting Platform et intégrer l'inscription au processus ;
4. Sécuriser la chaîne contractuelle : clauses de remontée d'information avec les fournisseurs de composants et les sous-traitants de développement, pour être informé à temps d'une vulnérabilité exploitée ;
5. Lancer la mise à niveau produit pour l'échéance de décembre 2027 : évaluation des écarts avec l'annexe I, feuille de route de conformité, documentation technique.

Ces chantiers rejoignent les obligations voisines qui s'imposent déjà à certaines entreprises du numérique au titre de NIS2 ou de DORA pour le secteur financier : les processus de détection et de notification peuvent être mutualisés, à condition de cartographier précisément quel texte déclenche quelle notification, auprès de qui et dans quel délai.

L'échéance de septembre est une répétition générale

Le 11 septembre 2026 ne marque pas la fin de la mise en conformité CRA : c'en est le premier test grandeur nature. Les fabricants qui auront un processus de notification opérationnel à cette date aborderont sereinement l'échéance complète de décembre 2027. Les autres découvriront leurs lacunes au pire moment : pendant un incident. Pour les éditeurs de logiciels comme pour les prestataires qui développent pour des fabricants, l'analyse du périmètre et la construction du processus de notification sont les deux chantiers à lancer sans attendre. Si vous voulez vérifier où vous en êtes, vous pouvez échanger sur votre situation directement avec moi.