Le Cyber Resilience Act (CRA) est déjà en vigueur depuis le 10 décembre 2024. Pourtant, dans beaucoup d'équipes, il reste perçu comme une réglementation lointaine, réservée aux fabricants d'objets connectés ou aux directions conformité. C'est une erreur.
Le CRA change la cible : il ne regarde pas seulement la cybersécurité d'une organisation, il regarde la cybersécurité des produits avec éléments numériques mis à disposition sur le marché européen. Logiciels installés, applications mobiles, firmwares, appliances, agents, extensions, SDK, équipements connectés — et parfois les services distants nécessaires à leur fonctionnement.
La première vraie échéance opérationnelle arrive le 11 septembre 2026 avec les obligations de reporting des vulnérabilités activement exploitées et des incidents graves (article 14). Les obligations principales s'appliquent ensuite à partir du 11 décembre 2027. Septembre 2026 n'est pas la date à laquelle il faut commencer à réfléchir : c'est la date à laquelle votre processus de notification doit déjà fonctionner. Ce billet répond à la seule question qui compte aujourd'hui : êtes-vous concerné ?
Le CRA en une minute
Le CRA est un règlement européen — donc directement applicable dans tous les États membres sans transposition nationale. Il impose des exigences de cybersécurité aux produits avec éléments numériques mis à disposition sur le marché de l'Union européenne dans le cadre d'une activité commerciale.
Trois idées-force à retenir :
- C'est une logique produit, pas une logique organisation. Le CRA ne vous regarde pas en tant qu'entreprise, il regarde chaque produit que vous mettez sur le marché.
- C'est une logique cycle de vie, pas une checklist au moment du lancement. Vous devez documenter, maintenir, corriger et notifier les vulnérabilités pendant toute la durée de support du produit.
- C'est une logique de preuve. Sans inventaire exploitable des composants, sans SBOM, sans traçabilité de build et sans politique de support documentée, vous aurez beaucoup de mal à démontrer votre maîtrise de la chaîne logicielle — et c'est cette maîtrise démontrable qui est attendue.
Êtes-vous concerné ? Le tableau de décision
Le CRA distingue plusieurs opérateurs économiques. Vous pouvez en occuper un, plusieurs ou aucun pour un produit donné.
| Rôle | Vous correspondez si… | Cas typique |
|---|---|---|
| Fabricant / éditeur | Vous développez ou faites développer un produit avec éléments numériques et le mettez sur le marché sous votre nom ou votre marque | Éditeur logiciel, fournisseur d'appliance, fabricant d'agent EDR, éditeur d'extension navigateur, éditeur de SDK |
| Importateur | Vous mettez sur le marché UE un produit portant le nom ou la marque d'un acteur établi hors UE | Distributeur européen d'une caméra connectée asiatique, intégrateur qui revend une appliance américaine |
| Distributeur | Vous rendez disponible un produit dans l'UE sans le modifier | Revendeur d'équipements réseau, intégrateur, marketplace spécialisée |
| Mandataire autorisé | Vous êtes mandaté dans l'UE pour effectuer certaines obligations au nom d'un fabricant établi hors UE | Représentant réglementaire, structure de mise en conformité |
| Open-source software steward | Vous êtes une personne morale qui soutient durablement le développement de projets open source destinés à des usages commerciaux, sans être le fabricant du produit final | Fondation, entité de gouvernance, structure de soutien à un projet OSS commercial |
Si vous occupez l'un de ces rôles pour un produit avec éléments numériques mis à disposition sur le marché européen dans le cadre d'une activité commerciale, vous devez analyser votre exposition au CRA. Le niveau d'obligation dépend ensuite de votre rôle exact, du type de produit et de son niveau de criticité.
Quelques cas concrets pour fixer les idées
- Vous êtes un éditeur SaaS français avec une extension navigateur pour vos clients. → Le SaaS lui-même n'est pas couvert, mais l'extension est un produit avec éléments numériques mis sur le marché → CRA.
- Vous êtes une plateforme cloud qui fournit une CLI officielle à vos utilisateurs pour piloter leur compte ou déployer leurs ressources (open source ou propriétaire, peu importe). → La CLI est installée et exécutée chez vos clients → CRA, en tant qu'éditeur de la CLI. Le service distant derrière peut en plus relever des solutions de traitement de données à distance si la CLI n'a aucune utilité sans lui.
- Vous êtes une start-up DevOps qui distribue un agent à installer chez vos clients pour collecter des métriques. → L'agent est un produit avec éléments numériques installé chez un client → CRA, en tant qu'éditeur.
- Vous êtes une ESN qui intègre une appliance réseau d'un fournisseur hors UE et la revend à des clients européens. → CRA, en tant qu'importateur.
- Vous êtes une équipe interne qui développe un outil pour vos propres opérations, jamais vendu, jamais distribué. → Hors périmètre (pas d'activité commerciale, pas de mise sur le marché).
Les trois confusions qui coûtent cher
Confusion n°1 — Le CRA, ce n'est pas NIS2
NIS2 cible les organisations considérées comme essentielles (hôpitaux, énergie, transport, cloud critique). Le CRA cible les produits avec éléments numériques. Vous pouvez être concerné par les deux, par l'un, par l'autre, ou par aucun. Pour une équipe DevOps, l'impact est radicalement différent : NIS2 vous demande de la gouvernance et de la continuité, le CRA vous demande de la documentation technique, une gestion des vulnérabilités, une traçabilité des composants, des preuves de conformité et un processus de notification avec alerte sous 24 h puis notification complète sous 72 h en cas de vulnérabilité activement exploitée.
Confusion n°2 — « On fait du SaaS, donc on est tranquilles »
C'est vrai uniquement dans les cas les plus simples. Un SaaS purement cloud, sans logiciel, agent, extension, application ou appliance mis à disposition du client, peut être hors périmètre CRA et relever plutôt d'autres cadres comme NIS2.
Mais dès qu'il existe un composant client — extension navigateur, application mobile compagnon, agent on-premise, SDK distribué, CLI officielle, appliance virtuelle — ce composant doit être analysé comme un produit avec éléments numériques. Et si un service distant est indispensable au fonctionnement de ce produit, il peut aussi entrer dans le périmètre comme solution de traitement de données à distance (remote data processing solution). La majorité des SaaS B2B modernes ont au moins un composant client, ne serait-ce qu'une CLI.
Confusion n°3 — « Le CRA va tuer l'open source »
Non, mais il change la responsabilité des entreprises qui consomment et commercialisent de l'open source. Le mainteneur individuel qui publie une bibliothèque sur GitHub sans activité commerciale n'est pas la cible du CRA.
En revanche, lorsqu'un éditeur intègre cette bibliothèque dans un produit commercial, c'est le produit final qui doit être maîtrisé : c'est l'éditeur qui répond des vulnérabilités de cette bibliothèque, pas le mainteneur upstream. Le CRA introduit aussi un régime spécifique pour les open-source software stewards : des personnes morales qui soutiennent durablement des projets open source destinés à des usages commerciaux, sans être nécessairement les fabricants du produit final.
Le message est donc simple : le CRA ne demande pas aux mainteneurs bénévoles de porter seuls la sécurité de toute l'industrie. Il demande aux acteurs économiques qui mettent des produits sur le marché d'assumer leur chaîne d'approvisionnement — d'où l'importance du SBOM.
Les 10 questions à se poser maintenant
Si vous répondez « oui » à au moins une question dans chaque bloc, vous êtes concerné et le chantier de préparation commence aujourd'hui.
Bloc 1 — Périmètre
- Mon produit contient-il du logiciel (code que j'écris ou que j'embarque) ?
- Est-il vendu, distribué ou mis à disposition dans l'Union européenne, même gratuitement ?
- Est-il installé chez un client sous une forme ou une autre (agent, SDK, extension, appliance, application mobile) ?
- Est-il connecté directement ou indirectement à un réseau ?
Bloc 2 — Capacité de preuve
- Ai-je un inventaire fiable des dépendances de chaque produit ?
- Suis-je capable de générer un SBOM à chaque release ?
- Suis-je capable de savoir, en moins d'une heure, si une CVE publiée aujourd'hui me concerne ?
- Ai-je une procédure de correction documentée et exécutable ?
- Ai-je une politique de support claire (durée, fréquence des patchs, fin de vie) ?
- Ai-je une procédure de notification des vulnérabilités exploitées aux autorités compétentes ?
Le meilleur test du CRA, ce n'est pas un tableau Excel. C'est un exercice réel : une CVE critique tombe sur une dépendance utilisée par trois de vos produits. Combien de temps vous faut-il pour savoir si vous êtes concernés, corriger, reconstruire, publier et informer ? Si la réponse dépasse 24 à 48 heures, votre processus n'est pas prêt.
Conclusion : le CRA est un sujet produit, pas conformité
Le CRA ne doit pas être traité comme une contrainte juridique de plus qu'on délègue au RSSI. Pour les équipes DevOps et DevSecOps, c'est l'occasion de remettre de l'ordre dans la chaîne de production logicielle : dépendances maîtrisées, builds traçables, artefacts signés, vulnérabilités industrialisées, support documenté.
La vraie question n'est donc pas seulement « sommes-nous concernés ? » mais « si nous le sommes, sommes-nous capables de le démontrer et de réagir vite ? ». La réponse à la première question se trouve dans le tableau plus haut. La réponse à la seconde dépend entièrement du travail que vous engagez aujourd'hui.