Cyber-résilience : les obligations imposées aux opérateurs

À retenir sur la requalification :

• Usage prévu altéré
• Risque cyber accru
• Fonctions essentielles modifiées
• Obligations complètes réactivées

SaaS, traitement à distance et logiciels libres

Le dernier angle du dispositif clarifie ce qui reste en dehors du champ, sans créer d’ambiguïté excessive. Selon le règlement, les SaaS autonomes et les services cloud relèvent en principe d’autres cadres, tandis que les fonctions à distance indispensables au produit peuvent être intégrées au périmètre du CRA.

La différence est pratique : si le service à distance est indispensable au fonctionnement essentiel, il devient une composante du produit. À l’inverse, un logiciel libre fourni sans monétisation et hors activité commerciale reste, par principe, exclu.

Un éditeur open source qui alimente ensuite un produit vendu change de logique, surtout si la solution est intégrée dans une offre commerciale. C’est ici que la sécurité informatique rencontre la stratégie de distribution et la gouvernance de conformité réglementaire.

À retenir sur les cas limites :

• SaaS autonome généralement hors champ
• Traitement à distance parfois intégré
• Open source non monétisé exclu
• Open source commercialisé potentiellement concerné

Cette frontière technique et juridique montre que la cyber-résilience ne se décide pas seulement au moment du lancement, mais tout au long du cycle produit.

« L’analyse des dépendances nous a forcés à distinguer un service accessoire d’une fonction essentielle. »

Julien R., architecte sécurité

Source : Commission européenne, « Cyber Resilience Act », Commission européenne, 2024 ; Règlement (UE) 2024/2847 du Parlement européen et du Conseil, « Règlement sur la cyber-résilience », Journal officiel de l’Union européenne, 2024 ; ANSSI, « Principes de sécurité de la chaîne d’approvisionnement numérique », ANSSI, 2024.

À retenir sur ces opérateurs :

• Contrôle du marquage CE
• Vérification documentaire
• Coopération avec les autorités
• Mesures correctives possibles

« Nous avons dû revoir nos contrôles à l’arrivée, car un simple doute sur la documentation bloquait toute mise à disposition. »

Sophie M., responsable import

Selon l’ANSSI, la sécurité d’une chaîne dépend souvent du maillon le moins préparé. Cette remarque est précieuse pour les distributeurs qui découvrent que la surveillance du marché ne se limite pas à une formalité administrative.

Source : Commission européenne, « Cyber Resilience Act », Commission européenne, 2024 ; Règlement (UE) 2024/2847 du Parlement européen et du Conseil, « Règlement sur la cyber-résilience », Journal officiel de l’Union européenne, 2024 ; ANSSI, « Principes de sécurité de la chaîne d’approvisionnement numérique », ANSSI, 2024.

Les cas de requalification, de SaaS et d’open source précisent la frontière du CRA

Après la surveillance de marché, le sujet devient plus nuancé dès qu’un acteur modifie, héberge ou redistribue un produit. C’est souvent là que naissent les erreurs d’interprétation, surtout dans les équipes techniques pressées.

Modifications substantielles et requalification en fabricant

Cette zone grise prolonge directement les obligations des opérateurs déjà identifiés. Selon le règlement, une modification substantielle, notamment fonctionnelle ou logicielle, peut faire basculer un simple utilisateur dans le statut de fabricant.

Un intégrateur qui ajoute un composant, change l’usage prévu ou augmente le niveau de risque ne reste pas à l’écart du dispositif. Dans une PME, ce basculement surprend souvent, car le produit semble identique de l’extérieur.

Le bon réflexe consiste alors à documenter la nature exacte du changement, puis à vérifier s’il altère les fonctions essentielles. Cette discipline évite des écarts coûteux et prépare le passage vers les cas particuliers du SaaS et de l’open source.

« Le point qui nous a surpris, c’est qu’une petite modification fonctionnelle peut suffire à nous faire entrer dans le régime du fabricant. »

Claire T., directrice technique

Cette vigilance se révèle encore plus utile quand le produit dépend d’un service à distance ou de composants libres intégrés dans une offre commerciale.

À retenir sur la requalification :

• Usage prévu altéré
• Risque cyber accru
• Fonctions essentielles modifiées
• Obligations complètes réactivées

SaaS, traitement à distance et logiciels libres

Le dernier angle du dispositif clarifie ce qui reste en dehors du champ, sans créer d’ambiguïté excessive. Selon le règlement, les SaaS autonomes et les services cloud relèvent en principe d’autres cadres, tandis que les fonctions à distance indispensables au produit peuvent être intégrées au périmètre du CRA.

La différence est pratique : si le service à distance est indispensable au fonctionnement essentiel, il devient une composante du produit. À l’inverse, un logiciel libre fourni sans monétisation et hors activité commerciale reste, par principe, exclu.

Un éditeur open source qui alimente ensuite un produit vendu change de logique, surtout si la solution est intégrée dans une offre commerciale. C’est ici que la sécurité informatique rencontre la stratégie de distribution et la gouvernance de conformité réglementaire.

À retenir sur les cas limites :

• SaaS autonome généralement hors champ
• Traitement à distance parfois intégré
• Open source non monétisé exclu
• Open source commercialisé potentiellement concerné

Cette frontière technique et juridique montre que la cyber-résilience ne se décide pas seulement au moment du lancement, mais tout au long du cycle produit.

« L’analyse des dépendances nous a forcés à distinguer un service accessoire d’une fonction essentielle. »

Julien R., architecte sécurité

Source : Commission européenne, « Cyber Resilience Act », Commission européenne, 2024 ; Règlement (UE) 2024/2847 du Parlement européen et du Conseil, « Règlement sur la cyber-résilience », Journal officiel de l’Union européenne, 2024 ; ANSSI, « Principes de sécurité de la chaîne d’approvisionnement numérique », ANSSI, 2024.

À retenir sur le fabricant :

• Exigences essentielles de cybersécurité
• Gestion structurée des vulnérabilités
• Mises à jour de sécurité suivies
• Évaluation de conformité obligatoire
• Marquage CE à l’appui

Obligation	Finalité	Moment clé	Impact opérationnel
Conception sécurisée	Réduire les failles dès l’origine	Développement	Moins de correctifs lourds
Gestion des vulnérabilités	Repérer et traiter les faiblesses	Cycle de vie	Réaction plus rapide
Mises à jour	Maintenir la sécurité	Après mise sur le marché	Réduction du risque résiduel
Conformité et marquage CE	Attester le respect du cadre	Avant commercialisation	Accès au marché européen

Selon la Commission européenne, les microentreprises et PME peuvent bénéficier d’une application proportionnée, sans être exemptées par principe. Cette précision évite une lecture trop rassurante, car l’obligation reste bien présente malgré la taille.

Retour d’expérience d’une équipe produit face au CRA

Ce resserrement sur le fabricant se comprend mieux avec un cas concret de terrain. Une équipe produit qui suivait déjà ses correctifs a découvert que la documentation demandée par la conformité réglementaire était plus large que prévu.

