Le 11 septembre 2026, une échéance très concrète arrive pour les fabricants de logiciels, d’objets connectés, d’équipements industriels et de solutions numériques : l’article 14 du Cyber Resilience Act (CRA) devient applicable. Une vulnérabilité activement exploitée devra faire l’objet d’une alerte précoce sous vingt-quatre heures, puis d’une notification plus complète sous soixante-douze heures. La Commission européenne prévoit un dépôt unique sur la Single Reporting Platform de l’ENISA, avec transmission au CSIRT compétent.

La difficulté apparaît lorsqu’une même entreprise est aussi une entité essentielle ou importante au sens de NIS2, ou lorsqu’une faille entraîne une violation de données personnelles. Le réflexe consistant à envoyer deux fois le même formulaire à la même autorité n’est pas le bon. Le CRA vise le produit mis sur le marché ; NIS2 vise la continuité et la sécurité des réseaux et systèmes utilisés par une entité régulée ; le RGPD protège les personnes dont les données ont été exposées. Les faits, les destinataires et les délais peuvent donc se superposer sans se confondre.

La réponse pratique tient en trois gestes : qualifier le rôle de l’entreprise, séparer le produit atteint du service interrompu et ouvrir une fiche de preuves horodatée. Le cadre français de NIS2 reste en cours de transposition, comme le rappelle l’ANSSI, mais cette incertitude ne justifie pas d’attendre pour organiser l’alerte. Les contrats, les obligations de sécurité et les responsabilités civiles existent déjà.

Pour replacer cette analyse dans l’ensemble des services proposés aux entreprises, consultez la page de référence du cabinet en droit des affaires.

I. Cyber Resilience Act et NIS2 : pourquoi une même faille peut-elle déclencher deux obligations distinctes ?

A. Que couvre le CRA et que couvre NIS2 pour une entreprise numérique ?

Le premier enjeu est de ne pas confondre deux objets juridiques. Le CRA encadre un produit comportant des éléments numériques lorsqu’il est mis à disposition sur le marché de l’Union européenne. NIS2 encadre une entité et les réseaux ou systèmes d’information dont elle dépend pour fournir un service ou exercer une activité entrant dans les secteurs visés par la directive. Une société peut donc relever des deux régimes en raison de deux qualités différentes.

Le règlement (UE) 2024/2847 impose au fabricant de prendre en compte la cybersécurité pendant la conception, la mise sur le marché et la période de soutien du produit. Il ne s’agit pas seulement d’un texte applicable aux fabricants de téléphones ou de routeurs. Un logiciel vendu séparément, un système embarqué, un équipement de production connecté, une caméra, un dispositif médical numérique, un composant destiné à être intégré dans une solution ou une application distribuée sous une forme commerciale peuvent entrer dans son périmètre. Le fabricant est la personne qui conçoit ou fait concevoir le produit et le commercialise sous son nom ou sa marque. L’importateur et le distributeur ont, eux aussi, des vérifications à réaliser avant de mettre le produit à disposition.

La Direction générale des entreprises décrit le CRA comme un cadre portant sur « l’ensemble des produits comportant des éléments numériques » mis sur le marché européen. L’ANSSI précise, dans sa FAQ actualisée, que les exigences essentielles de l’annexe I s’appliquent sans attendre la publication de toutes les normes harmonisées. Le fabricant doit donc pouvoir expliquer son analyse de risques, ses mesures de correction, son dispositif de contact et la manière dont il suit les vulnérabilités signalées par les utilisateurs, les chercheurs ou ses sous-traitants.

Le régime NIS2 raisonne autrement. La directive (UE) 2022/2555 vise un niveau élevé commun de cybersécurité pour les entités essentielles et importantes relevant notamment de l’énergie, des transports, de la banque, des infrastructures des marchés financiers, de la santé, de l’eau potable, des eaux usées, des infrastructures numériques, de la gestion des services TIC, de l’administration publique et de certains secteurs industriels. Le critère n’est pas l’existence d’un logiciel isolé mais le rôle de l’entité, son activité, sa taille et l’importance de ses réseaux et systèmes.

