La réglementation porte sur les produits, pas seulement sur les entreprises de cybersécurité

Le règlement européen sur la cyberrésilience — désigné par le sigle anglais CRA — établit des exigences obligatoires de cybersécurité pour les produits comportant des éléments numériques. Il couvre le matériel et les logiciels : la Commission européenne cite des exemples courants tels que les montres connectées, les babyphones, les applications et les programmes informatiques. Son objectif est que la sécurité soit prise en compte lors de la conception, du développement et de la maintenance du produit, et pas uniquement après sa mise sur le marché. [1]

Pour une entreprise, la première question n’est pas seulement de savoir si elle vend des technologies, mais quel produit elle met à disposition sur le marché européen et quel rôle elle joue dans sa chaîne d’approvisionnement. Les fabricants, importateurs et distributeurs peuvent avoir des responsabilités différentes. La Commission considère également les développeurs d’applications comme des fabricants lorsqu’ils commercialisent ces applications dans l’UE. Une appellation commerciale ne suffit pas à déterminer la classification : il est utile d’examiner le rôle réel de chaque entité et les caractéristiques du produit. [2]

Délimiter le champ d’application avant de lancer un plan de conformité

Un examen utile commence par un inventaire des produits et composants numériques, puis par l’évaluation de leurs liens avec des services connectés. Les orientations publiées par la Commission en juillet 2026 abordent notamment le champ d’application, les modifications substantielles, les périodes d’assistance, l’évaluation des risques et le signalement des vulnérabilités. Elles aident à comprendre la mise en œuvre pratique, mais ne remplacent pas le règlement et ne déterminent pas automatiquement le statut de chaque produit. [3]

Il ne faut pas supposer qu’une catégorie entière est incluse ou exclue sans examiner le cas concret. Un service cloud, par exemple, peut avoir un lien technique avec un produit couvert ; une source secondaire décrit des situations possibles de traitement à distance connecté au produit. Cette explication peut aider à formuler des questions, mais elle ne suffit pas à trancher une interprétation juridique. En cas d’incertitude importante, l’entreprise devrait comparer son architecture et son rôle au texte juridique et demander un avis spécialisé. [4]

Exigences à intégrer au cycle de vie du produit

La Commission présente le CRA comme un cadre d’exigences de cybersécurité pour les fabricants, qui concerne la planification, la conception, le développement et la maintenance des produits comportant des éléments numériques. Elle indique également que les fabricants doivent gérer les vulnérabilités tout au long du cycle de vie. Sur le plan opérationnel, cela implique de relier le travail de sécurité aux processus d’ingénierie, de maintenance et d’assistance, plutôt que de le traiter comme une vérification isolée avant le lancement. [1]

L’application concrète dépend du produit et des obligations qui lui incombent. Les orientations de la Commission de 2026 traitent de sujets tels que l’analyse des risques et l’interprétation des périodes d’assistance. Les entreprises devraient donc pouvoir expliquer quel produit elles ont évalué, quels risques elles ont pris en considération et comment elles organisent le traitement des vulnérabilités et les mises à jour. La documentation doit refléter les pratiques réelles, et non se limiter à une déclaration générale selon laquelle le produit est sûr. Les informations disponibles ici ne permettent pas de fixer une période d’assistance universelle pour tous les produits. [3]

Signalement des vulnérabilités : première échéance opérationnelle

Selon la page de la Commission consacrée aux obligations de signalement, à compter du 11 septembre 2026, les fabricants doivent signaler les vulnérabilités activement exploitées et les incidents graves qui affectent la sécurité de leurs produits comportant des éléments numériques. La Commission décrit une alerte initiale dans les 24 heures suivant la prise de connaissance, une notification complète dans les 72 heures et un rapport final soumis à des délais qui varient selon le type d’événement. [5]

La page officielle précise que le rapport final relatif à une vulnérabilité activement exploitée doit être remis au plus tard 14 jours après qu’une mesure corrective est disponible. Pour les incidents graves, elle indique un délai d’un mois à compter de la notification de 72 heures. Elle explique aussi que les fabricants signalent les événements via une plateforme unique, à destination de l’équipe de réponse aux incidents de sécurité informatique (CSIRT) compétente pour leur établissement principal. Ces délais courts imposent de préparer à l’avance les responsables, les circuits d’escalade et les critères de déclenchement, plutôt que de les improviser lors d’un incident. [5]

Le même calendrier officiel distingue les gestionnaires de logiciels libres : conformément à la disposition citée par la Commission, leurs obligations de signalement commencent le 11 décembre 2027. Cette différence concerne les organisations qui maintiennent des logiciels libres ainsi que les entreprises qui en dépendent ; elle ne doit pas être confondue avec la date applicable aux fabricants de produits. [5]

Calendrier : ne pas confondre signalement et application générale

Selon la Commission, le CRA est en vigueur depuis décembre 2024, mais cela ne signifie pas que toutes ses obligations ont commencé simultanément. L’échéance de septembre 2026 déclenche les obligations de signalement décrites ci-dessus. La Commission indique que le règlement sera pleinement applicable à partir du 11 décembre 2027. Pour planifier, les entreprises doivent distinguer l’entrée en vigueur, les échéances propres à certaines obligations et la date d’application générale. [1][5]

Un tableau de suivi interne peut éviter qu’un calendrier simplifié ou une publication d’un tiers ne devienne l’unique référence :

Échéance Date indiquée par la Commission Personnes concernées
Début du signalement par les fabricants 11 septembre 2026 Vulnérabilités activement exploitées et incidents graves
Signalement par les gestionnaires de logiciels libres 11 décembre 2027 Obligations indiquées pour ces gestionnaires
Application générale du CRA 11 décembre 2027 Cadre général du règlement

Le tableau récapitule les dates et les catégories telles qu’elles figurent dans les informations officielles consultées ; il ne remplace pas la vérification de l’article applicable à chaque organisation. [1][5]

Ce qu’il faut vérifier maintenant et ce qu’on ne peut pas conclure

Un plan pratique peut commencer par cinq vérifications : recenser les produits et les marchés ; attribuer un rôle à chaque entité ; documenter les composants et les dépendances ; établir un processus de détection, d’évaluation et d’escalade des vulnérabilités ; et confirmer qui transmet les signalements et par quel canal. Il convient ensuite de comparer ces mesures au règlement et aux orientations officielles, en prêtant attention à la classification du produit, aux modifications, à l’assistance et à l’évaluation des risques. [2][3][5]

Les recherches disponibles ne comprennent aucune déclaration directe de fabricants concernés et ne permettent pas d’attribuer une position, un niveau de préparation ou une interprétation à une entreprise précise. Elles ne fournissent pas non plus assez d’éléments pour résoudre tous les cas limites relevant du champ d’application. Par conséquent, rien ne permet ici d’affirmer qu’une entreprise déterminée respecte ou enfreint le règlement, ni de présenter une évolution réglementaire au-delà des échéances documentées. La conclusion vérifiable est plus limitée : la date de début des obligations de signalement est confirmée et les organisations doivent intégrer la date d’application générale à leur analyse. [1][5]