Le CRA Reçoit Son Manuel d'Instructions : Ce que la Guidance de la Commission Signifie pour Vous

Le Cyber Resilience Act dispose de son texte depuis fin 2024. Ce qui lui manquait, c'était un manuel d'instructions. Le 3 mars 2026, la Commission européenne a publié exactement cela : le projet de Communication Ares(2026)2319816 — environ 70 pages de guidance pratique sur la manière d'interpréter le règlement.

Il s'agit de la guidance Article 26 que l'industrie attendait. Voici ce qu'elle dit et ce que cela signifie pour vous.

Introduction

Le projet de Communication Ares(2026)2319816, daté du 3 mars 2026, est le premier document de guidance complet de la Commission européenne sur le Cyber Resilience Act. Avec environ 70 pages, il couvre les questions qui ont tenu les équipes de conformité éveillées la nuit : Qu'est-ce qui compte comme « traitement de données à distance » ? Les produits existants ont-ils besoin d'une refonte complète ? À quel moment une mise à jour logicielle devient-elle un nouveau produit ?

Cet article synthétise les neuf décisions les plus importantes en guidance pratique pour les fabricants, importateurs et distributeurs de produits comportant des éléments numériques.

1. SaaS et Cloud : Le Test RDPS

La Commission introduit un test strict en trois questions pour déterminer si un composant cloud ou SaaS se qualifie comme « solution de traitement de données à distance » (RDPS) et entre donc dans le périmètre d'évaluation de la conformité du produit.

