Cyber Resilience Act : pourquoi la première échéance tombe déjà en septembre 2026

Une idée fausse se révèle tenace : le Cyber Resilience Act ne concernerait les fabricants qu'à partir de fin 2027. C'est vrai pour une partie des obligations — mais pas pour la première, et c'est la plus inconfortable. Elle prend effet dès le 11 septembre 2026. Au moment où j'écris ces lignes, c'est dans moins d'un trimestre.

Je ne tiens pas le CRA pour de la bureaucratie pour la bureaucratie. Il contraint un secteur qui a traité la sécurité pendant des décennies comme une option à quelque chose qui va de soi depuis longtemps dans les domaines critiques : prouver ce que l'on fait. Pourtant, beaucoup sous-estiment à quel point l'horloge démarre tôt. D'où cet article.

Ce que le CRA exige — et à partir de quand

Le Cyber Resilience Act (règlement (UE) 2024/2847) est en vigueur depuis décembre 2024. Il prescrit le niveau de sécurité que les « produits comportant des éléments numériques » doivent atteindre face aux attaques — soit tout ce qui contient du logiciel ou se connecte à un réseau. Du thermostat intelligent à l'automate industriel. Il y a deux dates clés, et il ne faut pas les confondre :

11 septembre 2026 — l'obligation de signalement. À partir de cette date, je dois signaler toute vulnérabilité activement exploitée et tout incident de sécurité grave dans les 24 heures aux organismes compétents — l'agence européenne ENISA et les équipes nationales de réponse (CSIRT). Cela vaut aussi pour les produits déjà sur le marché depuis longtemps et encore suivis.

11 décembre 2027 — le reste. À partir de là, le produit doit être conçu sûr dès l'origine, recevoir des mises à jour de sécurité sur toute sa durée de vie, présenter une nomenclature logicielle complète, passer une évaluation de conformité et porter le marquage CE.

En mettant les deux dates côte à côte, le vrai problème apparaît : on ne peut signaler que ce que l'on sait présent dans son produit. Et cela mène droit à l'obstacle sous-estimé.

Pourquoi l'obligation de signalement est le véritable obstacle

Signaler une vulnérabilité en 24 heures ressemble à un détail d'organisation. Ce n'en est pas un. Pour pouvoir seulement juger si une faille tout juste divulguée touche mon propre produit, il me faut une liste complète de tous les composants logiciels intégrés — le fameux SBOM (software bill of materials), la nomenclature du code. Sans elle, je reste dans le noir à chaque nouveau signalement de vulnérabilité, à deviner si l'un de mes composants est concerné.

Autrement dit : le SBOM qui ne devient officiellement obligatoire qu'en 2027, j'en ai en réalité besoin dès septembre 2026. Celui qui ne commence qu'alors à inventorier ses dépendances a déjà perdu le premier incident réel. À cela s'ajoute la simple logistique : qui repère une faille exploitée, qui l'évalue, qui la signale — et cette chaîne fonctionne-t-elle aussi un samedi soir ? Vingt-quatre heures, ce sont vingt-quatre heures.

Fiabilité et résistance aux attaques convergent

C'est ici que cela devient intéressant pour mon cœur de métier. Depuis plus de trois décennies, je développe du logiciel embarqué critique, en grande partie selon l'ISO 26262 — la norme de sécurité fonctionnelle des véhicules. La sécurité fonctionnelle demande : que se passe-t-il si un composant tombe en panne ? Le CRA pose une seconde question à côté : que se passe-t-il si quelqu'un attaque l'appareil délibérément ?

Ces deux questions ont longtemps été des mondes séparés. Elles ne le sont plus. Un exemple parlant est l'intrusion à distance dans une Jeep Cherokee en 2015 : deux chercheurs en sécurité ont pris le contrôle des freins et de la transmission via une faille du système d'infodivertissement — à distance, par le réseau cellulaire. 1,4 million de véhicules ont dû être rappelés. Toute démonstration de sécurité du frein devenait sans valeur, car le frein n'a pas défailli par hasard mais sur ordre d'un attaquant. Une faille du logiciel était devenue un problème de sécurité au sens propre.