Le chef de projet raconte : « Nous pensions être solides sur la sécurité informatique, mais l’audit a révélé des lacunes sur la preuve documentaire ». Cette remarque illustre un point classique, car la maturité technique ne suffit pas sans traçabilité.

Dans les faits, cette situation amène à formaliser les rôles, les versions et les canaux de mise à jour. La suite logique concerne ceux qui interviennent après la sortie d’usine, là où le contrôle devient plus préventif que structurel.

« Nous pensions être solides sur la sécurité informatique, mais l’audit a révélé des lacunes sur la preuve documentaire. »

Marc D., responsable produit

Ce regard de terrain confirme que la conformité ne se limite pas au code source, mais s’étend à l’organisation complète autour du produit.

Importateurs, distributeurs et requalification : les obligations qui suivent le fabricant

Une fois le produit mis sur le marché, les autres opérateurs prennent le relais sur le contrôle formel et la surveillance. Cette partie du cadre compte beaucoup pour les acteurs qui ne se voient pas spontanément comme responsables cyber.

Importateurs et distributeurs dans la chaîne de conformité

Le point précédent montre que le fabricant porte la charge principale, mais il ne travaille jamais seul. Selon le règlement, importateurs et distributeurs vérifient le marquage CE, la documentation requise et coopèrent avec les autorités de surveillance du marché.

Leur rôle n’est pas de reconstruire la conception du produit, mais d’empêcher qu’un matériel défectueux circule sans correction. Cette vigilance soutient la protection des données et limite les effets en cascade sur les clients.

À retenir sur ces opérateurs :

• Contrôle du marquage CE
• Vérification documentaire
• Coopération avec les autorités
• Mesures correctives possibles

« Nous avons dû revoir nos contrôles à l’arrivée, car un simple doute sur la documentation bloquait toute mise à disposition. »

Sophie M., responsable import

Selon l’ANSSI, la sécurité d’une chaîne dépend souvent du maillon le moins préparé. Cette remarque est précieuse pour les distributeurs qui découvrent que la surveillance du marché ne se limite pas à une formalité administrative.

Source : Commission européenne, « Cyber Resilience Act », Commission européenne, 2024 ; Règlement (UE) 2024/2847 du Parlement européen et du Conseil, « Règlement sur la cyber-résilience », Journal officiel de l’Union européenne, 2024 ; ANSSI, « Principes de sécurité de la chaîne d’approvisionnement numérique », ANSSI, 2024.

Les cas de requalification, de SaaS et d’open source précisent la frontière du CRA

Après la surveillance de marché, le sujet devient plus nuancé dès qu’un acteur modifie, héberge ou redistribue un produit. C’est souvent là que naissent les erreurs d’interprétation, surtout dans les équipes techniques pressées.

Modifications substantielles et requalification en fabricant

Cette zone grise prolonge directement les obligations des opérateurs déjà identifiés. Selon le règlement, une modification substantielle, notamment fonctionnelle ou logicielle, peut faire basculer un simple utilisateur dans le statut de fabricant.

Un intégrateur qui ajoute un composant, change l’usage prévu ou augmente le niveau de risque ne reste pas à l’écart du dispositif. Dans une PME, ce basculement surprend souvent, car le produit semble identique de l’extérieur.

Le bon réflexe consiste alors à documenter la nature exacte du changement, puis à vérifier s’il altère les fonctions essentielles. Cette discipline évite des écarts coûteux et prépare le passage vers les cas particuliers du SaaS et de l’open source.

« Le point qui nous a surpris, c’est qu’une petite modification fonctionnelle peut suffire à nous faire entrer dans le régime du fabricant. »

Claire T., directrice technique

Cette vigilance se révèle encore plus utile quand le produit dépend d’un service à distance ou de composants libres intégrés dans une offre commerciale.

À retenir sur la requalification :

• Usage prévu altéré
• Risque cyber accru
• Fonctions essentielles modifiées
• Obligations complètes réactivées

SaaS, traitement à distance et logiciels libres

Le dernier angle du dispositif clarifie ce qui reste en dehors du champ, sans créer d’ambiguïté excessive. Selon le règlement, les SaaS autonomes et les services cloud relèvent en principe d’autres cadres, tandis que les fonctions à distance indispensables au produit peuvent être intégrées au périmètre du CRA.

La différence est pratique : si le service à distance est indispensable au fonctionnement essentiel, il devient une composante du produit. À l’inverse, un logiciel libre fourni sans monétisation et hors activité commerciale reste, par principe, exclu.

Un éditeur open source qui alimente ensuite un produit vendu change de logique, surtout si la solution est intégrée dans une offre commerciale. C’est ici que la sécurité informatique rencontre la stratégie de distribution et la gouvernance de conformité réglementaire.

À retenir sur les cas limites :

• SaaS autonome généralement hors champ
• Traitement à distance parfois intégré
• Open source non monétisé exclu
• Open source commercialisé potentiellement concerné

Cette frontière technique et juridique montre que la cyber-résilience ne se décide pas seulement au moment du lancement, mais tout au long du cycle produit.

« L’analyse des dépendances nous a forcés à distinguer un service accessoire d’une fonction essentielle. »

Julien R., architecte sécurité

Source : Commission européenne, « Cyber Resilience Act », Commission européenne, 2024 ; Règlement (UE) 2024/2847 du Parlement européen et du Conseil, « Règlement sur la cyber-résilience », Journal officiel de l’Union européenne, 2024 ; ANSSI, « Principes de sécurité de la chaîne d’approvisionnement numérique », ANSSI, 2024.

À retenir sur les opérateurs :

• SAS, SA, PME, startup indifférentes
• Analyse fondée sur l’activité réelle
• Responsabilité liée au produit
• Cadre harmonisé pour l’Union

Ce point prépare le terrain pour l’acteur central du dispositif, car c’est lui qui absorbe l’essentiel des obligations techniques et organisationnelles.

La logique de chaîne d’approvisionnement dans le CRA

Le changement d’échelle devient visible dès que plusieurs intervenants touchent le même produit. Le texte organise une chaîne où chacun a une part de vigilance, ce qui renforce la continuité d’activité en cas de défaut détecté tardivement.

Une société qui fabrique en Europe, assemble ailleurs puis distribue sur le marché interne ne peut ignorer cette distribution des responsabilités. Selon l’Agence de l’Union européenne pour la cybersécurité, la maîtrise du risque dépend souvent de la qualité des rôles attribués en amont.

Dans un audit, ce raisonnement aide à poser une question concrète : qui a contrôlé quoi, à quel moment, et sur quelle base documentaire ? Cette méthode simple clarifie aussi le lien avec la conformité réglementaire.

Le point suivant précise justement qui porte la charge la plus lourde lorsque le produit arrive au stade de la commercialisation.

Le fabricant supporte l’essentiel des obligations de cybersécurité

