Cyber Resilience Act : votre logiciel est-il concerné ?
Votre logiciel est-il concerné par le Cyber Resilience Act ? Périmètre, dates 2026-2027 et dossier de préparation en six preuves.
Le Cyber Resilience Act (CRA) concerne d’abord les entreprises qui mettent sur le marché européen, sous leur nom ou leur marque, un produit matériel ou logiciel comportant des éléments numériques. Il ne rend pas automatiquement chaque site web ou chaque service SaaS conforme à une nouvelle checklist universelle.
La première décision consiste à qualifier le produit, le rôle de l’entreprise, sa mise à disposition sur le marché et les traitements distants indispensables à son fonctionnement. Si le produit entre dans le périmètre, les obligations de signalement des vulnérabilités activement exploitées et des incidents graves commencent le 11 septembre 2026. Les principales exigences de conformité s’appliquent à partir du 11 décembre 2027.
Avant d’acheter un audit ou de réécrire le logiciel, construisez donc un dossier court : périmètre, risques, composants, canal de vulnérabilité, période de support et procédure de signalement. Il révélera ce qui manque réellement.
Qu’est-ce que le Cyber Resilience Act ?
Le CRA est le règlement européen 2024/2847 sur la cybersécurité des produits comportant des éléments numériques. Il couvre leur conception, leur développement, leur mise sur le marché, la gestion des vulnérabilités et le support après livraison.
La synthèse officielle de la Commission européenne définit un produit avec éléments numériques comme un produit matériel ou logiciel, avec les éventuelles solutions de traitement à distance dont l’absence empêcherait l’une de ses fonctions. La page de référence de l’ANSSI distingue ensuite les produits par défaut, importants de classe I ou II et critiques.
Cette classification change la procédure d’évaluation. Elle ne doit pas être déduite d’un mot présent sur une page commerciale. La fonction principale du produit, sa manière d’être mis à disposition et le rôle réel de l’entreprise comptent davantage que l’étiquette « application », « plateforme » ou « SaaS ».
Le CRA porte sur la sécurité d’un produit mis sur le marché. La directive NIS 2 organise, elle, la cybersécurité de certaines entités et de leurs systèmes d’information. Une entreprise peut rencontrer les deux cadres, un seul ou aucun. Les confondre produit surtout des listes de contrôles sans propriétaire.
Quels logiciels peuvent être concernés ?
Un logiciel distribué sous le nom de l’entreprise, une application mobile, un logiciel installé chez le client, un composant vendu séparément ou un objet connecté accompagné de son application peuvent entrer dans le périmètre. Une solution de traitement de données à distance peut aussi appartenir au produit lorsqu’elle a été conçue par le fabricant — ou sous sa responsabilité — et qu’une fonction du produit ne pourrait pas s’exécuter sans elle.
Pour un objet connecté, cette qualification cyber doit rester distincte de la recette d’accès aux données imposée par le Data Act : le CRA traite la sécurité et le cycle de vie du produit, tandis que le Data Act organise l’accès aux données générées par son usage.
À l’inverse, un service cloud autonome, un site éditorial ou un développement strictement interne ne doit pas être déclaré concerné par réflexe. La qualification d’un SaaS dépend notamment de ce qui est réellement mis sur le marché, de la relation entre le logiciel et le traitement distant, ainsi que du rôle assumé par l’entreprise. La nouvelle guidance de la Commission publiée le 27 juillet 2026 traite précisément le périmètre, les traitements distants, les modifications substantielles, les périodes de support et le signalement. Elle reste non contraignante : le règlement et l’analyse du cas conservent la priorité.
La matrice produit–rôle–marché–dépendance
Remplissez une ligne par produit, version ou composant réellement proposé. Une réponse incertaine devient une question à instruire, pas un « oui » implicite.
| Axe | Question à documenter | Preuve minimale | Décision suivante |
|---|---|---|---|
| Produit | Quel logiciel ou matériel forme l’unité proposée ? | description, versions, composants et fonctions principales | définir ce qui doit être évalué ensemble |
| Rôle | Qui le développe, le commercialise et appose son nom ? | contrats, marque, responsabilités et chaîne de distribution | distinguer fabricant, importateur et distributeur |
| Marché | Comment le produit est-il mis à disposition dans l’Union européenne ? | modèle de vente, licence, téléchargement ou distribution | vérifier si la mise sur le marché est caractérisée |
| Dépendance distante | Une fonction disparaît-elle sans le service distant ? | schéma de flux et comportement hors connexion | inclure ou séparer le traitement distant |
| Cycle de vie | Le produit existait-il avant 2027 et sera-t-il substantiellement modifié ? | historique des versions et changements prévus | qualifier la transition et les nouvelles obligations |
Cette matrice ne rend aucun avis de conformité. Elle évite toutefois une erreur courante : appliquer un plan de mise en conformité complet avant même d’avoir défini le produit et la personne juridiquement responsable.
Qui porte les obligations ?
Les principales obligations visent le fabricant : la personne physique ou morale qui développe ou fait développer un produit avec éléments numériques et le commercialise sous son nom ou sa marque, contre paiement, monétisation ou parfois gratuitement. Importateurs et distributeurs ont aussi des obligations propres dans la chaîne de mise sur le marché.
Cette définition empêche de confondre prestataire technique et fabricant. Une agence peut développer le code sans décider du produit, de la marque, de la distribution ou de la période de support. Inversement, une entreprise qui fait réaliser le produit puis le met sur le marché sous son nom ne transfère pas automatiquement son rôle au développeur.
Le contrat doit donc répondre à quatre questions : qui décide des exigences de sécurité, qui reçoit les signalements, qui finance et publie les correctifs, et qui conserve la documentation nécessaire à l’évaluation. Ces responsabilités prolongent les questions de propriété, architecture et exploitation d’un logiciel métier. Elles ne peuvent pas rester dans une annexe que personne n’utilise après la livraison.
Quelles dates faut-il préparer en 2026 et 2027 ?
Le calendrier comporte trois étapes différentes.
| Date | Ce qui change | Décision pratique |
|---|---|---|
| 11 juin 2026 | les dispositions relatives à la notification des organismes d’évaluation commencent à s’appliquer | vérifier si la classe du produit impose l’intervention d’un tiers |
| 11 septembre 2026 | le signalement de certaines vulnérabilités activement exploitées et de certains incidents graves devient applicable | nommer le responsable, le suppléant et tester la collecte des informations |
| 11 décembre 2027 | les principales obligations du CRA deviennent applicables | intégrer risques, exigences, documentation, évaluation et support au cycle produit |
La Commission précise que le signalement concerne les produits avec éléments numériques déjà mis à disposition sur le marché, y compris avant décembre 2027. Pour les autres exigences, un produit mis sur le marché avant cette date n’entre pas automatiquement dans le nouveau régime complet ; une modification substantielle après l’échéance peut changer la conclusion.
Ne transformez donc pas décembre 2027 en unique date de démarrage. Une organisation incapable aujourd’hui de relier une vulnérabilité à un produit, une version, un composant et un responsable ne pourra pas fabriquer cette chaîne en vingt-quatre heures le jour d’un incident.
Le dossier minimal CRA en six preuves
La conformité finale dépend du produit, de sa classe et des textes applicables. Le dossier suivant n’est pas une certification. Il constitue un socle opérationnel pour découvrir les responsabilités et les preuves manquantes.
1. Un registre des produits et des rôles
Listez chaque produit, version maintenue, composant distribué, service distant nécessaire, territoire, marque et rôle économique. Associez une personne qui peut arbitrer le périmètre.
Un inventaire de serveurs ne suffit pas. Le CRA suit des produits mis sur le marché, alors que l’exploitation suit souvent des environnements techniques. Il faut relier les deux vues.
2. Une évaluation des risques de cybersécurité
Pour chaque produit, identifiez les actifs protégés, les usages prévus, les surfaces d’attaque, les conséquences d’une compromission et les mesures retenues. La Commission indique que cette évaluation doit guider la conception, le développement, la production, la livraison et la maintenance.
Commencez par les parcours dont l’échec affecte disponibilité, intégrité, authenticité ou confidentialité. Une liste générique de menaces devient utile seulement lorsqu’elle modifie une décision d’architecture, de permission, de test ou de support.
3. Un inventaire des composants et dépendances
Reliez chaque version livrée à ses bibliothèques, composants, services critiques et responsables de mise à jour. Conservez les versions, les sources et les conditions de remplacement.
Ce travail rejoint celui de la dette technique et de sécurité : une dépendance inconnue ne coûte pas seulement lors d’une migration. Elle empêche aussi d’évaluer rapidement si une vulnérabilité touche le produit distribué.
4. Un processus de réception et de traitement des vulnérabilités
Définissez un point de contact, une méthode de tri, les critères de gravité, le propriétaire de la correction et la manière d’informer les utilisateurs. Testez le flux avec une vulnérabilité fictive sur une version encore supportée.
La réception seule ne suffit pas. Le processus doit relier le signal à la version concernée, produire une décision, préparer le correctif, conserver les éléments utiles et suivre sa diffusion.
5. Une période de support et une politique de mise à jour
Documentez la durée pendant laquelle les vulnérabilités seront traitées, les versions couvertes, le canal de mise à jour et la fin de support annoncée. Cette durée doit être cohérente avec l’usage attendu du produit et les attentes raisonnables des utilisateurs.
La période de support devient alors une décision produit et budgétaire. Elle engage des compétences, une capacité de correction, une infrastructure de distribution et une communication. Un contrat de maintenance vague ne peut pas remplacer cette responsabilité.
Lorsque cette maintenance passe par un éditeur ou un intégrateur externe, la recette des accès distants au logiciel métier vérifie séparément le canal, l’identité, le périmètre, l’expiration et les alertes de chaque intervention.
6. Une procédure de signalement et un exercice
À partir du 11 septembre 2026, les fabricants concernés utilisent la plateforme unique de signalement gérée par l’ENISA. La FAQ de l’ENISA mise à jour le 17 juillet 2026 distingue les vulnérabilités activement exploitées des incidents graves affectant la sécurité du produit.
La procédure doit permettre une alerte précoce sous vingt-quatre heures, une notification complétée sous soixante-douze heures, puis un rapport final selon le type d’événement et sa correction. Avant l’échéance, organisez un exercice : qui constate, qui qualifie, qui décide, qui rassemble les versions et utilisateurs concernés, et qui dispose de l’autorité pour notifier ?
Comment intégrer le CRA au développement sans créer un projet parallèle ?
Le CRA ne devrait pas devenir un classeur séparé du produit. Chaque preuve doit être produite par une activité qui existe déjà ou qui manque réellement au cycle de vie.
| Moment du produit | Question CRA utile | Artefact exploitable |
|---|---|---|
| Cadrage | quel produit, quel usage et quelle responsabilité ? | fiche de périmètre et matrice de rôle |
| Conception | quels risques changent le parcours ou l’architecture ? | décisions de sécurité et critères de recette |
| Développement | quels composants et versions entrent dans la livraison ? | inventaire traçable et historique de build |
| Recette | comment le produit réagit-il aux erreurs et attaques plausibles ? | scénarios, résultats et risques acceptés |
| Livraison | que reçoit l’utilisateur pour installer et utiliser le produit sûrement ? | instructions, version, support et canal de contact |
| Exploitation | comment détecter, corriger, informer et signaler ? | journal, correctif, notification et retour d’expérience |
Cette organisation protège aussi l’efficacité. Une preuve entretenue par le travail courant coûte moins qu’un dossier reconstitué avant une évaluation. Elle réduit le coût du prochain changement au lieu d’ajouter une seconde réalité documentaire.
Le modèle de cahier des charges Zence peut servir de point de départ pour nommer les objectifs, risques, responsabilités et critères de recette. Il ne contient pas une conformité CRA prête à signer : il aide à rendre les décisions visibles avant de choisir les contrôles adaptés.
Exemple fictif : une application reliée à un équipement
Imaginons une PME fictive qui vend dans l’Union un boîtier de mesure sous sa marque. Une application mobile configure l’équipement et un service distant calcule un indicateur indispensable à l’une de ses fonctions.
La première erreur serait de traiter séparément le boîtier, l’application et le cloud uniquement parce que trois équipes les maintiennent. La matrice doit vérifier leur dépendance fonctionnelle, le rôle de fabricant assumé par la PME, les composants distribués, les versions supportées et les modifications prévues après 2027.
Le premier mois de préparation ne chercherait pas à déclarer le produit conforme. Il produirait six éléments : périmètre signé, risques prioritaires, versions et composants, canal de vulnérabilité, politique de support, puis exercice de signalement. Les responsables sécurité et juridiques pourraient alors qualifier les écarts à partir d’un système réel.
Si le service distant était au contraire une application web autonome, sans produit matériel ou logiciel mis sur le marché auquel il fournit une fonction indispensable, l’analyse pourrait aboutir à un autre périmètre. C’est précisément pourquoi le mot « SaaS » ne suffit pas à conclure.
Cet exemple n’est ni un cas client, ni un avis sur un produit réel. Il montre comment réduire l’incertitude avant d’investir dans une architecture, une évaluation ou une documentation plus lourde.
Checklist de décision avant le 11 septembre 2026
- Le produit, ses versions et ses fonctions principales sont-ils nommés ?
- Le rôle de fabricant, importateur ou distributeur est-il documenté ?
- La mise à disposition sur le marché européen est-elle caractérisée ?
- Les traitements distants indispensables sont-ils reliés au produit ?
- Les produits existants et modifications prévues après 2027 sont-ils distingués ?
- Une personne reçoit-elle les vulnérabilités et peut-elle mobiliser l’équipe ?
- Les composants d’une version livrée peuvent-ils être retrouvés rapidement ?
- Les utilisateurs, versions et territoires affectés peuvent-ils être identifiés ?
- Un responsable et un suppléant savent-ils utiliser le processus de signalement ?
- La période de support et la fin de support sont-elles décidées et financées ?
- Un exercice a-t-il testé les délais, les informations manquantes et l’escalade ?
- Les conclusions ont-elles été relues par les fonctions sécurité et juridiques compétentes ?
Si les quatre premières réponses restent floues, ne lancez pas encore un programme de conformité complet. Clarifiez le périmètre. Si le produit est concerné mais que les questions six à neuf échouent, le processus de signalement devient prioritaire avant septembre.
Quelle première action prendre ?
Choisissez un produit réellement proposé aujourd’hui. Remplissez une seule ligne de la matrice produit–rôle–marché–dépendance, puis tentez de retrouver la version livrée, ses composants, son propriétaire et la personne qui recevrait une vulnérabilité demain matin. La première rupture observable devient le prochain travail.
La méthode Zence consiste à construire moins, mais finir ce qui compte. Pour le CRA, cela signifie produire une chaîne de preuve complète sur un produit avant de multiplier les politiques générales. Zence peut cadrer et faire évoluer un logiciel métier sur mesure en reliant architecture, dépendances, tests, documentation et exploitation. La qualification réglementaire finale doit rester relue par les responsables sécurité et juridiques appropriés.
Sources principales
- Commission européenne — Guidance sur l’application du Cyber Resilience Act, 27 juillet 2026
- Commission européenne — Synthèse du règlement Cyber Resilience Act
- Commission européenne — Obligations de signalement du CRA
- ANSSI — Cadre réglementaire du Cyber Resilience Act
- ENISA — Single Reporting Platform et FAQ, mise à jour du 17 juillet 2026
- Direction générale des Entreprises — Ce qui change avec le CRA, 12 mars 2026
- EUR-Lex — Règlement (UE) 2024/2847
