Politique de conservation des données : stockez moins et réduisez le risque

Pourquoi stocker moins de données réduit votre risque

Garder des données en trop semble inoffensif. Elles reposent dans une base, un tableau, ou une boîte mail. Mais chaque donnée que vous conservez est quelque chose qui peut fuir, se perdre ou être mal utilisée plus tard. Stocker moins est l'une des façons les plus simples de réduire le risque sur la vie privée et le travail quotidien en sécurité.

Les données en surplus augmentent le risque parce qu'elles multiplient les endroits à protéger et les occasions d'erreurs. Elles augmentent aussi le coût : plus de stockage et de sauvegardes, plus de revues d'accès, plus de temps pour traiter les demandes de suppression, et plus de temps pour enquêter sur les incidents.

Les équipes conservent souvent des informations sans raison claire : anciens tickets de support avec historique complet, logs gardés indéfiniment, copies de pièces d'identité et captures d'écran, CSV exportés sur des ordinateurs ou disques partagés, et bases de test remplies de données réelles de clients.

Une façon pratique de l'envisager est « besoin de savoir » et « besoin de conserver ». « Besoin de savoir » signifie que seules les personnes et systèmes requis pour une tâche peuvent accéder aux données. « Besoin de conserver » signifie que vous ne collectez et ne retenez que ce qui est nécessaire pour fournir le service, respecter des obligations légales ou prévenir la fraude, et que vous supprimez le reste.

C'est là qu'une politique de conservation des données devient utile. Elle impose des réponses claires : à quoi sert cette donnée, qui l'utilise, que se passe-t-il si elle fuit, et quand peut-on la supprimer en toute sécurité ?

« Pour toujours » n'est pas un choix neutre. Si quelque chose tourne mal, « pour toujours » peut signifier des années d'exposition. Une seule fuite peut inclure de vieux comptes, des fonctionnalités abandonnées, des logs obsolètes et des exports oubliés. Et cela signifie aussi que vous pourriez devoir expliquer des années plus tard pourquoi vous avez conservé des données inutiles.

Un exemple courant est la journalisation de debug. Les applications construites rapidement (y compris les prototypes générés par IA) consignent souvent par accident des détails sensibles : tokens de réinitialisation de mot de passe, réponses d'API complètes, ou secrets en clair. Si ces logs sont conservés indéfiniment, une erreur peut devenir un incident long et coûteux. Une rétention plus courte réduit le rayon d'impact.

Cartographiez ce que vous collectez et où ça finit

Avant de pouvoir stocker moins, vous avez besoin d'un inventaire clair de ce qui existe aujourd'hui. La plupart des équipes sautent cette étape et passent directement aux règles, puis découvrent des copies surprises dans des exports, fils de discussion et anciennes sauvegardes.

Commencez par lister les types de données que vous traitez, en utilisant des exemples réels du travail quotidien :

