Gouvernance d'architecture, conformité DORA & NIS2 : le guide

Modèle opératoire de gouvernance

La gouvernance doit être conçue comme un service qui améliore la qualité et la vitesse de décision, pas comme un rituel de revue.

Un modèle mature combine droits de décision explicites, profondeur de revue par niveau de risque et suivi transparent des outcomes.

• Créer des niveaux de risque avec autorités d'approbation explicites
• Standardiser les records de décision avec rationale et trade-offs
• Suivre les exceptions avec date d'expiration et plan de remédiation

La gouvernance rend l'architecture défendable

La plupart des équipes savent tracer un schéma. Bien moins savent prouver, des mois plus tard, pourquoi une décision a été prise, qui l'a approuvée, quelles applications soutiennent un service critique, et comment ces applications dépendent les unes des autres. C'est dans cet écart que les audits s'enlisent et que les revues réglementaires deviennent inconfortables.

La gouvernance d'architecture comble cet écart. C'est l'ensemble des instances, des enregistrements et des règles qui maintiennent votre architecture honnête dans le temps — et, effet utile, elle produit la documentation et la preuve qu'attendent des cadres comme DORA et NIS2. Ce guide parcourt les rouages et la place de chaque réglementation.

Un avertissement d'emblée, car il compte : rien ici ne vous rend légalement conforme. La conformité DORA et NIS2 est appréciée par les régulateurs et auditeurs au regard de vos mesures organisationnelles, contractuelles et de sécurité. Une pratique de gouvernance et un outil vous aident à documenter et prouver ce que vous faites ; ils ne remplacent pas le travail juridique, risque et sécurité.

Le comité d'architecture (ARB)

L'ARB est l'instance de décision. Les changements significatifs — une nouvelle application cœur, une intégration majeure, un nouveau modèle d'hébergement — sont revus au regard de principes d'architecture convenus avant d'être engagés. Le but n'est pas la bureaucratie ; c'est de détecter les enjeux de risque, de sécurité et de résilience tant qu'ils sont encore peu coûteux à corriger.

Un ARB ne se justifie que s'il reste léger et régulier : un périmètre clair de ce qui doit être revu, un noyau de membres restreint, et une cadence alignée sur les rythmes de livraison plutôt que les bloquant. Archilu le soutient avec des flux de revue et d'approbation structurés, afin que les décisions du comité soient saisies au moment où elles sont prises, et non reconstruites après coup.

Décisions tracées : la piste d'architecture

Une décision tracée consigne, pour chaque choix significatif, le contexte, les options envisagées, la décision retenue et la justification. Bien faite, elle répond à la question d'audit la plus difficile — « pourquoi est-ce ainsi ? » — sans fouiller dans les boîtes mail et les vieux supports.

Dans Archilu, les décisions sont des objets de premier rang liés aux applications, capacités et politiques qu'elles affectent. Ce lien transforme une liste de décisions en une piste navigable : un auditeur peut passer d'un service métier critique aux applications qui le soutiennent, puis aux décisions qui les ont façonnées, en quelques clics.

Politiques et principes comme contraintes vivantes

Les principes énoncent ce qui est souhaitable (« privilégier les services hébergés en UE pour les données personnelles ») ; les politiques transforment les principes en règles testables. La valeur vient du rattachement au modèle : quand une politique est liée aux applications et décisions qu'elle gouverne, vous voyez où vous êtes conforme et où vous avez accepté des exceptions documentées.

C'est aussi là que la gouvernance devient proactive plutôt que punitive. Une politique avec un propriétaire clair et une liste d'exceptions visible est un outil que les équipes utilisent pour mieux décider, pas une checklist qu'on impose après coup.

Le registre des applications

Le registre des applications est la colonne vertébrale. C'est l'inventaire faisant autorité des applications qui soutiennent vos services métier, chacune avec un propriétaire, une criticité, des informations d'hébergement et un statut de cycle de vie. Les régulateurs de la finance et, au titre de NIS2, des secteurs essentiels et importants attendent que vous sachiez quels actifs IT sous-tendent vos fonctions critiques ; le registre est votre réponse.

Le choix de conception décisif est que le registre soit le même modèle que vos architectes, vos équipes finance et risque utilisent déjà — pas un artefact parallèle reconstruit à chaque audit. Quand le registre est vivant, il reste à jour à mesure que les applications sont ajoutées, retirées ou changent de propriétaire, au lieu de dériver vers le tableur qu'il remplaçait.

