Gouvernance
démontrable

Le constat de départ est que les systèmes d’information modernes doivent répondre simultanément à des exigences métier, de sécurité, de gouvernance des données, de conformité, de résilience, d’exploitation et de souveraineté. Ces exigences sont généralement définies par des acteurs différents, selon des cycles de vie distincts, puis traduites de manière plus ou moins spécifique dans les applications. Il en résulte une fragmentation des responsabilités, une forte dépendance vis-à-vis des équipes de développement et une difficulté persistante à démontrer que les politiques définies par l’organisation ont effectivement été appliquées.

Le livre blanc propose de passer d’une gouvernance essentiellement déclarative à une gouvernance démontrable. Son principe consiste à transformer progressivement les politiques organisationnelles en actions et contrôles techniques exécutables. Ces actions et contrôles produisent des preuves vérifiables ; les preuves permettent d’établir des garanties ; l’accumulation de garanties permet enfin de construire la confiance. La confiance n’est donc pas considérée comme une propriété accordée a priori à une application, une infrastructure ou une identité, mais comme la conséquence de propriétés qui peuvent être démontrées au moment où elles sont nécessaires.

La logique métier demeure volontairement séparée des mécanismes de gouvernance. Un traitement métier se concentre sur sa finalité fonctionnelle — obtenir des données, les transformer et publier un résultat — tandis que des mécanismes spécialisés prennent en charge les contrôles et actions imposés par la gouvernance. Cette séparation permet aux politiques de sécurité, de données, d’exploitation ou de stratégie d’évoluer indépendamment du code métier et de leurs cycles de développement.

Une première famille de garanties porte sur les données. Le livre blanc propose notamment de vérifier leur intégrité et, lorsque cela est possible, leur authenticité au moyen de signatures numériques ; de formaliser leur structure par des Contrats de Données ; de valider leur conformité avant traitement ; puis de séparer leur représentation logique de leur représentation physique. Le métier manipule ainsi des abstractions standardisées plutôt que des fichiers, tables SQL, documents JSON ou autres formats de stockage directement. Cette normalisation et la dénormalisation correspondante réduisent le couplage avec les technologies de stockage et de transport et contribuent à la portabilité et à la souveraineté du système d’information.

Cette notion de confiance dans la donnée est étendue à son cycle de vie. Le contrôle effectué au moment d’un traitement ne protège pas une donnée pendant les périodes où elle demeure stockée. L’approche distingue donc les contrôles liés à l’exécution des contrôles patrimoniaux, qui peuvent être réalisés périodiquement afin de vérifier l’intégrité de données conservées sur des supports modifiables. Cette fréquence peut être adaptée selon la nature des données et les propriétés d’immutabilité du stockage.

Une deuxième famille de garanties concerne la confiance dans l’exécution. L’objectif n’est pas de prétendre qu’un logiciel est exempt de défauts, mais de vérifier que le composant exécuté correspond bien à celui qui a été approuvé et que ses capacités techniques sont compatibles avec les politiques applicables. À cette fin, le livre blanc introduit le Manifeste de Comportement (Behavior Manifest), produit à partir d’une analyse du composant et décrivant notamment les bibliothèques utilisées, espaces de noms, accès au système de fichiers ou au réseau, réflexion, P/Invoke, création de processus ou autres capacités techniques jugées pertinentes. Ce manifeste signé devient la référence du comportement autorisé et peut être recalculé et comparé avant chargement du traitement.

L’exécution est coordonnée par un Orchestrateur de Garanties, qui ne pilote pas la logique métier elle-même mais la construction de la confiance nécessaire à son exécution. Des Contrôleurs de Garanties vérifient des propriétés spécifiques et produisent les preuves correspondantes ; des Gestionnaires de Ressource assurent les interactions avec les ressources externes ; les changements d’état et les preuves produites permettent de tracer et, lorsque cela est possible, de reprendre une transaction après interruption.

Le traitement métier n’est ainsi exécuté que lorsque les garanties requises à l’étape considérée ont été établies. Cette posture conduit au principe de « refus de service à l’exécution incontrôlée » : lorsqu’une garantie obligatoire ne peut être démontrée, l’exécution peut être interrompue plutôt que poursuivie dans des conditions de confiance inconnues. Cette règle reste une décision de gouvernance et peut dépendre des politiques de l’organisation.

