Le plan d’action CRA impose 3 obligations d’ici 2027 sous peine de 15M€ d’amende

Le Cyber Resilience Act change la donne pour toute entreprise qui conçoit, édite, fabrique, importe ou distribue des produits numériques vendus dans l’Union européenne. Le texte est déjà entré en vigueur le 10 décembre 2024 et il s’appliquera pleinement à partir du 11 décembre 2027. Entre les deux, il impose une montée en maturité très concrète, avec des exigences de sécurité qui collent au produit, du design à la fin de vie.

Le point le plus simple à retenir, c’est celui-ci, tu ne pourras plus mettre sur le marché un produit avec des vulnérabilités connues, et tu devras prouver que tu gères les risques et les correctifs dans la durée. À la clé, un enjeu business direct, le marquage CE devient lié à la cybersécurité, et les sanctions peuvent grimper jusqu’à 15 millions d’euros ou 2,5% du chiffre d’affaires mondial annuel.

Le CRA impose la cybersécurité sur tout le cycle de vie

Le CRA vise les produits matériels et logiciels avec des éléments numériques mis sur le marché de l’UE. L’idée est d’arrêter le modèle où la sécurité se traite en fin de projet, puis se dilue dans le support. Ici, la cybersécurité devient une obligation continue, depuis la conception jusqu’à la maintenance, avec un niveau d’exigence comparable à ce que l’UE a déjà fait dans d’autres domaines via le marquage CE.

Concrètement, si tu vends un logiciel B2B, un produit IoT, un équipement réseau, une appli embarquée dans un appareil, tu dois te poser la question du périmètre. Un simple exemple, un capteur connecté vendu à des industriels, ou un logiciel de supervision livré avec un boîtier, peut entraîner des obligations sur la chaîne complète, y compris les composants tiers. Ça force à regarder le produit comme un assemblage, pas comme un seul binaire.

Le texte pousse aussi une logique secure by design et secure by default, ce qui veut dire que les paramètres par défaut doivent limiter l’exposition. Dans la vraie vie, ça vise des pratiques connues, comptes admin activés par défaut, ports ouverts sans raison, mots de passe initiaux faibles, mises à jour impossibles à déployer. Le CRA transforme ces mauvaises habitudes en risque juridique et commercial.

Nuance importante, le CRA est centré produit, pas organisation. Beaucoup d’entreprises confondent avec des cadres type NIS2, qui concernent davantage la gestion du risque au niveau entité. Ici, l’objet de contrôle, c’est le produit mis sur le marché. Et ça peut toucher une PME qui édite un logiciel de niche autant qu’un grand groupe, si le produit entre dans le champ et circule dans l’UE.

Le calendrier 2024-2027 oblige à lancer un projet dès 2026

Le calendrier est moins lointain qu’il n’y paraît. Le CRA est entré en vigueur le 10 décembre 2024 et il s’applique pleinement le 11 décembre 2027. Ça laisse trois ans, sur le papier. Dans la réalité, si ton cycle produit est de 12 à 24 mois, la version qui sort en 2026 ou 2027 doit déjà être conçue pour être conforme, sinon tu te retrouves avec un produit invendable ou à re-certifier.

Il y a aussi des jalons intermédiaires qui accélèrent la préparation. Les obligations de reporting sur les vulnérabilités activement exploitées et les incidents sévères s’appliquent à partir du 11 septembre 2026. D’autre part, des dispositions sur la notification des organismes d’évaluation de la conformité entrent en jeu à partir du 11 juin 2026. Traduction, tu dois avoir un dispositif prêt avant l’échéance finale, pas juste un dossier en 2027.

Un responsable sécurité d’un éditeur B2B, Marc, résume le piège classique, on pense conformité, on pense audit en fin de route, mais là il faut changer les tickets Jira, les revues d’architecture, la manière de livrer des correctifs, et ça prend des trimestres. Le CRA pousse à planifier une feuille de route, et à la coller au planning produit, sinon tu subis.

Autre point qui surprend, les acteurs hors UE sont aussi concernés. Si ton entreprise est basée hors Europe mais vend dans l’UE, tu dois respecter le cadre, et désigner un représentant autorisé dans l’Union. Ça veut dire que la conformité devient un sujet de contrat et de gouvernance avec les partenaires, importateurs et distributeurs. Si tu es distributeur, tu vas aussi exiger des preuves de conformité.

Le marquage CE et la documentation technique deviennent des preuves

Le marquage CE n’est plus un symbole administratif, il devient un verrou d’accès au marché lié à la cybersécurité. Un produit non conforme ne peut pas être vendu légalement dans l’UE, et ne peut pas porter ce marquage. C’est une bascule, parce que la conformité n’est plus seulement un sujet de réputation après un incident, c’est un sujet de mise sur le marché, donc de chiffre d’affaires et de distribution.

