Cyber Resilience Act (CRA) 2026–2027 : ce que nous savons déjà, ce qui manque encore et comment préparer concrètement un produit — avant la parution des normes harmonisées

Ce que nous savons avec certitude aujourd’hui (et pourquoi ce n’est pas un « sujet pour 2027 »)

Le Cyber Resilience Act peut donner l’impression d’être un énième document « venu de Bruxelles » qu’on pourra remettre à plus tard. C’est une réaction naturelle, surtout quand l’entreprise vit au rythme des projets : prototype, déploiement, production en série, service. Les réglementations arrivent souvent comme une « exigence finale » — quelque chose qu’on boucle à la toute fin. Le CRA change cette logique, car il ne concerne pas uniquement ce qui est visible dans le produit le jour de la vente. Il porte sur la capacité du fabricant à maintenir la sécurité du produit dans la durée et à démontrer qu’il l’a fait de manière intentionnelle, et non par hasard.

Le fait le plus important est simple, mais ses conséquences sont stratégiques : le CRA est une réglementation produit, ancrée dans les mécanismes du marché de l’UE (y compris le marquage CE). La Commission européenne indique explicitement que les produits doivent porter le marquage CE comme signal de conformité au CRA, et que l’application relève des autorités de surveillance du marché. Il ne s’agit donc pas d’un « standard IT » que l’on pourrait traiter comme un programme interne d’amélioration. C’est un cadre qui conditionne la possibilité de vendre.

Des dates qui structurent la réflexion

Le texte même du règlement (UE) 2024/2847 montre une application par étapes. Le CRA s’applique à partir du 11 décembre 2027, mais avec des exceptions clairement prévues. L’article 14 (reporting) s’applique à partir du 11 septembre 2026, et le chapitre sur la notification des organismes d’évaluation de la conformité (Chapter IV) à partir du 11 juin 2026. Ce sont trois dates à considérer comme des « jalons », car elles correspondent à trois types de préparation différents : opérationnelle, institutionnelle et produit.

La Commission le formule encore plus simplement : le CRA est entré en vigueur le 10 décembre 2024, les obligations essentielles à partir du 11 décembre 2027, et le reporting à partir du 11 septembre 2026. Quand quelqu’un dans l’entreprise dit « on a le temps jusqu’en 2027 », il pense le plus souvent aux exigences de conception et à l’évaluation de la conformité. Mais le reporting arrive plus tôt et concerne des événements qui, eux, n’attendent pas le planning.

Reporting : une obligation qui impose un processus (et pas un document)

L’exigence de reporting est un bon test révélateur, car elle montre comment le CRA comprend la « cybersécurité du produit ». Ce n’est ni une déclaration d’intention ni une « politique ». C’est un processus qui doit fonctionner en situation de stress : lorsqu’une vulnérabilité activement exploitée apparaît, ou lorsqu’un incident grave survient.

La Commission le décrit sans ambiguïté : le fabricant doit signaler les vulnérabilités activement exploitées ainsi que les severe incidents affectant la sécurité du produit. Un « early warning » est requis dans les 24 heures suivant la prise de connaissance, une notification complète dans les 72 heures, et un rapport final : dans les 14 jours après la disponibilité d’une mesure corrective pour les vulnérabilités activement exploitées, et dans le mois pour les severe incidents.

En pratique, cela signifie que l’organisation a besoin de plus qu’une checklist. Elle a besoin d’un mécanisme qui réponde à trois questions : comment saurons-nous qu’un problème existe ; qui qualifie s’il s’agit déjà d’une situation « activement exploitée » ou « severe » ; et comment organiser la communication d’information ainsi que le correctif dans des délais qui ne laissent aucune place à l’improvisation.

Si, en formation, on observe de la confusion, c’est souvent parce que le CRA tombe dans l’angle mort entre l’IT et le produit. Pour l’IT, un « incident » est parfois un événement dans l’infrastructure. Pour un fabricant, un « incident » est un événement qui touche le produit chez le client, une version, une configuration, un mode de déploiement. Le CRA impose de relier ces deux mondes en une responsabilité unique.

