Gouvernance d’architecture, DORA et NIS2 : décisions, inventaires et dépendances

La gouvernance d’architecture et la documentation réglementaire

Un schéma d’architecture se dessine vite. Des mois plus tard, il faut encore dire pourquoi une décision a été prise et qui l’a approuvée. Il faut aussi savoir quelles applications soutiennent un service critique et comment elles dépendent les unes des autres. Sans ces réponses, un audit s’enlise et une revue de supervision se complique.

La gouvernance d’architecture réunit les instances, les enregistrements et les règles qui gardent l’architecture exacte dans la durée. Elle produit une part de la documentation attendue par DORA et NIS2 : fonctions, actifs TIC, dépendances et décisions qui les ont façonnés.

Elle ne rend pas une entité conforme. L’autorité compétente et les auditeurs apprécient la conformité au regard des mesures organisationnelles, contractuelles et de sécurité de l’entité. Un référentiel d’architecture aide à documenter et à prouver ce qui est fait ; le travail des fonctions juridique, risques et sécurité reste entier.

Le comité d’architecture

Le comité d’architecture, ou Architecture Review Board, examine les changements significatifs avant leur engagement : nouvelle application cœur, intégration majeure, nouveau modèle d’hébergement. Il les confronte aux principes adoptés. Les questions de risque, de sécurité et de résilience se traitent alors tant que leur correction coûte peu.

Un comité tient s’il reste léger et régulier : un périmètre d’examen clair, peu de membres permanents, une cadence alignée sur les livraisons. Dans ArchiLU, les instances de décision se composent selon vos règles, chacune avec son mandat. Une instance peut n’avoir qu’un membre, et une personne peut cumuler plusieurs profils.

Le Board d’ArchiLU présente quatre vues : À traiter, Questions, En reprise et Historique. Le dossier d’architecture peut partir d’une demande ou être ouvert de façon autonome. Le Board pose ses questions aux responsables, réexamine les réponses, puis décide avec un motif ou demande une reprise et une nouvelle soumission. La décision est saisie au moment où elle est prise.

Les décisions tracées

Une décision tracée consigne, pour chaque choix significatif, le contexte, les options envisagées, la décision retenue et sa justification. Elle répond à la question d’audit la plus difficile, « pourquoi est-ce ainsi ? », sans recherche dans les messageries et les anciennes présentations.

Dans ArchiLU, le journal des décisions garde chaque décision avec son instance, son décideur, sa date, son issue et son motif. Pour un dossier soumis, la version, la présentation et les arbitrages examinés restent consultables. Une décision inscrite ne se réécrit pas : une autre la remplace, ou l’instance la retire.

Les conséquences d’une décision s’inscrivent dans les principes, les cibles et les éléments concernés ; la demande suivante retrouve ces références. L’auditeur relit chaque décision du board avec son motif. La piste d’audit est chaînée, vérifiable et exportable par l’administrateur. La séparation des tâches est active par défaut, et son retrait est tracé.

L’IA peut préparer une décision ou évaluer une dérogation ; seuls les membres de l’instance tranchent.

Principes, règles et dérogations

Un principe énonce ce qui est souhaitable, par exemple « privilégier des services hébergés dans l’Union européenne pour les données personnelles ». Une règle le rend vérifiable. Rattachés aux applications et aux décisions qu’ils encadrent, principes et règles montrent où l’architecture les respecte et où une dérogation documentée a été acceptée.

Dans ArchiLU, un principe se prépare dans son case et s’applique une fois que le board l’a adopté. Une demande ultérieure s’y confronte : elle respecte le principe, justifie une dérogation ou propose son évolution. Les dérogations ouvertes figurent parmi les constats de l’analyse d’exposition. Quand un principe a un responsable et que ses dérogations restent visibles, les équipes le consultent dès la préparation de leurs options.

L’inventaire des applications et des fonctions

DORA demande aux entités financières d’identifier, de classer et de documenter leurs fonctions métier soutenues par les TIC (article 8). L’obligation couvre aussi les actifs informationnels et les actifs TIC qui soutiennent ces fonctions, et leurs dépendances. La classification se réexamine au moins une fois par an ; les inventaires se mettent à jour périodiquement et à chaque modification importante.

Le registre d’informations de l’article 28 de DORA est un autre document. Il porte sur les accords contractuels de services TIC conclus avec des prestataires tiers. Dans ArchiLU, il se produit comme un rapport réglementaire à partir de la même chaîne.

