Cycle de vie de la donnée de la collecte à la destruction prouvée

Cycle de vie de la donnée de la collecte à la destruction prouvée

Une donnée n’est pas un fichier qui apparaît dans une base puis disparaît par magie à la fin d’un tableau de conservation. C’est un ensemble de copies, de métadonnées, de clés, de journaux et de sauvegardes qui doit suivre une politique cohérente, sinon la suppression devient un vœu pieux avec un ticket fermé.

Explication de la marmotte

Gérer une donnée ressemble à la gestion d’un dossier contenant des informations personnelles : il faut savoir pourquoi il existe, qui peut l’ouvrir, combien de temps le garder et pouvoir montrer qu’il a bien été détruit. Sans registre fiable, le dossier finit dans une armoire oubliée, avec les ennuis qui vont avec.

→ Lire l’explication complète de la marmotte

Collecte : finalité, minimisation et traçabilité d’origine

La première règle est brutale : une donnée non collectée ne fuit pas, ne coûte pas de stockage, ne réclame pas d’effacement et ne transforme pas une restauration de sauvegarde en opération archéologique. La collecte doit donc être reliée à une finalité nommée, à une durée de conservation et à un propriétaire métier identifié avant l’ouverture du flux.

Chaque événement collecté doit porter des métadonnées de cycle de vie séparées du contenu : identifiant de classification, finalité, date de collecte, source, échéance de conservation, base de suppression et domaine de responsabilité. Ces métadonnées doivent être immuables ou versionnées. Une date stockée dans un champ libre nommé commentaire, c’est de la gouvernance par boule de cristal.

La source doit être authentifiée avant ingestion. Pour une interface de programmation applicative, ou API (Application Programming Interface), cela implique au minimum une identité de service, une autorisation limitée au jeu de données attendu et un transport TLS (Transport Layer Security). L’authentification protège l’entrée, pas la qualité de la donnée : une source légitime peut transmettre un identifiant erroné, une donnée surclassifiée ou un secret glissé dans un champ de diagnostic.

La minimisation doit être appliquée dans le pipeline d’ingestion, pas promise dans une présentation de gouvernance. Supprimer ou tronquer les champs inutiles avant la persistance réduit immédiatement le rayon d’exposition. Pour les journaux techniques, préférer une empreinte cryptographique salée d’un identifiant quand la corrélation suffit. Le sel doit être distinct par domaine de données, sinon la pseudonymisation devient une table de jointure offerte à toute copie de journal.

Les identités qui écrivent, lisent ou administrent ces données doivent être rattachées à un modèle IAM (Identity and Access Management). La page authentifier les personnes et les services traite l’identification des acteurs ; ici, le point décisif est de faire porter à chaque accès la classification et l’objectif d’usage, pas seulement un rôle applicatif vague du genre data-admin.

Stockage, copies et cryptographie de cycle de vie

Le compromis central est le suivant : plus la conservation est distribuée, répliquée et performante, plus il devient coûteux de prouver l’effacement complet. La recommandation est de centraliser le plan de contrôle du cycle de vie, même lorsque les données restent réparties entre plusieurs stockages. Chaque copie doit être connue, rattachée à un objet logique et soumise à la même échéance.

Un inventaire doit couvrir les bases transactionnelles, moteurs de recherche, caches, exports, espaces analytiques, journaux, sauvegardes et environnements de test. Les environnements non productifs ne sont pas une zone franche où les échéances cessent d’exister. Une extraction anonymisée, documentée et renouvelable est préférable à la duplication brute d’un jeu de production.

Le chiffrement réduit l’impact d’un accès physique ou logique non autorisé, mais il ne remplace pas le contrôle d’accès. Utiliser une DEK (Data Encryption Key) par objet ou par lot de sensibilité homogène, puis chiffrer cette DEK avec une KEK (Key Encryption Key) détenue par un KMS (Key Management Service), permet de détruire une classe de données par destruction de clé. Ce mécanisme ne vaut que si aucune copie de la DEK ou de la KEK ne survit ailleurs.

Une KEK de production ne doit pas être exportable. Un HSM (Hardware Security Module) ou un service de gestion de clés avec garantie équivalente réduit le risque d’extraction de clé, mais ne corrige ni un droit d’usage trop large ni une application qui journalise les données déchiffrées. La gestion des clés et des mécanismes cryptographiques doit définir les algorithmes, les durées de validité et les procédures de rotation avant de présenter le chiffrement comme une gomme universelle.

La rotation d’une clé ne détruit aucune donnée. Elle limite l’exposition future et oblige parfois à rechiffrer. La destruction cryptographique, elle, rend les données illisibles si la clé est effectivement supprimée de tous les emplacements actifs, de secours et de sauvegarde. Cette distinction évite les rapports rassurants qui annoncent une « purge cryptographique » après avoir seulement créé une nouvelle version de clé. Le vocabulaire peut être créatif, les octets beaucoup moins.

Rétention et suppression orchestrée

