Fichiers ou pièces jointes : comprendre la différence avant de migrer

Dans une org un peu ancienne, deux mécanismes coexistent pour stocker un document sur un enregistrement. La liste liée « Notes et pièces jointes » d’un côté, la liste liée « Fichiers » de l’autre. Deux boutons voisins, deux comportements profondément différents, et une confusion qui coûte cher dès qu’un projet documentaire se met en route.

Cet article expose ce qui les distingue techniquement, ce que la conversion change, et les précautions à prendre avant de la déclencher.

Deux modèles techniques, deux époques

L’objet Attachment : un fichier, un parent

Le mécanisme historique repose sur l’objet Attachment. Le modèle est d’une simplicité extrême : chaque pièce jointe possède un champ ParentId désignant l’enregistrement auquel elle appartient, et le fichier lui-même réside dans un champ Body.

Cette simplicité en fait tout le défaut. Une pièce jointe appartient à un enregistrement, et à un seul. Pour qu’un contrat figure à la fois sur le compte et sur l’opportunité, il faut le déposer deux fois, ce qui crée deux fichiers distincts consommant chacun leur espace, et dont plus rien ne garantit qu’ils resteront identiques.

Il n’existe par ailleurs aucune notion de version : redéposer un fichier de même nom crée une seconde pièce jointe, et les deux cohabitent sans que rien n’indique laquelle fait foi.

Les Fichiers Salesforce : un document, plusieurs rattachements

Le mécanisme moderne repose sur trois objets qu’il vaut la peine de distinguer.

ContentDocument désigne le document en tant qu’entité, indépendamment de son contenu à un instant donné. C’est lui qui porte l’identité du document dans la durée.

ContentVersion désigne une version précise de ce document, avec son contenu binaire, sa date et son auteur. Un même ContentDocument peut compter dix ContentVersion, et l’historique demeure consultable.

ContentDocumentLink désigne un rattachement entre un document et un enregistrement. C’est la pièce maîtresse du modèle : puisque le lien est un objet à part entière, un même document peut être rattaché à autant d’enregistrements que nécessaire sans être dupliqué.

De cette architecture découlent les trois avantages décisifs des Fichiers : le versionnement natif, le rattachement multiple sans copie, et la génération de liens de partage externes.

Ce que la plateforme en dit, sans le dire

Salesforce n’a jamais annoncé la suppression de l’objet Attachment, et les orgs existantes continuent de fonctionner. Le signal est ailleurs, et il est sans ambiguïté : depuis des années, tout l’investissement de la plateforme porte sur les Fichiers.

Les fonctions récentes, prévisualisation enrichie, partage externe, intégration à Chatter et aux communautés, n’existent que du côté des Fichiers. Les outils d’administration mis à disposition visent la conversion, jamais l’inverse. Et l’expérience Lightning met les Fichiers en avant, reléguant la liste « Notes et pièces jointes » au rang de survivance qu’il faut désormais ajouter délibérément à une mise en page.

Autrement dit : Attachment n’est pas déprécié, il est abandonné à son sort. Pour un projet documentaire engagé aujourd’hui, la conclusion s’impose d’elle-même.

La conversion, et ce qu’elle implique

Salesforce met à disposition un outil gratuit, le Magic Mover for Notes and Attachments, disponible sur l’AppExchange. Il convertit les pièces jointes en Fichiers et, séparément, les anciennes notes en notes enrichies.

Le principe de fonctionnement mérite d’être compris avant tout lancement, car il commande la plupart des précautions qui suivent : l’outil crée le Fichier à partir de la pièce jointe, puis supprime éventuellement l’originale dans un second temps.

Le stockage double temporairement

Entre la création du Fichier et la suppression de la pièce jointe d’origine, les deux exemplaires coexistent. Sur un volume conséquent, la consommation de stockage double donc pendant la durée de l’opération.

