Provetry
ENDEDemander l’accès anticipé
Test gratuit
Demander l’accès anticipé

Provetry ouvre en novembre 2026. Le test CRA gratuit, les outils et les guides sont disponibles dès maintenant.

Le CRA et le SaaS : quand le logiciel en ligne est concerné

6 min de lecture

Sur cette page
  1. La règle : le SaaS pur est hors champ
  2. L’exception : le traitement de données à distance
  3. Des exemples
  4. Ce que cela change en pratique
  5. Un test rapide
  6. Ce que fait Provetry
  7. Sources

« Nous sommes une entreprise SaaS, donc le Cyber Resilience Act ne nous concerne pas. » Souvent vrai, parfois non. Le CRA porte sur les produits mis sur le marché ; un logiciel proposé seulement comme service en est en général exclu. Mais la partie en ligne d’un produit est traitée comme une partie de ce produit, et beaucoup d’entreprises qui se voient comme SaaS livrent aussi quelque chose : une application, un agent, un appareil.

La règle : le SaaS pur est hors champ

Le CRA couvre les produits comportant des éléments numériques mis à disposition sur le marché. Un logiciel auquel on accède seulement comme service, par le réseau, n’est pas « mis à disposition sur le marché » en ce sens, et les considérants confirment que le règlement ne couvre pas le SaaS en tant que tel. La sécurité de ces services relève de la directive NIS2, qui vise les fournisseurs de services d’informatique en nuage et bien des fournisseurs de services numériques en tant qu’entités.

L’exception : le traitement de données à distance

Le CRA définit le traitement de données à distance comme un traitement à distance 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 une de ses fonctions.

Un traitement de données à distance qui répond à cette définition fait partie du produit. Il doit respecter les exigences essentielles de l’annexe I, figurer dans l’évaluation des risques et la documentation technique, et ses vulnérabilités et incidents comptent pour le signalement.

Deux conditions, toutes deux nécessaires :

  1. Vous le concevez ou en êtes responsable. Un service tiers que l’utilisateur choisit lui-même n’est pas votre traitement de données à distance.
  2. Le produit ne peut pas exécuter une fonction sans lui. Si une fonction de l’appareil ou de l’application cesse de marcher quand votre serveur est arrêté, ce serveur est concerné.

Des exemples

Situation Dans le champ du CRA ?
Une application web utilisée seulement dans le navigateur, vendue par abonnement Non : SaaS. NIS2 peut s’appliquer à l’entreprise
Une caméra connectée dont la vision à distance passe par le nuage du fabricant Oui : le service en ligne est un traitement de données à distance de la caméra
Une application mobile vendue ou distribuée dans l’UE, avec sa propre API L’application est un produit ; son API est un traitement de données à distance si les fonctions de l’application en dépendent
Un logiciel de bureau qui vérifie sa licence et synchronise ses réglages par les serveurs de l’éditeur Le logiciel est un produit ; le service de synchronisation est un traitement de données à distance ; un serveur de licences peut l’être aussi, si le logiciel ne peut pas fonctionner sans lui
Une plateforme SaaS qui distribue aussi un agent à installer ou un outil en ligne de commande L’agent ou l’outil est un produit ; la plateforme derrière est concernée dans la mesure où ses fonctions en dépendent
Un site web qui montre la documentation d’un produit Non : le produit n’en a pas besoin pour exécuter ses fonctions
Un appareil qui envoie ses données vers un nuage choisi et exploité par le client L’appareil est concerné ; le nuage du client n’est pas un traitement de données à distance du fabricant

Ce que cela change en pratique

Si vous avez un traitement de données à distance :

  • intégrez le serveur dans l’évaluation des risques du produit, et dans les propriétés de sécurité de l’annexe I (contrôle d’accès, chiffrement, disponibilité, journalisation) ;
  • intégrez ses composants à votre démarche SBOM, ou au moins à votre gestion des vulnérabilités ;
  • traitez les incidents graves du serveur qui touchent la sécurité du produit comme des signalements de l’article 14 ;
  • maintenez le serveur pendant la période d’assistance du produit : l’arrêter plus tôt peut casser les fonctions du produit et ses mises à jour de sécurité.

Si vous êtes en pur SaaS, regardez plutôt NIS2 : selon votre secteur et votre taille, vous pouvez être une entité essentielle ou importante, avec vos propres obligations de gestion des risques et de signalement des incidents. Voir le CRA et NIS2.

Un test rapide

Posez trois questions :

  1. Donnons-nous aux clients quelque chose qui tourne chez eux : une application, un agent, un micrologiciel, une bibliothèque, un outil en ligne de commande ? Si oui, c’est un produit.
  2. A-t-il besoin de nos serveurs pour exécuter une de ses fonctions ? Si oui, ces serveurs sont un traitement de données à distance de ce produit.
  3. Si nous ne proposons qu’un service dans le navigateur, sommes-nous une entité au sens de NIS2 ?

Notre questionnaire gratuit pose ces questions pour chaque produit et vous dit quelles obligations s’appliquent.

Ce que fait Provetry

Quand vous décrivez un produit, vous dites ce que c’est (logiciel, application mobile, micrologiciel, objet connecté, composant) ; le dossier de conformité (offres Pro et Consultant) parcourt ensuite les questions de l’annexe I, où vous pouvez décrire le serveur dont dépend votre produit.

Ce guide est une information générale, pas un conseil juridique.

Sources