Cyber Resilience Act : votre logiciel est-il prêt ?

Cyber Resilience Act : votre logiciel est-il prêt ?

Le Cyber Resilience Act (CRA) n'est pas un texte réservé aux fabricants de montres connectées ou de routeurs. Il vise aussi les éditeurs de logiciels. Si vous vendez une application métier, un progiciel ou un outil installé chez vos clients dans l'Union européenne, il vous concerne probablement.

Le calendrier est déjà en marche. Le CRA est entré en vigueur le 10 décembre 2024. Depuis le 11 septembre 2026, les fabricants doivent signaler les vulnérabilités activement exploitées et les incidents graves. Les exigences principales s'appliqueront à partir du 11 décembre 2027. Il reste donc un peu plus d'un an pour mettre son produit en conformité, ce qui est court pour un logiciel métier ancien.

Ce que dit le texte, en clair

Le CRA s'appuie sur une logique simple : un produit comportant des éléments numériques doit être sûr dès sa mise sur le marché, et le rester pendant toute sa durée de vie. Le texte repose sur trois idées.

1. La sécurité dès la conception. Le produit doit être livré avec une configuration sécurisée par défaut, protéger les accès non autorisés et chiffrer les données sensibles.
2. La gestion des vulnérabilités sur la durée. Le fabricant doit identifier, corriger et signaler les failles, et fournir des mises à jour de sécurité pendant la durée de support annoncée.
3. La transparence. Le fabricant doit documenter les composants utilisés et informer ses clients et les autorités des failles exploitées.

Le marquage CE devient l'attestation que le produit respecte ces exigences. Certains produits jugés particulièrement sensibles pour la cybersécurité devront en outre passer une évaluation par un organisme tiers notifié avant mise sur le marché.

Pour les données, le texte va plus loin qu'on ne le pense : l'utilisateur doit pouvoir supprimer ses données du produit, et les exporter sans être enfermé chez un fournisseur. Le principe de minimisation s'applique : ne collectez que ce dont le service a besoin.

Le piège des logiciels sur mesure

C'est là que la question devient intéressante pour une ESN, une agence ou un éditeur de progiciels métier. Le CRA ne raisonne pas en « projet client » mais en « produit mis sur le marché ». Concrètement, la frontière dépend de votre modèle :

• Développement sur mesure pour un seul client, livré en propriété, sans commercialisation ultérieure : le périmètre est à analyser au cas par cas. Le contrat, la transmission du code et la maintenance comptent.
• Logiciel métier vendu en licence à plusieurs clients : vous êtes très probablement fabricant au sens du CRA, même si chaque instance est personnalisée.
• Solution SaaS hébergée par vous : en principe hors périmètre pour le SaaS pur, mais les composants embarqués dans un agent installé chez le client (un connecteur, une application desktop, un boîtier) redeviennent dans le champ.

Notre position : ne pas attendre la mise en conformité de ses clients pour se poser la question. Un client qui achète un progiciel en 2027 demandera une SBOM et un engagement de mises à jour. Autant avoir les réponses prêtes.

La SBOM, premier chantier concret

La SBOM (Software Bill of Materials) est la liste des composants et bibliothèques qu'une application utilise pour fonctionner. Pour le régulateur, elle prouve que vous savez ce qui tourne dans votre produit et que vous avez vérifié ces composants au moment de la mise sur le marché.

Pour un projet Node.js ou Python, générer une SBOM au format CycloneDX ou SPDX est devenu une étape de build banale. Voici un exemple avec Syft, un outil open source qui produit ces fichiers à partir d'une image ou d'un dossier :

# Génère une SBOM au format CycloneDX à partir d'un dossier de projet
syft dir:. -o cyclonedx-json > sbom.cdx.json

# Analyse les vulnérabilités connues des composants listés (avec Grype)
grype sbom:./sbom.cdx.json

Intégrez ces deux étapes dans votre pipeline CI : une SBOM par version, archivée avec le livrable. C'est le point de départ de toute démarche CRA, et c'est aussi ce qui permet de répondre vite lorsqu'une faille est publiée dans une bibliothèque que vous utilisez.

Le process de vulnérabilités : ce qui fait la différence

Le CRA impose une capacité, pas seulement un document. Le fabricant doit pouvoir :

• recevoir les signalements de vulnérabilités, y compris de chercheurs externes, via un canal documenté ;
• évaluer la gravité, corriger et publier la mise à jour ;
• notifier les autorités compétentes lorsqu'une faille est activement exploitée, dans les délais fixés par le texte ;
• informer les utilisateurs et fournir un correctif pendant la durée de support annoncée.

Pour une petite structure, le plus réaliste est de formaliser ce process dans un document de quelques pages, puis de le tester. Un exercice simple : simuler une CVE critique sur une bibliothèque de votre stack et chronométrer le temps entre la détection et le correctif livré. Si le chiffre vous surprend, vous savez où investir.

Par où commencer

Une checklist pragmatique pour les 90 prochains jours :

• Lister tous les produits logiciels commercialisés ou distribués dans l'UE, avec leur modèle (licence, embarqué, on-premise, SaaS).
• Qualifier pour chaque produit si le CRA s'applique, avec l'avis de votre conseil juridique.
• Générer une SBOM pour la version en production de chaque produit concerné, et l'intégrer à la CI.
• Mettre en place un scan de vulnérabilités récurrent sur ces SBOM.
• Rédiger la procédure de gestion des vulnérabilités et désigner un responsable.
• Définir la durée de support annoncée à vos clients et l'inscrire dans vos contrats.
• Revoir les configurations par défaut : aucun mot de passe par défaut, journalisation utile, chiffrement des données sensibles.

Le CRA peut sembler une contrainte de plus. Mais les exigences qu'il impose (SBOM, mises à jour, configuration sécurisée) sont celles que les grands comptes réclament déjà dans leurs appels d'offres. Le faire maintenant, c'est transformer une obligation réglementaire en argument commercial.

Sources principales : texte officiel et page de la Commission européenne sur le Cyber Resilience Act (dates d'entrée en vigueur et de application), mise à jour du 7 septembre 2026.