L'idée de départ, en une image
Quand vous achetez un grille-pain, vous partez du principe qu'il ne va pas prendre feu tout seul. Il y a des normes pour ça, et un fabricant sérieux les respecte avant de vendre son produit.
Pour les objets connectés et les logiciels, ce genre de garantie n'existait pas vraiment jusqu'ici. Une caméra de surveillance, une montre connectée, une appli mobile, un petit robot domestique : rien n'obligeait leurs fabricants à penser sérieusement à la sécurité avant de les mettre sur le marché. Résultat : beaucoup de produits connectés circulent avec des failles, parfois jamais corrigées.
Le Cyber Resilience Act, c'est l'équivalent des normes de sécurité du grille-pain, mais appliqué au numérique. C'est un règlement européen qui dit : "si vous vendez un produit avec un élément numérique dans l'Union européenne, vous devez garantir un niveau minimum de sécurité, et le prouver."
Concrètement, qui est concerné ?
Toute entreprise qui fabrique, importe ou distribue un produit comportant un élément numérique. En clair, c'est très large : un objet IoT, un logiciel vendu en tant que tel, une appli qui pilote un appareil, un firmware, un système d'exploitation embarqué... Si ça se connecte ou ça communique avec un réseau, ça rentre potentiellement dans le champ du CRA.
Il y a des exceptions notables, comme les logiciels purement "as a service" sans composant physique (le SaaS pur est traité différemment) ou les dispositifs médicaux déjà couverts par d'autres règlements. Mais pour l'écrasante majorité des objets connectés et logiciels grand public, le texte s'applique.
Ce qu'il demande, en trois grandes idées
1. Penser à la sécurité dès le départ, pas après coup
C'est le principe du "security by design". Plutôt que de corriger les failles une fois le produit déjà vendu, l'idée est de les anticiper dès la phase de conception. Concrètement, ça veut dire se demander, avant même d'écrire une ligne de code : comment pourrait-on détourner ce produit ? Quelles données sensibles manipule-t-il ? Quels sont les points d'entrée pour un attaquant ?
2. Suivre le produit dans la durée
Un produit numérique n'est jamais "fini" une fois vendu. De nouvelles vulnérabilités sont découvertes en permanence dans les logiciels du monde entier. Le CRA demande donc aux fabricants de continuer à surveiller et corriger les failles de sécurité pendant toute la durée de vie du produit, et de fournir des mises à jour de sécurité gratuites quand c'est nécessaire. Si une faille grave est découverte, il y a même une obligation de la signaler aux autorités dans un délai très court (24h pour un premier signalement).
3. Pouvoir le prouver
C'est sans doute la partie la moins intuitive, mais elle est centrale : il ne suffit pas d'être sécurisé, il faut pouvoir le démontrer. Cela passe par une documentation technique détaillée (comment le produit a été conçu, quels composants logiciels il contient, quels risques ont été identifiés) et, selon le niveau de risque du produit, par une évaluation de conformité, parfois réalisée par un organisme externe.
Un mot qui revient souvent : le SBOM
Vous entendrez parler de "SBOM" (Software Bill of Materials). C'est tout simplement la liste des ingrédients logiciels d'un produit : quelles bibliothèques, quelles dépendances, quelles versions sont utilisées à l'intérieur. Un peu comme la liste des ingrédients sur un paquet de gâteaux, mais pour du code. L'intérêt est évident : le jour où une faille est découverte dans une bibliothèque très utilisée (cela arrive régulièrement), un SBOM permet de savoir en quelques secondes si on est concerné, plutôt que de devoir éplucher tout son code dans l'urgence.
Et si on ne respecte pas le règlement ?
Comme pour le RGPD en son temps sur les données personnelles, le CRA prévoit des sanctions financières en cas de non-conformité, qui peuvent être significatives pour les manquements les plus graves. Mais l'objectif du texte n'est pas de sanctionner : c'est d'élever le niveau de sécurité général des objets connectés en Europe, pour des produits plus fiables et des utilisateurs mieux protégés.
Et la date à retenir ?
Le règlement est entré en vigueur en décembre 2024, mais il prévoit une période de transition. Les obligations de signalement des vulnérabilités s'appliquent à partir de septembre 2026, et l'ensemble du règlement, avec toutes ses exigences, devient pleinement applicable en décembre 2027. C'est cette dernière date qui sert généralement de repère pour se préparer.
En résumé
Le Cyber Resilience Act, c'est une manière d'imposer aux objets connectés et aux logiciels les mêmes réflexes de sécurité de base qu'on attend déjà de n'importe quel produit physique : être conçu sérieusement, rester sûr dans le temps, et pouvoir prouver qu'on a fait les choses correctement. Ce n'est pas une montagne infranchissable, surtout si on commence à s'y intéresser bien avant l'échéance.
Source :
