Pouvez-vous supprimer les données lorsque vous en avez besoin ? Une checklist de conservation et de suppression pour les applications auto-hébergées

Pourquoi la suppression est une exigence de sélection d’application, et pas seulement une tâche liée à la politique de confidentialité

Une application peut être facile à déployer, à exporter et à sauvegarder, tout en restant difficile à gouverner lorsque des informations doivent être supprimées. La question pratique n’est pas simplement de savoir si l’interface comporte un bouton Supprimer. Il s’agit de déterminer si votre équipe peut localiser les données concernées, appliquer la règle de conservation appropriée, préserver les exceptions justifiées et produire des éléments de preuve de ce qui s’est passé.

Cela concerne les données personnelles, mais c’est aussi un enjeu opérationnel pour les dossiers clients, les données des employés, les fichiers téléversés, les commentaires, les identifiants, les documents de projet et les informations de diagnostic. Les [orientations de la Commission européenne sur le RGPD](https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/principles-gdpr_en) décrivent la limitation de la conservation comme le fait de ne pas conserver les données personnelles plus longtemps que nécessaire et d’établir des délais pour les effacer ou les réexaminer. C’est un principe opérationnel utile, même lorsque le RGPD n’est pas le seul cadre applicable à votre organisation.

Considérez la capacité de suppression comme un critère d’adoption. Évaluez-la durant un essai ou une preuve de concept, lorsque vous pouvez encore choisir une autre application ou concevoir des contrôles compensatoires. Ne supposez pas que l’auto-hébergement simplifie la suppression : les données peuvent être réparties entre la base de données de l’application, le stockage persistant, les sauvegardes, les journaux et les services connectés.

• Faites de la conservation et de la suppression un critère d’acceptation documenté, au même titre que le contrôle des accès, les exports, la sauvegarde et la restauration.
• Évaluez les composants réellement déployés, et pas seulement la documentation du produit ou les libellés de l’interface.
• Exigez un test reproductible avec des données d’exemple avant de placer des informations de production dans le système.
• Soumettez les questions de conservation juridiques, contractuelles et propres à votre secteur aux conseillers internes ou externes compétents.

Commencez par un inventaire des données : enregistrements, fichiers, commentaires, profils utilisateurs, événements d’audit, journaux, exports et données dérivées

Vous ne pouvez pas supprimer de manière fiable les informations que vous n’avez pas cartographiées. Établissez un inventaire autour des types de données et des copies, plutôt que de vous appuyer sur une seule catégorie telle que les « données clients ». Commencez par ce que les utilisateurs peuvent voir, puis remontez les parcours techniques qui traitent, répliquent ou conservent ces données.

