Cyber Resilience Act : l’obligation de signalement des vulnérabilités est entrée en vigueur — et concerne peut-être déjà votre logiciel

Le 11 septembre 2026, les obligations de signalement de l’article 14 du Cyber Resilience Act européen sont entrées en application — plus d’un an avant les exigences de cybersécurité principales du règlement, qui ne s’appliqueront qu’à partir du 11 décembre 2027. Désormais, tout « fabricant » d’un produit à éléments numériques mis sur le marché européen — matériel ou logiciel vendu sous son propre nom — doit signaler une vulnérabilité activement exploitée dans les 24 heures suivant sa découverte, transmettre une notification complète sous 72 heures, puis un rapport final dans les 14 jours suivant la disponibilité d’un correctif (ou sous un mois pour un incident grave). Ces signalements partent simultanément vers deux destinataires : la nouvelle plateforme unique de signalement de l’ENISA et le CSIRT national désigné au titre de la directive NIS2 — en France, le CERT-FR de l’ANSSI. Les amendes en cas de manquement peuvent atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial annuel, le montant le plus élevé étant retenu — et l’obligation couvre aussi les produits déjà mis sur le marché avant cette date.

Ce qui change concrètement depuis le 11 septembre

• →Le règlement (UE) 2024/2847, adopté en 2024, se déroule en deux temps : les obligations de signalement dès le 11 septembre 2026, et l’ensemble des exigences essentielles de cybersécurité (marquage CE, documentation technique) seulement à partir du 11 décembre 2027.
• →La chaîne 24 heures / 72 heures / rapport final s’applique dès que vous avez connaissance d’une vulnérabilité activement exploitée ou d’un incident grave touchant un produit que vous commercialisez — pas seulement à partir de l’échéance de conformité de 2027.
• →Les produits déjà commercialisés avant septembre 2026 sont couverts eux aussi, tant qu’ils restent sur le marché.
• →Un signalement manquant ou tardif constitue en lui-même un manquement, indépendamment du fait que la vulnérabilité ait ou non été exploitée contre un client.

Est-ce que ça concerne vraiment votre PME ?

La définition de « fabricant » retenue par le règlement est plus large que « fabricant de matériel industriel ». Elle couvre toute entreprise qui développe, ou fait développer, un produit à éléments numériques et le met sur le marché européen sous sa propre marque — un logiciel packagé, un plugin, un objet connecté, ou un développement sur mesure livré sous votre propre nom. Elle ne couvre en général pas une agence ou une société de services qui construit un produit commercialisé sous la marque de son client, et un SaaS purement cloud échappe généralement au périmètre sauf s’il fait fonction de brique de traitement à distance d’un produit. En pratique : si votre PME publie et vend un logiciel ou un objet connecté sous son propre nom dans l’Union européenne, vous êtes très probablement « fabricant » au sens de ce règlement dès aujourd’hui — que quelqu’un dans votre entreprise ait entendu parler du Cyber Resilience Act ou non.

L’écart que la loi vient combler

Ce dernier point n’a rien de théorique. Une étude de 2024 menée par Szedlak, Reinemann et Hatzelmann, portant sur 673 entreprises dont 416 PME, montre que seules 12,3 % des PME avaient connaissance de l’existence du Cyber Resilience Act, contre 83,5 % des très grandes entreprises — et parmi celles qui en avaient connaissance, le manque de personnel qualifié et l’absence de tout processus formalisé de traitement des vulnérabilités étaient les obstacles les plus cités à la mise en conformité. L’obligation de signalement entrée en vigueur cette semaine n’attend pas que cet écart se comble.

Ce que ça change pour votre PME

La plupart des PME qui développent ou revendent du logiciel ont classé le Cyber Resilience Act dans la case « problème de 2027, on verra plus tard » — les exigences de marquage CE et de documentation technique sont effectivement encore à 15 mois. L’obligation de signalement, elle, ne l’est pas : elle est opposable dès maintenant, avec le même plafond d’amende, et elle suppose quelque chose que la plupart des petites équipes logicielles n’ont pas encore — un moyen de savoir, en quelques heures, qu’une de leurs dépendances est touchée par une vulnérabilité activement exploitée, et une personne désignée capable de transmettre ce signalement à l’ENISA et au CERT-FR dans une fenêtre de 24 heures. Construire ce processus après le début d’un incident, c’est s’y prendre dans le mauvais ordre.

Actions concrètes

• →Tranchez par écrit, produit par produit, si votre entreprise est « fabricant » au sens du Cyber Resilience Act — un logiciel ou un objet connecté vendu sous votre propre marque compte ; un développement livré sous la marque d’un client, en général non.
• →Si vous ne tenez pas d’inventaire des composants open source et tiers de votre produit (une nomenclature logicielle, ou SBOM), commencez-en un — on ne peut pas signaler une vulnérabilité qu’on n’a aucun moyen de détecter.
• →Désignez dès maintenant une personne ou une équipe responsable de l’alerte précoce à 24 heures et de la notification à 72 heures vers la plateforme de l’ENISA et le CERT-FR, avant d’en avoir besoin.
• →Mettez en place une surveillance continue des vulnérabilités activement exploitées touchant vos propres dépendances plutôt que de compter sur le hasard d’une veille informelle — c’est exactement le rôle que remplit une vigie opérations ou un agent de veille réglementaire dédié à ce suivi.
• →N’attendez pas l’échéance de décembre 2027 pour vous y mettre : le plafond d’amende pour un signalement manqué est déjà actif, indépendamment du reste du règlement.

Le gros titre retenu par la plupart des articles, c’est l’échéance de conformité de 2027. Ce qui mord réellement depuis cette semaine est plus discret et facile à manquer — et concerne beaucoup plus de PME françaises que ne le laisse penser le mot « fabricant ».