Le seuil de taille n’est pas une dispense automatique. La directive prévoit une application aux entités moyennes et aux entités dépassant les plafonds de la catégorie des entreprises moyennes lorsqu’elles fournissent des services ou exercent des activités dans l’Union. Des entités critiques peuvent être couvertes indépendamment de leur taille. Certaines catégories de fournisseurs numériques obéissent encore à des règles particulières. La qualification doit donc être faite à partir du secteur, du service fourni, de l’établissement concerné et de la législation nationale applicable.

En France, l’ANSSI indique que la transposition nationale de NIS2 se poursuit. Elle invite les futures entités essentielles et importantes à s’engager dès maintenant dans une démarche cohérente avec la directive et met à disposition, depuis le 17 mars 2026, le Référentiel Cyber France (ReCyF). L’agence qualifie ce référentiel de document de travail et précise qu’il est, à ce stade, par défaut non obligatoire. Cette nuance est importante : une société ne doit pas présenter le ReCyF comme une loi déjà appliquée à toutes les entreprises, mais elle peut s’en servir pour organiser ses contrôles et réunir des éléments utiles lors de la future mise en conformité.

Le droit français existant continue d’encadrer la relation entre l’entreprise et ses fournisseurs. L’article 1103 du Code civil dispose que « Les contrats légalement formés tiennent lieu de loi à ceux qui les ont faits ». Une convention d’infogérance, de maintenance, de licence ou de fourniture de matériel peut préciser le niveau de sécurité attendu, le délai d’alerte, la conservation des journaux, la coopération avec un CSIRT, l’assistance à la correction et la répartition du coût d’une notification. L’article 1104 du même code ajoute que « Les contrats doivent être négociés, formés et exécutés de bonne foi ». Une clause qui laisse le client sans information pendant une crise, alors que le fournisseur détient les journaux nécessaires à la qualification, doit être examinée à la lumière de ces engagements.

Pour un produit vendu à un consommateur, la garantie légale peut également entrer en jeu. L’article L. 217-3 du Code de la consommation impose au vendeur de délivrer un bien conforme au contrat et traite expressément le cas d’un bien comportant des éléments numériques. Il ne transforme pas toute vulnérabilité en défaut de conformité automatique, mais il oblige à distinguer l’absence de sécurité attendue au moment de la délivrance, le défaut apparu après cette délivrance et la question des mises à jour promises ou nécessaires.

La première grille de qualification peut être résumée ainsi :

• le produit numérique est-il fabriqué, importé ou distribué par l’entreprise ?
• le produit a-t-il été mis à disposition dans l’Union européenne, et sous quelle marque ?
• la vulnérabilité concerne-t-elle le code ou la conception du produit, ou seulement l’environnement informatique d’un client ?
• l’entreprise exploite-t-elle elle-même un réseau ou un système nécessaire à un service relevant de NIS2 ?
• l’incident a-t-il interrompu ce service, dégradé son intégrité ou compromis sa confidentialité ?
• des données personnelles sont-elles concernées, même si la faille se trouve dans un produit fourni par un tiers ?

Cette grille évite un premier faux raisonnement : « le fournisseur du logiciel doit notifier, donc l’entreprise utilisatrice n’a rien à faire ». Le fabricant peut avoir une obligation CRA tandis que l’utilisateur, parce que son service essentiel est perturbé, doit appliquer son propre plan NIS2 ou ses règles sectorielles. Inversement, une faille corrigée dans une bibliothèque interne sans exploitation active ni incident grave ne déclenche pas automatiquement l’alerte CRA. Il faut documenter la qualification plutôt que déclarer toute alerte technique comme un incident réglementaire.

Un autre faux raisonnement consiste à attribuer au CRA toutes les conséquences d’une intrusion. Le CRA concerne la sécurité du produit. Il ne remplace ni l’analyse de l’incident affectant le système d’information de l’entreprise, ni l’examen d’une éventuelle violation de données, ni la plainte pénale en cas d’accès frauduleux. L’article 323-1 du Code pénal punit l’accès ou le maintien frauduleux dans tout ou partie d’un système de traitement automatisé de données. La qualification pénale appartient aux autorités judiciaires ; elle ne doit pas retarder les mesures de confinement et d’information.

B. Faut-il notifier deux fois et quels sont les délais du 11 septembre 2026 ?

