Web sémantique · Conformité · Article 3 · Brouillon

La conformité comme graphe, pas comme tableur

Demandez à une équipe de conformité comment une exigence est satisfaite et vous avez souvent droit à une visite guidée de tableurs. Une feuille liste les exigences. Une autre liste les contrôles. Une troisième contient les preuves, une quatrième les risques, et les constats d'audit vivent dans un rapport. La réponse existe, mais quelqu'un doit relier les feuilles à la main, et la personne suivante recommencera.

L'idée du web sémantique offre une autre façon de conserver les mêmes informations.

L'idée en termes simples

L'idée du web sémantique est de publier les données sous forme d'énoncés liés et lisibles par machine : telle chose est liée à telle autre de telle façon. Chaque chose a sa propre identité, et les relations font partie des données, au lieu d'être quelque chose que le lecteur doit déduire. Un ensemble de tels énoncés forme un graphe de connaissances.

Pour la gouvernance, le risque et la conformité, cela signifie un petit changement d'habitude. Une exigence, un contrôle, une preuve, un risque et un constat d'audit cessent d'être des lignes dans des listes différentes. Chacun devient un enregistrement doté d'une identité, et les liens entre eux deviennent eux aussi des enregistrements.

Deux panneaux. À gauche, des listes séparées pour les exigences, les contrôles et les preuves que des personnes relient à la main, encore et encore. À droite, des enregistrements liés où chaque élément a une identité et où les relations entre eux sont aussi des enregistrements, de sorte que les liens sont conservés au lieu d'être reconstruits. Une flèche mène de gauche à droite. — Figure 1 : des listes aux enregistrements liés

À quoi ressemble un contrôle dans un graphe

Prenez un contrôle. Il satisfait une exigence. Il atténue un risque. Il est étayé par une preuve. Il a été testé lors d'un audit, et le test a produit un constat. Dans un graphe, chacun de ces énoncés est un lien du contrôle vers un autre enregistrement, et chaque lien dit qui l'a établi, quand et sur quelle base.

Un contrôle se trouve en haut. Des liens partent de lui vers une exigence qu'il satisfait, un risque qu'il atténue, une preuve qui l'étaye et un constat d'audit issu d'un test de ce contrôle. Une bande en dessous dit que chaque lien est lui-même un enregistrement qui indique qui l'a établi, quand et sur quelle base. — Figure 2 : un contrôle et ce à quoi il se rattache

Nul besoin de rien d'exotique pour voir l'avantage. La question « comment cette exigence est-elle satisfaite, et comment le savons-nous ? » devient un parcours le long des liens, et non une visite de feuilles.

Ce que cela rend possible

Traçabilité. À partir d'une exigence, vous pouvez suivre les liens jusqu'au contrôle, à la preuve et au dernier test, et remonter d'un constat vers le contrôle concerné. La piste, c'est la donnée elle-même.

Correspondance entre référentiels. Les exigences de référentiels différents demandent souvent à peu près la même chose. Dans un graphe, vous écrivez le contrôle une fois et le reliez à chaque exigence à laquelle il répond : un seul enregistrement sert plusieurs sources, et une lacune apparaît comme une exigence sans contrôle derrière elle.

Un enregistrement, plusieurs vues. Les faits n'étant tenus qu'une fois, on peut montrer à chacun la partie qui correspond à son rôle : le responsable conformité voit l'état et les lacunes, l'auditeur voit les tests et les preuves, le gestionnaire des risques voit les risques que le contrôle atténue. Personne ne garde de copie privée.

Un enregistrement de contrôle en haut. Trois vues en partent : le responsable conformité voit l'état et les lacunes, l'auditeur voit les tests et les preuves, et le gestionnaire des risques voit les risques qu'il atténue. L'enregistrement est tenu une seule fois et chacun voit la partie qui correspond à son rôle. — Figure 3 : un enregistrement, plusieurs vues

