Votre application mobile dialogue avec un serveur que vous avez construit. Sous le règlement sur la cyberrésilience, ce serveur n'est pas une entité séparée que vous pourriez écarter d'un revers de main. Il fait partie du produit. L'exemple phare du règlement pour le traitement de données à distance est précisément une application mobile qui accède à une API ou à une base de données fournie par un service que vous avez développé. Le backend derrière votre application n'est donc pas un voisin du produit. Il est à l'intérieur.
Cette page vous donne le test, puis trie chaque backend qu'une application typique sollicite en trois catégories : solution de traitement de données à distance, composant, et hors champ. Nous avons résumé le test dans la synthèse du projet d'orientations de la Commission de mars 2026. Voici la version détaillée pour quiconque livre une application mobile, une API ou un backend cloud.
Résumé
- Le traitement de données à distance fait partie du produit. Le CRA traite un produit connecté comme l'appareil ou l'application plus le backend que vous avez construit et dont il a besoin pour fonctionner. On abrège souvent solution de traitement de données à distance en RDPS, et cette page le fait aussi.
- Un seul test, trois conditions à réunir. Un backend relève du traitement de données à distance lorsqu'il s'exécute à distance, que votre produit en a besoin pour exécuter une fonction, et que vous l'avez construit ou fait construire pour vous. Si l'une des trois manque, ce n'en est pas un.
- L'exemple canonique est une application et son API. Le cas phare du règlement est une application mobile qui accède à une API ou à une base de données fournie par un service que vous avez construit.
- Trois catégories, rien d'autre. Chaque backend que votre application sollicite est soit une solution de traitement de données à distance, soit un composant, soit hors champ.
- Un SaaS sur étagère n'est pas une RDPS, mais reste votre affaire. Un service que vous vous contentez de licencier est un composant. Vous évaluez toujours le risque d'intégration et menez une diligence raisonnable sur son fournisseur.
- Le réseau 5G est entièrement exclu. Un réseau cellulaire est un vecteur de connectivité, comme un routeur ou un signal Wi-Fi. Vous ne devez à l'opérateur aucune diligence raisonnable.
- Vos pipelines CI/CD et votre CRM sont hors champ. Le CRA ne régule pas le réseau de votre entreprise dans son ensemble. Les pipelines internes, la paie et l'infrastructure de red team restent à l'extérieur.
Le traitement de données à distance en quatre chiffres : les conditions que vous vérifiez, les deux questions qui décident, les catégories dans lesquelles une dépendance peut atterrir, et l'exemple par lequel le règlement commence.
Ce que signifie réellement le traitement de données à distance
Le règlement le ramène à une seule idée, et trois conditions doivent être réunies en même temps. Les données doivent être traitées ailleurs que sur l'appareil de l'utilisateur. Votre produit doit avoir besoin de ce traitement pour accomplir l'une de ses tâches. Et vous devez avoir construit le service, ou l'avoir fait construire sous votre responsabilité. Réunissez les trois et vous tenez une solution de traitement de données à distance. Si l'une manque, non.
Prenez les trois séparément, car chacune piège une équipe différente.
- Traité à distance. Le traitement a lieu en dehors de l'appareil ou de l'environnement de l'utilisateur. Il peut se situer en périphérie, sur un lien filaire ou sans fil. Une application mobile qui accède à une fonction cloud fait partie du traitement qui se produit dans le cloud.
- Nécessaire à une fonction. Sans le service, le produit ne peut pas accomplir l'une de ses tâches. Le mot que le règlement emploie est fonctions, pas fonctionnalités phares, et cela compte. La section suivante détaille à quel point c'est large.
- Construit par ou pour vous. Vous avez conçu et développé le service, ou un prestataire l'a construit sous votre responsabilité. Louer l'espace pour l'exécuter ne change pas la réponse.
Deux points piègent les équipes avant même qu'elles commencent le tri :
- C'est votre logiciel, pas le matériel qui l'exécute. La solution de traitement de données à distance est le code que vous avez construit et exécuté à distance. L'hyperviseur ou le runtime du prestataire en dessous est un composant, et le matériel physique sur lequel tout repose est l'environnement produit. Aucun des deux n'est votre solution de traitement de données à distance, et vous évaluez le risque issu des deux.
- Cela n'a pas à être un cloud public. Une solution de traitement de données à distance peut s'exécuter sur vos propres serveurs sur site ou sur un cloud privé dans vos locaux. Le test porte sur la conception, le développement et la nécessité, pas sur l'emplacement physique de la machine.
Les trois questions
Faites passer chaque backend dont votre application dépend par trois questions, dans l'ordre. Chaque chemin aboutit à l'une des trois catégories.
La première question écarte tout ce qui ne quitte jamais l'appareil. Les deux suivantes forment la paire décisive, et toutes deux doivent être oui. Trois points méritent d'être fixés avant de commencer :
- Fonctions est plus large que fonctionnalités phares. Cela couvre tout ce qui soutient la façon dont le produit fonctionne, pas seulement la fonctionnalité vedette. Envoyer des commandes à un appareil, synchroniser des fichiers, intégrer un utilisateur, configuration et personnalisation, recevoir des mises à jour y compris des correctifs de sécurité, et authentifier les utilisateurs comptent tous comme des fonctions. Si un backend est nécessaire à l'une d'elles, la deuxième question est oui.
- Un repli manuel ne vous exonère pas. Une ampoule que vous pouvez allumer via une application ou par un interrupteur physique reste une solution de traitement de données à distance pour le chemin distant. L'option manuelle ne sort pas la fonction du champ.
- Construit par ou pour vous ne tient pas à qui l'exploite. Vous pouvez confier l'exploitation à un tiers et rester responsable. Sous votre responsabilité signifie sur mesure, construit pour votre compte selon votre cahier des charges, et possédé plutôt que licencié. Licencier un produit existant, ou une version légèrement modifiée, n'est pas construit par ou pour vous.
Le cas canonique : votre application, votre API, votre base de données
Commençons par le cas que le règlement lui-même utilise comme exemple. Une application mobile a besoin d'une API ou d'une base de données, et cette API ou cette base s'exécute sur un service que vous avez construit. Dans ce cas, le service est une solution de traitement de données à distance, point final. C'est l'image sur laquelle le reste de la page s'appuie.
Faites passer une application de prise de notes par les trois questions. L'application synchronise des fichiers via votre API REST et votre base de données. Traité à distance, oui. Nécessaire à une fonction, oui, car la synchronisation de fichiers est une fonction. Construit par ou pour vous, oui, car vous avez conçu l'API et le schéma de la base. Trois oui. Votre API et votre base de données sont une solution de traitement de données à distance. Elles se situent dans le champ de conformité du produit.
La plateforme cloud en dessous est une autre question. Si vous louez une infrastructure et y déployez votre propre code, la plateforme que vous louez n'est pas la solution de traitement de données à distance. Votre code l'est. L'IaaS en dessous est un composant. Vous documentez la dépendance, évaluez le risque d'intégration, et pouvez demander au prestataire des preuves de sécurité.
Les trois catégories en un coup d'œil
Chaque dépendance atterrit dans exactement une catégorie. Les deux questions décisives à oui font une solution de traitement de données à distance. Nécessaire à une fonction mais pas sous votre responsabilité fait un composant. Pas nécessaire à une fonction fait un hors champ, et vous vérifiez le risque qu'il introduit malgré tout.
| Catégorie | Quand elle s'applique | Signification | Ce que vous devez faire |
|---|---|---|---|
| Solution de traitement de données à distance | à distance, nécessaire à une fonction, et construite par ou pour vous | Partie du produit lui-même | Satisfaire aux exigences essentielles de l'annexe I. L'intégrer à l'évaluation des risques du produit. La couvrir dans la déclaration UE de conformité et la documentation technique. Traiter et signaler les vulnérabilités pendant la période de soutien |
| Composant | à distance et nécessaire à une fonction, mais pas construit par ou pour vous | Une pièce tierce sur laquelle votre produit s'appuie | Évaluer le risque d'intégration. Atténuer au niveau du produit, par l'authentification, des contrôles d'intégrité, l'isolation et la validation des réponses. Mener une diligence raisonnable sur le fournisseur et inscrire des garanties de sécurité dans le contrat de niveau de service. Réutiliser les preuves que le fournisseur détient déjà : un marquage CE, un certificat ISO/IEC 27001 ou 27017, un certificat de cybersécurité de l'UE, des preuves des obligations NIS2 du fournisseur, ou de ses obligations DORA le cas échéant |
| Hors champ | non nécessaire à une fonction, ou pure connectivité | Ni solution de traitement de données à distance, ni composant | Aucune obligation de conformité ni de composant. Vous évaluez tout de même le risque qu'introduit la communication. La pure connectivité, comme le réseau cellulaire, le Wi-Fi ou un routeur, est le seul cas où vous ne devez rien au prestataire |
Notre avis : En pratique, le test échoue rarement sur les deux premières questions. Presque tout ce qu'une application sollicite s'exécute à distance et sert à quelque chose. La réponse se joue sur la troisième question, la propriété, et c'est là que nous voyons les équipes déraper. Si un service a été construit pour vous et que vous le possédez, traitez-le comme dans le champ et passez à la suite. L'erreur coûteuse que nous voyons sans cesse est de classer un backend sur mesure en composant parce qu'un fournisseur se trouve l'exploiter.
Exemples détaillés
Le projet d'orientations raisonne à partir d'un ensemble de produits fictifs et archétypaux, et la galerie ci-dessous le reflète. Quand il nomme une catégorie technologique réelle, il classe le schéma typique. La réponse se joue sur la façon dont vous utilisez la chose, construit en propre face à licencié sur étagère, jamais un verdict juridique sur un fournisseur nommé.
A. Votre propre backend de synchronisation
Produit : une application de notes ou de productivité. L'application se connecte à votre API REST et à votre base de données sur une infrastructure louée. Traité à distance, oui. Nécessaire à une fonction, oui, la synchronisation de fichiers. Construit par ou pour vous, oui. C'est une solution de traitement de données à distance. L'infrastructure louée en dessous est un composant. C'est le cas canonique de la section ci-dessus.
B. Application compagnon de maison connectée
Produit : un thermostat ou une ampoule et son application compagnon. L'application dialogue avec votre backend cloud, que vous avez construit et exécutez sur une infrastructure tierce. L'appareil fonctionne aussi par un interrupteur manuel. Traité à distance, oui. Nécessaire à une fonction, oui, envoyer des commandes à un appareil, et le repli manuel n'y change rien. Construit par ou pour vous, oui. C'est une solution de traitement de données à distance. L'infrastructure en dessous est un composant. Le règlement confirme que le contrôle cloud d'un fabricant de maison connectée relève du champ.
C. Application bancaire, le cas des trois catégories
Produit : l'application bancaire. Une application, quatre dépendances, trois catégories.
- Votre couche API auto-hébergée est une solution de traitement de données à distance. Vous l'avez construite, l'application en a besoin, elle s'exécute à distance.
- Les systèmes de comptes et de registre que l'application ne touche jamais directement sont hors champ, une dépendance externe. Ils font tout de même l'objet d'une évaluation des risques. Vous appliquez une authentification forte des interfaces du backend, une protection de l'intégrité, et une vérification des réponses.
- Un SaaS de chat de support tiers est un composant. Vous l'isolez du flux bancaire cœur, validez le contenu qu'il renvoie, et menez une diligence raisonnable.
- Votre code de notifications push sur une PaaS tierce est une solution de traitement de données à distance. La plateforme PaaS elle-même est un composant. Votre code est le logiciel que vous avez conçu. La plateforme est la couche louée en dessous.
D. Identité et authentification
Produit : n'importe quelle application. Authentifier les utilisateurs est une fonction, donc l'identité entre en jeu.
- Votre propre service d'authentification émetteur de jetons est une solution de traitement de données à distance. Vous l'avez construit, l'application en a besoin pour authentifier les utilisateurs.
- Un fournisseur d'identité tiers que vous vous contentez de licencier sur étagère est un composant, pas une solution de traitement de données à distance. Vous évaluez le risque d'intégration et menez une diligence raisonnable.
- Un prestataire qui construit un service d'identité sur mesure uniquement pour vous, possédé par vous, repasse à une solution de traitement de données à distance. Même fournisseur, contrat différent, réponse différente.
E. Stockage SaaS sur étagère
Produit : une application média ou de lecture qui stocke du contenu acheté dans un SaaS de stockage tiers générique. Traité à distance, oui. Nécessaire à une fonction, oui. Construit par ou pour vous, non, car vous avez licencié un produit existant sur étagère. C'est un composant, pas une solution de traitement de données à distance. Vous sécurisez l'authentification, le chiffrement et l'intégrité de la communication, et menez une diligence raisonnable. Comparez avec l'exemple A. La même tâche, le stockage de fichiers, atterrit dans une catégorie différente selon qui a construit le service.
F. Fonctionnalité IA et LLM
Produit : une application dotée d'une fonctionnalité IA.
- Votre propre modèle ou service d'inférence que vous avez construit et exécutez sur une infrastructure tierce est une solution de traitement de données à distance.
- Une API de modèle tiers que vous vous contentez de licencier sur étagère est un composant, pas une solution de traitement de données à distance. Vous évaluez le risque d'intégration et menez une diligence raisonnable.
- Des données envoyées uniquement pour l'entraînement du modèle ou des statistiques, non nécessaires à une fonction du produit, sont probablement hors champ. Vous évaluez tout de même le risque qu'ajoute cette communication.
G. L'ensemble hors champ
Hors champ n'est pas une chose unique. Il a deux sous-zones, et elles portent un travail différent.
- Rien dû au prestataire. Le réseau 5G ou cellulaire, le Wi-Fi de l'utilisateur et le routeur sont des vecteurs de connectivité. Ils ne sont ni une solution de traitement de données à distance, ni un composant. Vous ne devez à l'opérateur aucune diligence raisonnable.
- Pas une solution de traitement de données à distance, tout de même un contrôle du risque. La télémétrie de plantage ou d'usage collectée uniquement à des fins statistiques ou de développement futur du produit n'est pas une solution de traitement de données à distance, mais vous évaluez tout risque de communication qu'elle ajoute. Un site marketing ou un centre d'aide vers lequel l'application se contente de pointer n'est pas non plus une solution de traitement de données à distance.
- Votre propre réseau. Le CRM interne, les RH, la paie, les pipelines CI/CD, la distribution interne des mises à jour vers les sites en périphérie, et l'infrastructure de pentest ou de red team ne sont pas une solution de traitement de données à distance. Le CRA ne régule pas le réseau de votre entreprise dans son ensemble.
Ce que chaque catégorie vous oblige à faire
La catégorie n'est pas une étiquette. Elle fixe le travail.
La ligne se déplace avec le modèle cloud. Sur une infrastructure louée, le logiciel que vous déployez peut être une solution de traitement de données à distance, l'hyperviseur du prestataire en dessous est un composant, et le matériel physique est l'environnement produit. Sur une plateforme louée, le code de votre application peut être une solution de traitement de données à distance et la plateforme d'exécution est un composant. Une application SaaS sur étagère est un composant, pas une solution de traitement de données à distance.
Solution de traitement de données à distance. Elle est à l'intérieur du produit. Vous satisfaites aux exigences essentielles de l'annexe I, l'intégrez à l'évaluation des risques du produit, la couvrez dans la déclaration UE de conformité et la documentation technique, et traitez et signalez les vulnérabilités pendant la période de soutien.
Composant. C'est une pièce tierce sur laquelle votre produit s'appuie. Vous évaluez le risque d'intégration et atténuez au niveau du produit, par l'authentification, des contrôles d'intégrité, l'isolation et la validation des réponses. Vous menez une diligence raisonnable sur le fournisseur et inscrivez des garanties de sécurité dans le contrat de niveau de service. Vous pouvez réutiliser les preuves que le fournisseur détient déjà : un marquage CE, un certificat ISO/IEC 27001 ou 27017, un certificat de cybersécurité de l'UE, des preuves des obligations NIS2 du fournisseur, ou de ses obligations DORA le cas échéant. Un prestataire tiers qui modifie son propre service n'est pas une modification substantielle de votre produit.
Hors champ. Aucune obligation de conformité ni de composant. Vous évaluez tout de même le risque qu'introduit la communication, sauf dans le cas de la connectivité où vous ne devez rien au prestataire.
Inscrivez les solutions de traitement de données à distance et la dépendance envers des tiers dans votre documentation technique. L'évaluation des risques couvre les solutions de traitement de données à distance, la dépendance envers des tiers, et l'environnement produit.
Vous n'avez pas à faire passer tout votre backend par l'évaluation de la conformité. Le CRA n'atteint que les parties de vos systèmes qui stockent ou traitent les données dont une fonction du produit a besoin. Séparer ces parties du reste, comme l'application bancaire garde son registre séparé de son API, réduit ce qui tombe dans l'évaluation. Et si un backend sert plusieurs produits, déclarez-le dans la documentation technique de chaque produit. Vous pouvez réutiliser cette documentation d'une évaluation produit à la suivante.
Erreurs fréquentes
- Considérer tout votre cloud comme dans le champ. Le CRA n'atteint pas le réseau de votre entreprise dans son ensemble. Vos CI/CD, CRM, RH et paie sont hors champ.
- Supposer que qui l'exploite décide. L'exploitation n'est pas le test. La conception, le développement et la propriété le sont.
- Oublier que les composants demandent tout de même du travail. Hors du champ de conformité ne veut pas dire hors obligation. Un composant demande une évaluation du risque d'intégration, des atténuations au niveau du produit et une diligence raisonnable sur le fournisseur.
- Croire que la télémétrie vous fait entrer. La télémétrie purement statistique n'est pas une solution de traitement de données à distance. Elle reçoit tout de même un contrôle du risque de communication, mais elle ne fait pas partie du produit.
- Confondre les mises à jour du produit avec la distribution interne des mises à jour. Un produit qui reçoit des mises à jour, y compris des correctifs de sécurité, est une fonction, donc le service de livraison des mises à jour que vous construisez peut être une solution de traitement de données à distance. La distribution interne de ces mises à jour entre vos propres sites en périphérie est une infrastructure interne et hors champ.
Foire aux questions
L'API REST propre à mon application est-elle dans le champ du CRA ?
Oui, si vous l'avez construite et que votre application en a besoin pour exécuter une fonction. L'exemple du règlement lui-même est une application mobile qui accède à une API ou à une base de données fournie par un service que le fabricant a construit, et cela place votre API dans le champ de conformité du produit. La plateforme cloud sur laquelle vous l'exécutez est une autre question, et elle est traitée comme un composant.
Si j'héberge mon backend sur un cloud tiers, le cloud fait-il de toute ma pile une solution de traitement de données à distance ?
Non. La solution de traitement de données à distance est le logiciel que vous avez conçu et développé, pas la plateforme en dessous. Cette plateforme appartient au prestataire, pas à vous, donc l'infrastructure louée est un composant. Vous évaluez le risque d'intégration et menez une diligence raisonnable sur le fournisseur.
Un fournisseur d'identité tiers est-il une solution de traitement de données à distance ?
Cela dépend de la façon dont vous l'utilisez. Un fournisseur d'identité tiers que vous licenciez sur étagère est un composant, pas une solution de traitement de données à distance, même si authentifier les utilisateurs est une fonction. Si à la place un prestataire construit un service d'identité sur mesure uniquement pour vous et que vous le possédez, cela repasse à une solution de traitement de données à distance. Même fournisseur, contrat différent, réponse différente.
Le CRA couvre-t-il mes pipelines CI/CD internes et mon CRM ?
Non. Le CRA ne régule pas le réseau et les systèmes d'information de votre entreprise dans leur ensemble. Le CRM interne, la paie, les pipelines CI/CD, la distribution interne des mises à jour vers les sites en périphérie, et le pentest ou le red teaming restent tous à l'extérieur. C'est votre propre réseau, pas une solution de traitement de données à distance dont votre produit dépend.
Le réseau mobile sur lequel mon application fonctionne est-il dans le champ ?
Non. Un réseau 5G ou cellulaire est un vecteur de connectivité, comme un routeur, un câble Ethernet ou un signal Wi-Fi. Il n'est ni une solution de traitement de données à distance, ni un composant, et vous ne devez à l'opérateur réseau aucune diligence raisonnable. C'est le seul cas hors champ qui ne porte aucune obligation envers le prestataire.
Quelle est la différence entre une solution de traitement de données à distance et un composant ?
Tous deux peuvent s'exécuter à distance et tous deux peuvent être nécessaires à une fonction. La différence est qui a construit le service. Une solution de traitement de données à distance est conçue et développée par vous, ou sous votre responsabilité, et se situe donc dans le champ de conformité du produit. Un composant est une pièce tierce que vous licenciez, et reste donc hors conformité mais demande tout de même une évaluation du risque d'intégration, des atténuations au niveau du produit et une diligence raisonnable. Voyez Qu'est-ce qu'un produit comportant des éléments numériques pour situer le traitement de données à distance dans le test de champ plus large.
Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil juridique. Les exemples détaillés suivent le projet d'orientations de la Commission européenne, communication Ares(2026)2319816 du 3 mars 2026, dont la consultation s'est close le 13 avril 2026 et qui n'est pas encore formellement adopté. Pour des conseils de conformité spécifiques, consultez un conseil juridique qualifié.