Le CRA s’applique-t-il à votre produit ? Trois questions pour le situer

Vous fabriquez un boîtier connecté, vous éditez un logiciel, vous vendez une application. Une question revient avant toutes les autres : cette réglementation européenne vous concerne-t-elle, oui ou non ?

Le règlement appelle ce qu’il régit un « produit comportant des éléments numériques » : un produit logiciel ou matériel capable d’échanger des données, ainsi que les traitements à distance sans lesquels il ne remplirait pas ses fonctions. Trois questions permettent de situer le vôtre, et elles se posent dans cet ordre. La deuxième est celle sur laquelle se trompent le plus d’entreprises.

Deux préalables les encadrent : ces questions supposent que vous fournissiez le marché de l’Union européenne, et qu’aucune des exclusions détaillées plus bas ne couvre déjà votre produit.

1. Votre produit échange-t-il des données ?

C’est la porte d’entrée. Le règlement ne vise pas tout ce qui contient de l’électronique, mais ce qui communique.

La distinction est plus fine qu’elle n’en a l’air, et la Commission a pris la peine de la préciser : un signal électrique qui déclenche une fonction n’est pas une donnée. Un interrupteur qui allume une lampe transmet du courant, pas de l’information.

Traduction : lorsque des signaux électriques servent uniquement à déclencher ou à alimenter une fonction, sans transporter d’information encodée sous forme numérique, il n’y a pas de connexion de données au sens du règlement — et le produit sort du champ d’application. Pour qu’une connexion existe, il faut un émetteur qui encode délibérément de l’information et un récepteur capable de la décoder.

Un produit strictement hors ligne, qui n’échange rien avec aucun appareil ni aucun réseau, n’est donc pas concerné. Si le vôtre se connecte — même indirectement, même par une passerelle, même une fois par mois pour une mise à jour — passez à la question suivante.

2. Votre client l’installe-t-il, ou le consulte-t-il ?

Cette question ne concerne que le logiciel. Si vous fabriquez du matériel connecté — un boîtier, un capteur, un appareil embarquant du logiciel —, la réponse est acquise : votre client l’obtient et l’utilise chez lui, c’est un produit comportant des éléments numériques, et vous pouvez passer directement à la question 3.

Le cas le plus fréquent mérite d’être traité tout de suite, parce qu’il est mixte : vous vendez un appareil, et vos clients le pilotent depuis une page web que vous avez développée. L’appareil est un produit, sans discussion. Pour la page web, la question n’est pas de savoir si l’appareil survit sans elle, mais si elle porte une de ses fonctions — commander, configurer, appairer, mettre à jour, afficher les mesures à l’utilisateur. Si oui, elle est absorbée dans le produit et suit son régime : vous avez un seul produit à qualifier. Le fait que la même fonction reste accessible manuellement ne change rien à cette réponse (guidance, § 191). Ne reste en dehors que le traitement à distance qui ne rend aucune fonction à l’utilisateur — typiquement de la télémétrie collectée à des fins statistiques ou de développement produit (§ 192). Les paragraphes qui suivent expliquent d’où vient cette distinction.

Pour le logiciel, en revanche, c’est ici que tout se joue, et c’est ici que les erreurs de qualification sont les plus fréquentes. Le critère n’est pas la technologie employée : c’est le mode de livraison.

Autrement dit : pour être dans le périmètre, un logiciel doit être fourni à l’utilisateur, obtenu par lui, et exécuté sur son propre système. Une application mobile téléchargée, un logiciel de bureau installé, une extension de navigateur, un micrologiciel embarqué dans un appareil remplissent ces trois conditions.

Un logiciel qui s’exécute à distance et que l’utilisateur se contente de consulter n’est pas, à ce seul titre, un produit régi par le règlement. C’est typiquement le cas d’une application web accessible uniquement par un navigateur. La Commission souligne au passage que cette distinction ne date pas de sa note : les considérants 11 et 12 du règlement — les paragraphes d’introduction qui exposent l’intention du législateur — posaient déjà que le traitement à distance n’entre dans le champ que dans la mesure où il est nécessaire au fonctionnement d’un produit.

La formule « à ce seul titre » est décisive, et deux situations très courantes font basculer un service en apparence hors périmètre vers l’intérieur.

