CRA pour les éditeurs SaaS : quelles obligations de cybersécurité ?

Le Cyber Résilience Act (règlement (UE) 2024/2847) a provoqué une onde de choc chez les éditeurs de logiciels européens. Mais pour les fournisseurs de solutions SaaS, la situation est plus nuancée qu’il n’y paraît. Le CRA cible les produits comportant des éléments numériques – pas les services. Cette distinction, apparemment simple, masque en réalité une frontiere poreuse que tout CTO d’un éditeur SaaS doit comprendre avec précision.

Cet article analyse le champ d’application du CRA du point de vue spécifique des éditeurs SaaS, identifie les situations ou le règlement s’applique malgré tout, et formule des recommandations concrètes pour anticiper les obligations.

Le principe : les services cloud purs sont hors du champ du CRA

Le CRA repose sur une distinction structurante. Son champ d’application, défini à l’article 2, vise les produits comportant des éléments numériques mis à disposition sur le marché européen. L’article 3, point 1, définit ces produits comme tout produit logiciel ou matériel, ainsi que ses solutions de traitement de données à distance, y compris les composants logiciels ou matériels mis sur le marché séparément.

Le considérant 12 du règlement precise explicitement que les solutions SaaS, en tant que services fournis à distance, ne constituent pas en elles-mêmes des produits comportant des éléments numériques. Le législateur européen a fait un choix délibéré : le CRA régule les produits, pas les services.

La logique est cohérente avec l’architecture réglementaire européenne. Les services cloud relèvent d’un autre cadre – principalement la directive NIS2 – qui impose ses propres obligations de cybersécurité aux fournisseurs de services numériques. Le CRA n’avait pas vocation à faire doublon.

En résumé : si votre solution est intégralement délivrée sous forme de service distant, sans composant logiciel distribue aux utilisateurs finaux, le CRA ne vous concerné pas directement en tant que fabricant.

Quand un éditeur SaaS entre malgré tout dans le champ du CRA

La réponse “le SaaS est hors du CRA” serait trop simple. Plusieurs scénarios font basculer un éditeur SaaS dans le champ d’application du règlement. Il convient de les examiner un par un.

1. Le client lourd ou l’application compagnon

Si votre solution SaaS s’accompagné d’une application desktop, d’un client mobile ou de tout composant logiciel téléchargé et installé sur le posté de l’utilisateur, ce composant est un produit comportant des éléments numériques. Il tombe sous le CRA.

C’est le cas le plus fréquent. De nombreux éditeurs SaaS proposent des applications iOS ou Android, des extensions de navigateur, des agents de collecte installés sur les postes clients, ou des outils CLI distribues via des gestionnaires de paquets. Chacun de ces composants est un produit au sens du CRA, indépendamment du fait que la logique métier principale réside dans le cloud.

2. L’option de déploiement on-premise

Certains éditeurs SaaS proposent également leur solution en version auto-hébergée (on-premise) pour répondre aux exigences de certains clients. Cette version distribuee est un produit logiciel au sens du règlement. L’éditeur qui la commercialise est fabricant au sens du CRA et doit respecter l’ensemble des obligations applicables : évaluation de conformité, gestion des vulnérabilités, documentation technique, marquage CE.

Le fait que la même solution existe également en mode SaaS ne changé rien. C’est la version distribuee qui créé l’obligation.

3. Le SaaS intègre à un produit matériel

Lorsqu’un service cloud constitue une composante indissociable du fonctionnement d’un produit comportant des éléments numériques, il entre dans le champ du CRA en tant que “solution de traitement de données à distance” au sens de l’article 3. C’est le cas, par exemple, d’une plateforme cloud qui gère les mises à jour firmware d’objets connectés, ou d’un backend SaaS sans lequel un dispositif IoT ne peut pas fonctionner.

Dans cette configuration, le fabricant du produit matériel doit intégrer le composant cloud dans son évaluation de conformité. Si vous fournissez ce service cloud, vous êtes concerné en tant que maillon de la chaîne.

4. Les API et SDK distribues

Si votre plateforme SaaS met à disposition des SDK, des bibliotheques ou des composants logiciels que vos clients intègrent dans leurs propres produits, ces composants sont des produits au sens du CRA lorsqu’ils sont mis sur le marché séparément. Vous devenez alors fabricant pour ces composants spécifiques.

NIS2 : le cadre applicable aux services cloud purs

Pour les éditeurs SaaS dont la solution reste intégralement dans le cloud, c’est la directive NIS2 qui constitue le cadre réglementaire pertinent en matière de cybersécurité. Les fournisseurs de services d’informatique en nuage sont désignés comme entités essentielles ou importantes selon leur taille et leur criticité.

