Un routeur continue de fonctionner, mais ne reçoit plus de correctifs. Une caméra connectée reste accessible depuis Internet alors que son fabricant a abandonné son logiciel. Ces produits ne sont pas forcément en panne : ils sont devenus difficiles à protéger. Le Cyber Resilience Act (CRA), règlement européen sur la cyberrésilience, entend changer cette situation. Son principe : vendre un objet ou un logiciel connecté ne suffit plus ; il faut aussi organiser sa sécurité dans le temps. En septembre 2026, cette promesse entre dans une première phase opérationnelle, avant l’application générale prévue fin 2027.
Septembre 2026 : une première échéance, pas le grand basculement
Adopté en 2024, le CRA est entré en vigueur le 10 décembre de cette année-là. Son calendrier distingue plusieurs étapes. Les dispositions relatives à la notification des organismes d’évaluation de la conformité s’appliquent depuis le 11 juin 2026. Les obligations de signalement des vulnérabilités activement exploitées et des incidents graves prennent effet le 11 septembre 2026. L’essentiel des exigences applicables aux produits suivra le 11 décembre 2027. Il serait donc trompeur de présenter tous les appareils vendus à la rentrée 2026 comme déjà soumis à l’intégralité du dispositif.
Cette montée en charge laisse du temps, mais elle impose d’anticiper. Un équipement conçu aujourd’hui peut encore être commercialisé après l’échéance générale. Surtout, créer une équipe de réponse aux vulnérabilités, inventorier les composants logiciels et sécuriser la distribution des correctifs ne se fait pas en quelques semaines. L’analyse prospective est assez claire : les industriels qui attendraient 2027 pour s’organiser risqueraient de découvrir que leur principal chantier n’est pas juridique, mais technique et humain.
Le produit numérique devient une responsabilité durable
Le texte vise largement les produits comportant des éléments numériques : logiciels, équipements et composants dont l’usage prévu ou raisonnablement prévisible implique une connexion directe ou indirecte à un appareil ou à un réseau. Cela concerne potentiellement une serrure connectée comme un système industriel. Des exclusions existent, notamment pour certains produits déjà couverts par des règles sectorielles. Les services en ligne ne sont pas tous automatiquement concernés, mais certaines fonctions de traitement à distance indispensables au produit peuvent entrer dans son périmètre.
Le changement central tient au cycle de vie. Le fabricant doit évaluer les risques, concevoir un produit avec un niveau de cybersécurité approprié et traiter ses vulnérabilités pendant la période de support. La sécurité ne peut plus se résumer à un audit réalisé avant le lancement. Elle devient une activité continue : recevoir une alerte, vérifier quels modèles sont touchés, développer un correctif, le tester, puis permettre aux utilisateurs de l’installer sans transformer leur équipement en presse-papiers.
Une vulnérabilité ne doit plus finir dans une boîte mail oubliée
L’histoire récente explique cette priorité. La faille Log4Shell, rendue publique en décembre 2021 dans la bibliothèque Java Log4j, a rappelé combien un composant discret pouvait se retrouver dans une multitude de logiciels. Pour corriger, encore fallait-il savoir où il était utilisé. Le CRA exige notamment une documentation des composants, avec une nomenclature logicielle dans un format couramment utilisé et lisible par machine. Cet inventaire n’est pas une garantie absolue ; c’est une condition pour enquêter rapidement.
Autre exigence structurante : disposer d’une politique de divulgation coordonnée des vulnérabilités et faciliter leur signalement. Concrètement, un chercheur ne devrait pas devoir solliciter le service commercial pour prévenir qu’un thermostat expose des identifiants. Derrière le point de contact, il faut une procédure capable de qualifier le problème, de dialoguer avec son auteur et de préparer la remédiation. Le véritable test sera moins l’existence d’une adresse électronique que la capacité à y répondre utilement.
Signaler vite, sans confondre tous les défauts
À partir du 11 septembre 2026, le calendrier réglementaire prévoit une alerte précoce dans les 24 heures suivant la prise de connaissance d’une vulnérabilité activement exploitée, puis une notification plus complète sous 72 heures. Le dispositif associe les CSIRT désignés comme coordinateurs et l’ENISA, l’agence européenne pour la cybersécurité. Des obligations concernent aussi les incidents graves ayant une incidence sur la sécurité du produit. Toute faille découverte n’est donc pas automatiquement une alerte réglementaire sous 24 heures. Cette distinction évite de confondre gestion quotidienne et urgence avérée.
Le support devient une caractéristique du produit
Combien de temps un fabricant doit-il suivre son produit ? Le règlement impose de déterminer une période de support tenant compte notamment de sa durée d’utilisation attendue. Cette période doit être d’au moins cinq ans, sauf si le produit est censé être utilisé moins longtemps. Mais cinq ans ne constituent pas un plafond universel : pour des équipements destinés à rester longtemps en service, une période supérieure peut être nécessaire. Le fabricant doit rendre l’échéance du support clairement accessible à l’acheteur.
Cette information pourrait devenir aussi décisive que l’autonomie ou la capacité de stockage. Un appareil soldé reste-t-il intéressant si son support approche de la fin ? Une entreprise peut-elle acheter des capteurs destinés à fonctionner dix ans sans connaître leur trajectoire de maintenance ? À terme, les acheteurs pourraient comparer un coût d’usage sécurisé plutôt qu’un simple prix d’acquisition. Cette évolution reste prospective, mais le règlement fournit un repère concret pour poser la question avant de signer.
Des mises à jour gratuites, mais jamais gratuites à produire
Le CRA prévoit, en principe, la diffusion gratuite des mises à jour de sécurité, avec une exception encadrée pour certains accords spécifiques entre professionnels concernant des produits sur mesure. Il demande aussi des mécanismes de distribution sécurisés. L’enjeu ne consiste pas seulement à publier un fichier : il faut empêcher qu’un attaquant remplace le correctif, informer les utilisateurs et faciliter son déploiement. Une mise à jour de sécurité devrait également pouvoir être distinguée, lorsque c’est techniquement possible, d’une évolution fonctionnelle.
Pour les fabricants, cette continuité a un coût : conserver des compétences, maintenir des infrastructures et tester plusieurs générations d’équipements. Elle pourrait favoriser des architectures plus simples et des gammes moins dispersées. À l’inverse, une conformité purement documentaire laisserait les problèmes intacts. Le recours à des composants open source ne supprime pas non plus la responsabilité du fabricant : il faut connaître ses dépendances et organiser leur suivi, sans assimiler tous les contributeurs bénévoles à des industriels soumis aux mêmes obligations.
La confiance se mesurera après le lancement
Le CRA ne promet pas des produits invulnérables. Il installe un cadre de conformité, de surveillance du marché et de sanctions pour rendre la sécurité moins facultative. Son efficacité dépendra aussi des moyens des autorités et de la qualité des évaluations. Pour l’utilisateur, les signes tangibles seront simples : une date de fin de support compréhensible, des alertes utiles et des correctifs effectivement disponibles.
Et maintenant ? D’ici à l’application générale de décembre 2027, les fabricants ont intérêt à traiter la maintenance comme une composante du produit, budgétée dès sa conception. Les distributeurs et acheteurs peuvent déjà réclamer des engagements précis. Si le règlement tient sa promesse, la meilleure question ne sera plus seulement « est-il sécurisé aujourd’hui ? », mais « qui prendra soin de sa sécurité demain ? »
