Le problème commence lorsqu’une équipe ajoute une règle simple : supprimer les dossiers trois ans après leur création. La première nuit, des contrats encore actifs disparaissent, des exports les réintroduisent et le support découvre que certaines pièces devaient rester disponibles après la clôture. Les utilisateurs perdent leur contexte et la reprise mobilise plusieurs équipes : la durée existait dans une politique, mais le produit ne savait pas l’exécuter.
Le vrai enjeu est de transformer une finalité et une règle de conservation en cycle de vie observable. Il faut définir l’événement de départ, les états, les copies concernées, les exceptions, les droits d’accès et la preuve de sortie. Une date seule ne dit ni ce qui doit disparaître ni ce que l’utilisateur verra ensuite.
Contre-intuitivement, conserver « au cas où » peut casser l’usage futur. Les recherches deviennent bruyantes, les données anciennes faussent les décisions et un support manipule des informations qui ne devraient plus être disponibles. À l’inverse, une purge brutale peut supprimer un contexte nécessaire à un litige, une obligation ou une reprise métier.
Pour une application web métier développée sur mesure, la conservation doit être conçue avec les workflows, pas ajoutée comme un cron final. Ce guide expose une méthode technique et organisationnelle ; les durées et exceptions doivent être validées par les responsables juridiques, métier et protection des données compétents.
Relier la durée à une finalité
Écrire pourquoi la donnée existe
Chaque catégorie reçoit une finalité précise : exécuter un contrat, traiter un dossier, fournir un support, respecter une obligation ou défendre un droit. La durée découle de ce besoin et de la règle applicable. « Historique utile » ou « analytics » est trop vague pour guider une suppression.
L’article 5, paragraphe 1, point e du RGPD pose pour les données personnelles une conservation sous une forme identifiante n’excédant pas ce qui est nécessaire aux finalités, sous réserve des cas prévus. Le texte n’impose pas une durée unique à tous les traitements. L’organisation doit justifier son choix.
Distinguer politique et règle exécutable
La politique décrit catégorie, finalité, durée, déclencheur, sort, exception et autorité. La règle technique traduit ces éléments en événements et requêtes versionnés. Un changement de durée a une date d’effet et une stratégie pour le stock existant ; il ne réécrit pas silencieusement l’histoire.
Cartographier toutes les copies
Le dossier principal n’est qu’un début. L’inventaire suit pièces jointes, tables de liaison, messages, index, cache, exports, journaux, outils de support, data warehouse, sauvegardes et prestataires. Il indique source, propriétaire, identifiant de rapprochement et mode de suppression.
Une copie calculée peut rester personnelle si elle permet encore d’identifier ou de retrouver une personne. Un hash prévisible d’adresse ne garantit pas l’anonymat. Une agrégation très fine peut réidentifier un cas rare. La qualification repose sur le contexte, les moyens raisonnablement disponibles et l’avis compétent.
La CNIL rappelle que les durées doivent être déterminées selon la finalité et distingue notamment base active et archivage intermédiaire lorsque celui-ci est justifié. Le produit rend ces états concrets dans ses droits, écrans et procédures.
Définir le point de départ et l’échéance
« Trois ans » ne suffit pas : depuis création, dernière activité, clôture, fin du contrat, dernier contact ou majorité ? Le déclencheur doit être un événement métier durable, horodaté avec fuseau et version. S’il manque, le dossier entre dans une file de qualification plutôt que de recevoir une date inventée.
Les réouvertures et renouvellements sont explicites. Un ticket rouvert peut créer une nouvelle période pour certains échanges sans repousser toutes les pièces historiques. Une action mineure ne doit pas réinitialiser artificiellement l’horloge du dossier complet.
Traiter calendriers et précision
La règle précise jours calendaires ou échéance métier, fuseau, fin de mois et traitement des dates impossibles. Le batch sélectionne une cohorte stable. Une exécution retardée conserve l’échéance d’origine afin que le monitoring montre le retard au lieu de le masquer.
Séparer base active, archive et suppression
La base active sert l’usage courant. Une archive intermédiaire, lorsqu’elle est justifiée, restreint l’accès à une finalité distincte et à des personnes habilitées. La suppression ou anonymisation clôt l’état identifiant. Déplacer dans une table « archive » sans changer droits ni usages ne constitue pas une réelle séparation.
L’interface explique le passage : un dossier n’apparaît plus dans la recherche opérationnelle, mais une personne autorisée peut éventuellement ouvrir une archive pour le motif prévu. Le support ne contourne pas cette frontière avec un accès base. Les actions et exports respectent le statut.
Le modèle conserve un identifiant technique de preuve seulement si nécessaire et proportionné. Il évite une « tombstone » contenant toutes les anciennes valeurs. L’état supprimé peut enregistrer règle, date, version et compte agrégé sans recréer le dossier.
Préserver l’usage sans conserver par défaut
Avant purge, l’équipe liste les décisions qui utilisent encore la donnée. Un calcul peut être figé dans un résultat explicable sans garder tous les détails. Une référence peut devenir un libellé non identifiant. Une statistique peut être agrégée à un niveau réellement compatible avec la finalité.
La recherche doit distinguer « aucun dossier » de « dossier sorti de la base active ». Révéler qu’une personne possédait une donnée supprimée peut déjà être sensible ; le message dépend donc du rôle. L’utilisateur métier reçoit une action suivante, pas une erreur SQL ou une réactivation cachée.
Concevoir les documents et exports
Un PDF téléchargé quitte le contrôle direct de l’application. Le produit limite génération, contenu, durée d’accès et destinataires, puis rappelle la responsabilité de la copie. Il n’annonce pas qu’une suppression serveur efface les fichiers déjà remis à des acteurs légitimes.
Propager la politique aux dépendances
Une suppression publie un événement versionné avec catégorie, identifiant opaque, règle et résultat attendu. Chaque consommateur confirme ou retourne une erreur. L’idempotence permet de rejouer sans recréer l’objet. Une file d’échec conserve la preuve minimale, pas le contenu supprimé.
Les prestataires reçoivent obligations, délais, formats et moyens de vérification dans les contrats pertinents. L’API de suppression et la politique du fournisseur sont testées avant le go. Un statut 200 signifie que la demande a été acceptée ou exécutée selon le contrat ; l’équipe ne lui attribue pas une preuve qu’il ne fournit pas.
Les systèmes analytiques et moteurs de recherche sont souvent oubliés. La donnée peut y être dénormalisée sous plusieurs clés. Un catalogue relie les copies à la source et mesure le temps jusqu’à disparition. L’absence d’un connecteur bloque l’automatisation générale ou impose une étape gouvernée.
Articuler purge et demandes de droits
Une demande d’accès, de rectification ou d’effacement suit un workflow propre. Elle ne se confond pas avec la purge planifiée, même si les deux réutilisent inventaire et connecteurs. L’équipe vérifie identité, périmètre, base juridique, exceptions et réponse avec les responsables compétents.
L’article 17 du RGPD encadre le droit à l’effacement et prévoit aussi des situations où il ne s’applique pas. Le système n’exécute donc pas un bouton « droit à l’oubli » sans qualification. Il garde le motif de décision et limite la preuve à ce qui est nécessaire.
Éviter de ressusciter une donnée
Une synchronisation entrante peut recréer le dossier après effacement. Le contrat indique si la source reste autorisée à l’envoyer. Une liste de suppression minimale ou un changement dans la source peut être nécessaire, avec sa propre durée et ses propres droits. Le choix est analysé plutôt qu’automatique.
Gouverner gels et exceptions
Un contentieux, une enquête ou une obligation peut suspendre la purge d’une cohorte. Le gel possède autorité, motif, périmètre, date de revue et accès restreint. Il ne transforme pas toute la base en archive permanente. À sa levée, le moteur recalcule le sort depuis l’échéance originale.
Une exception technique — connecteur indisponible, corruption ou absence d’identifiant — entre dans une file avec owner et délai. Elle ne repousse pas silencieusement la date de conservation. Le tableau sépare gel légitime et échec opérationnel.
Les seuils sont locaux. Le pilote peut arrêter le lot si une proportion anormale d’erreurs apparaît ou si la cohorte dépasse la capacité de rapprochement humain. Le chiffre est calibré sur les essais, la criticité et la réversibilité, jamais copié d’un autre produit.
Choisir suppression ou anonymisation
Supprimer retire la donnée ciblée. Anonymiser vise à rendre la personne non identifiable de manière irréversible dans le contexte considéré. Remplacer le nom par un identifiant stable ou chiffré est généralement une pseudonymisation si une table, une clé ou des recoupements permettent le retour.
L’équipe évalue unicité, attributs indirects, petits groupes, données externes et évolution des moyens. Elle documente l’utilité restante et le risque de réidentification. Une agrégation par mois et segment peut suffire à piloter le produit ; conserver chaque parcours pseudonymisé « pour la science » demande une justification propre.
Tester les contraintes référentielles
La suppression d’un acteur ne doit pas casser une comptabilité ou l’historique d’une décision. Le modèle peut conserver un rôle générique, un résultat et une date sans les attributs de la personne. Les clés étrangères, documents et journaux sont adaptés en recette sur des cas anciens et incomplets.
Traiter sauvegardes, caches et journaux
Une sauvegarde immuable n’est pas une base active. Sa durée, son accès et sa restauration sont bornés. Le runbook prévoit qu’une restauration ancienne rejoue les suppressions intervenues depuis ou isole la donnée jusqu’au rattrapage. Restaurer ne doit pas republier immédiatement des dossiers arrivés à échéance.
Les caches expirent et peuvent être invalidés par identifiant. Les journaux suivent une rétention distincte et minimisent les données dès l’écriture. Une trace d’audit peut conserver l’action et le résultat sans le document. Les environnements de test n’obtiennent pas une copie illimitée sous prétexte de diagnostic.
Les sauvegardes sont testées avec le registre des suppressions. L’exercice restaure une date antérieure, applique les événements manquants, puis vérifie qu’un échantillon supprimé ne redevient ni recherchable ni exportable. La preuve porte sur le processus, pas sur une promesse absolue d’effacement bit à bit instantané de tous les supports.
Prouver l’exécution sans garder la donnée
Le journal de purge contient job, version de règle, cohorte, compte de succès, erreurs, horodatage et systèmes concernés. Pour un dossier individuel, un identifiant opaque ou une empreinte soigneusement évaluée peut aider au rapprochement, mais il ne doit pas permettre de reconstruire la valeur ou de contourner la suppression.
Le monitoring suit dossiers échus encore actifs, âge de la plus vieille anomalie, connecteurs en retard et gels à revoir. Une absence de ligne n’est pas toujours une preuve de suppression : elle peut signaler un import manquant. La recette part d’une donnée sentinelle connue et vérifie chaque frontière.
Une personne non auteure doit pouvoir expliquer pourquoi un dossier est actif, archivé, gelé ou supprimé, puis rejouer l’échec d’un connecteur. Cette autonomie vaut davantage qu’une capture ponctuelle d’un tableau vert.
Cas concret : archiver un dossier clôturé
Cas hypothétique. Une plateforme gère des demandes avec pièces justificatives. Le métier a besoin du dossier pendant son traitement ; une obligation validée impose ensuite une conservation restreinte. Le pilote couvre 1 200 dossiers, dont 80 sentinelles de recette, par lots de 50. Ces volumes servent à éprouver verrous et reprise sur ce système, pas à recommander un batch universel. À la clôture, le workflow fixe l’échéance, retire le dossier des files actives et prépare son passage en archive.
Le jour venu, le job vérifie l’absence de gel, déplace les éléments nécessaires dans un espace à droits réduits et supprime les copies de travail. Les index et caches reçoivent l’événement. Les statistiques gardent des comptes agrégés, pas les pièces. L’écran opérationnel affiche seulement que le dossier n’est plus disponible dans ce contexte.
Un connecteur documentaire refuse trois suppressions. Le lot n’est pas déclaré réussi. Les trois cas restent dans une file d’exception, sans réactiver le dossier complet. Le support peut voir le motif technique ; l’owner et le responsable de traitement décident de la suite, éclairés par le DPO ou le conseil compétent. Après correction, l’idempotence permet de rejouer seulement les systèmes manquants.
Lors d’une restauration de sauvegarde, le registre d’événements réapplique les sorties survenues depuis le snapshot avant l’ouverture aux utilisateurs. Le test confirme que la pièce sentinelle reste absente. La durée exacte n’est pas fournie par cet exemple : elle dépend de la finalité et du cadre validé pour le traitement.
Pour qui et dans quels cas appliquer cette méthode
Le métier nomme finalité, événements et besoin opérationnel. Le responsable de traitement arrête et assume le cadre applicable ; le DPO ou le conseil compétent l’informe et le conseille dans son champ. Le produit traduit les états dans l’expérience. Les développeurs et la plateforme implémentent connecteurs, permissions, monitoring, sauvegardes et reprise.
Les owners de systèmes attestent les copies et la suppression. Le support explique le statut sans ouvrir une archive hors motif. L’audit vérifie règles, versions, exceptions et exercices. Un fournisseur documente son comportement et ses délais plutôt que de recevoir une demande informelle.
L’utilisateur sait, dans une forme adaptée, pourquoi une donnée est demandée et ce qu’il advient. Ce texte ne remplace pas les informations obligatoires ni l’analyse juridique. Il évite que l’interface promette une suppression immédiate que l’architecture ne sait pas tenir.
Éviter les erreurs de conservation
- Compter depuis la création par défaut : le dossier peut être encore actif ou l’événement pertinent survenir plus tard.
- Archiver sans restreindre : la table change de nom, mais les utilisateurs, recherches et exports restent identiques.
- Anonymiser seulement le nom : les attributs rares et les identifiants stables permettent encore un rapprochement.
- Oublier les dépendances : l’index ou l’outil support recrée la donnée après le passage du job principal.
- Effacer la preuve avec le dossier : personne ne peut expliquer une erreur ni confirmer l’exécution du processus.
- Conserver la donnée dans la preuve : le journal de purge devient une nouvelle base personnelle sans durée claire.
Une autre erreur consiste à intégrer la purge sans mode dégradé. Un batch lent peut bloquer la base, un connecteur peut limiter son débit et une contrainte peut casser. Les lots, seuils d’arrêt, retries et files d’exception sont dimensionnés sur le terrain.
Arbitrer quand les besoins se contredisent
Si la finalité courante disparaît et qu’aucune règle ne justifie une archive, la suppression ou anonymisation adaptée est prioritaire. Si une obligation ou un droit exige une conservation, l’accès et l’usage changent. Si une analyse statistique reste utile, l’équipe cherche le niveau d’agrégation minimal avant de conserver des lignes pseudonymisées.
Une incapacité technique n’est pas une nouvelle finalité. Elle devient une dette datée avec réduction de risque, owner et plan. À l’inverse, un besoin métier non documenté ne repousse pas automatiquement toutes les échéances. L’autorité compétente arbitre sur des faits : population, conséquence, copies et alternatives.
Si la finalité opérationnelle est close et qu’aucun gel validé n’existe, alors garder le dossier en base active est refusé. En revanche, si une obligation justifie une archive, l’accès, l’index et les exports doivent changer en même temps. Dans ce cas, déplacer la ligne sans réduire les usages ne produit pas le résultat attendu.
Si l’analyse peut fonctionner sur des agrégats, l’équipe privilégie ce format plutôt qu’une pseudonymisation ligne à ligne. Plutôt que lancer une purge globale, le pilote exige 100 % des sentinelles absentes de la recherche, zéro réapparition après restauration et un verdict explicite pour chaque connecteur. Ces seuils sont locaux au parcours testé.
Ordonner la décision de sortie
D’abord, fixer finalité et déclencheur. Ensuite, cartographier la donnée et ses copies. Puis, jouer archivage, suppression, exception et restauration. Enfin, mettre en production par cohorte avec monitoring et preuve, avant d’élargir les règles.
- D’abord, refuser toute durée sans finalité, déclencheur et autorité de validation.
- Ensuite, tester l’état actif, l’archive et la sortie sur des sentinelles documentées.
- Puis, contrôler chaque dépendance et reprendre uniquement les connecteurs en erreur.
- Enfin, valider la restauration et le verdict métier avant d’ouvrir une nouvelle catégorie.
Fermer le contrat technique de purge
Les entrées sont catégorie, finalité, événement, règle, gel et dépendances. Les sorties sont état, suppression, anonymisation ou archive avec verdict par système. Le moteur est versionné et idempotent. La journalisation minimise ; le monitoring couvre backlog, erreurs, latence et fraîcheur.
Les tests construisent dossiers actifs, échus, rouverts, gelés, incomplets et déjà supprimés. Ils vérifient permissions, contraintes, index, cache, export et prestation simulée. Un test de charge mesure verrous et durée sur des volumes représentatifs. Le lot s’arrête avant d’affecter les parcours en ligne selon une marge locale.
Le rollback d’une règle stoppe les futurs lots ; il ne restaure pas automatiquement une donnée supprimée. Cette irréversibilité est assumée et testée en amont. Pour une migration d’état réversible, l’équipe conserve temporairement une source contrôlée avec une date de sortie, sans la confondre avec la purge finale.
Concrètement, un premier job calcule la cohorte et produit un aperçu signé par la version de règle. Un second exécute les transitions par lots idempotents. Les consommateurs renvoient leur verdict dans une table minimale. Un drapeau coupe la sélection ou l’exécution séparément ; le runbook donne la requête de backlog, le seuil d’arrêt et la procédure de reprise d’un seul connecteur.
Plan d’action sur six semaines
Semaines 1 et 2 : choisir deux catégories
L’équipe suit un dossier et un document de leur collecte aux sauvegardes. Elle valide finalité, déclencheur, durée et exceptions avec les responsables. Les copies sans owner sont qualifiées. Des sentinelles de recette permettent de prouver le futur retrait sans utiliser de données réelles.
Semaines 3 et 4 : construire le cycle
Les états actif, archivé, gelé et sorti sont codés. Le job produit un aperçu, des lots bornés et un verdict par dépendance. Index, cache et outils support reçoivent l’événement. Les écrans expliquent l’indisponibilité sans révéler une donnée supprimée.
Semaines 5 et 6 : exercer les ruptures
Le pilote coupe un connecteur, injecte une erreur, lève un gel et restaure une sauvegarde ancienne. Une personne non auteure reprend la file. Le métier confirme l’usage restant et l’équipe de protection des données contrôle la cohérence du cadre.
La revue compare dossiers échus, délai de sortie, erreurs, coût et tickets. Elle révise les seuils sur les volumes observés. Aucun nouveau domaine n’entre tant que le premier ne sait pas expliquer ses exceptions et son comportement après restauration.
Chaque semaine livre une preuve : carte des copies, catalogue de règles, jeu sentinelle, résultat de dry-run, matrice des droits d’archive et compte rendu de restauration. Le comité relit un dossier actif, un archivé, un gelé et un supprimé. Il refuse toute catégorie dont le statut dépend d’une requête manuelle non versionnée.
À la clôture, une équipe non auteure coupe le connecteur documentaire, reprend les erreurs puis restaure un snapshot antérieur. Elle doit empêcher la publication des dossiers arrivés à échéance et confirmer les sentinelles. Si la procédure demande d’ouvrir la base avec des droits permanents, le pilote reste limité.
- À valider : finalité, déclencheur, sort et autorité pour chaque catégorie du pilote.
- À bloquer : connecteur sans verdict, archive aux droits inchangés ou sentinelle réapparue après restauration.
- À documenter : gels, erreurs de purge, délais locaux et preuve minimale conservée.
Relier données, workflow et run
Le diagnostic technique applicatif permet de retrouver copies et dépendances avant de coder la politique. Le guide d’observabilité des workflows métier aide à rendre échéance, état et file d’exception visibles sans journaliser le dossier.
Le test des workflows et exceptions sert à vérifier gel, reprise et connecteur défaillant. La conservation devient ainsi une fonction exercée du produit, et non une formule isolée dans un registre.
Conclusion : faire de la sortie une fonction
Une durée de conservation utile relie une finalité, un événement de départ, un état, des accès et un sort. Elle traverse exports, index, journaux et sauvegardes. L’archivage n’est pas un déplacement de table, et l’anonymisation n’est pas un simple masquage de nom.
La mise en œuvre garde aussi ses limites juridiques visibles. Une suppression planifiée ne remplace pas le traitement d’une demande de droit ; une incapacité technique ne crée pas une finalité ; une archive ne peut pas rester ouverte à tous. Les responsables compétents valident durées, gels et bases applicables pendant que le produit rend leurs décisions exécutables.
La preuve décisive est une reprise exercée : après une restauration, les données sorties ne redeviennent pas utilisables et les exceptions restent explicables. Dawap peut concevoir ce cycle dans une mission de développement web métier sur mesure, avec un accompagnement expert jusqu’à la purge, au mode dégradé et au verdict partagé.
