Preuves d’incidents de cybersécurité NIS2 : guide de conformité complet 2026

NIS2 en 2026 : pourquoi les enjeux viennent de monter

La directive NIS2 ((UE) 2022/2555) est entrée dans la phase que chaque directive de cybersécurité atteint finalement — la phase où la préparation se termine et l’application commence. Les États membres étaient tenus de la transposer en droit national avant le 17 octobre 2024. La plupart ont manqué cette échéance. En mars 2026 toutefois, 21 des 27 États membres de l’UE ont achevé la transposition, et la Commission européenne a passé les douze derniers mois à appliquer systématiquement une pression sur les retardataires restants.

En mai 2025, la Commission a émis des avis motivés à dix-neuf États membres qui n’avaient pas encore notifié une transposition complète — dont l’Allemagne, la France, l’Espagne, la Pologne, l’Irlande et les Pays-Bas. Un avis motivé est la dernière étape formelle avant que la Commission ne saisisse la Cour de justice de l’Union européenne, où des pénalités financières deviennent possibles. Le message aux capitales était sans ambiguïté : faites-le, ou payez-en le prix.

Tout au long de la fin 2025 et des premiers mois de 2026, cette pression a produit des résultats. L’Allemagne a achevé sa loi NIS2 nationale en décembre 2025. La loi suédoise sur la cybersécurité est entrée en vigueur en janvier 2026. Le Zákon o kybernetické bezpečnosti de la République tchèque a commencé à s’appliquer à partir du 1er novembre 2025. L’Autriche, l’Italie, le Portugal, les Pays-Bas et d’autres sont soit entrés en vigueur, soit dans les phases finales de le faire au cours de 2026. La période de grâce — l’entente implicite que personne ne sera sanctionné tant que la transposition est encore incomplète — a disparu.

Le 20 janvier 2026, la Commission a aussi proposé des amendements ciblés à NIS2 elle-même, visant à simplifier la conformité pour environ 28 700 entités. Ces amendements ne relâchent pas les obligations fondamentales ; ils clarifient le langage et réduisent la paperasse. Ils constituent une reconnaissance que NIS2 sera désormais appliquée sur le long terme, et que le cadre doit être exploitable à l’échelle à travers environ 160 000 entités dans le champ d’application à travers l’Union.

Pour les organisations soumises à NIS2, cela signifie une chose : le test opérationnel est arrivé. Les politiques de cybersécurité qui semblent bonnes sur le papier doivent désormais performer sous l’horloge de l’alerte précoce de 24 heures. Les cadres de gestion des risques doivent produire une preuve qu’un CSIRT national acceptera. Les conseils d’administration doivent démontrer une surveillance active sous menace de responsabilité personnelle. Et parmi les goulots d’étranglement pratiques qui prennent au dépourvu même les organisations bien préparées, un se distingue : dès qu’un incident commence, les preuves commencent à disparaître, et l’entité doit les capturer avant qu’elles ne soient perdues. Ce guide se concentre sur ce goulot d’étranglement — ce qu’il faut préserver, pourquoi c’est important juridiquement, et comment le faire d’une manière qui tient face à l’examen des autorités de contrôle à travers l’UE.

Qui NIS2 couvre : entités essentielles et importantes

NIS2 classe les organisations dans le champ d’application en deux catégories — entités essentielles et entités importantes — selon la criticité de leur secteur et la taille de l’organisation. Les deux catégories doivent mettre en œuvre les mêmes dix mesures de gestion des risques de cybersécurité au titre de l’article 21 et doivent se conformer aux mêmes obligations de signalement d’incident au titre de l’article 23. La différence réside dans le régime de contrôle appliqué à chaque catégorie et les pénalités maximales qui peuvent être imposées.

Entités essentielles (Annexe I, grandes entreprises)

Les entités essentielles sont des organisations opérant dans des secteurs de haute criticité (Annexe I) qui se qualifient comme grandes entreprises — généralement au moins 250 employés, ou un chiffre d’affaires annuel dépassant 50 millions d’euros et un total de bilan dépassant 43 millions d’euros. La liste couvre l’énergie (électricité, gaz, pétrole, chauffage urbain, hydrogène), les transports (aérien, ferroviaire, par voie d’eau, routier), la banque, les infrastructures des marchés financiers, la santé, l’eau potable, les eaux usées, l’infrastructure numérique (DNS, TLD, IXP, centres de données, cloud, CDN, prestataires de services de confiance), la gestion de services TIC en B2B, l’administration publique aux niveaux central et régional, et l’espace.

Entités importantes (Annexe II, moyennes entreprises et sous le seuil essentiel)

Les entités importantes sont des organisations dans d’autres secteurs critiques (Annexe II) ou dans des secteurs de l’Annexe I qui tombent sous le seuil de taille pour la classification essentielle. L’Annexe II couvre les services postaux et de messagerie, la gestion des déchets, la fabrication et distribution de produits chimiques, la production, transformation et distribution de denrées alimentaires, la fabrication (dispositifs médicaux, produits informatiques et électroniques, équipements électriques, machines, véhicules automobiles, autres équipements de transport), les fournisseurs numériques (places de marché en ligne, moteurs de recherche en ligne, plateformes de réseaux sociaux), et les organismes de recherche.

Régime de contrôle : article 32 versus article 33

Les deux catégories font face à des régimes de contrôle différents. Les entités essentielles sont soumises à l’article 32 — un contrôle proactif ex ante, qui inclut des inspections régulières sur site, des audits hors site, des demandes de documentation, et des audits de sécurité et tests de pénétration mandatés par l’autorité de contrôle. Les entités importantes relèvent de l’article 33 — un contrôle ex post déclenché seulement lorsque les autorités ont la preuve d’une non-conformité. La conséquence pratique est que les entités essentielles vivent avec une présence réglementaire continue ; les entités importantes traitent avec le régulateur principalement après que quelque chose a mal tourné.

Exemptions des petites et micro-entreprises, et discrétion des États membres

Les organisations de moins de 50 employés et dont le chiffre d’affaires annuel ou le total de bilan est de 10 millions d’euros ou moins sont généralement exemptées du champ d’application obligatoire. Cependant, les États membres conservent la discrétion d’inclure des entités plus petites dans le champ d’application lorsque l’entité est le seul prestataire d’un service dans une région, lorsque sa défaillance créerait un risque systémique, ou lorsqu’elle opère dans des sous-secteurs particuliers. L’Italie et la Slovénie ont notablement étendu leur champ d’application national au-delà des annexes de la directive ; la Belgique a ajouté des obligations de gouvernance renforcées. À retenir : même si votre organisation semble tomber sous le seuil, la transposition nationale est le document qui détermine si NIS2 s’applique à vous.