La réponse courte est la suivante : il n’y a pas deux dépôts CRA à effectuer pour un même produit. La Commission européenne indique que les fabricants déclarent une seule fois par la plateforme de signalement du CRA. Le dépôt est adressé au CSIRT du lieu de l’établissement principal et les informations sont, sauf circonstances exceptionnelles, transmises simultanément à l’ENISA. La FAQ de l’ANSSI précise que, pour un fabricant rattaché à la France, le CERT-FR de l’ANSSI reçoit la notification et que la plateforme permet de communiquer les compléments ultérieurs.

L’article 14 du règlement formule l’obligation en ces termes : « Un fabricant notifie toute vulnérabilité activement exploitée contenue dans le produit comportant des éléments numériques dont il prend connaissance ». L’expression « activement exploitée » n’est pas synonyme de vulnérabilité théorique, de défaut découvert par un audit ou de correctif simplement disponible. L’entreprise doit pouvoir expliquer les indices d’exploitation : journaux, échantillons, rapports de chercheurs, alertes de clients, compromission observée ou informations crédibles émanant d’un centre de réponse.

Pour une vulnérabilité activement exploitée, le calendrier CRA comprend trois séquences :

• une alerte précoce, sans retard injustifié et au plus tard vingt-quatre heures après la prise de connaissance ;
• une notification complétée, sans retard injustifié et au plus tard soixante-douze heures après la prise de connaissance, avec les informations disponibles sur le produit, la vulnérabilité, l’exploitation et les mesures prises ou proposées ;
• un rapport final au plus tard quatorze jours après la mise à disposition d’une mesure corrective ou d’atténuation.

Pour un incident grave ayant une incidence sur la sécurité du produit, le schéma conserve l’alerte précoce et la notification complète, mais le rapport final intervient au plus tard dans le mois. Le calcul doit partir de la prise de connaissance juridiquement pertinente, pas du moment où l’équipe technique a fini toute son analyse. Une équipe peut transmettre une alerte provisoire puis compléter les informations, à condition de garder les horodatages et les versions successives.

Le 11 septembre 2026 ne constitue pas une entrée en application générale de tout le CRA. Le texte prévoit une application générale à compter du 11 décembre 2027, avec une application anticipée de l’article 14 au 11 septembre 2026 et du chapitre IV relatif aux organismes d’évaluation de la conformité au 11 juin 2026. Le fabricant doit donc préparer dès maintenant le circuit de notification, même si les autres exigences de mise sur le marché suivent un calendrier différent. L’existence d’un article interne consacré à la faille activement exploitée et d’un autre consacré à la modification substantielle d’un logiciel ne dispense pas de traiter cette question plus étroite : comment coordonner deux régimes lorsque le même fait touche le produit et l’activité.

NIS2 connaît également une logique par étapes. Son article 23 prévoit une alerte précoce au CSIRT ou à l’autorité compétente dans les vingt-quatre heures suivant la prise de connaissance d’un incident important, puis une notification d’incident dans les soixante-douze heures avec une première évaluation de la gravité et de l’impact. Un rapport final doit en principe être fourni dans le mois, sauf si l’incident se poursuit, auquel cas un rapport d’avancement est possible. Ces délais concernent l’entité régulée et l’incident important affectant ses services ou ses opérations, non le simple fait qu’un produit d’un fournisseur comporte une vulnérabilité.

Le chevauchement se traite par une matrice, pas par la duplication mécanique d’un formulaire. Exemple : un éditeur français commercialise un logiciel de supervision dans l’Union. Une exploitation active de la faille du logiciel déclenche l’analyse CRA du fabricant. Si l’éditeur fournit en parallèle un service numérique entrant dans NIS2 et que sa propre plateforme tombe en panne ou perd son intégrité, le même événement peut aussi être un incident important NIS2. Le premier dépôt décrit le produit et ses mesures correctives ; le second décrit l’impact sur le service, les utilisateurs, la continuité et les indicateurs de compromission. Les deux déclarations peuvent partager des faits, mais elles ne répondent pas à la même question.

Autre exemple : un fabricant d’équipements industriels est lui-même opérateur d’une activité essentielle. Une faille dans le firmware de ses automates est exploitée chez plusieurs clients, mais le système de production du fabricant reste disponible. Le CRA peut s’appliquer au produit ; NIS2 ne se déclenche pas uniquement parce que les clients ont été exposés. À l’inverse, une attaque sur le réseau de l’usine, sans vulnérabilité activement exploitée dans un produit mis sur le marché, peut appeler une analyse NIS2 ou sectorielle sans appeler la notification CRA.