Les obligations NIS2 portent notamment sur la gestion des risques de cybersécurité, le signalement des incidents, la sécurité de la chaîne d’approvisionnement et la gouvernance. Le calendrier de transposition dans les droits nationaux est en cours, avec des échéances variables selon les États membres.

Pour un éditeur SaaS, NIS2 et le CRA ne sont pas interchangeables. Ils couvrent des périmètres distincts et peuvent se cumuler si l’éditeur distribue à la fois un service cloud et des composants logiciels.

Les implications de la chaîne d’approvisionnement

Même lorsqu’un éditeur SaaS reste hors du champ direct du CRA, les effets indirects du règlement sur sa relation commerciale sont considérables.

Vos clients CRA-regules vont exiger des garanties

Les fabricants soumis au CRA ont une obligation de diligence sur l’ensemble de leur chaîne d’approvisionnement. L’article 13, paragraphe 5, impose aux fabricants de s’assurer que les composants tiers intégrés dans leurs produits ne compromettent pas la conformité de ces produits.

Concrètement, si vos clients sont des fabricants de produits soumis au CRA et qu’ils intègrent votre service dans leur chaîne de valeur – même indirectement --, ils vous demanderont des garanties documentées : politiques de gestion des vulnérabilités, délais de correction, processus de notification, conformité à des standards comme l’ISO 27001 ou le SOC 2.

L’utilisation de composants open source soumis au CRA

Si votre plateforme SaaS intègre des composants logiciels open source qui sont eux-mêmes dans le champ du CRA (parce qu’ils sont mis sur le marché par un gestionnaire de logiciels open source au sens de l’article 3, point 14), vous devez suivre les notifications de vulnérabilités et les mises à jour de ces composants. Le SBOM (Software Bill of Materials) de vos dépendances devient un outil de pilotage incontournable.

Recommandations pratiques pour les CTO d’éditeurs SaaS

Face à cette situation réglementaire complexe, une approche méthodique s’impose.

1. Cartographier précisément votre périmètre de distribution. Recensez tous les composants logiciels que vous distribuez en dehors de votre infrastructure cloud : applications mobiles, extensions, agents, SDK, outils CLI, versions on-premise. Chacun est potentiellement un produit au sens du CRA.

2. Évaluer votre exposition NIS2. Si votre service cloud entre dans les catégories d’entités essentielles ou importantes de NIS2, anticipez les obligations de gestion des risques, de notification d’incidents et de gouvernance.

3. Structurer votre gestion des vulnérabilités. Que vous soyez directement concerné par le CRA ou non, vos clients regules l’exigeront. Mettez en place un processus formalisé de détection, évaluation, correction et notification des vulnérabilités sur l’ensemble de vos composants.

4. Documenter votre chaîne d’approvisionnement logicielle. Maintenez un SBOM à jour pour l’ensemble de vos dépendances. Identifiez les composants tiers susceptibles d’être dans le champ du CRA et suivez leur statut de conformité.

5. Préparer vos réponses contractuelles. Vos clients B2B soumis au CRA integreront des clauses de conformité dans leurs contrats. Anticipez en préparant des fiches de conformité, des attestations de sécurité et des engagements de niveau de service sur la gestion des vulnérabilités.

6. Outiller votre conformité multi-réglementaire. Un éditeur SaaS peut être simultanément concerné par le RGPD, NIS2, le CRA (pour ses composants distribues), voire des réglementations sectorielles. Des outils comme Legiscope permettent de centraliser la gestion de ces obligations croisées et d’éviter les angles morts dans le pilotage de la conformité.

Le calendrier a retenir

Les premières obligations du CRA entrent en application de manière échelonnée :

• 11 septembre 2026 : obligation de signalement des vulnérabilités activement exploitées et des incidents gravés.
• 11 décembre 2027 : application de l’ensemble des exigences, y compris l’évaluation de conformité, la documentation technique et le marquage CE.

Pour les éditeurs SaaS qui distribuent des composants logiciels, le calendrier est le même que pour tout fabricant. L’anticipation est indispensable, notamment pour les processus d’évaluation de conformité qui peuvent être longs à mettre en place.

Conclusion

La position des éditeurs SaaS face au CRA est une question de périmètre, pas de principe. Le service cloud pur reste hors du champ du règlement – c’est NIS2 qui s’applique. Mais des qu’un composant logiciel est distribue aux utilisateurs, la frontiere est franchie et les obligations du CRA s’imposent.

L’enjeu réel pour les éditeurs SaaS n’est pas seulement de déterminer s’ils sont directement concernés par le CRA. C’est de comprendre que le règlement restructure les exigences de cybersécurité de l’ensemble de leur écosystème – clients, partenaires, fournisseurs. S’y préparer n’est pas une option, c’est une condition de compétitivité sur le marché européen.