CRA et SaaS : qualifier le logiciel et le service distant

L’étiquette « SaaS » ne décide pas du champ du CRA. Un éditeur peut fournir un service distant, une application installée, un agent, un SDK ou une version auto-hébergée. Il faut examiner chaque offre et ses dépendances, puis identifier le produit et l’acteur responsable de sa mise sur le marché.

Service distant ou produit logiciel ?

Dans ses orientations C(2026) 5252 du 27 juillet 2026, § 20–21 et exemples 3–6, la Commission distingue l’application fournie pour exécution dans le système de l’utilisateur du service simplement consulté à distance. Une application web exclusivement accessible par navigateur n’est pas, de ce seul fait, un produit logiciel couvert. Elle peut néanmoins soutenir la fonction d’un produit et relever du traitement distant. Ces orientations sont interprétatives, non contraignantes.

Le règlement (UE) 2024/2847, Art. 2(1) et 3(1) reste la base juridique : produit logiciel ou matériel, connexion prévue ou raisonnablement prévisible à un dispositif ou réseau, mise à disposition sur le marché. Le guide du champ CRA détaille les rôles et exclusions.

Les deux conditions du traitement distant

L’Art. 3(2) vise un traitement à distance dont le logiciel est conçu et développé par le fabricant ou sous sa responsabilité, et dont l’absence empêcherait le produit d’assurer l’une de ses fonctions.

Deux questions doivent donc recevoir une réponse documentée :

1. Quelle fonction du produit dépend de ce traitement ?
2. Qui a conçu et développé le logiciel distant, ou en porte la responsabilité ?

Le produit associé peut être logiciel : l’existence d’un objet physique vendu par l’éditeur n’est pas exigée par cette définition. Le critère vise l’une de ses fonctions, pas uniquement sa fonction principale.

Les orientations, § 195–202, distinguent aussi une solution développée pour le fabricant d’un SaaS tiers standard simplement configuré. Ce dernier n’est pas automatiquement son traitement distant au sens du CRA ; son intégration peut néanmoins créer un risque de composant à évaluer. L’identité de l’hébergeur ne décide pas à elle seule de la qualification.

Partir de ce qui est effectivement fourni au client

Ouvrez le catalogue avec une personne du produit, une personne de l’architecture et une personne qui connaît les contrats. Ne vous limitez pas aux pages tarifaires : relevez ce que le client reçoit réellement, où le code s’exécute, qui le fournit et quelles fonctions sont annoncées. Un même abonnement peut donner accès à plusieurs éléments dont les qualifications diffèrent.

Pour chaque élément, conservez une référence de version et une description suffisamment stable pour être discutée. « Notre application » ne permet pas de savoir si l’on parle du service web, d’un client installé ou de l’ensemble. Un schéma simple peut distinguer ces éléments et les échanges nécessaires à leur fonctionnement.

La décision de périmètre doit ensuite pouvoir être retrouvée dans les documents techniques et commerciaux. Si le contrat présente un agent comme un simple accessoire tandis que l’architecture lui confie une fonction essentielle du service, relevez cet écart. Le nom commercial ne résout pas la qualification juridique ; il sert à retrouver les éléments à examiner.

Une fiche par offre distribuée

La grille suivante est une méthode de travail proposée pour éviter une conclusion unique trop large :

Ajoutez à chaque ligne l’architecture, les contrats, le mode de distribution et la décision motivée. Une simple documentation d’API n’est pas à confondre avec la fourniture d’un composant logiciel.

Constituer une preuve pour chacune des deux conditions

Pour la dépendance fonctionnelle, décrivez la fonction concernée et l’effet de l’absence du traitement distant. Évitez la seule formule « dépend du cloud ». Une description utile précise ce qui ne fonctionnerait plus, pour quels utilisateurs et dans quelle configuration. Elle distingue une fonction du produit d’un simple besoin interne de l’éditeur.

Pour la conception et le développement, rapprochez la description technique des pièces contractuelles. Identifiez le logiciel concerné, son concepteur, son développeur et le rôle du fabricant dans les spécifications. Le nom du fournisseur sur une facture d’hébergement ne répond pas à ces questions. Une clause générale sur la sécurité ne décrit pas non plus nécessairement qui a fait développer l’application.

La feuille ci-dessous est une proposition de dossier interne. Elle aide à conserver un raisonnement vérifiable ; elle ne constitue ni un formulaire officiel ni une présomption de conformité.

Une pièce manquante doit rester visible. Il vaut mieux écrire « responsabilité de développement à confirmer » que transformer un contrat non examiné en réponse négative. Le dossier peut avancer sur les autres éléments pendant que cette question est instruite.

Exemple fictif : une offre, plusieurs éléments à qualifier

L’éditeur fictif Brume fournit un espace web de suivi de travaux et propose un agent installé sur les postes de ses clients pour synchroniser certains fichiers. L’équipe dispose de trois pièces : une fiche commerciale regroupant l’offre, une documentation d’installation de l’agent et un schéma des échanges avec un service distant. Aucun produit réel n’est évalué dans cet exemple.

