Cyber Resilience Act · 2026/2027

Le règlement sur la cyberrésilience s’applique-t-il à mon produit ?

Auteur : Piotr AdamskiRevue opérationnelle et de sécurité : Brillnet C-Team

Contenu informatif. Il ne remplace ni un conseil juridique individuel ni une évaluation de conformité.

Vérifier le champ du CRA et télécharger votre évaluation

Vérificateur CRA : première évaluation d’un produit

Répondez à quatre questions pour obtenir une base de revue et une liste de preuves. Vos réponses restent dans ce navigateur ; téléchargez le rapport sans compte.

Il s’agit d’une première évaluation du périmètre, pas d’un conseil juridique ni d’une confirmation de conformité. Le responsable produit doit examiner le résultat. L’outil ne détermine pas les obligations spécifiques des intendants de logiciels ouverts.

Base des questions : articles 2 et 3 du CRA

Le champ d’application du CRA ne se détermine pas uniquement par le secteur de l’entreprise ou par des étiquettes comme « SaaS », « IoT » ou « éditeur de logiciels ». Partez du produit précis comportant des éléments numériques, de ses modalités de mise à disposition sur le marché de l’UE, du rôle de l’organisation et de tout traitement de données à distance faisant partie de ses fonctions.

Le résultat doit être une évaluation documentée du champ d’application, avec un fondement visible de la conclusion, plutôt qu’une réponse oui/non sans explication.

Étape 1. Identifiez le produit

Commencez par ce que l’utilisateur achète, télécharge, installe, intègre ou reçoit réellement comme composant.

Consignez :

  • le nom et l’identifiant du produit ;
  • la version ou la famille de versions ;
  • la destination ;
  • les fonctions principales ;
  • le mode de fourniture ;
  • la marque sous laquelle il arrive sur le marché ;
  • les marchés où il est mis à disposition.

Si l’équipe ne peut pas délimiter le produit, le reste de l’évaluation dépendra d’hypothèses difficiles à examiner par la suite.

Étape 2. Vérifiez la définition d’un produit comportant des éléments numériques

Le CRA définit un produit comportant des éléments numériques comme un produit logiciel ou matériel et ses solutions de traitement de données à distance. Les composants logiciels ou matériels mis séparément sur le marché peuvent aussi relever de cette définition.

Pour les services à distance, le lien fonctionnel est déterminant. Le règlement décrit le traitement de données à distance comme un traitement pour lequel le logiciel est conçu et développé par le fabricant ou sous sa responsabilité, et dont l’absence empêcherait le produit d’exécuter l’une de ses fonctions.

C’est pourquoi « il fonctionne dans le cloud » n’est pas un test suffisant du champ d’application. Cartographiez d’abord le produit et ses dépendances.

Étape 3. Déterminez le rôle de l’organisation

Le rôle concerné peut être :

  • fabricant ;
  • mandataire ;
  • importateur ;
  • distributeur ;
  • autre personne réalisant une modification substantielle et mettant le produit à disposition sur le marché.

Un cas important est celui d’un importateur ou distributeur qui met un produit sur le marché sous son propre nom ou sa propre marque, ou le modifie substantiellement. Le CRA peut alors lui appliquer les obligations du fabricant.

Étape 4. N’ignorez pas les produits déjà sur le marché

Les principales exigences du CRA s’appliquent à partir du 11 décembre 2027, mais cela ne signifie pas que les produits déjà sur le marché peuvent être ignorés pour les signalements actuels.

L’article 69(3) prévoit que les obligations de signalement de l’article 14 s’appliquent aux produits comportant des éléments numériques qui relèvent du règlement, même s’ils ont été mis sur le marché avant le 11 décembre 2027.

Pour un produit existant encore utilisé, le processus de signalement des vulnérabilités et incidents constitue donc une question opérationnelle actuelle.

Étape 5. Vérifiez les exclusions et la législation sectorielle

Ne vous fiez pas à une courte liste en ligne de « secteurs exclus du CRA ». Le règlement possède son propre champ d’application, ses exclusions et ses interactions avec le droit sectoriel de l’UE.