flowchart TD
    A["La solution traite-t-elle des données
« à distance » ?"] -->|Non| B["Pas RDPS"]
    A -->|Oui| C["Le produit perdrait-il une fonction centrale
sans cette solution ?"]
    C -->|Non| D["Pas RDPS
(traiter comme composant,
diligence raisonnable selon Art 13(5))"]
    C -->|Oui| E["Conçu par ou sous la responsabilité
du fabricant ?"]
    E -->|Non| F["Pas RDPS
(SaaS tiers = composant,
diligence raisonnable selon Art 13(5))"]
    E -->|Oui| G["RDPS : dans le périmètre
d'évaluation de la conformité du produit"]

La guidance illustre cela avec cinq scénarios concrets : une application bancaire, un thermostat intelligent, une liseuse électronique, un robot industriel et un équipement de réseau cellulaire.

Important : Même lorsqu'un service cloud ne se qualifie pas comme RDPS, le fabricant doit tout de même le traiter comme un composant et effectuer une diligence raisonnable sur la chaîne d'approvisionnement conformément à l'Article 13(5). L'obligation de sécurité ne disparaît pas — elle se déplace de l'évaluation de la conformité vers la gestion des composants.

2. Produits Existants

Les produits déjà sur le marché de l'UE avant décembre 2027 n'ont pas besoin d'être reconçus de zéro. Mais ils ne sont pas non plus exemptés.

La Commission clarifie trois points :

Aucune reconstruction historique requise. Vous n'avez pas besoin de recréer la documentation de développement d'années passées. Ce qui compte, c'est une évaluation actuelle des risques de cybersécurité démontrant que le produit satisfait aux exigences essentielles sur la base de sa destination prévue.

Les familles de produits peuvent être regroupées. Si plusieurs produits existants partagent la même architecture et le même profil de risque, vous pouvez effectuer une évaluation des risques unique couvrant la famille plutôt que d'évaluer chaque référence individuellement.

La conformité totale s'applique tout de même. Les produits existants ont toujours besoin du marquage CE, d'une Déclaration de conformité et d'une gestion active des vulnérabilités à l'avenir. L'allègement porte sur l'historique de documentation, pas sur les obligations elles-mêmes.

Pour une présentation détaillée du processus d'évaluation de la conformité, consultez notre Guide de Décision pour l'Évaluation de la Conformité. Pour la planification des périodes de support sur les produits existants, consultez Planification de la Période de Support.

3. Logiciels et « Copies Infinies »

Quand un logiciel est-il « mis sur le marché » ? La Commission confirme : une seule fois. La distribution numérique initiale constitue la mise sur le marché. Les mises à jour mineures ultérieures (par exemple, v1.0.0 vers v1.0.1) ne réinitialisent pas l'horloge réglementaire.

Cela s'applique spécifiquement aux logiciels autonomes distribués numériquement. Les produits matériels avec logiciels embarqués suivent les règles standard de mise sur le marché des biens physiques.

4. Quand les Mises à Jour Deviennent des « Modifications Substantielles »

Cette section est la partie la plus actionnable de l'ensemble de la guidance. La Commission fournit des exemples concrets distinguant les mises à jour de routine des modifications qui déclenchent une nouvelle évaluation de la conformité.

La Commission suggère quatre questions que chaque fabricant devrait se poser avant de publier une mise à jour :

1. La mise à jour introduit-elle de nouveaux vecteurs de menace ?
2. Permet-elle de nouveaux scénarios d'attaque ?
3. Modifie-t-elle la probabilité de scénarios d'attaque existants ?
4. Modifie-t-elle l'impact de scénarios d'attaque existants ?

Si la réponse à l'une de ces questions est oui, la mise à jour constitue probablement une modification substantielle nécessitant une nouvelle évaluation de la conformité.

Pour en savoir plus sur la classification des produits et son interaction avec les modifications, consultez notre Guide de Classification des Produits.

5. Règles pour l'Open Source

La guidance fournit plusieurs clarifications importantes sur la manière dont le CRA s'applique aux logiciels open source :

• Publier du code source sur des dépôts publics ne constitue pas une « mise sur le marché ». Le CRA s'applique au point de distribution commerciale, pas au point de disponibilité du code.
• Édition communautaire vs. édition payante = produits différents. Si vous proposez une version communautaire gratuite et une version commerciale payante, seule la version payante déclenche les obligations du fabricant.
• Les dons seuls ne rendent pas un FOSS commercial — à moins que l'accès au logiciel ne soit conditionné à un don. Les dons volontaires sont explicitement exclus.
• Les entités à but non lucratif dont le surplus va entièrement à des objectifs à but non lucratif sont exemptées des obligations du fabricant, même si elles monétisent.
• Les contributeurs sans contrôle sur les versions, la feuille de route ou la gouvernance ne sont PAS considérés comme des fabricants — même s'ils disposent d'un accès en validation. La responsabilité incombe à celui qui contrôle le processus de publication.
• Les obligations des intendants open source varient selon le niveau de support fourni. L'intendance non technique comporte des obligations plus légères que le support commercial complet.

Pour une guidance connexe sur la divulgation coordonnée des vulnérabilités dans les contextes open source, consultez notre Modèle de Politique CVD.

6. Période de Support : Cinq Ans Constitue un Plancher

La Commission indique clairement que la période de support par défaut de cinq ans est un minimum, pas un objectif. Les produits dont on prévoit qu'ils resteront en usage pendant plus de cinq ans doivent avoir des périodes de support proportionnellement plus longues.

La guidance clarifie également la voie de l'Article 13(10) : les fabricants peuvent cesser de corriger les versions plus anciennes si les utilisateurs peuvent passer gratuitement à une version supportée. Les « coûts supplémentaires » dans ce contexte désignent les achats de matériel obligatoires — les tests de routine, la reconfiguration ou l'effort de déploiement de la part de l'utilisateur ne se qualifient pas.

Pour des stratégies de planification détaillées, consultez notre Guide de Planification de la Période de Support.

7. Évaluation des Risques : L'Appétit pour le Risque Interne n'est Pas Pertinent

La Commission est sans ambiguïté : les évaluations des risques dans le cadre du CRA doivent être basées sur des critères de cybersécurité objectifs, et non sur l'appétit pour le risque interne du fabricant. Plus précisément :

• La stratégie commerciale et les considérations de coût n'entrent pas en compte dans l'évaluation des risques de cybersécurité.
• Vous ne pouvez pas transférer le risque de cybersécurité aux utilisateurs via la documentation, les avertissements ou les conditions d'utilisation.
• Si les risques identifiés ne peuvent pas être traités par des mesures techniques ou organisationnelles, le produit peut nécessiter des modifications de conception avant de pouvoir être mis sur le marché.

C'est une déclaration importante. Elle signifie qu'un fabricant ne peut pas sciemment commercialiser un produit présentant des risques de cybersécurité non atténués simplement parce que l'entreprise a « accepté » ce risque.

Pour un aperçu des implications en termes de coûts de conformité, consultez notre Guide d'Estimation des Coûts de Conformité.

8. Vulnérabilités Exploitables Connues

La guidance clarifie ce que signifie « connu » dans le contexte de l'exigence du CRA de commercialiser des produits sans vulnérabilités exploitables connues :

• Répertoriées dans des bases de données publiques : Base de données européenne des vulnérabilités, CVE/MITRE, NVD.
• Divulguées via des canaux non publics : programmes de divulgation coordonnée des vulnérabilités, tests de sécurité internes, tests de pénétration par des tiers.
• Largement rapportées dans des médias fiables : une vulnérabilité majeure couverte par les principales publications de cybersécurité est considérée comme « connue ».

Les fabricants disposent d'une fenêtre d'investigation limitée pour confirmer si une vulnérabilité signalée s'applique réellement à leur produit. Mais l'« investigation » n'est pas une échappatoire — le délai court à partir de la prise de connaissance, et les retards seront scrutés.

Pour une guidance pratique sur la documentation des vulnérabilités, consultez notre Guide VEX.

9. Obligations de Signalement (Septembre 2026)

Les obligations de signalement de septembre 2026 constituent le premier délai du CRA assorti de véritables mécanismes d'application. La guidance confirme la structure du calendrier :

• 24 heures : Alerte précoce à ENISA après avoir pris connaissance d'une exploitation active
• 72 heures : Notification détaillée avec indicateurs techniques
• 14 jours : Rapport final pour les vulnérabilités / 30 jours pour les incidents

« Avoir connaissance » signifie une certitude raisonnable après une évaluation initiale — pas une confirmation médico-légale complète. Si vous disposez de preuves crédibles d'exploitation active, le délai est en cours.

Sur la notification des utilisateurs : la Commission confirme que cela devrait être basé sur le risque et proportionné. Il n'y a pas d'obligation de divulgation publique obligatoire si la divulgation augmente le risque de sécurité.

Pour une présentation complète du processus de signalement, consultez notre Guide de Signalement ENISA en 24 Heures. Pour le calendrier de conformité complet, consultez notre Calendrier de Mise en Œuvre.

Ce que Cela Signifie pour Vous

Cette guidance ne modifie pas ce que le CRA exige. Mais elle modifie la part de conjecture impliquée. Les fabricants disposent désormais de tests concrets (RDPS), d'exemples concrets (modifications substantielles) et de délais concrets (signalement) sur lesquels travailler.

Trois actions immédiates :

1. Appliquez le test RDPS à chaque service cloud dont votre produit dépend. CRA Evidence automatise cette évaluation dans le cadre de son analyse des risques produit.
2. Réexaminez votre processus de mise à jour au regard des quatre questions sur les modifications substantielles. Intégrez-les à votre liste de contrôle de publication.
3. Préparez-vous pour le signalement de septembre 2026. Les processus internes de triage, les voies d'escalade et les modèles de rapport doivent être en place avant l'échéance.

La période de consultation est ouverte via le portail Mieux légiférer. Si vous avez des avis sur la guidance, c'est le moment de les exprimer.

Pour une approche étape par étape de la conformité au CRA, consultez notre Guide de Conformité pour les Startups.

Cet article est basé sur le projet de Communication Ares(2026)2319816, daté du 3 mars 2026. Cette guidance n'a pas encore été formellement adoptée par la Commission européenne et sera finalisée une fois que toutes les versions linguistiques de l'UE seront disponibles.