Project

General

Profile

Development #24494

Script de recensement des traitements

Added by Paul Marillonnet about 1 year ago. Updated about 1 year ago.

Status:
Nouveau
Priority:
Normal
Category:
-
Target version:
-
Start date:
13 Jun 2018
Due date:
% Done:

0%

Patch proposed:
Yes
Planning:
No
Demande du club utilisateur:
No

Description

Pour le fameux "inversement de la charge de la preuve", i.e. être capable de prouver qu'on connaît l'étendue des traitements sur les DCP, et qu'on maîtrise les risques induits.

0001-WIP-data-processing-records-24494.patch View (2.97 KB) Paul Marillonnet, 13 Jun 2018 10:44 AM

History

#1 Updated by Paul Marillonnet about 1 year ago

Et donc des données à récupérer pour chaque workflow. Je pose ici ce que j'avais écrit dans la page wiki.

  • Nom et adresse du responsable de traitement
    <Contact du propriétaire du workflow>
  • Date de mise en œuvre
    <Date d'activation de la démarche associée>
  • Finalité principale
    <Reprise d'un champ "description" relatif au workflow ou au formulaire>
  • Service chargé de la mise en œuvre
    <OU du propriétaire du workflow>
  • Fonction de la personne ou du service auprès duquel s'exerce le droit d'accès
    <Un des roles du propriétaire du workflow>
  • Catégorie de personnes concernées par le traitement
    Usagers de la solution GRU Publik
  • Données traitées
    <Un sous-ensemble des champs de formulaire>
  • Catégories de destinataires
    //Ici on pourrait imaginer cette information déduite d'un attribut du workflow prévu à cet effet.
  • Durée de conservation
    <Durée paramétrée avant anonymisation>
  • Mise à jour (date et objet)
    <Historique des versions successives des workflows>

Il y a clairement des infos qui vont manquer pour l'instant, je continue de regarder comment constituer cette sortie pour chaque WF.

#2 Updated by Paul Marillonnet about 1 year ago

  • Project changed from Interne to Publik

#3 Updated by Paul Marillonnet about 1 year ago

Du code, mais surtout un prétexte pour voir si l'état actuel des structures de données touchant aux workflows permettent de constituer le registre tel que défini plus haut.
Apparemment ce n'est pas le cas.

#4 Updated by Thomas Noël about 1 year ago

