Cinq schémas qui reviennent en mission, et pourquoi ils résistent à la documentation.

Sur huit ans d’intervention en banque commerciale française, cinq schémas reviennent à chaque mission. Aucun ne tient à un manque de bonne volonté. Tous tiennent à la structure du système d’information bancaire et au modèle classique de la conformité GDPR.

1. La règle existe, mais elle est dans un PowerPoint

C’est la situation la plus fréquente. La banque a fait l’exercice GDPR en 2018, a produit un registre des traitements, et a posé des durées de conservation sur le papier. Cinq ans plus tard, le PowerPoint dort dans SharePoint, les applications ont évolué, les durées documentées ne correspondent plus à la réalité. La CNIL ne sanctionne pas l’absence de règle, elle sanctionne l’écart entre la règle et l’exécution.

2. La purge théorique, l’archive éternelle

Une application est censée purger les données après la durée de conservation contractuelle. Mais elle archive systématiquement les enregistrements purgés dans une table secondaire « pour traçabilité ». La table secondaire ne fait pas partie du registre. Elle vit dix ans, vingt ans. C’est de la conservation déguisée, et la CNIL la trouve.

3. La règle métier mange la règle juridique

Une équipe commerciale a besoin de l’historique client sur cinq ans pour ses analyses. Le DPO a fixé une durée légale de trois ans. L’application porte cinq ans, parce que c’est le métier qui a câblé. Personne ne ment, personne n’a fraudé : la priorité opérationnelle a simplement écrasé la règle juridique. Sans confrontation directe en atelier, le décalage reste invisible.

4. L’archive intermédiaire qui sort du registre

Le code monétaire et financier impose des durées longues pour certains documents (LCB-FT, comptes bancaires, opérations). Ces durées sont légitimes, mais elles s’appliquent à une portion seulement de la donnée. La banque archive tout en bloc « pour ne pas trier ». Le tri ne se fait jamais. Ce n’est pas une rétention légale, c’est une conservation par défaut.

5. Le sous-traitant qui conserve plus longtemps que vous

Votre éditeur applicatif a sa propre politique de sauvegarde, plus longue que votre politique de conservation. Les sauvegardes incrémentales remontent à trois ans, parfois cinq. La donnée que vous avez « purgée » côté production est restaurable côté sauvegarde, et le sous-traitant ne le sait pas toujours lui-même. La CNIL pose la question dès la première heure du contrôle.

Le point commun

Tous ces schémas partagent une cause : la règle de rétention est écrite à un niveau (le registre), exécutée à un autre (l’application, le sous-traitant), et personne ne ferme la boucle. La purge des données n’est pas un problème de juriste, ce n’est pas non plus un problème de DSI. C’est un problème de jointure entre les deux.

Le travail qui marche, c’est de cadrer la règle au niveau de l’application, pas au niveau du registre. Une règle par application, une justification par règle, une priorité par écart. Tout le reste suit.