Le Cyber Resilience Act européen frappe l'IoT dès septembre. La plupart des équipes produit ne sont pas prêtes.

Le 11 septembre 2026, le Cyber Resilience Act (règlement européen sur la cyberrésilience) montre les dents pour la première fois. À partir de cette date, quiconque vend dans l'UE un produit comportant des éléments numériques — un thermostat intelligent, un traceur de flotte, une machine à café connectée, le firmware de n'importe lequel d'entre eux — devra signaler les vulnérabilités activement exploitées aux autorités européennes dans les 24 heures suivant leur découverte. Pas 24 heures ouvrées. Vingt-quatre heures.

C'est dans trois mois. Et cela s'applique aux produits que vous avez déjà livrés, pas seulement à ceux que vous lancerez après l'échéance.

La plupart des articles sur le CRA se concentrent sur décembre 2027, date d'arrivée des exigences complètes de sécurité dès la conception et du marquage CE. Ce cadrage est confortable, et faux. On ne peut pas signaler une vulnérabilité sous 24 heures sans disposer déjà de la machinerie pour la détecter, la trier et la déclarer. Et cette machinerie demande plus d'un trimestre à construire.

Ce que couvre le CRA (probablement votre produit)

La formule du règlement, « produits comportant des éléments numériques », est aussi large qu'elle en a l'air : du matériel embarquant du logiciel, plus le logiciel autonome lui-même. IoT grand public, capteurs industriels, routeurs, applications mobiles vendues dans l'UE, le code embarqué d'un distributeur automatique. Si ça exécute du code et que c'est sur le marché européen, partez du principe que c'est couvert.

Le lieu d'implantation de votre entreprise n'a aucune importance. Comme le RGPD, le CRA suit le produit sur le marché. Une startup américaine ou britannique qui vend des objets connectés à des clients allemands porte les mêmes obligations qu'un fabricant munichois.

Quelques catégories y échappent, parce qu'elles sont réglementées ailleurs : dispositifs médicaux, automobiles, systèmes aéronautiques, certains équipements maritimes. L'open source a son propre régime — on y revient plus bas. Tous les autres sont sur un même calendrier, avec deux dates qui comptent : le 11 septembre 2026 pour le signalement, le 11 décembre 2027 pour tout le reste.

Le 11 septembre est la vraie échéance

Voici la séquence que le règlement attend quand quelqu'un exploite activement une faille dans votre produit. Une alerte précoce à votre CSIRT national dans les 24 heures suivant la prise de connaissance. Une notification plus complète sous 72 heures. Un rapport final dans les 14 jours suivant la disponibilité d'un correctif. Les incidents graves suivent le même schéma, avec un mois pour le rapport final. Tout transite par une nouvelle plateforme de signalement unique, qui achemine l'information simultanément au CSIRT de votre État membre et à l'ENISA, l'agence européenne de cybersécurité.

Relisez ce paragraphe avec des yeux de chef de produit et le problème saute aux yeux. « Dans les 24 heures suivant la prise de connaissance » suppose que vous en preniez connaissance. La plupart des petits et moyens fabricants d'appareils n'ont aucun moyen structuré d'apprendre qu'une CVE vient d'être publiée pour une bibliothèque intégrée à leur firmware, aucune boîte mail où un chercheur en sécurité peut joindre un humain, et aucune réponse interne à la question « qui décide que c'est activement exploité, et qui déclare ? »

C'est pourquoi l'échéance pratique du SBOM, c'est 2026, pas 2027. L'inventaire logiciel — une liste lisible par machine de chaque composant de votre produit — est formellement une exigence de 2027. Mais on ne peut pas surveiller des dépendances qu'on n'a pas répertoriées, et on ne tient pas un délai de 24 heures avec un processus de triage qui commence par « attends, on utilise vraiment cette bibliothèque ? ». L'obligation de signalement avance discrètement le chantier SBOM d'un an.

Un détail inconfortable de plus : l'obligation de signalement couvre les produits déjà sur le marché. L'appareil que vous avez livré en 2022 avec le vague projet de « revoir la sécurité plus tard » entre dans le périmètre dès que quelqu'un commence à l'exploiter.

Ce dont votre produit aura besoin d'ici fin 2027

