Règlement européen cybersécurité : obligations pour votre logiciel

Règlement européen cybersécurité : savoir si votre logiciel ou votre application est concerné, qui doit signaler une faille et quoi prévoir au contrat.

Vous commercialisez un logiciel, publiez une application mobile ou faites développer un produit numérique par un prestataire ? Votre entreprise peut être « fabricant » au sens du règlement européen cybersécurité des produits numériques, le règlement (UE) 2024/2847 dit « règlement sur la cyberrésilience » (Cyber Resilience Act en anglais). Depuis le 11 septembre 2026, les fabricants doivent signaler en quelques heures les failles exploitées de leurs produits et les incidents graves ; l’essentiel du reste, dont les exigences de sécurité, s’appliquera à partir du 11 décembre 2027.

Règlement européen cybersécurité : ce qui s’applique depuis le 11 septembre 2026

Deux événements sont à déclarer (article 14) : une faille « activement exploitée », dont on a des preuves fiables qu’une personne malveillante l’a utilisée sans autorisation, et un incident grave touchant la sécurité du produit. La page de la Commission européenne sur les déclarations décrit trois étapes :

une alerte précoce, au plus tard 24 heures après en avoir eu connaissance ;
une notification sous 72 heures, qui décrit l’exploitation ou l’incident, les mesures prises et celles que les utilisateurs peuvent appliquer ;
un rapport final, au plus tard 14 jours après la mise à disposition d’un correctif pour une faille, ou un mois après la notification pour un incident grave.

Ces déclarations se font sur la plateforme unique de signalement de l’ENISA, l’agence européenne de cybersécurité. Elles arrivent en même temps à l’ENISA et au centre coordinateur de réponse aux incidents du pays de l’établissement principal du fabricant (le CERT-FR de l’ANSSI en France). Le fabricant doit aussi informer les utilisateurs touchés et, si nécessaire, leur indiquer les mesures à prendre.

L’obligation vaut aussi pour les produits déjà sur le marché, mais, selon la foire aux questions de l’ENISA, une exploitation connue du fabricant avant le 11 septembre 2026 n’a pas à être déclarée rétroactivement.

Votre logiciel ou votre application est-il concerné ?

Le règlement vise tout logiciel ou matériel, avec ses traitements de données à distance, prévu pour se connecter à un appareil ou à un réseau et fourni dans un cadre commercial, payant ou gratuit. Les orientations de la Commission du 27 juillet 2026, non contraignantes, donnent des repères :

une application mobile téléchargée depuis un magasin d’applications, ou un logiciel installé sur l’ordinateur de l’utilisateur, est un produit ;
le serveur sans lequel l’application ne peut pas remplir l’une de ses fonctions fait partie du produit, s’il a été conçu par le fabricant ou pour lui ;
une application web utilisée uniquement dans un navigateur, ou un site qui présente de l’information, n’est pas un produit, sauf s’il sert au fonctionnement d’un produit couvert ; d’autres textes, comme le RGPD, peuvent s’y appliquer.

Un produit fabriqué pour son propre usage n’est pas « mis sur le marché », précise la foire aux questions de la Commission, et certains, comme les dispositifs médicaux et les véhicules à moteur, sont exclus.

Qui est le fabricant quand vous faites développer ?

Le fabricant est celui qui développe un produit, ou le fait concevoir et développer, et le commercialise sous son nom ou sa marque. Faire appel à un prestataire ne transfère donc pas la responsabilité : pour une application développée par un studio et publiée sous votre marque, c’est en principe votre entreprise qui porte les obligations du fabricant, signalement compris.

À l’inverse, un prestataire qui vend sa propre solution sous son nom, ou accorde une licence sur son code source, en est le fabricant. Celui qui modifie de façon substantielle un produit existant puis le met à disposition devient fabricant de la partie modifiée, voire de tout le produit si la modification touche la cybersécurité de l’ensemble (article 22).

Un outil sur mesure à usage interne s’analyse au cas par cas. Pour un produit sur mesure destiné à un client professionnel précis, deux dérogations sont possibles si les deux parties le prévoient explicitement au contrat : sur la configuration sécurisée par défaut et sur la gratuité des mises à jour de sécurité.

Ce qui sera exigé à partir du 11 décembre 2027

Les produits mis sur le marché à partir du 11 décembre 2027 devront respecter les exigences essentielles de sécurité (annexe I). Le fabricant devra notamment :