Enfin, DORA peut prévaloir pour une entité financière soumise à son régime spécial, et le RGPD ajoute sa propre analyse lorsque des données personnelles sont en cause. Une banque qui utilise un logiciel vulnérable ne devient pas automatiquement fabricant du logiciel. Elle doit cependant examiner l’incident selon ses obligations financières, contractuelles et de protection des données. Le prestataire éditeur, lui, doit examiner la notification CRA s’il est fabricant et ses propres obligations NIS2 s’il fournit un service couvert.

Le rôle de la plateforme ne supprime pas les décisions internes. Avant le dépôt, l’entreprise doit décider qui est le fabricant, quelle entité porte l’établissement principal, quels États membres sont concernés, quelles versions du produit sont exposées et quel événement est daté comme la prise de connaissance. La plateforme diffuse l’information ; elle ne tranche pas la responsabilité civile, ne remplace pas le registre d’incident et ne suspend pas les délais de déclaration sectoriels.

II. Après une faille : quelles preuves, notifications et actions pour l’entreprise ?

A. Que faut-il préparer avant d’alerter l’ANSSI, l’ENISA ou la CNIL ?

La notification doit être assez rapide pour protéger les utilisateurs, mais elle doit aussi rester défendable plusieurs mois plus tard devant une autorité, un assureur, un client ou un tribunal. La bonne méthode consiste à ouvrir un dossier de crise distinct du canal de discussion technique. Ce dossier reçoit un identifiant, un responsable, une date et une liste des décisions. Il ne doit pas être modifié silencieusement après coup.

Le premier document est une fiche de qualification initiale. Elle indique le produit, la version, la marque, le fabricant apparent, l’importateur, les distributeurs connus, les pays de mise à disposition, la période de soutien et le point de contact de sécurité. Si le fabricant n’est pas certain, il faut conserver les contrats, factures, déclarations de conformité, dossiers de conception et échanges commerciaux qui expliquent le rôle de chaque société. Cette étape est particulièrement importante lorsqu’une société commercialise une solution développée par une filiale ou un sous-traitant.

Le deuxième document est une chronologie. Elle distingue au moins : la première alerte reçue, la première vérification humaine, la confirmation raisonnable de l’exploitation, la mesure de confinement, la décision d’alerter, le dépôt effectif, la mise à disposition du correctif et les communications aux utilisateurs. La date d’un courriel automatique ne doit pas être confondue avec la date à laquelle l’entreprise a eu une connaissance exploitable. Si plusieurs équipes ont des informations différentes, le dossier doit conserver les éléments contradictoires et expliquer la décision retenue.

Le troisième document est une carte des impacts. Elle sépare le produit, les systèmes internes, les services fournis, les clients, les partenaires et les personnes physiques. Pour chaque impact, il faut préciser la disponibilité, l’intégrité et la confidentialité. Une faille qui permet une exécution de code dans le produit n’a pas la même conséquence qu’une interruption de la plateforme de support ; une extraction de comptes clients ajoute un risque de données personnelles ; une compromission limitée à un environnement de test peut rester hors d’un seuil d’incident important, sous réserve des textes applicables.

Le quatrième document est une matrice des destinataires. Elle contient, selon le cas : la Single Reporting Platform du CRA, le CSIRT ou l’autorité compétente NIS2, la CNIL, les autorités financières ou sectorielles, l’assureur, les clients contractuellement concernés et les forces de l’ordre. Il faut noter pour chacun le fondement, le déclencheur, le délai, le responsable du dépôt et la preuve de réception. Cette matrice évite le silence mais aussi la divulgation prématurée d’informations techniques qui pourrait aggraver l’exploitation.

Si des données personnelles sont susceptibles d’avoir été compromises, l’article 33 du RGPD s’applique selon le risque pour les droits et libertés des personnes. Le texte prévoit une notification à l’autorité de contrôle dans les meilleurs délais et, si possible, au plus tard soixante-douze heures après la prise de connaissance, sauf absence de risque. Il impose aussi de documenter toute violation. La page officielle de la CNIL recommande de préparer en interne la nature de la violation, les catégories et nombres approximatifs de personnes et d’enregistrements, les conséquences probables et les mesures prises. Une notification CRA ne remplace donc jamais l’analyse RGPD.

