Cyber Resilience Act : ce que ça impose aux éditeurs logiciels

Le règlement européen sur la cyberrésilience est entré en vigueur le 10 décembre 2024. Depuis, il vit surtout dans des slides de conformité, quelque part entre le RGPD et NIS2, et rarement dans le backlog d'une équipe de développement.

Une société qui publie un logiciel vendu dans l'Union y est pourtant désignée par un mot précis : fabricant. Le même mot que pour un constructeur de caméras connectées.

Le texte est écrit en langage produit industriel : mise sur le marché, marquage CE, évaluation de conformité, documentation technique, organisme notifié. On ouvre le PDF, on lit trois pages de vocabulaire d'usine, et on en conclut que le sujet appartient à un autre métier.

Cet article fait la traduction dans l'autre sens : ce que chaque exigence demande à une équipe qui écrit du code, avec les commandes, les fichiers, les délais et les articles correspondants du règlement. Les exemples sont en Python et en Node.js.

Le mot qui décide de tout : fabricant

Le règlement (UE) 2024/2847, dit Cyber Resilience Act ou CRA, s'applique aux produits comportant des éléments numériques mis à disposition sur le marché de l'Union. La définition officielle couvre un produit logiciel ou matériel et ses solutions de traitement de données à distance, y compris les composants mis sur le marché séparément.

Le mot logiciel est là, seul, sans matériel autour. Un ERP installé chez le client, une application desktop, un firmware, une extension de navigateur, une bibliothèque distribuée commercialement : tout ça entre dans la même catégorie juridique qu'un thermostat connecté.

Le fabricant est la personne physique ou morale qui développe le produit, ou le fait développer, et le commercialise sous son nom ou sa marque. La formulation officielle précise : que ce soit contre paiement, contre monétisation ou à titre gratuit. Distribuer gratuitement ne sort donc pas du périmètre, dès lors qu'il y a activité commerciale.

Six cas, six réponses

Un cas de bascule mérite d'être connu des sociétés qui revendent le logiciel d'un tiers. L'article 21 prévoit qu'un importateur ou un distributeur qui met un produit sur le marché sous son propre nom ou sa propre marque, ou qui lui apporte une modification substantielle, endosse l'ensemble des obligations du fabricant. La marque blanche fait donc changer de statut, avec la documentation technique et le signalement qui vont avec.

La ligne du backend mérite un arrêt. La notion de traitement de données à distance vise le service conçu par le fabricant, ou sous sa responsabilité, dont l'absence empêcherait le produit d'assurer une de ses fonctions. Une application mobile qui perd son authentification, sa synchronisation ou son moteur de recherche quand l'API tombe embarque donc son backend dans le périmètre réglementaire.

L'article 2 pose six familles d'exclusions, toutes sectorielles. Les dispositifs médicaux et les dispositifs de diagnostic in vitro couverts par les règlements 2017/745 et 2017/746, les véhicules à moteur relevant du règlement 2019/2144, les produits certifiés au titre du règlement aviation civile 2018/1139, les équipements marins relevant de la directive 2014/90, les pièces détachées identiques fabriquées selon les mêmes spécifications que le composant remplacé, et les produits développés ou modifiés exclusivement à des fins de sécurité nationale ou de défense, y compris ceux conçus pour traiter des informations classifiées. Un acte délégué de juillet 2025, le règlement (UE) 2025/1535, a par ailleurs sorti certains véhicules à deux ou trois roues du champ d'application.

Le piège de ces exclusions vaut d'être signalé. Elles couvrent le produit dans les limites de ce que régit l'autre texte, et s'arrêtent là. L'application compagnon d'un dispositif médical, l'outil de configuration livré à côté, le portail de télémaintenance : ces éléments relèvent souvent du CRA pour leur propre compte. Un logiciel de gestion d'entreprise, lui, n'a aucune exclusion à invoquer.

Les trois dates du calendrier

Le règlement s'applique par paliers, prévus à l'article 71. Beaucoup d'équipes ont retenu décembre 2027 et rangé le sujet. La date opposable la plus proche est ailleurs.

11 juin 2026. Le chapitre IV est entré en application. Les États membres devaient désigner leurs autorités notifiantes, ce qui ouvre la mise en place des organismes notifiés. Aucune obligation directe pour un éditeur, mais c'est la date à partir de laquelle la capacité d'audit européenne se construit, avec une file d'attente qui se remplira à mesure que 2027 approche.

11 septembre 2026. Les obligations de signalement de l'article 14 s'appliquent. Toute vulnérabilité activement exploitée et tout incident grave affectant la sécurité du produit doivent être notifiés. Point critique que beaucoup ratent : ces obligations couvrent l'ensemble des produits mis à disposition sur le marché de l'Union, y compris ceux déjà commercialisés avant décembre 2027. La version 4.2 livrée en 2023 et toujours installée chez trente clients entre dans le champ.

11 décembre 2027. Le reste : exigences essentielles de l'annexe I, évaluation de conformité, déclaration UE de conformité, marquage CE, documentation technique. Les produits mis sur le marché avant cette date n'y sont soumis que s'ils font l'objet d'une modification substantielle après. Pour du logiciel qui livre toutes les six semaines, cette exception a une durée de vie courte.

Entre les deux, le travail de normalisation continue. La demande M/606, adoptée par la décision d'exécution C(2025) 618 du 3 février 2025 et acceptée par le CEN, le CENELEC et l'ETSI le 3 avril 2025, porte sur 41 normes harmonisées, horizontales et sectorielles. Une fois leurs références citées au Journal officiel de l'Union, elles ouvriront la présomption de conformité prévue à l'article 27. À la mi-août 2026, aucune n'y figure encore : cette présomption n'est donc ouverte pour aucune catégorie de produit.

L'ANSSI le rappelle dans sa foire aux questions consacrée au CRA : la conformité ne dépend pas de la disponibilité des normes. Aucune norme n'est obligatoire, leur usage reste volontaire, et tout autre moyen de démontrer le respect des exigences est recevable. L'annexe I exprime des résultats à atteindre, pas des recettes techniques.

