L'article 3(1) du Cyber Resilience Act, règlement (UE) 2024/2847, définit un produit comportant des éléments numériques comme « un produit logiciel ou matériel et ses solutions de traitement de données à distance ». L'article 3(2) définit le traitement de données à distance comme « un traitement de données à distance pour lequel le logiciel est conçu et développé par le fabricant, ou sous la responsabilité du fabricant, et en l'absence duquel le produit comportant des éléments numériques ne pourrait pas exécuter l'une de ses fonctions ». Que votre produit soit dans le champ d'application dépend de l'article 2 et du considérant 12. Une fois qu'il y est, la question suivante pour toute entreprise ayant une application et un cloud est de savoir quelles parties du cloud y sont entrées avec lui, parce que ces parties vont dans l'évaluation des risques, les exigences essentielles, la documentation technique et l'obligation de notification.

Les orientations de la Commission sur l'application du règlement, C(2026) 5252 du 27 juillet 2026, section 8, paragraphes 178 à 208, répondent à cette question avec plus de précision que le règlement. Cet article est cette section, avec ses cinq cas d'usage, lue pour un fabricant de logiciels.

Deux tests cumulatifs

Le paragraphe 184 décompose la définition en trois éléments : si le traitement est à distance, si son absence empêcherait le produit d'exécuter l'une de ses fonctions, et si le logiciel a été conçu et développé par le fabricant ou sous sa responsabilité. Le paragraphe 185 écarte ensuite le premier comme « pertinent mais pas suffisant » : le cloud, l'edge et les propres serveurs sur site du fabricant comptent tous comme à distance (paragraphe 187), de sorte que le premier élément décide rarement de quoi que ce soit. Le paragraphe 188 énonce la règle : le deuxième et le troisième sont « les deux questions décisives et cumulatives », et « si les deux questions reçoivent une réponse affirmative, le traitement de données à distance est qualifié » de solution de traitement de données à distance.

Le paragraphe 202 donne les trois issues. Deux fois oui : cela fait partie de votre produit, et l'annexe I s'y applique. Le test de la fonction non : pas partie du produit, mais « les fabricants devraient évaluer les risques découlant de l'existence d'un tel traitement de données dans le cadre de leur évaluation des risques ». Le test de la fonction oui mais le test de la responsabilité non : « les fabricants devraient traiter la solution tierce comme un composant », évaluer et atténuer les risques de son intégration, et « faire preuve de diligence raisonnable ».

Test un : son absence arrêterait-elle une fonction

Le mot est « fonctions », pas fonctionnalité de base. Paragraphe 189 : « la notion de "fonctions" incluse dans cette définition ne se limite pas à la "fonctionnalité de base" ou à la "destination" du produit comportant des éléments numériques », et couvre « à la fois les fonctions qui remplissent directement la destination du produit comportant des éléments numériques telle que les utilisateurs en font l'expérience et les fonctions qui soutiennent la performance globale du produit ». Le paragraphe 190 énumère six exemples de traitement à distance dont un produit ne peut se passer : « (i) l'envoi de commandes à un appareil ; (ii) la synchronisation de fichiers ; (iii) l'intégration de l'utilisateur ; (iv) la configuration (personnalisation du produit comportant des éléments numériques) ; (v) la distribution automatisée de mises à jour, y compris les mises à jour de fonctionnalités et les correctifs de sécurité ; (vi) la gestion des identités et des accès ».

Deux précisions comptent pour le logiciel. Une fonction que l'utilisateur peut exécuter à distance ou manuellement, l'ampoule allumée depuis une application ou à la main, compte quand même : « l'exécution de cette fonction à distance est également considérée comme faisant partie des fonctions offertes par le produit comportant des éléments numériques » (paragraphe 191). Et le contre-exemple est la télémétrie : « l'analyse à distance de données de télémétrie collectées à des fins purement statistiques ou pour le développement futur du produit » n'est pas une fonction dont le produit a besoin, donc pas un traitement de données à distance (paragraphe 192), même si le paragraphe 193 ajoute que les risques de ces composants distants ont toujours leur place dans l'évaluation des risques.

Les sites web ont leur propre paragraphe, le 194. Un site qui ne porte que des informations sur le produit n'est pas inclus, « même si le produit redirige vers ce site ». Un site qui « permet ou soutient une fonction » l'est : « un portail d'authentification qui délivre des identifiants ou des jetons nécessaires au fonctionnement du produit comportant des éléments numériques serait considéré comme une RDPS ». Pour la plupart des éditeurs de logiciels, cette seule phrase place le service de connexion à l'intérieur du produit.

Test deux : conçu et développé par vous, ou sous votre responsabilité