Ce que couvre le CRA : le produit comme relation au réseau, pas comme « appareil posé sur une table »

En pratique, avec les évaluations des risques des machines, nous avons appris que le risque n’est pas une caractéristique de la machine seule — il naît dans la relation homme–machine. Le CRA opère un déplacement de perspective similaire : la sécurité n’existe pas « dans l’appareil », mais dans la relation du produit avec l’environnement numérique, le mode d’utilisation et la capacité du fabricant à réagir.

La Commission, en résumant le CRA, attire l’attention sur la définition des « produits comportant des éléments numériques » et sur le fait que les obligations de reporting concernent tous ces produits mis à disposition sur le marché de l’UE — y compris ceux introduits avant le 11 décembre 2027. C’est une précision essentielle, car elle fait tomber un mythe fréquent : « pour les anciens produits, ça ne compte pas ». Le reporting — si.

Ce qui manque encore (les normes harmonisées) et pourquoi cela ne doit pas paralyser

W’échanges sur le CRA, on entend souvent cette phrase : « il n’y a pas encore de normes harmonisées, donc on ne peut rien faire ». Cela paraît logique, mais il y a là un piège. Les normes harmonisées sont un outil qui facilite la démonstration de la conformité (présomption de conformité), mais ce n’est pas l’unique voie pour construire une sécurité produit réelle. Et ce n’est pas une condition pour commencer à concevoir correctement.

La Commission traite explicitement le sujet des standards via la page « CRA Standardisation » et indique avoir adopté la standardisation request M/606, couvrant un ensemble de 41 standards soutenant le CRA — à la fois horizontaux et verticaux (par produit). C’est important, car cela montre que l’UE comprend la problématique du marché : sans standards, chaque entreprise construira sa conformité à sa manière, et la surveillance du marché aura plus de difficultés.

Standards horizontaux et verticaux : ce que cela signifie pour le fabricant

En simplifiant :

• les standards horizontaux doivent décrire « comment » construire et maintenir la sécurité d’un produit, indépendamment de la catégorie (processus, méthodes, approche fondée sur le risque),
• les standards verticaux doivent préciser les exigences pour des classes de produits spécifiques (là où les risques et les architectures sont typiques).

Cette distinction a des conséquences concrètes. Si vous développez un produit industriel, où une partie de l’environnement relève de l’« OT » et où le cycle de vie est long, vous aurez besoin de standards qui ne sont pas écrits pour une application SaaS. Et c’est précisément pour cela que les standards verticaux comptent : ils aident à passer de principes généraux à ce qu’il faut contrôler dans des architectures réelles.

Calendrier des travaux : les standards arriveront par étapes, pas « en bloc avant 2027 »

Dans ses supports sur la mise en œuvre du CRA, la Commission montre que le CRA est déployé progressivement et que les standards doivent accompagner ce processus dans le temps. Sur les faits aujourd’hui certains : le règlement a été formellement adopté et le mécanisme de normalisation (M/606) a été lancé.

Pour la pratique, l’essentiel est de comprendre une phrase : même lorsqu’un standard est élaboré par les organismes de normalisation, la « présomption de conformité » au sens juridique n’apparaît qu’au moment où la référence à la norme est publiée comme norme harmonisée au Journal officiel de l’UE. C’est un mécanisme commun à l’approche européenne de l’harmonisation : les standards font le lien entre le droit et la pratique d’ingénierie, mais ce lien doit être formellement « reconnu » par l’UE.

Du point de vue du fabricant, cela signifie que les années 2026–2027 seront une période où certaines entreprises agiront sur la base de leurs propres méthodes de démonstration de la conformité (fondées sur le risque + preuves), tandis que d’autres commenceront déjà à s’aligner sur les standards au fur et à mesure de leur publication. Et c’est normal.

« Pas de normes » ne veut pas dire « pas d’obligation » — cela signifie davantage de poids pour les preuves

Une conséquence importante apparaît ici : s’il n’existe pas de normes offrant la voie la plus simple pour démontrer la conformité, l’importance de ce qui, en pratique d’audit, est toujours déterminant augmente : une traçabilité décisionnelle cohérente.