Côté français, la répartition des rôles est fixée. L'ANSSI est l'autorité notifiante, chargée d'évaluer, de contrôler et de notifier les organismes d'évaluation de la conformité, accrédités au niveau national. La surveillance du marché revient à l'ANFR, avec l'appui technique de l'ANSSI. Et le CERT-FR, CSIRT de l'ANSSI, est le coordinateur national qui reçoit les signalements.

Le principe : un régime de sécurité produit

Trois textes européens se croisent souvent dans les mêmes réunions, et ils ne visent pas la même chose. Le RGPD encadre le traitement des données personnelles. NIS2 encadre le niveau de sécurité des organisations essentielles et importantes. Le CRA encadre les produits, leur conception, leur maintenance, leur documentation.

Cette différence a une conséquence de méthode. Le CRA reprend la mécanique du marquage CE utilisée pour les jouets, les machines ou les équipements électriques. Un produit ne peut être mis sur le marché que si le fabricant a démontré qu'il satisfait des exigences essentielles, l'a écrit dans une documentation technique, a signé une déclaration UE de conformité et a apposé le marquage CE. La conformité se démontre par des pièces écrites et datées.

Annexe I, deux parties

L'annexe I se lit en deux blocs. La partie I porte sur les propriétés du produit : ce qu'il doit être au moment où il est mis sur le marché. La partie II porte sur le traitement des vulnérabilités : ce que le fabricant doit faire pendant toute la période de support.

La partie I demande un produit conçu et développé de façon à assurer un niveau de cybersécurité approprié au risque, livré sans vulnérabilité exploitable connue, avec une configuration sécurisée par défaut et la possibilité de revenir à cet état d'origine. Elle demande aussi une protection contre les accès non autorisés, la protection de la confidentialité et de l'intégrité des données par des mécanismes à l'état de l'art, la minimisation des données traitées, la réduction de la surface d'attaque, la limitation de l'impact d'un incident, la journalisation des activités internes pertinentes, et la possibilité de supprimer ses données et ses réglages.

La partie II demande d'identifier et de documenter les composants et les vulnérabilités, dont un SBOM, de corriger sans délai indu, de tester régulièrement, de publier des informations sur les correctifs, de tenir une politique de divulgation coordonnée, de faciliter le signalement externe des failles, et de diffuser les mises à jour de sécurité de façon sécurisée et gratuite.

Un point de souplesse existe sur la publication. Quand le fabricant estime, dans un cas dûment justifié, que les risques de sécurité liés à la publication l'emportent sur ses bénéfices, il peut retarder la diffusion publique des informations sur une vulnérabilité corrigée jusqu'à ce que les utilisateurs aient eu la possibilité d'appliquer le correctif. Cette marge sert à laisser le temps du déploiement, et le texte la conditionne à une justification.

Qui évalue la conformité

Par défaut, le fabricant s'auto-évalue, avec la procédure de contrôle interne du module A. La grande majorité des logiciels de gestion, des applications métier et des outils internes vendus à des tiers relèvent de ce régime. Une auto-évaluation reste une évaluation : elle produit un dossier qu'une autorité de surveillance peut réclamer.

Les produits listés aux annexes III et IV sortent de ce régime. Un produit important de classe I peut encore s'auto-évaluer, à condition d'appliquer des normes harmonisées, des spécifications communes ou un schéma européen de certification. Les produits importants de classe II et les produits critiques passent obligatoirement par un organisme notifié ou par un tel schéma. Une exception vise les logiciels libres relevant des classes I et II : leurs fabricants gardent l'auto-évaluation s'ils rendent la documentation technique publique.

La liste de l'annexe III mérite une lecture attentive dans toute équipe qui édite du logiciel d'infrastructure. Relèvent de la classe I : la gestion des identités et des accès à privilèges, les navigateurs autonomes ou embarqués, les gestionnaires de mots de passe, les logiciels de recherche et de suppression de code malveillant, les produits assurant une fonction de VPN, les systèmes de gestion de réseau, les SIEM, les gestionnaires d'amorçage, les infrastructures à clés publiques, les systèmes d'exploitation, les routeurs, modems et commutateurs. Relèvent de la classe II : les hyperviseurs et moteurs d'exécution de conteneurs, les pare-feu, les systèmes de détection et de prévention d'intrusion. Les descriptions techniques de ces catégories ont été précisées par le règlement d'exécution (UE) 2025/2392 du 28 novembre 2025.

Les sanctions

L'article 64 fixe trois niveaux, le montant retenu étant le plus élevé des deux termes.

• Jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial, pour un manquement aux exigences essentielles de l'annexe I ou aux obligations des articles 13 et 14.
• Jusqu'à 10 millions d'euros ou 2 %, pour les autres obligations, dont celles des importateurs et des distributeurs.
• Jusqu'à 5 millions d'euros ou 1 %, pour la fourniture d'informations inexactes, incomplètes ou trompeuses aux autorités ou aux organismes notifiés.

Une contrepartie existe pour les plus petites structures. L'article 33 prévoit que les microentreprises et les petites entreprises peuvent fournir tous les éléments de la documentation technique de l'annexe VII dans un format simplifié, dont la Commission doit préciser la forme par acte d'exécution, et que les organismes notifiés sont tenus d'accepter. Le contenu ne rétrécit pas, la mise en forme oui. À la mi-2026, ce formulaire n'était pas encore publié : structurer son dossier en suivant l'ordre de l'annexe VII reste la façon la plus sûre de pouvoir le transposer ensuite. Le même article autorise les États membres à ouvrir des bacs à sable réglementaires.

Deux aménagements existent aussi du côté des sanctions, et ils sont peu connus. Les microentreprises et les petites entreprises ne peuvent pas être sanctionnées financièrement pour un dépassement des délais de 24 heures, ceux de l'alerte précoce sur une vulnérabilité exploitée comme sur un incident grave. Les dépositaires de logiciels libres au sens de l'article 24 ne sont pas soumis à ces amendes. L'obligation de signaler reste entière dans les deux cas, seule la sanction du retard tombe.