• Propriétaire, criticité et statut de cycle de vie pour chaque application
• Hébergement et résidence des données pour les questions de localisation
• Liens vers les services métier et capacités que chaque application soutient
• Maintenu en continu, pas reconstruit à chaque audit

Cartographie des dépendances IT

Connaître ses applications est nécessaire mais insuffisant. Les revues de résilience posent une question plus dure : si tel composant, prestataire ou flux de données tombe, quels services critiques sont touchés ? Y répondre exige des dépendances cartographiées — entre applications, entre applications et tiers qui les hébergent ou les alimentent, et entre applications et services métier au-dessus.

Archilu traite ces dépendances comme partie du modèle, de sorte que l'analyse d'impact est une requête plutôt qu'un atelier. Cartographier les dépendances IT est aussi le socle pratique du raisonnement sur les tolérances d'impact et le risque de concentration vers lequel des cadres comme DORA poussent les organisations — là encore, comme documentation et analyse, pas comme verdict de conformité.

Où DORA et NIS2 se situent vraiment

DORA (le règlement européen sur la résilience opérationnelle numérique) vise la résilience IT des entités financières et de leurs prestataires critiques ; NIS2 élargit les obligations de cybersécurité à travers les secteurs essentiels et importants. Les deux s'appuient fortement sur les mêmes faits sous-jacents : vous devez connaître vos actifs IT, vos dépendances et vos fonctions critiques, et savoir montrer votre gouvernance.

La gouvernance d'architecture produit précisément ces faits. Un registre tenu à jour, des dépendances cartographiées, des décisions consignées et une piste d'audit sont la matière première d'une revue de résilience ou de supervision. Mais — et l'avertissement est répété à dessein — la conformité DORA et NIS2 est une appréciation juridique faite par votre régulateur et vos auditeurs au regard de contrôles organisationnels, contractuels et de sécurité. Archilu est une aide à la preuve et à la documentation, pas une garantie de conformité. Associez-le à vos fonctions juridique, risque et sécurité ; la checklist architecture DORA & NIS2 liée est un point de départ pour la documentation côté architecture.

BIAN pour la banque, et faire tenir la gouvernance

Les banques ont une dimension supplémentaire : un modèle de référence partagé aide la gouvernance à passer à l'échelle. BIAN (Banking Industry Architecture Network) fournit un paysage standard de domaines de service pour la banque, maintenu par l'association BIAN. Aligner votre modèle de capacités et d'applications sur une référence de type BIAN rend le registre plus facile à raisonner entre équipes et au regard de la façon dont les superviseurs pensent les fonctions bancaires.

Quel que soit votre secteur, la gouvernance ne tient que si elle vit là où le travail se fait. Le schéma qui marche est de relier l'ARB, les décisions tracées, les politiques et le registre à vos rythmes existants — cycles budgétaires, renouvellements fournisseurs, jalons de transformation — plutôt que de mener un projet de conformité séparé qui se dispute l'attention. Partez de votre situation : l'évaluation gratuite de maturité EA d'Archilu note dix dimensions, dont la gouvernance, et renvoie un plan priorisé en environ dix minutes, et le guide outil de gouvernance et la checklist DORA & NIS2 liés transforment ces principes en prochaines étapes concrètes.

KPIs de gouvernance

Un modèle de gouvernance est crédible seulement s'il produit des décisions plus rapides et meilleures dans le temps.

• SLA revue vers décision par niveau de risque
• Tendance d'ancienneté du backlog d'exceptions
• Taux de rework après décision d'architecture
• Tendance du risque de dépendances transverses

Common mistakes

La gouvernance échoue quand elle renforce le contrôle mais laisse l'ambiguïté de décision.

• Traiter les changements faibles comme les risques élevés
• Ne pas définir les droits de décision par catégorie de risque
• Ne pas fixer de date d'expiration pour les exceptions
• Ne pas mesurer la qualité des arbitrages

Practical checklist

Cette baseline garde une gouvernance utile sans freiner le delivery.

• Définir niveaux de risque et droits de décision associés
• Créer templates de revue et critères d'acceptation
• Fixer des SLA de décision par niveau de risque
• Suivre exceptions, ancienneté et clôture chaque mois