Paragraphe 195 : le logiciel développé en interne remplit le test, et celui qu'un prestataire externe développe pour vous aussi, mais « sous la responsabilité du fabricant » signifie « sur mesure pour le fabricant », les cas où « le logiciel est construit uniquement par ou pour le compte du fabricant, sur la base de conceptions et de spécifications fournies par lui ». Licencier un service existant, « ou des versions légèrement modifiées de celui-ci », n'est pas cela.

Qui l'exploite est sans importance. Paragraphe 196 : « la notion de "qui exploite la solution" n'est pas un facteur décisif, la définition du CRA ne se référant qu'à la conception et au développement ». Un backend que vous avez écrit et qu'un hébergeur exploite est le vôtre.

Les paragraphes 197 à 200 classent ensuite les trois modèles de cloud. Sur une IaaS tierce, vous déployez vos propres systèmes d'exploitation et applications ; ce logiciel « est conçu et développé par le fabricant, ou sous sa responsabilité, et peut donc être qualifié » (paragraphe 198). Sur une PaaS tierce, vous déployez votre propre application sur l'environnement d'exécution du fournisseur ; « l'application est donc conçue et développée par le fabricant » et peut être qualifiée (paragraphe 199). Une application SaaS tierce intégrée dans votre produit « n'est donc pas conçue et développée par le fabricant » (paragraphe 200) et n'est pas un traitement de données à distance, quelle que soit la fonction qu'elle soutient.

Ce qui sort de la définition ne sort pas de votre responsabilité. Paragraphe 201 : l'hyperviseur sous votre IaaS, le système d'exploitation sous votre PaaS, le SaaS tiers « devraient être considérés comme similaires à des composants tiers » là où ils affectent la sécurité du produit, et le fabricant « est tenu d'identifier et d'évaluer les risques liés à l'intégration de ces éléments et d'y répondre en mettant en œuvre les exigences essentielles sur le produit comportant des éléments numériques lui-même », en exerçant « une obligation similaire à l'obligation de diligence raisonnable visée à l'article 13(5) ».

La limite : les modules auxquels votre produit parle, pas tout ce qui est derrière

C'est la partie qui décide de la taille de la documentation technique. Paragraphe 205 : le traitement de données à distance soumis à l'évaluation de la conformité du produit « devrait être limité aux modules logiciels responsables de la fonctionnalité du produit comportant des éléments numériques, et aux interfaces que ces modules utilisent avec des services externes. Les autres systèmes back-end qui effectuent un traitement ultérieur, et avec lesquels le produit comportant des éléments numériques n'interagit pas directement, ne sont pas considérés comme des RDPS ». Le paragraphe 206 les garde dans l'évaluation des risques comme « dépendances externes qui doivent être évaluées » et atténuées « par des mesures au niveau du produit ».

Le paragraphe 182 énumère ce que la définition n'a jamais été censée atteindre, sur la base du considérant 11 : « les systèmes internes relatifs aux ressources humaines du fabricant, à la paie, à la gestion de la relation client, aux pipelines d'intégration continue/livraison continue (CI/CD), à la distribution des mises à jour de sécurité vers des sites en périphérie, ne devraient pas être considérés comme des RDPS », pas plus que « les systèmes liés aux activités d'audit et de test, tels que les tests d'intrusion, la chasse aux menaces et le red teaming ». Le CRA couvre le produit, pas « l'ensemble de l'infrastructure informatique d'une organisation ». C'est le territoire de NIS2, et le considérant 12 le dit.

Le cas de la banque mobile, qui est celui de la plupart des éditeurs de logiciels

La section 8.3.1 parcourt l'application d'une banque avec un backend auto-hébergé et un chat de support tiers. L'application parle à une « interface bancaire » que la banque a construite, qui interroge à son tour un système de gestion des comptes et un grand livre. L'interface authentifie le client, transmet les ordres de virement et en renvoie le statut ; elle « est nécessaire pour que l'application exécute ses fonctions » et « est conçue et développée sous la responsabilité du fabricant », donc c'est un traitement de données à distance qui « doit par conséquent être inclus dans l'évaluation des risques de cybersécurité et dans la mise en œuvre des exigences essentielles ». Le système de gestion des comptes et le grand livre ne le sont pas : « l'application n'interagit pas directement avec eux », et « bien que leur disponibilité puisse être nécessaire à l'achèvement d'une fonction, le CRA ne couvre que les parties du système qui interagissent directement avec le produit ». Ils restent des dépendances externes dont la compromission « pourrait permettre à un attaquant d'influencer les résultats des transactions », à atténuer au niveau du produit, « par exemple une authentification forte des interfaces back-end, la protection de l'intégrité des données de transaction, des canaux de communication sécurisés et la vérification des réponses reçues par l'application ».

