Cyber Resilience Act : sécurisez vos logiciels desktop
Le règlement (UE) 2024/2847 impose des normes de cybersécurité strictes aux éditeurs de logiciels desktop. Évaluez votre conformité et structurez vos obligations.
Le Cyber Resilience Act (CRA) s'applique à tout logiciel desktop commercialisé dans l'UE dès lors qu'il communique avec des réseaux ou d'autres dispositifs. Les éditeurs doivent désormais documenter leurs composants via un SBOM, gérer activement les vulnérabilités et fournir une documentation technique exhaustive (Annexe VII) pour obtenir leur déclaration UE de conformité.
Pourquoi les applications desktop sont visées par le CRA
Qu'il s'agisse de binaires Windows (.exe), macOS (.dmg) ou Linux (.deb), votre logiciel entre dans la catégorie des « produits comportant des éléments numériques ». L'époque où l'exécution locale exemptait de régulation est révolue : mises à jour automatiques, télémétrie et authentification en ligne suffisent à déclencher l'application du règlement.
L'entrée en vigueur du texte le 10 décembre 2024 impose un calendrier strict pour les éditeurs sur le marché européen :
- 11 septembre 2026 : obligation légale de notifier les vulnérabilités exploitées et incidents graves à l'ENISA et aux CSIRT nationaux sous 24 heures.
- 11 décembre 2027 : respect intégral des exigences essentielles de sécurité, marquage CE et archivage de la documentation technique complète.
- Sanctions prévues : les infractions peuvent entraîner des amendes allant jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial annuel.
Exigences clés du CRA pour les éditeurs desktop
Le règlement UE 2024/2847 redéfinit la responsabilité des équipes produit et développement desktop.
Inventaire SBOM exhaustif
Assurez une traçabilité rigoureuse de toutes vos dépendances tierces et open source intégrées dans vos exécutables (.NET, C++, Rust, Go, Python ou Electron).
Gestion proactive des vulnérabilités
Surveillez en continu les failles de sécurité affectant vos bibliothèques embarquées et déployez rapidement des correctifs sécurisés pour vos utilisateurs.
Dossier technique (Annexe VII)
Constituez et archivez le dossier technique prouvant la robustesse de votre architecture logicielle et la maîtrise des risques cyber associés.
Reporting d'incidents (ENISA)
Mettez en œuvre des procédures internes documentées pour notifier toute exploitation active de vulnérabilité sur vos postes clients sous 24 heures.
Le défi des dépendances embarquées
Contrairement aux architectures web, une application desktop installe du code directement sur le poste de l'utilisateur. Chaque bibliothèque liée statiquement ou distribuée avec votre client lourd expose l'utilisateur final aux vulnérabilités non corrigées. La maîtrise de votre chaîne d'approvisionnement logicielle devient une priorité réglementaire.
- Détection des bibliothèques obsolètes figées dans vos installeurs ou runtimes.
- Visibilité totale sur les dépendances transitives (npm, NuGet, Crates).
- Génération automatique d'un inventaire SBOM au standard CycloneDX.
- Processus de mise à jour sécurisé et politique de divulgation via SECURITY.md.
Classifier votre logiciel desktop selon le CRA
Le CRA définit des niveaux d'évaluation basés sur la criticité de votre produit :
1. Logiciels par défaut (Auto-évaluation)
La majorité des logiciels desktop (outils métier, bureautique, utilitaires) relèvent de cette classe. L'éditeur réalise sa propre évaluation de conformité sans organisme tiers, sous réserve d'une documentation technique irréprochable.
2. Produits importants (Annexe III)
Si votre application intègre des fonctions critiques (gestionnaires de mots de passe, clients VPN, antivirus), elle est classée I ou II, imposant des normes harmonisées ou l'intervention d'un organisme notifié.
3. Produits critiques (Annexe IV)
Réservée aux composants ultra-sensibles (matériel cryptographique, cartes à puce), cette catégorie exige une certification de sécurité européenne formelle.
Obligations sur le cycle de vie du binaire
La mise sur le marché impose des impératifs de conception et d'exploitation :
- Sécurité par défaut : interdiction des mots de passe par défaut, réduction de la surface d'attaque et restriction des privilèges d'exécution.
- Mises à jour sécurisées : fourniture gratuite de correctifs pendant la durée de vie du produit, via un mécanisme d'installation authentifié.
- Transparence : maintien d'un fichier SBOM exportable pour chaque version livrée.
Préparez votre logiciel desktop aux échéances 2026 et 2027
Analysez votre code source et générez vos premiers livrables de conformité CRA en quelques clics.
Feuille de route : conformité de votre application
- 1
Cartographier les dépendances
Connectez vos dépôts pour inventorier les packages utilisés dans vos binaires (.NET, Rust, Go, PyPI, npm, etc.).
- 2
Générer un SBOM standardisé
Exportez un Software Bill of Materials (CycloneDX) pour lister rigoureusement vos bibliothèques statiques et dynamiques.
- 3
Évaluer la maturité cyber
Identifiez les écarts réglementaires et suivez la progression de vos mises en conformité sur une échelle de 100 points.
- 4
Produire la documentation technique
Rassemblez la déclaration UE, l'analyse des risques (Annexe VII) et votre politique SECURITY.md pour archiver vos preuves.
CRAcheck : simplifiez votre auto-évaluation
CRAcheck structure votre démarche d'auto-évaluation sans ralentir vos cycles de développement :
- Connexion GitHub : synchronisation instantanée avec vos dépôts de code desktop.
- Multi-écosystèmes : extraction de SBOM sur 9 langages majeurs (npm, PyPI, Go, Rust, .NET, PHP, Ruby, Java, CycloneDX).
- Surveillance continue : alertes immédiates en cas de CVE critique sur vos dépendances publiées.
- Modèles pré-remplis : génération de la documentation Annexe VII, déclaration UE et matrices de reporting ENISA.
Note : CRAcheck est un outil d'aide à la décision. Il permet aux éditeurs de la catégorie par défaut de structurer leurs dossiers techniques face aux exigences du règlement.
Questions fréquentes sur le CRA
Un logiciel desktop hors ligne est-il concerné ?+
Oui, dès lors qu'il est commercialisé dans l'UE et possède des capacités de connexion (mises à jour, licence, télémétrie). Seuls les logiciels totalement isolés sans aucune interface numérique peuvent prétendre à une exclusion.
Les logiciels open source sont-ils soumis au CRA ?+
Le règlement exclut les logiciels développés hors activité commerciale. Toutefois, si une entreprise commercialise un logiciel basé sur des briques open source, elle est pleinement responsable de la conformité du produit final.
Puis-je m'auto-évaluer pour le marquage CE ?+
Oui, pour la catégorie par défaut (majorité des logiciels desktop). L'auto-évaluation impose toutefois la tenue rigoureuse du dossier technique (Annexe VII) et la signature de la déclaration UE.
Quelles sont les dates limites à retenir ?+
Entrée en vigueur le 10 décembre 2024. Reporting des vulnérabilités (ENISA) obligatoire dès le 11 septembre 2026. Conformité technique et marquage CE obligatoires au 11 décembre 2027.
Structurez la conformité CRA de vos applications
Connectez vos dépôts, évaluez vos dépendances et produisez vos livrables de conformité technique dès aujourd'hui.
Sur le même thème — Par type de produit
Nouveau sur le Cyber Resilience Act ? Commence par le guide complet.
Le guide CRADepuis le blog
Vérifie ta conformité CRA en 1 minute
Gratuit, sans inscription. Scanne ton dépôt et obtiens ton score de conformité + tes documents pré-remplis.