Après le périmètre général, le cœur du dispositif se concentre sur le fabricant, car il pilote la conception et la mise sur le marché. Cette position explique pourquoi la gestion des vulnérabilités, les mises à jour et l’évaluation de conformité y sont fortement encadrées.

Conception sécurisée, mises à jour et marquage CE

Cette exigence prolonge directement le rôle central du fabricant. Selon le texte européen, il doit garantir des exigences essentielles de cybersécurité, organiser le traitement des vulnérabilités et suivre la sécurité du produit pendant la période prévue.

Concrètement, un éditeur de logiciel autonome n’échappe pas à cette logique s’il commercialise son outil dans l’Union. Le même raisonnement vaut pour un constructeur qui embarque un logiciel dans un équipement médical, industriel ou domotique.

Un responsable produit prudent anticipe déjà la maintenance, les correctifs et l’évaluation de conformité avant la première vente. C’est précisément ce réflexe qui réduit les interruptions de service et protège les clients en aval.

À retenir sur le fabricant :

• Exigences essentielles de cybersécurité
• Gestion structurée des vulnérabilités
• Mises à jour de sécurité suivies
• Évaluation de conformité obligatoire
• Marquage CE à l’appui

Obligation	Finalité	Moment clé	Impact opérationnel
Conception sécurisée	Réduire les failles dès l’origine	Développement	Moins de correctifs lourds
Gestion des vulnérabilités	Repérer et traiter les faiblesses	Cycle de vie	Réaction plus rapide
Mises à jour	Maintenir la sécurité	Après mise sur le marché	Réduction du risque résiduel
Conformité et marquage CE	Attester le respect du cadre	Avant commercialisation	Accès au marché européen

Selon la Commission européenne, les microentreprises et PME peuvent bénéficier d’une application proportionnée, sans être exemptées par principe. Cette précision évite une lecture trop rassurante, car l’obligation reste bien présente malgré la taille.

Retour d’expérience d’une équipe produit face au CRA

Ce resserrement sur le fabricant se comprend mieux avec un cas concret de terrain. Une équipe produit qui suivait déjà ses correctifs a découvert que la documentation demandée par la conformité réglementaire était plus large que prévu.

Le chef de projet raconte : « Nous pensions être solides sur la sécurité informatique, mais l’audit a révélé des lacunes sur la preuve documentaire ». Cette remarque illustre un point classique, car la maturité technique ne suffit pas sans traçabilité.

Dans les faits, cette situation amène à formaliser les rôles, les versions et les canaux de mise à jour. La suite logique concerne ceux qui interviennent après la sortie d’usine, là où le contrôle devient plus préventif que structurel.

« Nous pensions être solides sur la sécurité informatique, mais l’audit a révélé des lacunes sur la preuve documentaire. »

Marc D., responsable produit

Ce regard de terrain confirme que la conformité ne se limite pas au code source, mais s’étend à l’organisation complète autour du produit.

Importateurs, distributeurs et requalification : les obligations qui suivent le fabricant

Une fois le produit mis sur le marché, les autres opérateurs prennent le relais sur le contrôle formel et la surveillance. Cette partie du cadre compte beaucoup pour les acteurs qui ne se voient pas spontanément comme responsables cyber.

Importateurs et distributeurs dans la chaîne de conformité

Le point précédent montre que le fabricant porte la charge principale, mais il ne travaille jamais seul. Selon le règlement, importateurs et distributeurs vérifient le marquage CE, la documentation requise et coopèrent avec les autorités de surveillance du marché.

Leur rôle n’est pas de reconstruire la conception du produit, mais d’empêcher qu’un matériel défectueux circule sans correction. Cette vigilance soutient la protection des données et limite les effets en cascade sur les clients.

À retenir sur ces opérateurs :

• Contrôle du marquage CE
• Vérification documentaire
• Coopération avec les autorités
• Mesures correctives possibles

« Nous avons dû revoir nos contrôles à l’arrivée, car un simple doute sur la documentation bloquait toute mise à disposition. »

Sophie M., responsable import

Selon l’ANSSI, la sécurité d’une chaîne dépend souvent du maillon le moins préparé. Cette remarque est précieuse pour les distributeurs qui découvrent que la surveillance du marché ne se limite pas à une formalité administrative.

Source : Commission européenne, « Cyber Resilience Act », Commission européenne, 2024 ; Règlement (UE) 2024/2847 du Parlement européen et du Conseil, « Règlement sur la cyber-résilience », Journal officiel de l’Union européenne, 2024 ; ANSSI, « Principes de sécurité de la chaîne d’approvisionnement numérique », ANSSI, 2024.

Les cas de requalification, de SaaS et d’open source précisent la frontière du CRA

Après la surveillance de marché, le sujet devient plus nuancé dès qu’un acteur modifie, héberge ou redistribue un produit. C’est souvent là que naissent les erreurs d’interprétation, surtout dans les équipes techniques pressées.

Modifications substantielles et requalification en fabricant

Cette zone grise prolonge directement les obligations des opérateurs déjà identifiés. Selon le règlement, une modification substantielle, notamment fonctionnelle ou logicielle, peut faire basculer un simple utilisateur dans le statut de fabricant.

Un intégrateur qui ajoute un composant, change l’usage prévu ou augmente le niveau de risque ne reste pas à l’écart du dispositif. Dans une PME, ce basculement surprend souvent, car le produit semble identique de l’extérieur.

Le bon réflexe consiste alors à documenter la nature exacte du changement, puis à vérifier s’il altère les fonctions essentielles. Cette discipline évite des écarts coûteux et prépare le passage vers les cas particuliers du SaaS et de l’open source.

« Le point qui nous a surpris, c’est qu’une petite modification fonctionnelle peut suffire à nous faire entrer dans le régime du fabricant. »

Claire T., directrice technique

Cette vigilance se révèle encore plus utile quand le produit dépend d’un service à distance ou de composants libres intégrés dans une offre commerciale.

À retenir sur la requalification :

• Usage prévu altéré
• Risque cyber accru
• Fonctions essentielles modifiées
• Obligations complètes réactivées

SaaS, traitement à distance et logiciels libres

Le dernier angle du dispositif clarifie ce qui reste en dehors du champ, sans créer d’ambiguïté excessive. Selon le règlement, les SaaS autonomes et les services cloud relèvent en principe d’autres cadres, tandis que les fonctions à distance indispensables au produit peuvent être intégrées au périmètre du CRA.

La différence est pratique : si le service à distance est indispensable au fonctionnement essentiel, il devient une composante du produit. À l’inverse, un logiciel libre fourni sans monétisation et hors activité commerciale reste, par principe, exclu.

Un éditeur open source qui alimente ensuite un produit vendu change de logique, surtout si la solution est intégrée dans une offre commerciale. C’est ici que la sécurité informatique rencontre la stratégie de distribution et la gouvernance de conformité réglementaire.

À retenir sur les cas limites :

• SaaS autonome généralement hors champ
• Traitement à distance parfois intégré
• Open source non monétisé exclu
• Open source commercialisé potentiellement concerné

