💻 computer science

From Audit Requirements to Computable Software Architecture: A Rule-Engine and Evidence-Indexing Method for Trusted Digital Infrastructure

Cet article propose une méthodologie de moteur de règles et d'indexation de preuves qui comble le fossé sémantique entre les exigences d'audit et l'architecture logicielle en créant un modèle de classification, une matrice de correspondance et un algorithme de vérification afin d'intégrer des contrôles exécutables tôt dans la phase de conception, réduisant ainsi les coûts de remédiation et permettant une infrastructure numérique prête pour l'audit.

Auteurs originaux : Jinyuan Li, Ruijie Ma, Yicheng Gu

Publié 2026-07-02

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Jinyuan Li, Ruijie Ma, Yicheng Gu

Article original sous licence CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous construisez un coffre-fort bancaire massif et hautement sécurisé. Dans l'ancienne méthode, vous construiriez d'abord tout le coffre, y installeriez les portes et les caméras, puis, après qu'il soit terminé, vous engageriez un inspecteur qui dirait : « Oh, au fait, nous avons besoin d'un second verrou sur la porte arrière, et les caméras doivent être connectées à un serveur différent. » Cela conduit à démolir des murs, recâbler et effectuer des corrections coûteuses.

Ce document propose une autre méthode : intégrer les règles de sécurité directement dans les plans dès le premier jour.

