Erreurs courantes de conservation et suppression que les equipes SaaS font encore

Les erreurs de conservation et de suppression apparaissent quand une entreprise SaaS traite le sujet comme une politique ecrite plutot que comme un processus operationnel. Le GDPR impose de ne pas garder les donnees personnelles plus longtemps que necessaire, de definir des delais de suppression ou de revue, et de repondre correctement aux demandes d'effacement. La difficulte est de le prouver dans les systemes, tickets, fournisseurs, sauvegardes et dossiers d'audit.

Les erreurs typiques sont des triggers flous, des regles non reliees aux systemes, des exceptions informelles, des promesses irrealisables sur les backups et une preuve insuffisante.

Pourquoi cela casse encore

Une politique peut dire que les donnees client, tickets support, donnees candidats et backups suivent des durees precises. Mais les donnees circulent dans l'application, le data warehouse, le CRM, le helpdesk, les logs, les analytics, la facturation, les exports et les outils fournisseurs. Sans cartographie, la suppression reste partielle.

Erreur 1 : une politique sans cartographie systeme

La retention schedule doit montrer ou les donnees existent, qui possede le systeme, quelle action est possible et quelle preuve reste. Commencez par les workflows les plus visibles : fermeture de compte, demande d'effacement, tickets support, donnees employes, offboarding fournisseur, analytics et logs.

Erreur 2 : une duree sans evenement declencheur

Dire "conserver trois ans" ne suffit pas. Le delai commence-t-il a la resiliation, a la facture finale, a la desactivation du compte ou a la cloture d'un ticket ? Le trigger doit etre un evenement operationnel que les equipes peuvent calculer et verifier.

Erreur 3 : confier tout a l'engineering

Engineering execute souvent la suppression, mais privacy, legal, security, support, finance, product et procurement participent au controle. Le workflow doit dire qui decide, qui detecte le trigger, qui approuve les exceptions, qui execute et qui conserve la preuve.

Erreur 4 : attendre le jour de suppression pour parler minimisation

La suppression devient plus difficile quand trop de donnees ont ete collectees. Formulaires, analytics, pieces jointes support, integrations et champs libres creent des copies. Chaque lancement devrait verifier si la donnee est necessaire, si une version anonyme suffit, ou elle est copiee et quelle regle de conservation s'applique.

Erreur 5 : oublier les backups

Les systemes actifs peuvent etre purges rapidement, alors que les backups expirent souvent par rotation. Certains sont immuables ou impossibles a modifier ligne par ligne. Le modele doit distinguer suppression live, anonymisation, expiration backup, controles de restauration et legal holds. L'EDPB a cite en 2026 les backups et periodes de conservation comme difficultes pratiques.

Erreur 6 : traiter chaque demande d'effacement de la meme facon

Le droit a l'effacement n'est pas absolu. Des obligations legales, l'interet public ou la defense de droits peuvent justifier une conservation limitee. Utilisez un arbre de decision : verifier identite et scope, lister systemes et fournisseurs, verifier le fondement, examiner les exceptions, agir et documenter.

Erreur 7 : perdre la trace de preuve

Un script execute, un email fournisseur et un ticket ferme ne suffisent pas si rien ne relie la regle, le trigger, la decision, l'owner, l'action et la date. La preuve doit etre legere mais coherente.

Erreur 8 : oublier les changements produit

Une integration, une table analytics, des logs AI ou une migration billing peuvent changer le perimetre. Les lancements a risque doivent inclure une question simple : quelles donnees personnelles, quelles copies, quel owner, quelle suppression, quelle preuve ?

Checklist pratique

• Chaque regle est liee a des systemes et fournisseurs.
• Le trigger est un evenement clair.
• Les owners de decision, execution et preuve sont connus.
• Backups, archives et exports sont traites separement.
• Les exceptions et legal holds sont documentes.
• Les promesses client correspondent a la realite technique.

Commencez par un workflow concret comme la fermeture de compte ou une demande d'effacement. Un controle executable vaut mieux qu'une politique ambitieuse mais fragile.