Gestion d’amendes pour infractions routières

L’event log de gestion d’amendes pour infractions routières est un log dans lequel chaque trace représente la gestion d’une amende3. Chaque trace commence avec l’émission de l’amende (create fine), qui a un attribut amount représentant le montant de l’amende. Cet event a aussi un attribut dismissal représentant une ou plusieurs raisons de rejet de l’amende. Cet attribut prend la valeur "NIL" si l’amende doit absolument être payée. Un paiement (payment ) a un attribut paymentAmount indiquant le montant de l’amende payé. Le montant total de l’amende peut être payé en plusieurs fois. Certaines amendes sont payées directement à l’officier de police lorsque l’amende est donnée, d’autres sont envoyées par courrier (send fine). Un envoi postal a un attribut (expense) représentant le

1. http ://www.promtools.org/doku.php

2. https ://svn.win.tue.nl/trac/prom/browser/Packages/LocalProcessModelDiscovery 3. https ://doi.org/10.4121/uuid :270fd440-1057-4fb9-89a9-b699b47990f5

Section 7.1

coût de gestion du dossier, s’ajoutant au montant total de l’amende à payer. Lorsqu’une amende n’est pas payée à temps, une pénalité de retard (add penalty) est appliquée, avec un attribut (amount ) qui indique le montant de la pénalité à ajouter au montant de l’amende. Si l’amende n’est toujours pas payée après l’application de la pénalité de retard, elle est envoyée en recouvrement (send for credit collection). De plus, une amende peut être contestée à la préfecture (send appeal to prefecture), voir même devant les tribunaux (appeal to court ). Si la contestation est concluante, l’attribut dismissal de l’event create fine prend la valeur "G" ou "#".

Au total, cet event log contient 11 activités distinctes et 150 370 traces d’une lon- gueur moyenne de 4 events ; la trace la plus courte et la trace la plus longue comportant respectivement 2 et 20 events.

Create Fine €5.60 M / €5.83 M

Send for Credit Collection €6.32 M / €6.43 M

Payment €731 K / €731 K

(1) profit = 12,6 Me

Insert Date Appeal to Prefecture €378 K / € 384 K

Send for Credit Collection €6.39 M / €6.43 M

Send Appeal to Prefecture €570 K / € 570 K Create Fine

€3.15 M / € 5.83 M

(2) profit = 10,5 Me

Create Fine

€2.93 M / €5.83 M _{Receive Result Appeal from Prefecture} €125 K / €138 K

Send for Credit Collection €6.39 M / €6.43M

Notify Result Appeal to Offender €128 K / €129 K

(3) profit = 9,6 Me

Figure 7.1 – Les trois HU-LPMs avec le plus haut profit extraits à partir du log de gestion des amendes pour infractions routières, en utilisant le montant restant à payer comme profit.

Supposons un analyste avec le besoin d’analyser les parties du processus de gestion des amendes où le montant restant à payer est élevé.

Pour atteindre cet objectif, nous utilisons une fonction de profit qui définit le profit comme le montant de l’amende restant à payer au moment où l’event est rejoué. Cette fonction est définie sur le périmètre trace car elle dépend, pour un γ-segment rejoué dans le LPM, du dernier attribut "amount " rencontré (soit dans un event "create fine" soit dans un event "add penalty"), plus le potentiel surplus dû à un envoi postal, moins le montant des paiements déjà effectués.

L’extraction des HU-LPMs sur cet event log prend 39 minutes, sur une machine équipée d’un processeur Intel i7 2,4GHz et 16Go de RAM.

Nous présentons dans la Figure7.1 les 3 meilleurs HU-LPMs ; i.e., les 3 LPMs avec le profit le plus élevé. De façon presque identique à un LPM, un HU-LPM est modélisé par un réseau de Petri dont les transactions sont sous la forme (actX/Y ), avec act le label de l’activité modélisée, mais avec Y le profit total des events dans le log ayant exécuté act, et X le profit total des events de Y rejouables dans le LPM.

Le premier HU-LPM montre qu’au total, 5,83 Me d’amendes ont été émises. Parmi ces amendes, certaines ont été envoyées en recouvrement, d’autres ont reçu des paiements,

Chapitre 7

