RGPD et suppression définitive de fichiers dans Salesforce

Une demande d’effacement arrive. Vous ouvrez la fiche, vous cliquez sur « supprimer », la ligne disparaît de l’écran. La question est de savoir ce qui vient de se passer dans la base.

Cet article est technique : il décrit le comportement de la plateforme et ce qu’il faut mettre en face. Il ne dit pas ce que votre obligation légale exige — c’est le métier de votre conseil, pas le nôtre.

Ce que Salesforce fait quand vous supprimez un fichier

Un fichier Salesforce n’est pas un objet, mais trois :

• ContentDocument désigne le document lui-même ;
• ContentVersion désigne une version précise, et porte le contenu binaire ;
• ContentDocumentLink rattache le document à un enregistrement.

Cette structure a une conséquence directe sur la suppression. Supprimer un ContentDocumentLink détache le document de la fiche : il disparaît de la liste liée, mais le ContentDocument existe toujours, ses versions aussi, et le quota est toujours consommé.

Supprimer le ContentDocument place l’objet et toutes ses versions dans la corbeille de l’org, où ils restent quinze jours avant purge — ou jusqu’à ce que la corbeille soit vidée manuellement.

Trois écarts en découlent, et ils passent tous inaperçus depuis l’interface :

• Le fichier détaché mais présent. Il n’apparaît plus sur aucune fiche. Il est toujours dans l’org, retrouvable par requête, et compté dans le stockage.
• Le fichier partagé. Un contrat lié au compte et à l’opportunité possède deux ContentDocumentLink. En retirer un ne supprime rien.
• Le délai de corbeille. Entre le clic et la disparition effective, il s’écoule jusqu’à quinze jours.

Le résidu que personne ne mesure

La plupart des solutions documentaires posent leur propre couche d’index par-dessus les fichiers Salesforce. Retirer un document de leur interface supprime leur enregistrement d’index.

Le ContentDocument, lui, reste. Il n’est plus visible dans la GED, plus rattaché à rien de lisible, et toujours facturé dans votre quota de stockage de fichiers.

Sur une org de quelques années, ce résidu s’accumule sans que rien ne le signale. Il ne devient visible que le jour où l’on compare le nombre de documents affichés par l’outil au nombre réel de ContentDocument de l’org. L’écart surprend.

Deux conséquences : vous payez du stockage pour des fichiers que vous croyez supprimés, et vous êtes incapable d’affirmer qu’une pièce a réellement quitté votre système.

Ce qu’il faut pour répondre à une demande d’effacement

Répondre « c’est supprimé » ne suffit pas. Il faut pouvoir dire quoi, quand, et par qui. Cela suppose quatre mécanismes, et ils fonctionnent ensemble.

1. La suppression atteint le fichier, pas l’index

L’opération doit supprimer le ContentDocument lui-même. C’est la seule façon de libérer le quota et de rendre la pièce irrécupérable par requête.

2. Le rattachement multiple est traité explicitement

Si le document est lié à un autre enregistrement, le supprimer casserait un dossier qui n’a rien demandé. Le comportement correct est de l’épargner et d’écrire pourquoi : la trace doit dire « non supprimé, encore rattaché à tel enregistrement », et non se taire.

C’est le cas de figure le plus fréquent en pratique, et celui que les outils traitent le plus mal.

3. Le journal précède la suppression

L’ordre compte. Journaliser d’abord le document, son tag, son dossier, son auteur et la date. Supprimer ensuite. Un journal écrit après coup peut manquer l’information qu’il devait conserver.

Ce journal est la seule chose qui reste après l’opération. C’est donc lui, et lui seul, qui constitue votre preuve.

4. La rétention connaît les dossiers gelés

Une purge automatique fondée sur une durée de conservation est utile. Elle devient dangereuse le jour où elle emporte une pièce nécessaire à un litige en cours.

Il faut donc une conservation à titre probatoire : un marquage qui bloque la purge sur les dossiers concernés par une procédure ou un contrôle. Sans elle, une purge automatique est pire que pas de purge du tout.

Le mode simulation, ou comment ne pas découvrir après

Une suppression de masse est irréversible passé le délai de corbeille. La lancer sans savoir ce qu’elle va emporter est le genre d’opération qu’on ne fait qu’une fois.

Un mode simulation exécute la sélection sans rien détruire, et affiche :

• les fichiers qui seraient supprimés, avec leur tag et leur dossier ;
• ceux qui seraient épargnés, avec le motif ;
• le volume de stockage que l’opération libérerait.

Vous lisez la liste, vous corrigez la sélection, puis vous exécutez. C’est la différence entre une purge maîtrisée et un pari.

Comment gedone traite ces quatre points

gedone journalise le retrait, puis supprime le fichier. Le ContentDocument part réellement, et le quota est libéré.

Si le document est rattaché à un autre enregistrement, il est épargné et le motif est écrit dans le journal. Chaque dépôt, consultation, partage et suppression est tracé, avec son auteur et sa date. Une durée de rétention configurable purge ce qui a dépassé sa durée de conservation, sauf sur les dossiers marqués en conservation probatoire. Un mode simulation montre ce qui serait supprimé avant que rien ne le soit.

Ajoutons ce qui n’est pas une fonction, mais une propriété d’architecture : gedone ne déclare aucun site distant. Vos documents ne quittent jamais votre org, ce qui retire une question à votre registre de sous-traitance plutôt que d’en ajouter une.

Ce qu’il faut retenir

Détacher n’est pas supprimer : un ContentDocumentLink retiré laisse le ContentDocument et son stockage en place. Supprimer un index n’est pas supprimer un fichier.

Pour produire une réponse tenable, il faut une suppression qui atteint le fichier, un traitement explicite du rattachement multiple, un journal écrit avant l’opération, et une purge qui sait s’arrêter devant un dossier gelé. Le mode simulation n’est pas un confort : c’est ce qui rend l’opération vérifiable avant d’être irréversible.