Cyber Resilience Act : ce qui change pour les éditeurs de logiciels

Vendredi, 17 h 40. Un client vous écrit : une faille d’un composant que vous embarquez depuis trois ans est en train d’être exploitée, chez lui. Votre équipe bascule en mode correctif. Jusqu’ici, la question était technique. Depuis le 11 septembre 2026, elle est aussi réglementaire : un compteur de 24 heures a démarré.

Bonne nouvelle : les obligations qui viennent d’entrer en vigueur sont d’abord des obligations d’organisation. Un contact de sécurité, un inventaire à jour, un circuit de décision clair, et vous êtes prêt. Voici ce qui change, ce qui attendra décembre 2027, et les chantiers à lancer maintenant.

Le CRA en trois dates

Le Cyber Resilience Act (règlement UE 2024/2847) s’applique par paliers.

• 11 septembre 2026 : les obligations de signalement de l’article 14 sont en vigueur.
• 11 décembre 2027 : les exigences de sécurité des produits et le marquage CE s’appliquent.
• Aujourd’hui : les deux chantiers avancent en parallèle, parce que le second se prépare sur douze mois, pas sur quinze jours.

À retenir

Le CRA porte sur les produits. NIS2 porte sur les organisations qui exploitent des services critiques. Une entreprise relève des deux, pour des raisons différentes : les deux textes se complètent, ils ne se remplacent pas.

Êtes-vous concerné ?

Le texte vise le fabricant, c’est-à-dire l’entité qui conçoit, développe ou fait fabriquer un produit comportant des éléments numériques et le met sur le marché européen sous son nom. Un éditeur de logiciels entre pleinement dans cette définition.

Trois précisions utiles.

Le lieu du siège ne protège de rien. Le règlement s’applique à quiconque met un produit numérique sur le marché de l’Union, quel que soit le pays d’établissement. Vos concurrents américains sont logés à la même enseigne que vous.

Le SaaS pur reste en dehors du périmètre direct. Dès qu’un composant est téléchargé ou installé chez le client, le produit entre dans le champ : une plateforme cloud accompagnée d’une application mobile est concernée pour sa partie applicative. Agent de supervision, connecteur on-premise, extension navigateur, SDK distribué à vos clients : la frontière se déplace vite. La qualification se fait produit par produit, avec votre conseil juridique, car les interprétations divergent encore d’un cabinet à l’autre.

L’open source commercial est concerné. Les logiciels open source fournis hors activité commerciale restent exclus, mais facturer le support, vendre une édition entreprise à côté d’une version gratuite ou distribuer des composants au sein de produits commerciaux sont des indices d’activité commerciale.

Ce qui s’applique depuis le 11 septembre 2026

L’obligation est simple à énoncer et exigeante à tenir. Les fabricants notifient à l’ENISA et aux CSIRT nationaux les vulnérabilités activement exploitées et les incidents graves : alerte précoce sous 24 heures, notification complète sous 72 heures, rapport final sous 14 jours ou un mois.

Trois points méritent l’attention.

Un canal unique. Le signalement passe par la plateforme de signalement de l’ENISA : le fabricant déclare une fois, et l’information est routée vers les CSIRT nationaux concernés. En France, le CERT-FR de l’ANSSI assure la coordination.

Le parc existant est inclus. Les règles de signalement couvrent l’ensemble des produits disponibles sur le marché européen, y compris les versions publiées avant septembre 2026. Une version installée chez un client il y a quatre ans et toujours en production entre dans le périmètre.

Un allègement, pas une exemption. Les microentreprises et les petites entreprises ne peuvent pas être sanctionnées pour le seul dépassement du délai de 24 heures de l’alerte précoce. L’obligation de signaler, elle, demeure.

Côté sanctions, le manquement expose à des amendes pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial.

Les cinq chantiers à mettre en place

Le délai de 24 heures ne se décrète pas le jour de l’incident. Il se prépare.

1. Un contact de sécurité identifié

Une adresse dédiée, publiée, relevée en dehors des heures de bureau, et un fichier security.txt sur vos domaines. C’est par là qu’arrivent les signalements de vos clients, des chercheurs et des CERT.

2. Un inventaire logiciel à jour (SBOM)

L’obligation documentaire de SBOM prend effet en décembre 2027, mais identifier sous 24 heures une exploitation active touchant un composant tiers suppose de disposer dès maintenant d’une nomenclature à jour. Sans inventaire, vous perdez la première demi-journée à chercher qui embarque quoi, et dans quelle version.

