Cyber Resilience Act : le 11 septembre 2026, votre logiciel devient un produit réglementé (et vous aurez 24 heures pour signaler une faille)

Dans trois semaines, une faille dans votre produit deviendra un signalement obligatoire

Depuis deux ans, les dirigeants que je croise ont tous entendu parler de NIS2. Beaucoup ont vérifié s'ils étaient dans les 18 secteurs, s'ils passaient le seuil des 50 salariés, et se sont rassurés : « on est trop petits ».

Le Cyber Resilience Act, lui, ne pose aucune de ces questions. Il ne regarde pas votre taille, ni votre secteur. Il regarde ce que vous vendez.

Le règlement (UE) 2024/2847, adopté le 23 octobre 2024, impose des exigences de cybersécurité à tout « produit comportant des éléments numériques » mis sur le marché européen. Un logiciel. Un firmware. Un objet connecté. Une application vendue sous votre marque. Et sa première échéance opérationnelle tombe le 11 septembre 2026 : à partir de cette date, toute vulnérabilité activement exploitée dans un de vos produits devra être signalée sous 24 heures.

Pas 24 heures ouvrées. 24 heures.

Et contrairement à NIS2, il n'y a aucun seuil d'exonération pour les PME ou les startups. Un éditeur de trois personnes qui vend un logiciel en Europe est soumis exactement aux mêmes obligations de signalement qu'un groupe du CAC 40. Source : Commission européenne — Cyber Resilience Act.

Le calendrier réel (deux dates, pas une)

La confusion la plus répandue sur le CRA, c'est de croire qu'il s'applique « en 2027 ». C'est vrai pour la majorité du texte. C'est faux pour la partie qui va vous tomber dessus en premier.

Le point que presque personne ne relève : l'obligation du 11 septembre 2026 ne s'applique pas seulement aux nouveaux produits. L'article 69 du règlement exempte bien les produits mis sur le marché avant le 11 décembre 2027 des exigences essentielles — c'est le mécanisme de « grandfathering », qui tombe si le produit subit ensuite une modification substantielle. Mais il fait expressément exception pour le signalement de l'article 14, qui couvre tout le parc existant. Une nuance honnête sur ces produits anciens : l'obligation porte sur la transmission de l'information, pas sur celle de produire un correctif à tout prix. Vous n'avez donc pas jusqu'à décembre 2027 pour construire un processus de signalement : vous avez jusqu'au 11 septembre.

Êtes-vous concerné ? (la question du périmètre, sans surpromesse)

C'est ici que la plupart des articles se trompent, dans un sens comme dans l'autre. Le périmètre du CRA a des frontières précises, et je préfère vous les donner honnêtement plutôt que de vous vendre une panique généralisée.

Le règlement vise les produits comportant des éléments numériques : logiciels et matériels connectables directement ou indirectement à un réseau. Il y ajoute, via l'article 3, les solutions de traitement de données à distance — ces backends distants développés par ou pour le fabricant, sans lesquels le produit ne peut pas remplir une de ses fonctions.

Deux nuances méritent qu'on s'y arrête, parce que ce sont elles qui piègent les PME.

Première nuance : le SaaS. Un logiciel fourni uniquement en tant que service est explicitement exclu du CRA. Mais si votre plateforme est le backend sans lequel un produit physique ou un logiciel distribué ne fonctionne pas, elle rentre dans le périmètre au titre des solutions de traitement de données à distance. Une balance connectée et son application, une montre et son cloud, un boîtier industriel et son portail : le service en ligne suit le régime du produit. Le test est simple — le backend tourne à distance, le produit en a besoin pour fonctionner, il a été développé par ou pour le fabricant : c'est dans le champ.

Seconde nuance : la marque blanche. Le règlement définit le fabricant comme celui qui conçoit un produit ou le fait concevoir, et le commercialise sous son propre nom ou sa propre marque. Autrement dit : si vous faites développer un logiciel par un prestataire et que vous le vendez sous votre marque, le fabricant au sens du CRA, c'est vous. Même chose si vous distribuez un produit tiers en le rebaptisant, ou si vous lui apportez une modification substantielle. Ce « pont du rebranding » transfère l'intégralité des obligations sur vos épaules.

C'est un point que je répète systématiquement aux clients qui me font développer un produit sur mesure : le prestataire construit, mais la responsabilité réglementaire reste chez celui dont le nom est sur le produit.

Le mécanisme : 24 h, 72 h, 14 jours

