CRA pour SaaS : portée, actions détenues et preuves

Le seul modèle d’abonnement ne permet pas de répondre de manière fiable à la question « le SaaS relève-t-il du CRA ? ». Le CRA réglemente les produits comportant des éléments numériques, tandis que les services d’informatique en nuage, dont le SaaS, sont aussi traités dans le cadre de NIS2. La question centrale est ce qu’est le produit, quel logiciel est mis à disposition sur le marché et si un service à distance fait partie intégrante d’une fonction du produit.

Partez de l’architecture et du mode de fourniture, plutôt que de l’étiquette commerciale.

Deux questions souvent confondues

Le service en nuage lui-même est-il un produit comportant des éléments numériques au sens du CRA ?

Ne le supposez pas simplement parce que les utilisateurs accèdent au logiciel depuis un navigateur.

Le service à distance fait-il partie d’un autre produit comportant des éléments numériques ?

Cela peut être le cas. Le CRA définit une « solution de 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 comportant des éléments numériques d’exécuter l’une de ses fonctions.

Les considérants du CRA donnent l’exemple d’une application mobile nécessitant l’accès à une API ou à une base de données fournie par un service développé par le fabricant. Dans cette situation, le service peut entrer dans le périmètre du produit en tant que solution de traitement de données à distance.

Cartographiez l’architecture avant de décider du champ d’application

Pour une offre SaaS, décrivez séparément :

le logiciel livré au client — agent, application de bureau ou mobile, équipement, extension, bibliothèque ;
l’interface web — ce à quoi l’utilisateur accède dans le navigateur ;
le serveur / l’API — fonctions exécutées à distance ;
les bases de données et traitements — éléments à distance nécessaires aux fonctions du produit ;
les intégrations tierces — ce qui relève de la responsabilité du fabricant et ce qui n’en relève pas ;
le modèle de marché — qui met la solution à disposition et sous quelle marque ;
les mises à jour — éléments modifiés par le fabricant et effets sur la sécurité ;
l’assistance — durée de maintenance de chaque composant pertinent.

Cette cartographie soutient l’évaluation du champ d’application et la documentation technique ultérieure.

Trois exemples de situations

A. Service en nuage accessible uniquement par navigateur

L’utilisateur se connecte à un service dans un navigateur sans recevoir de produit logiciel ou matériel distinct. Ne passez pas directement de « SaaS » à « le CRA s’applique ». Vérifiez les définitions du CRA et les orientations actuelles de la Commission, puis évaluez séparément les obligations NIS2 pertinentes pour l’organisation.

B. Produit logiciel avec un serveur exploité par le fabricant

Le client reçoit une application ou un composant dont une fonction importante ne peut pas fonctionner sans un serveur conçu par le fabricant. Le traitement à distance peut faire partie du produit au sens du CRA.

C. Un produit utilise un service en nuage indépendant

Lorsque le service est conçu et développé en dehors de la responsabilité du fabricant, le lien peut différer de celui d’un serveur propre au fabricant. « Les données sont dans le cloud » ne répond pas, à lui seul, à la question du CRA.

Ces exemples servent à s’orienter ; ils ne constituent pas des conclusions juridiques pour une architecture précise.

Pourquoi cela compte dès maintenant sur le plan opérationnel

L’article 14 s’applique depuis le 11 septembre 2026 et couvre les produits concernés mis sur le marché avant le 11 décembre 2027.

Si une offre comprend une application, un composant et un serveur, l’équipe doit savoir, pour le produit et la version concernés :

où arrivent les signalements de vulnérabilités ;
qui effectue le triage ;
comment l’impact sur le produit est évalué ;
comment les correctifs sont publiés ;
comment les utilisateurs sont informés ;
quand l’évaluation du besoin de signalement CRA est déclenchée.

Sans limites claires du produit, il est difficile de définir T0, les responsabilités ou le périmètre d’une notification.

Informations à consigner dans une décision de champ d’application SaaS

Schéma délimitant le produit ;
éléments livrés localement ;
éléments exécutés à distance ;
fonction assurée par chaque élément ;
effet de la suppression de l’élément à distance sur l’exécution d’une fonction du produit ;
responsabilité du développement de l’élément à distance ;
modèle de distribution et de marque ;
rôle de l’organisation ;
fondement juridique et orientations utilisés pour l’évaluation ;
personne approuvant le résultat ;
prochaine date de revue.

Comment Pulsar peut aider

Pulsar permet de conserver la décision de champ d’application et les documents justificatifs, puis de relier le résultat aux risques, documents, actions, fournisseurs et preuves. Lorsque l’architecture change dans une version ultérieure, la décision peut être soumise à une nouvelle revue plutôt que de rester un PDF obsolète.