3. Un circuit de tri et de qualification

Qui décide qu’une vulnérabilité est activement exploitée ? Qui rédige l’alerte ? Qui la transmet ? Un logigramme d’une page, validé et testé une fois à blanc, vaut mieux qu’une procédure de trente pages jamais ouverte.

4. De la traçabilité

Journaux centralisés, horodatés, conservés : c’est ce qui permet de démontrer l’exploitation, d’en délimiter l’ampleur et de nourrir le rapport final à 14 jours. C’est aussi ce que vos clients vous demanderont pour leur propre analyse.

5. Une capacité à corriger vite

Signaler ne suffit pas. Un correctif d’urgence se prépare : environnement de recette, sauvegardes fraîches, procédure de retour arrière, fenêtre de déploiement documentée. C’est la partie la plus opérationnelle du sujet, et celle qui se joue sur votre infrastructure. Si vous avez un doute sur ce dernier point, faites le point avec un ingénieur HostMe.

À retenir

Quatre de ces cinq chantiers reposent sur votre organisation et votre infrastructure, pas sur votre code. C’est la bonne nouvelle : ils se mettent en place en quelques semaines.

Décembre 2027 : le second palier

Le 11 décembre 2027, les exigences de fond entrent en scène : sécurité dès la conception, absence de vulnérabilités connues au moment de la mise sur le marché, mises à jour de sécurité pendant la période de support, documentation technique et marquage CE.

La grande majorité des produits relève de la catégorie par défaut, avec une auto-évaluation documentée. Les produits dits importants des classes I et II, comme les systèmes d’exploitation, les routeurs ou les gestionnaires de mots de passe, passent par un organisme notifié. Pour la quasi-totalité des éditeurs TPE et PME, l’autodéclaration de conformité suffira, les exigences de sécurité restant obligatoires à cette date.

Autrement dit : douze mois pour documenter ce que vous faites déjà, et combler ce qui manque.

Ce que votre hébergeur porte avec vous

Un éditeur ne sous-traite pas sa conformité. Il s’appuie, en revanche, sur une infrastructure qui produit les preuves et tient les délais. Chez HostMe, cela prend une forme concrète.

• Supervision 24h/24 et 7j/7 : la détection d’un comportement anormal ne dépend pas de la disponibilité de votre équipe un vendredi soir.
• Journalisation et conservation : les traces dont vous avez besoin pour qualifier une exploitation et alimenter votre rapport final.
• Sauvegardes testées et PRA intégré : déployer un correctif d’urgence devient une opération maîtrisée, avec un retour arrière possible.
• Infrastructure certifiée ISO 27001, hébergée en France : la réponse est prête quand vos clients vous envoient leur questionnaire sécurité, sujet qui monte en puissance avec NIS2.
• Des experts joignables : pendant les 24 premières heures, vous avez besoin d’un interlocuteur, pas d’un ticket.

C’est le choix qu’a fait Newmips, éditeur d’une plateforme de développement bas-code, en s’appuyant sur une infrastructure souveraine et des briques open source opérées par nos équipes.

Par où commencer cette semaine

• Qualifiez vos produits : lesquels sont distribués, installés ou intégrés chez vos clients ?
• Publiez un contact de sécurité et un fichier security.txt.
• Constituez ou mettez à jour la SBOM de votre produit principal.
• Écrivez le logigramme 24 h / 72 h / 14 jours et nommez les responsables.
• Vérifiez que vos journaux, vos sauvegardes et votre procédure de correctif d’urgence tiennent la charge d’un vendredi soir. Notre diagnostic gratuit couvre précisément ces trois points.
• Faites un exercice à blanc avant la fin du trimestre.

À retenir

Le CRA transforme la rapidité de signalement en critère contractuel. Vos clients vont vous poser la question. Autant y répondre avec un processus écrit et une infrastructure qui suit.

Faisons le point sur votre infrastructure

Vous vous demandez si votre hébergement actuel vous permet de tenir un délai de 24 heures, de produire les traces attendues et de déployer un correctif sans interruption de service ?

Demandez votre diagnostic gratuit : 30 minutes avec un ingénieur HostMe, un état des lieux de votre infrastructure, de vos dépendances et de votre capacité de réaction, et un compte rendu écrit. Sans engagement.

Cet article présente les grandes lignes du règlement. La qualification exacte de vos produits relève d’une analyse juridique, que nous vous invitons à mener avec votre conseil.