À partir du 11 septembre 2026, deux types d'événements déclenchent une obligation de signalement : une vulnérabilité activement exploitée dans un de vos produits, et un incident grave ayant un impact sur la sécurité du produit.

Le signalement se fait via la plateforme unique de signalement (Single Reporting Platform) opérée par l'ENISA, l'agence européenne de cybersécurité. En France, les notifications transmises via cette plateforme sont simultanément relayées au CERT-FR, l'équipe de réponse à incident de l'ANSSI. Source : cyber.gouv.fr — Cyber Resilience Act.

Le calendrier est une escalade en trois temps :

• •Sous 24 heures — l'alerte précoce. Dès que vous avez connaissance de l'exploitation active d'une vulnérabilité ou d'un incident grave, vous émettez une première alerte. Elle peut être minimale : ce qui compte, c'est le délai.
• •Sous 72 heures — la notification complète. Vous complétez avec une évaluation initiale : nature de la faille, gravité, impact, et les mesures correctives ou d'atténuation déjà prises.
• •Sous 14 jours après la mise à disposition d'un correctif — le rapport final pour une vulnérabilité. Pour un incident grave, le rapport final est attendu sous un mois.

Lisez à nouveau le premier délai et posez-vous la vraie question : si une faille exploitée était signalée demain matin à 9 h sur votre produit, qui la reçoit ? qui décide qu'il faut notifier ? qui a le compte sur la plateforme ? Dans la grande majorité des PME que je vois, la réponse honnête est : personne. Le mail arrive sur une adresse générique, il est traité « quand quelqu'un aura le temps », et 24 heures ont passé avant même que le sujet ne remonte au dirigeant.

Ce n'est pas un problème technique. C'est un problème d'organisation — et c'est justement ce qui rend l'échéance de septembre atteignable même pour une petite structure.

Ce que vous risquez

Le CRA prévoit un barème à trois niveaux, et retient toujours le montant le plus élevé entre la valeur absolue et le pourcentage du chiffre d'affaires annuel mondial :

• •15 millions d'euros ou 2,5 % du CA mondial — non-respect des exigences essentielles de cybersécurité (annexe I) ou des obligations de gestion et de signalement des vulnérabilités. C'est le niveau qui couvre l'échéance de septembre 2026.
• •10 millions d'euros ou 2 % du CA mondial — non-respect des autres obligations du règlement (documentation, information des utilisateurs, coopération).
• •5 millions d'euros ou 1 % du CA mondial — fourniture d'informations incorrectes, incomplètes ou trompeuses aux autorités de surveillance.

Attention au piège de lecture : « le montant le plus élevé » ne protège pas les petites structures, il fait l'inverse. Pour une entreprise à 3 M€ de chiffre d'affaires, 2,5 % représentent 75 000 € — mais c'est bien 15 M€ qui reste le plafond légal, puisque c'est le plus élevé des deux montants. Les autorités doivent tenir compte de la taille de l'entreprise et appliquer un principe de proportionnalité, et en pratique aucune PME ne se verra infliger 15 M€ ; il n'empêche que votre chiffre d'affaires ne réduit pas le plafond théorique, contrairement à ce qu'on lit souvent.

Le règlement prévoit en revanche une exemption ciblée, et une seule. L'article 64, paragraphe 10, dispense les microentreprises (moins de 10 salariés et 2 M€) et les petites entreprises (moins de 50 salariés et 10 M€) de toute amende pour le seul non-respect du délai d'alerte précoce de 24 heures — celui de l'article 14(2)(a) pour une vulnérabilité et de l'article 14(4)(a) pour un incident grave. Lisez bien ce qu'elle ne dit pas : l'obligation de signaler demeure entière, les délais de 72 heures et de rapport final restent sanctionnables, et une entreprise moyenne (50 à 249 salariés) n'en bénéficie pas. C'est un filet de sécurité sur le premier délai, pas une dispense.

Et les sanctions financières ne sont de toute façon pas le vrai risque à court terme : l'autorité de surveillance du marché peut aussi ordonner le retrait ou le rappel d'un produit non conforme. Pour un éditeur, c'est le produit qui sort du marché européen — un risque commercial d'un tout autre ordre qu'une amende.

En France, le projet de loi Ddadue 2026 organise la gouvernance nationale : l'ANFR (Agence nationale des fréquences) est désignée autorité de surveillance du marché pour les produits comportant des éléments numériques, et l'ANSSI autorité notifiante, chargée d'encadrer les organismes d'évaluation de la conformité. Le texte a été adopté en première lecture au Sénat le 18 février 2026, en procédure accélérée, et attend son examen à l'Assemblée nationale : la désignation n'est donc pas encore définitive. Source : analyse Lexing sur la gouvernance nationale du CRA.