Les 18 secteurs et la règle du plafond de taille

NIS2 élargit dramatiquement le champ d’application sectoriel par rapport à son prédécesseur. Là où NIS1 s’appliquait à sept secteurs, NIS2 s’applique à dix-huit, organisés sur deux annexes. L’expansion reflète à quel point la société moderne est devenue dépendante des services numériques et des chaînes d’approvisionnement — et comment un incident de cybersécurité dans l’un de ces secteurs peut se propager à travers les frontières en quelques heures.

Annexe I : secteurs de haute criticité

Les secteurs de l’Annexe I sont ceux dont la perturbation produit des conséquences immédiates à l’échelle de la société. Ils incluent l’énergie sous ses diverses formes, les transports, la banque et l’infrastructure des marchés financiers, la santé, l’eau potable et les eaux usées, l’infrastructure numérique (qui couvre les prestataires DNS, les registres TLD, les points d’échange internet, les fournisseurs de cloud computing, les prestataires de services de centres de données, les réseaux de diffusion de contenu, les prestataires de services de confiance et les fournisseurs de communications électroniques), la gestion de services TIC en B2B, l’administration publique aux niveaux central et régional, et l’espace. Chacun de ceux-ci a ses propres spécificités sectorielles dans la transposition des États membres, mais la référence de cybersécurité est harmonisée.

Annexe II : autres secteurs critiques

L’Annexe II couvre des secteurs qui sont critiques mais où la perturbation est généralement moins immédiatement catastrophique — bien qu’elle puisse encore produire un préjudice significatif. Elle inclut les services postaux et de messagerie, la gestion des déchets, les produits chimiques (fabrication, distribution), la production alimentaire, la fabrication de dispositifs médicaux et de biens industriels clés, les fournisseurs de services numériques dont les places de marché en ligne, les moteurs de recherche et les services de réseaux sociaux, et les organismes de recherche. Le règlement d’exécution (UE) 2024/2690 de la Commission fournit des règles techniques et de classification d’incidents spécifiques pour plusieurs sous-secteurs de l’Annexe II, dont le cloud, le DNS, les places de marché, la recherche et les réseaux sociaux.

La règle du plafond de taille

Au sein de ces secteurs, NIS2 applique une règle de plafond de taille : les organisations se qualifient comme dans le champ d’application si elles ont au moins 50 employés ET un chiffre d’affaires annuel ou un total de bilan dépassant 10 millions d’euros. Les grandes entreprises (250+ employés, ou 50 M€+ de chiffre d’affaires et 43 M€+ de bilan) dans les secteurs de l’Annexe I sont classées comme entités essentielles. Les entreprises de taille moyenne (50-249 employés, 10-50 M€ de chiffre d’affaires) dans l’Annexe I, et toute entreprise moyenne ou grande dans l’Annexe II, sont classées comme entités importantes. Le plafond est intentionnellement généreux — NIS2 ne veut pas écraser les petites entreprises avec des obligations disproportionnées — mais il capture essentiellement chaque acteur significatif dans les secteurs réglementés.

Exceptions, portée de la chaîne d’approvisionnement, et l’effet de l’acheteur réglementé de facto

Au-delà du champ d’application formel, NIS2 a une portée pratique qui s’étend bien plus loin. L’article 21 exige des entités essentielles et importantes qu’elles gèrent la cybersécurité de la chaîne d’approvisionnement — ce qui signifie que l’entité doit évaluer et imposer des mesures de sécurité appropriées à ses fournisseurs directs et prestataires de services. Le résultat est que les organisations non directement dans le champ d’application de NIS2 sont de plus en plus tenues de démontrer une sécurité alignée sur NIS2 à leurs clients réglementés, simplement pour rester dans le pipeline d’approvisionnement. Si votre client est dans le champ d’application, votre contrat est dans le champ d’application. Cet effet indirect double ou triple la population de facto d’entités pertinentes pour NIS2 à travers l’économie de l’UE.

L’article 23 en détail : le calendrier de signalement en trois étapes

L’article 23 est le cœur opérationnel de NIS2 pour la réponse aux incidents. Il établit une cascade de signalement en trois étapes avec des délais stricts, et ajoute une obligation de notifier les destinataires de services dans certaines circonstances. L’horloge commence à tourner lorsque l’entité prend connaissance qu’un incident significatif s’est produit — une définition qui est elle-même contestée en pratique — et elle ne s’arrête pas jusqu’à ce que le rapport final soit soumis jusqu’à un mois plus tard. Manquer toute étape est un manquement à la conformité, et les autorités de contrôle ont clairement déclaré qu’elles le traiteront comme tel.

Étape 1 — alerte précoce de 24 heures

Dans les 24 heures suivant la prise de connaissance d’un incident significatif, l’entité doit soumettre une alerte précoce à son CSIRT national ou autorité compétente. L’alerte précoce doit indiquer, lorsque l’information est disponible, si l’incident est soupçonné d’être causé par des actes illicites ou malveillants, et s’il pourrait avoir un impact transfrontalier. Ce n’est pas un rapport complet — son but est d’alerter les autorités pour qu’elles puissent se préparer à une réponse coordonnée et informer les autres États membres affectés. Les défaillances courantes à ce stade incluent l’absence de canaux de communication CSIRT pré-établis, l’absence de modèle pré-préparé, et l’incertitude sur si l’événement atteint encore le seuil significatif.

Étape 2 — notification d’incident de 72 heures

Dans les 72 heures suivant la prise de connaissance, l’entité doit soumettre une notification d’incident plus substantielle. Cette mise à jour doit inclure une évaluation initiale de l’incident — gravité, portée, impact — et surtout, lorsque disponibles, les indicateurs de compromission (IoC). La notification de 72 heures est là où la préservation de preuves devient contraignante : vous ne pouvez pas décrire des IoC que vous avez laissé écraser. Les pages de hameçonnage, les fausses interfaces de connexion, les URL malveillantes, les propriétés web défigurées, et autres artefacts d’attaque orientés web doivent être capturés avant qu’ils ne s’évanouissent pendant la remédiation de la réponse aux incidents.

