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 GDPR (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é GDPR 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 secondaire
Une banque qui passe au découpage applicatif découvre presque toujours qu’elle a entre 15 et 30 % d’applications de plus que ce qu’elle pensait. Les « petites applications » oubliées dans le registre. Ce n’est pas un échec, c’est l’utilité de l’exercice : il rend visible ce qui était sorti du radar.