L'angle que personne ne vous vend : le CRA est un argument commercial

Tout le monde présente le CRA comme une contrainte. Je le vois arriver autrement, et c'est ce que je dis aux éditeurs que j'accompagne.

À partir de décembre 2027, un produit conforme portera le marquage CE au titre de la cybersécurité. Vos clients — surtout les entreprises assujetties à NIS2, qui doivent sécuriser leur chaîne d'approvisionnement — vont commencer à le demander bien avant. Comme pour NIS2, l'obligation légale d'un client devient l'exigence contractuelle de son fournisseur.

Trois choses vont sortir du CRA et devenir des différenciateurs à l'achat :

• •Le SBOM (Software Bill of Materials), l'inventaire lisible par machine de vos composants. L'annexe I n'exige au minimum que les dépendances de premier niveau, et la Commission doit encore préciser le format par acte d'exécution — mais rien ne vous empêche d'aller plus loin dès maintenant. C'est exactement ce qui a manqué à des milliers d'entreprises lors des attaques sur la chaîne d'approvisionnement logicielle — voir ce que j'écrivais sur le piratage d'Axios sur npm. Un éditeur capable de dire en dix minutes « voici mes 400 dépendances et leurs versions » répond à un appel d'offres que ses concurrents ne peuvent pas honorer.
• •La période de support, avec des mises à jour de sécurité gratuites pendant au moins cinq ans (ou la durée d'utilisation prévue du produit si elle est plus courte). C'est un engagement écrit, opposable, que vos concurrents devront afficher aussi.
• •Une politique de divulgation des vulnérabilités et un point de contact sécurité publics. Ça coûte une page sur votre site. Ça rassure immédiatement un acheteur grand compte.

Autrement dit : ce que le CRA vous force à construire, ce sont des preuves de sérieux que vos clients cherchent déjà. La question n'est pas de savoir si vous allez le faire, mais si vous le ferez en septembre 2026 par anticipation, ou en décembre 2027 dans l'urgence, avec le même prestataire, au double du prix.

Les quatre idées fausses qui vont coûter cher

1. « On est trop petits, comme pour NIS2 »

C'est le contresens le plus coûteux. NIS2 réglemente des entités et prévoit des seuils de taille et de secteur. Le CRA réglemente des produits et ne prévoit aucun seuil d'exonération. Une startup de trois personnes qui distribue un logiciel dans l'Union est un fabricant au sens du règlement. Il existe des allègements réels pour les micro et petites entreprises : documentation technique simplifiée, outils d'auto-évaluation publiés par l'ENISA (le SME Cyber Resilience Maturity Assessment Model, sorti le 13 juillet 2026), et surtout l'exemption d'amende de l'article 64(10) sur le seul délai de 24 heures. Mais des allègements ne sont pas des exemptions : l'obligation de signaler s'applique à vous comme aux autres, et une entreprise moyenne n'a droit à aucun de ces aménagements.

2. « On fait du SaaS, on est hors champ »

Vrai pour un SaaS autonome. Faux dès que votre plateforme est le backend d'un produit distribué : dans ce cas, elle est traitée comme une partie intégrante du produit. Et même pour un SaaS réellement hors champ, la question ne s'arrête pas là : si vous distribuez une application mobile, un agent à installer, un plugin ou un SDK, ces composants-là sont des produits. Beaucoup d'éditeurs « SaaS » ont, sans y penser, au moins un artefact distribué dans leur catalogue.

3. « C'est notre prestataire qui développe, c'est son problème »

Non. Le fabricant, c'est celui qui conçoit ou fait concevoir un produit et le commercialise sous son nom. Si le logiciel porte votre marque, les obligations sont les vôtres — le signalement sous 24 heures compris. Ce que vous pouvez et devez faire, en revanche, c'est l'inscrire au contrat : engagement du prestataire sur la remontée immédiate des vulnérabilités, fourniture du SBOM à chaque livraison, durée de maintien des correctifs de sécurité. Si vos contrats de développement actuels ne contiennent rien de tout ça, c'est le premier chantier.

4. « L'open source, c'est exclu »

Non plus. Les logiciels libres et ouverts sont dans le champ du règlement dès lors qu'ils sont mis sur le marché dans le cadre d'une activité commerciale. Le CRA aménage un régime spécifique et nettement allégé pour les « open source stewards » — fondations et organisations à but non lucratif qui soutiennent durablement des projets : ni marquage CE, ni évaluation de conformité, ni documentation technique à conserver, et l'article 64 les place hors du champ des amendes administratives. Il exclut par ailleurs les contributeurs individuels non commerciaux, et la fourniture d'un logiciel non monétisé n'est pas une activité commerciale. Mais si vous packagez, distribuez et monétisez un produit basé sur de l'open source, vous en êtes le fabricant. Vos dépendances deviennent votre responsabilité : c'est précisément l'objet du SBOM.

Votre plan en 4 étapes avant le 11 septembre 2026

Il reste peu de temps, mais l'échéance de septembre est beaucoup plus légère que celle de 2027 : il s'agit d'être capable de signaler, pas encore d'être pleinement conforme. C'est faisable en quelques semaines.

Étape 1 — Inventoriez ce que vous mettez sur le marché (semaine 1)

Listez tout ce que votre entreprise distribue en Europe : logiciels, applications mobiles, firmwares, objets connectés, plugins, SDK, images de conteneurs, ainsi que les backends sans lesquels ces produits ne fonctionnent pas. Pour chaque ligne, tranchez votre rôle : fabricant, importateur, distributeur — et repérez immédiatement les produits vendus sous votre marque mais développés par un tiers, car ceux-là font de vous le fabricant.

Étape 2 — Désignez un point de contact sécurité et une chaîne d'alerte (semaine 2)

Nommez une personne responsable de la réception des signalements de vulnérabilités et une doublure, publiez une adresse de contact sécurité sur votre site, et écrivez noir sur blanc qui décide de notifier, sous quel délai, et qui prend le relais en congés ou le week-end. Le délai de 24 heures ne se tient pas avec de la bonne volonté : il se tient avec un nom, un numéro de téléphone et une procédure d'une page.

Étape 3 — Établissez votre SBOM et surveillez vos dépendances (semaines 3-4)

Générez la nomenclature logicielle de chaque produit dans un format lisible par machine (CycloneDX ou SPDX), automatisez sa production à chaque build, et branchez une surveillance des vulnérabilités connues sur vos dépendances. Sans SBOM, vous ne pouvez pas savoir en 24 heures si une faille publiée touche vos produits — et c'est pourtant exactement la question qui vous sera posée.

Étape 4 — Testez la procédure à blanc et sécurisez vos contrats (semaines 5-6)

Faites un exercice : quelqu'un signale une vulnérabilité exploitée un vendredi à 18 h, et vous déroulez la chaîne jusqu'au projet de notification. Chronométrez, corrigez ce qui bloque. En parallèle, ajoutez à vos contrats de développement et à vos conditions fournisseurs les clauses de remontée de vulnérabilité, de fourniture du SBOM et de durée de maintien des correctifs. Une procédure jamais testée et des contrats muets, c'est une non-conformité qui se découvre le jour de l'incident.

Conclusion : le 11 septembre ne demande pas d'être parfait, mais d'être joignable

Le Cyber Resilience Act est un texte lourd, et sa mise en conformité complète — exigences essentielles, documentation technique, marquage CE — est un vrai chantier qui vous occupera jusqu'à décembre 2027.

Mais ce qui tombe dans trois semaines est d'une autre nature. Le 11 septembre 2026 ne vous demande pas d'avoir un produit parfaitement sécurisé. Il vous demande d'être capable de réagir en 24 heures quand une faille de votre produit est activement exploitée. Un responsable identifié, une adresse de contact publiée, une procédure d'une page, un inventaire de vos dépendances. C'est court, c'est concret, et ça se met en place en quelques semaines.

Ceux qui rateront cette marche ne le rateront pas par manque de moyens. Ils le rateront parce que personne, chez eux, n'aura jamais posé la question : *« si ça arrive demain, qui décroche ? »*

Vous vendez un logiciel, une application ou un produit connecté et vous vous demandez si le CRA vous vise, et par où commencer ? Parlons-en : en 30 minutes, on passe en revue ce que vous mettez sur le marché, votre rôle exact au sens du règlement, et les deux ou trois actions à mener avant septembre.

Questions fréquentes

Ma PME est-elle concernée par le Cyber Resilience Act ?

Si vous mettez sur le marché européen un logiciel, une application, un firmware ou un objet connecté, oui — quelle que soit votre taille. Contrairement à NIS2, qui réglemente des entités avec des seuils de secteur et d'effectif, le Cyber Resilience Act réglemente des produits et ne prévoit aucun seuil d'exonération pour les PME ou les startups. Il existe des allègements pour les petites structures — documentation technique simplifiée, outils d'auto-évaluation de l'ENISA, et une exemption d'amende sur le seul délai d'alerte de 24 heures pour les microentreprises et les petites entreprises — mais ce sont des allègements de sanction et de procédure, pas une sortie du périmètre.

Que dois-je faire précisément au 11 septembre 2026 ?

À partir de cette date, vous devez signaler toute vulnérabilité activement exploitée dans un de vos produits, ainsi que tout incident grave affectant leur sécurité, via la plateforme unique de signalement gérée par l'ENISA. Le calendrier est une escalade : alerte précoce sous 24 heures, notification complète avec évaluation de la gravité sous 72 heures, rapport final sous 14 jours après la mise à disposition d'un correctif (ou sous un mois pour un incident grave). En France, ces signalements sont relayés au CERT-FR, désigné CSIRT coordinateur. Attention : cette obligation couvre aussi les produits déjà commercialisés, pas seulement les nouveaux. Seule souplesse prévue par le règlement : les microentreprises et les petites entreprises ne sont pas passibles d'amende pour le seul dépassement du délai de 24 heures — mais elles restent tenues de signaler, et les délais suivants leur sont opposables.

Mon SaaS est-il concerné par le CRA ?

Un logiciel fourni uniquement en tant que service, autonome et sans produit associé, est explicitement exclu du champ du règlement. Mais l'exclusion tombe si votre plateforme est une « solution de traitement de données à distance », c'est-à-dire le backend développé par ou pour vous sans lequel un produit distribué ne pourrait pas remplir une de ses fonctions — le cloud d'un objet connecté, par exemple. Vérifiez également si vous distribuez une application mobile, un agent, un plugin ou un SDK : ces composants-là sont des produits au sens du CRA, même si votre offre principale est un SaaS.

C'est mon prestataire qui développe le logiciel : est-ce lui le responsable ?

Non. Le règlement définit le fabricant comme l'entité qui conçoit ou fait concevoir un produit et le commercialise sous son propre nom ou sa propre marque. Si le logiciel porte votre marque, les obligations du CRA sont les vôtres, y compris le signalement sous 24 heures. La bonne réponse n'est pas de transférer la responsabilité, c'est de la couvrir contractuellement : engagement du prestataire sur la remontée immédiate des vulnérabilités, fourniture d'un SBOM à chaque livraison, et durée de maintien des correctifs de sécurité.

Quelles sont les sanctions prévues par le Cyber Resilience Act ?

Le barème comporte trois niveaux, et retient toujours le montant le plus élevé entre la valeur absolue et le pourcentage du chiffre d'affaires annuel mondial : jusqu'à 15 M€ ou 2,5 % pour le non-respect des exigences essentielles (annexe I) ou des obligations des articles 13 et 14 ; jusqu'à 10 M€ ou 2 % pour les autres obligations ; jusqu'à 5 M€ ou 1 % pour des informations incorrectes ou trompeuses fournies aux autorités. Contrairement à une idée reçue, « le montant le plus élevé » ne ramène pas la sanction au pourcentage pour une petite structure : c'est la valeur absolue qui reste le maximum légal, même si les autorités doivent appliquer un principe de proportionnalité. Une seule exemption existe (article 64, paragraphe 10) : les microentreprises et les petites entreprises ne peuvent pas être sanctionnées pour le seul dépassement du délai d'alerte de 24 heures. Au-delà des amendes, l'autorité de surveillance du marché peut ordonner le retrait ou le rappel d'un produit non conforme — souvent le risque le plus lourd pour un éditeur.

Quelle différence entre NIS2 et le Cyber Resilience Act ?

NIS2 réglemente des organisations : elle impose des mesures de sécurité et une notification d'incident aux entités de 18 secteurs critiques atteignant un seuil de taille. Le CRA réglemente des produits : il impose des exigences de sécurité, un signalement des vulnérabilités exploitées et, à terme, un marquage CE à tout produit comportant des éléments numériques vendu dans l'Union, sans condition de taille. Les deux se combinent fréquemment : une entreprise assujettie à NIS2 doit sécuriser sa chaîne d'approvisionnement, et exigera donc de ses fournisseurs des produits conformes au CRA — bien avant l'échéance de décembre 2027.