Le pourcentage se calcule sur le chiffre d'affaires annuel mondial de l'exercice précédent, et le montant retenu est le plus élevé entre la somme fixe et le pourcentage. Pour une société de vingt personnes, c'est le plafond en euros qui sert de référence, le pourcentage restant très en dessous. Les autorités doivent par ailleurs tenir compte de la nature et de la durée de l'infraction, des sanctions déjà prononcées et de la taille de l'entreprise.

Les exigences traduites en travail de développement

Voici la partie utile. Chaque exigence de l'annexe I est reprise ici avec sa traduction dans un dépôt de code.

1. L'évaluation de risque, point de départ obligatoire

L'article 13 impose une évaluation des risques de cybersécurité, prise en compte à la planification, à la conception, au développement, à la production, à la livraison et à la maintenance. Elle doit figurer dans la documentation technique.

Un tableau de dix lignes versionné dans le dépôt suffit pour commencer, à condition qu'il soit relu à chaque évolution majeure. Utilisation prévue, utilisation détournée raisonnablement prévisible, actifs à protéger, menaces, mesure retenue, exigence de l'annexe I couverte. Un fichier docs/risk-assessment.md passé en revue de code force la mise à jour quand l'architecture bouge, ce qu'un document sur un partage réseau ne fait jamais.

Deux précisions du texte sont souvent ratées. L'évaluation doit être mise à jour pendant toute la période de support, et pas figée au moment de la première mise sur le marché. Elle doit aussi indiquer si les exigences de l'annexe I partie I point 2 s'appliquent au produit, et de quelle façon elles sont mises en oeuvre. Quand une exigence ne s'applique pas, l'article 13(4) demande une justification claire dans la documentation technique : écrire qu'une exigence est hors sujet est permis, le faire sans motif ne l'est pas.

2. Livrer sans vulnérabilité exploitable connue

L'annexe I partie I demande un produit mis sur le marché sans vulnérabilité exploitable connue. Cette phrase, appliquée à un projet Node.js de 900 dépendances transitives, se traduit par une porte automatique dans le pipeline plutôt que par une bonne intention.

Côté Python :

pip install pip-audit
pip-audit --strict --format json --output pip-audit.json
 
# variante avec la base OSV, qui couvre plusieurs écosystèmes
osv-scanner scan source -r .

Côté Node.js :

npm audit --audit-level=high --omit=dev
 
# installation reproductible, indispensable pour que l'audit ait un sens
npm ci

Une précision sur ces commandes, vérifiée en les exécutant : pip-audit sort déjà avec un code non nul quand il trouve une vulnérabilité, l'option --strict ajoute l'échec quand une dépendance n'a pas pu être auditée du tout. Les deux comportements sont souhaitables en intégration continue, pour des raisons différentes : le premier bloque une faille connue, le second bloque un angle mort.

Le mot exploitable a son importance. Une alerte sur une dépendance de développement qui ne part jamais en production ne relève pas de la même urgence qu'une faille dans la couche HTTP exposée. Ce tri s'écrit, il ne s'improvise pas : le fichier qui justifie une exception fait partie du dossier technique, avec la date et la personne qui a tranché.

Une obligation passe souvent inaperçue. Quand un fabricant identifie une vulnérabilité dans un composant intégré, y compris un composant open source, l'article 13(6) lui impose de la signaler à la personne ou à l'entité qui développe ou maintient ce composant. S'il a produit un correctif, il doit partager le code ou la documentation associée avec elle, si possible dans un format lisible par machine. Le règlement fait remonter la correction vers l'amont au lieu de la laisser dans un fork privé.

3. Configuration sécurisée par défaut, et retour à l'état d'origine

Le règlement demande une configuration sécurisée par défaut, avec la possibilité de réinitialiser le produit à cet état. En pratique, ça élimine les comptes admin/admin, les clés de signature en dur dans le dépôt, les modes debug qui restent activés en production et les options de chiffrement désactivées par confort d'installation. Une seule dérogation figure au texte, pour un produit sur mesure fourni à un utilisateur professionnel qui en convient autrement avec le fabricant.

Une application qui refuse de démarrer quand un secret n'est pas fourni transforme cette exigence en propriété vérifiable. En Python, avec pydantic-settings :

from pydantic import Field, SecretStr
from pydantic_settings import BaseSettings
 
 
class Settings(BaseSettings):
    # aucune valeur par defaut : l'absence de secret bloque le demarrage
    secret_key: SecretStr = Field(min_length=32)
    database_url: SecretStr
 
    # les defauts sont les valeurs sures, pas les valeurs pratiques
    debug: bool = False
    require_tls: bool = True
    session_cookie_secure: bool = True
    allowed_hosts: list[str] = ["localhost"]
    audit_log_enabled: bool = True
 
 
settings = Settings()  # leve une erreur explicite si la config est incomplete

L'équivalent en Node.js, sans dépendance :

import express from 'express';
import helmet from 'helmet';
import session from 'express-session';
 
const REQUIRED = ['SESSION_SECRET', 'DATABASE_URL', 'ENCRYPTION_KEY'];
 
const missing = REQUIRED.filter((key) => !process.env[key]);
if (missing.length > 0) {
  console.error(`Demarrage refuse. Variables manquantes : ${missing.join(', ')}`);
  process.exit(1);
}
 
if (process.env.SESSION_SECRET.length < 32) {
  console.error('SESSION_SECRET trop court, 32 caracteres minimum.');
  process.exit(1);
}
 
const app = express();
 
app.use(helmet());
app.use(
  session({
    secret: process.env.SESSION_SECRET,
    resave: false,
    saveUninitialized: false,
    cookie: { httpOnly: true, secure: true, sameSite: 'lax' },
  })
);

Deux détails d'exécution, constatés en lançant ce code : sans resave ni saveUninitialized, express-session affiche deux avertissements de dépréciation au démarrage. Et secure: true empêche l'envoi du cookie en HTTP simple, ce qui est le comportement voulu et surprend en développement local : il faut un proxy TLS ou une configuration distincte pour cet environnement.