La vague de décembre 2027 représente le plus gros effort d'ingénierie. Pour les produits mis sur le marché à partir de cette date, les exigences essentielles comprennent :

• Livrer sans vulnérabilité exploitable connue, avec une configuration sécurisée par défaut — ce qui, entre autres, met fin à l'ère du mot de passe par défaut universel.
• Un vrai mécanisme de mise à jour : correctifs de sécurité livrés en OTA le cas échéant, signés cryptographiquement, vérifiés sur l'appareil, protégés contre le retour à des versions vulnérables, et assez robustes pour ne pas bricker le parc en cours de mise à jour.
• Un SBOM lisible par machine, en pratique SPDX ou CycloneDX, généré par le build plutôt qu'assemblé à la main une fois par an.
• Une politique de divulgation coordonnée des vulnérabilités, avec un canal public permettant aux chercheurs de signaler des problèmes — et quelqu'un qui lit réellement ce qui arrive.
• Des mises à jour de sécurité gratuites pendant la période de support du produit — au minimum cinq ans, ou la durée de vie attendue du produit si elle est plus courte.

La conformité se matérialise par le marquage CE, celui que vous connaissez déjà sur l'électronique, désormais étendu à la cybersécurité. La plupart des produits peuvent s'auto-évaluer. Les classes « importantes » — routeurs, pare-feu, gestionnaires de mots de passe, hubs domotiques à fonctions de sécurité et consorts — devront faire vérifier leur copie par un organisme notifié tiers. Mieux vaut savoir tôt dans quelle case tombe votre produit, parce que la capacité des organismes notifiés en 2027 sera un goulot d'étranglement.

Les amendes, et les petites lignes

Manquer aux exigences essentielles expose à des amendes pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial total, le montant le plus élevé étant retenu. Les infractions moindres se chiffrent à 10 millions d'euros ou 2 %, et tromper les autorités coûte jusqu'à 5 millions d'euros ou 1 %. Les pourcentages sont tout l'enjeu — c'est l'arithmétique du RGPD, conçue pour qu'ignorer les règles ne soit jamais moins cher que les suivre.

Deux exceptions sont souvent surinterprétées. Les micro et petites entreprises ne peuvent pas être sanctionnées pour avoir manqué les délais de signalement de 24 et 72 heures — mais toutes les autres obligations restent pleinement passibles d'amendes : c'est un sursis ponctuel, pas une exemption. Et les stewards open source (fondations et mainteneurs qui développent du logiciel sans le monétiser) sont totalement exonérés d'amendes. Mais dès que ce code open source est embarqué dans votre produit commercial, c'est vous le fabricant, et ses vulnérabilités deviennent votre problème de signalement.

Que faire d'ici septembre

Si vous vendez, ou comptez vendre, un produit connecté dans l'UE, la checklist de l'été est courte et concrète. Inventoriez ce que contiennent réellement vos produits — générez un SBOM depuis le build, ne le reconstituez pas de mémoire. Mettez en place un canal de réception des vulnérabilités : un security.txt, une boîte mail surveillée, une politique de divulgation qu'un chercheur peut trouver. Rédigez le runbook d'incident et répétez une fois le compte à rebours de 24 heures, sur une fausse CVE, pour que le premier vrai signalement ne soit pas aussi la répétition générale. Et vérifiez la classification de votre produit, parce qu'elle détermine si 2027 rime avec auto-évaluation ou file d'attente d'audit.

Le point le plus dur n'est pas dans cette liste, parce que ce n'est pas un problème de septembre : le firmware mettable à jour sur le terrain. Si vos appareils ne peuvent pas recevoir une mise à jour signée en OTA aujourd'hui, le rattrapage représente des mois de travail entre bootloader, infrastructure de livraison et exploitation du parc. Les équipes qui s'y mettront en 2027 le feront pendant la période d'application du règlement, et non avant.

Rien de tout cela ne relève d'une ingénierie exotique. Des mises à jour signées, un suivi des dépendances, un moyen pour quelqu'un de vous dire que votre produit a un trou — une équipe produit bien tenue veut tout ça de toute façon, comme elle veut des tests et des sauvegardes. Le CRA a juste transformé « veut » en « doit » et y a attaché une date. Deux dates, en réalité. La seconde concentre toute l'attention. La première est l'échéance.