Étape 3 — rapport final d’un mois

Au plus tard un mois après la notification d’incident, l’entité doit soumettre un rapport final. Celui-ci contient une description détaillée de l’incident, y compris sa gravité et son impact, le type de menace ou la cause racine qui l’a probablement déclenché, les mesures d’atténuation appliquées et en cours, et le cas échéant, l’impact transfrontalier. Le rapport final est le document auquel les autorités de contrôle reviendront lors de toute inspection ou audit ultérieur. Sa qualité détermine si votre organisation sera considérée comme ayant traité l’incident de manière professionnelle — ou comme ayant manqué les bases.

Rapports intermédiaires sur demande du CSIRT, et rapports d’avancement pour les incidents en cours

Le CSIRT ou l’autorité compétente peut demander des mises à jour intermédiaires à tout moment pendant la phase de réponse. Si l’incident est encore en cours à l’échéance d’un mois, l’entité soumet un rapport d’avancement au lieu d’un rapport final, avec un rapport final ultérieur dû dans un mois après que l’incident a réellement pris fin. Le mécanisme intermédiaire crée un dialogue continu entre l’entité et l’autorité — et signifie que la capacité de l’entité à produire des mises à jour crédibles et étayées par des preuves sur demande est une capacité permanente, pas un effort ponctuel.

Notification des destinataires de services (article 23(2))

Lorsqu’un incident significatif est susceptible d’affecter défavorablement la fourniture de services aux destinataires, l’entité doit informer ces destinataires sans retard indu. Cela inclut de décrire ce qui s’est passé, quels services sont affectés, et quelles mesures d’atténuation les destinataires devraient prendre. Pour les prestataires B2B cela signifie notifier leur base de clients ; pour les prestataires orientés consommateurs cela peut signifier une communication publique. La notification elle-même devient partie de l’enregistrement de preuve — et une fois qu’elle a été publiée, c’est ce à quoi l’autorité de contrôle tiendra l’entité.

Ce qui compte comme incident significatif

L’article 23 ne se déclenche que lorsqu’un incident est significatif. La définition de la directive est large : un incident est significatif s’il a causé ou est capable de causer une perturbation opérationnelle grave des services de l’entité ou une perte financière pour l’entité, ou s’il a affecté ou est capable d’affecter d’autres personnes physiques ou morales en causant un dommage matériel ou immatériel considérable. Le libellé « capable de causer » est critique — les entités ne peuvent pas attendre que le préjudice se matérialise pour commencer à signaler. La prévisibilité raisonnable suffit.

Seuils du règlement d’exécution 2024/2690 de la Commission

Pour des entités spécifiées du secteur numérique (prestataires DNS, registres TLD, fournisseurs de cloud, centres de données, CDN, MSP, MSSP, places de marché en ligne, moteurs de recherche, réseaux sociaux, et prestataires de services de confiance), le règlement d’exécution (UE) 2024/2690 de la Commission du 17 octobre 2024 fixe des seuils concrets. Un incident est significatif lorsque, entre autres, il cause ou est capable de causer une perte financière dépassant 100 000 € ou 5 % du chiffre d’affaires annuel (le plus faible des deux), ou lorsqu’il implique un accès non autorisé réussi et suspecté malveillant aux réseaux et systèmes d’information, ou lorsqu’il cause un dommage réputationnel considérable. Le règlement s’applique directement à ses secteurs nommés ; pour les autres entités, il sert de référence interprétative utile.

Dommage réputationnel et attention médiatique comme facteurs

Le critère du dommage réputationnel considérable n’est pas subjectif. Les régulateurs examinent des indicateurs concrets : si l’incident a été rapporté dans les médias grand public, si l’entité est susceptible de perdre des clients en nombre significatif pour son activité, si elle sera incapable de satisfaire les exigences réglementaires en conséquence en aval, et si la position de l’entité auprès des partenaires et des superviseurs a été mesurablement endommagée. Les attaques ciblant la marque — pages de hameçonnage usurpant vos services, fausses interfaces de connexion hébergées sur des domaines sosies — se situent carrément dans cette catégorie, et elles génèrent des artefacts orientés web qui doivent être préservés comme preuves.

Accès non autorisé réussi comme déclencheur automatique

L’une des dispositions les plus conséquentes sur le plan opérationnel du RE 2024/2690 est que tout accès non autorisé réussi et suspecté malveillant aux réseaux et systèmes d’information est en soi significatif pour les entités dans le champ d’application du règlement. Cela élimine le débat sur les seuils : si un attaquant est entré et que l’accès est soupçonné d’être malveillant, c’est significatif, et l’horloge de 24 heures démarre. Le champ de signification plus large de la directive — perte financière, dommage réputationnel, perturbation de service — s’applique par-dessus cette référence.

Incidents récurrents et le seuil agrégé

Une série d’incidents plus petits peut collectivement atteindre le seuil significatif même si chaque événement individuel ne le ferait pas. Le libellé des considérants à travers les textes d’exécution indique clairement que les autorités attendent des entités qu’elles évaluent les incidents récurrents en agrégat, pas isolément. Cela est particulièrement pertinent pour les secteurs faisant face à des attaques persistantes de type campagne : une séquence de tentatives de credential stuffing, une série de rafales DDoS à faible volume, ou des vagues de hameçonnage coordonnées peuvent ensemble franchir le seuil. Documenter le lien entre les incidents est en soi un défi probant — un qui dépend d’une rétention de journaux cohérente et d’une capture forensique tout au long de la chronologie de la campagne.

Pourquoi la préservation de preuves équivaut à la conformité NIS2

Il y a une tendance parmi les organisations nouvellement réglementées par NIS2 à traiter le signalement d’incident comme un problème de paperasse — remplir le modèle, cliquer sur soumettre, passer à autre chose. Cette vision méconnaît fondamentalement ce que la notification de 72 heures exige réellement et ce que les autorités de contrôle vérifieront lors des inspections. La notification d’incident de 72 heures mandate l’inclusion des indicateurs de compromission lorsque disponibles. Le rapport final d’un mois mandate une description de la cause racine et du type de menace. Ni l’un ni l’autre n’est réalisable sans preuve forensique préservée — et cette preuve doit être capturée au moment de la détection, pas reconstruite des semaines plus tard.