• Votre service à distance soutient le fonctionnement d’un produit. L’Art. 3 § 1 range dans le produit ses « solutions de traitement de données à distance », que l’Art. 3 § 2 définit par deux conditions cumulatives : le logiciel est conçu et développé par vous ou sous votre responsabilité, et son absence empêcherait le produit d’exécuter une de ses fonctions. Un portail que vous développez pour délivrer les jetons d’authentification de votre boîtier fait partie du produit. Un service tiers du commerce dont vous dépendez, non.
• Vous livrez aussi un client installé. Dès qu’une partie de votre offre s’exécute chez l’utilisateur, elle est un produit — et le traitement à distance dont elle dépend y est absorbé.

Traduction de cet exemple : une application web à laquelle l’utilisateur accède exclusivement par un navigateur n’est pas un produit comportant des éléments numériques ; à moins qu’elle ne soutienne la fonctionnalité d’un tel produit, elle sort du champ. À l’inverse, une application fournie sous forme de client installé localement, qui s’exécute sur l’appareil de l’utilisateur, en est un ; et si ce client dépend, pour l’une de ses fonctions, d’un traitement de données à distance répondant à la définition, ce traitement fait lui aussi partie du produit.

Un éditeur dont le logiciel est accessible uniquement par navigateur, sans rien à installer et sans matériel associé, se situe donc hors du périmètre. Le même éditeur qui distribue un agent, une extension de navigateur ou un client lourd y entre — et son infrastructure distante y entre avec lui.

3. Le fournissez-vous dans le cadre d’une activité commerciale ?

Attention au contresens le plus répandu : le critère n’est pas la vente. L’Art. 3 § 22 définit la mise à disposition sur le marché comme la fourniture d’un produit destiné à être distribué ou utilisé sur le marché de l’Union dans le cadre d’une activité commerciale, « à titre onéreux ou gratuit ».

La gratuité ne suffit donc pas à sortir du champ. Une application distribuée sans frais mais financée par la publicité, par une version payante, ou par l’exploitation de données personnelles reste fournie dans le cadre d’une activité commerciale : la Commission l’illustre par une place de marché gratuite rémunérée par commissions, par un service de réseau privé virtuel gratuit dont les serveurs sont payants, et par une application de suivi d’activité physique conditionnée au traitement de données personnelles.

L’exception vise le logiciel libre et ouvert non monétisé, et lui seul.

Le considérant 15 caractérise la fourniture dans le cadre d’une activité commerciale : facturer le produit, facturer le support technique au-delà du recouvrement des coûts réels, exiger des données personnelles pour autre chose que la sécurité, la compatibilité ou l’interopérabilité, fournir une plate-forme logicielle par laquelle le fabricant monétise d’autres services, ou accepter des dons supérieurs aux coûts du projet.

Sur ce dernier point, la Commission a assoupli sa lecture le 27 juillet 2026 : le seul fait de collecter des dons, même au-delà des coûts, ne caractérise pas une intention lucrative, et un logiciel libre financé uniquement par des dons est « peu susceptible » d’être regardé comme mis sur le marché (guidance, § 61). La souplesse s’arrête là où le don conditionne l’accès : réserver aux donateurs les binaires, les mises à jour ou les correctifs de sécurité revient à faire payer le produit, et le fait entrer dans le champ (§ 62).

Le règlement crée par ailleurs un statut intermédiaire, celui d’intendant de logiciels ouverts — en anglais « open-source software steward ». L’Art. 3 le définit comme une personne morale, autre que le fabricant, qui soutient de façon systématique et continue le développement d’un logiciel libre destiné à des activités commerciales : typiquement une fondation. Ses obligations, définies à l’Art. 24, sont allégées, et aucune amende ne peut lui être infligée. Si vous n’éditez pas de logiciel libre, ce paragraphe ne vous concerne pas.

Les exclusions : six secteurs, et une liste qui peut s’allonger

Six familles de produits sortent du périmètre parce qu’une autre réglementation européenne les couvre déjà : les dispositifs médicaux et les dispositifs de diagnostic in vitro, les produits automobiles, les produits aéronautiques effectivement certifiés, les équipements marins, et depuis un règlement délégué de 2025, les véhicules de catégorie L — deux-roues, trois-roues et quadricycles. Cette dernière exclusion porte une exception qu’il vaut mieux connaître : les vélos à assistance électrique de catégorie L1e conçus pour être pédalés restent dans le champ du règlement.