La partie réinitialisation est souvent oubliée. Le produit doit offrir un moyen de revenir à son état d'origine et de supprimer les données et réglages de l'utilisateur. Pour un logiciel installé, ça veut dire une procédure documentée qui remet la configuration à zéro sans réinstallation complète, et un désinstallateur qui nettoie autre chose que le répertoire des binaires.

4. Le mécanisme de mise à jour, exigence de conception

L'annexe I partie I demande que les vulnérabilités puissent être corrigées par des mises à jour de sécurité et, lorsque c'est applicable, que ces mises à jour s'installent automatiquement dans un délai approprié, cette installation automatique étant activée par défaut. Trois contreparties accompagnent cette règle : un mécanisme de désactivation clair et simple d'usage, la notification des mises à jour disponibles, et la possibilité pour l'utilisateur de les reporter temporairement.

Pour un éditeur, cette exigence touche l'architecture du produit et se décide tôt. Un logiciel desktop distribué par une archive ZIP et mis à jour à la main par un administrateur système ne satisfait pas cette attente, sauf à démontrer dans l'évaluation de risque pourquoi la mise à jour automatique n'est pas applicable au produit et à son environnement, ce que l'article 13(4) permet à condition de le justifier.

5. Confidentialité et intégrité par des mécanismes à l'état de l'art

L'annexe I ne cite aucun algorithme, aucune taille de clé, aucune version de protocole. Elle renvoie à l'état de l'art, ce qui déplace la charge de la preuve : c'est au fabricant de montrer que ses choix étaient raisonnables à la date de conception, et de les réviser. Un produit qui hachait encore les mots de passe en SHA-1 en 2027 aurait du mal à défendre son dossier.

from argon2 import PasswordHasher
from argon2.exceptions import VerifyMismatchError
 
ph = PasswordHasher()  # Argon2id, parametres par defaut de la bibliotheque
 
 
def hash_password(plain: str) -> str:
    return ph.hash(plain)
 
 
def verify_password(stored_hash: str, plain: str) -> str | None:
    """Retourne un nouveau hash si les parametres doivent etre remontes.
 
    None signifie : mot de passe valide, rien a reecrire en base.
    Une exception VerifyMismatchError signifie : mot de passe invalide.
    """
    ph.verify(stored_hash, plain)  # leve VerifyMismatchError si invalide
    if ph.check_needs_rehash(stored_hash):
        # remonter les parametres fait partie de la maintenance de securite
        return ph.hash(plain)
    return None

La ligne intéressante est check_needs_rehash. L'état de l'art bouge, un produit maintenu cinq ans doit pouvoir migrer ses paramètres cryptographiques sans casser les comptes existants. Cette capacité se conçoit dès le départ, la greffer après coup coûte cher.

6. Minimisation des données et journalisation

Deux exigences voisines qui se contredisent si on ne fait pas attention. Le produit doit traiter le minimum de données nécessaires, et il doit enregistrer et surveiller les activités internes pertinentes, dont les accès et modifications des données, services et fonctions, avec une possibilité de désactivation pour l'utilisateur.

La sortie de cette contradiction apparente est un journal d'audit structuré, séparé des logs applicatifs, qui enregistre des identifiants et des actions plutôt que des contenus.

import json
import logging
from datetime import UTC, datetime
 
audit = logging.getLogger("audit")
 
 
def log_access(actor_id: str, action: str, resource: str, outcome: str) -> None:
    """Journal d'audit CRA : qui, quoi, sur quoi, avec quel resultat.
 
    Aucun contenu metier, aucune donnee personnelle au-dela de l'identifiant
    technique. Le journal sert a reconstituer une chronologie, pas a archiver
    les donnees des utilisateurs.
    """
    if not settings.audit_log_enabled:
        return
    audit.info(
        json.dumps(
            {
                "ts": datetime.now(UTC).isoformat(),
                "actor": actor_id,
                "action": action,        # read, update, delete, export, login
                "resource": resource,    # invoice:4821, user:112
                "outcome": outcome,      # granted, denied, error
            }
        )
    )

Le pendant en Node.js consiste à empêcher les secrets de finir dans les logs applicatifs, ce qui arrive à peu près partout où un intergiciel journalise les en-têtes bruts :

const SENSITIVE = new Set(['authorization', 'cookie', 'x-api-key', 'set-cookie']);
 
function safeHeaders(headers) {
  return Object.fromEntries(
    Object.entries(headers).map(([key, value]) => [
      key,
      SENSITIVE.has(key.toLowerCase()) ? '[redacted]' : value,
    ])
  );
}
 
app.use((req, _res, next) => {
  logger.info({
    method: req.method,
    path: req.path,
    headers: safeHeaders(req.headers),
  });
  next();
});

Le sujet de la surface d'attaque minimale et du moindre privilège relève de la même famille d'exigences. Un service qui tourne en root, un compte de base de données qui peut supprimer des tables alors qu'il ne fait que des lectures, un jeton d'API qui donne tous les droits pour trois appels : le règlement demande de limiter l'impact d'un incident, et c'est exactement ce que fait ce principe. Le sujet est traité en détail dans notre article sur le principe de moindre privilège.

7. La période de support, décision commerciale devenue obligation

L'article 13 impose de déterminer une période de support qui reflète la durée d'utilisation attendue du produit, avec un plancher de cinq ans, sauf si le produit est destiné à être utilisé moins longtemps. Pour un superviseur industriel ou un logiciel de gestion déployé sur site, la durée réelle dépasse souvent dix ans, et la période de support doit suivre.

Pendant cette période, les vulnérabilités doivent être traitées, et les mises à jour de sécurité fournies gratuitement. La date de fin, mois et année, doit être indiquée clairement au moment de l'achat, dans les informations à l'utilisateur de l'annexe II.