Les orientations techniques de l’ENISA sur les mesures de gestion des risques NIS2, publiées en novembre 2024 aux côtés du règlement d’exécution 2024/2690 de la Commission, mettent l’accent sur la préservation de preuves comme partie intégrante du traitement des incidents. Les orientations placent l’obligation aux côtés de la détection, du confinement et de la récupération — pas comme un ajout optionnel. Les journaux doivent être conservés avec une intégrité et une durée suffisantes pour soutenir la reconstruction post-incident. Douze mois de journalisation infalsifiable est une référence largement acceptée ; certaines transpositions sectorielles spécifiques en exigent davantage.

Mais la catégorie de preuve la plus délicate n’est pas les données de journaux — ce sont les artefacts orientés web de l’attaque elle-même. Lorsque le vecteur d’attaque implique une page de hameçonnage usurpant vos services, une fausse interface de connexion qui a capturé les identifiants de vos clients, un site web d’entreprise défiguré, ou un site de fuite de rançongiciel publiant vos données volées, la preuve est hébergée sur une infrastructure que vous ne contrôlez pas. Le fournisseur d’hébergement la retire en quelques heures ou jours. L’attaquant l’abandonne. L’enregistrement DNS est neutralisé. Le temps que vous rédigiez la notification de 72 heures, la preuve a disparu à moins que vous ne l’ayez capturée pendant la réponse initiale.

C’est précisément la lacune que les plateformes de preuve web forensique comme GetProofAnchor sont conçues pour combler. Une capture faite au moment de la détection de l’incident produit un paquet infalsifiable — HTML complet, capture d’écran rendue, contenu extrait, métadonnées réseau, chaîne TLS — liés ensemble par un horodatage électronique qualifié au titre de l’article 42 d’eIDAS, ancré indépendamment dans la blockchain Bitcoin via OpenTimestamps, et relié par une chaîne cryptographique en ajout seul. Lorsque l’autorité de contrôle demande deux mois plus tard la preuve que la page de hameçonnage existait et ressemblait à ce que vous avez décrit, le ZIP de preuve fournit la réponse avec une certitude mathématique.

Le point n’est pas que chaque entité NIS2 doive adopter un outil spécifique. Le point est que la préservation de preuves pendant la phase de réponse aux incidents est une obligation de conformité de premier ordre au titre de NIS2 — et que les organisations qui n’ont pas bâti cette capacité avant qu’un incident ne survienne découvriront, trop tard, que l’absence de preuve préservée devient son propre manquement à signaler.

Capturer forensiquement les preuves d’attaque sur le web

Beaucoup des incidents significatifs NIS2 les plus courants laissent leur trace forensique primaire sur l’internet public. Comprendre quels artefacts capturer, et comment les capturer d’une manière qui satisfait les attentes de l’autorité de contrôle, est l’une des capacités opérationnelles à plus fort levier qu’une entité réglementée par NIS2 peut développer. Le reste de cette section parcourt cinq catégories de preuves d’incident sur le web et à quoi ressemble la capture forensique pour chacune.

Pages de hameçonnage usurpant vos services

Lorsqu’un attaquant met en place une page de hameçonnage sur un domaine sosie pour récolter les identifiants de vos clients, la page elle-même est la preuve flagrante. Elle démontre le ciblage de votre marque par l’attaquant, la sophistication technique de la campagne, et la portée de l’exposition des clients. La capture forensique doit inclure le HTML complet, le rendu visuel (plusieurs fenêtres si des variantes spécifiques au mobile existent), les captures réseau (HAR, DNS, chaîne de certificats TLS montrant le domaine sosie), et l’horodatage de capture lié cryptographiquement à tous les artefacts. Une capture d’écran standard ne suffit pas — l’autorité de contrôle et tout renvoi ultérieur aux forces de l’ordre voudront le DOM sous-jacent et l’identité réseau de l’infrastructure malveillante.

Sites web d’entreprise défigurés et modifications de contenu non autorisées

Les incidents de défiguration — où les attaquants modifient le contenu visible de votre site web public pour afficher de la propagande, des demandes de rançon, ou simplement de la moquerie — durent typiquement des heures avant la remédiation. Le processus de remédiation lui-même détruit des preuves : les pages modifiées sont écrasées par le contenu restauré, les journaux de serveur peuvent être pivotés, et les artefacts pertinents sur le plan forensique disparaissent dans le cycle de sauvegarde. Avant que la remédiation ne commence, l’état défiguré devrait être capturé forensiquement. La même chose s’applique aux modifications non autorisées subtiles — un seul extrait JavaScript injecté exfiltrant les données de formulaire, une iframe cachée, un point de terminaison de paiement modifié — qui exigent la capture non seulement de la page visible mais des scripts sous-jacents et des appels réseau.

Sites de fuite de rançongiciel et déversements de données sur le dark web

Lorsqu’un attaquant exfiltre des données et les publie sur un site de fuite pour extorquer un paiement, le site de fuite lui-même est une preuve. Il démontre la matérialisation du risque d’exfiltration, la portée des données que l’attaquant prétend détenir, et la chronologie de négociation. La plupart des groupes de rançongiciel opèrent sur des services cachés Tor, et ces services vont et viennent rapidement. Une capture forensique de la page d’annonce, de la structure du fichier de données d’échantillon, du compte à rebours, et des instructions de paiement de la rançon devient une preuve critique pour le rapport final — et pour tout engagement ultérieur des forces de l’ordre, réclamation d’assurance, ou contentieux civil en aval.

Comptes de réseaux sociaux usurpant la marque et fausses pages de support

Adjacentes au hameçonnage au sens strict sont les campagnes d’usurpation de marque sur les réseaux sociaux et via des pages de support falsifiées. Celles-ci sont particulièrement dommageables car elles s’exécutent souvent en parallèle avec une intrusion primaire — l’usurpateur de réseau social dirige le trafic vers la page de hameçonnage hébergée ailleurs — et parce qu’elles étendent la portée de la base de clients affectée. La capture devrait inclure le profil de l’usurpateur, toutes les publications, les nombres d’abonnés, l’infrastructure de hameçonnage liée, et la chronologie des tentatives de retrait et des réponses de la plateforme.

Indicateurs de compromission de la chaîne d’approvisionnement sur des propriétés tierces

