Une politique de conservation et de suppression ne se met pas en œuvre avec une seule instruction DELETE. Dans une application PHP, une même information peut figurer dans plusieurs tables, fichiers, caches, journaux et services externes. Si le processus ne supprime que la ligne principale, des copies actives peuvent subsister ; s’il supprime sans vérifier les dépendances, il peut perturber des opérations ou effacer des données qui devaient être conservées.
L’objectif pratique consiste à traduire chaque règle en un processus qui identifie les données concernées, applique l’action appropriée, gère les exceptions et laisse des éléments vérifiables. La politique doit être convenue avec les équipes responsables du produit, de la technologie et des données, puis confrontée aux obligations applicables à l’activité. Il ne convient pas de déduire des durées légales universelles : elles dépendent du contexte et doivent être validées avant toute automatisation.
Commencez par les catégories et les règles de conservation
Avant de concevoir la suppression, classez les informations selon leur finalité et leur usage. Un profil, une adresse nécessaire à une opération en cours, un historique d’activité et un enregistrement comptable peuvent être soumis à des règles différentes, même s’ils sont liés au même compte.
Pour chaque catégorie, documentez au minimum :
- Finalité et responsable : pourquoi les données sont stockées et quelle équipe décide de leur conservation.
- Événement déclenchant la règle : par exemple, la clôture d’un compte, l’expiration d’une relation ou une demande validée.
- Durée et condition : quand l’action est examinée ou exécutée, y compris les éventuelles suspensions justifiées.
- Action : supprimer, anonymiser, conserver avec un accès restreint ou soumettre à un examen manuel.
- Dépendances : les systèmes et processus qui doivent être achevés avant que le dossier soit déclaré résolu.
« Conserver » ne signifie pas garder indéfiniment par commodité. Il faut une raison, un périmètre et une date ou une condition de réexamen. Si une partie des informations doit être conservée pour répondre à un besoin opérationnel, séparez cet ensemble du reste et limitez les personnes qui peuvent y accéder.
Inventoriez les copies, les références et les systèmes connectés
L’inventaire doit suivre le parcours réel des données, et pas seulement le schéma de la base de données. Examinez les tables liées, les champs JSON, les fichiers téléversés, les exports, les index de recherche, les caches, les files d’attente, les journaux de l’application et les systèmes intégrés. Incluez également les flux qui génèrent des copies : rapports, outils d’assistance, analytique ou processus d’importation.
Pour chaque emplacement, notez quel identifiant permet de retrouver les données, qui en est responsable, comment les supprimer ou les mettre à jour et ce qui se passe si le système est indisponible. Examinez les relations au moyen des clés étrangères et de la logique de l’application : une relation dans la base de données peut empêcher une suppression en cascade, tandis qu’une suppression en cascade peut effacer plus de données que prévu.
Traitez les sauvegardes comme un cas distinct. Il se peut qu’elles ne permettent pas de supprimer un élément individuellement sans restaurer la sauvegarde complète. Définissez les modalités de restriction de leur accès, leur durée de conservation et la procédure qui empêche des données supprimées de revenir dans les systèmes actifs après une restauration. Documentez la décision et validez-la avec les responsables de l’infrastructure et de la conformité.
Décidez quand supprimer, anonymiser ou conserver
La suppression physique retire les données d’un système actif, mais ce n’est pas toujours la bonne option pour chaque enregistrement. L’anonymisation peut convenir lorsqu’il faut conserver des informations statistiques et qu’il est possible de supprimer effectivement toute possibilité de les relier à une personne. Remplacer un nom par un identifiant stable ne suffit pas s’il existe une autre table permettant de reconstituer le lien.
La conservation avec accès restreint peut convenir aux données encore nécessaires à une opération ou au respect d’une obligation validée. Maintenez ces éléments séparés, avec des autorisations spécifiques et une règle de réexamen. S’il est impossible de déterminer avec certitude l’action à appliquer — par exemple en raison d’un litige, d’une dépendance inconnue ou d’une incohérence d’identité —, placez le dossier dans une file d’examen au lieu d’improviser.
Il faut également examiner les conséquences fonctionnelles : que deviennent les commandes, abonnements, tickets, clés d’API ou documents partagés lorsqu’un compte disparaît ? Le comportement doit être explicite et cohérent dans l’interface, la logique PHP et les services connectés.
Mettez en place un processus idempotent et observable
Un processus de suppression s’exécute généralement en arrière-plan, dans une file d’attente ou au moyen d’une tâche planifiée. Représentez le dossier par des états explicites, par exemple : demandé, validé, en cours, en attente de systèmes externes, terminé ou à examiner. Définissez les transitions autorisées et les personnes habilitées à relancer le traitement ou à clôturer une exception.
L’idempotence est essentielle : répéter une étape ne doit ni dupliquer ses effets ni causer de dommages. Avant de supprimer un fichier, vérifiez qu’il existe ; lors du traitement d’une demande, vérifiez son état actuel ; lors d’un appel à un service externe, utilisez des mécanismes d’idempotence s’ils sont disponibles. Si vous ne pouvez pas le garantir, enregistrez la réponse et concevez un mécanisme de rapprochement avant toute nouvelle tentative à l’aveugle.
Un schéma conceptuel en PHP pourrait séparer l’orchestration des actions propres à chaque système :
foreach ($steps as $step) {
if ($step->isComplete($requestId)) {
continue;
}
$step->execute($subjectReference);
$step->markComplete($requestId);
}Cet exemple ne résout pas les transactions distribuées : une base de données et un fournisseur externe ne partagent pas nécessairement une transaction. Enregistrez la progression de manière fiable, gérez les erreurs à chaque étape et permettez la reprise du traitement. Si une opération échoue en cours de route, l’état doit indiquer ce qu’il reste à faire ; le dossier ne doit pas être présenté comme terminé.
Consignez l’exécution sans créer une autre copie de données personnelles
La traçabilité permet de savoir quelle personne ou quel processus a agi, quand, sur quelle demande et avec quel résultat. Consignez les identifiants internes des opérations, les états, les étapes et les codes d’erreur utiles au diagnostic. Évitez de copier les noms, adresses e-mail, documents, contenus de fichiers ou charges utiles complètes d’API dans les journaux.
Un identifiant utilisateur pseudonyme peut rester sensible s’il permet de réidentifier une personne. Restreignez l’accès aux journaux, limitez leur durée de conservation et séparez autant que possible les informations opérationnelles de l’identité. Les messages d’erreur doivent aider à localiser le système concerné sans exposer de données personnelles dans les outils de supervision.
Vérifiez le résultat et préparez le traitement des exceptions
Les tests doivent couvrir à la fois le cas normal et les défaillances partielles. Utilisez des données de test et vérifiez les emplacements recensés dans l’inventaire, pas seulement la table principale. Incluez des scénarios tels qu’une relation qui empêche la suppression, un fichier absent, un fournisseur externe indisponible, une nouvelle tentative et une exception nécessitant un examen.
Une liste de contrôle opérationnelle utile pose les questions suivantes : chaque copie connue a-t-elle été localisée ? L’action prévue a-t-elle été appliquée à chaque catégorie ? Une étape est-elle encore en attente ? Les systèmes externes ont-ils confirmé le résultat ? Les journaux ne contiennent-ils que les informations nécessaires ? Une nouvelle tentative préserve-t-elle la sécurité du processus ? Ajoutez des vérifications périodiques pour détecter de nouvelles tables, intégrations ou voies de circulation des données absentes de l’inventaire.
Exemple hypothétique : clôture d’un compte
Supposons qu’une personne demande la clôture de son compte dans une application PHP. Le processus valide la demande et consulte les règles définies pour le profil, les fichiers, l’activité et les informations liées aux opérations en cours. Le profil et les fichiers pouvant être supprimés le sont ; certains enregistrements sont conservés avec un accès restreint si une raison approuvée le justifie ; les données destinées à l’analyse ne sont conservées que si elles ont été anonymisées de manière effective.
L’application consigne chaque étape sans inclure l’adresse e-mail ni le contenu des fichiers. Si un service externe ne répond pas, le dossier reste en attente et un processus ultérieur effectue une nouvelle tentative ou demande une intervention selon la politique. Il n’est déclaré terminé que lorsque toutes les actions requises ont été confirmées ou qu’une exception formelle a été documentée et approuvée.
Avant la mise en œuvre, tranchez les questions encore ouvertes : quels systèmes contiennent les données, qui autorise les exceptions, que signifie « terminé » pour chaque destination, comment traiter les sauvegardes et qui examine les échecs. Cette définition transforme une intention de suppression en un processus maintenable, vérifiable et sûr.