C'est exactement là que naissent aujourd'hui les lacunes coûteuses : chez les fabricants qui maîtrisent leur fiabilité mais n'ont jamais examiné le volet attaque de façon systématique. Penser l'ISO 26262 sans analyse de sécurité d'accompagnement, c'est ne plus boucler sa chaîne d'argumentation.

Ce qui change concrètement dans le firmware

On écarte volontiers le CRA comme un sujet de juristes. J'y vois une erreur. Derrière les exigences se cachent des tâches très concrètes pour le firmware — le logiciel de commande logé en dur dans l'appareil. Quatre points me paraissent centraux :

Le logiciel doit être stocké chiffré dans l'appareil. Quiconque peut lire le code en clair depuis la flash a laissé une porte ouverte. Les microcontrôleurs modernes offrent une protection — verrouillage sécurisé de la lecture, démarrage signé, zones mémoire liées à une clé. L'essentiel est aussi de les gérer proprement en production, au lieu de perdre les clés en chemin.

Les mises à jour doivent être infalsifiables. Un appareil doit pouvoir recevoir des mises à jour de sécurité sur toute sa durée de vie — de telle sorte que personne ne puisse y glisser un logiciel étranger. Un produit sans chemin de mise à jour signé et vérifié n'est tout simplement plus commercialisable à partir de 2027.

Chaque composant doit être connu et surveillé. Chaque bibliothèque achetée, chaque brique du système d'exploitation temps réel, chaque pile cryptographique a sa place dans la nomenclature et doit être surveillée au regard des vulnérabilités connues. Cela inclut de repérer les composants obsolètes que le fournisseur d'origine n'entretient plus — avant qu'une autorité ne le fasse.

Un code propre est payant. Dans les projets critiques, je développe selon des règles de codage strictes, comme MISRA-C. Beaucoup de ces règles éliminent précisément les comportements indéfinis à partir desquels se construisent ensuite les exploits. Qui travaille ainsi dès le départ a déjà fait une partie des devoirs du CRA — mais devrait aussi pouvoir le prouver.

Le petit fabricant est lui aussi un « fabricant »

Une idée reçue répandue veut que cela ne concerne que les grands groupes. Faux. Le CRA s'applique à quiconque met sur le marché de l'UE un produit comportant des éléments numériques — de la PME au développeur indépendant spécialisé. Celui qui importe ou revend des appareils porte lui aussi ses propres obligations. Et les amendes ne sont pas un épouvantail : elles atteignent jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial.

Qui pensait jusqu'ici que la sécurité était une option pour « les versions ultérieures du produit » n'a plus ce choix.

Ce que je conseille aux fabricants maintenant

Les prochains mois décident si septembre 2026 trouve un déroulement ordonné ou une improvisation fébrile. Mon conseil est peu spectaculaire, mais il fonctionne : commencer. Un état des lieux des produits concernés et encore suivis. Une première nomenclature logicielle par produit. Une voie de signalement définie qui porte réellement, sur le plan organisationnel, le délai de 24 heures. Et, en parallèle, durcir le firmware — comme une architecture réfléchie, non comme un correctif collé après coup.

Un positionnement honnête pour finir : celui qui cherche un tampon attestant que tout va déjà bien n'est pas au bon endroit avec moi. Celui qui veut savoir où en sont réellement ses produits en septembre 2026, et ce qu'il faut faire dans le firmware d'ici là, est au bon endroit.

Conclusion

Le CRA n'est pas un problème lointain pour après-demain. La première échéance contraignante tombe en septembre 2026, et elle suppose que je sache déjà aujourd'hui ce qui se trouve dans mes produits. Qui commence tôt répartit le travail et évite les corrections coûteuses de dernière minute juste avant l'échéance.

Le plus grand levier réside rarement dans la seule technique. Il réside dans le jeu propre entre nomenclature, processus de signalement et durcissement de l'appareil — et dans le fait de penser enfin fiabilité et résistance aux attaques comme un concept commun, et non comme deux tiroirs séparés. C'est précisément le pont sur lequel je préfère travailler.