Une démarche justifiable consiste à :

  1. consigner la disposition juridique et la source utilisées pour l’évaluation ;
  2. consigner la date de revue ;
  3. distinguer les faits des hypothèses ;
  4. signaler les questions nécessitant une analyse juridique qualifiée, au lieu de transformer une incertitude en affirmation catégorique sur le produit.

Contenu minimal d’une fiche d’évaluation du champ d’application

Champ Informations à consigner
Produit Nom, version, identifiant
Rôle de l’organisation Fabricant / importateur / distributeur / autre
Marché Lieux où le produit est mis à disposition
Fonctions numériques Logiciels, matériels, interfaces, composants
Traitement à distance Traitements réalisés à distance et nécessité pour une fonction du produit
Fondement Disposition CRA, orientations de la Commission, hypothèses
Résultat Probablement concerné / probablement non concerné / analyse approfondie nécessaire
Responsable de la décision Personne approuvant l’évaluation
Date de revue Moment où la décision doit être réexaminée

Quand réévaluer

Une évaluation du champ d’application ne doit pas devenir un PDF oublié. Réexaminez-la notamment lorsque :

  • la destination change ;
  • un nouveau service à distance devient nécessaire à une fonction du produit ;
  • le produit est substantiellement modifié ;
  • le modèle de distribution ou la marque change ;
  • l’organisation assume un autre rôle d’opérateur économique ;
  • de nouvelles orientations de la Commission ou des autorités modifient le fondement de la décision.

Comment Pulsar assure la traçabilité de la décision

Pulsar permet de conserver le fondement de l’évaluation avec ses documents justificatifs et de relier le résultat aux risques, actions et preuves. La valeur ne réside pas dans une réponse automatique sans explication. Elle réside dans la possibilité de montrer plus tard ce qui a été évalué, les sources utilisées, la personne ayant approuvé le résultat et les actions qui ont suivi.

Pulsar ne remplace pas une analyse juridique individuelle.

Découvrez comment mener une évaluation dans Pulsar GRC

Guides associés

Construire une décision à partir du produit réellement distribué

Une fiche de périmètre doit décrire ce qui est fourni, à qui et sous quelle responsabilité. Commencez par une version précise et son mode de distribution. Une application mobile, un logiciel installé chez le client et une fonction accessible uniquement à distance peuvent appartenir à une même offre commerciale sans former un périmètre juridique identique. Le rôle des services à distance doit donc être examiné à partir des fonctions du produit, pas seulement du contrat d’abonnement.

Demandez à une personne connaissant l’architecture de dessiner les éléments et leurs relations. Pour chaque composant, indiquez qui le développe, qui le fournit et ce qui se produit s’il devient indisponible. Cette description ne décide pas à elle seule du champ du CRA. Elle apporte les faits nécessaires à la personne chargée de la qualification. Conservez le schéma examiné avec sa date ; une architecture modifiée peut conduire à une conclusion différente.

Une matrice proposée pour plusieurs offres

Si l’entreprise distribue plusieurs produits, utilisez une ligne par produit ou famille dont le périmètre est réellement comparable. Identifiez la marque, la version, les fonctions, le modèle de fourniture et le responsable. Ajoutez un état de décision : non examiné, informations manquantes, qualification approuvée ou revue nécessaire. Cette matrice évite qu’une conclusion prise pour une offre soit copiée sans analyse dans une autre fiche simplement parce que l’équipe de développement est commune.

L’objectif est de savoir quelle décision reste à prendre. Une ligne « hors champ » sans justification ne sert pas davantage qu’une ligne « conforme ». Enregistrez les définitions et dispositions examinées, les faits déterminants et les questions qui ont nécessité une interprétation. La matrice demeure un outil de travail interne ; elle ne remplace ni le texte du règlement ni une appréciation juridique du produit et du rôle économique de l’organisation.

Exemple hypothétique : application et service à distance

Une entreprise fournit une application installée sur les postes clients. Cette application utilise un service développé sous la responsabilité du fabricant pour exécuter une de ses fonctions. L’équipe doit décrire cette fonction et l’effet de l’absence du service. Dire uniquement « la base est dans le cloud » ne montre pas si le traitement à distance répond à la définition pertinente du CRA. L’analyse doit porter sur la relation fonctionnelle et la responsabilité de développement.

