Le Cyber Resilience Act (reglement (UE) 2024/2847) a provoque une onde de choc chez les editeurs de logiciels europeens. Mais pour les fournisseurs de solutions SaaS, la situation est plus nuancee qu’il n’y parait. Le CRA cible les produits comportant des elements numeriques – pas les services. Cette distinction, apparemment simple, masque en realite une frontiere poreuse que tout CTO d’un editeur SaaS doit comprendre avec precision.

Cet article analyse le champ d’application du CRA du point de vue specifique des editeurs SaaS, identifie les situations ou le reglement s’applique malgre tout, et formule des recommandations concretes 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, defini a l’article 2, vise les produits comportant des elements numeriques mis a disposition sur le marche europeen. L’article 3, point 1, definit ces produits comme tout produit logiciel ou materiel, ainsi que ses solutions de traitement de donnees a distance, y compris les composants logiciels ou materiels mis sur le marche separement.

Le considerant 12 du reglement precise explicitement que les solutions SaaS, en tant que services fournis a distance, ne constituent pas en elles-memes des produits comportant des elements numeriques. Le legislateur europeen a fait un choix delibere : le CRA regule les produits, pas les services.

La logique est coherente avec l’architecture reglementaire europeenne. Les services cloud relevent d’un autre cadre – principalement la directive NIS2 – qui impose ses propres obligations de cybersecurite aux fournisseurs de services numeriques. Le CRA n’avait pas vocation a faire doublon.

En resume : si votre solution est integralement delivree sous forme de service distant, sans composant logiciel distribue aux utilisateurs finaux, le CRA ne vous concerne pas directement en tant que fabricant.

Quand un editeur SaaS entre malgre tout dans le champ du CRA

La reponse “le SaaS est hors du CRA” serait trop simple. Plusieurs scenarios font basculer un editeur SaaS dans le champ d’application du reglement. Il convient de les examiner un par un.

1. Le client lourd ou l’application compagnon

Si votre solution SaaS s’accompagne d’une application desktop, d’un client mobile ou de tout composant logiciel telecharge et installe sur le poste de l’utilisateur, ce composant est un produit comportant des elements numeriques. Il tombe sous le CRA.

C’est le cas le plus frequent. De nombreux editeurs SaaS proposent des applications iOS ou Android, des extensions de navigateur, des agents de collecte installes 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, independamment du fait que la logique metier principale reside dans le cloud.

2. L’option de deploiement on-premise

Certains editeurs SaaS proposent egalement leur solution en version auto-hebergee (on-premise) pour repondre aux exigences de certains clients. Cette version distribuee est un produit logiciel au sens du reglement. L’editeur qui la commercialise est fabricant au sens du CRA et doit respecter l’ensemble des obligations applicables : evaluation de conformite, gestion des vulnerabilites, documentation technique, marquage CE.

Le fait que la meme solution existe egalement en mode SaaS ne change rien. C’est la version distribuee qui cree l’obligation.

3. Le SaaS integre a un produit materiel

Lorsqu’un service cloud constitue une composante indissociable du fonctionnement d’un produit comportant des elements numeriques, il entre dans le champ du CRA en tant que “solution de traitement de donnees a distance” au sens de l’article 3. C’est le cas, par exemple, d’une plateforme cloud qui gere les mises a jour firmware d’objets connectes, ou d’un backend SaaS sans lequel un dispositif IoT ne peut pas fonctionner.

Dans cette configuration, le fabricant du produit materiel doit integrer le composant cloud dans son evaluation de conformite. Si vous fournissez ce service cloud, vous etes concerne en tant que maillon de la chaine.

4. Les API et SDK distribues

Si votre plateforme SaaS met a disposition des SDK, des bibliotheques ou des composants logiciels que vos clients integrent dans leurs propres produits, ces composants sont des produits au sens du CRA lorsqu’ils sont mis sur le marche separement. Vous devenez alors fabricant pour ces composants specifiques.

NIS2 : le cadre applicable aux services cloud purs

Pour les editeurs SaaS dont la solution reste integralement dans le cloud, c’est la directive NIS2 qui constitue le cadre reglementaire pertinent en matiere de cybersecurite. Les fournisseurs de services d’informatique en nuage sont designes comme entites essentielles ou importantes selon leur taille et leur criticite.