« À quoi cela ressemblait-il alors ». Le temps fait partie du modèle de deux façons. Un enregistrement conserve des versions datées, et chaque modification est aussi consignée comme un événement : qui a changé quoi, de quelle valeur à quelle valeur. Ensemble, elles permettent de relire l'état passé d'un enregistrement, de sorte que les questions que posent les auditeurs sur un instant donné cessent d'être de l'archéologie.

Une ligne de temps de gauche à droite avec une version antérieure, une modification et la version actuelle du même enregistrement. Une bande en dessous dit que chaque modification est un événement qui consigne qui a changé quoi, de quelle valeur à quelle valeur, de sorte que l'état passé peut être relu. — Figure 4 : à quoi cela ressemblait alors

Un lieu où les agents peuvent lire et écrire, avec des points de validation. Un graphe est quelque chose que des agents logiciels peuvent lire directement, car la structure est explicite. Écrire est une autre affaire. Dans l'esprit des contrôles du premier article de cette série, un agent lit librement mais propose les modifications par un point de validation : revue, approbation du propriétaire et trace de la décision. Le graphe reste fiable parce que ce qui y entre a été approuvé et est traçable.

Un agent à gauche, avec des identifiants limités, lit librement dans le graphe au milieu. Quand il veut changer quelque chose, il propose la modification à un point de validation à droite, où elle attend revue et approbation ; seule la modification approuvée atteint le graphe. Une bande en dessous dit que chaque proposition, décision et modification est consignée. — Figure 5 : les agents lisent et écrivent avec des points de validation

Là où un graphe perd face à un tableur

Un graphe n'est pas gratuit, et ce n'est pas toujours le meilleur outil. Quatre coûts, en toute honnêteté :

La maintenance. Les liens doivent être créés et tenus à jour. Une ligne de tableur se corrige en une minute ; une relation doit être corrigée partout où elle est utilisée.
Un lien périmé est pire qu'une ligne périmée. Une ligne périmée a l'air périmée. Un lien périmé a l'air d'un fait, et chaque question qui le parcourt hérite de l'erreur avec assurance. Les liens ont besoin d'une source, d'une date et d'un moyen d'être marqués comme remplacés.
L'entretien du modèle. Un vocabulaire partagé de types d'enregistrements et de liens ne sert que tant que quelqu'un en est responsable. Sans responsable, il dérive, ou il grossit jusqu'à ce que plus personne ne s'en occupe.
La qualité des données. Un graphe rend les mauvaises données plus visibles, pas meilleures. Des enregistrements en double, des noms en texte libre et des identifiants manquants se traduisent en liens cassés ou dédoublés.

Pour une question petite et stable traitée par une seule équipe, un tableur est plus rapide et moins cher. Un graphe vaut son coût lorsque les mêmes faits sont lus par beaucoup de personnes et beaucoup d'outils, lorsque les relations comptent plus que les lignes, et lorsqu'il faut pouvoir répondre sur l'historique.

Pourquoi il convient à ce domaine en particulier

La gouvernance, le risque et la conformité sont un domaine de relations : ce qui est exigé, ce qui est fait pour y répondre, ce qui montre que c'est fait, ce qui pourrait encore mal tourner, et ce qu'un relecteur indépendant a constaté. Les tableurs conservent les choses et laissent les relations aux personnes. Un graphe conserve les deux, et le travail passe de la réconciliation à la lecture.

Il rejoint aussi l'argument de cette série. Les contrôles stricts pour les agents et la conformité automatisable reposent sur la même chose : des faits explicites, liés et consignés qu'une personne ou un agent peut suivre et vérifier.

À retenir

Gardez l'exigence, le contrôle, la preuve, le risque et le constat comme enregistrements liés, consignez chaque modification comme un événement, et laissez les agents lire librement et n'écrire que par un point de validation. La traçabilité, l'historique et la correspondance viennent alors de la structure, pas de l'effort.