Cette exigence a une conséquence directe sur la stratégie de branches. Maintenir une correction de sécurité sur une version publiée il y a quatre ans suppose qu'elle soit encore compilable et livrable. Une équipe qui ne garde que la branche principale et détruit ses branches de version découvre le coût de cette promesse au premier CVE critique sur une ancienne majeure.

Le règlement ouvre toutefois une seconde voie pour le logiciel. Quand un éditeur a mis sur le marché des versions successives substantiellement modifiées, l'article 13(10) l'autorise à n'assurer la correction des vulnérabilités que sur la dernière version mise sur le marché, à deux conditions cumulatives : les utilisateurs des versions antérieures y accèdent gratuitement, et ils ne supportent aucun coût d'adaptation de l'environnement matériel et logiciel dans lequel ils utilisaient la version d'origine. Une migration facturée, ou qui impose de changer de serveur ou de base de données, ne remplit pas ces conditions.

Deux règles de conservation s'ajoutent, et elles surprennent les équipes qui purgent leurs artefacts. Chaque mise à jour de sécurité diffusée pendant la période de support doit rester disponible au moins dix ans après sa publication, ou jusqu'à la fin de la période de support si celle-ci va au-delà (article 13(9)). La documentation technique et la déclaration UE de conformité suivent la même logique : à disposition des autorités de surveillance pendant au moins dix ans après la mise sur le marché, ou pendant toute la période de support si elle est plus longue (article 13(13)).

Deux obligations de contact terminent ce bloc. Quand c'est techniquement possible, le produit doit afficher une notification informant l'utilisateur que la période de support est arrivée à son terme. Et le fabricant doit désigner un point de contact unique, facilement identifiable, permettant aux utilisateurs de le joindre directement et rapidement, notamment pour signaler une vulnérabilité. L'article 13(17) précise que ce point de contact laisse à l'utilisateur le choix du moyen de communication et ne peut pas se limiter à des outils automatisés : un chatbot seul ne suffit pas.

Le SBOM, première obligation légale de ce type

L'annexe I partie II, point 1, demande d'identifier et de documenter les vulnérabilités et les composants du produit, notamment en établissant une nomenclature logicielle dans un format couramment utilisé et lisible par machine, couvrant au minimum les dépendances de premier niveau. C'est le passage qui fait du SBOM une obligation juridique et plus une bonne pratique recommandée par un référentiel.

Deux formats dominent : CycloneDX, porté par l'OWASP, et SPDX, porté par la Linux Foundation. Les deux répondent à l'exigence. CycloneDX est plus répandu côté outillage applicatif, SPDX côté licences et distributions.

Générer le SBOM

# Python : depuis l'environnement virtuel reellement installe
pip install cyclonedx-bom
cyclonedx-py environment --output-format JSON --output-file sbom.json
 
# variante a partir d'un requirements fige
python -m pip freeze | cyclonedx-py requirements -
 
# Node.js
npx @cyclonedx/cyclonedx-npm --omit dev --output-file sbom.json

Un point de méthode qui change tout : le SBOM doit être produit par le pipeline, à partir de ce qui est réellement livré, et archivé avec l'artefact correspondant. Un SBOM généré à la main depuis le poste d'un développeur décrit son environnement, pas le produit installé chez le client.

Extrait de ce que produit CycloneDX, réduit à un composant :

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:8f2b...",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "requests",
      "version": "2.32.3",
      "purl": "pkg:pypi/requests@2.32.3",
      "licenses": [{ "license": { "id": "Apache-2.0" } }]
    }
  ]
}

Le champ purl est la clé de voûte. C'est lui qui permet d'interroger automatiquement les bases de vulnérabilités.

Deux points à garder en tête. La Commission peut, par acte d'exécution, préciser le format et les éléments attendus du SBOM (article 13(24)), donc le choix fait aujourd'hui pourra demander un ajustement. Et les autorités de surveillance du marché peuvent réclamer les SBOM des fabricants dans le cadre d'une évaluation des dépendances menée à l'échelle de l'Union (article 13(25)). Ce fichier a le statut d'une pièce communicable, ce qui vaut la peine d'être su avant d'y laisser un nom de dépôt interne ou un chemin de build parlant.

Exploiter le SBOM plutôt que l'archiver

Un SBOM produit puis oublié coche une case et ne sert à rien le jour où une faille tombe. Sa valeur apparaît quand on peut répondre en quelques minutes à la question : est-ce que ce CVE touche une de mes versions livrées, et lesquelles. Le script suivant croise un SBOM avec la base OSV.

"""Croise un SBOM CycloneDX avec la base OSV.
 
Usage : python check_sbom.py sbom.json
Sortie : la liste des composants du produit pour lesquels une vulnerabilite
publique existe, avec les identifiants correspondants.
"""
 
import json
import sys
import urllib.request
from pathlib import Path
 
OSV_BATCH = "https://api.osv.dev/v1/querybatch"
 
 
def load_purls(path: Path) -> list[tuple[str, str, str]]:
    bom = json.loads(path.read_text(encoding="utf-8"))
    return [
        (c.get("name", "?"), c.get("version", "?"), c["purl"])
        for c in bom.get("components", [])
        if "purl" in c
    ]
 
 
def query_osv(purls: list[str]) -> list[dict]:
    payload = {"queries": [{"package": {"purl": purl}} for purl in purls]}
    request = urllib.request.Request(
        OSV_BATCH,
        data=json.dumps(payload).encode("utf-8"),
        headers={"Content-Type": "application/json"},
    )
    with urllib.request.urlopen(request, timeout=30) as response:
        return json.load(response).get("results", [])
 
 
def main(path: str) -> int:
    entries = load_purls(Path(path))
    results = query_osv([purl for _, _, purl in entries])
 
    touched = 0
    # strict=True : une reponse tronquee de l'API leve une erreur
    # au lieu de passer des composants sous silence
    for (name, version, _purl), result in zip(entries, results, strict=True):
        vulns = result.get("vulns", [])
        if vulns:
            touched += 1
            print(f"{name} {version} : {', '.join(v['id'] for v in vulns[:5])}")
 
    print(f"\n{touched} composant(s) concerne(s) sur {len(entries)} analyses.")
    return 1 if touched else 0
 
 