Les obligations NIS2 portent notamment sur la gestion des risques de cybersecurite, le signalement des incidents, la securite de la chaine d’approvisionnement et la gouvernance. Le calendrier de transposition dans les droits nationaux est en cours, avec des echeances variables selon les Etats membres.

Pour un editeur SaaS, NIS2 et le CRA ne sont pas interchangeables. Ils couvrent des perimetres distincts et peuvent se cumuler si l’editeur distribue a la fois un service cloud et des composants logiciels.

Les implications de la chaine d’approvisionnement

Meme lorsqu’un editeur SaaS reste hors du champ direct du CRA, les effets indirects du reglement sur sa relation commerciale sont considerables.

Vos clients CRA-regules vont exiger des garanties

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

Concretement, si vos clients sont des fabricants de produits soumis au CRA et qu’ils integrent votre service dans leur chaine de valeur – meme indirectement --, ils vous demanderont des garanties documentees : politiques de gestion des vulnerabilites, delais de correction, processus de notification, conformite a des standards comme l’ISO 27001 ou le SOC 2.

L’utilisation de composants open source soumis au CRA

Si votre plateforme SaaS integre des composants logiciels open source qui sont eux-memes dans le champ du CRA (parce qu’ils sont mis sur le marche par un gestionnaire de logiciels open source au sens de l’article 3, point 14), vous devez suivre les notifications de vulnerabilites et les mises a jour de ces composants. Le SBOM (Software Bill of Materials) de vos dependances devient un outil de pilotage incontournable.

Recommandations pratiques pour les CTO d’editeurs SaaS

Face a cette situation reglementaire complexe, une approche methodique s’impose.

1. Cartographier precisement votre perimetre 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. Evaluer votre exposition NIS2. Si votre service cloud entre dans les categories d’entites essentielles ou importantes de NIS2, anticipez les obligations de gestion des risques, de notification d’incidents et de gouvernance.

3. Structurer votre gestion des vulnerabilites. Que vous soyez directement concerne par le CRA ou non, vos clients regules l’exigeront. Mettez en place un processus formalise de detection, evaluation, correction et notification des vulnerabilites sur l’ensemble de vos composants.

4. Documenter votre chaine d’approvisionnement logicielle. Maintenez un SBOM a jour pour l’ensemble de vos dependances. Identifiez les composants tiers susceptibles d’etre dans le champ du CRA et suivez leur statut de conformite.

5. Preparer vos reponses contractuelles. Vos clients B2B soumis au CRA integreront des clauses de conformite dans leurs contrats. Anticipez en preparant des fiches de conformite, des attestations de securite et des engagements de niveau de service sur la gestion des vulnerabilites.

6. Outiller votre conformite multi-reglementaire. Un editeur SaaS peut etre simultanement concerne par le RGPD, NIS2, le CRA (pour ses composants distribues), voire des reglementations sectorielles. Des outils comme Legiscope permettent de centraliser la gestion de ces obligations croisees et d’eviter les angles morts dans le pilotage de la conformite.

Le calendrier a retenir

Les premieres obligations du CRA entrent en application de maniere echelonnee :

• 11 septembre 2026 : obligation de signalement des vulnerabilites activement exploitees et des incidents graves.
• 11 decembre 2027 : application de l’ensemble des exigences, y compris l’evaluation de conformite, la documentation technique et le marquage CE.

Pour les editeurs SaaS qui distribuent des composants logiciels, le calendrier est le meme que pour tout fabricant. L’anticipation est indispensable, notamment pour les processus d’evaluation de conformite qui peuvent etre longs a mettre en place.

Conclusion

La position des editeurs SaaS face au CRA est une question de perimetre, pas de principe. Le service cloud pur reste hors du champ du reglement – 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 reel pour les editeurs SaaS n’est pas seulement de determiner s’ils sont directement concernes par le CRA. C’est de comprendre que le reglement restructure les exigences de cybersecurite de l’ensemble de leur ecosysteme – clients, partenaires, fournisseurs. S’y preparer n’est pas une option, c’est une condition de competitivite sur le marche europeen.