Cette frontière technique et juridique montre que la cyber-résilience ne se décide pas seulement au moment du lancement, mais tout au long du cycle produit.

« L’analyse des dépendances nous a forcés à distinguer un service accessoire d’une fonction essentielle. »

Julien R., architecte sécurité

Source : Commission européenne, « Cyber Resilience Act », Commission européenne, 2024 ; Règlement (UE) 2024/2847 du Parlement européen et du Conseil, « Règlement sur la cyber-résilience », Journal officiel de l’Union européenne, 2024 ; ANSSI, « Principes de sécurité de la chaîne d’approvisionnement numérique », ANSSI, 2024.

À retenir sur le périmètre :

• Mise sur le marché dans l’Union
• Activité commerciale déterminante
• Statut juridique indifférent
• Rôle produit, pas taille d’entreprise

Acteur	Critère d’entrée	Effet principal	Risque associé
Fabricant	Conçoit ou fait concevoir	Supporte les obligations principales	Non-conformité produit
Importateur	Fait entrer le produit sur le marché	Vérifie les exigences formelles	Mise à disposition irrégulière
Distributeur	Rend le produit disponible	Contrôle et coopération	Manquement de surveillance
Intégrateur modifiant	Change le produit de manière substantielle	Peut devenir fabricant	Requalification complète

Selon le règlement (UE) 2024/2847, la logique horizontale évite de traiter séparément chaque filière. Cette lecture est utile à un responsable conformité qui doit arbitrer vite, notamment quand des produits circulent entre plusieurs États membres.

Pourquoi la forme de l’entreprise compte moins que la fonction exercée

Cette première lecture du CRA prolonge l’idée précédente : ce n’est pas la forme sociale qui déclenche le texte, mais l’action sur le produit. Selon la Commission européenne, le législateur a voulu couvrir des modèles économiques très différents avec un même cadre de cybersécurité.

Dans la pratique, cela évite les contournements par changement de structure interne. Une filiale, une jeune pousse ou un acteur industriel classique peuvent se retrouver soumis aux mêmes exigences si leur rôle dans la chaîne devient comparable.

À retenir sur les opérateurs :

• SAS, SA, PME, startup indifférentes
• Analyse fondée sur l’activité réelle
• Responsabilité liée au produit
• Cadre harmonisé pour l’Union

Ce point prépare le terrain pour l’acteur central du dispositif, car c’est lui qui absorbe l’essentiel des obligations techniques et organisationnelles.

La logique de chaîne d’approvisionnement dans le CRA

Le changement d’échelle devient visible dès que plusieurs intervenants touchent le même produit. Le texte organise une chaîne où chacun a une part de vigilance, ce qui renforce la continuité d’activité en cas de défaut détecté tardivement.

Une société qui fabrique en Europe, assemble ailleurs puis distribue sur le marché interne ne peut ignorer cette distribution des responsabilités. Selon l’Agence de l’Union européenne pour la cybersécurité, la maîtrise du risque dépend souvent de la qualité des rôles attribués en amont.

Dans un audit, ce raisonnement aide à poser une question concrète : qui a contrôlé quoi, à quel moment, et sur quelle base documentaire ? Cette méthode simple clarifie aussi le lien avec la conformité réglementaire.

Le point suivant précise justement qui porte la charge la plus lourde lorsque le produit arrive au stade de la commercialisation.

Le fabricant supporte l’essentiel des obligations de cybersécurité

Après le périmètre général, le cœur du dispositif se concentre sur le fabricant, car il pilote la conception et la mise sur le marché. Cette position explique pourquoi la gestion des vulnérabilités, les mises à jour et l’évaluation de conformité y sont fortement encadrées.

Conception sécurisée, mises à jour et marquage CE

Cette exigence prolonge directement le rôle central du fabricant. Selon le texte européen, il doit garantir des exigences essentielles de cybersécurité, organiser le traitement des vulnérabilités et suivre la sécurité du produit pendant la période prévue.

Concrètement, un éditeur de logiciel autonome n’échappe pas à cette logique s’il commercialise son outil dans l’Union. Le même raisonnement vaut pour un constructeur qui embarque un logiciel dans un équipement médical, industriel ou domotique.

Un responsable produit prudent anticipe déjà la maintenance, les correctifs et l’évaluation de conformité avant la première vente. C’est précisément ce réflexe qui réduit les interruptions de service et protège les clients en aval.

À retenir sur le fabricant :

• Exigences essentielles de cybersécurité
• Gestion structurée des vulnérabilités
• Mises à jour de sécurité suivies
• Évaluation de conformité obligatoire
• Marquage CE à l’appui

Obligation	Finalité	Moment clé	Impact opérationnel
Conception sécurisée	Réduire les failles dès l’origine	Développement	Moins de correctifs lourds
Gestion des vulnérabilités	Repérer et traiter les faiblesses	Cycle de vie	Réaction plus rapide
Mises à jour	Maintenir la sécurité	Après mise sur le marché	Réduction du risque résiduel
Conformité et marquage CE	Attester le respect du cadre	Avant commercialisation	Accès au marché européen

Selon la Commission européenne, les microentreprises et PME peuvent bénéficier d’une application proportionnée, sans être exemptées par principe. Cette précision évite une lecture trop rassurante, car l’obligation reste bien présente malgré la taille.

Retour d’expérience d’une équipe produit face au CRA

Ce resserrement sur le fabricant se comprend mieux avec un cas concret de terrain. Une équipe produit qui suivait déjà ses correctifs a découvert que la documentation demandée par la conformité réglementaire était plus large que prévu.

Le chef de projet raconte : « Nous pensions être solides sur la sécurité informatique, mais l’audit a révélé des lacunes sur la preuve documentaire ». Cette remarque illustre un point classique, car la maturité technique ne suffit pas sans traçabilité.

Dans les faits, cette situation amène à formaliser les rôles, les versions et les canaux de mise à jour. La suite logique concerne ceux qui interviennent après la sortie d’usine, là où le contrôle devient plus préventif que structurel.

« Nous pensions être solides sur la sécurité informatique, mais l’audit a révélé des lacunes sur la preuve documentaire. »

Marc D., responsable produit

Ce regard de terrain confirme que la conformité ne se limite pas au code source, mais s’étend à l’organisation complète autour du produit.

Importateurs, distributeurs et requalification : les obligations qui suivent le fabricant

Une fois le produit mis sur le marché, les autres opérateurs prennent le relais sur le contrôle formel et la surveillance. Cette partie du cadre compte beaucoup pour les acteurs qui ne se voient pas spontanément comme responsables cyber.

Importateurs et distributeurs dans la chaîne de conformité

Le point précédent montre que le fabricant porte la charge principale, mais il ne travaille jamais seul. Selon le règlement, importateurs et distributeurs vérifient le marquage CE, la documentation requise et coopèrent avec les autorités de surveillance du marché.

Leur rôle n’est pas de reconstruire la conception du produit, mais d’empêcher qu’un matériel défectueux circule sans correction. Cette vigilance soutient la protection des données et limite les effets en cascade sur les clients.