• Données clients (détails de compte, informations de facturation, tickets de support)
• Données employés (paie, notes de performance, enregistrements d'appareils)
• Données fournisseurs (contrats, factures, listes de contacts)
• Données produit (événements d'utilisation, rapports d'erreur, feature flags)
• Éléments sensibles (mots de passe, documents d'identité, données de santé ou financières)

Ensuite, notez d'où provient chaque type : formulaires d'inscription et de paiement, e-mails de support, logs serveurs, téléchargements de fichiers, et outils tiers (paiements, analytics, e-mail, CRM). Les points de collecte sont souvent le départ d'une sur-collecte accidentelle.

Puis suivez où ces données résident aujourd'hui, pas où vous pensez qu'elles résident. Incluez les systèmes évidents (base d'app, entrepôt de données, outil de tickets) et les systèmes informels (tableaux partagés, messages de chat, boîtes mail personnelles).

Enfin, signalez les stockages « cachés » qui prolongent silencieusement la conservation :

• Sauvegardes et snapshots
• Exports analytics ou dumps d'événements bruts
• Outils de logging qui conservent les payloads de requête
• Pièces jointes d'e-mails transférées dans l'équipe
• Bases de staging/dev copiées depuis la production

Un exemple rapide : un petit SaaS collecte la « taille de l'entreprise » à l'inscription, mais le support demande des captures d'écran qui incluent des noms, et les logs d'erreur capturent des requêtes complètes avec des tokens. L'équipe pense ne stocker que des données de profil basiques, mais en pratique elle a des données clients dans des logs, boîtes mail et archives de sauvegarde.

Si vous avez hérité d'une app générée par IA, cette étape de cartographie compte d'autant plus. Il est courant de trouver des tokens d'auth, des secrets ou des objets utilisateur complets qui finissent dans des logs ou analytics par accident. Une carte simple vous donne la liste des cibles : ce qu'il faut arrêter de collecter, où raccourcir la rétention, et ce qui nécessite une suppression sécurisée.

Décidez ce que vous devez vraiment collecter

Une bonne politique de conservation commence en amont, au moment de la collecte. Si vous ne collectez jamais une donnée, vous n'avez jamais à la sécuriser, la supprimer ou expliquer pourquoi vous l'aviez.

Utilisez un test simple : cette donnée aide-t-elle à fournir le service, respecter une obligation légale ou prévenir la fraude ? Si la réponse honnête est « ça pourrait être utile un jour », traitez-la comme optionnelle jusqu'à preuve du contraire.

Séparez « requis » de « sympa à avoir »

La plupart des équipes collectent des champs en trop parce qu'un formulaire avait de la place, un modèle le suggérait, ou quelqu'un l'a demandé une fois. C'est ainsi que les bases se remplissent discrètement de détails sensibles.

Demandez-vous pour chaque champ : que se passe-t-il si on le supprime ? Si rien ne se passe, c'est « sympa à avoir ». Si le produit ne peut pas fonctionner sans (par exemple, on ne peut pas créer de compte sans e-mail), c'est « requis ».

Une façon pratique de procéder :

• Marquez chaque champ comme Requis, Optionnel ou Arrêter de collecter
• Par défaut, considérez les nouveaux champs comme Optionnels et ne les promouvez que s'ils prouvent une vraie valeur
• Évitez de collecter des données à haut risque « au cas où »
• Assignez un propriétaire à chaque champ (une personne ou une équipe réelle)

Associez chaque type de donnée à un but clair

Pour chaque type de donnée, rédigez une phrase d'objectif qu'une personne non technique comprendra :

• E-mail : « Envoyer des codes de connexion et des notifications importantes de compte. »
• Adresse de facturation : « Calculer la taxe et émettre les factures. »
• Chats de support : « Résoudre les problèmes clients et améliorer les articles d'aide. »

Si vous ne pouvez pas écrire un seul but clair, c'est un signe que vous la collectez sans besoin réel.

Décidez qui a réellement besoin d'accès

La minimisation des données ne concerne pas seulement ce que vous collectez. Elle concerne aussi qui peut voir les données au quotidien. Beaucoup d'échecs en matière de vie privée surviennent parce que trop de personnes ont accès à trop de choses.

Serrez les accès : donnez l'accès complet seulement aux rôles qui doivent utiliser les données pour faire leur travail. Pour les autres, fournissez moins de détails (par exemple, les 4 derniers chiffres au lieu des identifiants complets) ou supprimez l'accès.

Soyez strict avec les champs difficiles à protéger ou difficiles à justifier, comme les numéros de sécurité sociale. Si vous n'avez pas d'obligation légale de les collecter, ne le faites pas. Si vous devez vraiment collecter des données à haut risque, traitez-les comme un cas spécial avec des contrôles supplémentaires et une période de conservation courte.

Combien de temps faut-il garder les données ? Règles simples qui fonctionnent

Une politique de conservation est plus facile si vous partez d'une idée simple : chaque donnée doit avoir une date de fin. Si vous ne pouvez pas expliquer pourquoi vous la gardez encore, vous ne devriez probablement pas la conserver.

Commencez par un défaut, puis faites des exceptions

Choisissez une période de conservation par défaut pour chaque type de données selon la raison de la collecte (support, facturation, sécurité, légal). Les valeurs par défaut empêchent que « garder pour toujours » devienne la règle silencieuse.

Une approche pratique est de définir la rétention par catégorie :

• Données de compte (nom, e-mail) : conserver tant que le compte est actif, puis supprimer ou anonymiser après une période de grâce.
• Paiements et factures : conserver le temps nécessaire pour la comptabilité et les litiges.
• Messages de support : conserver uniquement tant qu'ils aident à résoudre des problèmes et former l'équipe.
• Événements de sécurité : conserver assez longtemps pour enquêter, puis agréger en résumés.
• Analytics produit : conserver les données agrégées plus longtemps que les traces d'événements bruts.

Les données sensibles devraient généralement avoir la timeline la plus courte. Il en va de même pour les logs verbeux. Les logs contiennent souvent des IP, tokens ou secrets accidentels, surtout dans les produits construits rapidement. Conservez les logs détaillés brièvement (jours ou semaines), puis ne conservez que ce dont vous avez besoin (comptes, types d'erreurs) plus longtemps.

Utilisez des timelines différentes pour utilisateurs actifs vs inactifs

Traitez l'inactivité comme un déclencheur. Par exemple : conservez le profil complet et l'historique pour les utilisateurs actifs, mais après 90 jours d'inactivité cessez de collecter certains événements, et après 12 mois supprimez ou anonymisez l'ancien historique.

Cela force la clarté sur les données « au cas où ». Si un utilisateur n'utilise pas le produit, votre besoin de conserver ses données détaillées diminue rapidement.

Décidez ce qui se passe lorsqu'une personne demande la suppression

Une demande de suppression ne devrait pas être une panique ponctuelle. Définissez-la à l'avance :

• Ce que vous supprimez (et ce que vous devez garder pour des raisons légales/comptables)
• Le délai pour compléter la suppression (par exemple, sous 30 jours)
• Comment les sauvegardes sont traitées (expiration naturelle, ou exclusion des restaurations)
• Quelle preuve vous conservez (un petit enregistrement que la demande a été satisfaite)

Si vous pouvez énoncer ces règles en langage simple, vous pourrez généralement les appliquer sans drame — et sans garder des données plus longtemps que nécessaire.

Construisez un calendrier de conservation que l'on peut suivre

Un calendrier de conservation est la partie de votre politique que les gens peuvent utiliser sans deviner. S'il ressemble à un document légal, il sera ignoré. Gardez-le court, précis, et associez chaque ligne à un but clair.

Commencez par un tableau simple qui répond à cinq questions : quel est le type de données, pourquoi vous l'avez, qui en est responsable, combien de temps vous le gardez, et comment vous le supprimez. L'objectif n'est pas de tout cataloguer parfaitement le premier jour. L'objectif est d'éviter que quelque chose reste « au cas où ».

« Propriétaire » fait la différence entre un plan et un souhait. Choisissez une personne ou un rôle réel pour chaque ligne. Ils n'ont pas besoin de supprimer manuellement les enregistrements, mais ils doivent remarquer quand les choses dérapent (par exemple, des logs qui restent une année).

Rédigez les règles de rétention en termes simples et évitez des termes vagues comme « selon les besoins ». De bonnes règles ressemblent à : « Supprimer 30 jours après la fermeture du compte », ou « Garder 14 jours sauf si un incident est ouvert ». Si vous ne pouvez pas le dire en une phrase, ce n'est probablement pas assez clair.

Des exceptions arriveront, documentez-les d'emblée :

• Gel légal : pause de suppression pour certains comptes ou enregistrements
• Enquête fraude/sécurité : conserver les logs et événements pertinents jusqu'à la clôture du dossier
• Demande réglementaire : ne garder que ce qui est requis, pas tout

Pour chaque exception, indiquez qui peut l'approuver et comment elle est enregistrée (même un ticket simple ou une note écrite). Ainsi, « temporaire » ne devient pas « pour toujours ».

Étapes : implémenter la minimisation et la rétention

Une politique de conservation fonctionne seulement si elle change ce que votre produit collecte, où ça se trouve, et quand ça disparaît. Voici une séquence qui garde le travail petit et réduit les surprises.

1) Coupez la collecte à la source

Commencez par les formulaires, flux d'inscription, checkout, tickets de support, et analytics « sympa à avoir ». Supprimez les champs que vous n'utilisez pas pour fournir le service, prévenir la fraude, ou respecter une obligation légale.

Si vous ne pouvez pas nommer le rapport, la fonctionnalité ou la raison légale qui a besoin du champ, arrêtez de le collecter.

2) Réduisez les copies et restreignez l'accès

Le risque augmente quand la même donnée vit à cinq endroits. Avancez vers un système unique de référence, et faites en sorte que les autres outils ne tirent que ce dont ils ont besoin. Limitez les accès par rôle et évitez les comptes partagés.

Si un outil fournisseur a besoin de données, envoyez le minimum (par exemple, ID utilisateur et niveau d'abonnement, pas le profil complet).

3) Automatisez la suppression, pas les rappels

Le nettoyage manuel est souvent oublié. Définissez des règles temporelles pour expirer les profils inactifs, supprimer les pièces jointes après la clôture d'un ticket, faire pivoter les logs, vider les exports temporaires, et purger les données de test.

Gardez les règles assez simples pour qu'un·e ingénieur·e puisse les implémenter rapidement.

4) Assurez-vous que la suppression est réelle (y compris dans les sauvegardes)

Supprimer un enregistrement dans l'app n'est pas la même chose que le supprimer partout. Confirmez combien de temps sauvegardes, réplicas et tables d'entrepôt conservent les données. Si des sauvegardes doivent exister, réduisez la fenêtre de rétention et documentez ce que « supprimé » signifie en pratique (par exemple : retiré de la production immédiatement, puis disparu des sauvegardes sous 30 jours).

5) Revoyez trimestriellement et corrigez les dérives