Pulsar ne doit pas fournir de manière autonome une réponse juridiquement définitive « le CRA s’applique / ne s’applique pas » sans fondement pouvant être examiné et sans approbation humaine.

Découvrez Pulsar GRC dans un processus d’évaluation

Guides associés

Décrire la frontière technique sans confondre les contrats

La cartographie d’une offre SaaS doit faire apparaître les éléments que le client reçoit, les fonctions exécutées à distance et les services fournis par des tiers. Rassemblez les faits avec les responsables du produit, du développement et des contrats. Une description commerciale peut réduire toute l’offre à un abonnement ; l’architecture peut contenir un agent local, une application mobile ou un composant livré avec un équipement. Ces différences influencent les questions à examiner.

Pour chaque fonction, demandez ce qui se passe si le service à distance est supprimé. L’application conserve-t-elle cette fonction, en perd-elle une partie ou devient-elle inutilisable ? Consignez la réponse avec une description technique vérifiable. Cette observation soutient l’analyse de la solution de traitement de données à distance ; elle ne constitue pas un test juridique autonome. La définition du règlement et la responsabilité de conception restent déterminantes pour la conclusion.

Exemple proposé : un agent local et son portail

Dans un scénario hypothétique, un éditeur fournit un agent installé chez le client et un portail qui traite les données reçues. L’agent et le portail sont développés sous sa responsabilité. L’équipe doit définir les fonctions respectives et les versions concernées. Elle doit aussi savoir quelle partie reçoit les correctifs, comment les versions incompatibles sont traitées et qui prend les décisions de sécurité. Le nom « SaaS » ne décrit pas cette organisation de produit.

Une seconde offre peut être accessible uniquement par un navigateur, sans autre produit logiciel ou matériel distinct fourni au client. Son examen peut conduire à des questions différentes. Ne recopiez pas la conclusion du premier dossier. Décrivez les éléments effectivement fournis et vérifiez les définitions, les exclusions éventuelles et les orientations applicables. Les obligations de l’organisation au titre de NIS2 demandent une analyse séparée selon sa transposition nationale et ses activités.

Ne pas laisser la frontière varier selon l’interlocuteur

Le support, l’équipe commerciale et le développement doivent utiliser une description cohérente du produit. Si le contrat présente une fonction comme essentielle mais que le dossier CRA la décrit comme indépendante, faites examiner cette différence. Elle peut révéler une documentation incomplète ou une appréciation incorrecte de la relation entre les éléments. Le dossier doit expliquer la situation réelle plutôt que retenir la formulation la plus commode pour conclure.

Conservez les versions des documents qui ont servi à la décision. Un contrat mis à jour après une nouvelle fonctionnalité ne doit pas effacer la base d’une analyse ancienne. Reliez la modification au responsable du dossier et au motif de la revue. Cette méthode facilite aussi les échanges avec un client qui demande pourquoi une offre et une autre sont traitées différemment alors qu’elles portent la même marque.

Relier les versions locales et les versions distantes

Une publication du service à distance peut affecter plusieurs versions de l’application distribuée. Identifiez cette relation pour les fonctions pertinentes et les risques connus. Les essais doivent examiner les combinaisons réellement prises en charge, selon une méthode définie par l’équipe. Un test du serveur le plus récent ne montre pas à lui seul le comportement d’un agent plus ancien encore utilisé chez les clients. Conservez les limites de couverture des essais.

Ce lien est également utile pour le traitement d’une vulnérabilité. Le responsable doit savoir si la correction est réalisée côté service, exige une mise à jour locale ou concerne les deux. Documentez les versions corrigées et les instructions communiquées aux utilisateurs. La présence d’un correctif dans un dépôt interne ne démontre pas que tous les clients concernés disposent de la mesure. L’équipe doit distinguer préparation, publication et déploiement lorsqu’elle apprécie le résultat.

Examiner les dépendances tierces dans leur contexte

Une prestation externe peut fournir l’hébergement, une fonction de paiement ou un autre service utilisé par le produit. Décrivez la fonction, la responsabilité du fournisseur et les effets d’une indisponibilité ou d’un changement. Cette description aide à l’analyse du périmètre, mais aussi à la continuité et à la sécurité. Le fait que la prestation soit indépendante n’efface pas les risques de votre produit ni les engagements que vous avez pris envers les clients.