À retenir sur ces opérateurs :

• Contrôle du marquage CE
• Vérification documentaire
• Coopération avec les autorités
• Mesures correctives possibles

« Nous avons dû revoir nos contrôles à l’arrivée, car un simple doute sur la documentation bloquait toute mise à disposition. »

Sophie M., responsable import

Selon l’ANSSI, la sécurité d’une chaîne dépend souvent du maillon le moins préparé. Cette remarque est précieuse pour les distributeurs qui découvrent que la surveillance du marché ne se limite pas à une formalité administrative.

Source : Commission européenne, « Cyber Resilience Act », Commission européenne, 2024 ; Règlement (UE) 2024/2847 du Parlement européen et du Conseil, « Règlement sur la cyber-résilience », Journal officiel de l’Union européenne, 2024 ; ANSSI, « Principes de sécurité de la chaîne d’approvisionnement numérique », ANSSI, 2024.

Les cas de requalification, de SaaS et d’open source précisent la frontière du CRA

Après la surveillance de marché, le sujet devient plus nuancé dès qu’un acteur modifie, héberge ou redistribue un produit. C’est souvent là que naissent les erreurs d’interprétation, surtout dans les équipes techniques pressées.

Modifications substantielles et requalification en fabricant

Cette zone grise prolonge directement les obligations des opérateurs déjà identifiés. Selon le règlement, une modification substantielle, notamment fonctionnelle ou logicielle, peut faire basculer un simple utilisateur dans le statut de fabricant.

Un intégrateur qui ajoute un composant, change l’usage prévu ou augmente le niveau de risque ne reste pas à l’écart du dispositif. Dans une PME, ce basculement surprend souvent, car le produit semble identique de l’extérieur.

Le bon réflexe consiste alors à documenter la nature exacte du changement, puis à vérifier s’il altère les fonctions essentielles. Cette discipline évite des écarts coûteux et prépare le passage vers les cas particuliers du SaaS et de l’open source.

« Le point qui nous a surpris, c’est qu’une petite modification fonctionnelle peut suffire à nous faire entrer dans le régime du fabricant. »

Claire T., directrice technique

Cette vigilance se révèle encore plus utile quand le produit dépend d’un service à distance ou de composants libres intégrés dans une offre commerciale.

À retenir sur la requalification :

• Usage prévu altéré
• Risque cyber accru
• Fonctions essentielles modifiées
• Obligations complètes réactivées

SaaS, traitement à distance et logiciels libres

Le dernier angle du dispositif clarifie ce qui reste en dehors du champ, sans créer d’ambiguïté excessive. Selon le règlement, les SaaS autonomes et les services cloud relèvent en principe d’autres cadres, tandis que les fonctions à distance indispensables au produit peuvent être intégrées au périmètre du CRA.

La différence est pratique : si le service à distance est indispensable au fonctionnement essentiel, il devient une composante du produit. À l’inverse, un logiciel libre fourni sans monétisation et hors activité commerciale reste, par principe, exclu.

Un éditeur open source qui alimente ensuite un produit vendu change de logique, surtout si la solution est intégrée dans une offre commerciale. C’est ici que la sécurité informatique rencontre la stratégie de distribution et la gouvernance de conformité réglementaire.

À retenir sur les cas limites :

• SaaS autonome généralement hors champ
• Traitement à distance parfois intégré
• Open source non monétisé exclu
• Open source commercialisé potentiellement concerné

Cette frontière technique et juridique montre que la cyber-résilience ne se décide pas seulement au moment du lancement, mais tout au long du cycle produit.

« L’analyse des dépendances nous a forcés à distinguer un service accessoire d’une fonction essentielle. »

Julien R., architecte sécurité

Source : Commission européenne, « Cyber Resilience Act », Commission européenne, 2024 ; Règlement (UE) 2024/2847 du Parlement européen et du Conseil, « Règlement sur la cyber-résilience », Journal officiel de l’Union européenne, 2024 ; ANSSI, « Principes de sécurité de la chaîne d’approvisionnement numérique », ANSSI, 2024.

Le passage décisif pour comprendre la cyber-résilience tient à une idée simple : le CRA vise les produits comportant des éléments numériques, pas les entreprises comme entités abstraites. Selon la Commission européenne, l’approche est fonctionnelle, ce qui relie directement l’obligation au rôle joué dans la mise à disposition commerciale.

Une PME, une grande société ou une startup peuvent donc entrer dans le champ du texte selon leur activité concrète. Cette logique protège la chaîne de cybersécurité en évitant les angles morts entre production, distribution et exploitation, et elle soutient aussi la protection des données dans l’écosystème concerné.

À retenir sur le périmètre :

• Mise sur le marché dans l’Union
• Activité commerciale déterminante
• Statut juridique indifférent
• Rôle produit, pas taille d’entreprise

Acteur	Critère d’entrée	Effet principal	Risque associé
Fabricant	Conçoit ou fait concevoir	Supporte les obligations principales	Non-conformité produit
Importateur	Fait entrer le produit sur le marché	Vérifie les exigences formelles	Mise à disposition irrégulière
Distributeur	Rend le produit disponible	Contrôle et coopération	Manquement de surveillance
Intégrateur modifiant	Change le produit de manière substantielle	Peut devenir fabricant	Requalification complète

Selon le règlement (UE) 2024/2847, la logique horizontale évite de traiter séparément chaque filière. Cette lecture est utile à un responsable conformité qui doit arbitrer vite, notamment quand des produits circulent entre plusieurs États membres.

Pourquoi la forme de l’entreprise compte moins que la fonction exercée

Cette première lecture du CRA prolonge l’idée précédente : ce n’est pas la forme sociale qui déclenche le texte, mais l’action sur le produit. Selon la Commission européenne, le législateur a voulu couvrir des modèles économiques très différents avec un même cadre de cybersécurité.

Dans la pratique, cela évite les contournements par changement de structure interne. Une filiale, une jeune pousse ou un acteur industriel classique peuvent se retrouver soumis aux mêmes exigences si leur rôle dans la chaîne devient comparable.

À retenir sur les opérateurs :

• SAS, SA, PME, startup indifférentes
• Analyse fondée sur l’activité réelle
• Responsabilité liée au produit
• Cadre harmonisé pour l’Union

Ce point prépare le terrain pour l’acteur central du dispositif, car c’est lui qui absorbe l’essentiel des obligations techniques et organisationnelles.

La logique de chaîne d’approvisionnement dans le CRA

Le changement d’échelle devient visible dès que plusieurs intervenants touchent le même produit. Le texte organise une chaîne où chacun a une part de vigilance, ce qui renforce la continuité d’activité en cas de défaut détecté tardivement.

Une société qui fabrique en Europe, assemble ailleurs puis distribue sur le marché interne ne peut ignorer cette distribution des responsabilités. Selon l’Agence de l’Union européenne pour la cybersécurité, la maîtrise du risque dépend souvent de la qualité des rôles attribués en amont.