le tout pour un montant de 5,60 Me. Les 230 K e restant correspondent aux amendes qui n’ont pas encore été payées mais qui sont assez récentes pour ne pas avoir été encore envoyées en recouvrement. Nous remarquons que le montant total des paiements reçus après un event create fine est de 731 Ke, ce qui est plutôt faible comparé aux 5,83 M e qui sont dus. Il est à noter que les amendes envoyées en recouvrement représentent un montant total de 6,43 Me, ce qui est supérieur au montant total initial de 5,83 M e. Cet écart s’explique par l’ajout de pénalités de retard, et dans une moindre mesure, des frais additionnels pour envoi postal. Enfin, des 6,43 Me d’amendes envoyées en recouvrement, la plupart d’entre elles, d’un montant de 6,32 Me, représentent des events rejouables dans le premier HU-LPM ; i.e., l’envoi en recouvrement apparaît après la création de l’amende et est dans une situation de choix exclusif avec le paiement de l’amende. Puisque nous savons que chaque trace commence avec la création de l’amende, la seule explication possible est que le montant de 6,32 Me d’amendes envoyées en recouvrement n’a pas reçu un seul paiement avant l’envoi, alors qu’une partie des amendes restantes aussi envoyées en recouvrement, d’un montant de 110 Ke, ont reçu au moins un premier paiement partiel. Le second HU-LPM présenté dans la Figure7.1 montre que sur un total de 5,83 Me, 3,15 Me a soit été envoyé en recouvrement soit contesté en préfecture. Une contestation est d’abord enregistrée (insert date appeal to prefecture) avant d’être envoyée en préfecture (send appeal to prefecture). Le HU-LPM montre que, pour les amendes contestées, le montant total est de 378 Ke lors de l’enregistrement, mais les pénalités pour retard de paiement fait passer ce montant à 570 Ke lors de l’envoi en préfecture. Cela signifie qu’en moyenne, le montant des amendes sont multipliées par un facteur 1,5 lors de la procédure de contestation en préfecture à cause des retards de paiement générés. Enfin, le montant des amendes envoyées en recouvrement montre que seulement une petite partie des amendes créées ont été suivies par une contestation en préfecture.

Le troisième HU-LPM présenté dans la Figure 7.1 modélise un fragment similaire au deuxième HU-LPM, avec la différence qu’il décrit maintenant les étapes suivantes de la contestation en préfecture. Lorsque le verdict de la contestation est reçu, le montant total encore dû est de 138 Ke. Ce montant est bien inférieur aux montants respectifs de 378 Ke et 570 K e des étapes précédentes de la procédure de contestation en préfecture. Cela signifie que sur 570 Ke d’amendes contestées en préfecture, 432 K e d’amendes n’ont pas eu de verdict suite à la contestation. Les contestations ont donc été soit retirées avant d’être étudiées ou sont encore en attente de verdict. De plus, sur 138 Ke d’amendes contestées en préfecture et dont le verdict a été reçu, 125 Ke représentent des events rejouables dans le troisième HU-LPM, signifiant que les 13 Ke restants représentent des contestations qui n’ont pas encore été notifiées, ou dont les amendes concernées ont été envoyées en recouvrement avant d’être contestées.

Cet event log a déjà été utilisé pour l’application de trois autres techniques existantes, et qui utilisent les attributs disponibles dans l’event log pour en extraire des connais- sances : le MP-Declare Miner [Schönig et al., 2016b], une technique qui se rapproche de la nôtre et que nous avons analysée dans le chapitre5; et les Multi-Perspective Process Ex- plorer [Mannhardt et al., 2015] et Data-Aware Heuristic Miner [Mannhardt et al., 2017] qui s’éloignent de notre problématique dans la mesure où elles analysent un modèle sur un périmètre global plutôt que local.

Avec le MP-Declare Miner, les informations suivantes ont pu être extraites : "(1) Dans 74 % des cas où une pénalité pour retard est donnée, l’amende a été envoyée en recou- vrement" ; "(2) Lorsqu’une pénalité est donnée, le montant de cette pénalité est compris

Section 7.1

entre 470e et 795 e" ; et "(3) Plus la pénalité est élevée, plus la probabilité que l’amende ne soit pas payée est basse". Il est à noter que ces informations sont différentes de celles que l’on peut obtenir avec des HU-LPMs : alors que les informations extraites par le MP-Declare Miner sont des corrélations entre le control-flow et les attributs ; i.e., entre l’exécution d’une activité et la valeur des attributs au moment de l’exécution ; les HU- LPMs montrent aussi l’évolution de la valeur des différents attributs entre les différentes étapes du control-flow ; e.g. l’évolution des montants restant à payer pour les amendes. Les corrélations entre les attributs et les étapes du control-flow pourraient être facile- ment extraites à partir des HU-LPM en utilisant des techniques classiques de decision mining [Mannhardt et al., 2016].

Avec le Data-Aware Heuristic Miner, les informations suivantes ont pu être extraites : "(1) L’ajout de pénalités pour retard de paiement dépend de la valeur de l’attribut "dis- missal" de l’amende concernée. S’il vaut "G", alors aucune pénalité n’est ajoutée, alors que s’il vaut "N IL" une pénalité est ajoutée et dont la valeur dépend du montant de l’amende" ; "(2) Les amendes non payées dont le montant est inférieur à 35e reçoivent une pénalité" ; "(3) Le processus se termine par la notification à l’officier de police du ver- dict de la contestation de l’amende en préfecture pour les amendes dont l’attribut "dismis- sal" a la valeur "#" ou "G".". La seule information extraite depuis le Multi-Perspective Process Explorer est : "L’envoi en recouvrement survient pour les amendes dont le mon- tant est supérieur à 71e". A l’image des informations extraites du ML-Declare Miner, celles extraites par le Data-Aware Heuristic Miner et le Multi-Perspective Process Ex- plorer concernent toutes des relations entre les attributs et le control-flow. Encore une fois, la différence majeure qu’il existe avec l’extraction de HU-LPM est que cette dernière permet d’extraire des informations sur l’évolution des attributs dans les différentes étapes du control-flow modélisé.