Les produits changent, la collecte revient. Chaque trimestre, choisissez un flux et revérifiez : ce que vous collectez, où ça atterrit, qui peut le voir, et quand c'est supprimé.

Erreurs courantes qui maintiennent un risque élevé

La plupart des problèmes de données ne proviennent pas d'une grande décision mais d'habitudes mineures qui s'accumulent jusqu'à ce qu'on ne sache plus pourquoi on stocke ceci ou cela.

Un piège classique est de garder les logs indéfiniment parce qu'ils pourraient servir plus tard. Les logs aident au debug, mais contiennent souvent des e-mails, IP, tokens de reset et autres éléments sensibles. Sans limite de temps, le dépannage d'hier devient l'exposition de l'an prochain.

Une autre erreur fréquente est de « supprimer » des données dans l'app alors que des copies existent ailleurs. On supprime un enregistrement de la base, puis on oublie le CSV exporté sur un drive partagé, la pièce jointe dans un e-mail, ou le snapshot dans des sauvegardes. Quand un client demande la suppression, une suppression partielle ne suffit pas et crée un problème de confiance.

Signes qui augmentent silencieusement l'exposition

Surveillez ces habitudes :

• Stockage « au cas où » sans date d'expiration ou de revue
• Suppressions qui n'ont lieu qu'à un endroit mais pas dans les exports, tickets et backups
• Secrets stockés en clair ou intégrés dans du code côté client
• Outils qui copient les données clients par défaut sans besoin clair
• Pas de propriétaire clair, donc personne ne suit quand des exceptions apparaissent