Le dossier probatoire doit permettre de répondre à cinq questions simples : que savait l’entreprise, à quel moment, sur quelle source, quelle mesure a-t-elle prise et pourquoi a-t-elle retenu ou écarté un régime de notification ? L’article 1353 du Code civil rappelle que « Celui qui réclame l’exécution d’une obligation doit la prouver ». En pratique, la preuve peut comprendre les journaux système, les exports de tickets, les empreintes de fichiers, les sauvegardes, les avis d’experts, les captures, les procès-verbaux de constat, les rapports de test, les courriels et les comptes rendus des décisions de direction.

Entre commerçants, l’article L. 110-3 du Code de commerce prévoit que les actes de commerce peuvent se prouver par tous moyens, sauf disposition contraire. Cette liberté ne signifie pas qu’un simple tableau rédigé après la crise suffira. La fiabilité de la collecte, la conservation de l’original, l’identité de l’auteur et l’absence d’altération doivent pouvoir être expliquées. Les accès à la plateforme de déclaration, les accusés de réception et les versions des formulaires doivent être archivés avec le dossier.

La jurisprudence montre la portée concrète de cette discipline. Dans son arrêt du 6 mars 2018, n° 17-80.875, la chambre criminelle de la Cour de cassation a cassé une décision qui n’avait pas recherché si le demandeur avait pu consulter les données utilisées contre lui. Elle rappelle que « la procédure pénale doit être équitable et contradictoire et préserver l’équilibre des droits des parties ». La décision concernait une infrastructure informatique et des investigations sur un serveur virtuel ; elle n’institue pas une procédure CRA, mais elle confirme l’intérêt de conserver une méthode de collecte contrôlable et contradictoire lorsqu’une plainte ou une expertise judiciaire est possible.

Avant toute communication externe, l’entreprise doit aussi préserver les éléments sans détruire la scène technique. Il faut isoler les comptes compromis, révoquer les jetons et clés exposés, conserver une copie des journaux avant rotation, documenter les changements de configuration et maintenir une version saine du produit. L’équipe juridique doit être associée à la décision de divulgation, sans empêcher les équipes de sécurité de contenir l’attaque. Le secret des affaires ne justifie pas une omission dans une notification obligatoire, mais il peut conduire à transmettre des détails sensibles par un canal sécurisé et à différer une publication publique qui révélerait un mode d’exploitation.

L’alerte précoce n’est pas un rapport d’expertise complet. Elle doit contenir les éléments nécessaires pour signaler le risque et demander de l’aide. L’entreprise peut préciser que certains faits sont en cours de vérification, à condition de ne pas présenter une hypothèse comme une certitude. La notification complémentaire doit reprendre l’identifiant de l’alerte, décrire les changements, corriger les erreurs et indiquer le correctif ou la mesure d’atténuation. Le rapport final explique la cause, la portée, les produits concernés, les pays touchés, les mesures de correction et les enseignements tirés.

À Paris et en Île-de-France, cette organisation vaut pour les éditeurs, intégrateurs, cabinets de conseil, start-up industrielles, opérateurs de services numériques et groupes qui ont leur direction juridique ou leur centre de décision dans la région. Le lieu du siège ne suffit toutefois pas à choisir tous les destinataires : le régime applicable dépend du rôle juridique, du service et de l’établissement concerné. Une société francilienne qui vend un produit dans plusieurs pays doit cartographier les États de mise à disposition et conserver la preuve de ce périmètre.

B. Quels recours contre le fournisseur, le sous-traitant ou le dirigeant ?

La notification réglementaire et le recours contractuel sont deux démarches différentes. Alerter une autorité ne vaut pas reconnaissance générale de responsabilité envers les clients. Inversement, engager une discussion avec le fournisseur ne permet pas de repousser une notification obligatoire. Les deux dossiers doivent être coordonnés, avec des formulations exactes et une distinction entre les faits établis, les hypothèses techniques et les préjudices déjà chiffrés.

Le contrat doit être lu article par article. Les points sensibles sont la sécurité du produit, la maintenance, la gestion des vulnérabilités, les mises à jour, le support hors horaires, les délais d’escalade, l’accès aux journaux, la sous-traitance, l’assurance, la limitation de responsabilité, la confidentialité, la coopération avec les autorités et la réversibilité. Il faut vérifier si le fournisseur s’est engagé à atteindre un résultat précis, à mettre en œuvre des moyens identifiés ou à informer immédiatement le client d’un incident. Une clause qui utilise un vocabulaire technique sans définir le niveau de service peut devenir le centre du litige.

