Cyber Resilience Act : les obligations de signalement au 11 septembre 2026, expliquées

Le règlement européen sur la cyberrésilience ouvre demain son premier chapitre contraignant : le signalement des failles exploitées. Ce que le texte impose, à qui il l'impose, et pourquoi la question change de nature quand votre logiciel est un outil interne.

Les obligations de signalement du Cyber Resilience Act s'appliquent à partir du 11 septembre 2026, indique la page officielle de la Commission européenne consacrée au règlement. La même page rappelle que le texte est entré en vigueur le 10 décembre 2024 et que ses obligations principales s'appliqueront, elles, au 11 décembre 2027.

Ce que le règlement couvre

La Commission décrit un champ large : des moniteurs de bébé aux montres connectées, des applications aux programmes informatiques, matériels et logiciels connectables. Le règlement impose des exigences de cybersécurité aux fabricants, sur la planification, la conception, le développement et la maintenance de ces produits, et prévoit un marquage CE pour attester la conformité. Un traitement particulier est réservé au logiciel libre et ouvert, en raison de sa place dans la chaîne, sans que la page détaille les exemptions. Savoir si votre produit entre dans ce champ se tranche avec votre conseil juridique, et la réponse dépend souvent d'un détail contractuel plutôt que de la nature du logiciel.

Qui porte l'obligation

Le texte vise celui qui met un produit sur le marché, pas celui qui l'utilise. L'obligation vise l'éditeur du logiciel, pas le cabinet qui l'achète et s'en sert. La distinction devient intéressante au moment où un dirigeant fait construire un outil et se demande de quel côté il se trouve. Un outil interne, jamais vendu ni distribué, ne relève pas de la même logique qu'un produit proposé à des clients. Entre les deux existe une zone grise que seul un avis juridique tranche : une application mise à disposition de vos franchisés, un module revendu avec une prestation, un accès ouvert à vos clients dans le cadre d'un abonnement. Beaucoup de dirigeants découvrent qu'ils éditent un logiciel le jour où ils le facturent.

Ce que la Commission ne dit pas sur sa page

La presse spécialisée cite des délais de signalement de 24 heures, 72 heures et 14 jours. La page de la Commission ne les mentionne pas, et nous n'avons pas pu lire le texte du règlement en source directe. Nous les laissons donc de côté plutôt que de les répéter, quitte à donner moins de détails que d'autres articles publiés cette semaine. Ce qui est établi tient en une phrase : à partir du 11 septembre 2026, un fabricant concerné doit signaler les vulnérabilités exploitées de son produit, y compris pour un produit livré avant cette date. Le reste, y compris le compte à rebours exact, se vérifie dans le règlement avec votre conseil.

Le vrai sujet pour un dirigeant

L'obligation de signalement suppose deux capacités que peu de petites structures possèdent : savoir qu'une faille est exploitée, et savoir qui la corrige. Une application construite en quelques soirées avec un générateur, mise en ligne, puis oubliée, ne remplit ni l'une ni l'autre. Personne ne surveille, personne ne tient la liste des composants embarqués, et la question de la propriété du code se pose au pire moment. Nous l'avons détaillée dans ce qui reste entre vos mains quand un outil ferme : sans le code et sans le document qui le décrit, un correctif urgent devient un chantier de plusieurs semaines, et la personne capable de le mener n'est pas toujours joignable en août.

Il existe une version plus élémentaire du problème, et elle se vérifie en deux minutes : une base de données laissée ouverte n'attend pas 2027 pour vous coûter cher. Les règles d'accès sont d'ailleurs le mur sur lequel butent la plupart des outils de génération rapide, comme le comparatif de ce matin le montre sur deux plateformes très différentes. Un produit qui n'a jamais eu de cahier des charges n'a jamais eu, non plus, de liste écrite de qui accède à quoi.

En pratique, cette semaine

Trois lignes suffisent à savoir où vous en êtes. Un : écrivez si votre logiciel sort de votre entreprise, vendu, distribué ou mis à disposition, ou s'il reste un outil interne. Deux : nommez la personne qui vous prévient quand une faille est signalée sur un composant que votre produit embarque, avec son prénom, pas son service. Trois : dites où vit le code et par quel chemin vous y feriez appliquer un correctif sans attendre l'accord d'une plateforme. Portez les réponses à votre conseil avec la question du champ d'application. Chez Maestro, le code et les documents restent sur votre Mac, ce qui répond à la troisième ligne et à elle seule : la conformité d'un produit reste le travail de celui qui le met sur le marché, et aucun outil ne l'endosse à votre place.