Vérifiez les informations nécessaires à la décision : contrat, documentation technique, versions pertinentes et modalités de notification d’un changement. Une page publique du fournisseur peut servir de contexte ; elle n’est pas toujours une preuve des engagements applicables à votre contrat. Enregistrez les différences et les questions ouvertes. La décision de qualification doit rester compréhensible si le fournisseur ou l’architecture change dans la prochaine version de l’offre.

Garder un parcours commun pour les informations de sécurité

Même quand le périmètre CRA demande encore une analyse, l’organisation peut organiser la réception des informations de sécurité et leur traitement. Identifiez le produit, la version, la source et le responsable technique. Lorsque la qualification est approuvée, les responsabilités de signalement peuvent être reliées au même dossier. Cette continuité évite de conserver une alerte dans un canal informel pendant que plusieurs personnes débattent de l’étiquette juridique du service.

La décision de notifier au titre du CRA doit suivre les critères et responsabilités applicables. Elle ne se déduit ni d’une alerte de scanner ni du fait qu’un client a ouvert un ticket urgent. Gardez les faits disponibles, la raison de la conclusion et la date de la décision. Si une information nouvelle apparaît, le dossier doit pouvoir être réexaminé sans réécrire l’historique précédent.

Ce qu’une démonstration peut effectivement vérifier

Une démonstration de Pulsar GRC peut utiliser une architecture fictive avec un agent, un portail et un fournisseur. Vérifiez si les participants relient la décision de périmètre aux risques, documents et actions. Demandez à une autre personne autorisée de retrouver les raisons de la conclusion. Le logiciel ne doit pas être utilisé comme un moteur donnant une qualification juridique autonome à partir du seul nom de l’offre.

Les fonctions d’IA produisent des brouillons à examiner. Pulsar ne promet pas de récupérer automatiquement les preuves depuis votre cloud ni de garantir la conformité ou une certification. L’essai de quatorze jours avec moyen de paiement requis doit être évalué selon l’offre actuelle. Le critère utile reste votre capacité à conserver une décision fondée sur des faits, à identifier les informations manquantes et à organiser la prochaine revue.

Répéter une exigence et un résultat examiné

Utilisez un produit fictif composé d’un client de bureau et d’un backend exploité par le fabricant. Il s’agit d’un exemple d’architecture synthétique, et non d’une déclaration selon laquelle chaque service SaaS relève de la CRA. Enregistrez d’abord la fonction du produit, le rôle du backend et la question qui nécessite un examen qualifié de la portée. Conservez la source légale et la décision de révision avec le dossier.

Une fois que les hypothèses d’applicabilité de l’exemple sont explicites, choisissez une exigence et une action pertinentes. Attribuez un propriétaire et une date, puis définissez quelles preuves démontreraient le résultat de l’action. Par exemple, l’action peut examiner une règle d’accès au produit et joindre la description et le résultat du test fictif. Une personne autorisée examine les preuves par rapport au critère énoncé. Un fichier joint à l’action ne complète pas cet examen à lui seul.

Dans Pulsar, relisez l’exigence, l’action liée, la version source et les preuves après l’enregistrement. Demandez à un collègue d’identifier la prochaine responsabilité sans explication de l’auteur. Le résultat concret de l’essai est un fragment inspectable du travail sur le produit. Il ne s’agit pas d’une classification CRA automatique, d’une évaluation de la conformité, d’une déclaration CE ou d’un dépôt auprès d’une autorité.

Pulsar propose un essai de 14 jours nécessitant un mode de paiement. Vérifiez le forfait sélectionné, le prix après l’essai et les conditions d’annulation avant de confirmer. Utilisez des enregistrements synthétiques pour cet exercice ; une véritable décision concernant un produit nécessite votre propre architecture et un examen qualifié.

Sources

État documentaire du guide : 2 octobre 2026. Vérifiez les instructions opérationnelles actuelles avant toute notification.

Pulsar GRC — accès, isolation des données et export (polonais) Sources vérifiées: 2026-10-10.
CRA — Regulation (EU) 2024/2847 — Portée du produit et obligations applicables.
European Commission — CRA guidance, 27 July 2026 — Orientations officielles sur la portée et la mise en œuvre.
European Commission — CRA legislative summary — Portée, gestion des vulnérabilités et dates d’application.
Pulsar GRC — features — Exigences, actions et preuves enregistrées.
Pulsar GRC — pricing — Conditions d’essai.
Portée du produit publié et conditions d’essai — Portée du produit publié et conditions d’essai. Révisez les conditions et démarrez l’essai de 14 jours

Vulnérabilités des composants IoT : fournisseurs, décisions et correctifs

KSC/NIS2 polonais pour les fournisseurs informatiques : évaluation et registre d’actions

API et MCP dans GRC : définir l’accès avant de connecter les systèmes