De nombreux incidents NIS2 proviennent non pas de l’infrastructure que l’entité possède mais d’un service tiers que l’entité consomme. Un fournisseur SaaS compromis, un point de terminaison CDN détourné, une mise à jour logicielle corrompue sur le site web d’un fournisseur — chacun de ceux-ci exige de l’entité qu’elle capture la preuve de l’état du tiers au moment de la détection, avant que le tiers ne remédie et que la trace ne soit perdue. C’est l’un des problèmes probants véritablement nouveaux que NIS2 introduit, car l’entité doit démontrer quelque chose qu’elle ne contrôlait pas. La seule solution est de capturer l’état du tiers comme instantané forensique au moment de la prise de connaissance — avec un horodatage crédible qui prouve quand la capture a été faite — et de préserver cette capture indépendamment du tiers.

Chaîne de preuve : l’ISO 27037 rencontre NIS2

NIS2 elle-même ne prescrit pas de méthodologie de chaîne de preuve spécifique. L’article 21 exige des mesures appropriées et proportionnées, et les considérants de la directive pointent vers les normes européennes et internationales comme référence pratique de ce qu’approprié signifie. Dans l’espace de la preuve numérique, cette référence est l’ISO/IEC 27037:2012 — la norme internationale pour l’identification, la collecte, l’acquisition et la préservation de la preuve numérique. Les entités qui alignent leurs procédures de traitement des incidents sur l’ISO 27037 se retrouveront naturellement à satisfaire les attentes de NIS2 liées aux preuves.

L’ISO 27037 définit quatre phases pour le traitement de la preuve numérique : identification (reconnaître quels éléments de données sont des preuves), collecte (les rassembler physiquement), acquisition (créer des copies forensiquement saines), et préservation (maintenir l’intégrité dans le temps). Pour la preuve sur le web, les quatre phases se projettent proprement sur une seule opération de capture forensique — à condition que la capture soit conçue pour produire, en une étape atomique, un artefact qui est identifiable, collecté, acquis, et prêt à la préservation. C’est l’objectif de conception de toute plateforme de preuve web forensique sérieuse : réduire le workflow en une seule opération défendable, documenter chaque paramètre, et produire un paquet dont l’intégrité peut être vérifiée indépendamment.

La primitive d’intégrité est l’empreinte cryptographique. Chaque artefact du paquet de preuve — la capture d’écran, le HTML, le texte extrait, les captures réseau, les métadonnées — est haché avec SHA-256 et les empreintes sont enregistrées dans un manifeste. Le manifeste est lui-même haché, et cette empreinte finale est l’entrée d’un horodatage électronique qualifié eIDAS au titre de l’article 42 du règlement (UE) 910/2014. L’horodatage qualifié lie l’ensemble du paquet à un moment spécifique dans le temps, avec le même effet juridique dans les 27 États membres de l’UE qu’une attestation notariale de date. Toute modification ultérieure de tout octet de tout artefact rompt la chaîne et est détectable en quelques secondes lors de la vérification.

L’ancrage dans la blockchain Bitcoin via OpenTimestamps fournit une deuxième couche indépendante qui ne dépend pas de l’entité, du prestataire de services de confiance, ou d’une quelconque infrastructure centralisée. Cela importe pour les incidents transfrontaliers où l’entité peut avoir besoin de démontrer l’intégrité de la preuve à des autorités dans un État membre dont l’entité connaît peu l’EU Trusted List nationale. L’ancrage blockchain peut être vérifié par quiconque a accès aux en-têtes de blocs Bitcoin — mondialement, sans coordination.

Le troisième élément, une chaîne cryptographique en ajout seul à travers toutes les captures, empêche une entité d’éditer discrètement l’historique. Même avec un accès administratif complet à ses propres systèmes, l’entité ne peut pas insérer une entrée antidatée — chaque maillon de la chaîne dépend de l’empreinte du précédent, et toute modification se propage à travers chaque enregistrement ultérieur. Pour les autorités de contrôle, cela transforme l’intégrité de la preuve d’incident d’une question de confiance en l’entité réglementée en une question de mathématiques. Ce déplacement est ce que défendable signifie réellement.

Incidents transfrontaliers et le réseau des CSIRT de l’UE

Peu d’incidents cyber significatifs respectent les frontières nationales. NIS2 anticipe cela en établissant une architecture de coordination couvrant l’Union : chaque État membre désigne un ou plusieurs CSIRT (équipes de réponse aux incidents de sécurité informatique) et un point de contact unique pour les affaires transfrontalières, qui participent tous au réseau des CSIRT de l’UE aux côtés de l’ENISA. Le réseau européen des organisations de liaison en cas de crise cyber — EU-CyCLONe — coordonne la réponse au niveau stratégique aux incidents à grande échelle. Pour les entités réglementées, cela signifie qu’une notification d’incident soumise au CSIRT national peut rapidement produire une portée dans plusieurs États membres et dans l’ENISA elle-même.

L’article 23(6) prévoit que lorsqu’un incident significatif concerne deux États membres ou plus, le CSIRT ou l’autorité compétente destinataire doit informer les autres États membres affectés et l’ENISA sans retard indu. L’article 23(9) exige des points de contact uniques qu’ils soumettent des rapports agrégés anonymisés à l’ENISA tous les trois mois, et l’ENISA fait rapport au groupe de coopération et au réseau des CSIRT tous les six mois. L’effet pratique est qu’une entité opérant dans plusieurs États membres ne peut pas s’attendre à garder un incident confiné au régulateur d’une seule juridiction — l’architecture est conçue pour partager l’information à travers l’Union.

Pour l’entité réglementée, deux conséquences opérationnelles s’ensuivent. Premièrement, la preuve soutenant la notification d’origine doit être portable à travers les juridictions. Un CSIRT d’un État membre peut demander des informations supplémentaires, des CSIRT d’États membres supplémentaires peuvent faire des demandes parallèles, et l’ENISA peut demander une contribution à ses rapports de synthèse. Un paquet de preuve qui satisfait un régulateur doit satisfaire tous, ce qui signifie qu’il doit être autonome, vérifiable indépendamment, et non dépendant de la disponibilité ou de la volonté continue de l’entité à produire des informations supplémentaires. Deuxièmement, l’entité doit comprendre quel CSIRT national est le premier point de contact approprié — généralement le CSIRT de l’État membre de l’établissement principal de l’entité dans l’Union, mais avec des variations sectorielles.