NIS2 compte la gestion des actifs parmi les mesures de gestion des risques en matière de cybersécurité (article 21). Dans les deux cas, l’inventaire des applications sert de base. Il reste à jour s’il est le modèle que les architectes, la finance et les risques utilisent déjà. Reconstruit pour chaque audit, il redevient le tableur qu’il devait remplacer. Dans ArchiLU, applications et fonctions partagent le même référentiel :

• Responsable, criticité, cycle de vie et fournisseur de chaque application.
• Un catalogue des fonctions avec leur criticité au sens de DORA, leur responsable et les applications qui les servent.
• Les liens de chaque application vers ses capacités, processus, interfaces, technologies et contrats.
• Des objets sans responsable qui restent visibles, et une tâche adressée tous les douze mois à chaque responsable pour confirmer ses objets.

Les dépendances TIC et l’analyse d’exposition

Connaître ses applications ne suffit pas. Une revue de résilience demande ce qui s’arrête si un composant, un prestataire ou un flux de données fait défaut. DORA demande de répertorier les liens et interdépendances entre actifs, et d’identifier les processus qui dépendent de prestataires tiers de services TIC (article 8).

Dans ArchiLU, la chaîne part d’une fonction critique ou importante. Elle suit les processus et capacités liés, les applications, puis les services TIC, les fournisseurs et les contrats documentés. Un rattachement manquant reste visible. La fiche de la fonction montre aussi l’instance déployée, avec sa reprise et sa perte admissible, et le plan de sortie de l’application.

L’analyse d’exposition part d’un prestataire et remonte aux processus et aux fonctions critiques ou importantes qui en dépendent. Elle calcule ses constats : concentration, obsolescence, objets critiques sans responsable, dérogations ouvertes. Chaque constat mène à une demande, à un risque ou à une décision du board.

La stratégie de résilience prévue par DORA détermine la tolérance au risque lié aux TIC et analyse la tolérance à l’incidence des dysfonctionnements (article 6). Avant un accord qui soutient une fonction critique ou importante, l’entité évalue aussi le risque de concentration (articles 28 et 29). Ces appréciations restent à l’entité ; la chaîne documente leur objet.

La place de DORA et de NIS2

Le règlement (UE) 2022/2554, dit DORA, s’applique depuis le 17 janvier 2025 aux entités financières énumérées à son article 2. Il couvre la gestion du risque lié aux TIC, la notification des incidents majeurs, les tests de résilience et le risque lié aux prestataires tiers. Il établit aussi un cadre de supervision des prestataires tiers critiques de services TIC.

La directive (UE) 2022/2555, dite NIS2, vise des entités essentielles et importantes de nombreux secteurs. Les États membres devaient la transposer au plus tard le 17 octobre 2024. Une entité financière peut être identifiée comme essentielle ou importante. DORA est alors l’acte juridique sectoriel au sens de l’article 4 de NIS2 (article 1, paragraphe 2, de DORA).

Les deux textes engagent l’organe de direction. Sous DORA, il définit, approuve et supervise le cadre de gestion du risque lié aux TIC, et répond de sa mise en œuvre (article 5). Sous NIS2, les organes de direction approuvent les mesures de gestion des risques, supervisent leur mise en œuvre et peuvent être tenus responsables (article 20).

DORA demande aussi que la stratégie de résilience décrive l’architecture TIC de référence et les changements nécessaires (article 6, paragraphe 8). Dans ArchiLU, chaque paysage porte l’existant, la cible et une feuille de route datée. L’écart donne à chaque élément son lot de travail et son échéance.

Un inventaire tenu, des dépendances cartographiées, des décisions motivées et une piste d’audit forment la matière d’une revue de résilience ou de supervision. La liste de contrôle DORA et NIS2 aide à recenser la documentation d’architecture à produire.

BIAN pour la banque, et une gouvernance qui dure

Une banque peut aussi s’appuyer sur une référence sectorielle. BIAN, le Banking Industry Architecture Network, publie des modèles de référence ; son Service Landscape organise des Service Domains. Dans ArchiLU, un modèle de secteur, BIAN pour la banque, se charge par le classeur. Les responsables métier examinent ensuite chaque correspondance avec leurs capacités et leurs applications.

La gouvernance tient quand elle suit les rythmes existants : cycles budgétaires, renouvellements de contrats, jalons de transformation. Le comité, les décisions, les principes et l’inventaire s’y rattachent, sans projet de conformité séparé qui disputerait l’attention des équipes.

Dans ArchiLU, la chaîne DORA et l’analyse d’exposition relèvent de l’offre APM & Risk. Les dossiers d’architecture et le board relèvent de l’offre Enterprise Architecture, qui comprend aussi APM & Risk. L’essai d’un mois se fait sur votre instance.