Voici une décomposition simple de la manière dont les auteurs, Jinyuan Li, Ruijie Ma et Yicheng Gu, suggèrent de procéder pour les systèmes numériques (comme ceux utilisés pour la gestion d'actifs numériques).

1. Le problème central : Le fossé du « Traducteur »

Les auteurs soulignent l'existence d'une barrière linguistique.

Les auditeurs parlent en termes de règles comme : « Nous avons besoin de la preuve que seul le gestionnaire a approuvé cette transaction. »
Les architectes logiciels parlent en termes de code comme : « Nous avons besoin d'une table de base de données et d'un point de terminaison d'API. »

Généralement, ces deux groupes ne se parlent pas avant que le logiciel ne soit déjà construit. Le résultat est que la sécurité et la conformité deviennent des « correctifs » ajoutés plus tard, ce qui est désordonné et coûteux.

2. La solution : Un « Moteur de règles » et un « Index de preuves »

Les auteurs ont créé une méthode pour traduire les règles des auditeurs directement dans l'ADN du logiciel avant même d'écrire la moindre ligne de code. Ils utilisent trois outils principaux :

A. La « Matrice de traduction » (Le livre de recettes)

Considérez cela comme un immense livre de recettes qui transforme des règles vagues en ingrédients spécifiques.

La Règle : « Nous devons savoir qui a modifié cette donnée. »
La Traduction : Le système sait automatiquement qu'il doit créer un « Verrou de version », enregistrer un « Journal de modifications » et générer une « Empreinte numérique » (hash) de la donnée.
Le Résultat : Au lieu qu'un humain devine comment coder cela, le système sait exactement quels « modules fonctionnels » (comme un service de connexion ou un service de journalisation) doivent être activés.

B. Le « Moteur de règles » (Le videur)

Une fois les règles traduites, elles sont chargées dans un « Moteur de règles ». Imaginez cela comme un videur à l'entrée d'un club qui vérifie une liste de règles avant de laisser entrer qui que ce soit.

Si vous tentez d'approuver une transaction sans la signature d'une seconde personne, le videur (le logiciel) l'arrête immédiatement.
Si vous tentez d'accéder à un fichier auquel vous n'avez pas droit, le videur vous bloque.
Cela se produit automatiquement dans le flux normal, et non comme une réflexion après coup.

C. L'« Index de preuves » (Le classeur numérique)

Autrefois, prouver que l'on avait suivi les règles signifiait fouiller dans des traces papier désordonnées ou des journaux informatiques éparpillés.

Les auteurs proposent un système où chaque action génère automatiquement un « reçu » (une preuve).
Ces reçus sont estampillés d'un identifiant unique, d'un horodatage et d'une signature numérique.
Ils sont classés instantanément dans un « Répertoire de preuves » spécial.
L'analogie : C'est comme un classeur intelligent qui, dès que vous signez un document, prend automatiquement une photo, y appose la date et le place dans un tiroir verrouillé que seul l'auditeur peut ouvrir. Vous n'avez pas à chercher le papier plus tard ; il est déjà là, organisé et prêt.

3. Comment ils l'ont testé : La plateforme d'actifs numériques

L'équipe a testé cette méthode sur une « Plateforme de gestion d'actifs numériques » (un système pour gérer des éléments comme de l'argent numérique ou des jetons). Ils ont comparé deux scénarios :

Scénario A (L'ancienne méthode) : Construire le système d'abord, puis essayer d'ajouter les règles de sécurité plus tard.
Scénario B (La nouvelle méthode) : Intégrer les règles de sécurité dans la conception dès le départ.

Les résultats :

Moins de corrections : L'« Ancienne méthode » a nécessité 24 modifications de ses interfaces (comme changer la forme d'une porte). La « Nouvelle méthode » n'en a nécessité que 7.
Moins de réécriture : L'« Ancienne méthode » a nécessité de patcher 16 structures de données (comme refaire la plomberie). La « Nouvelle méthode » n'en a nécessité que 3.
Tests plus rapides : Tester la « Nouvelle méthode » a pris 58 heures de travail ; l'« Ancienne méthode » en a pris 143.
Meilleure preuve : La « Nouvelle méthode » avait 95 % des preuves requises prêtes automatiquement, contre seulement 70 % pour l'« Ancienne méthode ».

4. L'essentiel

Le document soutient qu'en traitant les exigences d'audit comme des instructions calculables (comme du code) plutôt que comme de simples documents textuels, vous pouvez construire des systèmes qui sont « prêts pour l'audit » par défaut.

Au lieu de construire une maison et de réaliser ensuite que vous avez oublié l'issue de secours, vous dessinez l'issue de secours directement dans le plan. Lorsque la maison est construite, l'issue de secours est déjà là, parfaitement intégrée et prête à être inspectée. Cela permet d'économiser de l'argent, de réduire le stress et de rendre l'infrastructure numérique beaucoup plus fiable.

Résumé Technique : Des exigences d'audit à l'architecture logicielle calculable

Énoncé du problème

La traduction des exigences d'audit en spécifications calculables pour les infrastructures numériques de confiance demeure un défi majeur. L'obstacle principal est le décalage sémantique entre les professionnels de l'audit et les architectes système lors du développement de systèmes fintech. Par conséquent, les mécanismes de conformité sont souvent traités comme une réflexion après coup, intégrés lors des phases ultérieures de codage, d'intégration ou de livraison, plutôt que d'être intégrés tôt dans l'architecture logicielle. Cette approche fait en sorte que les contrôles d'audit deviennent des « correctifs post-développement » plutôt que des contraintes natives, ce qui entraîne une augmentation des changements d'interface, des corrections de données et de la charge de tests lorsque des mesures correctives sont nécessaires. La recherche existante s'est largement concentrée sur l'acquisition de preuves, l'automatisation de l'audit et la surveillance des risques, mais a accordé une attention limitée à la relation de mapping spécifique entre les assertions d'audit, la logique du moteur de règles, les machines à états de workflow et les référentiels de preuves indexés lors de la phase de conception du système.

Méthodologie

L'étude propose une méthode de moteur de règles et d'indexation de preuves pour convertir les exigences d'audit en règles de contrôle exécutables, en modules fonctionnels du système et en objets de preuve vérifiables. La méthodologie s'articule autour de plusieurs modèles et processus formels :

1. Modélisation et mapping formels

Transformation de l'assertion en règle : Les assertions d'audit ( $A$ ) sont transformées en règles de contrôle exécutables ( $R$ ) via une fonction $\phi$ .
Objectif d'optimisation : Une fonction d'objectif de vérification ( $Q = \lambda P + \mu E - \nu D$ ) est définie pour équilibrer la couverture du contrôle ( $P$ ), l'exhaustivité des preuves ( $E$ ) et le coût de modification architecturale ( $D$ ).
Classification des preuves : La preuve d'audit est classée en quatre catégories — processus, données, comportement et confiance — chacune étant mappée à des contreparties techniques spécifiques (ex: transitions d'état de workflow, instantanés de version, logs d'API, signatures numériques).
Matrice de conversion : Une matrice ( $M_{ij}$ ) mappe les assertions d'audit aux modules fonctionnels du système en fonction des poids de risque des nœuds et des priorités fonctionnelles. Lorsque la force du mapping dépasse un seuil, les contrôles sont distribués aux machines à états de workflow, aux services de contrôle d'accès (RBAC), aux services de logs d'audit et aux services d'indexation de preuves.

2. Architecture logicielle de confiance

Le système adopte une architecture à trois couches :

Couche d'orchestration métier : Gère l'ordonnancement des instances de processus et la vérification des transformations d'état.
Couche d'exécution du contrôle : Gère le rapprochement de règles, le contrôle d'accès basé sur les rôles (RBAC) et les appels signés.
Couche de fondation des preuves : Gère l'agrégation de logs, les instantanés de déploiement et l'indexation sommaire.
Stratégie de déploiement : Les éléments de contrôle sont enregistrés comme des unités de politique avec des priorités et des déclencheurs spécifiques. Les nœuds de transaction clés utilisent une écriture à double canal : la base de données métier stocke les données principales, tandis que la base de données de preuves écrit simultanément les TraceIDs, les IDs d'opérateur, les horodatages et les valeurs de hachage sous les contraintes de la machine à états.

3. Extraction des points de contrôle et orchestration des règles

En utilisant la relecture de journaux d'événements (event-log replay) lors de la simulation de processus, la méthode analyse des champs tels que les identifiants d'instance de processus et les rôles d'opérateur pour localiser les points de contrôle à haut risque. Les assertions d'audit sont décomposées en condition, action et éléments de preuve, puis orchestrées en chaînes de règles exécutables. Les nœuds à haut risque emploient un « double lien de règle », où une règle primaire régit les transitions d'état du service et une règle secondaire vérifie la cohérence des signatures, des horodatages et des index de preuves.

4. Cycle de vie et vérification des preuves

Le cycle de vie des preuves comprend la génération, la liaison, le stockage, la récupération et l'archivage. Une stratégie « référentiel métier + référentiel de preuves + référentiel d'index sommaire » est utilisée, les preuves à haut risque étant protégées par des hachages SHA-256 et des signatures Ed25519. L'efficacité du contrôle est vérifiée par un protocole de test à trois couches :

Vérification de la structure : Vérifie le déploiement des points de contrôle et des identifiants de politique.
Relecture de comportement : Injecte des événements normaux, non autorisés, de rollback et de timeout.
Examen des preuves : Valide la cohérence des TraceIDs, des signatures et des valeurs de condensat (digest).

Contributions clés

Le document introduit une voie pratique pour l'implémentation d'une architecture de conformité intégrée dans les pratiques actuelles du génie logiciel. Les contributions spécifiques incluent :

Modèle de classification : Un modèle de contrepartie technique liant les types de preuves d'audit (processus, données, comportement, confiance) aux structures computationnelles.
Matrice de mapping : Une matrice de conversion qui traduit les assertions d'audit (intégrité, autorisation, traçabilité, non-répudiation) en modules fonctionnels système spécifiques et en configurations de paramètres clés.
Algorithme de vérification : Un algorithme de vérification de l'efficacité du contrôle orienté vers la vérifiabilité qui quantifie la validité du contrôle basés sur les taux de réussite des tests de protocole et l'exhaustivité des preuves.
Contrainte en boucle fermée : Une méthodologie qui crée une contrainte en boucle fermée entre les contrôles, les fonctions et les preuves lors de la phase de conception architecturale.

Résultats

La méthodologie a été illustrée par une étude de cas d'une Plateforme de Gestion d'Actifs Numériques couvrant six processus majeurs : enregistrement des actifs, vérification de la propriété, approbation, changement de statut, transfert d'autorité et archivage/gel.

Une analyse comparative a été menée entre deux scénarios :

Scénario A (Post-déploiement) : Ajout des contrôles d'audit une fois le développement terminé.
Scénario B (Pré-intégré) : Intégration de la carte de contrôle lors de la conception architecturale.

Résultats quantitatifs :

Couverture du contrôle : Augmentation de 74,8 % (post-correction) à 93,6 % (pré-intégré).
Exhaustivité des preuves : Amélioration de 69,7 % à 95,1 %.
Coûts d'ingénierie :
- Les modifications d'interface ont diminué de 24 à 7.
- Les correctifs de structure de données sont passés de 16 à 3.
- Les cas de tests de régression ont été réduits de 143 à 58.
- Les heures de remédiation sont tombées de 247 à 86.
Performance : Le temps de réponse moyen des requêtes d'audit est passé de 436 ms à 182 ms, et le taux de clôture des chemins d'anomalie est passé de 68,9 % à 92,4 %.

Les résultats indiquent que l'intégration en amont limite les changements aux paramètres de politique et aux configurations d'index, évitant ainsi la réécriture des chemins de transaction critiques ou la réalisation de correctifs étendus sur les bases de données.

Signification et revendications

Le papier affirme que cette approche offre une voie pratique pour l'implémentation en ingénierie informatique d'une conformité intégrée et d'une conception de système prête pour l'audit. En convertissant la sémantique de conformité en moteurs de règles déployables, en contraintes de machines à états et en objets de preuve indexés, la méthode réduit les coûts associés aux actions correctives prises après le développement. Elle comble l'écart entre les assertions d'audit et les fonctions du système, garantissant que les contrôles sont des contraintes natives plutôt que des correctifs a posteriori.

Les auteurs reconnaissent des limites concernant la couverture des scénarios et l'adaptabilité aux systèmes hétérogènes multi-plateformes. Des travaux futurs sont suggérés pour s'étendre vers les architectures multi-cloud, la préservation des preuves collaborative on-chain et off-chain, et les agents intelligents auditables.