Voici un exemple de modélisation en BPMN d’un processus qui traduit les obligations de notification qui sont faites aux responsables de traitement (RT) et sous-traitants de données à caractère personnel (DCP) en cas de violation de DCP.

Ce processus peut bien entendu être adapté tant au niveau de la forme (son degré d’abstraction sera fonction du cadre de son utilisation) qu’au niveau du fond (est souhaitable une adaptation à la réalité de l’organisation, voire, s’il est voué à être automatisé, à l’architecture du SI de l’entreprise).
Il peut par ailleurs être intéressant de considérer ce processus de notification comme partie intégrante d’un macro-processus de gestion des violations de DCP.

 
C’est notamment à ce titre qu’on imagine toute l’opportunité de prendre en compte lors de la modélisation les éventuels processus existants (comme par exemple un plan de continuité d’activité) et d’y greffer ce processus de conformité, en fonction bien sûr de l’intérêt que l’organisme peut trouver à une telle opération.

Le processus Détecter fournira – entre autres- les moyens de détecter une violation de DCP, événement déclencheur du processus aval Réagir dont notifier fait partie. Dans cet exemple, le déclenchement du processus de notification intervient suite à l’émission d’un signal au niveau des tableaux de bords du service informatique), ou après avoir été notifié par un sous-traitant.

 
Mais revenons à notre diagramme représentant la gestion du processus de notification par un organisme, que – soit dit en passant – je vous souhaite de ne jamais avoir à exécuter en situation réelle.
Une telle représentation imagée des exigences règlementaires s’adresse à mon sens particulièrement aux organismes au sein desquels les fonction métiers assurent elles-mêmes la conformité. Ces organismes n’ont en effet pas nécessairement la compétence juridique en interne (dans le domaine IT qui plus est), ni accès à des outils de type BPMS ou moteurs de règles permettant d’entériner les exigences du règlement dans les processus de l’organisme – pour peu qu’ils existent et soient formellement documentés et appliqués -.
Cette modélisation, en traduisant les contraintes règlementaires pourrait ainsi permettre à un non-initié de piloter ce processus de conformité.
Rq : Aux organismes ayant désigné un DPD : à moins que celui-ci ne prenne jamais de vacances, comment refuser une telle opportunité de transfert de compétences !
En outre, ce type de représentation a cet avantage de présenter les exigences règlementaires comme une séquence logique de tâches ordonnancées poursuivant une finalité -et référant aux articles du règlement si besoin -, plutôt qu’une liste longue comme le bras de contraintes qui auraient du mal à être comprises par un collaborateur, confortant son hostilité au changement… le tout sur un support de visualisation unique facilitant ainsi la compréhension du processus.
Et comprendre, en donnant du sens, est un premier pas vers l’acceptation. Et cela est pour le moins souhaitable quand on voit à quel point l’arrivée du RGPD dans la sphère de l’entreprise – entraînant certes son lot de contraintes – suscite nombre de réactions épidermiques.

A propos de Martin REBOULLEAU