Cybersécurité — réglementation

Cyber Resilience Act : le compte à rebours des éditeurs

Le règlement européen sur la cyber-résilience impose des exigences de sécurité à tout produit comportant des éléments numériques vendu dans l'UE — logiciels compris. Depuis le 11 septembre 2026, les vulnérabilités activement exploitées doivent être signalées sous 24 heures ; fin 2027, ce sera sécurité dès la conception, documentation et marquage CE. Si vous éditez un logiciel ou fabriquez un produit connecté, le compte à rebours a commencé.

Diagnostic déductible d'une mission de mise en conformité.

Le périmètre

NIS2 régule les entreprises, le CRA régule les produits

C'est le premier texte qui conditionne l'accès au marché européen à la cybersécurité du produit lui-même. Trois profils sont en première ligne :

Éditeurs de logiciels

Logiciel vendu en licence, en abonnement ou embarqué : commercialisé dans l'UE, c'est un « produit comportant des éléments numériques ». L'open source non commercial est exclu ; le logiciel sur mesure et le SaaS se tranchent au cas par cas.

Fabricants de produits connectés

Objets connectés, équipements industriels, capteurs, électronique grand public : tout matériel avec du logiciel embarqué est couvert — avec des catégories « importantes » et « critiques » soumises à des exigences renforcées.

Importateurs et distributeurs

Le CRA suit la logique du marquage CE : chacun dans la chaîne doit vérifier la conformité de ce qu'il met sur le marché. Revendre un produit non conforme engage votre responsabilité.

Ce que le règlement exige

Une obligation déjà active, trois pour fin 2027

01

Signaler — depuis le 11 sept. 2026

Vulnérabilité activement exploitée ou incident grave : alerte sous 24 h, notification sous 72 h, rapport final sous 14 jours (vulnérabilité) ou un mois (incident). L'obligation est active — il faut un processus qui tienne ces délais.

02

Sécurité dès la conception — déc. 2027

Analyse de risque documentée, configuration sûre par défaut, surface d'attaque réduite, protection des données. La sécurité devient une exigence de mise sur le marché, plus une option commerciale.

03

Gérer les vulnérabilités — déc. 2027

Nomenclature des composants (SBOM), politique de divulgation coordonnée, correctifs de sécurité gratuits pendant la période de support — cinq ans en règle générale.

04

Documenter et marquer CE — déc. 2027

Documentation technique, évaluation de conformité (autoévaluation ou tiers selon la catégorie), déclaration UE et marquage CE. Sans lui, plus de mise sur le marché européen.

Notre accompagnement

Du périmètre à la feuille de route, en trois temps

Nous développons et maintenons des logiciels en production : les exigences du CRA, nous les appliquons à nos propres livrables. Pas de juristes hors-sol — des ingénieurs qui parlent à vos équipes techniques.

Étape 1

Diagnostic de périmètre

Votre produit est-il couvert, dans quelle catégorie, avec quelles échéances ? Une réponse motivée, opposable à vos clients et partenaires.

Étape 2

Processus de signalement

Détection, qualification, déclaration sous 24/72 h : on met en place le processus de gestion des vulnérabilités — l'obligation déjà active, et le socle du reste.

Étape 3

Feuille de route 2027

SBOM, sécurité by design, documentation, préparation CE : un plan réaliste, séquencé sur les mois qui restent, intégré à votre roadmap produit.

Questions fréquentes

Le CRA en clair

Qu'est-ce que le Cyber Resilience Act ?

Le CRA (règlement UE 2024/2847) est le premier texte européen qui impose des exigences de cybersécurité aux produits eux-mêmes — et non aux entreprises qui les utilisent, comme le fait NIS2. Il couvre les « produits comportant des éléments numériques » : logiciels, objets connectés, équipements, composants. Entré en vigueur fin 2024, il s'applique par étapes : obligations de signalement depuis le 11 septembre 2026, et l'essentiel des exigences au 11 décembre 2027.

Suis-je concerné si j'édite « seulement » un logiciel ?

Oui. Un logiciel commercialisé dans l'UE est un produit comportant des éléments numériques au sens du CRA — qu'il soit vendu en licence, en abonnement ou intégré à un matériel. Les logiciels open source non commerciaux sont exclus, et certains secteurs déjà réglementés (médical, automobile, aéronautique) relèvent de leurs textes propres. Pour un éditeur SaaS, la frontière avec NIS2 se joue au cas par cas : c'est typiquement une question que notre diagnostic tranche.

Que faut-il faire depuis le 11 septembre 2026 ?

Signaler. Toute vulnérabilité activement exploitée dans votre produit, et tout incident grave affectant sa sécurité, doivent être notifiés : alerte précoce sous 24 heures, notification détaillée sous 72 heures, rapport final ensuite (14 jours pour une vulnérabilité, un mois pour un incident). Cela suppose d'être capable de détecter, qualifier et déclarer — donc d'avoir un processus de gestion des vulnérabilités qui fonctionne avant l'incident.

Et au 11 décembre 2027 ?

L'essentiel du règlement : sécurité dès la conception et par défaut, analyse de risque documentée, nomenclature des composants logiciels (SBOM), politique de divulgation coordonnée des vulnérabilités, mises à jour de sécurité gratuites pendant la période de support (cinq ans en règle générale), documentation technique et marquage CE. Un produit non conforme ne pourra plus être mis sur le marché européen.

Quelles sanctions ?

Jusqu'à 15 M€ ou 2,5 % du chiffre d'affaires mondial pour les manquements aux exigences essentielles, avec des paliers inférieurs pour les autres obligations. S'y ajoute le risque commercial : le retrait du marché, et des acheteurs — notamment publics et grands comptes — qui intégreront la conformité CRA à leurs appels d'offres bien avant les contrôles.

Par où commencer ?

Par un diagnostic : votre produit est-il dans le périmètre, dans quelle catégorie, et où en êtes-vous face aux exigences ? Puis par le processus de gestion des vulnérabilités — c'est l'obligation déjà active et le socle du reste. Le chantier 2027 (SBOM, documentation, CE) se planifie ensuite, sur une feuille de route réaliste. Développeurs nous-mêmes, nous parlons le langage de vos équipes techniques.

Faire le point

Savoir si votre produit est concerné prend une conversation

Décrivez votre produit — logiciel, SaaS, objet connecté. On vous dit s'il est dans le périmètre, ce qui est déjà obligatoire, et on cadre la feuille de route 2027. Sans engagement.