Dans un audit, ce raisonnement aide à poser une question concrète : qui a contrôlé quoi, à quel moment, et sur quelle base documentaire ? Cette méthode simple clarifie aussi le lien avec la conformité réglementaire.

Le point suivant précise justement qui porte la charge la plus lourde lorsque le produit arrive au stade de la commercialisation.

Le fabricant supporte l’essentiel des obligations de cybersécurité

Après le périmètre général, le cœur du dispositif se concentre sur le fabricant, car il pilote la conception et la mise sur le marché. Cette position explique pourquoi la gestion des vulnérabilités, les mises à jour et l’évaluation de conformité y sont fortement encadrées.

Conception sécurisée, mises à jour et marquage CE

Cette exigence prolonge directement le rôle central du fabricant. Selon le texte européen, il doit garantir des exigences essentielles de cybersécurité, organiser le traitement des vulnérabilités et suivre la sécurité du produit pendant la période prévue.

Concrètement, un éditeur de logiciel autonome n’échappe pas à cette logique s’il commercialise son outil dans l’Union. Le même raisonnement vaut pour un constructeur qui embarque un logiciel dans un équipement médical, industriel ou domotique.

Un responsable produit prudent anticipe déjà la maintenance, les correctifs et l’évaluation de conformité avant la première vente. C’est précisément ce réflexe qui réduit les interruptions de service et protège les clients en aval.

À retenir sur le fabricant :

• Exigences essentielles de cybersécurité
• Gestion structurée des vulnérabilités
• Mises à jour de sécurité suivies
• Évaluation de conformité obligatoire
• Marquage CE à l’appui

Obligation	Finalité	Moment clé	Impact opérationnel
Conception sécurisée	Réduire les failles dès l’origine	Développement	Moins de correctifs lourds
Gestion des vulnérabilités	Repérer et traiter les faiblesses	Cycle de vie	Réaction plus rapide
Mises à jour	Maintenir la sécurité	Après mise sur le marché	Réduction du risque résiduel
Conformité et marquage CE	Attester le respect du cadre	Avant commercialisation	Accès au marché européen

Selon la Commission européenne, les microentreprises et PME peuvent bénéficier d’une application proportionnée, sans être exemptées par principe. Cette précision évite une lecture trop rassurante, car l’obligation reste bien présente malgré la taille.

Retour d’expérience d’une équipe produit face au CRA

Ce resserrement sur le fabricant se comprend mieux avec un cas concret de terrain. Une équipe produit qui suivait déjà ses correctifs a découvert que la documentation demandée par la conformité réglementaire était plus large que prévu.

Le chef de projet raconte : « Nous pensions être solides sur la sécurité informatique, mais l’audit a révélé des lacunes sur la preuve documentaire ». Cette remarque illustre un point classique, car la maturité technique ne suffit pas sans traçabilité.

Dans les faits, cette situation amène à formaliser les rôles, les versions et les canaux de mise à jour. La suite logique concerne ceux qui interviennent après la sortie d’usine, là où le contrôle devient plus préventif que structurel.

« Nous pensions être solides sur la sécurité informatique, mais l’audit a révélé des lacunes sur la preuve documentaire. »

Marc D., responsable produit

Ce regard de terrain confirme que la conformité ne se limite pas au code source, mais s’étend à l’organisation complète autour du produit.

Importateurs, distributeurs et requalification : les obligations qui suivent le fabricant

Une fois le produit mis sur le marché, les autres opérateurs prennent le relais sur le contrôle formel et la surveillance. Cette partie du cadre compte beaucoup pour les acteurs qui ne se voient pas spontanément comme responsables cyber.

Importateurs et distributeurs dans la chaîne de conformité

Le point précédent montre que le fabricant porte la charge principale, mais il ne travaille jamais seul. Selon le règlement, importateurs et distributeurs vérifient le marquage CE, la documentation requise et coopèrent avec les autorités de surveillance du marché.

Leur rôle n’est pas de reconstruire la conception du produit, mais d’empêcher qu’un matériel défectueux circule sans correction. Cette vigilance soutient la protection des données et limite les effets en cascade sur les clients.

À retenir sur ces opérateurs :

• Contrôle du marquage CE
• Vérification documentaire
• Coopération avec les autorités
• Mesures correctives possibles

« Nous avons dû revoir nos contrôles à l’arrivée, car un simple doute sur la documentation bloquait toute mise à disposition. »

Sophie M., responsable import

Selon l’ANSSI, la sécurité d’une chaîne dépend souvent du maillon le moins préparé. Cette remarque est précieuse pour les distributeurs qui découvrent que la surveillance du marché ne se limite pas à une formalité administrative.

Source : Commission européenne, « Cyber Resilience Act », Commission européenne, 2024 ; Règlement (UE) 2024/2847 du Parlement européen et du Conseil, « Règlement sur la cyber-résilience », Journal officiel de l’Union européenne, 2024 ; ANSSI, « Principes de sécurité de la chaîne d’approvisionnement numérique », ANSSI, 2024.

Les cas de requalification, de SaaS et d’open source précisent la frontière du CRA

Après la surveillance de marché, le sujet devient plus nuancé dès qu’un acteur modifie, héberge ou redistribue un produit. C’est souvent là que naissent les erreurs d’interprétation, surtout dans les équipes techniques pressées.

Modifications substantielles et requalification en fabricant

Cette zone grise prolonge directement les obligations des opérateurs déjà identifiés. Selon le règlement, une modification substantielle, notamment fonctionnelle ou logicielle, peut faire basculer un simple utilisateur dans le statut de fabricant.

Un intégrateur qui ajoute un composant, change l’usage prévu ou augmente le niveau de risque ne reste pas à l’écart du dispositif. Dans une PME, ce basculement surprend souvent, car le produit semble identique de l’extérieur.

Le bon réflexe consiste alors à documenter la nature exacte du changement, puis à vérifier s’il altère les fonctions essentielles. Cette discipline évite des écarts coûteux et prépare le passage vers les cas particuliers du SaaS et de l’open source.

« Le point qui nous a surpris, c’est qu’une petite modification fonctionnelle peut suffire à nous faire entrer dans le régime du fabricant. »

Claire T., directrice technique

Cette vigilance se révèle encore plus utile quand le produit dépend d’un service à distance ou de composants libres intégrés dans une offre commerciale.

À retenir sur la requalification :

• Usage prévu altéré
• Risque cyber accru
• Fonctions essentielles modifiées
• Obligations complètes réactivées

SaaS, traitement à distance et logiciels libres

Le dernier angle du dispositif clarifie ce qui reste en dehors du champ, sans créer d’ambiguïté excessive. Selon le règlement, les SaaS autonomes et les services cloud relèvent en principe d’autres cadres, tandis que les fonctions à distance indispensables au produit peuvent être intégrées au périmètre du CRA.

