Extracting ODRL Policies from Business Process Models: A Graph Traversal Approach to Compliance-by-Extraction

Imaginez un monde où, chaque fois que vous entrez dans un magasin, un robot garde vous vérifie votre pièce d'identité, votre liste de courses et votre budget avant de vous laisser ramasser le moindre article. Ce robot ne fait pas que deviner ; il suit un manuel de règles strict écrit par le propriétaire du magasin. Dans le monde numérique, ce manuel de règles est appelé une « politique ». Elle indique aux ordinateurs ce qu'ils sont autorisés à faire, ce qu'ils doivent faire et ce qui leur est strictement interdit de faire. Pendant longtemps, écrire ces manuels de règles numériques a été comparable à la construction d'un gratte-ciel à la main, brique par brique. C'est lent, sujet à l'erreur humaine, et si vous vous trompez sur une seule brique, toute la structure peut s'effondrer.

Entrez dans le concept de « conformité ». C'est le mot savant pour s'assurer que tout le monde respecte les règles. Dans le monde des affaires, les entreprises passent des années à dessiner des cartes de la manière dont leur travail est effectué. Ces cartes sont appelées Modèles de Processus Métier (BPMN). Considérez-les comme les plans d'une usine ou le script d'une pièce de théâtre. Elles montrent qui fait quoi, quand, et dans quel ordre. La grande question que les scientifiques se posent est la suivante : « Si nous avons déjà ces plans détaillés, pourquoi devons-nous réécrire le manuel de règles à nouveau ? » Les plans contiennent déjà les règles ; ils parlent simplement une langue différente. Ce document traite de la construction d'un traducteur qui transforme ces plans directement en un manuel de règles moderne et lisible par machine, afin que nous n'ayons pas à écrire les règles deux fois.

Le Traducteur Magique : Des Plans aux Règles

Les auteurs de ce document, une équipe de chercheurs d'Espagne et d'Italie, ont construit un pipeline ingénieux qui agit comme un détective numérique. Leur tâche consiste à examiner la carte de processus d'une entreprise (le fichier BPMN) et à en extraire automatiquement les règles cachées, pour les transformer en un format appelé ODRL. Vous pouvez considérer l'ODRL comme la « langue universelle » des droits et des règles numériques, une norme que les ordinateurs partout peuvent comprendre.

Voici comment fonctionne leur « travail de détective », décomposé en étapes simples :

1. Le Plan est déjà un Manuel de Règles
Les chercheurs ont réalisé que la façon dont une carte de processus est dessinée est en réalité un ensemble de règles. Si une carte montre qu'un travailleur doit vérifier une commande avant de l'expédier, c'est une règle appelée « Devoir » (Duty). Si la carte montre qu'un travailleur peut sauter une étape si une certaine condition est remplie, c'est une « Permission ». Si la carte montre qu'un travailleur ne peut pas avancer tant qu'un événement spécifique ne s'est pas produit, c'est une « Interdiction » (Prohibition). Le problème est que ces règles sont verrouillées à l'intérieur du dessin. Le nouveau pipeline déverrouille ces règles.

2. Le Parcours de Graphe (Le Labyrinthe Runner)
Le logiciel de l'équipe traite la carte de processus comme un labyrinthe. Il utilise une technique appelée « parcours de graphe » (graph traversal), qui est essentiellement une façon systématique de parcourir chaque chemin du labyrinthe pour voir ce qui se passe.