La coordination transfrontalière s’étend aussi au-delà de l’architecture propre à NIS2. Les CSIRT sont tenus de partager l’information avec les autorités compétentes au titre de la directive CER ((UE) 2022/2557) pour les entités identifiées comme entités critiques, et la relation entre NIS2 et le GDPR (règlement (UE) 2016/679) signifie que les notifications de violation de données personnelles au titre de l’article 33 du GDPR peuvent se dérouler sur une voie parallèle. La preuve préservée avec une intégrité vérifiable satisfait tout cela simultanément ; la preuve reconstruite de mémoire ne satisfait aucun d’eux.

État de transposition dans les 27 États membres (mai 2026)

Dix-huit mois après l’échéance formelle de transposition du 17 octobre 2024, le tableau à travers l’Union s’est substantiellement clarifié. Selon le suivi de transposition de l’Organisation européenne de cybersécurité (ECSO), en mars 2026, vingt et un des vingt-sept États membres ont achevé la transposition. Les autres — France, Irlande, Luxembourg, Pologne, Espagne et Bulgarie — sont à divers stades avancés du processus législatif, avec une adoption attendue au cours de 2026.

Parmi les achèvements récents, plusieurs méritent une attention particulière pour les organisations opérant à travers plusieurs juridictions. La loi de transposition NIS2 de l’Allemagne a été achevée en décembre 2025, et est appliquée via le BSI comme autorité compétente. La loi suédoise sur la cybersécurité et l’ordonnance qui l’accompagne sont entrées en vigueur le 1er janvier 2026. Le Zákon o kybernetické bezpečnosti de la République tchèque a commencé à s’appliquer à partir du 1er novembre 2025, supervisé par le NÚKIB. La loi NISG 2026 de l’Autriche entre en vigueur le 1er octobre 2026, bien que la transposition soit déjà formellement complète. Le projet final du Portugal entre en vigueur en avril 2026.

Le 7 mai 2025, la Commission européenne a émis des avis motivés à dix-neuf États membres, les avertissant formellement que la saisine de la Cour de justice était l’étape suivante. En mai 2026, la plupart de ces dix-neuf États ont soit transposé, soit sont proches de le faire, mais pour les retardataires restants la pression juridique s’est intensifiée. Les amendements de janvier 2026 de la Commission à NIS2 elle-même — proposant une simplification du langage de conformité pour environ 28 700 entités dont 6 200 micro et petites entreprises — accompagnent plutôt qu’ils ne remplacent l’effort d’application. Les amendements rendent la conformité plus réalisable ; ils ne la retardent pas.

Pour les entités multi-juridictionnelles, l’implication pratique est que les États membres ayant transposé opèrent pleinement sur leurs lois NIS2 nationales, tandis que les États membres n’ayant pas encore transposé sont soumis à l’effet direct de la directive à certains égards et à l’action pendante de la Commission au titre de l’article 258 du TFUE. Une entité opérant simultanément dans les deux groupes a besoin d’une posture de réponse aux incidents qui satisfait la transposition applicable la plus stricte tout en étant adaptable à quelle que soit la transposition qui émerge dans les juridictions restantes. L’hypothèse de base devrait être que les 27 États membres seront pleinement opérationnels d’ici fin 2026 au plus tard.

Il vaut aussi la peine de noter que plusieurs États membres ont utilisé la transposition nationale pour étendre NIS2 au-delà de son champ d’application minimum. L’Italie et la Slovénie ont ajouté des secteurs. La Belgique a ajouté des obligations de gouvernance et de surveillance renforcées. Le projet de loi pendant de la France a inclus des déclencheurs d’événements sectoriels spécifiques pour l’énergie et la banque avec des délais de notification plus courts que la référence de 24 heures. Les entités multi-juridictionnelles ne devraient pas supposer que le texte seul de la directive est une orientation suffisante — la transposition nationale est le document opérationnel, et les écarts entre États membres peuvent être significatifs.

Sanctions et responsabilité personnelle des dirigeants

Les pénalités financières au titre de NIS2 sont calibrées pour être conséquentes au niveau du conseil d’administration, pas absorbables comme un coût d’exploitation. Pour les entités essentielles, l’article 34 fixe l’amende administrative maximale à 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial total de l’entité au cours de l’exercice précédent, le plus élevé des deux. Pour les entités importantes, le plafond est de 7 millions d’euros ou 1,4 % du chiffre d’affaires mondial, le plus élevé des deux. Les États membres peuvent — et plusieurs l’ont fait — ajouter des pénalités nationales par-dessus ces minimums de l’UE.

Ces chiffres se situent aux côtés d’autres régimes réglementaires qui peuvent s’appliquer au même incident. Les pénalités de niveau 2 du GDPR atteignent 20 millions d’euros ou 4 % du chiffre d’affaires mondial. DORA, applicable aux entités financières, inclut des astreintes périodiques jusqu’à 1 % du chiffre d’affaires quotidien mondial moyen de l’entité. Un seul incident de rançongiciel affectant une entité essentielle qui traite des données personnelles pourrait plausiblement déclencher des pénalités au titre de NIS2, du GDPR, et (pour les entités du secteur financier) de DORA simultanément — chaque régulateur évaluant son propre composant indépendamment.

Plus frappant que les pénalités financières est le régime de responsabilité personnelle au titre de l’article 20. Les membres des organes de direction des entités essentielles et importantes sont tenus d’approuver les mesures de gestion des risques de cybersécurité prises pour se conformer à l’article 21, de superviser leur mise en œuvre, et de suivre une formation spécifique sur la cybersécurité. Lorsque les organes de direction manquent à ces devoirs — particulièrement par négligence grave — les États membres sont tenus de prévoir la possibilité de tenir les membres individuels de la direction responsables. Plusieurs transpositions nationales ont mis cela en œuvre comme des amendes administratives sur les dirigeants individuels ; d’autres ont mis en œuvre des interdictions temporaires de fonctions de direction.

Les conséquences réputationnelles s’étendent au-delà des pénalités formelles. Le mécanisme de l’avis motivé, le signalement agrégé trimestriel de l’UE à l’ENISA, et les dispositions de notification d’intérêt public de l’article 23(7) signifient que les incidents significatifs — particulièrement ceux mal traités — deviennent des matières d’enregistrement public. Les marchés de la cyber-assurance ont répondu en resserrant les conditions de souscription sur les entités réglementées par NIS2 : les assureurs exigent de plus en plus une capacité documentée de réponse aux incidents, y compris la préservation de preuves forensiques, comme condition préalable à la couverture.

