La suppression logique masque une donnée active tout en conservant une trace, mais elle exige des règles claires pour les recherches, les droits et la conservation.
Supprimer une fiche client ou une commande peut avoir des conséquences sur les factures, les rapports et les audits. Une suppression logique ajoute un état comme « archivé » ou « supprimé » afin d’empêcher l’usage courant tout en conservant les éléments nécessaires à une vérification.
Cette approche ne convient pas à tous les contenus. Certaines données doivent être supprimées ou anonymisées après une durée définie. D’autres doivent rester accessibles pour prouver une opération. Décidez d’abord la finalité de la conservation, puis choisissez le mécanisme technique.
Définir les états de fin de vie
Un champ booléen peut suffire pour un cas simple, mais il ne décrit pas toujours la raison ni la date. Un statut explicite peut distinguer actif, archivé, supprimé et bloqué. Chaque état doit indiquer les actions autorisées et les relations qui restent disponibles.
Un dossier archivé peut rester visible dans un historique mais disparaître des listes de travail. Un dossier supprimé peut être réservé à un administrateur ou remplacé par une référence anonymisée. Ces choix doivent apparaître dans les critères d’acceptation.
Une suppression peut être demandée par l’utilisateur, par un traitement de conservation ou après la clôture d’un compte. Enregistrez l’origine de la décision et la date d’effet. Une date de suppression ne doit pas être confondue avec la date de dernière modification du contenu.
Protéger les recherches ordinaires
Les requêtes habituelles doivent exclure les données inactives avec une règle commune. Si chaque écran ajoute son propre filtre, un oubli peut réafficher une donnée supprimée. Centralisez la portée active lorsque le framework et le modèle le permettent, puis prévoyez une requête explicite pour l’administration.
Les exports, rapports, suggestions et recherches plein texte doivent suivre la même règle. Un enregistrement absent d’une liste mais présent dans l’index peut encore être révélé par une recherche. Reconstruisez ou retirez l’index quand l’état change, selon le délai acceptable.
Le cache doit inclure l’état ou être invalidé lors de l’archivage. Une réponse mise en cache peut afficher un dossier après sa suppression. Le délai d’invalidation doit correspondre au risque du parcours, surtout pour les données sensibles.
Gérer les relations
Une fiche client peut être référencée par une facture. La supprimer physiquement peut casser un historique comptable. L’archiver peut conserver la référence et empêcher de nouvelles commandes. Documentez le comportement des relations avant de choisir une contrainte de suppression.
Une commande annulée ne doit pas réapparaître comme disponible parce qu’un parent a été restauré. La restauration doit vérifier les dépendances, les droits et l’état actuel. Elle peut être interdite lorsque des opérations ont évolué entre la suppression et la demande de récupération.
Les fichiers attachés suivent leur propre durée de vie. Masquer un document métier sans supprimer son fichier peut laisser une copie accessible dans le stockage. Reliez les règles de l’objet et du fichier, avec une procédure de vérification après suppression.
Contrôler les droits et les restaurations
La suppression doit demander un droit spécifique lorsque son effet est large. Une confirmation peut afficher les dépendances qui seront archivées. Un utilisateur ne doit pas pouvoir restaurer une fiche dans un état qui contourne une validation ou une séparation entre entreprises.
Dans un SaaS multi entreprise, le filtre d’appartenance s’applique aussi aux données supprimées. L’administrateur d’une entreprise ne doit pas rechercher les archives d’un autre espace. Les règles d’isolation des données clients doivent couvrir les états inactifs et les restaurations.
Un accès de support peut être temporaire et doit être journalisé. Le journal d’audit conserve qui a supprimé, restauré ou consulté la donnée. Évitez d’y recopier une information que la suppression devait justement protéger.
Automatiser la conservation avec précaution
Un traitement périodique peut supprimer ou anonymiser les données dont la durée est dépassée. Avant l’automatisation, produisez un rapport des éléments candidats et demandez une vérification sur un environnement représentatif. Une date mal interprétée peut toucher beaucoup de dossiers.
La conservation doit prendre en compte les sauvegardes. Une suppression en production ne retire pas forcément une copie ancienne. Documentez la durée de vie des sauvegardes et la procédure lorsqu’une restauration remettrait des données qui doivent rester supprimées.
Un export de conformité doit indiquer les états et les dates sans réactiver les données. Les rapports doivent conserver une définition stable lorsque le nombre de dossiers actifs diminue. Séparez les indicateurs d’activité courante des archives.
Tester les cas difficiles
Testez l’archivage depuis chaque rôle, la recherche directe par identifiant, les exports, les notifications planifiées et les traitements différés. Testez une restauration après la modification d’une donnée liée et une suppression pendant qu’un utilisateur a le dossier ouvert.
Vérifiez les données de cache, l’index plein texte et les fichiers. Contrôlez aussi les sauvegardes avec une restauration isolée. Les effets attendus doivent être écrits avant la mise en service, avec une personne responsable des exceptions.
La suppression logique est un outil de cycle de vie. Elle sert quand l’entreprise doit retirer une donnée du travail courant tout en conservant une preuve ou une possibilité de traitement. Ses limites deviennent gérables quand les états, les relations, les droits et la conservation sont définis ensemble.
Sources : OWASP, protection des données, CNIL, durée de conservation.