Cyber Resilience Act : les nouvelles obligations de sécurité pour vos logiciels

Obsolescence architecturale garantie: le calendrier CRA

Ce cadre réglementaire entré en vigueur le 10 décembre 2024 impose désormais, par étapes, des exigences obligatoires de cybersécurité dès la conception pour tout logiciel ou matériel connecté mis sur le marché européen. Les obligations de signalement s'appliqueront dès le 11 septembre 2026 — soit dans quelques jours. L'ensemble des exigences principales prendra effet le 11 décembre 2027.

Trois dates. Trois paliers de contrainte. Aucune excuse valable pour ignorer le calendrier.

Architecture de conformité: ce que le CRA impose concrètement

Le règlement couvre la totalité du cycle de vie produit: planification, conception, développement, maintenance. Pas de zone morte dans la chaîne de valeur — chaque maillon est responsable.

Voici les obligations structurantes:

• Cybersécurité dès la conception: les éditeurs de logiciels et constructeurs de matériel doivent intégrer les exigences de sécurité au plus tôt dans le processus de développement. Rétro-ingénierie sécuritaire a posteriori: terminé.
• Gestion des vulnérabilités: obligation de traitement pendant toute la durée de vie du produit. Un firmware sans correctif n'est plus une option commerciale défendable.
• Évaluation tierce: certains produits jugés critiques pour la cybersécurité devront passer par un organisme notifié avant mise sur le marché. Validation externe obligatoire.
• Marquage CE: conformité CRA intégrée au marquage CE. Les autorités nationales de surveillance du marché assurent le contrôle.

Le CRA complète la directive NIS2 et s'inscrit dans la stratégie de cybersécurité de l'UE adoptée en 2020. Il traite un angle que NIS2 ne couvre pas directement: le niveau insuffisant de cybersécurité des produits eux-mêmes, et l'absence de mises à jour de sécurité en temps voulu.

Impact opérationnel: les compromis à anticiper

Pour les éditeurs de logiciels et les intégrateurs, la contrainte est structurelle. Quatre points méritent une attention immédiate:

• Dette technique exposée: tout composant sans politique de maintenance documentée devient un risque réglementaire. Les dépendances non maintenues dans une chaîne logicielle — bibliothèques tierces, SDK obsolètes — posent problème en cascade.
• Chaîne d'approvisionnement: le texte cible explicitement les fabricants « tout au long de la chaîne de valeur ». Un intégrateur qui assemble des composants tiers reste responsable de la conformité globale du produit final.
• Charge de documentation: prouver la conformité suppose de documenter les choix architecturaux de sécurité, les processus de gestion des vulnérabilités et les mécanismes de mise à jour. Sans traçabilité, pas de marquage CE.
• Scalabilité du processus: pour les éditeurs multi-produits, la conformité doit devenir un pipeline répétable, pas un audit ponctuel par ligne de code.

Le guide pratique publié en juillet 2026 vise précisément à démocratiser l'accès à ces obligations, y compris pour les PME. Le message implicite: les exemptions pour contraintes de taille n'existeront pas éternellement.