Purger par application, pas par table

Bernard Malachane · 3 min de lecture  

Pourquoi le découpage applicatif bat le découpage technique, et comment l'organiser.

Les missions qui produisent un livrable défendable devant la CNIL ont toutes une caractéristique commune : la règle de rétention est écrite au niveau de l’application métier, pas au niveau de la table de la base de données. C’est un choix de découpage, et il change tout.

Le mauvais découpage : la table

L’approche intuitive pour une DSI, c’est de partir des bases de données. On liste les tables, on associe une durée par table, on programme une purge SQL. Cela paraît rigoureux. C’est en réalité très fragile.

D’abord, parce qu’une même table peut porter des données soumises à des durées différentes selon leur source ou leur usage. Une table « clients » peut contenir des prospects (durée courte), des clients actifs (durée contractuelle), des clients en contentieux (durée longue). La purge par table aligne tout sur la durée la plus longue « pour être prudent ». C’est de la sur-rétention déguisée.

Ensuite, parce que les tables changent de structure plus vite que les obligations légales. À chaque évolution applicative, la cartographie technique est à refaire. Les bases divergent, la documentation suit avec retard.

Le bon découpage : l’application métier

L’autre approche, c’est de partir de l’application métier. Une application a une finalité unique au sens RGPD (CRM, octroi de crédit, recouvrement, paiement). Une finalité, c’est une durée légale. Une application, c’est un éditeur, une équipe métier, un sponsor identifié. La règle peut être discutée, validée, signée.

Quand la règle est portée par l’application :

• Le DPO sait à qui parler en cas de doute (le sponsor métier de l’application).
• Le DSI sait où câbler la purge (le module de purge interne à l’application, ou le job programmé dessus).
• Le contrôleur CNIL peut suivre le fil sans se perdre dans la couche technique.

Comment l’organiser ?

Il faut un inventaire applicatif. La plupart des banques en ont un, souvent dans un outil de cartographie SI ou un fichier Excel maintenu par l’équipe architecture. Cet inventaire est le point de départ. On l’enrichit avec :

• La finalité RGPD de l’application
• La durée de conservation cible, avec sa source légale ou contractuelle
• L’éditeur ou l’équipe interne qui pilote l’application
• L’état d’exécution de la purge (programmée, manuelle, absente)

Une fois ces quatre colonnes remplies, le plan d’action devient lisible : on sait où sont les écarts, par qui ils sont portés, et dans quel ordre les traiter.

L’effet bénéfique

La démarche permet de pallier les conséquences de la découverte d'applications oubliées dans le registre (les organisations qui passent au découpage applicatif découvrent presque toujours 15 à  30 % d’applications de plus qu'elles n'en avaient prévues), et de mettre à jour la cartographie des applications et le registre RGPD.