Trois autres exclusions, souvent oubliées, ne tiennent pas au secteur : les pièces de rechange remplaçant à l’identique un composant selon les mêmes spécifications (Art. 2 § 6), les produits développés exclusivement pour la sécurité nationale ou la défense, et ceux spécifiquement conçus pour traiter des informations classifiées (Art. 2 § 7).

Cette liste n’est pas figée, et le règlement l’a prévu lui-même : l’Art. 2 § 5 habilite la Commission à ajouter des exclusions par acte délégué — un texte qu’elle adopte sans nouvelle procédure législative, le Parlement européen et le Conseil disposant d’un droit d’objection de deux mois qui peut en empêcher l’entrée en vigueur (Art. 61 § 6). Deux conditions doivent être réunies : que l’exclusion soit compatible avec le cadre réglementaire du secteur, et que les règles sectorielles assurent un niveau de protection identique ou supérieur.

Vous êtes concerné : dans quel régime ?

Tous les produits concernés ne supportent pas la même charge. Le règlement distingue trois familles — par défaut, important (en deux classes) et critique —, soit quatre régimes d’évaluation. La différence porte sur un point très concret : devrez-vous, ou non, faire intervenir un organisme extérieur pour valider votre conformité ? Si votre produit ne figure dans aucune des listes ci-dessous, vous relevez du régime par défaut.

• Régime par défaut : vous évaluez vous-même votre conformité, sous votre responsabilité. C’est le cas de la majorité des produits.
• Produits importants, classe I — 19 catégories listées à l’annexe III : navigateurs, gestionnaires de mots de passe, logiciels antimalveillants, réseaux privés virtuels, systèmes de gestion des informations et des événements de sécurité, systèmes d’exploitation, routeurs et modems, jouets connectés relevant de la directive 2009/48/CE qui présentent des caractéristiques sociales interactives ou des fonctions de localisation, objets portables de suivi de santé hors dispositifs médicaux ainsi que ceux destinés à être utilisés par et pour les enfants, entre autres.
• Produits importants, classe II — 4 catégories : hyperviseurs et systèmes d’exécution de conteneurs, pare-feu et systèmes de détection et de prévention des intrusions, microprocesseurs résistants aux manipulations, microcontrôleurs résistants aux manipulations. Un organisme tiers est toujours obligatoire, même si vous appliquez toutes les normes.
• Produits critiques — 3 catégories à l’annexe IV : dispositifs matériels avec boîtier de sécurité, passerelles pour compteur intelligent, cartes à puce ou dispositifs similaires y compris les éléments sécurisés.

Le classement se fait sur la fonctionnalité de base du produit, pas sur son étiquette commerciale.

Pour la classe I, l’auto-évaluation reste possible, mais seulement si vous appliquez des normes harmonisées, des spécifications communes ou un schéma européen de certification au niveau d’assurance dit « substantiel » au minimum. Les normes harmonisées sont des normes techniques élaborées à la demande de la Commission puis citées au Journal officiel : s’y conformer vaut présomption de conformité pour les exigences que ces normes couvrent, c’est-à-dire que l’autorité vous y présume en règle sans autre démonstration. À défaut de ces référentiels, un organisme notifié intervient : un organisme indépendant d’évaluation de la conformité, désigné et notifié par un État membre, qui examine votre produit ou votre système qualité (Art. 32 § 2).

En pratique, aujourd’hui, cette voie de l’auto-évaluation n’est pas ouverte : aucune norme harmonisée ni spécification commune n’a été publiée, et la Commission n’a pas encore désigné par acte délégué les schémas de certification utilisables pour démontrer la conformité au règlement (Art. 27 § 9). Un fabricant de produit important passe donc par un organisme tiers.

Pour les produits critiques de l’annexe IV, une certification européenne de cybersécurité devient obligatoire lorsque la Commission l’impose par acte délégué, ce qui suppose qu’un schéma européen pertinent existe et soit disponible. Tant qu’aucun acte délégué n’a été adopté — et aucun ne l’est à ce jour —, ces produits suivent le régime de la classe II : organisme tiers obligatoire (Art. 8 § 1 et Art. 32 § 4).

Une exception mérite d’être connue des éditeurs de logiciel libre : l’Art. 32 § 5 leur permet de rester en auto-évaluation même pour un produit important, à condition de publier leur documentation technique au moment de la mise sur le marché.