La différence est pratique : si le service à distance est indispensable au fonctionnement essentiel, il devient une composante du produit. À l’inverse, un logiciel libre fourni sans monétisation et hors activité commerciale reste, par principe, exclu.

Un éditeur open source qui alimente ensuite un produit vendu change de logique, surtout si la solution est intégrée dans une offre commerciale. C’est ici que la sécurité informatique rencontre la stratégie de distribution et la gouvernance de conformité réglementaire.

À retenir sur les cas limites :

• SaaS autonome généralement hors champ
• Traitement à distance parfois intégré
• Open source non monétisé exclu
• Open source commercialisé potentiellement concerné

Cette frontière technique et juridique montre que la cyber-résilience ne se décide pas seulement au moment du lancement, mais tout au long du cycle produit.

« L’analyse des dépendances nous a forcés à distinguer un service accessoire d’une fonction essentielle. »

Julien R., architecte sécurité

Source : Commission européenne, « Cyber Resilience Act », Commission européenne, 2024 ; Règlement (UE) 2024/2847 du Parlement européen et du Conseil, « Règlement sur la cyber-résilience », Journal officiel de l’Union européenne, 2024 ; ANSSI, « Principes de sécurité de la chaîne d’approvisionnement numérique », ANSSI, 2024.

Le règlement européen sur la cyber-résilience change la manière d’aborder la sécurité informatique des produits numériques. Il ne s’adresse pas d’abord à des secteurs, mais à des opérateurs qui mettent des biens connectés ou logiciels sur le marché de l’Union.

Cette logique compte déjà pour les fabricants, les importateurs, les distributeurs et certains intégrateurs qui modifient un produit en profondeur. Elle impose une vraie gestion des risques, une conformité réglementaire suivie et un plan de réponse aux incidents crédible, d’où l’importance de bien distinguer les responsabilités avant d’avancer vers A retenir :

A retenir :

• Opérateurs définis par le rôle sur le produit
• Fabricant au centre des obligations cyber
• Importateurs et distributeurs sous surveillance
• Modifications substantielles, risque de requalification
• Open source et SaaS, périmètre différencié

Le champ du CRA repose sur la mise sur le marché des produits numériques

Le passage décisif pour comprendre la cyber-résilience tient à une idée simple : le CRA vise les produits comportant des éléments numériques, pas les entreprises comme entités abstraites. Selon la Commission européenne, l’approche est fonctionnelle, ce qui relie directement l’obligation au rôle joué dans la mise à disposition commerciale.

Une PME, une grande société ou une startup peuvent donc entrer dans le champ du texte selon leur activité concrète. Cette logique protège la chaîne de cybersécurité en évitant les angles morts entre production, distribution et exploitation, et elle soutient aussi la protection des données dans l’écosystème concerné.

À retenir sur le périmètre :

• Mise sur le marché dans l’Union
• Activité commerciale déterminante
• Statut juridique indifférent
• Rôle produit, pas taille d’entreprise

Acteur	Critère d’entrée	Effet principal	Risque associé
Fabricant	Conçoit ou fait concevoir	Supporte les obligations principales	Non-conformité produit
Importateur	Fait entrer le produit sur le marché	Vérifie les exigences formelles	Mise à disposition irrégulière
Distributeur	Rend le produit disponible	Contrôle et coopération	Manquement de surveillance
Intégrateur modifiant	Change le produit de manière substantielle	Peut devenir fabricant	Requalification complète

Selon le règlement (UE) 2024/2847, la logique horizontale évite de traiter séparément chaque filière. Cette lecture est utile à un responsable conformité qui doit arbitrer vite, notamment quand des produits circulent entre plusieurs États membres.

Pourquoi la forme de l’entreprise compte moins que la fonction exercée

Cette première lecture du CRA prolonge l’idée précédente : ce n’est pas la forme sociale qui déclenche le texte, mais l’action sur le produit. Selon la Commission européenne, le législateur a voulu couvrir des modèles économiques très différents avec un même cadre de cybersécurité.

Dans la pratique, cela évite les contournements par changement de structure interne. Une filiale, une jeune pousse ou un acteur industriel classique peuvent se retrouver soumis aux mêmes exigences si leur rôle dans la chaîne devient comparable.

À retenir sur les opérateurs :

• SAS, SA, PME, startup indifférentes
• Analyse fondée sur l’activité réelle
• Responsabilité liée au produit
• Cadre harmonisé pour l’Union

Ce point prépare le terrain pour l’acteur central du dispositif, car c’est lui qui absorbe l’essentiel des obligations techniques et organisationnelles.

La logique de chaîne d’approvisionnement dans le CRA

Le changement d’échelle devient visible dès que plusieurs intervenants touchent le même produit. Le texte organise une chaîne où chacun a une part de vigilance, ce qui renforce la continuité d’activité en cas de défaut détecté tardivement.

Une société qui fabrique en Europe, assemble ailleurs puis distribue sur le marché interne ne peut ignorer cette distribution des responsabilités. Selon l’Agence de l’Union européenne pour la cybersécurité, la maîtrise du risque dépend souvent de la qualité des rôles attribués en amont.

Dans un audit, ce raisonnement aide à poser une question concrète : qui a contrôlé quoi, à quel moment, et sur quelle base documentaire ? Cette méthode simple clarifie aussi le lien avec la conformité réglementaire.

Le point suivant précise justement qui porte la charge la plus lourde lorsque le produit arrive au stade de la commercialisation.

Le fabricant supporte l’essentiel des obligations de cybersécurité

Après le périmètre général, le cœur du dispositif se concentre sur le fabricant, car il pilote la conception et la mise sur le marché. Cette position explique pourquoi la gestion des vulnérabilités, les mises à jour et l’évaluation de conformité y sont fortement encadrées.

Conception sécurisée, mises à jour et marquage CE

Cette exigence prolonge directement le rôle central du fabricant. Selon le texte européen, il doit garantir des exigences essentielles de cybersécurité, organiser le traitement des vulnérabilités et suivre la sécurité du produit pendant la période prévue.

Concrètement, un éditeur de logiciel autonome n’échappe pas à cette logique s’il commercialise son outil dans l’Union. Le même raisonnement vaut pour un constructeur qui embarque un logiciel dans un équipement médical, industriel ou domotique.

Un responsable produit prudent anticipe déjà la maintenance, les correctifs et l’évaluation de conformité avant la première vente. C’est précisément ce réflexe qui réduit les interruptions de service et protège les clients en aval.

À retenir sur le fabricant :

• Exigences essentielles de cybersécurité
• Gestion structurée des vulnérabilités
• Mises à jour de sécurité suivies
• Évaluation de conformité obligatoire
• Marquage CE à l’appui

Obligation	Finalité	Moment clé	Impact opérationnel
Conception sécurisée	Réduire les failles dès l’origine	Développement	Moins de correctifs lourds
Gestion des vulnérabilités	Repérer et traiter les faiblesses	Cycle de vie	Réaction plus rapide
Mises à jour	Maintenir la sécurité	Après mise sur le marché	Réduction du risque résiduel
Conformité et marquage CE	Attester le respect du cadre	Avant commercialisation	Accès au marché européen

