Cyber Resilience Act : la cybersécurité devient une obligation de produit, et beaucoup d’entreprises ne sont pas prêtes

Pendant des années, la cybersécurité des logiciels et des objets connectés a reposé sur une étrange convention : le fabricant vendait le produit, l’utilisateur assumait ensuite l’essentiel du risque. Un mot de passe par défaut, une application abandonnée, une caméra qui dépend d’un serveur situé à l’autre bout du monde ou un équipement qui ne reçoit plus de correctif après deux ans étaient considérés comme des problèmes techniques regrettables, mais presque ordinaires.

Cette époque touche à sa fin.

Le 27 juillet 2026, la Commission européenne a publié son guide pratique d’application du Cyber Resilience Act, ou CRA. Ce document arrive à un moment décisif : dès le 11 septembre 2026, les fabricants devront déclarer les vulnérabilités activement exploitées et certains incidents graves affectant leurs produits numériques. Les autres obligations principales entreront en application le 11 décembre 2027. 

Pour les dirigeants et les DSI, ce texte ne doit surtout pas être rangé dans la catégorie « conformité juridique à traiter plus tard ». Il transforme profondément la manière de concevoir, acheter, maintenir et commercialiser un produit contenant du logiciel.

Le CRA ne concerne pas seulement les fabricants d’objets connectés

Le mot « produit » peut induire en erreur. Le règlement couvre les équipements matériels et les logiciels comportant des éléments numériques, mais aussi certains composants vendus séparément et certaines solutions de traitement à distance indispensables au fonctionnement du produit. Une application, un système d’exploitation, un équipement réseau, une passerelle domotique, un logiciel de sauvegarde ou un appareil industriel connecté peuvent donc entrer dans son périmètre. 

Une entreprise peut également être considérée comme fabricant sans posséder une seule usine. Lorsqu’elle fait développer un logiciel ou fabriquer un appareil, puis le commercialise sous son propre nom ou sa propre marque, elle peut porter les obligations correspondantes. Les importateurs et les distributeurs ont eux aussi des responsabilités de vérification, de coopération et de retrait éventuel des produits non conformes. 

Prenons un exemple concret. Une société française achète en Asie des serrures connectées, y appose sa marque et les vend avec une application développée par un sous-traitant. Elle ne pourra pas simplement renvoyer la responsabilité vers le fabricant du matériel, l’éditeur de l’application ou l’hébergeur du cloud. Elle devra comprendre l’ensemble de la chaîne technique, organiser le traitement des vulnérabilités et être capable de démontrer la sécurité du produit qu’elle met sur le marché.

Ce qui change dès septembre 2026

L’échéance immédiate concerne la déclaration des incidents.

À compter du 11 septembre, une vulnérabilité activement exploitée ou un incident grave affectant la sécurité d’un produit numérique devra faire l’objet d’une première alerte dans les 24 heures suivant sa découverte, puis d’une notification plus complète dans les 72 heures. Des rapports finaux devront ensuite être produits selon des délais précis. Les déclarations passeront par une plateforme unique gérée par l’ENISA et seront transmises aux autorités compétentes. 

Le point le plus important est souvent ignoré : ces obligations de déclaration ne concernent pas uniquement les nouveaux produits lancés après 2027. Elles s’appliqueront également aux produits numériques déjà mis à disposition sur le marché européen. 

Une entreprise qui possède dix ans d’historique produit doit donc être capable de répondre à des questions très simples, mais parfois redoutables :

Qui sait quels produits sont encore utilisés ?

Qui reçoit les signalements de vulnérabilité ?

Qui peut décider qu’un incident est suffisamment grave pour être déclaré ?

Qui possède la liste des clients concernés ?

Qui peut produire une première analyse en moins de 24 heures ?

Une adresse électronique générique surveillée une fois par semaine ne suffira plus.

La sécurité devra être organisée sur tout le cycle de vie

Les obligations principales prévues pour 2027 vont plus loin que la gestion des incidents. Les fabricants devront réaliser une analyse de risque cybersécurité, documenter les mesures retenues, appliquer des principes de sécurité par défaut, maîtriser les accès, utiliser les mécanismes cryptographiques appropriés et gérer les mises à jour. Ils devront également traiter les vulnérabilités pendant une période de support annoncée aux utilisateurs. 

Cette dernière obligation est une petite révolution commerciale.

Aujourd’hui, la durée de support d’une caméra, d’une box, d’un logiciel ou d’un système domotique est rarement visible au moment de l’achat. L’utilisateur découvre souvent l’abandon du produit lorsque l’application disparaît, qu’un service cloud ferme ou qu’une faille reste sans correctif.

Le CRA prévoit que la date de fin de support soit clairement indiquée. La sécurité devient ainsi une caractéristique du produit, au même titre que ses performances, son prix ou sa consommation électrique. 