Le chat de support, « développé et exploité par un prestataire tiers », est nécessaire à une fonction mais échoue au test de la responsabilité, donc il « n'est pas une RDPS » et « devrait être traité comme un composant tiers », isolé des fonctions de base, avec diligence raisonnable envers le prestataire.

Transposez à un SaaS B2B typique avec un client de bureau ou mobile : la passerelle API et le service d'authentification que le client appelle sont dans le produit ; l'entrepôt de données trois sauts derrière eux est une dépendance externe ; les widgets tiers d'analyse, de chat ou de paiement intégrés sont des composants. Les quatre autres cas confirment le schéma : les fonctions cloud d'un thermostat sur une IaaS tierce sont dedans (8.3.2), le stockage SaaS tiers d'une liseuse est un composant (8.3.3), le service de vision d'un robot sur IaaS est dedans (8.3.4), et le réseau 5G d'un téléphone n'est ni l'un ni l'autre, « seulement un canal de communication », sans diligence raisonnable due à l'opérateur (8.3.5).

Ce qui va dans le dossier, et ce que vous pouvez réutiliser

Paragraphe 204 : les fabricants « devraient (i) indiquer dans la documentation technique que leur produit comportant des éléments numériques a des RDPS ou repose sur des solutions distantes tierces et (ii) décrire ces solutions », et lorsqu'un même backend sert plusieurs produits, il est déclaré dans le dossier de chaque produit et la documentation « peut être réutilisée d'une évaluation de la conformité à l'autre ».

Pour les services tiers dont vous dépendez, le paragraphe 207 énumère les éléments d'assurance qui peuvent être réutilisés à l'appui de votre évaluation et de votre diligence raisonnable : la preuve du respect par le prestataire du règlement d'exécution NIS2, de DORA, un certificat délivré au titre d'un schéma européen de certification de cybersécurité, ou « la preuve de la conformité à l'ISO/IEC 27017:2015 ou à l'ISO/IEC 27001:2022 ». Le paragraphe 208 ajoute le volet contractuel : des garanties de sécurité dans les accords de niveau de service, « y compris l'assurance que les prestataires traitent correctement les vulnérabilités », et un changement majeur chez un prestataire n'est pas une modification substantielle de votre produit, mais il peut exiger la révision de votre évaluation des risques.

Lu dans l'autre sens, le paragraphe 207(d) est aussi ce que vos propres clients peuvent exiger de vous. Si votre produit est un traitement de données à distance pour le leur, votre certificat ISO 27001 est l'élément que les orientations nomment pour leur dossier.

La détermination, en six lignes

Pour chaque service distant que votre produit appelle, consignez :

  1. Le service et la fonction qu'il soutient, au sens que les orientations donnent à fonction.
  2. Test un : le produit perdrait-il cette fonction sans lui. Télémétrie et sites d'information : non.
  3. Test deux : construit par vous ou selon vos spécifications, ou application tierce sous licence. IaaS et PaaS mettent votre code du côté inclus ; SaaS met l'application du côté composant.
  4. L'issue selon le paragraphe 202 : partie du produit, composant à évaluer avec diligence raisonnable, ou dépendance externe à évaluer.
  5. La limite selon le paragraphe 205 : avec quels modules le produit interagit directement, et quels systèmes se trouvent derrière eux.
  6. L'élément que vous détenez pour chaque service tiers, dans la liste du paragraphe 207, et la date à laquelle vous l'avez obtenu.

Ce tableau est la section sur le traitement à distance de la documentation technique, l'entrée de l'évaluation des risques qu'exige l'article 13, et la réponse à la deuxième question de notre détermination du champ d'application. C'est aussi la liste des systèmes dont la compromission déclenche l'horloge de notification, parce que le paragraphe 178 dit que le produit, traitement à distance compris, est ce sur quoi porte la notification de l'article 14.

Sources

  • Règlement (UE) 2024/2847, article 3(1), (2) et (4), article 13(2), (3) et (5), considérants 11 et 12.
  • Commission européenne, orientations de la Commission sur l'application du règlement (UE) 2024/2847, C(2026) 5252 final du 27 juillet 2026, annexe, section 8, paragraphes 178 à 208 et cas d'usage 8.3.1 à 8.3.5.
  • Directive (UE) 2022/2555 (NIS2) et règlement d'exécution (UE) 2024/2690 de la Commission, pour les services cloud que les orientations leur laissent.

Ceci n'est pas un avis juridique. La section 8 fait onze pages et les cinq cas en sont la partie la plus claire de toutes les orientations ; lisez-les avant de tracer votre propre ligne.