CRA : votre backend cloud fait-il partie du produit que vous devez sécuriser ?

Une application mobile, un équipement connecté ou un logiciel peuvent sembler constituer des produits clairement délimités.

Mais que se passe-t-il lorsque leur fonctionnement dépend d’une API ou d’un service distant ?

Le Cyber Resilience Act ne limite pas nécessairement le produit à ce qui est installé chez l’utilisateur. Il définit le produit comportant des éléments numériques comme un produit logiciel ou matériel et ses solutions de traitement de données à distance lorsqu’elles répondent aux conditions prévues par le règlement.1

Les orientations publiées par la Commission européenne le 27 juillet 2026 viennent justement préciser ce périmètre.2

Pour les fabricants et éditeurs, la question devient très concrète : où s’arrête réellement le produit que nous devons sécuriser ?

Le backend peut faire partie du produit

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

Deux éléments sont donc particulièrement importants : le lien avec le fabricant et le caractère nécessaire du service distant pour une fonction du produit.

Prenons une caméra connectée.

La caméra capture les images localement. Mais l’application utilisée pour la configurer interroge une API distante. L’authentification passe par le backend du fabricant. Certaines fonctions de sécurité et les mises à jour dépendent également de services distants.

Le produit réellement fourni à l’utilisateur ne se résume alors plus nécessairement à caméra + application.

Il peut être nécessaire de raisonner sur une chaîne plus large :

équipement → application → API → backend → fonctions distantes.

La Commission cite précisément les solutions de traitement de données à distance parmi les questions de périmètre clarifiées dans ses orientations de 2026.2

Tout service cloud utilisé par le produit n’entre pas automatiquement dans le périmètre

Il serait toutefois excessif d’en conclure que chaque service cloud consommé par une application devient automatiquement une partie du produit au sens du CRA.

Il faut reconstruire la relation entre le service distant et la fonction fournie.

Une question simple permet de commencer l’analyse : que se passe-t-il si ce service distant disparaît ?

Si le produit continue à assurer toutes ses fonctions, le rôle du service n’est pas le même que si sa disparition rend une fonction du produit impossible.

Il faut ensuite déterminer qui a conçu ou fait développer le logiciel correspondant et sous quelle responsabilité il fonctionne.

L’analyse devient donc :

fonction du produit → traitement distant nécessaire ? → logiciel conçu par le fabricant ou sous sa responsabilité ? → dépendance indispensable à la fonction ?

Cette approche évite deux erreurs opposées : considérer que tout le cloud fait partie du produit, ou considérer que le cloud n’en fait jamais partie.

Une question de cybersécurité devient une question d’architecture

Le problème apparaît rapidement lorsque les équipes produit ne disposent pas d’une vision consolidée des dépendances.

Une fonction visible par l’utilisateur peut mobiliser une application locale, une API, un service d’authentification, un backend métier, une base de données, un service de mise à jour et plusieurs composants tiers.

Pour déterminer le périmètre pertinent, il faut donc pouvoir reconstruire :

fonction → logiciel → flux → API → service distant → opérateur.

Puis distinguer les dépendances directement liées au produit des dépendances techniques sous-jacentes.

Cette distinction devient importante pour l’analyse des risques, la gestion des vulnérabilités et le maintien en condition de sécurité.

Cas construit : une caméra connectée et son cloud

Imaginons une caméra de sécurité vendue dans l’Union européenne.

Elle dispose de quatre fonctions : capturer une vidéo ; permettre la consultation depuis une application mobile ; envoyer une alerte lorsqu’un mouvement est détecté ; recevoir des mises à jour de sécurité.

La capture fonctionne localement. En revanche, l’authentification de l’utilisateur dépend d’un backend exploité sous la responsabilité du fabricant. Les notifications passent également par une infrastructure distante. La configuration de certaines fonctions est stockée dans le cloud.

Pour analyser le périmètre, il faut examiner chaque fonction séparément.

Capture locale : la fonction peut continuer à fonctionner sans backend.

Consultation distante : elle dépend de l’authentification et des API distantes.

Notifications : elles nécessitent un traitement distant.

Mises à jour : elles dépendent d’une infrastructure contrôlée par le fabricant.

Une représentation uniquement centrée sur le matériel masquerait donc une partie importante du fonctionnement réel du produit.

La bonne unité d’analyse n’est plus uniquement le composant physique. C’est la fonction fournie à l’utilisateur et l’ensemble des éléments nécessaires pour la réaliser.

Le périmètre doit rester compréhensible pendant toute la vie du produit

La difficulté ne s’arrête pas à la mise sur le marché.

Une architecture évolue. Un service peut être remplacé. Une API peut être externalisée. Une fonctionnalité initialement locale peut devenir cloud. Un fournisseur peut être ajouté.

Le CRA introduit parallèlement des exigences de cybersécurité couvrant le cycle de vie des produits et encadre les périodes de support. Les orientations de juillet 2026 consacrent une partie importante à leur interprétation.2

Le périmètre de sécurité ne devrait donc pas être considéré comme une photographie réalisée uniquement au moment de la conception.

Il faut pouvoir suivre l’évolution de la relation :

produit → fonctions → composants → services distants → responsabilités.

Depuis le 11 septembre 2026, la question devient encore plus concrète

Les principales exigences du CRA s’appliqueront à partir du 11 décembre 2027. Mais toutes les obligations n’attendent pas cette date.

Depuis le 11 septembre 2026, les obligations de notification prévues par le CRA sont déjà applicables.3

Les fabricants doivent notamment notifier certaines vulnérabilités activement exploitées et certains incidents sévères affectant la sécurité de leurs produits.

Cette entrée en application rend la connaissance du périmètre encore plus importante.

Lorsqu’une vulnérabilité touche un backend, une API ou un composant distant, le fabricant doit pouvoir déterminer rapidement : quels produits en dépendent ? quelles versions sont concernées ? quelles fonctions sont affectées ? le service distant appartient-il au périmètre du produit ? quels utilisateurs peuvent être exposés ?

La frontière entre produit et infrastructure n’est donc plus uniquement une question de vocabulaire réglementaire. Elle conditionne la capacité à comprendre et gérer un événement de cybersécurité.

Cartographier le produit par ses fonctions

Une représentation utile peut commencer simplement :

produit → fonction → composant → flux → service distant → responsable.

Puis être enrichie avec les versions, dépendances logicielles, données manipulées, fournisseurs, vulnérabilités, périodes de support et mécanismes de mise à jour.

Cette représentation permet de conserver une frontière claire entre le produit visible par l’utilisateur et l’architecture réellement nécessaire à son fonctionnement.

C’est précisément cette deuxième frontière que le CRA oblige désormais les fabricants à regarder.