L’article 1217 du Code civil offre plusieurs réponses en cas d’inexécution : « obtenir une réduction du prix », « provoquer la résolution du contrat » ou « demander réparation des conséquences de l’inexécution ». Selon l’urgence, l’entreprise peut demander la correction du service, suspendre une prestation devenue dangereuse, faire réaliser une expertise, réclamer une réduction, résilier ou solliciter des dommages et intérêts. Chaque mesure doit être compatible avec la continuité de l’activité et les obligations de coopération avec les autorités.

L’article 1231-1 du Code civil prévoit que le débiteur peut être condamné à des dommages et intérêts en raison de l’inexécution ou du retard, sauf force majeure. Le préjudice peut comprendre, selon les preuves et les limites contractuelles, les frais d’expertise et de remédiation, les coûts de restauration, la perte d’exploitation, les pénalités versées aux clients, les dépenses de communication de crise et la perte de marge directement liée à l’incident. Les dommages purement hypothétiques ou les pertes trop éloignées restent contestables.

Lorsque le fournisseur a commis une faute distincte qui a causé un dommage à un tiers, l’article 1240 du Code civil rappelle que « Tout fait quelconque de l’homme, qui cause à autrui un dommage, oblige celui par la faute duquel il est arrivé à le réparer ». Le fondement dépend des relations entre les parties, de la qualité du demandeur, du contenu du contrat et du dommage. Une entreprise utilisatrice ne doit pas recopier automatiquement le fondement délictuel dans une relation contractuelle ; elle doit identifier l’obligation violée et le lien causal.

La décision de la chambre commerciale du 2 juin 2021, n° 19-17.862, constitue un rappel utile dans un litige lié à une cyberattaque ayant touché des abonnés d’un fournisseur d’accès. La Cour de cassation a prononcé une cassation partielle pour un motif de procédure relatif à la rectification d’une décision, mais le dossier fait apparaître les questions que les parties doivent pouvoir établir : contenu du contrat, alerte donnée ou non, origine technique du piratage, paiements effectués auprès des clients et lien entre la faute invoquée et le dommage. La référence officielle est disponible sur Légifrance, chambre commerciale, 2 juin 2021, n° 19-17.862. Elle doit être utilisée comme illustration probatoire, non comme une règle générale attribuant automatiquement une cyberattaque au fournisseur.

Un second arrêt permet de sécuriser les clauses de responsabilité et de délai. Dans l’arrêt de la première chambre civile du 13 mars 2024, n° 22-12.345, la Cour de cassation a jugé qu’un fournisseur d’accès ne pouvait pas se décharger par une clause d’obligation générale de moyens contraire au régime applicable aux contrats concernés. Elle a également rappelé qu’une clause ne peut pas réduire la prescription en dessous de la limite légale en fixant son point de départ à la survenance du fait générateur plutôt qu’à la connaissance des faits. La décision, publiée au bulletin, est consultable sur Légifrance, première chambre civile, 13 mars 2024, n° 22-12.345. Le contrat d’un éditeur de logiciel n’est pas celui d’un fournisseur d’accès, mais la leçon pratique demeure : une clause doit être confrontée au régime impératif applicable avant d’être opposée au client.

La responsabilité du dirigeant doit être abordée avec prudence. Le seul fait qu’une société ait subi une faille ne prouve pas une faute personnelle du dirigeant. En revanche, une absence totale de gouvernance, la suppression de journaux, la dissimulation d’un incident, la poursuite de la mise sur le marché d’un produit dont une vulnérabilité activement exploitée est connue ou le refus de financer une mesure indispensable peuvent nourrir une analyse distincte. Il faut comparer les informations dont disposait l’organe de direction, les délégations, les alertes reçues, les décisions prises et les ressources disponibles.

Pour un sous-traitant, la stratégie commence par une mise en demeure précise. Elle demande la conservation des preuves, l’identification des versions touchées, la communication des mesures de correction, la coopération aux notifications et la prise en charge des coûts prévus au contrat. Elle évite d’accuser sans preuve l’auteur technique de la faille, car la vulnérabilité peut provenir d’un composant tiers, d’une configuration du client, d’une intégration ou d’une exploitation que personne ne pouvait raisonnablement détecter au moment concerné. La mise en demeure doit néanmoins réserver les droits de l’entreprise et interrompre, lorsque cela est juridiquement possible, les discussions qui risquent de laisser courir un délai.