if __name__ == "__main__":
    sys.exit(main(sys.argv[1]))

Sur un SBOM volumineux, mieux vaut envoyer les composants par lots successifs plutôt qu'en une seule requête. Ce script tient en cinquante lignes et sans dépendance externe. Lancé sur les SBOM archivés de chaque version encore supportée, il répond à la question que posera un client au téléphone le jour où une faille fait la une, et il alimente directement le processus de signalement décrit plus bas.

Le signalement 24 h / 72 h / 14 jours

C'est l'obligation qui arrive en premier, le 11 septembre 2026, et celle qui demande le plus d'organisation humaine pour le moins de code.

Ce qui déclenche une notification

Deux événements, et deux seulement. Une vulnérabilité activement exploitée affectant le produit. Un incident grave ayant une incidence sur la sécurité du produit. Une faille théorique découverte en revue de code, non exploitée, ne déclenche pas l'obligation de l'article 14. Elle relève du traitement de vulnérabilités de l'annexe I, avec ses propres délais de correction, ce qui n'est pas la même chose.

Le règlement définit l'incident grave à l'article 14(5). Un incident l'est quand il affecte négativement, ou peut affecter, la capacité du produit à protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité de données ou de fonctions sensibles ou importantes. Il l'est aussi quand il a conduit, ou peut conduire, à l'introduction ou à l'exécution de code malveillant dans le produit ou dans les systèmes d'un utilisateur. Cette seconde branche vise directement le scénario d'une chaîne de distribution compromise.

Le déclencheur est la connaissance du fait. L'horloge démarre au moment où le fabricant en a connaissance, pas au moment où il a terminé son analyse.

Où et à qui

La notification part simultanément vers le CSIRT désigné comme coordinateur et vers l'ENISA, via la plateforme unique de signalement prévue à l'article 16. Un dépôt unique, ensuite relayé aux CSIRT des autres États membres où le produit est disponible. Pour une société française, l'interlocuteur est le CERT-FR, CSIRT de l'ANSSI.

Le CSIRT compétent est celui de l'État membre où le fabricant a son établissement principal dans l'Union, défini par le règlement comme celui où les décisions relatives à la cybersécurité de ses produits sont majoritairement prises. Ce n'est donc pas nécessairement le siège social. Pour un fabricant sans établissement dans l'Union, l'article 14(7) fixe un ordre de rattachement : l'État du mandataire couvrant le plus de produits, sinon celui de l'importateur qui en met le plus sur le marché, sinon celui du distributeur, sinon celui où se trouve le plus grand nombre d'utilisateurs.

Le CSIRT qui reçoit la notification peut aussi demander un rapport intermédiaire sur l'évolution de la situation, entre les étapes prévues.

Le règlement prévoit aussi une voie volontaire : toute personne physique ou morale peut signaler une vulnérabilité, une menace, un incident ou un quasi-incident par ce même canal.

Prévenir les utilisateurs, pas seulement les autorités

L'article 14(8) ajoute une obligation qui échappe souvent à la lecture rapide. Après avoir eu connaissance d'une vulnérabilité activement exploitée ou d'un incident grave, le fabricant doit informer les utilisateurs concernés du produit, et le cas échéant l'ensemble de ses utilisateurs, ainsi que des mesures d'atténuation et de correction qu'ils peuvent appliquer. Le texte demande que cette information soit fournie, lorsque c'est approprié, dans un format structuré et lisible par machine, facilement traitable de façon automatique.

Le texte prévoit ce qui se passe en cas de silence : si le fabricant n'informe pas ses utilisateurs en temps utile, les CSIRT notifiés peuvent le faire à sa place lorsqu'ils le jugent proportionné et nécessaire. Une communication produite par une autorité à la place de l'éditeur est rarement celle que l'éditeur aurait écrite.

Ce qu'il faut avoir prêt avant l'échéance

Vingt-quatre heures, c'est un dimanche soir inclus. La partie technique de cette obligation est mineure comparée à la partie organisationnelle. Il faut une personne joignable, un droit de décider sans réunion, un accès à la plateforme créé et testé à l'avance, et un modèle rempli à 70 % au repos.

Mon avis sur l'ordre des priorités : le SBOM se met en place en une journée, la chaîne de décision met des semaines. C'est elle qu'il faut lancer en premier.

Le script suivant calcule les échéances et prépare le brouillon de l'alerte précoce à partir de l'horodatage de la découverte.

"""Prepare le dossier de signalement article 14 du CRA."""
 
from dataclasses import dataclass, field
from datetime import UTC, datetime, timedelta
 
 
@dataclass
class Signalement:
    produit: str
    versions_affectees: list[str]
    identifiant: str                 # CVE, GHSA ou reference interne
    exploitation_active: bool
    etats_membres: list[str] = field(default_factory=list)
    connu_le: datetime = field(default_factory=lambda: datetime.now(UTC))
 
    @property
    def echeances(self) -> dict[str, str]:
        return {
            "alerte_precoce_24h": (
                self.connu_le + timedelta(hours=24)
            ).isoformat(timespec="minutes"),
            "notification_72h": (
                self.connu_le + timedelta(hours=72)
            ).isoformat(timespec="minutes"),
            "rapport_final": "14 jours apres mise a disposition du correctif",
        }
 
    def alerte_precoce(self) -> str:
        etats = ", ".join(self.etats_membres) or "en cours d'identification"
        return (
            f"Produit : {self.produit}\n"
            f"Versions affectees : {', '.join(self.versions_affectees)}\n"
            f"Reference : {self.identifiant}\n"
            f"Exploitation active constatee : "
            f"{'oui' if self.exploitation_active else 'non'}\n"
            f"Etats membres ou le produit est disponible : {etats}\n"
            f"Connaissance du fait : "
            f"{self.connu_le.isoformat(timespec='minutes')}\n"
            f"Mesures immediates : (a completer)\n"
            f"Contact : security@exemple.fr"
        )
 
 
