Vous concevez, fabriquez ou commercialisez un produit connecté ou un logiciel vendu en Europe ? Alors le Cyber Resilience Act (CRA) vous concerne, et sa première échéance contraignante tombe le 11 septembre 2026. Le problème, c’est que ce règlement est aujourd’hui surtout commenté par des avocats et des cabinets de conseil en cybersécurité. Difficile d’y trouver une réponse simple à la question que se pose un dirigeant ou un responsable produit : concrètement, qu’est-ce que je dois faire, et pour quand ?
Chez Playmoweb, nous développons depuis plus de 12 ans des applications mobiles, web et des produits IoT pour des industriels du médical, de l’agriculture ou de la maison connectée. La conformité réglementaire fait partie de nos projets au même titre que le code : nous avons déjà décrypté le Data Act pour les acteurs de l’IoT, voici le même exercice pour le CRA, avec les échéances, les obligations et une feuille de route pragmatique.
Sommaire
Adopté fin 2024, le Cyber Resilience Act est le premier règlement européen qui impose des exigences de cybersécurité aux produits eux-mêmes, et non aux organisations. C’est la grande différence avec NIS2 : NIS2 dit aux entreprises comment se protéger, le CRA dit aux fabricants comment concevoir des produits sécurisés.
Le principe est simple à retenir : à partir du 11 décembre 2027, un produit numérique ne pourra plus être commercialisé dans l’Union européenne sans être conforme au CRA. La cybersécurité devient une composante du marquage CE, au même titre que la sécurité électrique. En cas de non-conformité, les sanctions peuvent atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial.
Le CRA s’applique aux « produits comportant des éléments numériques » : tout matériel ou logiciel susceptible d’être connecté, directement ou indirectement, à un appareil ou à un réseau. Dans la pratique, cela couvre un spectre très large :
Le SaaS pur, fourni entièrement dans le cloud, est exclu du champ d’application. Mais attention : dès qu’il existe un composant téléchargeable ou installé côté client, le produit entre dans le périmètre. Une plateforme cloud accompagnée d’une application mobile est donc concernée pour sa partie applicative.
Le règlement distingue ensuite des catégories de criticité. La grande majorité des produits relève de la catégorie par défaut, avec une auto-évaluation documentée. Les « produits importants » (classe I et II : systèmes d’exploitation, routeurs, gestionnaires de mots de passe, domotique, jouets connectés…) devront passer par un organisme d’évaluation notifié.
Enfin, le CRA ne vise pas que les fabricants : les importateurs et distributeurs de produits numériques ont aussi des obligations de vérification. Si vous faites fabriquer en marque blanche ou si vous revendez du matériel connecté, vous êtes dans la boucle.
| Échéance | Ce qui s’applique | Qui est concerné |
|---|---|---|
| 11 juin 2026 | Mise en place des organismes d’évaluation de la conformité | Les États membres et organismes certificateurs |
| 11 septembre 2026 | Obligation de notifier les vulnérabilités activement exploitées et les incidents graves | Tous les fabricants, y compris pour les produits déjà sur le marché |
| 11 décembre 2027 | Application complète : exigences de conception, documentation, marquage CE | Fabricants, importateurs, distributeurs |
La nuance qui change tout : les produits mis sur le marché avant décembre 2027 ne sont pas rétroactivement soumis aux exigences de conception, sauf modification substantielle ultérieure. En revanche, l’obligation de notification de septembre 2026 s’applique bien à votre parc existant. C’est cette échéance qui arrive dans quelques semaines.
À partir de cette date, tout fabricant doit signaler deux types d’événements :
Le signalement s’effectue via la plateforme unique européenne (Single Reporting Platform) opérée par l’ENISA, qui transmet automatiquement l’information au CSIRT national. En France, c’est le CERT-FR de l’ANSSI qui coordonne.
Les délais sont stricts : une alerte précoce sous 24 heures après la prise de connaissance, puis une notification détaillée sous 72 heures. Autant dire que ce n’est pas le genre de processus qu’on improvise le jour J. Pour tenir ces délais, il faut savoir détecter la vulnérabilité (veille, monitoring, canal de signalement), qualifier sa criticité et déclencher la notification. Si personne dans votre organisation n’est aujourd’hui responsable de ce processus, c’est le premier chantier à ouvrir.
Pour les produits mis sur le marché à partir du 11 décembre 2027, ou substantiellement modifiés après cette date, le CRA impose des exigences tout au long du cycle de vie :
| Exigence | Ce que ça implique concrètement |
|---|---|
| Sécurité dès la conception (security by design) | Analyse de risques documentée, choix d’architecture justifiés, configuration sécurisée par défaut |
| Nomenclature logicielle (SBOM) | Inventaire lisible par machine de tous les composants du produit, y compris les librairies open source et leurs versions |
| Gestion des vulnérabilités | Processus de veille, canal de signalement public, politique de divulgation coordonnée |
| Mises à jour de sécurité | Capacité à déployer des correctifs (OTA pour l’IoT) pendant toute la période de support annoncée |
| Documentation technique | Dossier de conformité : évaluation des risques, résultats de tests, SBOM, procédures |
Pour un produit IoT, la capacité de mise à jour à distance (OTA) devient de fait un prérequis réglementaire. Un objet connecté qu’on ne peut pas patcher après déploiement ne sera plus défendable, ni commercialement, ni juridiquement.
En échangeant avec des fabricants et des porteurs de projets connectés, nous voyons revenir les mêmes angles morts :
Voici la démarche que nous recommandons, dans l’ordre :
Si vous répondez non à l’une de ces questions, la fenêtre pour agir sereinement se referme : deux mois avant les obligations de notification, dix-huit mois avant l’application complète.
Vous développez ou faites évoluer un produit connecté ? Parlons de votre conformité CRA lors d’un échange gratuit et sans engagement. 👉 Contactez-nous