La preuve du préjudice se construit par postes. Il faut conserver les factures de l’expert, les jours mobilisés, les mesures d’urgence, les licences de remplacement, les remises accordées aux clients, les notifications contractuelles, les pertes de production, les commandes annulées et les recettes comparables. Une comptabilité analytique séparée permet de rapprocher chaque dépense de l’incident. L’entreprise doit également calculer ce qu’elle aurait dépensé même sans attaque pour éviter de réclamer une économie qui ne constitue pas un dommage.

L’assurance cyber ne doit pas être oubliée. La police peut imposer une déclaration rapide, une procédure de choix de l’expert, une interdiction de reconnaître la responsabilité sans accord de l’assureur ou des conditions relatives au prestataire de réponse à incident. La déclaration à l’assureur doit rester cohérente avec les notifications réglementaires, mais elle peut être plus détaillée sur les coûts et la garantie recherchée. Le refus de garantie, un retard de prise en charge ou une exclusion de vulnérabilité connue peuvent ouvrir un litige spécifique, à documenter séparément.

Si l’entreprise est assignée ou menacée d’une action, elle doit conserver la séquence exacte de ses notifications. Un dépôt tardif peut être discuté par l’autorité, mais il ne suffit pas à établir tout le dommage commercial allégué par un client. À l’inverse, une notification honnête et chronologiquement documentée ne neutralise pas une faute de sécurité antérieure. Le juge examine les obligations contractuelles, la gravité du manquement, la prévisibilité du dommage, les mesures de mitigation et le comportement de chaque partie.

Enfin, il faut éviter de confondre notification et publication. La SRP, un CSIRT, la CNIL ou une autorité sectorielle reçoivent des informations selon des règles précises. Une communication publique aux utilisateurs obéit à une autre logique : elle doit permettre de se protéger, expliquer les versions concernées et le correctif, sans donner aux attaquants un mode opératoire exploitable. Le calendrier de communication doit être décidé avec l’équipe de sécurité, le conseil juridique et, lorsque la police le demande, les enquêteurs.

Conclusion

Le 11 septembre 2026, le CRA déclenchera une obligation de signalement spécifique pour les fabricants : une vulnérabilité activement exploitée ou un incident grave touchant la sécurité d’un produit doit être déclaré selon le calendrier de l’article 14. Le fabricant dépose une notification CRA via la plateforme unique ; il n’a pas à multiplier les dépôts CRA pour chaque État de mise à disposition. En revanche, la même crise peut créer une obligation distincte pour une entité NIS2 si ses réseaux, ses systèmes ou ses services sont affectés, et une obligation RGPD si des données personnelles présentent un risque.

La méthode robuste consiste à qualifier séparément le produit, l’entité, le service et les données, puis à faire courir chaque délai depuis un événement horodaté. L’entreprise doit conserver la preuve des alertes reçues, des mesures prises, des notifications déposées et des raisons pour lesquelles un régime a été retenu ou écarté. Cette discipline protège à la fois les utilisateurs, la direction, les relations contractuelles et les droits de recours.

Avant l’échéance, un fabricant ou un fournisseur numérique devrait donc vérifier son rôle dans la chaîne de mise sur le marché, préparer son contact de sécurité, tester son accès à la plateforme, établir sa matrice CRA-NIS2-RGPD, relire ses contrats et organiser la conservation des journaux. Si une faille est déjà exploitée, l’urgence ne permet pas d’attendre la fin de l’analyse : l’alerte initiale doit partir avec les informations disponibles, puis être complétée de manière contrôlée.

Besoin d’un avis rapide sur votre dossier

Une consultation téléphonique en 48 heures avec un avocat du cabinet peut vous aider à qualifier l’incident, préserver les preuves et organiser les notifications utiles.

Une consultation téléphonique en 48 heures avec un avocat du cabinet permet aussi de relire les contrats du fournisseur, la police d’assurance et la stratégie de recours.

Appelez le cabinet au 06 46 60 58 22 ou utilisez le formulaire de contact. Le cabinet accompagne les entreprises à Paris et en Île-de-France dans leurs problématiques de cybersécurité, de contrats numériques et de responsabilité.