Pour chaque catégorie, consignez l’emplacement dans le système, le propriétaire des données, la finalité, la règle de conservation, la méthode de suppression, les rôles d’accès, les intégrations, le traitement dans les sauvegardes et la source des éléments de preuve. Les [orientations du NIST sur la gestion des journaux](https://nvlpubs.nist.gov/nistpubs/legacy/SP/nistspecialpublication800-92.pdf) rappellent utilement que la conservation et l’élimination s’appliquent aux couches système et infrastructure ; les données applicatives ne constituent pas à elles seules l’inventaire complet.

Incluez les copies dérivées et opérationnelles. Un nom ou un identifiant peut apparaître dans un commentaire, le nom d’un fichier joint, une feuille de calcul exportée, une notification, un index de recherche, une entrée de cache ou des métadonnées de journal. La [documentation Docker](https://docs.docker.com/engine/logging/configure/) indique également que certains pilotes de journalisation peuvent ajouter les valeurs de variables d’environnement et de labels des conteneurs dans la sortie des journaux ; examinez donc ce que votre déploiement place dans ces champs.

• Enregistrements principaux : contacts, transactions, projets, tickets, contenus, formulaires et objets métier.
• Données liées aux utilisateurs : profils, identifiants d’authentification, rôles, préférences et statut du compte.
• Contenu généré par les utilisateurs : téléversements, pièces jointes, commentaires, révisions, images et documents intégrés.
• Données opérationnelles : événements d’audit, journaux applicatifs, journaux de conteneurs, journaux de base de données, rapports d’erreur et métriques lorsque cela est pertinent.
• Copies dérivées : exports, rapports, index de recherche, caches, aperçus, notifications et charges utiles de tâches d’arrière-plan.
• Copies de stockage et de résilience : dumps de base de données, volumes persistants, instantanés de stockage de fichiers et archives de sauvegarde.
• Copies externes : fournisseurs d’e-mail, fournisseurs d’identité, destinataires de webhooks, plateformes d’analytique, outils d’automatisation et stockage objet.

Définissez les événements qui déclenchent la conservation, la suppression, l’anonymisation ou une obligation de conservation légale

Un calendrier de conservation doit être fondé sur des événements. « Conserver pendant deux ans » est incomplet si personne ne comprend quand le délai commence, ce qui y met fin, qui approuve une exception et comment la règle est exécutée. Parmi les événements déclencheurs courants figurent la clôture d’un compte, la fin d’un contrat, l’achèvement d’un projet, le retrait du consentement, la clôture d’un travail de support et une demande de suppression approuvée.

Distinguez la suppression de l’anonymisation. La suppression vise à retirer les données identifiées dans le périmètre système défini. L’anonymisation peut permettre à un enregistrement de rester utile pour le reporting uniquement s’il ne permet plus d’identifier une personne dans le contexte concerné. Ne qualifiez pas d’anonymisation la simple suppression d’un nom d’affichage sans évaluer les champs restants et leur possibilité de mise en relation.

Définissez aussi les procédures d’obligation de conservation légale (« legal hold »), ou de préservation dans le cadre d’un litige, avant qu’un cas urgent ne survienne. L’[article 17 du RGPD](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679) établit un droit à l’effacement dans certaines circonstances, mais il est conditionnel et non absolu. Les [orientations du NIST](https://nvlpubs.nist.gov/nistpubs/legacy/SP/nistspecialpublication800-92.pdf) demandent de la même manière que les demandes de préservation précisent comment les enregistrements de journaux concernés sont marqués, stockés et protégés. Votre flux de travail doit prévoir un moyen documenté de suspendre la destruction courante lorsqu’une obligation valide s’applique, tout en limitant la préservation aux informations concernées et en la réexaminant périodiquement.

• Pour chaque classe de données, définissez : l’événement déclencheur, la période de conservation ou l’intervalle de révision, l’action, l’approbateur, le circuit d’exception et les éléments de preuve conservés.
• Indiquez si l’action est une suppression définitive, un archivage, une conservation restreinte, une anonymisation ou une pseudonymisation.
• Consignez le périmètre d’une obligation de conservation légale : dossiers concernés, sources de données, date de début, dépositaire, restrictions d’accès et date de révision.
• Journalisez la raison lorsqu’une demande de suppression est refusée, retardée ou seulement partiellement exécutée.
• Définissez comment une obligation de conservation légale prend fin et comment le traitement normal du cycle de vie reprend ensuite.

Testez ce que signifie « supprimer » dans l’application : suppression logique, effacement définitif, archivage et désactivation de compte

Les termes d’une interface ne constituent pas des garanties techniques. « Supprimer », « retirer », « archiver », « désactiver » et « désactiver un compte » peuvent produire des résultats très différents. Un élément supprimé peut être masqué pour les utilisateurs ordinaires tout en restant disponible pour les administrateurs ; un compte peut ne plus pouvoir se connecter alors que son profil et son contenu restent intacts ; une archive peut intentionnellement conserver l’enregistrement complet.

Effectuez un test contrôlé avec des données synthétiques et identifiables de façon unique. Créez un enregistrement, des commentaires associés, une pièce jointe et un compte utilisateur lorsque l’application le permet. Exécutez ensuite chaque action disponible et examinez les résultats attendus côté utilisateur et côté administration. Testez les limites des rôles : les utilisateurs ordinaires, les responsables, les administrateurs et les clients API peuvent-ils encore trouver ou récupérer le contenu ?

Si l’application utilise PostgreSQL, distinguez la visibilité au niveau de l’application de la suppression physique immédiate des anciennes versions de lignes. [PostgreSQL explique](https://www.postgresql.org/docs/current/routine-vacuuming.html) que, dans le cadre du MVCC, un DELETE ou un UPDATE ne supprime pas immédiatement l’ancienne version de ligne ; VACUUM récupère ensuite l’espace pour le rendre réutilisable. VACUUM standard rend généralement l’espace réutilisable plutôt que de le restituer au système d’exploitation, tandis que VACUUM FULL réécrit une table pour la compacter. Il s’agit d’un fait relatif à la maintenance de bases de données, et non d’une raison de contourner les contrôles applicatifs ou de formuler des affirmations non étayées sur la récupérabilité. Établissez le niveau de vérification approprié pour votre cas d’usage avec des parties prenantes techniques et de conformité qualifiées.

• L’élément est-il absent des vues ordinaires, des recherches, des API et des écrans administratifs ?
• Un administrateur peut-il le restaurer ? Si oui, avec quel rôle et pendant combien de temps ?
• La suppression se propage-t-elle aux enregistrements enfants, commentaires, pièces jointes et révisions ?
• La suppression d’un compte diffère-t-elle de la désactivation ou de la révocation d’accès ?
• L’application fournit-elle un export ou une trace d’audit de l’action sans conserver de contenu inutile ?
• Des suppressions en masse et des actions de conservation automatisées sont-elles disponibles, ou le traitement manuel est-il la seule possibilité ?

Tracez les données associées : pièces jointes, révisions, index de recherche, notifications, caches et données de tâches d’arrière-plan

Un test de suppression réussi suit les relations, et pas seulement l’enregistrement principal. Commencez par un marqueur connu dans votre enregistrement synthétique et recherchez-le dans le contenu associé. Examinez les tables de base de données uniquement si vous y êtes autorisé et compétent ; sinon, demandez au mainteneur de l’application d’expliquer le modèle de données et de fournir des éléments de preuve pris en charge.

Les pièces jointes nécessitent une attention particulière, car elles peuvent être stockées dans une base de données, dans un répertoire persistant local ou dans un stockage objet externe. Les révisions et les aperçus de documents peuvent survivre à la version actuelle. Les index de recherche et les caches peuvent rester temporairement obsolètes. Les notifications par e-mail et les tâches d’arrière-plan en file d’attente peuvent déjà contenir des valeurs copiées. Décidez quel délai, le cas échéant, est acceptable pour chaque composant et comment vous vérifierez la suppression finale.

La configuration du stockage objet peut changer la signification de la suppression. AWS indique que, dans un [bucket S3 avec versionnage activé](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeletingObjectVersions.html), une demande de suppression sans ID de version ajoute un marqueur de suppression au lieu de supprimer définitivement l’objet. La suppression définitive exige de supprimer les versions conservées spécifiées. Si une application utilise un stockage objet versionné ou un service compatible, testez le comportement exact du stockage et votre capacité à identifier chaque version pertinente.

• Consignez l’emplacement des pièces jointes et déterminez si les fichiers sont copiés, transformés ou prévisualisés.
• Vérifiez les fonctionnalités de révisions, d’historique, de corbeille ou de bac de recyclage, ainsi que leurs paramètres d’expiration.
• Recherchez le marqueur de test avant et après la suppression via la recherche et les API prises en charge par l’application.
• Identifiez le comportement de rafraîchissement du cache et de l’index, y compris les éventuelles tâches asynchrones.
• Examinez les modèles de notification, les parcours de distribution des e-mails et les files de tâches pour détecter le contenu copié.
• Pour le stockage objet externe, vérifiez le versionnage, les marqueurs de suppression, les règles de cycle de vie et les preuves de suppression.

Vérifiez les systèmes connectés : fournisseurs d’identité, services d’e-mail, webhooks, analytique, outils d’automatisation et stockage externe

Les intégrations rendent les données applicatives plus utiles, mais elles élargissent le périmètre de suppression. Une application peut retirer un enregistrement local alors qu’un fournisseur d’e-mail conserve une notification, qu’un flux d’automatisation stocke sa charge utile, qu’une destination de webhook reçoit une copie ou qu’un fournisseur d’identité conserve des attributs de compte selon ses propres règles de cycle de vie.

Documentez chaque connexion sortante et entrante. Pour les flux sortants, identifiez les champs transmis, déterminez si une charge utile complète ou un identifiant est envoyé, vérifiez si les nouvelles tentatives ou le traitement des messages non distribuables conservent des données, et établissez si le destinataire peut les supprimer. Pour les flux entrants, identifiez si le système externe peut recréer un enregistrement après sa suppression.

C’est également un point de décision. Si une intégration critique ne peut pas respecter vos exigences de conservation et qu’aucune alternative architecturale acceptable n’existe, ne considérez pas un bouton Supprimer local à l’application comme suffisant. Choisissez une autre conception d’intégration ou une autre application.

• Identité : identifiants de compte, attributs de profil, processus de déprovisionnement et règles de source de vérité.
• E-mail : contenu des messages, pièces jointes, journaux de livraison, listes de suppression et contrôles de conservation.
• Webhooks et automatisation : contenu des charges utiles, nouvelles tentatives, historiques de flux de travail, journaux d’exécution et destinataires en aval.
• Analytique : champs d’événements, identifiants, données liées aux adresses IP lorsqu’elles sont pertinentes et interface de suppression.
• Stockage externe : cycle de vie des objets, versionnage, réplicas, contrôles d’accès et enregistrements d’audit.
• Documentez un contact ou un responsable pour chaque système connecté et chaque parcours de suppression.

Distinguez la suppression des données actives de la conservation des sauvegardes et des procédures de restauration

La suppression des données actives et l’expiration des sauvegardes répondent à des problèmes différents. Retirer des informations de l’application de production ne les retire pas automatiquement des archives de sauvegarde déjà créées. Inversement, l’expiration des sauvegardes ne prouve pas que l’application active a supprimé un enregistrement. Documentez explicitement les deux cycles de vie.

[Docker indique](https://docs.docker.com/engine/storage/volumes/) qu’un volume de données persiste après la suppression de son conteneur. Supprimer ou recréer un conteneur ne prouve donc pas que les données sous-jacentes de l’application ont été supprimées. Docker documente également des procédures de sauvegarde du contenu des volumes et de restauration dans le même volume de conteneur ou dans un autre, ce qui explique pourquoi les parcours de restauration doivent faire partie de l’évaluation.

Pour une application gérée par Airbip, les instances s’exécutent comme des charges de travail Docker sur les serveurs cloud d’Airbip, et Airbip propose des sauvegardes quotidiennes, hebdomadaires et mensuelles configurables. Vérifiez dans la configuration et les conditions en vigueur comment les options de sauvegarde disponibles s’alignent sur vos règles de conservation au niveau de l’application. Une infrastructure gérée peut rendre les opérations de cycle de vie pratiques, mais elle ne décide pas ce que votre organisation doit conserver, supprimer ou préserver au titre d’une obligation de conservation légale.

Testez la restauration en toute sécurité. Restaurez une sauvegarde dans un environnement isolé et à accès contrôlé lorsque cela est autorisé, vérifiez que les données historiques attendues sont présentes et confirmez qu’elles ne peuvent pas être confondues avec les données de production actuelles. Définissez qui peut autoriser une restauration, quels contrôles post-restauration s’appliquent et comment les données restaurées sont traitées après la fin du test ou de l’incident.

• Créez un calendrier de conservation distinct pour les données de production, les sauvegardes, les instantanés et les archives exportées.
• Identifiez tous les emplacements de sauvegarde, fréquences, durées de conservation, mécanismes de chiffrement et autorités de restauration dans votre environnement documenté.
• Indiquez si les demandes de suppression n’affectent que les sauvegardes futures et pendant combien de temps les copies historiques peuvent rester conservées selon le calendrier de sauvegarde.
• Testez une procédure de restauration sans écraser les données de production.
• Mettez en place des contrôles pour empêcher qu’une restauration de sauvegarde obsolète ne réintroduise silencieusement des données dans la production.
• N’assimilez pas la suppression d’un conteneur, la suppression d’un volume, l’expiration d’une sauvegarde et l’assainissement des supports : ce sont des contrôles distincts.

Évaluez les éléments de preuve administratifs : journaux de suppression, pistes d’audit, rapports exportables et limites documentées

Un processus de suppression est plus facile à défendre et à exécuter lorsqu’il produit des éléments de preuve proportionnés. Au minimum, vous devez pouvoir identifier la demande ou l’événement déclencheur, la décision, l’opérateur ou le processus automatisé, la date, les systèmes inclus dans le périmètre, les exceptions et le statut d’achèvement. Évitez de créer une piste d’audit qui reproduit inutilement les données que vous cherchiez à supprimer.

Vérifiez si l’application offre des événements d’audit, des rapports administratifs ou des API prises en charge pouvant produire ces éléments de preuve. Si les preuves sont incomplètes, déterminez si un enregistrement opérationnel documenté peut combler cette lacune. Un registre manuel peut être acceptable pour des activités à faible volume, mais il devient fragile lorsque de nombreux utilisateurs, intégrations ou emplacements de stockage sont impliqués.

La journalisation exige ses propres contrôles. Le [NIST](https://nvlpubs.nist.gov/nistpubs/legacy/SP/nistspecialpublication800-92.pdf) conseille aux organisations de traiter la conservation, l’élimination, la préservation et la responsabilité de l’infrastructure de gestion des journaux. Docker prend en charge plusieurs [pilotes et destinations de journalisation](https://docs.docker.com/engine/logging/configure/). Docker indique également que la modification de la configuration de journalisation par défaut s’applique aux conteneurs nouvellement créés, tandis que les conteneurs existants conservent leur configuration actuelle jusqu’à leur recréation. Vérifiez la configuration déployée plutôt que de supposer qu’un changement de politique a déjà modifié chaque charge de travail.

• Pouvez-vous exporter un rapport de suppression indiquant le statut et les horodatages sans exposer de contenu sensible inutile ?
• La piste d’audit distingue-t-elle une action d’utilisateur, une action d’administrateur et une tâche de conservation automatisée ?
• Pouvez-vous documenter une exécution partielle, une obligation de conservation légale ou un refus justifié ?
• Où sont envoyés les journaux des conteneurs, de la plateforme et de l’application, et qui est responsable de leurs paramètres de conservation et d’élimination ?
• Les modifications de configuration nécessitent-elles de recréer les charges de travail pour prendre effet ?
• Les enregistrements de preuve sont-ils soumis à un contrôle d’accès et conservés uniquement aussi longtemps que nécessaire ?