L’effet combiné est que NIS2 a déplacé la cybersécurité de la fonction technique à la fonction de gouvernance. Le conseil est désormais responsable pour la même raison qu’il est responsable du reporting financier : les régulateurs l’ont voulu ainsi. Et comme le reporting financier, le standard de preuve est documentaire. Les assurances verbales du RSSI ne sont pas le standard ; une preuve documentée, datée, à intégrité préservée l’est.

NIS2, DORA, CER et GDPR : obligations qui se chevauchent

NIS2 n’opère pas isolément. Elle se situe au sein d’un ensemble réglementaire — DORA, la directive CER, le GDPR, le Cyber Resilience Act à venir — chacun traitant d’un sujet qui se chevauche sous un angle différent. Pour un seul incident significatif, une entité peut faire face à des obligations simultanées au titre de deux, trois, voire quatre de ces cadres. Comprendre comment ils s’imbriquent est essentiel pour éviter à la fois les lacunes et les efforts dupliqués.

DORA — services financiers, lex specialis

Le Digital Operational Resilience Act (règlement (UE) 2022/2554) est entré en application le 17 janvier 2025 et s’applique aux entités financières dont les banques, entreprises d’investissement, assureurs, prestataires de services sur crypto-actifs, et un large éventail de prestataires tiers de services TIC servant le secteur financier. DORA fonctionne comme lex specialis à NIS2 pour les entités financières dans son champ d’application, ce qui signifie que là où DORA impose des obligations plus spécifiques, elle prévaut. Le signalement d’incidents TIC de DORA au titre de l’article 19 a ses propres délais et définitions de seuil qui sont similaires à NIS2 mais pas identiques.

Directive CER — résilience physique des entités critiques

La directive sur la résilience des entités critiques (directive (UE) 2022/2557) est le pendant physique de NIS2 — traitant de la résilience des entités critiques contre tous les risques, pas seulement le cyber. Les États membres identifient les entités critiques dans onze secteurs largement chevauchant l’Annexe I de NIS2. Une entité peut être soumise à la fois à NIS2 (cybersécurité) et à CER (résilience physique et opérationnelle), et les deux régimes réglementaires partagent l’information au niveau de l’autorité compétente. L’article 23(10) de NIS2 prévoit que les CSIRT doivent informer les autorités compétentes CER des incidents significatifs affectant les entités critiques identifiées par CER.

Article 33 du GDPR — violation de données personnelles

Si un incident significatif NIS2 implique une violation de données personnelles, la notification de l’article 33 du GDPR — à l’autorité de protection des données dans les 72 heures de la prise de connaissance — se déroule en parallèle. Les horloges sont similaires mais les déclencheurs sont différents : NIS2 se déclenche sur un impact opérationnel significatif ; le GDPR se déclenche sur un risque pour les droits et libertés des personnes concernées. Une entité peut avoir besoin de déposer les deux, et la preuve sous-tendant les deux doit être préservable sous une forme qui satisfait les exigences applicables les plus strictes. Certains États membres ont établi des points d’entrée uniques pour les deux rapports ; cela ne change pas les obligations substantielles.

Cyber Resilience Act — produits comportant des éléments numériques

Le Cyber Resilience Act (règlement (UE) 2024/2847) est entré en vigueur le 10 décembre 2024 et s’applique intégralement à partir du 11 décembre 2027. Le CRA traite de la cybersécurité des produits comportant des éléments numériques — matériel et logiciel mis sur le marché de l’UE — et inclut des obligations pour les fabricants de signaler les vulnérabilités activement exploitées et les incidents graves impliquant la sécurité de leurs produits. Les fabricants de produits dans le champ d’application qui sont aussi des entités réglementées par NIS2 devront gérer le signalement d’incidents CRA et NIS2 sur des voies parallèles une fois que le CRA deviendra pleinement applicable.

Bâtir des pistes d’audit que votre autorité de contrôle acceptera

Une notification d’incident est un document dans un corpus probant bien plus large qu’une autorité de contrôle peut examiner lors des inspections NIS2. Les entités essentielles au titre de l’article 32 font face à des inspections proactives — sur site et hors site — et les autorités sont explicitement habilitées à exiger des audits de sécurité, des analyses de vulnérabilité, et l’accès aux données et à la documentation pertinentes. Les entités importantes au titre de l’article 33 font face à des inspections déclenchées par des indications de non-conformité, mais une fois déclenchée, la portée est tout aussi large. La qualité de la piste d’audit d’une entité détermine comment ces inspections se concluent.

Les autorités posent typiquement trois catégories de questions. Premièrement, la gouvernance : l’organe de direction a-t-il approuvé les mesures de l’article 21, a-t-il supervisé la mise en œuvre, a-t-il achevé la formation requise, les procès-verbaux de réunion sont-ils documentés et datés ? Deuxièmement, technique : les dix mesures de gestion des risques de l’article 21 ont-elles été mises en œuvre de manière appropriée et proportionnée, existe-t-il des contrôles documentés, ont-ils été testés, des journaux existent-ils ? Troisièmement, spécifique à l’incident : pour chaque incident significatif, l’alerte précoce de 24 heures a-t-elle été envoyée, la notification de 72 heures soumise, le rapport final d’un mois déposé, et l’entité peut-elle produire la preuve sous-tendant chacun ?

Le mode de défaillance récurrent lors des inspections NIS2 n’est pas l’absence de documentation — la plupart des entités réglementées produisent des politiques et procédures volumineuses. La défaillance est l’absence de preuve à intégrité préservée pour les actions entreprises. Documents de politique datés arbitrairement, fichiers de journaux récupérables mais trivialement modifiables, rapports d’incident déposés mais les artefacts de capture sous-jacents depuis longtemps écrasés — ce sont les schémas qui attirent l’attention en matière d’application. Le remède n’est pas plus de documentation, mais une documentation dont l’intégrité est vérifiable indépendamment.

La vérifiabilité indépendante est le standard le plus élevé. Elle signifie que tout tiers — une autorité de contrôle, un expert nommé par le tribunal, un cyber-assureur, l’avocat adverse en contentieux — peut vérifier l’intégrité de la preuve de l’entité en utilisant seulement la preuve elle-même et des outils de vérification disponibles publiquement. C’est le principe de conception derrière le format ZIP de preuve de GetProofAnchor et l’outil en ligne de commande gpa-verify sous licence MIT publié sur PyPI : l’entité réglementée remet le ZIP, et le destinataire peut le vérifier hors ligne, dans son propre environnement Python isolé, sans aucune dépendance à l’entité ou à GetProofAnchor. Que l’entité adopte ou non cet outil spécifique, le principe sous-jacent devrait être : concevez votre pipeline de preuve de sorte que le vérificateur n’ait pas à faire confiance au producteur.