Une règle de rétention doit être exécutable : périmètre, horloge de référence, événement déclencheur, durée, exceptions documentées et action finale. « Conserver selon besoin » n’est pas une règle. C’est une invitation à conserver indéfiniment jusqu’à ce qu’un incident donne soudain un sens concret au mot besoin.

L’échéance doit être calculée depuis un événement stable, par exemple la clôture d’un compte ou la réception d’une transaction, jamais depuis la date du dernier accès. Réinitialiser le compteur à chaque lecture fabrique une conservation perpétuelle par simple consultation. Pour les contentieux, investigations ou obligations de conservation, appliquer une suspension ciblée, identifiée et expirante. Une suspension sans date de révision est une rétention déguisée avec un badge administratif.

Le moteur de suppression doit agir sur les identifiants d’objets et non sur des requêtes textuelles fragiles. Une suppression doit être idempotente : relancer le traitement après interruption ne doit ni restaurer un objet ni produire une preuve contradictoire. Les dépendances doivent être explicites, notamment pour les index de recherche, pièces jointes, tables de jointure et caches distribués.

Les sauvegardes imposent une décision d’architecture. Deux stratégies sont valables :

• Purger les sauvegardes à chaque demande de suppression : nécessaire lorsque la donnée doit devenir inaccessible avant l’expiration normale des sauvegardes, mais coûteux et risqué pour la restaurabilité.
• Laisser expirer les sauvegardes selon une durée bornée, tout en empêchant toute restauration de réintroduire une donnée supprimée : acceptable si la durée résiduelle est connue, courte au regard de la politique et contrôlée par un journal de suppressions.

La seconde approche est souvent plus exploitable. Elle exige un registre de tombstones, c’est-à-dire d’identifiants supprimés, appliqué après chaque restauration. Restaurer une base sans rejouer ce registre recrée le passé avec une ponctualité admirable et une sécurité franchement médiocre.

Destruction prouvée : preuve, intégrité et limites

Prouver une destruction ne signifie pas prouver un événement physique absolu sur chaque support. Sur un stockage distribué, cette promesse dépasse souvent les capacités observables. La preuve doit plutôt démontrer qu’un objet identifié a reçu l’action prévue, que les systèmes concernés ont accusé réception et qu’aucun chemin normal de lecture ne permet encore de le récupérer.

Un certificat de destruction doit inclure : identifiant de l’objet logique, version, classification, motif, horodatage en temps universel coordonné, ou UTC (Coordinated Universal Time), identité du moteur ayant exécuté l’action, emplacements visés, résultat par emplacement, références des clés détruites et identifiant de la politique appliquée. Ne pas inclure le contenu supprimé, ni un identifiant directement réutilisable hors du domaine. Une preuve de suppression qui révèle la donnée est un poisson rouge chargé de surveiller l’aquarium.

Signer chaque lot de preuves avec une clé dédiée, distincte des clés de chiffrement de données. Une empreinte SHA-256 (Secure Hash Algorithm 256 bits) du manifeste, chaînée au lot précédent, détecte la réécriture rétrospective du journal. Pour résister à un administrateur disposant des droits sur le stockage, répliquer les preuves vers un dépôt à rétention verrouillée et séparer les rôles d’administration, d’exécution et d’audit.

Ce mécanisme ne garantit pas la destruction chez un tiers qui a reçu une exportation, dans une capture mémoire réalisée avant suppression, sur un poste ayant téléchargé un fichier ou dans une impression papier. Ces canaux nécessitent des contrôles de sortie, une journalisation des exports, des droits minimaux et parfois des engagements contractuels. La destruction prouvée du stockage primaire n’efface pas les conséquences d’une diffusion antérieure.

Exemple reproductible : manifeste de suppression signé

L’exemple suivant construit un manifeste minimal, calcule son empreinte et le signe avec une clé de preuve. Il démontre l’intégrité d’un enregistrement de destruction ; il ne détruit aucun fichier à lui seul. La commande nécessite OpenSSL 3.x et une clé privée protégée par des permissions système ou un HSM compatible PKCS#11 (Public Key Cryptography Standards number 11).

#!/usr/bin/env bash
set -euo pipefail

# Créer une clé de démonstration une seule fois.
openssl genpkey -algorithm ED25519 -out destruction-proof.key
openssl pkey -in destruction-proof.key -pubout -out destruction-proof.pub

# Enregistrer le résultat d'une suppression réellement exécutée par le moteur.
cat > destruction-manifest.json <<'EOF'
{
  "object_id": "customer-7f3b9e",
  "policy_id": "retention-account-36m-v4",
  "deleted_at_utc": "2026-09-20T12:00:00Z",
  "targets": ["primary-db", "search-index", "backup-tombstone-registry"],
  "result": "completed"
}
EOF

# Signer le manifeste, puis vérifier la preuve avec la clé publique.
openssl pkeyutl -sign -rawin -inkey destruction-proof.key \
  -in destruction-manifest.json -out destruction-manifest.sig