La première décision consiste à examiner séparément l’agent fourni et le service uniquement consulté dans le navigateur. Il faut ensuite identifier les fonctions de l’agent et les traitements distants dont elles dépendent. Le simple fait que l’espace web reste accessible sans l’agent ne répond pas à la question de savoir si l’agent peut assurer ses propres fonctions sans le distant.

Une inconnue subsiste : le service de synchronisation a-t-il été développé par Brume, pour Brume ou s’agit-il d’un service tiers standard ? Le schéma réseau ne suffit pas à trancher. La note doit demander les pièces de conception et de développement avant de conclure sur ce traitement distant. Elle peut déjà inventorier les risques liés à la dépendance et les versions potentiellement concernées.

Le résultat attendu est une décision motivée par élément, avec une réserve explicite tant que la pièce manque. Une conclusion globale « tout le SaaS est exclu » ferait disparaître l’agent ; une conclusion « tout ce qui est dans le cloud appartient au produit » dépasserait également l’analyse requise.

Que préparer lorsque le produit est couvert ?

Le fabricant doit organiser l’analyse des risques, les exigences essentielles, la gestion des vulnérabilités, la documentation et la procédure de conformité. Les Art. 13 et 32 encadrent ces obligations ; elles ne se réduisent pas à obtenir une certification de l’hébergeur.

Le dossier de documentation technique CRA doit décrire le périmètre réellement évalué. La gestion des vulnérabilités doit relier les composants aux versions livrées et aux utilisateurs concernés. Prévoyez notamment les interfaces avec les équipes qui exploitent le service distant.

Les obligations de l’article 14 s’appliquent depuis le 11 septembre 2026. L’application générale intervient le 11 décembre 2027, avec les dispositions transitoires pertinentes. Ne repoussez pas la procédure de signalement CRA au lancement du projet de marquage CE.

Relier la qualification aux équipes qui maintiennent l’offre

Une fois le périmètre établi, attribuez les tâches entre développement, exploitation, support et juridique. Identifiez qui reçoit une information de vulnérabilité, qui recherche les versions concernées, qui prépare le correctif et qui suit sa diffusion. Pour le traitement distant, précisez comment une modification déployée côté serveur peut affecter les versions du logiciel encore utilisées par les clients.

Prévoyez également les informations nécessaires lorsque le fournisseur intervient : interlocuteur, description de l’événement, composants concernés et actions possibles. Un contrat peut organiser ces échanges sans déplacer automatiquement la qualité de fabricant définie par le règlement. L’équipe doit pouvoir retrouver les engagements effectivement convenus, sans supposer que le fournisseur réalise toutes les tâches de sécurité.

Enfin, réexaminez la note de qualification lors d’un changement de distribution, de fonction ou de responsabilité de développement. Le lancement d’une version installable ou la reprise d’un développement tiers peut nécessiter une nouvelle analyse. Archivez la décision précédente avec son périmètre : sa date et ses hypothèses expliquent pourquoi elle ne s’applique pas forcément à l’offre modifiée.

NIS2 et contrats clients : des analyses séparées

Être hors du champ d’une obligation CRA ne démontre pas que toute l’entreprise relève automatiquement de NIS2. Il faut examiner l’activité, les seuils, les exceptions et les règles nationales applicables. L’articulation CRA–NIS2 porte sur des périmètres différents : produit d’une part, sécurité de l’entité et de ses services d’autre part.

Un client peut aussi demander des engagements contractuels de sécurité. Identifiez alors ce qui découle de la loi et ce qui est négocié : notification entre parties, accès aux preuves, traitement des composants, continuité et sortie. Une promesse « conformité à toutes les réglementations » ne remplace pas un périmètre et des responsabilités explicites.

Ce qu’il faut retenir

• Cartographiez les offres et composants, pas seulement le modèle commercial SaaS.
• Le traitement distant suppose une fonction dépendante et un lien avec la conception du logiciel.
• Une application distribuée et son service associé peuvent appeler une analyse commune.
• CRA, NIS2 et exigences contractuelles doivent être qualifiés séparément.

FAQ

Un SaaS exclusivement accessible par navigateur relève-t-il automatiquement du CRA ?

Non. Il faut notamment rechercher s’il soutient la fonction d’un produit couvert. Le mode d’accès seul ne clôt pas l’analyse de l’offre complète.

Utiliser un hébergeur tiers transfère-t-il la responsabilité du fabricant ?

Non. Il faut analyser qui conçoit et développe le logiciel, les fonctions du produit et les risques liés aux services tiers. Le contrat d’hébergement ne remplace pas cette qualification.

Un éditeur proposant aussi une version auto-hébergée doit-il la qualifier séparément ?

Oui. Le produit fourni, les versions, les fonctions et les responsabilités peuvent différer de l’offre distante. Conservez une décision propre à chaque mode de fourniture.

Recevez nos analyses conformité dans la newsletter.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la conformité numérique.