Le 11 septembre 2026, une première série d’obligations du Cyber Resilience Act devient applicable aux fabricants de produits comportant des éléments numériques. Le reste du règlement européen ne s’appliquera pleinement qu’au 11 décembre 2027, mais le calendrier des signalements commence dès cette première échéance. Une entreprise qui découvre une vulnérabilité activement exploitée ou un incident grave touchant la sécurité de son produit devra alors agir en heures, non en semaines.
Le dispositif concerne notamment les éditeurs de logiciels, les fabricants d’objets connectés et les entreprises qui commercialisent sous leur nom un produit numérique. Il s’applique aussi aux produits déjà placés sur le marché avant décembre 2027 lorsqu’ils entrent dans le champ du règlement. L’alerte précoce doit être transmise dans les vingt-quatre heures suivant la prise de connaissance. Une notification plus complète suit dans les soixante-douze heures, puis un rapport final.
Cette obligation ne se résume pas à un formulaire destiné à l’ENISA. Elle oblige le fabricant à définir qui qualifie l’événement, à quel moment l’entreprise est réputée en avoir connaissance, quelles preuves sont conservées et comment les utilisateurs sont informés. Les contrats conclus avec les développeurs, mainteneurs, hébergeurs, intégrateurs et distributeurs doivent permettre de faire remonter l’information assez tôt. À défaut, le fabricant peut manquer le délai alors même que la faille était connue d’un sous-traitant.
I. Cyber Resilience Act : qui doit signaler une vulnérabilité ou un incident dès le 11 septembre 2026 ?
A. Quels logiciels, objets connectés et fabricants entrent dans l’obligation de signalement ?
Le texte de référence est le règlement (UE) 2024/2847 du 23 octobre 2024. Il vise les produits comportant des éléments numériques mis à disposition sur le marché de l’Union dans le cadre d’une activité commerciale. Cette catégorie réunit les produits matériels ou logiciels et leurs solutions de traitement de données à distance lorsque celles-ci sont nécessaires à l’une de leurs fonctions.
Un logiciel vendu sous licence relève naturellement de cette définition. Une application mobile, un micrologiciel, une solution de sécurité, un routeur, une caméra connectée, un jouet intelligent ou un équipement industriel piloté par logiciel peuvent également y entrer. Un service en nuage indépendant ne relève pas du CRA par sa seule qualité de service cloud. Il peut toutefois être intégré au produit lorsqu’il a été conçu sous la responsabilité du fabricant et que le produit ne peut exécuter l’une de ses fonctions sans ce traitement distant.
Le mot « fabricant » ne désigne pas seulement l’entreprise qui assemble un objet dans une usine. Le règlement regarde l’opérateur qui développe ou fait développer un produit et le commercialise sous son nom ou sa marque. Une société française qui confie tout le développement à une équipe extérieure, puis vend l’application sous sa propre marque, ne perd donc pas nécessairement cette qualité. Elle doit cartographier la chaîne technique au lieu de supposer que le prestataire supportera seul la notification.
Cette lecture contractuelle rejoint le droit français des contrats. L’article 1103 du code civil dispose mot pour mot que « Les contrats légalement formés tiennent lieu de loi à ceux qui les ont faits. » Le contrat de développement ou de maintenance peut répartir les tâches, organiser les alertes et fixer des délais plus courts entre partenaires. Il ne peut cependant pas effacer une obligation réglementaire qui pèse directement sur le fabricant.
L’entreprise doit commencer par établir une matrice produit par produit. Elle identifie le nom commercial, les versions encore utilisées, la date de mise sur le marché, la période d’assistance, les composants tiers, le mainteneur, les canaux de remontée et les pays où le produit est disponible. Cette matrice doit inclure les versions anciennes encore actives. Le paragraphe 3 de l’article 69 du règlement soumet en effet à l’article 14 les produits relevant du CRA qui ont été placés sur le marché avant le 11 décembre 2027.
Les logiciels libres et ouverts demandent une analyse séparée. Un code simplement publié hors activité commerciale ne se traite pas comme un logiciel commercialisé. La conclusion change lorsque le produit est monétisé, fourni avec des services qui dépassent le remboursement des coûts ou intégré dans une offre commerciale sous la responsabilité d’un fabricant. Le seul mot « open source » dans un inventaire ne suffit donc pas à conclure à l’exclusion.
Certains secteurs disposent de régimes propres. Les dispositifs médicaux et les dispositifs de diagnostic in vitro couverts par leurs règlements européens sont notamment exclus du champ horizontal du CRA. Les véhicules, certains produits aéronautiques et d’autres catégories réglementées doivent aussi être contrôlés au regard des exclusions exactes. L’entreprise doit documenter la raison de l’inclusion ou de l’exclusion, avec le produit, la version et le texte appliqué. Une liste générale rédigée sans rattachement aux références commercialisées protège peu en cas de contrôle.
La question la plus immédiate porte sur les événements à déclarer. Une vulnérabilité activement exploitée est une faille pour laquelle des preuves fiables montrent qu’un acteur malveillant l’a exploitée sans autorisation dans un système. Une vulnérabilité découverte de bonne foi pendant un test ou une recherche n’entre pas automatiquement dans cette catégorie. En revanche, un incident est grave lorsqu’il atteint, ou risque d’atteindre, la capacité du produit à protéger la disponibilité, l’authenticité, l’intégrité ou la confidentialité de fonctions ou de données sensibles ou importantes.
La distinction doit être décidée à partir de faits conservés. Un indicateur de compromission, un journal d’authentification, un code malveillant injecté, une adresse d’origine, un ticket client ou l’analyse d’un centre de réponse peuvent établir l’exploitation. Pour l’incident grave, le règlement retient aussi le cas où l’événement a conduit, ou peut conduire, à l’introduction ou à l’exécution d’un code malveillant dans le produit ou dans les processus de développement, de production ou de maintenance du fabricant. Une rumeur, une alerte non reproduite ou un défaut théorique ne prouve pas la même chose. L’entreprise peut néanmoins préparer une notification volontaire ou poursuivre l’analyse sans attendre qu’une certitude absolue rende impossible le respect du délai.
Le droit français rappelle l’importance de cette preuve technique. Dans un litige portant sur un produit, la première chambre civile a jugé que « la simple imputabilité du dommage au produit incriminé ne suffit pas à établir son défaut ni le lien de causalité entre ce défaut et le dommage » (Cass. 1re civ., 27 juin 2018, n° 17-17.469). L’arrêt ne tranche pas l’obligation de signalement du CRA, mais il montre pourquoi la chronologie, le défaut, l’exploitation et leurs conséquences doivent être distingués dans le dossier d’incident.
Cette exigence correspond à l’article 1353 du code civil : « Celui qui réclame l’exécution d’une obligation doit la prouver. Réciproquement, celui qui se prétend libéré doit justifier le paiement ou le fait qui a produit l’extinction de son obligation. » Les rapports d’incident, versions de journaux, captures horodatées et décisions de qualification doivent donc être conservés dans un format qui permette d’établir leur origine et leur intégrité.
Le fabricant reste l’acteur central de la notification, mais les autres opérateurs ne peuvent pas rester silencieux. Un importateur ou un distributeur qui pense qu’un produit présente un risque de cybersécurité doit transmettre l’information au fabricant et aux autorités selon les situations prévues par le règlement. Dans la pratique, le contrat de distribution doit imposer une remontée immédiate des plaintes, incidents, vulnérabilités et demandes d’autorité. Un délai contractuel de plusieurs jours rendrait le respect des vingt-quatre heures aléatoire.
Le fabricant doit enfin désigner le moment de la « prise de connaissance ». Le délai ne devrait pas dépendre de la seule lecture personnelle du dirigeant. Il peut commencer lorsque l’information pertinente parvient à l’organisation par un canal dont elle a organisé l’usage : équipe de sécurité, support, développeur, prestataire de réponse à incident ou personne chargée du traitement des vulnérabilités. Une procédure interne doit définir le niveau de preuve nécessaire pour déclencher l’escalade et la personne qui tranche en cas de doute.
B. Comment respecter les délais de vingt-quatre heures, soixante-douze heures et du rapport final ?
L’article 14 du règlement impose trois temps pour une vulnérabilité activement exploitée. Le fabricant adresse d’abord « une alerte précoce de vulnérabilité activement exploitée, sans retard injustifié et, en tout état de cause, au plus tard 24 heures après en avoir eu connaissance ». Il transmet ensuite, au plus tard dans les soixante-douze heures, les informations générales disponibles sur le produit, la nature de l’exploitation, la vulnérabilité, les mesures déjà prises et celles que les utilisateurs peuvent appliquer.
Le rapport final intervient « au plus tard 14 jours après la mise à disposition d’une mesure de correction ou d’atténuation ». Il décrit la vulnérabilité, sa gravité, ses répercussions, l’acteur malveillant lorsqu’il est connu et le correctif déployé. Le délai de quatorze jours ne part donc pas nécessairement de la première alerte. Il est rattaché à la disponibilité d’une mesure corrective ou d’atténuation.
Le calendrier diffère pour l’incident grave. L’alerte précoce doit encore partir sous vingt-quatre heures et la notification d’incident sous soixante-douze heures. Le rapport final est dû dans le mois suivant cette notification. Il doit exposer l’incident, sa gravité, ses répercussions, la menace ou la cause profonde probable, ainsi que les mesures d’atténuation appliquées et en cours.
Ces notifications passent par la plateforme unique de signalement du CRA. La Commission européenne indique que la plateforme doit être opérationnelle le 11 septembre 2026. La notification est dirigée simultanément vers le CSIRT coordinateur de l’État membre où le fabricant a son établissement principal et vers l’ENISA. Une entreprise établie en France doit donc préparer son accès, ses habilitations et un canal de remplacement avant le premier incident.
La première alerte ne doit pas être retardée pour produire un rapport définitif. Le règlement organise au contraire une information progressive. L’entreprise transmet ce qu’elle sait, indique les zones d’incertitude et complète ensuite. Le procès-verbal interne de qualification doit conserver l’heure de la première information, l’heure de l’escalade, les éléments examinés, la décision prise et l’heure d’envoi. Ce document permet de démontrer la diligence sans transformer une hypothèse en fait établi.
L’information des utilisateurs forme une obligation distincte. Après avoir pris connaissance d’une vulnérabilité activement exploitée ou d’un incident grave, le fabricant informe les utilisateurs touchés et, si nécessaire, tous les utilisateurs. Il communique aussi les mesures correctives ou d’atténuation qu’ils peuvent mettre en œuvre. Un message trop vague, dépourvu de version affectée, de correctif ou de mesure de contournement, risque d’être inutilisable au moment où le client doit agir.
La procédure doit donc préparer plusieurs modèles. Le premier sert à l’alerte réglementaire. Le deuxième organise la communication technique vers les utilisateurs. Le troisième informe les distributeurs, intégrateurs et mainteneurs. Le quatrième conserve les décisions de sécurité qui justifient un éventuel décalage entre ces communications. Chaque modèle doit prévoir le produit, les versions, l’indicateur de compromission, la gravité, les actions immédiates et le contact de suivi.
Le fabricant ne peut pas attendre le 11 septembre pour négocier les remontées avec ses prestataires. Le droit français impose déjà au professionnel de traiter certaines informations décisives avant la conclusion du contrat. L’article 1112-1 du code civil précise que « Celle des parties qui connaît une information dont l’importance est déterminante pour le consentement de l’autre doit l’en informer dès lors que, légitimement, cette dernière ignore cette information ou fait confiance à son cocontractant. » Il ajoute que les parties ne peuvent ni limiter ni exclure ce devoir.
Dans une affaire de cyberattaque liée à un environnement Microsoft Azure, la cour d’appel de Bordeaux a rappelé mot pour mot que « Il incombe à celui qui prétend qu’une information lui était due de prouver que l’autre partie la lui devait, à charge pour cette autre partie de prouver qu’elle l’a fournie » (CA Bordeaux, 5 mai 2026, n° 24/02155). La cour a rouvert les débats sur un éventuel manquement au devoir de conseil. Cette décision invite surtout à conserver la preuve des alertes de sécurité effectivement délivrées.
Un contrat de développement doit prévoir que le prestataire notifie au fabricant toute vulnérabilité connue, tout signe d’exploitation et tout incident susceptible d’entrer dans l’article 14. Le délai contractuel doit être inférieur au délai réglementaire, par exemple quelques heures, afin de laisser au fabricant le temps de qualifier et transmettre. La clause identifie un canal joignable en permanence, les informations minimales, l’obligation de préserver les journaux, la coopération avec les experts et la continuité pendant les week-ends.
Le même travail concerne les contrats de maintenance et d’hébergement. Dans l’affaire Claranet, la cour d’appel de Versailles a retenu que le prestataire « n’a pas été en mesure de résoudre l’incident qui s’est produit le 28 juin 2017, ce qui caractérise un manquement à son obligation contractuelle de “garantie de temps de rétablissement de 4 heures en 24/7” » (CA Versailles, 19 mai 2022, n° 20/05106). Une promesse de délai devient donc un élément probatoire précis lorsqu’un incident survient.
Le fabricant doit cependant définir lui-même sa politique de sauvegarde, de journalisation et de reprise. Une cour peut refuser de transférer au prestataire une obligation que le contrat n’a pas mise à sa charge. Dans un contentieux concernant l’incendie d’un centre de données, la cour d’appel de Douai a retenu qu’il n’était pas démontré qu’une règle imposait au prestataire d’une option de sauvegarde de conserver toutes les copies dans des lieux distincts, tout en constatant un manquement à l’engagement précis relatif à l’espace de sauvegarde souscrit (CA Douai, 24 avril 2025, n° 23/00858). Le contenu exact de l’offre a déterminé le résultat.
La procédure interne doit enfin éviter les qualifications automatiques. Une alerte de vulnérabilité n’est pas toujours une exploitation active. Une interruption de service n’est pas toujours un incident grave touchant la sécurité du produit. À l’inverse, l’absence de plainte client ne prouve pas l’absence d’exploitation. L’équipe doit croiser la télémétrie, les signalements externes, les tickets support, les informations du CERT et les données du mainteneur. Elle conserve aussi la raison pour laquelle un événement a été déclaré ou écarté.
II. Comment préparer la preuve, les contrats et la responsabilité de l’entreprise avant l’échéance ?
A. Quelles clauses et quelles preuves faut-il réunir avant la première alerte ?
Le CRA crée une obligation administrative, mais son exécution traverse une série de contrats privés. Un éditeur peut dépendre d’un développeur, d’une bibliothèque tierce, d’un hébergeur, d’un prestataire de détection, d’un intégrateur et d’un réseau de distribution. Si chacun promet seulement d’informer son propre cocontractant « dans les meilleurs délais », personne ne sait si le fabricant recevra les faits utiles avant l’expiration des vingt-quatre heures.
La première clause à revoir porte sur la définition des événements. Elle reprend les catégories du règlement : vulnérabilité activement exploitée, incident grave ayant des répercussions sur la sécurité du produit, correctif, mesure d’atténuation et prise de connaissance. Elle distingue les informations confirmées des suspicions. Le prestataire doit transmettre les deux, avec leur niveau de confiance, sans attendre de pouvoir rédiger une analyse complète.
La deuxième clause fixe le délai et le canal. Une remontée sous quatre ou six heures peut laisser au fabricant le temps de réunir le comité de qualification. Le canal doit fonctionner en dehors des horaires ordinaires et prévoir un accusé de réception. Une adresse générique non surveillée ou un ticket classé dans une file commerciale ne répond pas à une crise mesurée en heures.
La troisième clause concerne la preuve. Les parties déterminent qui conserve les journaux, pendant combien de temps, dans quel fuseau horaire et avec quels mécanismes d’intégrité. Elles prévoient la copie des configurations affectées, l’image des systèmes lorsque cela est proportionné, les indicateurs de compromission, le suivi des versions et les échanges avec le chercheur ou le client qui a signalé la faille. Les données à caractère personnel et les secrets d’affaires doivent rester protégés pendant cette collecte.
La quatrième clause organise la coopération. Le fabricant doit pouvoir demander une analyse technique, un rapport intermédiaire et la préparation du correctif. Le prestataire doit désigner un responsable et informer sans délai de tout obstacle. La propriété intellectuelle ne doit pas empêcher la remise des informations nécessaires à la notification. Les engagements de confidentialité doivent permettre les transmissions imposées par la loi aux autorités et aux utilisateurs.
La cinquième clause traite des communications externes. Le fabricant reste maître de sa notification, mais le prestataire peut devoir fournir les éléments techniques. Les distributeurs doivent relayer rapidement les messages aux utilisateurs qu’ils connaissent. Les parties déterminent qui répond à la presse, qui communique avec les clients professionnels et qui publie les mises à jour. Cette organisation réduit les contradictions sans permettre à une partie de bloquer une information légalement requise.
La sixième clause répartit les coûts et les responsabilités. Elle prévoit les investigations, correctifs, notifications, communications, rappels et mesures d’urgence. Toute limitation de responsabilité doit être relue au regard de l’obligation essentielle. L’article 1170 du code civil énonce que « Toute clause qui prive de sa substance l’obligation essentielle du débiteur est réputée non écrite. » Une clause limitative n’est pas automatiquement privée d’effet, mais elle ne peut réduire à néant l’engagement central qui a été souscrit.
La décision Claranet montre cette nuance. La cour d’appel de Versailles a admis un plafond correspondant à trois mois de facturation parce qu’elle a considéré que ce plafond n’effaçait pas l’obligation de disponibilité convenue. Le contrat prévoyait aussi qu’un incident pouvait survenir. La clause a donc produit effet malgré le manquement (CA Versailles, 19 mai 2022, n° 20/05106). La portée d’un plafond dépend ainsi du service promis, du risque transféré et du montant restant réellement indemnisable.
Un autre litige relatif à un logiciel de paie confirme que la correction d’une erreur ne fait pas disparaître le manquement initial. La cour d’appel de Paris a retenu que la stipulation obligeant le prestataire à corriger les erreurs « n’exonère pas la société ADP de sa responsabilité » en raison de la nature essentielle de l’information utilisée pour calculer les primes. Elle a néanmoins appliqué la limitation de responsabilité et partagé la responsabilité avec le client qui avait tardé à contrôler les résultats (CA Paris, 13 janvier 2023, n° 19/21630).
Le devoir de collaboration du client ou du fabricant doit donc être écrit et exécuté. L’équipe produit fournit l’architecture, les usages, la criticité, les versions et les contacts. Le prestataire interroge ces besoins, documente les risques et remet ses recommandations. La cour d’appel de Reims a rappelé que « L’obligation de conseil inhérente à tout contrat de fourniture informatique impose au vendeur de se renseigner sur les besoins de l’acheteur et d’informer ce dernier de l’aptitude du produit proposé à l’utilisation qui en est prévue » (CA Reims, 28 avril 2026, n° 24/01502).
Dans cette affaire, une cyberattaque par rançongiciel avait bloqué les données du client. La cour a retenu que le prestataire n’avait pas mis tout en œuvre pour sécuriser le système et que le défaut de conseil, associé au non-respect des prescriptions de sécurité, avait concouru au dommage. La responsabilité a toutefois été partagée. Le client avait choisi une offre moins coûteuse et sa propre intervention dans l’installation devait être examinée. Un dossier de conformité CRA doit donc conserver les recommandations, les arbitrages budgétaires et les refus de mesure, sans transformer cette traçabilité en décharge générale.
La répartition technique des pouvoirs peut aussi écarter la responsabilité d’un prestataire. Après deux piratages d’un réseau téléphonique, la cour d’appel de Paris a relevé qu’ils « ont été permis par l’ouverture d’un port du pare-feu de la société Datalog, sur lequel la société Drax n’avait pas la main » (CA Paris, 15 novembre 2024, n° 21/00036). Le contrat et le schéma d’architecture doivent donc identifier qui contrôle chaque pare-feu, compte, clé, journal et mécanisme de mise à jour. Une responsabilité générale de « sécurité » ne remplace pas cette attribution opérationnelle.
Le contrat ne remplace pas non plus la délivrance conforme. L’article 1604 du code civil dispose que « La délivrance est le transport de la chose vendue en la puissance et possession de l’acheteur. » Pour une solution numérique complexe, la conformité s’apprécie aussi au regard des caractéristiques convenues et de l’usage connu du vendeur.
La cour d’appel de Rennes a ainsi jugé qu’un fournisseur de logiciel métier ne pouvait se dire tenu d’une simple obligation de moyens pour la compatibilité entre le matériel livré et le logiciel installé. Elle a relevé des paramétrages incomplets et de nombreuses demandes d’assistance avant la rupture (CA Rennes, 10 juillet 2026, n° 21/01039). Pour le CRA, le cahier des charges doit donc identifier les fonctions de sécurité, les mises à jour, la journalisation et la gestion des vulnérabilités attendues.
Lorsque le produit est déjà sur le marché, l’entreprise doit constituer un dossier opérationnel avant le 11 septembre. Il comprend la liste des produits, leurs versions, les responsables, les contacts des prestataires, les comptes d’accès à la plateforme, les modèles de notification, les délégations, les journaux disponibles, la liste des utilisateurs joignables et les mesures d’atténuation possibles. Un exercice sur table permet de mesurer le temps réel nécessaire entre l’alerte et l’envoi.
B. Que risque le fabricant et comment agir après une vulnérabilité activement exploitée ?
Le non-respect des articles 13 et 14 peut faire l’objet d’une amende administrative allant jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial total de l’exercice précédent, le montant le plus élevé étant retenu. Ce plafond figure à l’article 64 du règlement. Il ne signifie pas que toute notification tardive entraînera automatiquement l’amende maximale. L’autorité doit tenir compte des circonstances, de la gravité, de la durée, de la coopération et de la taille de l’entreprise.
Le règlement prévoit une protection particulière pour les microentreprises et petites entreprises au sujet du délai de vingt-quatre heures. Elles ne doivent pas recevoir d’amende administrative pour le seul non-respect de ce délai d’alerte précoce. Cette règle ne les dispense pas de notifier, de coopérer, de corriger ni de respecter les autres obligations applicables. Elle ne transforme pas non plus un défaut de sécurité ou une absence d’information des utilisateurs en événement sans conséquence.
Les conséquences civiles peuvent s’ajouter au contrôle administratif. L’article 1231-1 du code civil dispose que « Le débiteur est condamné, s’il y a lieu, au paiement de dommages et intérêts soit à raison de l’inexécution de l’obligation, soit à raison du retard dans l’exécution, s’il ne justifie pas que l’exécution a été empêchée par la force majeure. » Un client devra encore établir le manquement, le dommage réparable et le lien de causalité. Le seul constat d’une faille ne fixe pas automatiquement l’indemnité.
L’article 1217 du code civil ouvre plusieurs sanctions lorsque l’engagement n’a pas été exécuté ou l’a été imparfaitement : suspension, exécution forcée, réduction du prix, résolution et réparation. Les sanctions compatibles peuvent être cumulées. Un contrat de logiciel ou de produit connecté doit donc prévoir la continuité du service, le correctif et la coopération, pas seulement un plafond financier après le dommage.
Le régime des produits défectueux peut également être discuté lorsqu’un défaut de sécurité cause un dommage entrant dans son champ. L’article 1245-3 du code civil définit le produit défectueux comme celui qui « n’offre pas la sécurité à laquelle on peut légitimement s’attendre ». Il faut tenir compte de la présentation, de l’usage raisonnablement attendu et du moment de la mise en circulation. La seule existence d’un produit ultérieur plus perfectionné ne suffit pas.
La réaction doit commencer par la maîtrise du temps. L’entreprise enregistre l’heure de prise de connaissance, ouvre une cellule restreinte et préserve les données. Elle identifie le produit, les versions, les pays, la nature de l’exploitation et les utilisateurs exposés. Elle prépare l’alerte de vingt-quatre heures avec les informations disponibles, sans attendre le correctif. Elle poursuit l’enquête pour la notification de soixante-douze heures et organise simultanément l’information des utilisateurs.
Le correctif ne doit pas devenir une nouvelle source de risque. Il est testé, signé, distribué par un canal maîtrisé et accompagné d’instructions. Lorsque le correctif n’est pas prêt, une mesure d’atténuation peut réduire l’exposition : désactivation d’une fonction, limitation d’un accès, rotation de clés, segmentation, filtrage ou recommandation d’arrêt temporaire. Le choix dépend du produit et du danger. Il doit être documenté avec les effets attendus et les risques résiduels.
La communication doit rester factuelle. Elle indique les versions touchées, la menace connue, les mesures immédiates et le canal de suivi. Elle ne minimise pas un risque confirmé et ne présente pas une hypothèse comme un fait. Le secret des affaires peut justifier de limiter certains détails diffusés au public, mais il ne permet pas d’omettre les informations que le règlement impose aux autorités ou celles dont les utilisateurs ont besoin pour se protéger.
Le fabricant doit également examiner les autres régimes applicables. Une atteinte aux données personnelles peut imposer une notification au titre du RGPD. Une entité soumise à NIS 2 ou au règlement DORA peut avoir d’autres obligations de déclaration. Ces dispositifs n’ont pas les mêmes événements, destinataires ni délais. Une seule cellule peut coordonner les faits, mais elle doit tenir un tableau séparé par texte afin d’éviter de considérer qu’une notification en remplace automatiquement une autre.
L’article consacré aux preuves attendues après une cyberattaque et au contrôle de la CNIL détaille la conservation des journaux, habilitations et mesures de sécurité. Les entreprises du secteur financier peuvent aussi consulter l’analyse des clauses contractuelles imposées aux prestataires TIC par DORA. Le CRA poursuit un objectif différent : sécuriser les produits comportant des éléments numériques et imposer au fabricant une chaîne de remontée des vulnérabilités.
À Paris et en Île-de-France, les éditeurs, fabricants et intégrateurs concentrent souvent leurs équipes techniques, juridiques et leurs sous-traitants sur plusieurs sites. La procédure doit préciser qui peut notifier lorsque le responsable habituel est absent et comment joindre les prestataires hors horaires ouvrés. Elle doit aussi tenir compte des filiales étrangères : le principal établissement au sens du règlement détermine le CSIRT coordinateur, tandis que la mise à disposition du produit dans plusieurs États influence les informations à transmettre.
La preuve d’une bonne organisation se construit avant l’incident. Le conseil d’administration ou la direction valide le périmètre. Les équipes produit tiennent l’inventaire. La sécurité conserve les indicateurs et les journaux. Le juridique qualifie les textes et protège les échanges nécessaires. Le support remonte les signaux faibles. Les contrats imposent des délais internes compatibles avec l’article 14. Un exercice teste l’ensemble et produit un compte rendu de correction.
Conclusion
Le 11 septembre 2026 n’est pas l’entrée en application générale du Cyber Resilience Act. C’est pourtant une échéance immédiate pour les fabricants de produits comportant des éléments numériques, y compris pour certains produits déjà commercialisés. À compter de cette date, une vulnérabilité activement exploitée ou un incident grave peut déclencher une alerte sous vingt-quatre heures, une notification sous soixante-douze heures et un rapport final selon le calendrier propre à l’événement.
La première tâche consiste à déterminer quels produits et quelles versions entrent dans le règlement. La deuxième consiste à identifier le fabricant juridiquement responsable, sans confondre développement externalisé et transfert de l’obligation. La troisième consiste à organiser la remontée depuis les équipes, clients, chercheurs, mainteneurs, hébergeurs et distributeurs. La quatrième consiste à conserver la preuve de la qualification, des heures, des décisions et des mesures prises.
Les contrats doivent soutenir ce dispositif. Ils définissent les événements, imposent une remontée en quelques heures, organisent la conservation des journaux et permettent la coopération avec les autorités. Ils répartissent aussi les coûts des enquêtes, correctifs, notifications et communications. Une clause de responsabilité ne dispense pas le fabricant de notifier et ne protège pas une partie qui ne peut démontrer l’information ou le service qu’elle avait promis.
L’entreprise qui découvre une exploitation active doit donc transmettre une première alerte avec les données disponibles, poursuivre l’enquête et informer les utilisateurs lorsque le règlement l’exige. Elle traite parallèlement le RGPD, NIS 2, DORA ou les obligations contractuelles applicables, sans présumer qu’un seul signalement suffit. Le dossier doit permettre de reconstituer la chronologie et la raison de chaque décision.
Besoin d’un avis rapide sur votre dossier.
Votre entreprise édite un logiciel, commercialise un objet connecté ou dépend d’une chaîne de sous-traitants pour gérer ses vulnérabilités. Une consultation téléphonique peut être organisée sous 48 heures avec un avocat du cabinet afin d’examiner le périmètre du CRA, les contrats, les preuves et la procédure de signalement.
Contactez Maître Reda KOHEN au 06 46 60 58 22, écrivez à [email protected] ou utilisez le formulaire de contact du cabinet.