Petit chose liées à la façon dont les choses sont articulées dans w.c.s. : la plupart de ces informations ne sont pas liées au seul workflow, mais aussi au formulaire qui y est lié (il faut se souvenir qu'un même workflow peut être utilisé par plusieurs formulaires). Par exemple le responsable du traitement ne va pas être le même pour une demande de voirie et une demande concernant les espaces verts... mais ça sera le même workflow.

Techniquement dans un workflow, on peut avoir un rôle "Responsable du traitement", qui est en fait une "fonction", ie un "rôle qui va contenir un vrai rôle", un "meta-rôle". Et c'est dans le formulaire qu'on va dire quel est le "Responsable du traitement".

Tout ça pour dire que ton code irait plutôt dans FormDef que dans Workflow.

#5 Updated by Paul Marillonnet about 1 year ago

Thomas Noël a écrit :

[...] Tout ça pour dire que ton code irait plutôt dans FormDef que dans Workflow.

Entendu, merci, je vais regarder ça.

Ce que je verrais bien:
- un WS w.c.s. qui renvoie cette liste en JSON pour chacun des formulaires.
- un script (script hobo ?) qui exploite cette interface pour constituer un document humainement intelligible.

#6 Updated by Benjamin Dauvergne about 1 year ago

Est-ce qu'il vaut mieux avoir ces informations dans w.c.s. (c'est sympa ça suit les renommage, les import/export, etc..) ou bien avoir un seul champ identifiant la démarche de manière unique (qui ne bougera pas entre la préprod et la préprod, on va dire l'identifiant RGPD) moissoner cea dans un outil dédié (style pia-machin de LibreInformatique) et administrer dans cette outil le registre (à développer par exemple dans Tryton).

Je reparle de Tryton ici parce que ça m'embête que le sujet soit un peu tomber dans les limbes et que je verrai bien Tryton comme la base de notre fichier client et tout ce qui s'ensuit, recensement des démarches, i.e. toutes les données qu'on peut rattacher à un client.

#7 Updated by Paul Marillonnet about 1 year ago

Benjamin Dauvergne a écrit :

[...] ou bien avoir un seul champ identifiant la démarche de manière unique (qui ne bougera pas entre la préprod et la préprod, on va dire l'identifiant RGPD) moissoner cea dans un outil dédié (style pia-machin de LibreInformatique) et administrer dans cette outil le registre (à développer par exemple dans Tryton).

Oui je comprends ce que tu veux dire. L'idée de la prise en charge du recensement par Tryton me plaît.
Pour le recensement en lui-même, je ne pense pas que l'outil dédié soit nécessaire. Par contre c'est possible que ça nous facilite la tâche pour l'analyse des risques, censée suivre le recensement de traitements jugés "risqués".

#8 Updated by Benjamin Dauvergne about 1 year ago

Mon souci c'est qu'un registre ça doit être un truc stable, avec une liste des gens qui interviennent dessus (normalement uniquement le CIL), un historique, etc... Avoir ce registre mélangé au milieu des outils où un formulaire peut changer de nom, changer de contenu, être publié, dé-publié, supprimé, modifier par on ne sait pas qui, ça me chagrine. Ensuite on aura le cas de traitements qui ne sont pas des formulaires (Zoo à Nanterre, Petale, le porte-doc, etc..) ou bien où l'on ne joue qu'un petit rôle sans passer par w.c.s. (on propose un WS à un autre logiciel de la collectivité).

Qu'on provisionne le registre depuis la prod, sûr, qu'on soit capable de dire quand la prod et le registre diffère (tiens il y a un nouveau champ ou un nouveau TS, alerte!) aussi avec de l'aide à la saisie, mais la description de la finalité ou des durées de rétention c'est un travail humain, à journaliser.

À défaut de Tryton ça pourrait bêtement être un wiki (un script créé une page par formulaire à partir de son numéro de déclaration CNIL/RGPD interne1) en s'appuyant sur les WS dans Redmine; on a pas mal de possibilité d'organisation je pense sans foncer droit vers l'idée d'ajouter des champs dans w.c.s.

[1]: un script crée une hiérarchie dans le wiki Redmine "CIL/RGPD", Registre RGPD/Client/<Référence TS>/ en moissonnant nos instance w.c.s., dans chaque page on a un tableau pré-rempli avec les champs du formulaire de workflow, etc.. et on peut éditer (un peu de boulot pour le merge mais ça devrait aller), ça laisse de la place pour l'éditorial en dessous, et toutes les modifications sont journalisées.

#9 Updated by Paul Marillonnet about 1 year ago

Benjamin Dauvergne a écrit :

la description de la finalité [...] c'est un travail humain, à journaliser.

OK. Je ne sais pas à quel point ce travail est éphémère (ou du moins, à refaire à chaque fois que quelque chose bouge) et colossal.

des durées de rétention c'est un travail humain, à journaliser.

Là, pour les traitements liés à des formulaires, je pensais pouvoir déduire cette durée de rétention du workflow associé (en l'occurrence, la durée de conservation avant anonymisation de la demande).

À défaut de Tryton ça pourrait bêtement être un wiki (un script créé une page par formulaire à partir de son numéro de déclaration CNIL/RGPD interne1) en s'appuyant sur les WS dans Redmine; on a pas mal de possibilité d'organisation je pense sans foncer droit vers l'idée d'ajouter des champs dans w.c.s.

Ok, oui c'est vrai.

[1]: un script crée une hiérarchie dans le wiki Redmine "CIL/RGPD", Registre RGPD/Client/<Référence TS>/ en moissonnant nos instance w.c.s., dans chaque page on a un tableau pré-rempli avec les champs du formulaire de workflow, etc.. et on peut éditer (un peu de boulot pour le merge mais ça devrait aller), ça laisse de la place pour l'éditorial en dessous, et toutes les modifications sont journalisées.

Ok, mais je ne vois pas encore le "boulot de merge" dont tu parles.

#10 Updated by Benjamin Dauvergne about 1 year ago

Paul Marillonnet a écrit :

Benjamin Dauvergne a écrit :

la description de la finalité [...] c'est un travail humain, à journaliser.

OK. Je ne sais pas à quel point ce travail est éphémère (ou du moins, à refaire à chaque fois que quelque chose bouge) et colossal.

C'est bien l'idée de merger le registre avec la vue de l'existant. Merger ça veut dire par exemple si on a un tableau avec la listes des informations collectées (champs), d'ajouter les nouveaux champs avec un gros NOUVEAU en rouge, et de barrer les anciens champs avec un gros "SUPPRIMÉ" en noir. Au CIL de venir voir les changements régulièrement pour voir ce qu'il y a à faire. Ce serait pour moi le boulot principal d'un script pour recenser les traitements.

des durées de rétention c'est un travail humain, à journaliser.

Là, pour les traitements liés à des formulaires, je pensais pouvoir déduire cette durée de rétention du workflow associé (en l'occurrence, la durée de conservation avant anonymisation de la demande).

Oui éventuellement tu peux obtenir un faisceau d'indice quand à la durée du traitement, mais outre que ce n'est pas évident à faire (tu veux faire du reverse-engineering de workflow, i.e. déduire d'un object technique des informations fonctionelles, ce ne sera pas forcément évident).

Ok, mais je ne vois pas encore le "boulot de merge" dont tu parles.

Ce serait la principale intelligence du script (mais je ne souhaite pas qu'on se focalise sur une implémentation à base de wiki ou autre, c'est juste un example).
Disons que w.c.s. te retourne ça (par exemple en interrogeant le WS qui liste les formulaires):

Formulaire: Demande d'acte de naissance
Numéro RGPD: rouen-aec-naissance-01
Champs:
- nom
- prenom
- date de naissance
- lieu de naissance

Ça génèrerait dans un premier temps le contenu wiki suivant:

rouen-aec-naissance-01

Nom: Demande d'acte d'état civil

Finalité du traitement:

À FAIRE

Données recueillis:

| Intitulé          | Champs dans w.c.s. | Finalité | Depuis     | Jusqu'au |
| Nom               | nom                | À faire  | 2018-06-12 |          |
| Prénom            | prenom             | À faire  |      "     |          |
| Date de naissance | date_de_naissance  | À faire  |      "     |          |
| Lieu de naissance | lieu_de_naissance  | À faire  |      "     |          |

Durée de rétention:

À FAIRE

Là dessus toi ou un CPF vient compléter le dossier. Fin.

Plus tard on ajoute un nouveau champ, l'idée c'est que le script parse la page wiki, trouve le tableau et y ajoute une ligne "À FAIRE" avec le nouveau champ. On recevra une notification de Redmine que la page wiki a changé, à charge pour un CPF ou toi de venir mettre à jour les parties à remplir "À FAIRE".

Plutôt que plusieurs pages on pourrait avoir une page par client histoire d'avoir un historique unique.

Je parle de wiki mais on peut imaginer de stocker ça dans un dépôt git dans un format "parsable" genre YAML ou JSON, dépôt GIT mis à jour par les CPF ou toi et le script de moissonnage, et de générer des pages HTML qui constitueront le registre officiel et les logs git étant l'historique, un peu comme certaines association ont utilisé github pour journaliser le droit français.

#11 Updated by Paul Marillonnet about 1 year ago

Ok, compris, je vais partir là dessus.

Also available in: Atom PDF