Ce que vous risquez, et ce que les PME ne risquent pas

L’Art. 64 fixe trois plafonds d’amende administrative, selon la nature du manquement. Le non-respect des exigences essentielles de cybersécurité de l’annexe I, ou des obligations des Art. 13 et 14, peut aller jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu. D’autres manquements plafonnent à 10 millions ou 2 %. La fourniture d’informations inexactes aux autorités, à 5 millions ou 1 %.

Deux tempéraments comptent pour une petite structure : aucune amende ne peut être infligée à une microentreprise ou à une petite entreprise pour le seul dépassement du délai de vingt-quatre heures de l’alerte précoce, ni à un intendant de logiciels ouverts pour quelque infraction que ce soit (Art. 64 § 10). Les seuils sont ceux de la recommandation 2003/361/CE, à laquelle le règlement renvoie : une microentreprise occupe moins de 10 personnes et ne dépasse pas 2 millions d’euros de chiffre d’affaires ou de bilan annuel ; une petite entreprise occupe moins de 50 personnes et ne dépasse pas 10 millions d’euros. Le critère d’effectif et le critère financier s’appliquent ensemble. Appartenir à un groupe, en revanche, n’exclut pas d’office : une entreprise liée additionne les données de son groupe, une entreprise partenaire les agrège au prorata de sa participation, et l’entreprise reste micro ou petite si le total ainsi obtenu passe sous les seuils — sauf si 25 % au moins de son capital ou de ses droits de vote sont détenus par des organismes publics, auquel cas la recommandation écarte le statut de PME quelle que soit sa taille. Cette protection ne couvre en outre que ce délai précis, pas les autres manquements.

Vos dates

La troisième date, le 11 juin 2026, est déjà passée : elle ne concernait que la désignation des organismes chargés d’évaluer la conformité. Deux échéances vous restent.

Le 11 septembre 2026, l’obligation de signalement entrera en application : toute vulnérabilité activement exploitée et tout incident grave devront être notifiés, la première alerte dans les vingt-quatre heures suivant le moment où vous en avez connaissance. Un point mérite d’être souligné, parce qu’il surprend : cette obligation vise aussi les produits déjà mis sur le marché avant le 11 décembre 2027 (Art. 69 § 3). Votre catalogue existant est concerné, pas seulement vos futures versions. Le détail de ce signalement — à qui il s’adresse, ce que contient la première alerte, comment court l’horloge — fait l’objet d’un article distinct de ce blog, consacré à l’Art. 14.

Le 11 décembre 2027, l’ensemble des exigences essentielles de l’annexe I s’appliquera : l’annexe I est la liste jointe au règlement qui énonce ce qu’un produit doit satisfaire — mise sur le marché sans vulnérabilité exploitable connue, configuration de sécurité par défaut, possibilité de corriger les vulnérabilités par des mises à jour, protection contre les accès non autorisés, confidentialité des données, entre autres. Elle s’accompagne du marquage CE, la marque que vous apposez pour déclarer que le produit satisfait aux exigences applicables.

Par où commencer

Si les trois réponses vous placent dans le périmètre, deux actions valent d’être engagées avant le 11 septembre 2026, parce qu’elles conditionnent tout le reste.

• Savoir de quoi votre produit est fait. L’obligation de signalement porte sur les vulnérabilités activement exploitées : sans inventaire de vos composants et de leurs versions, vous ne pouvez pas savoir si une vulnérabilité publiée vous concerne, ni dans quel délai.
• Décider qui reçoit l’alerte et qui décide. Le délai de vingt-quatre heures court à partir du moment où vous avez connaissance du fait. Une chaîne de décision non désignée à l’avance consomme ce délai à chercher un interlocuteur.

Quelques configurations restent sans réponse écrite : un produit développé sur mesure pour un client unique, un produit vendu hors de l’Union mais accessible depuis l’Union, une version bêta distribuée pour test — l’Art. 4 § 3 prévoit pour cette dernière un régime particulier, le temps nécessaire aux essais. Aucun des 67 exemples de la note de la Commission ne les traite. Si votre cas est l’un de ceux-là, les trois questions ci-dessus restent le bon point de départ : elles vous situent, et c’est sur cette base que l’analyse se poursuit.