Quels risques avons-nous évalués ? Quels scénarios avons-nous jugés réalistes ? Comment avons-nous choisi les mesures de protection ? Comment gérons-nous les vulnérabilités ? Pendant combien de temps assurons-nous le support du produit ? Comment informons-nous le client ? Le CRA n’exige pas que le fabricant « devine les futures normes EN ». Il exige que le fabricant soit capable de montrer que ses décisions n’étaient pas arbitraires, mais fondées sur le risque et sur l’état de l’art.

Comment préparer concrètement un produit au CRA (feuille de route pour le fabricant et l’intégrateur)

La plus grande valeur du CRA est qu’il impose une montée en maturité : la cybersécurité cesse d’être un « plus » ajouté au produit et devient une caractéristique intrinsèque. Sauf que la maturité ne naît pas d’une déclaration. Elle naît d’un processus suffisamment précis pour fonctionner en pratique, et suffisamment simple pour que l’ingénierie ne commence pas à le contourner.

En analyse des risques machines, les meilleures décisions de conception apparaissent lorsque l’on cesse de demander « quels dangers la machine présente » et que l’on commence à demander « dans quelles tâches et quels états l’être humain est exposé ». Pour le CRA, c’est analogue : on cesse de demander « quelles vulnérabilités le produit a » et l’on commence à demander « dans quelles conditions le produit devient exposé et ce que le fabricant est alors capable de faire ». Ce changement de perspective structure le travail.

Étape 1 : Définissez le produit comme un système (et non comme un appareil)

Commencez par définir ce qui, dans votre cas, constitue un « produit comportant des éléments numériques ». Pas seulement le matériel et le micrologiciel, mais aussi ce qui est souvent omis parce que cela ne tient pas dans la boîte : composants, bibliothèques, mécanismes de mise à jour, services sans lesquels le produit ne remplit pas sa fonction. Dans le CRA, c’est important, car la responsabilité du fabricant porte sur ce qui est mis sur le marché en tant que produit — et pas uniquement sur ce qu’a fabriqué le service mécanique.

C’est aussi le premier moment où les intégrateurs doivent être lucides : si vous intégrez des composants et les configurez d’une manière qui crée un « produit final » aux yeux du client, vous n’êtes pas seulement un « déployeur ». Vous êtes co-auteur du risque et co-auteur de la responsabilité.

Étape 2 : Réalisez l’analyse de risques CRA de façon à en faire un outil de décision

Il ne s’agit pas d’une « matrice » sur des slides. Il s’agit d’une évaluation des risques qui débouche sur des décisions de conception et qui est reproductible.

En pratique, une bonne approche de la CRA commence par une question simple : quels sont les scénarios d’usage abusif réels dans l’environnement du client, et pas seulement en laboratoire ? Qui dispose d’un accès de maintenance ? À quoi ressemble le réseau ? À quelle fréquence met-on à jour ? Quelles sont les conséquences d’un arrêt ? Dans l’industrie, ces questions sont plus inconfortables qu’en IT, car les réponses sont souvent : « nous ne pouvons pas mettre à jour chaque semaine » ou « nous n’avons pas de télémétrie ». Et c’est précisément pour cela qu’il faut les poser. La CRA relève du droit, mais ses effets sont d’abord des choix de conception.

Krok 3: Construisez le « vulnerability handling » comme un processus industriel, pas comme une réaction de crise

Les exigences de notification décrites par la Commission (24h/72h/14 jours/mois) sont impitoyables pour une organisation qui n’a pas de processus. Si vous voulez être prêt pour le 11 septembre 2026, vous devez traiter le « vulnerability handling » comme un élément du cycle de vie du produit, et non comme une « tâche de l’équipe sécurité ».

Cela signifie :

• un canal unique de réception des signalements (politique CVD + contact),
• un triage avec un responsable et des critères,
• un mécanisme de création et de diffusion des security updates,
• un modèle de communication vers les clients qui ne repose pas sur l’improvisation,
• une capacité de notification (qui déclare, avec quelles données, à quelle vitesse).