Une entreprise capable de garantir sept ou dix ans de correctifs pourra transformer cette contrainte en avantage concurrentiel. À l’inverse, un fabricant habitué à multiplier les références puis à les abandonner rapidement devra revoir son modèle économique.

Le vrai chantier sera organisationnel

Les équipes techniques savent généralement corriger une vulnérabilité. Le problème est rarement la production du correctif elle-même. Il réside dans le temps nécessaire pour comprendre qui est responsable, quelles versions sont touchées, quels composants externes sont concernés et quels clients utilisent encore le produit.

Le DSI devra donc rapprocher des fonctions qui travaillent souvent séparément : développement, infrastructure, cybersécurité, juridique, achats, support, qualité, communication et direction produit.

Chaque produit numérique devrait désormais disposer d’un responsable clairement identifié, d’un inventaire de ses composants, d’une procédure de traitement des vulnérabilités, d’un canal de remontée, d’une durée de support, d’un plan de mise à jour et d’un scénario de retrait.

L’inventaire logiciel devient particulièrement stratégique. Lorsqu’une bibliothèque open source critique est compromise, l’entreprise doit pouvoir déterminer rapidement quels produits l’utilisent. Une nomenclature logicielle, souvent appelée SBOM, ne résout pas tout, mais elle réduit considérablement le temps perdu à rechercher manuellement des dépendances dispersées dans plusieurs dépôts ou confiées à des sous-traitants. Le CRA impose d’ailleurs une vigilance sur les composants tiers intégrés aux produits. 

Les fournisseurs devront répondre à de nouvelles questions

Le CRA doit également changer les achats informatiques.

Avant de retenir un équipement connecté, un logiciel embarqué ou une plateforme associée à un produit, l’entreprise devra demander :

Quelle est la durée de support garantie ?

Comment les vulnérabilités sont-elles reçues et traitées ?

Qui produit les correctifs ?

Quels délais contractuels sont prévus ?

Le produit continue-t-il à fonctionner si le service cloud disparaît ?

Existe-t-il une documentation des composants ?

Qui assume les obligations européennes lorsque le fabricant est situé hors de l’Union ?

Ces questions ne doivent plus rester dans une annexe technique jamais lue. Elles influencent directement le risque juridique, opérationnel et financier de l’entreprise.

Un fournisseur qui promet un produit « sécurisé » sans préciser son processus de mise à jour, son architecture cloud et sa durée de maintenance ne fournit pas une garantie. Il fournit un slogan.

Une occasion de reprendre le contrôle

Le CRA ajoutera des coûts : documentation, tests, surveillance, maintien des compétences, traitements d’incidents et mises à jour sur plusieurs années. Certaines petites entreprises découvriront qu’un produit connecté vendu peu cher coûte beaucoup plus cher à maintenir qu’à fabriquer.

Mais cette contrainte peut aussi assainir le marché.

Elle favorisera les architectures maintenables, les produits capables de fonctionner localement, les API documentées, les composants suivis et les modèles économiques fondés sur la durée plutôt que sur l’obsolescence rapide.

Elle pourrait également renforcer la confiance des entreprises dans les objets connectés, l’edge computing et les infrastructures personnelles. Un DSI acceptera plus facilement d’intégrer un produit lorsqu’il connaît sa durée de support, son processus de correction et l’identité de l’acteur juridiquement responsable.

Le DSI devient aussi responsable de la résilience des produits

Le métier de DSI s’est longtemps concentré sur les outils utilisés par l’entreprise. Il doit désormais s’intéresser également aux logiciels et équipements que l’entreprise vend à ses clients.

Lorsqu’un produit contient du code, dépend d’une API ou communique avec un service distant, il devient une composante du risque numérique global.

Le guide publié par la Commission le 27 juillet apporte 67 exemples pratiques, des cas d’usage et des schémas pour clarifier notamment le périmètre du règlement, les modifications substantielles, les périodes de support, les analyses de risque et les déclarations d’incidents. Il est non contraignant, mais il fournit enfin une base concrète pour commencer le travail. 

La bonne décision n’est donc pas de créer un groupe de travail pour 2027. Elle consiste à tester dès maintenant la capacité de l’entreprise à détecter, qualifier et déclarer un incident sur l’un de ses produits en moins de 24 heures.

Beaucoup découvriront alors que le problème n’est pas l’absence d’un outil supplémentaire. C’est l’absence d’une responsabilité clairement organisée.

#Cybersecurite #CyberResilienceAct #CRA #DSI #CIO #TransformationNumerique #ObjetsConnectes #IoT #Logiciel #Cloud #GestionDesRisques #SecureByDesign #Conformite #Innovation #GouvernanceIT #SecuriteNumerique