Pour tenir cette promesse, le CRA impose de produire et maintenir une documentation technique démontrant la conformité. Ce n’est pas un PDF figé, c’est un corpus qui doit refléter l’analyse de risques, les choix de conception, les mesures de sécurité, et la manière dont tu gères les vulnérabilités. Si tu n’as pas l’habitude de documenter, tu vas devoir industrialiser, sinon tu vas courir après les preuves au pire moment.

Dans la pratique, un élément devient central, la SBOM, la nomenclature logicielle. Elle sert à savoir quels composants, bibliothèques et dépendances sont embarqués, et à réagir vite quand une vulnérabilité touche un composant. Exemple simple, si une bibliothèque de chiffrement est compromise, tu dois identifier où elle est utilisée, quelle version, quels clients, et pousser un correctif. Sans SBOM à jour, tu fais ça à la main, et tu perds des jours.

Le CRA te demande aussi de faire une analyse des menaces et une évaluation des risques, souvent décrite comme TARA. Là encore, ce n’est pas une formalité, c’est un exercice qui doit justifier des choix, par exemple pourquoi tel service est exposé, pourquoi tel mécanisme d’authentification est retenu, comment tu limites les impacts. La critique qu’on peut faire, c’est que certaines PME vont se retrouver à produire une documentation lourde, sans toujours avoir les compétences internes.

Vulnérabilités, incidents et mises à jour: la nouvelle routine obligatoire

Le cur opérationnel du CRA, c’est la gestion des vulnérabilités et des correctifs. Il faut un processus structuré de gestion des vulnérabilités, avec des mécanismes de réception, triage, correction et déploiement. Et surtout, il faut pouvoir notifier rapidement les autorités compétentes quand une vulnérabilité est activement exploitée, ou quand un incident sévère touche un produit concerné. Ça impose une chaîne d’alerte claire.

Autre obligation, informer les utilisateurs affectés sans délai indu. Dans la vraie vie, ça veut dire que ton support client, ton équipe sécurité et ton juridique doivent être alignés. Exemple, une faille exploitée sur un produit de télémaintenance, tu dois à la fois corriger, communiquer, et donner des mesures de mitigation. Beaucoup d’entreprises savent corriger, moins savent communiquer vite sans se contredire, et le CRA rend cette faiblesse plus coûteuse.

Le texte insiste aussi sur les mises à jour de sécurité pendant toute la durée de vie prévue du produit. Ça peut bouleverser des modèles économiques, surtout quand le produit était vendu une fois avec un support minimal. Si tu vends un équipement connecté avec logiciel embarqué, tu dois anticiper les coûts de maintenance, les pipelines de livraison, la signature des mises à jour, et la capacité des clients à les déployer.

Marc, côté éditeur, pointe une nuance, la sécurité par défaut, tout le monde est d’accord, mais si tu verrouilles trop, tu augmentes les coûts d’intégration chez le client, et tu prends le risque qu’il désactive des protections. Le CRA pousse à mieux concevoir, mais il ne résout pas la tension produit entre ergonomie, intégration et sécurité. Il faut donc tester les paramètres par défaut avec des cas d’usage réels, pas seulement en labo.

Amendes jusqu’à 15 M et 2,5%: comment préparer un plan concret

Le CRA prévoit des sanctions administratives significatives. Le maximum peut atteindre 15 millions d’euros ou 2,5% du chiffre d’affaires mondial annuel, selon le montant le plus élevé. Pour une entreprise internationale, 2,5% peut représenter bien plus que 15 millions. Même pour une ETI, la perspective suffit à justifier un programme de conformité, parce que le risque n’est pas théorique si un produit non conforme reste sur le marché.

La préparation commence par une étape terre à terre, cartographier les produits vendus dans l’UE et décider s’ils entrent dans le champ, puis les classer selon leur catégorie de risque. À partir de là, tu construis une feuille de route, avec des livrables concrets, TARA, SBOM, documentation, processus de vulnérabilités, et capacités de patch. Ce n’est pas un projet cyber isolé, c’est un chantier produit.

Un plan crédible inclut aussi la chaîne d’approvisionnement. Si tu intègres des composants tiers, tu dois exiger des informations, des correctifs, et une transparence minimale. Sans ça, tu portes le risque sans maîtriser la correction. Dans beaucoup de secteurs, la comparaison avec la qualité industrielle est parlante, tu ne certifies pas un produit sans contrôler tes fournisseurs. Là, tu dois faire pareil sur le logiciel et le firmware.

Dernier point, pense organisation et budget. Le CRA pousse à former les équipes, dev, produit, support, conformité, parce que les obligations s’étalent sur tout le cycle de vie. Une critique réaliste, c’est que certaines entreprises vont chercher une conformité papier trop tard, avec un empilement d’outils. Le bon réflexe, c’est de démarrer petit mais réel, une SBOM fiable sur un produit prioritaire, un processus de vulnérabilités testé, et une capacité de mise à jour éprouvée sur le terrain.