Tout cela ressemble à du travail « organisationnel ». En réalité, c’est du travail produit, car cela touche aux versions, à la compatibilité, à l’architecture de mise à jour et à la stratégie de support.

Krok 4: Choisissez la période de support comme une décision business, pas comme une exigence minimale

Si vos produits restent en service dans l’industrie pendant 10–15 ans, la période de support est stratégique. La CRA impose que le support ne soit pas une promesse sans fondement. Cela signifie que la période de support doit découler d’une analyse : combien de temps le produit sera utilisé, à quoi ressemble la chaîne d’approvisionnement des composants, combien de temps vous serez en mesure de fournir des correctifs. En pratique, la période de support « tire » tout l’écosystème : contrats avec les fournisseurs, disponibilité de l’environnement de build, maintien des toolchains, et même des décisions sur le fait que le produit dispose de fonctions à distance ou qu’il soit isolé.

Si vous traitez la période de support comme une formalité, au plus tard en 2027 vous vous retrouverez en conflit : le client attend du support, et vous n’avez plus ni les ressources ni les dépendances pour le fournir. La CRA ne crée pas ce problème — elle ne fait que le révéler.

Krok 5: Mettez de l’ordre dans la chaîne d’approvisionnement : parler aux fournisseurs fait partie de la conformité

Dans la CRA, il n’y a pas de « magie » qui rendrait les composants externes sûrs. Si votre équipement repose sur des bibliothèques, des modules de communication, un système d’exploitation, un SDK ou des composants matériels, votre risque dépend directement de la qualité des pratiques du fournisseur.

C’est pourquoi il vaut la peine, dès maintenant, d’engager une discussion sur des sujets qui ne relèvent pas du marketing, mais de l’ingénierie :

• le fournisseur sait-il communiquer sur les vulnérabilités de manière prévisible,
• quel est son délai de réaction,
• a-t-il un processus de publication de correctifs,
• peut-il maintenir le composant sur une durée cohérente avec votre période de support.

C’est là que la CRA touche réellement le business : un fournisseur incapable de gérer les vulnérabilités n’est pas « moins cher ». C’est un risque réglementaire.

Krok 6: Construisez la documentation comme une traçabilité cohérente : droit → risque → décision → preuve

Dans les audits de conformité, c’est toujours la cohérence qui l’emporte. Si l’évaluation des risques conclut qu’une interface est critique et que la documentation n’explique pas comment vous la sécurisez ; si vous affirmez que les mises à jour sont sûres mais que vous ne savez pas montrer comment vous garantissez l’intégrité des paquets ; si vous dites avoir un processus de gestion des vulnérabilités mais que vous ne savez pas montrer comment vous faites le triage des signalements — ce n’est pas un « manque de papier ». C’est l’absence de preuve que le processus fonctionne.

Dans la CRA, en l’absence de normes harmonisées, cette traçabilité est particulièrement importante. Car elle servira de base aux échanges avec l’autorité de surveillance du marché, avec un client enterprise, et, dans certaines catégories de produits, également avec l’organisme d’évaluation de la conformité. Et, tout aussi important : elle sera le socle de la stabilité interne. L’équipe sait pourquoi on fait quelque chose, et pas seulement « parce qu’il le faut ».

Conclusion : la CRA comme nouvelle exigence de conception, pas comme un « projet compliance »

S’il ne fallait retenir qu’une idée pour relier ces trois parties : la CRA n’est pas un problème à régler à la fin. C’est un cadre qui change la manière de penser le produit. De la même façon que ISO 12100 enseigne que le risque naît de la relation homme–machine, la CRA enseigne que la cybersécurité naît de la relation produit–environnement–cycle de vie du fabricant.

Les normes harmonisées arriveront et simplifieront certains parcours. Mais leur absence n’est pas une raison de rester immobile. C’est une raison de se concentrer sur ce que la CRA évalue toujours : les décisions, les preuves et la capacité à agir dans la réalité — pas dans une présentation.