openssl pkeyutl -verify -rawin -pubin -inkey destruction-proof.pub \
  -in destruction-manifest.json -sigfile destruction-manifest.sig

En production, le manifeste doit être émis par le moteur de cycle de vie après vérification des accusés de réception. Le signer dans un script lancé par le même compte qui supprime les données ne sépare aucun pouvoir. Cela ajoute surtout une signature décorative, ce qui est très ère des plateformes.

Supervision, reprise et tests d’échec

Superviser le volume d’objets arrivant à échéance, le taux d’échec par cible, l’âge du plus ancien objet en attente, les suppressions bloquées par suspension et la dérive entre inventaire et stockage réel. Une absence d’alertes ne prouve rien si le moteur de rétention s’est arrêté silencieusement. Un indicateur doit comparer le nombre d’objets éligibles au nombre d’actions effectivement terminées.

La reprise doit être testée sur une restauration complète : restaurer un jeu de données, appliquer le registre de tombstones, vérifier l’absence des objets supprimés, puis contrôler la cohérence des index et des clés. Le test doit inclure une suppression interrompue entre deux cibles. Les architectures distribuées échouent par morceaux, rarement avec la courtoisie d’un échec atomique.

Les clés de chiffrement, manifestes signés et registres de tombstones doivent être sauvegardés selon des règles distinctes. Sauvegarder la clé qui rend une donnée détruite relisible annule la destruction cryptographique. Détruire le registre qui évite sa réapparition après restauration annule la suppression opérationnelle. La gouvernance des données doit donc relier propriétaires, politiques et preuves techniques, sans prétendre remplacer une analyse juridique.

🐝 Ce qui arrive si on s’en passe

Sans plan de cycle de vie outillé, la porte de la ruche reste ouverte : chaque nouvelle copie entre sans étiquette et personne ne sait combien de temps elle reste. Le premier coût est la qualification d’incident. En l’absence d’inventaire des emplacements et de métadonnées de finalité, délimiter le périmètre exposé exige une exploration manuelle des stockages, ce qui allonge le délai de notification et aboutit à une estimation défensive plus large que la réalité. Le deuxième coût est la réponse aux demandes d’accès ou d’effacement, impossible à prouver sans certificat signé ni identifiant d’objet logique. Le troisième est financier et technique : des jeux anciens jamais échus gonflent les index, les sauvegardes et les durées de restauration. Enfin, une donnée non datée ne peut être écartée d’une analyse, donc elle continue d’alimenter des traitements dont la base d’usage n’existe plus.

🦫 Explication de la marmotte 🍫

Une organisation doit décider avant de recevoir une information pourquoi elle la demande, qui pourra l’utiliser et quand elle devra disparaître. Elle ajoute alors une étiquette qui indique l’origine de l’information, sa durée de conservation et la règle qui lui est appliquée. Les informations inutiles doivent être retirées dès l’arrivée, car les garder crée des risques supplémentaires.

Pendant la conservation, les accès sont limités aux personnes et programmes autorisés. Les copies sont recensées : base principale, moteur de recherche, sauvegardes, exports et environnements de test. Les informations peuvent être chiffrées, ce qui les rend illisibles sans une clé secrète. Cette clé doit être protégée séparément des données.

Quand la date arrive, un programme supprime l’information de chaque emplacement prévu. Si une copie est dans une sauvegarde qui ne peut pas être modifiée, son identifiant est inscrit dans un registre. Après une restauration, ce registre est relu pour supprimer à nouveau ce qui ne doit plus revenir.

Le système produit ensuite une preuve : quel objet a été supprimé, à quelle date, selon quelle règle et avec quel résultat pour chaque emplacement. Cette preuve est protégée contre la modification. Si une suppression échoue, elle doit rester visible et déclencher une alerte. La preuve ne peut pas effacer une copie envoyée auparavant à un tiers, téléchargée sur un poste ou imprimée : ces sorties doivent être contrôlées avant la destruction.

À lire aussi

• Classifier les données avant de les protégerLa classification des données permet de décider quelles protections appliquer, où les appliquer et ce qu’elles ne couvrent pas.
• Résidence des données et souveraineté cloudRésidence des données et souveraineté : distinguer la localisation réelle des données, le contrôle technique et les dépendances juridiques.
• Gouvernance d'un data lake et copie des donnéesGouverner un data lake exige de contrôler les copies, les identités, les métadonnées, les clés et le cycle de vie des données.
• Comment détruire une clé pour effacer des données chiffréesLa destruction sécurisée de clés, ou crypto-shredding, rend définitivement inexploitables les données chiffrées lorsque l’architecture et les sauvegardes le permettent.

Pages voisines

La citent

• AI Act : gouvernance des données d'entraînement (article 10)
• AIPD RGPD article 35 : méthode, critères et impact sur l'architecture
• Le registre des traitements comme outil de sécurité

Cycle de vie de la donnée de la collecte à la destruction prouvée

Elle cite

• Effacement des données dans une architecture distribuée
• Pourquoi supprimer un fichier ne l'efface pas
• Masquage dynamique pour tests et développement