# NIS2 et DORA : ce que l’exploitation IT doit pouvoir prouver · Stilla > Les deux réglementations posent la même question : savez-vous quels services sont impactés par une interruption, qui en est responsable et qu'est-ce qui a… URL: https://stratum.eywo.digital/fr/blog/nis2-dora-evidence/ Language: fr Last updated: 2026-10-25 [← Retour au blog](https://stratum.eywo.digital/fr/blog/) Gouvernance25 octobre 20263 min luÉquipe Eywo # NIS2 et DORA : ce que l’exploitation IT doit pouvoir prouver Les deux réglementations posent la même question : savez-vous quels services sont impactés par une interruption, qui en est responsable et qu'est-ce qui a changé et quand ? Sans cartographie des dépendances fiable, les réponses sont compilées manuellement, souvent sous pression de temps. C'est vendredi après-midi et une panne de stockage a frappé plusieurs systèmes. Outre la restauration du service, une deuxième horloge est maintenant en marche : si cela constitue un incident majeur, il doit être signalé dans un délai court. Quelqu'un pose la question : « Quels services ont été touchés, combien d'utilisateurs, et à quel point sont-ils critiques ? » La réponse est reconstituée à partir de la supervision, d'un tableur de services et de la mémoire de collègues expérimentés. Les mêmes questions reviennent lors d'une inspection – seulement plus tard, et avec une demande de preuves. ## Ce que les réglementations exigent NIS2 et DORA diffèrent dans leur portée et leurs autorités de contrôle, mais d'un point de vue des opérations informatiques, les mêmes exigences reviennent : - **connaître l'impact** d'une panne sur les services et leur criticité, - **signaler les incidents majeurs** dans des délais définis et avec des preuves suffisantes, - **gérer les changements et les vulnérabilités** et être en mesure de montrer qui a approuvé quoi, - **garder une vue d'ensemble des services et des fournisseurs ICT** dont les opérations dépendent, - **retracer la responsabilité** – qui est propriétaire du service et qui a changé quoi, quand. Aucune de ces exigences n'est nouvelle. Ce qui est nouveau, c'est la pression pour que les réponses soient rapides, complètes et prouvables. ## Ce que Stilla couvre aujourd'hui La fondation des réponses réglementaires est les données que Stilla conserve pour les opérations quotidiennes : - **Une cartographie des dépendances** du service métier à l'infrastructure et au calcul de l'impact qui prend en compte la redondance – clusters, réplication de bases de données, stockage miroir. - **Un propriétaire pour chaque service**, rôles définis et une matrice RACI que Stilla vérifie par rapport aux autorisations. - **Un historique de vérification immuable** pendant cinq ans ; pour la configuration, l'état avant et après un changement est stocké. - **Des changements gérés** approuvés par le propriétaire du service affecté, fenêtres de maintenance et gel des changements. - **Des contrats de service et des SLA de fournisseur**, y compris l'escalade des incidents au fournisseur selon le contrat. - **Des vulnérabilités par service** avec des délais par gravité, distinguant les failles activement exploitées. Lorsqu'un incident se produit, Stilla montre les services affectés à partir de la cartographie des dépendances, et non à partir d'une estimation. Le propriétaire du service peut être retrouvé, et l'historique des changements montre ce qui a changé ces derniers jours. ## Ce qui est en préparation En plus de ces données, nous construisons des sorties réglementaires qui ne font pas encore partie du produit : - **Classification des incidents majeurs** selon les critères NIS2 et DORA, dérivée de l'impact dans la CMDB, - **Un rapport pré-rempli** avec chronologie et impact, - **Un registre des services et des fournisseurs ICT** sous DORA. Le principe restera le même que dans le reste du produit : Stilla prépare les preuves, une personne décide et soumet toujours. Nous confirmerons la synchronisation de la sortie avec les clients pilotes. ## Où commencer Une réponse réglementaire n'est aussi bonne que les données qui la sous-tendent. C'est pourquoi nous recommandons de commencer là où cela rapporte même sans réglementation : avec les services clés, leurs propriétaires et la cartographie des dépendances. Celui qui a cela en ordre a la plupart du travail fait – et un vendredi après-midi, des réponses à partir de données, et non de la mémoire. Stilla ne remplace pas l'évaluation juridique. Examinez les obligations spécifiques de votre organisation avec votre équipe de conformité. **Stilla Standard** Pour les organisations qui souhaitent une CMDB fiable et des processus ITSM gérés. [Comparer les éditions →](https://stratum.eywo.digital/fr/editions/) ## Plus d'articles [Gouvernance·8 octobre 2026 ### Audit et réglementation : une responsabilité que vous pouvez prouver Un auditeur ne demande pas si vous avez un processus, mais si vous pouvez montrer qui a fait quoi, quand, et qui a approuvé cela. Voici comment avoir les réponses prêtes avant que la question ne se pose. Standard4 min lu](https://stratum.eywo.digital/fr/blog/audit-and-accountability/)[Gouvernance·17 septembre 2026 ### Plateforme partagée, données client séparées Un fournisseur de services partagés a besoin d'une plateforme pour chaque client, tandis que chaque client souhaite ne voir que ses propres serveurs, incidents et coûts. Voici comment avoir les deux sans compromettre la sécurité. Enterprise4 min lu](https://stratum.eywo.digital/fr/blog/shared-platform-separated-data/)[Gouvernance·25 juin 2026 ### Qui est le propriétaire de ce service ? Une responsabilité que vous pouvez suivre Lorsque personne n'est certain d'être responsable d'un service, les changements sont retardés, les incidents sont renvoyés entre les équipes et les approbations sont bloquées. La propriété claire est le fondement sur lequel repose le reste des opérations. Standard4 min lu](https://stratum.eywo.digital/fr/blog/who-owns-the-service/)