Vendredi, un chrono réglementaire s'arme dans toute l'Union européenne. Il vient du Cyber Resilience Act, le règlement européen sur la cybersécurité des produits numériques. CRA pour la suite, et non, rien à voir avec ton compte rendu d'activité. La plupart des équipes ne savent pas encore qu'il les concerne.
TL;DR : à partir du 11 septembre 2026, le Cyber Resilience Act rend le signalement obligatoire. Une vulnérabilité activement exploitée dans ton produit te laisse 24 h pour l'alerte précoce, 72 h pour la notification, 14 jours pour le rapport final. Le vrai sujet n'est pas juridique. C'est ta capacité à savoir vite, qualifier vite et écrire vite. Voici le runbook côté pipeline.
Cet article est pour les éditeurs qui vendent du logiciel dans l'UE, surtout les petites équipes sans juriste interne. Je ne suis pas juriste : les dates et le périmètre viennent des sources primaires listées en bas.
Es-tu concerné ?
Le CRA vise les « fabricants » : ceux qui commercialisent dans l'UE un produit avec des éléments numériques. Du logiciel vendu, une app, un firmware, un objet connecté.
Le SaaS pur est en principe couvert par une autre loi, NIS2. Il retombe dans le CRA quand le service est nécessaire au fonctionnement d'un produit.
Les contributeurs open source individuels ne sont pas visés. Les fondations qui soutiennent des projets, appelées stewards, ont un régime allégé, sans amendes.
La conformité complète, marquage CE compris, attend décembre 2027. Le signalement, lui, commence ce vendredi.
Le chrono, concrètement
Deux événements déclenchent le signalement. Une vulnérabilité de ton produit activement exploitée, c'est-à-dire que quelqu'un s'en sert vraiment. Ou un incident grave qui touche la sécurité du produit.
Le signalement part vers ton CSIRT national et l'ENISA, par une plateforme unique, la Single Reporting Platform. Un CSIRT est l'équipe nationale de réponse aux incidents. En France, c'est l'ANSSI.
Et le chrono démarre au moment où tu en prends connaissance :
J0 : tu apprends l'exploitation active
< 24 h : alerte précoce (produit, nature du problème)
< 72 h : notification complète (évaluation, mesures prises)
< 14 j : rapport final, une fois le correctif disponible
< 30 j : rapport final pour un incident graveRelis la première ligne. « Dès que tu en prends connaissance. » Tout l'enjeu tient dans ta capacité à en prendre connaissance tôt, et à le prouver.
Ce que ta pipeline sait déjà faire
La bonne nouvelle : si tu as une pipeline de sécurité sérieuse, la moitié du travail existe. Voici ce que j'installe chez mes clients depuis des années, et ce que ça couvre.
govulncheck surveille les vulnérabilités Go, et n'alerte que si ton code appelle vraiment la fonction touchée. Renovate maintient les dépendances à jour. syft génère un SBOM à chaque build. Grype ou Trivy scannent les images. gitleaks attrape les secrets.
Un SBOM est l'inventaire machine-readable de tout ce que ton produit embarque. Sans lui, tu ne peux pas répondre en 24 h à la question « es-tu affecté par la CVE X ? ». Avec lui, c'est une recherche.
Cette partie couvre « détecter vite » et « savoir ce que tu embarques ». C'est nécessaire. Ce n'est pas suffisant.
Ce que presque personne n'a
Le contenu CRA existant vient des cabinets d'avocats et des vendeurs d'outils. Aucun ne répond à la question d'équipe : que fait-on lundi matin ? Voici les cinq pièces qui manquent presque partout.
Une définition écrite de « en avoir connaissance » : quelles alertes comptent, sur quel canal elles arrivent, qui les lit, sous quel délai.
Un modèle de rapport pré-rempli : produit, version, CVE, nature de l'exploitation, mesures. À J0, tu remplis des trous, tu ne rédiges pas.
L'accès à la plateforme de signalement, créé avant l'incident. Découvrir un portail à J0 + 20 h est un scénario réel et évitable.
Une politique de divulgation coordonnée publiée : un contact sécurité joignable et une promesse de réponse. Le CRA l'exige, et c'est ta source d'alerte gratuite.
Et un exercice à blanc, chronomètre en main. Une fausse CVE, l'équipe déroule, tu mesures. C'est là que le runbook théorique casse, et c'est le but.
Le runbook que j'installe
AVANT (cette semaine)
- SBOM généré à chaque build, archivé par version
- scan vulnérabilités planifié, pas seulement sur push
- page de divulgation + contact sécurité publiés
- accès à la plateforme de signalement créé et testé
- modèle de rapport pré-rempli, rôles écrits
À J0 (prise de connaissance)
- qualifier : exploitation active ? produit dans le périmètre ?
- ouvrir l'incident, timeline écrite dès la première minute
Puis
- alerte précoce avant 24 h
- notification complète avant 72 h
- correctif, rapport final sous 14 jours, post-mortemRien d'exotique. C'est un plan de réponse à incident, avec des échéances imposées et un guichet unique. La difficulté n'est pas l'ambition, c'est l'avance de phase : tout se prépare avant.
La partie Go que personne ne traite
Un binaire Go statique embarque tout. Ton go.mod n'est pas ton SBOM : il liste ce que tu déclares, pas ce que tu livres.
# SBOM de ce qui est vraiment livré (format CycloneDX)
syft scan ./bin/app -o cyclonedx-json > sbom.json
# cette CVE te concerne-t-elle vraiment ?
govulncheck ./...Le duo fait le triage des 24 premières heures. Le SBOM répond « est-ce embarqué ? ». govulncheck répond « est-ce appelé ? ». Deux réponses en minutes, documentées, à mettre telles quelles dans l'alerte précoce.
Honnêteté totale : je n'ai encore jamais déclenché de signalement CRA réel, personne ne l'a fait avant vendredi. Ce runbook est celui que j'installe, pas un retour d'incident. L'outillage en dessous, lui, tourne en production depuis des années.
La checklist avant vendredi
Une demi-journée suffit pour l'essentiel. C'est une bonne demi-journée.
- Tu sais dire si ton produit est dans le périmètre du CRA, et pourquoi
- Un SBOM machine-readable sort de ta CI à chaque build
govulncheckou l'équivalent tourne en planifié, avec un humain destinataire- « En avoir connaissance » a une définition écrite : canal, lecteur, délai
- Le contact sécurité et la politique de divulgation sont publiés
- L'accès à la plateforme de signalement existe déjà
- Le modèle de rapport est pré-rempli, les rôles sont nommés
- Un exercice à blanc est daté dans l'agenda, chronomètre en main
Ce qu'il faut retenir
Le CRA ne te demande pas d'être parfait. Il te demande d'être rapide et documenté.
Une pipeline qui sait dire en une heure « voilà ce qu'on embarque, voilà si on est touché » rend les délais tenables. Sans elle, 24 h est un sprint perdu d'avance.
Le meilleur moment pour préparer un signalement, c'est quand tu n'en as pas à faire.
Tu veux une pipeline et un runbook prêts pour le CRA ? Parlons-en.