La première échéance du Cyber Resilience Act (CRA) qui concerne les équipes produit est le 11 septembre 2026, date à laquelle les obligations de notification commencent à s'appliquer. Les obligations principales suivent le 11 décembre 2027. La notification repose sur des processus et des personnes, ce qui est long à mettre en place : elle passe donc avant tout le reste.
Ce qui s'applique, et quand
Le CRA est le règlement (UE) 2024/2847. Selon la page de la Commission européenne consacrée au CRA, il fixe des exigences de cybersécurité obligatoires pour les fabricants, couvrant la planification, la conception, le développement et la maintenance des produits comportant des éléments numériques. Il impose aussi aux fabricants de gérer les vulnérabilités tout au long du cycle de vie du produit.
| Date | Ce qui se passe |
|---|---|
| 10 décembre 2024 | Entrée en vigueur du CRA |
| 11 septembre 2026 | Application des obligations de notification |
| 11 décembre 2027 | Application des obligations principales |
Les produits conformes porteront le marquage CE, et les autorités nationales de surveillance du marché veillent au respect des règles. Certains produits particulièrement sensibles pour la cybersécurité pourront nécessiter une évaluation par un tiers, un organisme notifié, avant leur mise en vente sur le marché de l'UE. Déterminez tôt de quel côté de cette frontière se situe votre produit, car cela modifie votre calendrier.
La Commission a également publié des lignes directrices pratiques à l'attention des fabricants le 27 juillet 2026. Lisez-les avant de figer la conception de l'un des processus décrits ci-dessous.
Preuves de développement sécurisé
Les autorités de contrôle et vos clients vous demanderont ce que vous avez fait. Constituez donc des traces comme sous-produit du travail quotidien, plutôt que de les reconstituer après coup. Un cadre reconnu aide à structurer la démarche.
Le NIST Secure Software Development Framework, SP 800-218, est un socle de pratiques de haut niveau que vous ajoutez au SDLC que vous appliquez déjà. Ses objectifs affichés sont de réduire le nombre de vulnérabilités dans les logiciels livrés, d'atténuer l'impact de celles qui subsistent et de traiter les causes racines pour qu'elles ne se reproduisent pas. Il offre aussi un vocabulaire commun à utiliser avec vos acheteurs et fournisseurs. Il s'agit d'un document américain et non d'une checklist du CRA : considérez-le comme une ossature.
Les preuves à conserver pour chaque version livrée :
- le threat model ou la revue de conception qui a couvert la modification
- les résultats de revue de code et de tests, y compris les tests de sécurité
- la liste des dépendances avec leurs versions, et la décision prise au sujet des vulnérabilités connues qu'elles contiennent
- l'approbation de la release, avec un nom et une date
Les ressources Secure by Design de la CISA ajoutent deux points pratiques. La responsabilité doit se situer au niveau de la direction, et les paramètres par défaut comptent : MFA, journalisation et SSO doivent être disponibles d'emblée, sans surcoût. Si votre produit vend ces fonctions comme options payantes, attendez-vous à ce que cela soit remis en question. La CISA publie aussi des recommandations sur les feuilles de route vers les langages memory safe, utiles si votre code est en C ou C++.
Gestion et notification des vulnérabilités
À partir du 11 septembre 2026, les fabricants doivent notifier les vulnérabilités activement exploitées, ainsi que les autres éléments listés sur la page de notification de la Commission. Consultez cette page pour connaître le périmètre exact et le canal à utiliser. Ne vous fiez pas à un résumé, y compris celui-ci.
Ce dont vous avez besoin en interne, quels que soient les détails définitifs :
- Un point d'entrée unique. Un contact sécurité surveillé, indiqué sur le site du produit et dans la documentation, avec un responsable nommé et un suppléant.
- Une routine de triage. Quelqu'un décide dans un délai fixé si un signalement est valide, s'il est exploité et quels produits et versions il touche. Un score de sévérité cohérent accélère ce travail ; notre calculateur CVSS est utile pour s'accorder sur les scores au sein de l'équipe.
- Un circuit de décision pour la notification. Documentez qui décide qu'une vulnérabilité exploitée déclenche une notification, et qui la dépose. Répétez-le une fois sur un cas fictif, en dehors des heures de bureau si c'est à ce moment que cela se produirait réellement.
- Une trace de chaque décision. Y compris pour les signalements que vous avez jugés hors périmètre, avec la raison.
La notification ne peut pas fonctionner si vous ne savez pas ce que contient votre produit. Tenez à jour un inventaire des composants pour chaque version livrée, car on ne peut pas évaluer de mémoire son exposition à une nouvelle vulnérabilité.
Processus de mise à jour
La Commission cite l'absence de mises à jour de sécurité en temps utile parmi les problèmes auxquels le CRA répond. Les produits doivent être conçus, mis à jour et maintenus de manière à protéger les utilisateurs. En pratique, cela signifie tester votre chaîne de mise à jour aussi sérieusement que vos fonctionnalités.
Vérifiez les points suivants sur chaque gamme de produits :
- Vous pouvez livrer un correctif de sécurité indépendamment d'une version fonctionnelle.
- Les clients peuvent savoir qu'une mise à jour existe, et l'installer ne nécessite pas d'appel au support.
- Les anciennes versions ont une date de fin de support que les clients peuvent consulter avant d'acheter.
- Pour le matériel, vous avez testé la mise à jour d'un appareil resté hors ligne pendant un an, ainsi que la récupération d'un appareil dont la mise à jour échoue à mi-parcours.
Le point faible courant n'est pas la technologie, mais la responsabilité. Beaucoup d'équipes savent produire un correctif en une journée, puis passent trois semaines à chercher qui a le droit de le publier.
Documentation technique
Les sources que j'ai utilisées ne détaillent pas le contenu exigé du dossier technique : reportez-vous pour cela au texte juridique et aux lignes directrices de la Commission. Sur le plan pratique, la documentation doit être assemblée en continu à partir des preuves décrites plus haut, et non rédigée dans le dernier trimestre avant l'échéance.
Donnez à chaque produit un dossier de documentation, ou une section de dépôt, avec un responsable. Placez-y la conception et l'analyse de risques, l'inventaire des composants, les résultats de tests, la procédure de gestion des vulnérabilités et la politique de mise à jour. Versionnez-le avec le produit. Lorsqu'un auditeur ou une autorité demande un dossier, vous voulez pouvoir l'exporter, pas le faire rédiger.
Si vous relevez aussi de la directive NIS2, que le CRA complète selon la Commission, réutilisez les mêmes procédures d'incident et de vulnérabilité plutôt que d'en maintenir deux jeux.
Par où commencer
- Lisez les lignes directrices de la Commission du 27 juillet 2026 et la page de notification, puis consignez quels produits sont dans le périmètre et si certains pourraient nécessiter un organisme notifié.
- Nommez un responsable de la réception des vulnérabilités et de la notification des vulnérabilités exploitées, publiez un contact sécurité et organisez une répétition ce trimestre.
- Produisez un inventaire des composants pour chaque version supportée et intégrez sa génération à votre build.
- Confrontez votre SDLC actuel aux pratiques du SSDF, notez les écarts et commencez à conserver, pour chaque release, les traces de revue, de test et d'approbation.
- Testez votre chaîne de mise à jour de bout en bout et publiez les dates de fin de support de chaque produit.
- Créez le dossier de documentation par produit et remplissez-le avec ce que vous avez déjà. Si vous souhaitez un regard extérieur sur les écarts, notre service de conseil et notre service de développement logiciel sécurisé couvrent précisément ce sujet.