Selon la Commission européenne, les microentreprises et PME peuvent bénéficier d’une application proportionnée, sans être exemptées par principe. Cette précision évite une lecture trop rassurante, car l’obligation reste bien présente malgré la taille.

Retour d’expérience d’une équipe produit face au CRA

Ce resserrement sur le fabricant se comprend mieux avec un cas concret de terrain. Une équipe produit qui suivait déjà ses correctifs a découvert que la documentation demandée par la conformité réglementaire était plus large que prévu.

Le chef de projet raconte : « Nous pensions être solides sur la sécurité informatique, mais l’audit a révélé des lacunes sur la preuve documentaire ». Cette remarque illustre un point classique, car la maturité technique ne suffit pas sans traçabilité.

Dans les faits, cette situation amène à formaliser les rôles, les versions et les canaux de mise à jour. La suite logique concerne ceux qui interviennent après la sortie d’usine, là où le contrôle devient plus préventif que structurel.

« Nous pensions être solides sur la sécurité informatique, mais l’audit a révélé des lacunes sur la preuve documentaire. »

Marc D., responsable produit

Ce regard de terrain confirme que la conformité ne se limite pas au code source, mais s’étend à l’organisation complète autour du produit.

Importateurs, distributeurs et requalification : les obligations qui suivent le fabricant

Une fois le produit mis sur le marché, les autres opérateurs prennent le relais sur le contrôle formel et la surveillance. Cette partie du cadre compte beaucoup pour les acteurs qui ne se voient pas spontanément comme responsables cyber.

Importateurs et distributeurs dans la chaîne de conformité

Le point précédent montre que le fabricant porte la charge principale, mais il ne travaille jamais seul. Selon le règlement, importateurs et distributeurs vérifient le marquage CE, la documentation requise et coopèrent avec les autorités de surveillance du marché.

Leur rôle n’est pas de reconstruire la conception du produit, mais d’empêcher qu’un matériel défectueux circule sans correction. Cette vigilance soutient la protection des données et limite les effets en cascade sur les clients.

À retenir sur ces opérateurs :

• Contrôle du marquage CE
• Vérification documentaire
• Coopération avec les autorités
• Mesures correctives possibles

« Nous avons dû revoir nos contrôles à l’arrivée, car un simple doute sur la documentation bloquait toute mise à disposition. »

Sophie M., responsable import

Selon l’ANSSI, la sécurité d’une chaîne dépend souvent du maillon le moins préparé. Cette remarque est précieuse pour les distributeurs qui découvrent que la surveillance du marché ne se limite pas à une formalité administrative.

Source : Commission européenne, « Cyber Resilience Act », Commission européenne, 2024 ; Règlement (UE) 2024/2847 du Parlement européen et du Conseil, « Règlement sur la cyber-résilience », Journal officiel de l’Union européenne, 2024 ; ANSSI, « Principes de sécurité de la chaîne d’approvisionnement numérique », ANSSI, 2024.

Les cas de requalification, de SaaS et d’open source précisent la frontière du CRA

Après la surveillance de marché, le sujet devient plus nuancé dès qu’un acteur modifie, héberge ou redistribue un produit. C’est souvent là que naissent les erreurs d’interprétation, surtout dans les équipes techniques pressées.

Modifications substantielles et requalification en fabricant

Cette zone grise prolonge directement les obligations des opérateurs déjà identifiés. Selon le règlement, une modification substantielle, notamment fonctionnelle ou logicielle, peut faire basculer un simple utilisateur dans le statut de fabricant.

Un intégrateur qui ajoute un composant, change l’usage prévu ou augmente le niveau de risque ne reste pas à l’écart du dispositif. Dans une PME, ce basculement surprend souvent, car le produit semble identique de l’extérieur.

Le bon réflexe consiste alors à documenter la nature exacte du changement, puis à vérifier s’il altère les fonctions essentielles. Cette discipline évite des écarts coûteux et prépare le passage vers les cas particuliers du SaaS et de l’open source.

« Le point qui nous a surpris, c’est qu’une petite modification fonctionnelle peut suffire à nous faire entrer dans le régime du fabricant. »

Claire T., directrice technique

Cette vigilance se révèle encore plus utile quand le produit dépend d’un service à distance ou de composants libres intégrés dans une offre commerciale.

À retenir sur la requalification :

• Usage prévu altéré
• Risque cyber accru
• Fonctions essentielles modifiées
• Obligations complètes réactivées

SaaS, traitement à distance et logiciels libres

Le dernier angle du dispositif clarifie ce qui reste en dehors du champ, sans créer d’ambiguïté excessive. Selon le règlement, les SaaS autonomes et les services cloud relèvent en principe d’autres cadres, tandis que les fonctions à distance indispensables au produit peuvent être intégrées au périmètre du CRA.

La différence est pratique : si le service à distance est indispensable au fonctionnement essentiel, il devient une composante du produit. À l’inverse, un logiciel libre fourni sans monétisation et hors activité commerciale reste, par principe, exclu.

Un éditeur open source qui alimente ensuite un produit vendu change de logique, surtout si la solution est intégrée dans une offre commerciale. C’est ici que la sécurité informatique rencontre la stratégie de distribution et la gouvernance de conformité réglementaire.

À retenir sur les cas limites :

• SaaS autonome généralement hors champ
• Traitement à distance parfois intégré
• Open source non monétisé exclu
• Open source commercialisé potentiellement concerné

Cette frontière technique et juridique montre que la cyber-résilience ne se décide pas seulement au moment du lancement, mais tout au long du cycle produit.

« L’analyse des dépendances nous a forcés à distinguer un service accessoire d’une fonction essentielle. »

Julien R., architecte sécurité

Source : Commission européenne, « Cyber Resilience Act », Commission européenne, 2024 ; Règlement (UE) 2024/2847 du Parlement européen et du Conseil, « Règlement sur la cyber-résilience », Journal officiel de l’Union européenne, 2024 ; ANSSI, « Principes de sécurité de la chaîne d’approvisionnement numérique », ANSSI, 2024.

À retenir

Une défense européenne qui se construit dossier après dossier

Qu'il s'agisse de budgets militaires, de coopération avec l'OTAN, d'initiatives européennes, d'impacts économiques ou de perspectives d'avenir, chaque rubrique raconte une facette différente de la même question : comment l'Europe assume, aujourd'hui, sa propre sécurité. Rien n'est figé : chaque texte adopté et chaque investissement engagé peut encore faire évoluer cet équilibre.

Pour aller plus loin

• Comparer plusieurs sources avant de juger la fiabilité d'un chiffre ou d'une échéance stratégique
• Replacer chaque initiative européenne dans son calendrier d'application réel, pas seulement sa date d'annonce
• S'intéresser aux dépendances industrielles autant qu'aux annonces politiques
• Suivre l'actualité européenne pour voir ces équilibres évoluer d'une année à l'autre