Exemple pratique : un fondateur déploie un prototype généré par IA qui marche en démo. Plus tard, il découvre que l'app logge des réponses d'authentification complètes et qu'une clé API est codée dans le frontend. Ils enlèvent la clé d'un fichier, mais une ancienne build, un extrait collé dans un e-mail de support et une sauvegarde la contiennent encore. Le risque reste.

Vérifications rapides à faire cette semaine

Vous n'avez pas besoin d'un plan gigantesque pour réduire le risque. Quelques vérifications rapides montrent où vous collectez trop, conservez trop longtemps, ou ne pouvez pas supprimer quand il le faut.

Commencez par ce que vous collectez. Choisissez un flux clé (inscription, checkout, formulaire de contact) et passez en revue chaque champ. Si vous ne pouvez pas expliquer en une phrase pourquoi vous avez besoin d'un champ, supprimez-le ou rendez-le optionnel.

Puis vérifiez la rétention dans les endroits qu'on oublie : logs, uploads, et systèmes de support. Ils contiennent souvent des e-mails, IP, captures d'écran, et parfois des secrets copiés dans des messages.

Cinq vérifications à finir en une semaine :

• Pour chaque champ collecté, écrivez une raison en une phrase et le format le plus petit nécessaire (ex : année de naissance, pas la date complète).
• Notez les périodes de rétention pour logs, uploads et tickets, même approximatives (ex : 30, 90, 365 jours).
• Effectuez un test de suppression de bout en bout pour un utilisateur : BDD app, exports analytics, fichiers et threads de support.
• Listez où les sauvegardes vivent et combien de temps elles persistent, y compris anciens snapshots et machines dev.
• Confirmez que les données sensibles sont chiffrées et que l'accès est limité à un petit groupe.