établir la liste des composants logiciels, dans un format courant lisible par un programme, couvrant au moins ceux que le produit utilise directement, sans obligation de la publier ;
corriger les failles sans retard, si possible par des mises à jour de sécurité distinctes des évolutions fonctionnelles, gratuites sauf accord contraire pour un produit sur mesure ;
tester régulièrement la sécurité du produit, appliquer une politique de divulgation coordonnée des failles (traiter celles que des tiers signalent) et fournir une adresse pour les signaler ;
vérifier avec soin les composants fournis par d’autres, logiciels libres compris.

Il fixera une période d’assistance (pendant laquelle il traite les failles) d’au moins cinq ans, ou égale à la durée d’utilisation prévue si elle est plus courte, et en indiquera la date de fin à l’achat. Chaque mise à jour de sécurité restera disponible au moins dix ans, ou jusqu’à la fin de la période d’assistance si elle est plus longue. Les produits mis sur le marché avant le 11 décembre 2027 n’y sont soumis qu’en cas de modification substantielle après cette date.

Ce qu’il faut prévoir au contrat avec votre prestataire

Le délai de 24 heures court dès que le fabricant a connaissance de l’exploitation : si votre prestataire héberge et surveille l’application, le contrat doit prévoir comment il vous prévient. À formaliser :

qui est le fabricant et qui établira la documentation technique et la déclaration de conformité exigées dès décembre 2027 ;
un délai court pour vous alerter en cas de soupçon d’exploitation ou d’incident, et les personnes inscrites sur la plateforme de l’ENISA ;
la liste des composants à chaque version, la veille sur les composants externes et des délais de correction selon la gravité ;
la période d’assistance, les mises à jour de sécurité et les éventuelles dérogations (produit sur mesure) ;
l’accès au code source, aux outils de fabrication du logiciel et à la documentation : le fabricant reste responsable pendant toute la période d’assistance, même s’il change de prestataire.

À transmettre à votre prestataire : cette liste est la nomenclature des logiciels (SBOM), dépendances de premier niveau au minimum.

Un exemple concret

Prenons, à titre d’illustration, une PME de 30 personnes, distributeur de matériel professionnel. Elle a fait développer sous sa marque une application mobile de commande et de suivi des livraisons, avec un serveur conçu pour elle et hébergé par le prestataire. La PME est en principe le fabricant, et ce serveur fait partie du produit.

Un vendredi soir, la surveillance du prestataire détecte des accès anormaux au serveur, qui exploitent la faille d’un composant externe. Si le contrat prévoit une alerte sous quelques heures et qu’un représentant de la PME est déjà inscrit sur la plateforme, l’alerte précoce peut partir dans les 24 heures ; sinon, le délai devient difficile à tenir.

Questions fréquentes

Une petite entreprise est-elle dispensée de signaler les failles ?

Non. Les microentreprises et petites entreprises échappent seulement à l’amende pour non-respect du délai de 24 heures de l’alerte précoce. Pour les autres manquements aux articles 13 et 14 (obligations du fabricant, signalement) ou à l’annexe I, l’amende est plafonnée à 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu ; chaque État membre fixe ses sanctions.

Faut-il déclarer une faille découverte lors d’un audit ?

Non, tant qu’aucune exploitation malveillante n’est avérée : selon la foire aux questions de la Commission, une faille trouvée lors de tests menés pour le fabricant n’a pas à être déclarée. Corrigez-la vite ; vous pouvez aussi la signaler volontairement (article 15).

Par où commencer dès maintenant ?

Recensez les produits publiés sous votre marque et leur fabricant. Inscrivez sur la plateforme de l’ENISA un représentant principal et au moins un secondaire, chacun avec un compte EU Login de la Commission européenne, protégé par une authentification à plusieurs facteurs (en plus du mot de passe). Revoyez enfin vos contrats.

411bit peut vous y aider : audit de sécurité de vos applications et de leurs composants (Secure), développement sur mesure sans dépendance propriétaire, avec remise possible du code, de la documentation et de la liste des composants logiciels (Build), supervision avec alertes et maintenance continue selon un niveau de service contractuel (Run). Pour faire le point, contactez-nous : chaque demande reçoit une réponse sous 24 heures ouvrées. Si un autre prestataire a développé votre application, le projet d’audit puis de reprise d’une plateforme B2B industrielle illustre la démarche.