Vérifiez votre marge disponible avant de commencer, et procédez par lots plutôt qu’en une seule passe si elle est étroite. Une conversion interrompue faute d’espace laisse une org dans un état hybride, ce qui est le pire des cas de figure.

Les rattachements se conservent, les identifiants non

Le Fichier créé est rattaché au même enregistrement que la pièce jointe d’origine, ce qui préserve l’essentiel. En revanche, l’identifiant change : le nouvel objet possède son propre Id.

Toute intégration, tout rapport, tout code Apex ou tout lien externe qui référençait un Attachment par son identifiant cessera donc de fonctionner. Recensez ces références avant de lancer la conversion ; c’est le point qui provoque le plus de mauvaises surprises.

Les droits changent de logique

Une pièce jointe hérite mécaniquement des droits de son enregistrement parent. Un Fichier obéit à un modèle de partage propre, articulé autour de ContentDocumentLink et de sa visibilité.

Dans la grande majorité des cas, le résultat est équivalent, voire plus fin. Il convient toutefois de le vérifier sur les enregistrements sensibles plutôt que de le supposer, et une sandbox est l’endroit indiqué pour cette vérification.

Les pièces jointes privées demandent une attention particulière

Une pièce jointe peut être marquée comme privée, auquel cas seul son propriétaire et les administrateurs y accèdent. Assurez-vous du traitement réservé à ces cas dans votre conversion, sous peine de rendre visible ce qui ne devait pas l’être, ou d’égarer ce qui devait rester accessible.

La marche à suivre

Une conversion réussie se déroule en cinq temps.

1. Mesurer. Comptez vos Attachment par objet parent, et pesez-les. Une requête suffit, et le résultat conditionne tout le reste : cent pièces jointes ne se traitent pas comme deux cent mille.
2. Recenser les références. Intégrations, rapports, code Apex, liens externes envoyés à des tiers : tout ce qui désigne une pièce jointe par son identifiant devra être repris.
3. Éprouver en sandbox. Convertissez un lot représentatif, puis vérifiez les droits, les prévisualisations et les rattachements sur des cas réels, notamment sur vos enregistrements les plus sensibles.
4. Convertir par lots en production. En dehors des heures ouvrées, en surveillant le stockage à chaque palier, et en conservant les originales jusqu’à validation complète.
5. Nettoyer. Une fois la conversion vérifiée, supprimez les pièces jointes d’origine et retirez la liste liée « Notes et pièces jointes » des mises en page, faute de quoi les utilisateurs continueront d’y déposer des documents et le problème renaîtra de lui-même.

Cette dernière étape est celle qu’on néglige le plus volontiers, et elle explique à elle seule la plupart des orgs qui, deux ans après une conversion, comptent de nouveau plusieurs milliers de pièces jointes.

Et si l’on ne convertit pas ?

L’org continuera de fonctionner. Vous conserverez cependant deux endroits où chercher un document, ce qui suffit à ruiner toute organisation documentaire, et vous vous priverez du versionnement, du rattachement multiple et du partage externe.

Surtout, la plupart des solutions documentaires natives ne traitent que les Fichiers, ce qui est le cas de gedone. Ce n’est pas une paresse d’éditeur : bâtir un produit sur un mécanisme que la plateforme n’entretient plus reviendrait à hypothéquer sa pérennité. La conversion constitue donc un préalable, non une option, et elle vaut d’être menée pour elle-même, indépendamment de tout projet d’outillage.

Avant de lancer la conversion

Attachment relève d’un modèle ancien : un fichier, un parent, aucune version. Les Fichiers reposent sur un modèle riche : un document, plusieurs rattachements sans copie, un historique complet.

La conversion s’opère avec un outil gratuit fourni par l’éditeur. Elle exige d’anticiper le doublement temporaire du stockage, le changement d’identifiants et la vérification des droits. Menée par lots, éprouvée d’abord en sandbox, elle ne présente pas de difficulté particulière ; menée en une passe et sans recensement préalable, elle occupe une équipe pendant une semaine.