L’approche repose également sur des descriptions déclaratives indépendantes. La Définition du Processus Métier décrit ce que le traitement doit réaliser et les ressources qu’il utilise, tandis que la Définition du Pipeline de Garanties décrit les actions, contrôles, ressources et preuves nécessaires pour gouverner son exécution. Les Contrats de Données, manifestes de comportement et autres artefacts possèdent eux aussi leurs propres cycles de vie. Une transaction correspond ainsi à la convergence de plusieurs artefacts indépendamment versionnés, dont les versions exactes sont enregistrées dans son contexte d’exécution.

Cette séparation permet de considérer le moteur d’exécution non comme l’implémentation d’une politique donnée, mais comme l’interprète de politiques déclaratives. Une politique peut évoluer sans modifier la logique métier ; inversement, une évolution fonctionnelle ne nécessite pas nécessairement de modifier la politique de gouvernance. Le modèle vise ainsi à réduire le couplage entre les responsabilités et à préserver l’autonomie des équipes concernées.

Le livre blanc introduit également la notion d’Assurance Qualité d’Exécution. Contrairement à l’assurance qualité traditionnelle, réalisée principalement avant le déploiement, celle-ci vérifie les conditions réelles de chaque transaction : version du traitement exécuté, disponibilité des contrats applicables, application du pipeline de gouvernance, succès des contrôles obligatoires et production des preuves attendues. Elle ne cherche pas à établir que la décision métier est correcte, mais à démontrer qu’elle a été produite dans les conditions déclarées et approuvées.

Les preuves produites ne servent pas uniquement à l’audit. Parce qu’elles relient chaque transaction aux versions exactes des traitements, contrats, politiques, contrôles et autres artefacts qui l’ont gouvernée, elles constituent progressivement une source de connaissance sur le système d’information.

Les descriptions déclaratives deviennent ainsi des actifs de connaissance. Elles peuvent être exploitées pour analyser les dépendances, étudier les impacts d’une évolution, comparer des politiques, vérifier les contrôles applicables ou identifier les éléments affectés par une modification. Le système d’information contribue alors à produire sa propre documentation à partir d’artefacts nécessaires à son fonctionnement, plutôt qu’à dépendre exclusivement d’une documentation maintenue séparément.

L’accumulation de ces relations entre traitements, données, politiques, contrôles, artefacts et exécutions peut donner naissance à un Graphe de Connaissances d’Entreprise. Celui-ci permet notamment d’interroger les dépendances entre processus et contrats de données, de retrouver les politiques ayant gouverné une transaction ou d’évaluer les impacts d’un changement proposé. Cette connaissance est une propriété émergente des descriptions déclaratives et des preuves qui les relient.

Cette capacité contribue également à la cyber-résilience. Une organisation ne doit pas seulement être capable de restaurer des composants techniques ; elle doit connaître les fonctions critiques, leurs dépendances et les conditions nécessaires à leur restauration dans un état de confiance. La production automatique de connaissances sur les fonctions, les dépendances et les garanties peut ainsi faciliter l’analyse d’impact et la reconstruction après incident.

La souveraineté est abordée sous un angle plus large que la seule localisation des infrastructures ou des données. L’objectif est de préserver la capacité de l’organisation à maîtriser et faire évoluer sa logique métier, ses données, ses politiques, ses preuves et les connaissances qui décrivent son système d’information. L’approche ne supprime pas les dépendances technologiques, mais cherche à les identifier, à les isoler et à réduire leur impact sur les fonctions métier afin de faciliter leur remplacement.

Enfin, la gouvernance démontrable n’est pas présentée comme un produit ni comme une transformation « tout ou rien ». Le livre blanc propose une adoption progressive : commencer par formaliser les traitements et les contrats, rendre les artefacts vérifiables par signature, caractériser les comportements, introduire progressivement des contrôles d’exécution et produire des preuves. Chaque garantie supplémentaire vise à réduire l’incertitude et chaque preuve supplémentaire à accroître le niveau de confiance disponible pour l’organisation.

En synthèse, le livre blanc propose une architecture dans laquelle la confiance n’est ni présumée ni fournie par un composant unique. Elle résulte de l’assemblage d’engagements indépendamment gouvernés, de leur vérification au cours de l’exécution et de la conservation des preuves démontrant qu’ils ont été respectés. L’exécution métier devient ainsi simultanément un processus de transformation fonctionnelle et un processus de production de preuves de gouvernance.