Une lecture courante du règlement (UE) 2024/2847 amène les éditeurs de solutions SaaS à conclure qu’ils ne sont pas concernés par le Cyber Resilience Act. La logique est apparemment simple : le CRA s’applique aux produits avec éléments numériques mis sur le marché, et les services en mode cloud relèveraient plutôt de la directive NIS2. Cette lecture est exacte dans son principe. Elle est dangereusement incomplète dans son application pratique.
Beaucoup d’éditeurs SaaS, particulièrement dans les secteurs régulés (santé, finance, industrie, automatisation), ne sont pas en réalité des services SaaS purs. Ils combinent une plateforme centrale en mode cloud — qui relève bien de NIS2 — et un ou plusieurs composants logiciels installés chez l’utilisateur : agent de collecte, agent de chiffrement, application mobile, client lourd, plugin navigateur, librairie embarquée dans le produit du client. Ces composants installés sont, eux, des produits avec éléments numériques mis sur le marché. Ils relèvent du CRA.
Trois cas typiques de basculement
Premier cas : l’éditeur d’une plateforme de télésurveillance santé. La plateforme centrale agrège et analyse les données médicales remontées par des dispositifs connectés. Côté patient, un boîtier ou une application mobile collecte ces données et les transmet via le réseau Internet. Le boîtier et l’application mobile sont des produits avec éléments numériques au sens du CRA. La plateforme centrale, en mode SaaS, relève de NIS2 si l’éditeur dépasse les seuils. Mais l’éditeur ne peut pas se déclarer « hors CRA » sous prétexte qu’il vend un service : il vend en réalité aussi des produits, et ces produits sont en première ligne.
Deuxième cas : l’éditeur d’une plateforme de gestion d’entrepôt de données de santé pour des médecins généralistes ou des établissements de soins. La plateforme centrale est en SaaS, mais les médecins installent localement un agent de chiffrement qui collecte les données depuis leur logiciel métier et les transmet de manière sécurisée à la plateforme centrale. L’agent installé localement est un produit avec éléments numériques. Si une vulnérabilité de cet agent permet à un attaquant de compromettre le poste du médecin ou d’extraire des données patient, c’est l’éditeur qui en porte la responsabilité au titre du CRA.
Troisième cas : l’éditeur d’une solution d’analyse industrielle qui se connecte aux automates programmables et aux capteurs en environnement OT. La connexion peut passer par un boîtier de collecte installé chez le client, ou par un logiciel agent déployé sur un PC industriel, ou par un module ajouté à la configuration de l’automate. Ces éléments installés chez le client sont des produits CRA, indépendamment du fait que les données soient ensuite analysées dans une plateforme SaaS.
La justification dans le texte du règlement
Le règlement définit en son article 3 le « produit comportant des éléments numériques » comme « tout produit logiciel ou matériel et ses solutions de traitement de données à distance, y compris les composants logiciels ou matériels devant être mis sur le marché séparément ». Cette définition inclut explicitement les composants distribués séparément. Un agent installé chez le client est un composant logiciel distribué séparément de la plateforme SaaS centrale, même s’il est conçu pour fonctionner en interaction avec elle.
Par ailleurs, l’article 2 du règlement précise les exclusions. Les services en mode SaaS pur, dépourvus de composant installé chez l’utilisateur, sont effectivement hors champ. Les services SaaS qui distribuent un agent, une application mobile, un client lourd ou tout autre composant installé ne bénéficient pas de cette exclusion : la partie distribuée du dispositif est dans le champ.
Les conséquences opérationnelles pour l’éditeur concerné
Un éditeur qui se retrouve dans cette configuration mixte (plateforme SaaS centrale + composants distribués) doit traiter deux régimes réglementaires distincts. La plateforme centrale relève de NIS2 si l’éditeur dépasse les seuils des Entités Importantes ou Essentielles. Les composants distribués relèvent du CRA et doivent respecter l’ensemble des exigences essentielles de l’Annexe I.
Concrètement, cela signifie que l’éditeur doit, pour chaque composant distribué, conduire l’analyse de risque cyber prévue à l’article 13, documenter le dossier technique conformément à l’Annexe V et VI, identifier la classification du produit (par défaut, Important I, Important II, ou Critique), apposer le marquage CE, rédiger la déclaration UE de conformité, mettre en œuvre un processus de gestion coordonnée des vulnérabilités, notifier les vulnérabilités activement exploitées à l’ENISA dans les vingt-quatre heures à compter du 11 septembre 2026, et générer le SBOM.
Cette charge n’est pas négligeable. Pour un éditeur qui n’aurait pas anticipé cette qualification de ses composants distribués, le délai de mise en conformité est court : l’obligation de notification des vulnérabilités est effective dès septembre 2026, et l’ensemble du régime CRA s’applique à compter du 11 décembre 2027.
Comment vérifier votre situation
Pour les éditeurs qui se sont jusqu’ici considérés hors du périmètre CRA, trois questions simples permettent de procéder à une vérification rapide.
Première question : votre solution comporte-t-elle un ou plusieurs composants installés chez vos utilisateurs, en dehors de la plateforme centrale en cloud ? Application mobile, agent de collecte, client lourd, plugin navigateur, librairie intégrée chez le client, boîtier physique, module embarqué. Si la réponse est oui, vous avez probablement au moins un produit CRA dans votre portefeuille.
Deuxième question : ces composants sont-ils distribués au sein de l’Union européenne ? Si oui, le CRA s’applique. Si la distribution est strictement extérieure à l’UE, l’analyse est différente.
Troisième question : ces composants traitent-ils des données qui peuvent transiter ou être stockées sur le réseau, directement ou indirectement ? La réponse est presque toujours oui pour les agents et applications connectés, mais la formulation explicite est utile pour borner le périmètre.
Si les trois réponses sont oui, votre stratégie de conformité doit être révisée pour intégrer le double régime CRA / NIS2. Cette révision peut représenter un effort significatif si elle est faite tardivement, mais elle reste largement gérable si elle est anticipée en 2026.
En conclusion
La frontière entre service SaaS et produit avec éléments numériques n’est pas une frontière entre deux mondes étanches. C’est une frontière qui traverse la plupart des solutions modernes. Un éditeur qui distribue des composants chez ses clients pour leur fournir un service est, du point de vue du droit européen, à la fois un fournisseur de service (NIS2) et un fabricant de produits (CRA).
Cette double qualification n’est pas anecdotique. Elle conditionne des obligations très différentes et des sanctions cumulatives en cas de manquement. Pour les éditeurs qui ne se sont pas encore posé sérieusement la question de leur exposition CRA, le bon moment pour le faire est maintenant, avant que l’échéance de septembre 2026 sur la notification des vulnérabilités rende l’absence de préparation manifeste.
Sources : règlement (UE) 2024/2847 du 23 octobre 2024 (CRA), articles 2, 3 et 14 ; directive (UE) 2022/2555 (NIS2). Cet article n’est pas un avis juridique.
Commentaires récents