NIS2 et architecture d'entreprise : cartographier les systèmes et dépendances que touche la gestion des risques

Ce que NIS2 attend réellement des entités essentielles et importantes

NIS2 a élargi le filet. Là où son prédécesseur visait un ensemble relativement étroit d'opérateurs, NIS2 fait entrer dans le périmètre une population bien plus large d'entités essentielles et importantes — dans des secteurs comme l'énergie, les transports, la banque et les infrastructures de marché financier, la santé, les infrastructures numériques, l'administration publique et d'autres. Si vous êtes une organisation financière régulée ou une entité critique de l'UE, l'hypothèse de départ réaliste est qu'une partie de NIS2 vous touche, et la qualification précise est à confirmer avec un conseil qualifié.

Sous le texte juridique, la substance est reconnaissable : prendre des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées pour gérer les risques pesant sur vos réseaux et systèmes d'information ; sécuriser votre chaîne d'approvisionnement ; traiter les incidents, y compris notifier les plus significatifs dans des délais définis ; et savoir le démontrer. Cet article est une aide à la préparation et à la documentation, pas un conseil juridique. Ce qu'il montre, c'est où l'architecture d'entreprise donne une colonne vertébrale à ces mesures — car presque chacune présuppose que vous savez réellement voir vos systèmes et la façon dont ils se connectent.

Chaque attente NIS2 repose sur une question préalable : connaissez-vous vos systèmes ?

Gestion des risques, sécurité de la chaîne d'approvisionnement et traitement des incidents sonnent comme des chantiers séparés. Ils partagent un prérequis caché. On n'évalue pas le risque d'un système qu'on n'a pas inventorié. On ne sécurise pas une chaîne d'approvisionnement dont on ne sait pas tracer les prestataires jusqu'aux services qu'ils soutiennent. On ne cadre pas un incident si l'on ignore de quoi dépend le composant touché. La question préalable — connaissez-vous vos systèmes et leurs dépendances — se tient sous tout le régime.

Pour la plupart des organisations, cette connaissance existe, mais dispersée : une CMDB qui a dérivé, des schémas réseau dans un wiki, des listes fournisseurs aux finances, des évaluations de criticité dans une présentation de l'an dernier. Rien ne se relie, et c'est précisément la jointure dont les conversations NIS2 ont besoin. Un référentiel d'architecture d'entreprise est, au fond, l'endroit où ces fils deviennent un seul modèle connecté — les systèmes, les services métier qu'ils soutiennent, les dépendances entre eux, et les tiers derrière eux.

• La gestion des risques présuppose un vrai inventaire des réseaux et systèmes d'information
• La sécurité de la chaîne d'approvisionnement présuppose de tracer les services jusqu'à leurs prestataires
• Le traitement des incidents présuppose de savoir de quoi dépend un composant touché
• Le prérequis commun est une vue connectée et à jour — pas quatre listes déconnectées

Cartographier systèmes et dépendances pour la gestion du risque cyber

L'attente centrale de NIS2 en gestion des risques est d'identifier et de traiter les risques pesant sur vos réseaux et systèmes d'information avec des mesures proportionnées à l'exposition. La proportionnalité a besoin d'un dénominateur : quels systèmes soutiennent quels services essentiels, à quel niveau de criticité, et ce qui serait affecté si l'un tombait. Une liste d'actifs plate ne le dit pas ; un modèle de dépendances le dit.

Dans un référentiel EA, chaque système porte des attributs qui le rendent analysable — propriétaire, criticité, hébergement, technologie sous-jacente — et pointe vers les services métier qu'il soutient et les systèmes dont il dépend. Avec cela en place, vous pouvez poser les questions sur lesquelles tourne vraiment la gestion des risques : si ce composant est compromis, quels services essentiels se dégradent ? Où une seule faiblesse se propage-t-elle le plus loin ? La réserve honnête vaut comme toujours — le modèle ne vaut que par les données que vous y mettez, et les décisions de traitement du risque restent du côté de vos fonctions sécurité et risque. Le référentiel leur donne de la visibilité, pas un verdict.

• Registre des systèmes avec propriétaire, criticité, hébergement et empreinte technologique
• Chaque système relié aux services métier qu'il soutient
• Dépendances cartographiées pour suivre les chemins de propagation
• Un modèle interrogeable qui rend la proportionnalité évaluable, pas devinée

Chaîne d'approvisionnement et relations IT tierces, rendues visibles

