Pourquoi supprimer est-il si difficile dans des environnements construits au fil du temps ?
Une cliente apparaît dans le système central, dans le système de sinistres ou de dossiers, dans la comptabilité, dans le CRM et dans l'archive. Les systèmes proviennent de différents éditeurs, certains ont plusieurs décennies, et les données dépendent les unes des autres : un contrat renvoie à une personne, un paiement à un contrat.
Si chaque système supprime de son côté, des lacunes et des contradictions apparaissent. Certains systèmes ont leurs propres raisons de conserver des données plus longtemps. Et sans retour, personne ne sait au final si les données ont vraiment disparu partout. Une suppression manuelle système par système est coûteuse et difficile à prouver.
Que doit faire un pilotage des suppressions ?
| Exigence | Pourquoi |
|---|---|
| Le bon ordre | Les données dépendantes sont supprimées en premier ; il ne reste nulle part de référence à des données déjà supprimées. |
| Objections | Une application peut s'opposer à la suppression parce qu'elle a encore besoin des données. |
| Blocages de suppression | Un legal hold suspend les suppressions pour certains cas, par exemple en cas de litige. |
| Validations | Lorsque le risque l'exige, une personne habilitée valide la suppression avant qu'elle n'ait lieu. |
| Retour | Chaque application confirme ce qu'elle a supprimé. |
| Surveillance | Si un retour manque, une alerte est émise. |
| Journal | Une preuve par cycle de suppression pour la révision et l'autorité de surveillance. |
Piloter de manière centrale, supprimer de manière décentralisée
Chaque application connaît mieux que quiconque sa structure de données et sa logique métier. C'est pourquoi elle devrait supprimer elle-même – via ses fonctions de suppression existantes. Le pilotage central n'intervient pas dans les bases de données : il définit ce qui est supprimé et quand, vérifie et recueille les retours.
Les applications sont connectées via une interface ouverte, par exemple REST, ou par messages, par exemple avec Azure Service Bus. Elles peuvent ainsi être connectées pas à pas, sans tout basculer d'un coup.
Supprimer, anonymiser ou archiver ?
Toutes les applications ne doivent pas réagir de la même manière. Selon le type de données et l'obligation, les données sont supprimées, anonymisées – par exemple lorsqu'elles sont nécessaires pour des statistiques – ou archivées si une obligation de conservation court encore. Un bon pilotage permet de le définir par application et consigne ce qui s'est passé dans chaque cas.
Issu de la pratique
Chez Pax, l'assurance prévoyance suisse dont le siège est à Bâle, Espresso Data Privacy supprime depuis 2024 de manière automatisée dans des systèmes SAP et non SAP – avec des chaînes de suppression qui tiennent compte des dépendances entre applications et objets métier.