if __name__ == "__main__":
    s = Signalement(
        produit="Atlas ERP",
        versions_affectees=["6.2.0", "6.3.1", "7.0.0"],
        identifiant="CVE-2026-XXXXX",
        exploitation_active=True,
        etats_membres=["FR", "BE", "DE"],
    )
    print(s.alerte_precoce())
    print()
    for etape, date in s.echeances.items():
        print(f"{etape:22} {date}")

Publier un avis lisible par machine

Le règlement demande aussi de diffuser des informations sur les vulnérabilités corrigées, avec la description, l'impact et l'aide à la remédiation. Publier cet avis dans un format standard permet aux outils de tes clients de le consommer. Voici la production d'un avis au format OSV en Node.js.

import { writeFileSync } from 'node:fs';
 
const advisory = {
  schema_version: '1.9.0',
  id: 'ATLAS-2026-0007',
  // id et modified sont les deux seuls champs obligatoires du schema OSV
  modified: new Date().toISOString(),
  published: new Date().toISOString(),
  summary: "Contournement d'authentification sur l'API d'export",
  details:
    "Une requete forgee permet d'acceder aux exports d'un autre locataire. " +
    'Corrige en 7.0.4. Contournement temporaire : desactiver le module export.',
  severity: [{ type: 'CVSS_V3', score: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N' }],
  affected: [
    {
      package: { ecosystem: 'npm', name: '@exemple/atlas-server' },
      ranges: [
        { type: 'SEMVER', events: [{ introduced: '6.2.0' }, { fixed: '7.0.4' }] },
      ],
    },
  ],
  references: [
    { type: 'ADVISORY', url: 'https://exemple.fr/securite/atlas-2026-0007' },
    { type: 'FIX', url: 'https://github.com/exemple/atlas/commit/9a1c...' },
  ],
};
 
writeFileSync('advisory.json', JSON.stringify(advisory, null, 2));

Le canal d'entrée : security.txt

L'annexe I demande de faciliter le signalement des vulnérabilités par des tiers et de tenir une politique de divulgation coordonnée. Le fichier /.well-known/security.txt, défini par la RFC 9116, répond à la première partie en dix lignes.

Contact: mailto:security@exemple.fr
Expires: 2027-06-30T23:59:00.000Z
Canonical: https://exemple.fr/.well-known/security.txt
Encryption: https://exemple.fr/pgp-key.txt
Preferred-Languages: fr, en
Policy: https://exemple.fr/securite/divulgation-coordonnee
Acknowledgments: https://exemple.fr/securite/remerciements

La RFC n'impose que deux champs, Contact et Expires, et recommande une date d'expiration à moins d'un an pour forcer la relecture. Le reste est optionnel. Un fichier expiré est traité comme invalide par la plupart des outils qui le consomment.

La page pointée par Policy porte la politique de divulgation coordonnée : périmètre couvert, délai d'accusé de réception, délai de correction visé, engagement de ne pas poursuivre un chercheur de bonne foi. Sans cette page, une personne qui découvre une faille dans ton produit finit par écrire sur X, et tu apprends l'exploitation active en même temps que tes clients.

Le pipeline minimum, de bout en bout

Les exigences précédentes se rejoignent dans un seul endroit : la chaîne de build. Voici un workflow GitHub Actions qui couvre l'audit des dépendances, l'analyse statique, la génération du SBOM et l'attestation de provenance, pour un projet Node.js. La version Python change trois commandes.

name: release
 
on:
  push:
    tags: ['v*']
 
permissions:
  contents: read
  security-events: write
  id-token: write
  attestations: write
  artifact-metadata: write
 
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - name: Aucune vulnerabilite exploitable connue
        run: npm audit --audit-level=high --omit=dev
 
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: github/codeql-action/init@v4
        with:
          languages: javascript-typescript
          queries: security-extended
      - uses: github/codeql-action/analyze@v4
 
  build-et-sbom:
    needs: [audit, sast]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm run build
 
      - name: Generation du SBOM CycloneDX
        run: npx @cyclonedx/cyclonedx-npm --omit dev --output-file sbom.json
 
      - name: Attestation de provenance
        uses: actions/attest@v4
        with:
          subject-path: 'dist/**'
 
      - name: Attestation du SBOM, signee et liee a l'artefact
        uses: actions/attest@v4
        with:
          subject-path: 'dist/**'
          sbom-path: sbom.json
 
      - name: Archivage pour le dossier de conformite
        uses: actions/upload-artifact@v7
        with:
          name: conformite-${{ github.ref_name }}
          path: |
            sbom.json
            dist/**
          retention-days: 90

Les quatre-vingt-dix jours de rétention d'artefacts sont une limite de la plateforme, sans rapport avec les durées de conservation du règlement. La documentation technique et la déclaration UE de conformité doivent rester à disposition des autorités pendant au moins dix ans après la mise sur le marché, ou pendant toute la période de support si elle est plus longue, en application de l'article 13(13). Les binaires de mises à jour de sécurité relèvent d'une règle voisine à l'article 13(9). Le SBOM, les rapports de build et les artefacts livrés doivent donc être copiés vers un stockage durable, hors de l'outil de CI.

La deuxième étape d'attestation mérite un mot. actions/attest détecte son mode selon les entrées fournies : sans sbom-path, il génère une attestation de provenance SLSA ; avec un fichier SPDX ou CycloneDX, il produit une attestation de SBOM. Les deux ensemble donnent une chaîne vérifiable : voici comment l'artefact a été construit, et voici la liste de composants qui lui correspond, l'une et l'autre signées par Sigstore et rattachées au dépôt. Pour un dossier de conformité, la différence entre un SBOM posé dans un bucket et un SBOM signé lié à un binaire précis n'est pas mince.

Côté Python, les trois commandes remplacées :

- uses: actions/setup-python@v6
  with:
    python-version: '3.14'
- run: pip install -r requirements.txt
- run: pip-audit --strict
- run: cyclonedx-py environment --output-format JSON --output-file sbom.json

Si la mise en place de ce type de chaîne est nouvelle pour l'équipe, notre formation CI/CD avec GitHub Actions couvre les fondations : workflows, runners, secrets, environnements et déploiement. Le sujet de la reproductibilité du build, qui conditionne la fiabilité du SBOM, recoupe largement la méthode des douze facteurs.

Les pièges qui coûtent cher

Traiter septembre 2026 comme un sujet 2027

L'erreur la plus répandue. Les obligations de signalement s'appliquent à tous les produits déjà disponibles sur le marché, sans période de grâce et sans exemption pour les PME. Une entreprise de douze personnes qui vend un logiciel installé chez ses clients est concernée au même titre qu'un éditeur de mille salariés.

Croire que le produit est hors marché européen

La question n'est pas où se trouve l'éditeur, mais où le produit est mis à disposition. Un éditeur établi hors de l'Union qui vend en Europe par un revendeur relève du règlement, et son importateur porte des obligations propres : vérifier le marquage CE, la documentation technique, la présence d'un processus de traitement des vulnérabilités.

Générer le SBOM sans jamais l'interroger

Un fichier JSON produit à chaque release et déposé dans un bucket coche la case documentation et rate l'objectif. Sans veille automatique qui rejoue les identifiants de paquets contre une base de vulnérabilités, le SBOM ne raccourcit pas le délai de réaction, qui est précisément ce que le règlement cherche à obtenir.

Annoncer une période de support choisie par le marketing

La période doit refléter la durée d'utilisation attendue du produit, avec un plancher de cinq ans. Annoncer trois ans sur un logiciel industriel dont on sait qu'il tourne dix ans en usine est un écart documenté par le produit lui-même. La date de fin doit en plus être visible au moment de l'achat, sous une forme facilement accessible.

Empaqueter le correctif de sécurité dans une release fonctionnelle

Quand c'est techniquement possible, les mises à jour de sécurité doivent être diffusées séparément des mises à jour de fonctionnalités. La raison est opérationnelle : un client qui doit accepter une refonte d'interface pour recevoir un correctif d'authentification retarde l'installation, ou l'annule.

N'avoir aucune adresse pour recevoir un signalement

Beaucoup de sociétés n'ont ni security@, ni security.txt, ni politique publiée. Une faille signalée arrive alors sur le formulaire de contact commercial, où elle attend six jours. Le délai de 24 heures court pendant ce temps.

Attendre les normes harmonisées

Les 41 normes issues de la demande M/606 donneront une présomption de conformité, ce qui simplifiera la démonstration. Elles ne créent pas l'obligation, qui existe déjà dans le règlement, et l'ANSSI l'écrit noir sur blanc dans sa FAQ : aucune norme n'est obligatoire, leur usage reste volontaire. Aucune n'était d'ailleurs citée au Journal officiel de l'Union à la mi-août 2026. Une équipe qui attend leur publication pour commencer perdra les mois qui comptent, d'autant que la capacité des organismes notifiés se réservera d'ici 2027.

Confondre sécurité du code et sécurité de la chaîne

Une analyse statique impeccable ne protège pas d'un paquet compromis dans les dépendances transitives ni d'un artefact modifié après le build. Les compromissions successives observées sur npm et PyPI ces dernières années visent ce maillon. L'attestation de provenance et la signature d'artefacts répondent à cette menace, et ils sont attendus par les clients avant de l'être par les autorités. La question des risques réels est développée dans notre article sur ce que coûte une application non sécurisée.

Laisser un assistant de code décider de l'architecture de sécurité

Le code généré à grande vitesse produit des configurations par défaut permissives, des secrets en clair pour faire fonctionner un exemple et des dépendances ajoutées sans examen. Ces trois habitudes entrent en collision frontale avec l'annexe I. La méthode pour garder la main est décrite dans cet article sur le travail avec un assistant de code.

Feuille de route

Trois horizons, dans cet ordre. Le premier tient en quelques jours de travail et couvre l'échéance la plus proche.

Pour les équipes qui veulent traiter ce parcours en interne avec un accompagnement, LaPolaris propose une formation dédiée de cinq jours, Git, GitHub Actions et Cyber Resilience Act, construite autour d'une stack .NET et WPF de logiciel industriel. Elle passe par la mise en place du pipeline sur un projet réel de l'équipe, la génération du premier SBOM CycloneDX, la simulation d'une notification 24 heures, et se termine par un plan d'action CRA et une charte Git adoptés par l'équipe. Les autres parcours techniques sont réunis dans la catégorie DevOps et déploiement.

Reste une question que le règlement ne tranche pas et que chaque équipe devra trancher seule : qui décroche le dimanche soir.

Questions fréquentes

Sources officielles

• Règlement (UE) 2024/2847 sur EUR-Lex, texte intégral en français
• Résumé officiel du texte législatif, Commission européenne
• Orientations de la Commission du 27 juillet 2026, document C(2026) 5252
• Plateforme unique de signalement et obligations de notification
• Le CRA et les logiciels libres et open source
• Règlement d'exécution (UE) 2025/2392, description technique des produits importants et critiques
• État de la normalisation harmonisée, demande M/606
• Direction générale des Entreprises, mise en oeuvre du CRA en France
• ANFR, autorité de surveillance du marché pour le CRA en France
• ANSSI, autorité notifiante et CSIRT coordinateur national via le CERT-FR
• Mesures de soutien aux microentreprises et PME

Références techniques

• Spécification du format OSV, champs obligatoires et types de plages
• RFC 9116, format du fichier security.txt
• CycloneDX pour Python, génération de SBOM
• CycloneDX pour npm, génération de SBOM
• OSV-Scanner, analyse des dépendances contre la base OSV

Références réglementaires vérifiées contre le texte du règlement (UE) 2024/2847 et les publications de la Commission le 14 août 2026. Les exemples de code ont été exécutés sur Python 3.14.4 et Node.js 24.19.0 avant publication. Le calendrier de normalisation et les désignations d'organismes notifiés évoluent : vérifier ces deux points avant toute décision.