La sécurité de la chaîne d'approvisionnement est l'un des points où NIS2 a le plus nettement relevé le niveau. Les entités sont attendues pour prendre en compte la sécurité de leur chaîne d'approvisionnement, y compris les relations avec leurs fournisseurs et prestataires directs, et la qualité des pratiques de sécurité de ces parties. On ne gère pas une exposition qu'on ne voit pas, et l'exposition fournisseur est précisément de celles qui s'accumulent invisiblement : chaque dépendance prise isolément paraissait raisonnable au moment où elle a été nouée.

Un modèle cartographié transforme cette accumulation invisible en quelque chose de dénombrable. Reliez chaque application aux fournisseurs et prestataires derrière elle, puis tracez chaque service essentiel jusqu'à ces tiers. Les amas apparaissent : le prestataire qui se tient derrière une part disproportionnée de ce qui compte, la dépendance que vous n'auriez pas choisie délibérément mais avez héritée. C'est aussi exactement l'analyse qui recoupe le travail DORA sur le risque tiers IT et de concentration — un modèle, deux conversations réglementaires. Pour être clair sur la frontière : le référentiel révèle et documente les relations ; l'évaluation de sécurité d'un fournisseur, et la posture contractuelle autour, restent vôtres.

Traitement des incidents : cadrer le rayon d'impact depuis une carte vivante

Quand quelque chose casse, la vitesse de compréhension compte autant que la vitesse de réponse. Les attentes de NIS2 en traitement et notification des incidents supposent que vous pouvez comprendre vite ce qu'un incident affecte et le communiquer dans des délais définis. Le plus lent n'est souvent pas le correctif technique mais le cadrage — déterminer, sous pression, quels services sont touchés et de quoi ils dépendent.

Un modèle d'architecture à jour escamote cette étape. Tracez le composant touché vers le haut, vers les services métier et essentiels qu'il soutient, et vers le bas, vers les systèmes et fournisseurs dont il dépend, et le rayon d'impact est à l'écran plutôt que dans une tête. Le même modèle rend le compte rendu post-incident défendable : vous montrez, depuis une source versionnée, ce qui était dans le périmètre et pourquoi. Nous sommes précis sur la limite — un référentiel EA soutient le traitement des incidents en fournissant le contexte de dépendances ; il ne détecte pas les incidents et n'effectue pas la réponse. Détection, confinement et reprise vivent dans vos opérations de sécurité, et le modèle d'architecture les alimente plutôt qu'il ne les remplace.

• Tracez le composant touché vers les services essentiels qu'il soutient
• Tracez-le vers le bas, vers les systèmes et fournisseurs dont il dépend
• Cadrez le rayon d'impact depuis un modèle, pas de mémoire sous pression
• Montrez, depuis une source versionnée, ce qui était dans le périmètre — défendable après coup

Pourquoi un référentiel souverain et hébergeable en UE convient spécifiquement

Trois propriétés d'ArchiLU comptent davantage dans un contexte NIS2 que presque partout ailleurs. Il peut être hébergé dans l'UE ou en on-premise, si bien que la carte sensible des systèmes qui soutiennent quels services essentiels — proche d'un plan de vos points les plus vulnérables — ne quitte pas un périmètre que vous contrôlez. Il est disponible nativement en français et en anglais, ce qui compte quand le même modèle doit servir un comité sécurité francophone et un audit ou un échange avec l'autorité en anglais. Et il est licencié pour des utilisateurs illimités, si bien que les personnes des risques, de la sécurité et de l'architecture qui doivent toutes lire la même carte de dépendances ne sont pas bridées par un nombre de sièges ; le détail commercial vit sur la page des tarifs plutôt qu'ici.

La frontière honnête, redite parce qu'elle compte : ArchiLU est un référentiel d'architecture d'entreprise qui produit de la documentation et de la preuve et les rend plus simples à assembler. Ce n'est pas une certification NIS2, pas une bibliothèque de contrôles, et nous restons transparents sur les certifications que nous ne détenons pas encore. Ce qu'il donne à une institution régulée de l'UE, c'est un modèle souverain, multilingue et connecté de ses systèmes et dépendances — le socle sur lequel reposent à la fois les conversations NIS2, DORA et EU AI Act. Pour situer le plus vite votre propre pratique sur les dimensions portefeuille, gouvernance et risque, l'évaluation gratuite de maturité EA note dix dimensions et renvoie un plan priorisé en une dizaine de minutes.