Chaîne d'approvisionnement logicielle : le fournisseur qui vous fait tomber.
Votre application embarque des centaines de composants que personne n'a évalués. Le SBOM ne protège de rien, mais transforme trois semaines d'enquête en dix minutes.
Regardez sous votre grille-pain, derrière votre chargeur de téléphone, au dos d'un jouet : vous y trouverez un petit sigle, CE. Il ne veut pas dire « fabriqué en Europe » ; il veut dire « ce produit a prouvé qu'il ne prendra pas feu, n'électrocutera personne, respecte les règles pour être vendu ici ». Depuis des décennies, aucun appareil physique ne peut entrer sur le marché européen sans cette promesse de sécurité. Or jusqu'à récemment, un objet pouvait respecter toutes les normes électriques du monde et être une passoire numérique : une caméra connectée avec un mot de passe par défaut, un logiciel jamais mis à jour, une faille béante et aucun responsable pour la corriger. Le Cyber Resilience Act (CRA) vient combler ce vide. En une phrase : c'est le sigle CE, étendu à la sécurité numérique.
Ce règlement européen impose la sécurité par conception à tout « produit comportant des éléments numériques » vendu dans l'Union - c'est-à-dire, en pratique, presque tout : objets connectés, logiciels, composants, applications. Et il approche vite : deux dates encadrent désormais les agendas, dont une à quelques semaines.
En résumé
- Le Cyber Resilience Act, c'est le marquage CE étendu à la sécurité numérique : jusqu'ici un objet pouvait respecter toutes les normes électriques et rester une passoire informatique.
- Deux dates structurent l'effort. Le 11 septembre 2026 : signalement sous 24 heures des vulnérabilités activement exploitées et des incidents graves. Le 11 décembre 2027 : pleine application.
- L'obligation de parler quand ça brûle arrive donc en premier, et elle concerne déjà les produits actuellement sur le marché.
- Les exigences relèvent du bon sens qu'on aurait dû imposer plus tôt : aucune faille connue à la sortie d'usine, configuration sûre par défaut, mises à jour sur toute la durée de support, traçabilité.
- Le texte ne vise pas les éditeurs de sécurité mais quiconque fabrique, importe ou distribue un produit contenant du logiciel dans l'Union - jusqu'à 15 M€ ou 2,5 % du chiffre d'affaires mondial.
- À ne pas confondre avec NIS2 : NIS2 vous demande d'être une organisation sûre, le CRA de mettre sur le marché des produits sûrs.
Les deux dates à retenir
- 11 septembre 2026 - le signalement. C'est la première échéance, et la plus proche. Dès cette date, un fabricant doit signaler sous 24 heures, à l'ENISA et aux CSIRT nationaux, toute vulnérabilité de son produit activement exploitée ainsi que tout incident grave. Vingt-quatre heures : le délai d'un rappel d'urgence, pas d'une réunion trimestrielle.
- 11 décembre 2027 - la pleine application. À cette date, l'ensemble des obligations entre en vigueur : exigences de sécurité dès la conception, évaluation de conformité, marquage CE numérique, et fourniture de mises à jour de sécurité pendant toute la durée de support du produit.
Autrement dit, l'obligation de parler quand ça brûle arrive d'abord ; l'obligation de construire sûr suit un an plus tard. Mais préparer la seconde prend bien plus de temps que d'attendre l'échéance, et la première concerne déjà les produits actuellement sur le marché.
Sources : Commission européenne, ENISA, analyses juridiques du calendrier CRA - voir les liens en bas d'article.
Ce que le CRA exige, concrètement
Derrière le vocabulaire réglementaire, les obligations se résument à du bon sens qu'on aurait dû exiger depuis longtemps :
- Pas de faille connue à la sortie d'usine. Interdiction de vendre un produit avec une vulnérabilité exploitable connue. On ne livre plus une voiture dont on sait déjà que les freins lâchent.
- Une configuration sûre par défaut. Fini le mot de passe « admin/admin » d'usine : la sécurité doit être l'état initial, pas une option que l'utilisateur devra penser à activer.
- Des mises à jour pendant toute la durée de support. Le fabricant doit corriger les failles et diffuser les correctifs, gratuitement, aussi longtemps qu'il soutient le produit. Un objet vendu n'est plus abandonné le lendemain.
- Le signalement des failles exploitées et des incidents graves, dans les délais serrés évoqués plus haut.
- Une documentation et une traçabilité permettant de prouver tout cela - la partie invisible mais exigeante du travail.
« Je ne suis pas une entreprise cyber, suis-je concerné ? »
Probablement, oui. Le CRA ne vise pas les éditeurs de sécurité : il vise quiconque fabrique, importe ou distribue un produit contenant du logiciel dans l'Union. Un fabricant d'équipements connectés, un éditeur d'applications, une PME industrielle qui intègre un composant logiciel dans sa machine - tous entrent dans le champ. Et si vous ne faites qu'acheter ces produits, le CRA joue en votre faveur : il relève le niveau de sécurité de tout ce que vous consommez.
Des sanctions à la hauteur des enjeux
Comme pour le RGPD, le CRA n'est pas une recommandation. Le manquement aux exigences essentielles de sécurité peut être sanctionné jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu. Le message est clair : la sécurité d'un produit numérique n'est plus un argument marketing optionnel, c'est une condition d'accès au marché européen.
Un cousin de NIS2, mais pas le même sujet
On confond souvent les deux textes. La distinction est pourtant simple. NIS2 encadre la cybersécurité des organisations qui opèrent des services essentiels - comment elles se protègent, se gouvernent, réagissent. Le CRA, lui, encadre la sécurité des produits eux-mêmes, tout au long de leur vie. NIS2 vous demande d'être une organisation sûre ; le CRA vous demande de mettre sur le marché des produits sûrs. Beaucoup d'entreprises relèveront des deux, et gagneront à traiter la sécurité comme une discipline commune plutôt qu'en silos réglementaires. La logique de fond - tenir les fondamentaux dans la durée - est la même.
Par où commencer, sans attendre 2027
La pire stratégie serait d'attendre la dernière échéance pour découvrir l'ampleur du chantier. Quelques premiers pas, utiles quel que soit votre calendrier :
- Inventorier vos produits concernés et les composants logiciels qu'ils embarquent - on ne sécurise que ce qu'on a recensé.
- Mettre en place le processus de signalement des vulnérabilités exploitées, puisque c'est l'échéance la plus proche (11 septembre 2026).
- Vérifier vos configurations par défaut et votre capacité à diffuser des mises à jour de sécurité sur la durée.
- Documenter ce que vous faites déjà : une bonne partie de la conformité consiste à prouver des pratiques saines, encore faut-il les tracer.
Situer vos produits face au CRA
Kenawek vous aide à identifier vos produits concernés, à bâtir le processus de signalement des vulnérabilités et à construire une trajectoire de conformité réaliste, alignée avec vos obligations NIS2. Parlons-en.
En conclusion
Le Cyber Resilience Act fait pour le numérique ce que le marquage CE a fait pour la sécurité physique : il transforme la sécurité d'un argument facultatif en condition d'entrée sur le marché. Deux dates structurent l'effort - le signalement des failles exploitées dès le 11 septembre 2026, la pleine application le 11 décembre 2027. Entre les deux, il y a le temps de se préparer sereinement… ou celui de se laisser surprendre. Les organisations qui commencent maintenant transformeront une contrainte en avantage de confiance ; les autres découvriront le chantier trop tard.