Deux tiers des acteurs interrogés dans l'écosystème logiciel déclarent connaître peu ou pas du tout le Cyber Resilience Act, et cette proportion a augmenté en un an : 66 % en 2026 contre 62 % en 2025 (Linux Foundation Research et OpenSSF, CRA Awareness and Readiness Report, juin 2026, 843 répondants). Du côté des PME européennes, l'ENISA mesure l'écart autrement : 66 % des organisations interrogées avaient entendu parler du règlement, mais seules 35 % tiennent une nomenclature logicielle de leurs produits et 54 % déclarent une compréhension limitée ou nulle des procédures d'évaluation de la conformité (ENISA, SME CRA Survey Report, juin 2026, 194 organisations dans 31 pays).
Le paradoxe tient en une phrase : le texte est connu, sa mécanique ne l'est pas. Et la première échéance contraignante n'est pas en décembre 2027, comme le croient 34 % seulement des répondants correctement informés. Elle tombe le 11 septembre 2026, dans moins de six semaines. Cet article documente ce qui s'applique exactement à cette date, pourquoi elle concerne des produits que vous avez déjà vendus et livrés, et ce qu'un dirigeant de PME ou d'ETI industrielle doit avoir tranché d'ici là.
Ce qui tombe le 11 septembre 2026, et ce qui attend décembre 2027
Le Cyber Resilience Act est le règlement (UE) 2024/2847, dit règlement sur la cyberrésilience, adopté le 23 octobre 2024 et entré en vigueur le 10 décembre 2024. Il ne régule pas votre organisation : il régule les produits comportant des éléments numériques que vous mettez sur le marché européen. C'est une différence structurante, sur laquelle nous revenons plus bas.
Son application est échelonnée en trois jalons :
- 11 juin 2026 : entrée en application des dispositions relatives aux organismes d'évaluation de la conformité.
- 11 septembre 2026 : entrée en application de l'article 14, les obligations de signalement.
- 11 décembre 2027 : application complète, exigences essentielles de cybersécurité, documentation technique, déclaration UE de conformité et marquage CE.
Ce qui commence le 11 septembre porte sur deux types d'événements, et deux seulement : une vulnérabilité activement exploitée affectant l'un de vos produits, c'est-à-dire une faille pour laquelle il existe une preuve fiable qu'un acteur malveillant l'a exploitée sans autorisation, et un incident grave ayant une incidence sur la sécurité du produit.
Le rythme est fixé et il est court :
| Étape |
Délai |
Objet |
| Alerte précoce |
24 heures |
Identification du produit, évaluation initiale de la gravité, confirmation de l'exploitation |
| Notification |
72 heures |
Informations générales et première évaluation |
| Rapport final (vulnérabilité) |
14 jours après disponibilité d'une mesure corrective |
Description et correctif |
| Rapport final (incident grave) |
1 mois après la notification |
Analyse complète |
Les signalements sont adressés simultanément à l'ENISA et au CSIRT désigné coordinateur de votre État membre principal, en France le CERT-FR, via la Single Reporting Platform, la plateforme unique de signalement opérée par l'ENISA et prévue opérationnelle le 11 septembre 2026.
Reste la question qui décide de tout en pratique : quand le compteur démarre-t-il ? La Commission européenne a publié le 27 juillet 2026 sa première guidance officielle d'application du règlement (communication C(2026) 5252). Elle précise qu'un fabricant est réputé avoir connaissance d'un événement lorsque, après une évaluation initiale, il dispose d'un degré raisonnable de certitude qu'une vulnérabilité de son produit est activement exploitée ou qu'un incident grave a compromis sa sécurité. Autrement dit, le chronomètre ne part pas au premier signal faible, mais il part bien avant que vous ayez un correctif.
Le CRA ne vous demande pas d'avoir zéro faille. Il vous demande d'être capable de dire, en 24 heures, laquelle, dans quel produit, chez quels clients.
Le point que le calendrier fait rater : vos produits déjà vendus sont concernés
C'est l'erreur de lecture la plus répandue, et celle qui coûtera le plus cher. Le raisonnement spontané en comité de direction est le suivant : « les exigences produit s'appliquent en décembre 2027, donc nos produits actuellement en service ne sont pas concernés ». Il est faux, et le texte le dit explicitement.
L'article 69, paragraphe 2, exempte bien les produits mis sur le marché avant le 11 décembre 2027 des exigences essentielles, de la documentation technique et du marquage CE, sauf modification substantielle ultérieure. Mais le paragraphe 3 retire expressément l'obligation de signalement de l'article 14 de cette exemption. La conséquence est directe : l'automate, la passerelle industrielle, le capteur communicant ou la version logicielle que vous avez livrés il y a trois ans entrent dans le périmètre du signalement dès le 11 septembre 2026, même s'ils ne porteront jamais de marquage CE au titre du CRA.
Une nuance utile, apportée par la guidance du 27 juillet : il n'existe aucune obligation de déclaration rétroactive pour une exploitation active dont le fabricant avait déjà connaissance avant le 11 septembre 2026. Le stock de failles connues n'a pas à être déclaré. Le flux, lui, l'est intégralement, sur l'ensemble du parc installé.
Pour une PME industrielle, ce seul paragraphe change la nature du chantier. Il ne s'agit plus de préparer la conformité des produits de demain, avec dix-huit mois devant soi. Il s'agit de savoir, dans six semaines, ce que l'on a vendu, à qui, et dans quelle version.
Sur le terrain : ce que les praticiens signalent cet été
Les signaux publics de juillet 2026 convergent sur un point : l'écosystème technique a compris que l'échéance de septembre est la première vraie, et se prépare dans l'urgence.
Un média européen spécialisé dans l'électronique embarquée a consacré fin juillet une série en plusieurs volets à ce que le règlement change concrètement pour les fabricants, et un webinaire dédié à ce qu'il appelle « le côté pratique de la conformité », centré sur le développement produit sécurisé et la gestion des vulnérabilités. Le cadrage retenu est révélateur : la question posée aux industriels n'est pas « connaissez-vous le texte », mais « votre produit connecté est-il prêt ».
Une fondation logicielle européenne annonçait de son côté, fin juillet également, la tenue à Bruxelles d'un rendez-vous consacré à la conformité du code, avec un argument d'ouverture sans détour : les premières obligations du CRA démarrent en septembre. Un éditeur allemand d'outils de conformité, commentant la publication de la guidance de la Commission, retenait trois points comme prioritaires pour les entreprises : le périmètre d'application, la notion de modification substantielle, et les obligations de signalement applicables à compter du 11 septembre 2026. Ces trois points sont exactement ceux que la présente analyse détaille, et ce n'est pas un hasard : ce sont les trois qui décident si vous êtes concerné, et à quel titre.
Enfin, un intégrateur spécialisé dans les objets connectés résumait en juin l'état du terrain d'une formule que nos propres missions confirment : le règlement est en vigueur, et la plupart des fabricants d'équipements connectés ne sont pas prêts, principalement parce qu'ils passent à côté des échéances intermédiaires.
Êtes-vous « fabricant » au sens du CRA ? Quatre cas qui surprennent
Le règlement ne vise pas des entreprises, il vise des rôles à l'égard d'un produit. Est fabricant, au sens de l'article 3, point 13, toute personne qui conçoit ou développe un produit comportant des éléments numériques, ou le fait concevoir pour son compte, et le met sur le marché sous son nom ou sa marque. La forme juridique et la taille n'entrent pas dans l'équation. Quatre situations attrapent régulièrement des PME qui ne se pensaient pas concernées.
La machine qui embarque un automate. Vous fabriquez une ligne de conditionnement, une presse, un système de dosage. Elle contient un automate, une interface homme-machine, parfois une passerelle de télémaintenance. C'est un produit comportant des éléments numériques. Une connexion de données, logique ou physique, directe ou indirecte, suffit à faire entrer le produit dans le champ.
Le logiciel vendu séparément. Le CRA couvre aussi les produits logiciels et les composants matériels ou logiciels mis sur le marché indépendamment. Un éditeur métier de dix personnes est un fabricant au même titre qu'un groupe industriel.
Le produit revendu sous votre marque. Vous achetez un boîtier à un fournisseur asiatique, vous y apposez votre nom, vous le vendez. Vous n'êtes pas distributeur, vous êtes fabricant, avec l'intégralité des obligations correspondantes. C'est le cas de figure le plus sous-estimé dans les PME de négoce technique.
La modification substantielle. L'article 22 prévoit que toute personne qui apporte une modification substantielle à un produit et le remet à disposition sur le marché est considérée comme fabricant, et se voit appliquer les articles 13 et 14. La modification substantielle est définie à l'article 3, point 30 : un changement postérieur à la mise sur le marché qui affecte la conformité aux exigences essentielles ou modifie la destination du produit. La guidance de la Commission précise que les mises à jour logicielles courantes n'en constituent généralement pas, sauf lorsqu'elles introduisent de nouveaux vecteurs de menace ou changent l'usage prévu.
Restent les exclusions, qui comptent autant. Les dispositifs médicaux, les véhicules à moteur et l'aviation civile relèvent de leurs cadres sectoriels propres. Le SaaS autonome est hors du champ du CRA et relève principalement de la directive NIS 2, que nous avons traitée dans notre analyse des 15 000 entités françaises concernées par NIS 2. En revanche, une solution de traitement de données à distance conçue par le fabricant ou pour son compte, indispensable au fonctionnement du produit, dont l'absence empêcherait le produit d'exécuter une fonction essentielle, est juridiquement traitée comme une composante du produit (article 3, point 2). Le portail cloud de votre machine n'est pas un service à côté du produit : c'est le produit.
24 heures : un problème d'information avant d'être un problème de cybersécurité
Voici l'exercice à faire cette semaine, en réunion de direction, sans consultant et sans budget. Prenez votre produit connecté le plus diffusé et répondez à cinq questions, chronomètre en main :
- Quelles versions de ce produit sont actuellement en service chez des clients ?
- Quels composants logiciels tiers chacune de ces versions embarque-t-elle, et dans quelle version ?
- Quels clients détiennent quelle version, et comment les joindre en moins de 24 heures ?
- Qui, dans l'entreprise, décide qu'une information reçue constitue une « exploitation active » ?
- Qui signe la déclaration à l'ENISA et au CERT-FR, et qui signe quand cette personne est en congés ?
Dans la grande majorité des PME et ETI industrielles que nous accompagnons, les questions 1 et 3 se répondent en quelques heures, la question 2 en quelques semaines, et les questions 4 et 5 n'ont pas de réponse du tout. C'est le diagnostic important : le goulot d'étranglement du 11 septembre n'est pas un centre de supervision de sécurité, c'est un référentiel produit et une chaîne de décision. Le CRA est d'abord un problème d'information sur ce que vous vendez.
Le réflexe inverse, acheter un outil de gestion de vulnérabilités et considérer le sujet réglé, est celui que documente toute la littérature sur l'échec des projets technologiques. Les travaux du MIT sur l'IA générative chiffraient l'an dernier à 95 % la part des initiatives ne produisant aucun retour mesurable (MIT NANDA, juillet 2025), pour une raison qui vaut intégralement ici : l'outil arrive avant le processus, et personne n'a cartographié ce que l'outil est censé surveiller. Chez Nymphar.AI, nous prenons systématiquement le problème dans l'autre sens, en partant du parc réel et des processus existants avant de parler d'outillage. C'est le principe d'un audit de cadrage bottom-up : on ne sécurise pas ce qu'on n'a pas inventorié.
Une PME qui ne sait pas dire en 24 heures quel client utilise quelle version n'a pas un problème de cybersécurité. Elle a un problème de données produit, et il se règle avec les mêmes méthodes que n'importe quel chantier data.
Le SBOM, ou pourquoi peu d'industriels savent ce qu'ils vendent
L'annexe I, partie II du règlement impose au fabricant de mettre en place des processus de traitement des vulnérabilités, et la documentation technique doit inclure une nomenclature logicielle, le software bill of materials ou SBOM, couvrant au minimum les dépendances de premier niveau du produit.
Les chiffres de préparation sont sans ambiguïté. Seulement 32 % des fabricants produisent un SBOM pour l'ensemble de leurs produits, une proportion stable depuis un an, et 51 % continuent de dépendre passivement des projets amont pour les correctifs de sécurité, en hausse par rapport à 46 % l'année précédente (Linux Foundation Research et OpenSSF, juin 2026). Chez les PME européennes, la proportion utilisant un SBOM tombe à 35 %, et la moitié des micro-entreprises en sont encore à un traitement improvisé de la sécurité produit, sans processus formalisé (ENISA, juin 2026). Des travaux académiques sur les fabricants d'équipements industriels relevaient un écart de maturité encore plus brutal entre PME et très grandes entreprises en matière de connaissance du texte.
Un SBOM exploitable documente, pour chaque composant : son nom, sa version exacte telle que déployée, son fournisseur ou son auteur, l'arbre de dépendances, la licence applicable et un identifiant normalisé. Ce n'est pas un document de conformité que l'on produit une fois : c'est un actif vivant, archivé version par version, qui doit être conservé au minimum dix ans après la mise sur le marché.
L'argument de conformité est le moins intéressant des trois. Le premier bénéfice réel est le temps de réaction : quand une vulnérabilité critique est publiée sur une bibliothèque très répandue, l'entreprise qui tient un SBOM sait en minutes si elle est exposée et où, quand les autres mobilisent leurs équipes pendant des semaines. Le deuxième est commercial : la nomenclature est ce qui vous permet de répondre aux questionnaires fournisseurs de vos clients grands comptes. Le troisième est patrimonial, et il parle directement aux dirigeants en préparation de transmission : un parc produit dont on connaît la composition et le cycle de vie se valorise, un parc opaque se décote. C'est exactement la logique que nous développons sur l'exploitation des données d'équipements dans notre analyse du Data Act et des données de vos machines, et que nous appliquons en mission sur les sujets d'IA et de données en industrie.
Période de support : la clause qui engage vos dix prochaines années
C'est la disposition la moins commentée du règlement, et probablement celle qui aura le plus d'effet sur vos marges.
L'article 13, paragraphe 8, impose au fabricant de fixer une période d'assistance reflétant la durée pendant laquelle le produit est censé être utilisé, avec un plancher : au moins cinq ans, sauf si le produit est destiné à être utilisé moins longtemps, auquel cas la période correspond à la durée d'utilisation prévue. La lecture est contre-intuitive pour un industriel : cinq ans est un plancher, pas un plafond. Une machine-outil conçue pour durer quinze ans engage quinze ans de traitement des vulnérabilités et de mises à jour de sécurité gratuites.
Deux obligations de conservation s'y ajoutent. Chaque mise à jour de sécurité mise à disposition pendant la période d'assistance doit rester accessible au moins dix ans après son émission, ou pendant le reste de la période d'assistance si celle-ci est plus longue (article 13, paragraphe 9). La documentation technique et la déclaration UE de conformité doivent être tenues à disposition des autorités de surveillance du marché dix ans après la mise sur le marché, ou pendant la période d'assistance, la plus longue des deux durées étant retenue (article 13, paragraphe 13).
Traduit en gestion : le CRA transforme une partie de votre coût produit en charge récurrente pluriannuelle. Elle doit être modélisée dans le prix de vente et dans le plan de trésorerie, produit par produit. C'est aussi la raison pour laquelle 47 % des fabricants de taille PME anticipent une hausse de leurs prix pour absorber le coût de la conformité (Linux Foundation Research et OpenSSF, juin 2026). Celui qui sait chiffrer ce coût le répercute, celui qui ne le sait pas le subit sur sa marge.
Ce que coûte l'inaction
Le barème d'abord. Le manquement aux obligations du règlement, y compris à l'obligation de signalement, expose à 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. La formulation mérite d'être notée, car elle est l'inverse de celle de l'AI Act, dont l'article 99, paragraphe 6, retient pour les PME le montant le plus faible des deux. Nous avions détaillé cette clause dans notre analyse de ce qui s'applique au titre de l'AI Act. Sur le CRA, aucune atténuation équivalente n'est prévue en fonction de la taille.
Mais pour une PME, la sanction n'est pas le premier risque, et il serait malhonnête de vendre la peur du contrôle. La surveillance du marché montera en charge progressivement, et environ 90 % des produits relèvent de la catégorie par défaut, c'est-à-dire de l'auto-évaluation : personne ne viendra vérifier votre dossier avant qu'un incident ne se produise.
Le risque réel est commercial et il est déjà là. Vos clients grands comptes et vos donneurs d'ordre publics sont, eux, soumis à NIS 2, qui les oblige à sécuriser leur chaîne d'approvisionnement. Ils répercutent cette obligation par voie contractuelle. Concrètement, à partir de l'automne 2026, les questionnaires fournisseurs demanderont votre nomenclature logicielle, votre politique de divulgation coordonnée des vulnérabilités, votre période d'assistance déclarée et votre procédure de signalement. Le fournisseur qui ne peut pas répondre ne prend pas d'amende : il sort de la liste. C'est un coût sans procédure, sans notification, et sans possibilité de recours.
Six semaines : la séquence à dérouler d'ici le 11 septembre
Aucune PME ne sera pleinement conforme au CRA le 11 septembre, et ce n'est pas l'objectif. L'objectif est d'être capable de signaler dans les délais, et d'avoir tranché le périmètre. Voici la séquence que nous déroulons en mission, dans cet ordre, parce que chaque étape conditionne la suivante.
Semaine 1, trancher le périmètre. Listez tout ce que vous mettez sur le marché européen sous votre nom ou votre marque et qui comporte un élément numérique, y compris ce que vous achetez pour le revendre sous votre marque. Pour chaque ligne, tranchez : fabricant, importateur, distributeur, ou hors champ. Une demi-journée de comité de direction suffit, et ce document est le seul livrable dont tout le reste dépend.
Semaine 2, cartographier le parc installé. Croisez produits, versions livrées et clients. C'est un travail de données, pas de sécurité : vos systèmes de gestion commerciale, de production et de service après-vente contiennent déjà l'essentiel de l'information, rarement au même endroit. Le livrable est une table unique, à jour, interrogeable en moins d'une heure.
Semaines 3 et 4, un premier SBOM sur deux produits. Pas sur le catalogue entier. Prenez les deux produits les plus diffusés ou les plus exposés, établissez leur nomenclature de premier niveau, et industrialisez la génération dans votre chaîne de compilation plutôt que de la maintenir à la main. L'exercice sur deux produits vous apprend ce que coûtera le reste.
Semaine 5, écrire la procédure de signalement. Qui reçoit l'information, par quel canal, qui la qualifie, sous quel délai, qui déclare, qui supplée. Créez et publiez l'adresse de contact de divulgation des vulnérabilités, identifiez le point d'entrée CERT-FR et préparez les comptes nécessaires sur la plateforme de signalement de l'ENISA. Une page suffit, à condition qu'elle nomme des personnes et pas des services.
Semaine 6, un exercice à blanc. Simulez une vulnérabilité activement exploitée un vendredi à 17 heures et mesurez le temps réel jusqu'à une alerte précoce complète. Quatre-vingt-dix minutes d'exercice révèlent plus de failles de processus que trois mois de veille réglementaire. Notre checklist d'audit reprend cette logique de test sur données réelles plutôt que d'auto-déclaration.
Le 11 septembre, la question ne sera pas « êtes-vous conforme ». Elle sera « êtes-vous capable de produire une alerte précoce en 24 heures ». Ce sont deux chantiers différents, et seul le second est urgent.
CRA, NIS 2, AI Act, Data Act : qui couvre quoi
Quatre textes européens arrivent simultanément sur le bureau des dirigeants, avec des périmètres distincts que la presse spécialisée confond régulièrement. La grille de lecture tient en un tableau.
| Texte |
Ce qu'il régule |
Qui est visé |
Prochaine échéance |
| Cyber Resilience Act |
Le produit que vous vendez |
Fabricants, importateurs, distributeurs |
11 septembre 2026, puis 11 décembre 2027 |
| NIS 2 |
La sécurité de votre organisation |
Entités essentielles et importantes |
Adoption de la loi Résilience |
| AI Act |
Les systèmes d'IA |
Fournisseurs et déployeurs |
Applicable depuis le 2 août 2026 |
| Data Act |
L'accès aux données des objets connectés |
Détenteurs et utilisateurs de données |
12 septembre 2026 |
La règle mnémotechnique est simple : NIS 2 regarde votre entreprise, le CRA regarde vos produits, l'AI Act regarde vos systèmes d'IA, le Data Act regarde vos données. Une PME industrielle qui vend des machines connectées et utilise un copilote IA en interne est concernée par les quatre, à des titres différents, avec un socle commun qui n'est jamais un outil : la cartographie de ce qu'elle possède, produit et exploite.
Questions fréquentes
Mon logiciel est vendu en SaaS, suis-je concerné ?
En principe non pour le CRA : les services SaaS autonomes sont exclus du champ du règlement et relèvent principalement de NIS 2. La nuance est importante et coûteuse à ignorer : si votre solution cloud est conçue par vos soins, indispensable au fonctionnement d'un produit que vous vendez, et que son absence empêcherait ce produit d'exécuter une de ses fonctions essentielles, elle est traitée comme une composante du produit et entre dans le périmètre. Le test est strict et se pose produit par produit, pas au niveau de l'entreprise.
Combien coûte une mise en conformité CRA pour une PME ?
Il n'existe pas de chiffre de référence crédible, et il faut se méfier de ceux qui en avancent un. Ce qui se chiffre, en revanche, ce sont les composantes : l'établissement du premier SBOM et son automatisation dans la chaîne de compilation, la mise à jour de la documentation technique, et surtout la charge récurrente de la période d'assistance, qui est la ligne la plus lourde sur la durée. Notre recommandation de cadrage est de chiffrer d'abord cette charge récurrente produit par produit, avant tout investissement d'outillage. C'est précisément l'objet d'un workshop de cadrage d'une journée à 2 500 €, qui produit le périmètre, la cartographie et l'estimation de charge.
En combien de temps voit-on un effet ?
Sur la capacité à signaler, six semaines suffisent si le périmètre est tranché dès la première semaine. Sur la maîtrise réelle de la composition logicielle du parc, comptez deux à trois trimestres pour un catalogue de taille moyenne, avec une montée en compétence progressive des équipes plutôt qu'un projet unique. C'est le format de nos sessions d'intelligence mensuelles à 800 € par mois, facturées mois par mois, conçues pour installer la compétence en interne au lieu de la louer indéfiniment.
Ce que ça change pour un dirigeant
Le Cyber Resilience Act ne se traite pas comme un dossier réglementaire à confier au responsable informatique ou à un avocat. Il touche à trois décisions de direction générale : ce que vous vendez et sous quelle marque, combien d'années vous vous engagez à maintenir chaque produit, et qui a autorité pour déclarer un incident aux autorités européennes en 24 heures.
Ces trois décisions ne s'achètent pas. Elles se prennent, à partir d'un état des lieux honnête du parc installé. C'est la raison pour laquelle nous abordons systématiquement ces sujets par la donnée avant de les aborder par la sécurité : la conformité est un sous-produit d'une cartographie propre, jamais l'inverse. Un dirigeant qui sort de l'été avec un périmètre tranché, une table produits-versions-clients à jour et une procédure de signalement nominative a réglé l'essentiel du risque de septembre, et s'est constitué au passage un actif qui servira à tout le reste : maintenance prédictive, exploitation des données machines, valorisation à la cession.
Le reste est du travail d'ingénierie, et il peut attendre décembre 2027.
Sources
- Règlement (UE) 2024/2847 du Parlement européen et du Conseil, dit règlement sur la cyberrésilience, articles 3, 13, 14, 22 et 69, annexes I et VII.
- Commission européenne, communication C(2026) 5252, guidance sur l'application du Cyber Resilience Act, 27 juillet 2026.
- ENISA, Single Reporting Platform et SME CRA Survey Report, juin 2026 (194 organisations, 31 pays).
- Linux Foundation Research et OpenSSF, 2026 CRA Awareness and Readiness Report, juin 2026 (843 répondants, enquête de janvier 2026).
- Direction générale des Entreprises, Cyber Resilience Act : ce qui change pour les entreprises, mars 2026.
- ANSSI, page réglementation sur la cybersécurité des produits et programme de notification CRA.
- MIT NANDA, The GenAI Divide: State of AI in Business, juillet 2025.
Signaux de terrain (juillet 2026)