Un test qui surprend souvent : demandez à quelqu'un de retrouver et supprimer un utilisateur qui a écrit au support il y a un an. Si la réponse est « on peut supprimer de l'app, mais pas de l'outil de ticketing ou des backups », vous avez un écart clair à corriger.

Exemple : réduire la collecte dans un petit produit

Un petit SaaS vendait un abonnement mensuel. À l'inscription, il demandait un numéro de téléphone, une adresse personnelle et la date de naissance. Rien de tout cela n'était nécessaire pour fournir le produit. C'était là parce que la première version avait copié un modèle de « profil complet ».

Quelques mois plus tard, le support demandait des captures d'écran quand quelque chose cassait. Ces captures incluaient souvent noms, e-mails, et parfois des détails de paiement ou de compte. Parallèlement, l'équipe exportait des analytics dans un tableau pour « analyse ultérieure » et le gardait des années, avec les e-mails des utilisateurs en clair.

Ils ont traité ça comme un problème de risque, pas comme du papier, et ont opéré trois changements :

• Suppression du téléphone, de l'adresse et de la date de naissance à l'onboarding, ne gardant que le nécessaire pour le compte et la facturation.
• Ajout d'une invite dans le support pour flouter les informations personnelles et règle interne de suppression des pièces jointes après résolution du ticket.
• Arrêt des exports par défaut des analytics au niveau utilisateur. Lorsqu'un export était nécessaire, ils utilisaient un ID utilisateur anonymisé et définissaient une expiration à 30 jours.

Ils ont aussi réduit la rétention des logs techniques. Les logs applicatifs sont passés de « garder pour toujours » à 14 jours, et les traces d'erreur contenant des identifiants utilisateurs ont été masquées. Les sauvegardes ont été ajustées : sauvegardes quotidiennes conservées 14 jours, sauvegardes mensuelles 3 mois, et les copies plus anciennes supprimées en sécurité.

Le résultat était simple : moins de données sensibles qui traînent dans les formulaires, boîtes mail, feuilles de calcul, logs et sauvegardes. Quand quelque chose tournait mal, il y avait moins à fuir, moins à chercher, et moins à expliquer.

Prochaines étapes : réduisez ce que vous stockez et faites-le durer

Une bonne politique de conservation n'est pas un gros document. Ce sont quelques décisions claires que votre équipe peut suivre chaque semaine.

Commencez par écrire les 10 principaux éléments de données que votre produit manipule (pas tout, juste les gros). À côté de chacun, choisissez une période de rétention que vous pouvez défendre. Puis choisissez une zone à haut risque à corriger en premier : logs d'auth, uploads de fichiers, ou une boîte de support partagée sont des coupables courants.

Ajoutez de l'automatisation légère pour que ce ne soit pas basé sur la mémoire : jobs de suppression pour les tokens expirés, rotation des logs avec âge maximal fixe, et règles d'expiration claires pour uploads et exports.

Si vous avez hérité d'une base de code générée par IA et que vous ne savez pas ce qui est loggé ou conservé, une revue ciblée du code et de la configuration peut rapidement révéler les gros risques (logs trop verbeux, secrets exposés, et données copiées dans les mauvais outils). Des équipes comme FixMyMess (fixmymess.ai) font ce type de diagnostic et réparation quand un prototype généré par IA doit devenir prêt pour la production : journalisation plus sûre, renforcement de la sécurité, et routines de suppression qui s'exécutent réellement.