Dans une autre offre, le logiciel utilise une prestation tierce indépendante. Documentez également cette dépendance et son fournisseur. La qualification peut différer, mais l’existence d’un tiers ne permet pas une exclusion automatique. Le responsable doit examiner les faits, les définitions et les orientations applicables. Ces deux exemples expliquent les informations à recueillir ; ils ne donnent pas une conclusion universelle pour tous les produits dont l’architecture leur ressemble.

Examiner les exceptions sans raccourci commercial

Les exclusions et les dispositions particulières doivent être évaluées avec leurs conditions. Le nom du secteur, le caractère gratuit d’une offre ou la disponibilité du code ne suffisent pas à décrire toute la situation. Une décision doit citer la disposition examinée et expliquer pourquoi les faits du produit correspondent ou ne correspondent pas à ses conditions. Lorsque les informations sont insuffisantes, conservez un état ouvert plutôt que forcer une réponse binaire.

Si le produit relève aussi d’un autre cadre réglementaire, identifiez ce cadre et l’effet précis sur l’analyse CRA. Le dossier doit éviter deux erreurs : ignorer une règle particulière ou supposer qu’une certification existante couvre automatiquement le sujet. La personne compétente apprécie la relation entre les textes. Les méthodes proposées ici organisent les éléments de cette appréciation et ne créent pas une nouvelle catégorie de produit exempté.

Définir les événements qui imposent une nouvelle revue

Une qualification ne reste pas valable par inertie. Une fonction ajoutée, un composant distribué localement ou une modification de responsabilité peut changer les faits déterminants. Listez les changements que le responsable produit doit signaler au propriétaire du dossier. La revue n’a pas besoin d’attendre le prochain audit annuel si l’architecture qui justifiait la conclusion a déjà changé. Conservez la décision précédente pour comprendre pourquoi elle avait été prise.

La même attention s’applique au modèle de distribution. Une offre utilisée en interne peut évoluer vers une mise à disposition sur le marché, ou une entreprise peut assumer un rôle différent dans la chaîne. Faites décrire la nouvelle situation par les personnes qui connaissent les contrats et la commercialisation. Une décision copiée d’un dossier ancien peut être techniquement lisible tout en reposant sur des faits devenus faux.

Garder les conséquences opérationnelles de la décision

Après la qualification, identifiez le travail qui en découle. Pour un produit considéré dans le champ, le responsable doit relier la conclusion au traitement des vulnérabilités, au signalement, à la documentation et aux autres exigences applicables. Pour une décision de non-applicabilité, conservez la justification et les conditions de réexamen. Une conclusion négative n’efface pas les engagements de sécurité contractuels ni les autres cadres qui peuvent concerner l’organisation.

La fiche peut également indiquer les questions à confirmer auprès d’un conseil ou d’une autorité compétente. Donnez un propriétaire à chacune et gardez la réponse avec son contexte. Une simple note « vu avec le juridique » ne permet pas de savoir ce qui a été demandé et sur quelles informations reposait l’avis. La traçabilité de ces échanges aide à éviter une nouvelle discussion identique lors de la prochaine version.

Critères proposés pour accepter le dossier

Une personne autorisée qui n’a pas participé à l’analyse doit retrouver le produit, la version, l’architecture, les faits déterminants, les sources et l’approbation. Elle doit aussi distinguer les points confirmés des hypothèses et comprendre ce qui déclenche une revue. Si elle retrouve seulement une réponse de questionnaire sans pièces, le dossier demande un complément. Ce contrôle de lisibilité est une pratique proposée, pas une procédure officielle d’évaluation de la conformité.

Pulsar GRC peut relier la décision aux documents, risques et tâches associés. L’IA peut aider à préparer une description, mais la qualification juridique et l’acceptation restent humaines. Avant une démonstration, utilisez un produit fictif ou des éléments non confidentiels. Le résultat à chercher est une décision expliquée et révisable, plutôt qu’une étiquette automatique qui donnerait une confiance sans fondement.

Sources

État documentaire du guide : 2 octobre 2026. Vérifiez les instructions opérationnelles actuelles avant toute notification.