• La vérification du « Doit-faire » : Le logiciel demande : « Si nous supprimons cette tâche, le processus peut-il toujours se terminer ? » Si la réponse est « Non, le processus s'arrête », alors cette tâche est un Devoir (un must-do).
• La vérification du « Peut-sauter » : Si la tâche se trouve sur un chemin qui n'est pas toujours emprunté, c'est une Permission.
• La règle d'« Attente » (La Grande Découverte) : C'est ici que l'article devient vraiment ingénieux. Dans les anciennes méthodes, si un processus devait attendre un e-mail ou un signal (appelé un « événement de capture intermédiaire »), la règle était souvent ignorée ou traitée comme un simple délai. Les auteurs soutiennent que cela est erroné. Ils disent : « Si vous attendez, vous êtes en fait interdit de progresser jusqu'à ce que le signal arrive. » Ainsi, ils ont inventé une nouvelle façon de marquer ces moments comme des Interdictions avec une « contrainte de levée » (lifting constraint). C'est comme un feu rouge qui ne devient vert que lorsqu'une voiture spécifique (l'événement) passe par là.

3. Le Résultat
Après avoir parcouru le labyrinthe, le logiciel recrache un manuel de règles propre et valide au format JSON-LD. Il s'agit d'un fichier que les ordinateurs peuvent lire instantanément. Le meilleur dans tout cela ? L'entreprise n'a pas eu à écrire une seule nouvelle règle. Le logiciel a simplement extrait les règles qui étaient déjà cachées dans leurs cartes existantes.

Ce qu'ils ont trouvé (et ce qu'ils n'ont pas trouvé)

L'équipe a testé son traducteur sur cinq scénarios de « référence » différents, allant d'un processus simple d'« Expédition de Marchandises » à un « Restaurant en Libre-service » complexe impliquant trois personnes différentes (pools) interagissant entre elles.

• Le Succès : Dans les cinq cas, le logiciel a réussi à transformer les cartes en manuels de règles sans planter. Il a correctement identifié qui devait faire quoi, qui pouvait sauter des étapes et qui devait attendre. Par exemple, dans le scénario de « Score de Crédit », il a compris qu'une banque doit demander un score, mais qu'un service de notation ne peut pas calculer le score tant que les données ne sont pas arrivées. Il a même géré parfaitement les règles d'« attente » complexes, les étiquetant comme des interdictions qui se lèvent lorsque l'événement se produit.
• Les Limites : L'article est honnête sur l'endroit où la magie s'arrête.
  • Boucles : Si un processus comporte une boucle (comme un client essayant encore et encore), le logiciel simplifie. Il traite la boucle comme une seule tâche de type « doit-faire », ce qui est sûr mais perd la nuance du « répéter jusqu'au succès ».
  • Noms : Parfois, les cartes n'ont pas de noms pour les personnes impliquées (comme « Banque » ou « Commis »). Dans ces cas, le logiciel utilise simplement des étiquettes génériques comme « Participant_1 », ce qui rend le manuel de règles un peu difficile à lire pour les humains, bien que l'ordinateur le comprenne parfaitement.
  • Chronologie Complexe : Le logiciel ne peut pas encore exprimer des règles de temps complexes telles que « La tâche A doit se terminer exactement 5 minutes avant que la tâche B ne commence ». Il capture l'ordre, mais pas le timing précis.

Pourquoi cela importe

L'article ne prétend pas avoir résolu tous les problèmes du monde des règles. Il ne dit pas que c'est la solution finale et parfaite. Au lieu de cela, il prouve qu'une méthode spécifique et automatique de transformation des cartes de processus en manuels de règles fonctionne.

Avant cela, si une entreprise voulait être conforme à de nouvelles lois (comme les règles de confidentialité des données), elle devait embaucher des experts pour rédiger manuellement des milliers de documents de politique. C'était lent et coûteux. Si l'entreprise modifiait son processus, elle devait réécrire les politiques. Cette nouvelle approche suggère que si vous modifiez votre carte de processus, le manuel de règles se met à jour automatiquement. Cela crée un lien direct et auditable entre ce qu'une entreprise fait et les règles qu'elle suit.

Les chercheurs précisent avec prudence que, bien que leur méthode fonctionne très bien pour les cartes de processus standards, elle nécessite encore des travaux pour gérer les boucles complexes et le timing précis. Mais pour l'instant, ils ont montré que les règles sont déjà là, cachées à la vue de tous, attendant qu'un traducteur les libère. C'est une étape vers un avenir où la conformité n'est plus un cauchemar administratif, mais un produit naturel de la conception de notre travail.