La conservation à long terme est le corollaire. NIS2 ne prescrit pas de période de conservation spécifique, mais les orientations techniques de l’ENISA et plusieurs transpositions nationales indiquent que douze mois est une référence sensée pour les journaux de routine, avec des extensions sectorielles spécifiques pour les catégories de preuves à plus haut risque. Pour les captures forensiques de preuves web liées à un incident, la conservation devrait s’étendre au délai de prescription de toute procédure en aval raisonnablement anticipée — administrative, civile, ou pénale — qui peut aller jusqu’à sept ans ou plus.

Liste de contrôle des preuves d’incident NIS2 (15 points)

La liste de contrôle suivante consolide les enseignements pratiques de ce guide. Elle n’est pas un substitut à un conseil juridique ou aux orientations spécifiques de votre autorité nationale compétente, mais elle capture les priorités opérationnelles qui distinguent les entités NIS2 bien préparées de celles qui ne le sont que sur le papier.

• Déterminez votre classification NIS2 (essentielle, importante, ou hors champ d’application) au titre de la transposition de votre État membre, et documentez la détermination avec une justification à l’appui.
• Identifiez votre CSIRT national et votre autorité compétente, établissez des canaux de communication pré-incident, et obtenez des modèles pour l’alerte précoce de 24 heures, la notification de 72 heures, et le rapport final d’un mois.
• Définissez des critères de classification internes pour l’incident significatif alignés sur l’article 23(3) et, le cas échéant, les seuils du règlement d’exécution 2024/2690 de la Commission — et révisez-les au moins annuellement.
• Assurez une capacité de détection 24/7 pour que l’horloge de 24 heures puisse démarrer au moment de la prise de connaissance, indépendamment des heures ouvrables ou des week-ends.
• Désignez un responsable principal du signalement d’incidents et au moins un adjoint avec pleine autorité pour déposer les notifications, afin d’éliminer les points uniques de défaillance dans la chaîne de signalement.
• Mettez en œuvre une journalisation infalsifiable avec des primitives d’intégrité documentées (chaînes d’empreintes, horodatages qualifiés, ou équivalent) et une conservation d’au moins 12 mois comme référence.
• Pour tout artefact d’incident orienté web — pages de hameçonnage, sites défigurés, sites de fuite, fausses interfaces de connexion — établissez une procédure de capture forensique qui produit une preuve à horodatage qualifié eIDAS au moment de la détection.
• Liez les artefacts de capture ensemble par des manifestes cryptographiques (SHA-256 sur tous les fichiers) et soumettez l’empreinte du manifeste à un prestataire de services de confiance qualifié eIDAS pour un horodatage électronique qualifié au titre de l’article 42 du règlement (UE) 910/2014.
• Ancrez les paquets de preuve indépendamment — par exemple, via la blockchain Bitcoin par OpenTimestamps — de sorte que l’intégrité puisse être vérifiée sans dépendance à l’entité ou à un quelconque prestataire de services de confiance unique.
• Documentez la chaîne de preuve conformément aux phases de l’ISO/IEC 27037:2012 (identification, collecte, acquisition, préservation), avec les rôles, horodatages, et actions enregistrés pour chaque étape.
• Formez l’organe de direction sur les obligations de l’article 20 de NIS2, y compris l’approbation des mesures de l’article 21 et la supervision de la mise en œuvre ; documentez la formation avec des registres de présence datés.
• Cartographiez le chevauchement entre NIS2 et les autres réglementations applicables (GDPR, DORA, directive CER, cadres sectoriels spécifiques) pour éviter à la fois les lacunes et les notifications dupliquées, et documentez la cartographie.
• Établissez des procédures de preuve de chaîne d’approvisionnement pour que les incidents impliquant des services tiers puissent être capturés contre l’état du tiers au moment de la prise de connaissance, avant que le tiers ne remédie.
• Menez au moins un exercice sur table par an simulant le calendrier complet de l’article 23, y compris la capture de preuves, l’escalade interne, la notification au CSIRT, et la communication aux destinataires de services.
• Rendez tous les paquets de preuve vérifiables indépendamment par des tiers — autorités de contrôle, tribunaux, assureurs, conseils — à l’aide d’outils open source et sans dépendance à l’infrastructure de l’entité productrice.

Questions fréquentes et conclusion

Les réponses suivantes traitent les questions qui surgissent le plus souvent lorsque les organisations commencent à opérationnaliser leurs obligations de traitement des preuves NIS2. Elles sont destinées comme orientation pratique, pas comme conseil juridique pour une situation spécifique.

L’application de NIS2 en 2026 n’est pas hypothétique. La période de grâce est terminée, la transposition est largement achevée, et les autorités de contrôle à travers l’Union passent de la phase de construction du cadre à la phase d’application du cadre. Pour les entités réglementées, le test pratique n’est plus de savoir si des documents de politique existent — presque tout le monde en a — mais si une preuve peut être produite sous l’horloge de l’article 23 et vérifiée par des tiers indépendants.

Les capacités qui distinguent les entités NIS2 bien préparées ne sont pas exotiques. Ce sont la détection, la classification, la préservation forensique des artefacts d’incident, la chaîne de preuve documentée, la rétention de journaux à intégrité préservée, et une posture de gouvernance au niveau du conseil qui peut être démontrée à un superviseur. Chacune de celles-ci est réalisable avec des outils existants et des normes existantes. Le facteur décisif est de savoir si elles sont en place avant l’incident — car une fois que l’horloge de 24 heures démarre, le temps pour la construction de capacité est terminé.

GetProofAnchor existe pour rendre le composant de préservation forensique de cette pile — spécifiquement les artefacts orientés web qui disparaissent le plus vite dans les moments suivant la détection — simple, défendable, et vérifiable indépendamment. Si votre organisation bâtit sa capacité de traitement des preuves NIS2 et aimerait voir comment la capture web forensique à horodatage qualifié s’intègre à vos procédures de réponse aux incidents, la façon la plus directe est de créer une preuve d’exemple à partir de toute URL publique et d’inspecter le ZIP de preuve. La vérification est open source et fonctionne sur tout ordinateur portable. Le standard est reproductible parce qu’il doit l’être.