Gérer les documents clients dans Salesforce : ce que la plateforme fait, et ce qu'elle ne fait pas

Toute entreprise qui exploite Salesforce finit par y déposer des documents. Un devis signé, une pièce d’identité, un contrat, une attestation. La logique est imparable : la fiche client constitue le lieu où le travail s’accomplit, donc celui où les documents devraient se trouver.

La question survient invariablement au bout de quelques mois. Salesforce est-il une GED ? La réponse honnête tient en une nuance : il l’est en partie, et il importe de savoir laquelle. Le présent article s’emploie à tracer cette frontière.

Ce que la plateforme accomplit, et accomplit bien

Le stockage des fichiers

Depuis l’abandon progressif des anciennes pièces jointes, tout transite par les Fichiers Salesforce. Trois objets techniques les soutiennent : ContentDocument, qui désigne le document lui-même ; ContentVersion, qui en désigne une version précise ; et ContentDocumentLink, qui rattache le document à un enregistrement.

Cette structure emporte une conséquence considérable, et pourtant méconnue : un même fichier peut être rattaché à plusieurs enregistrements sans être dupliqué pour autant. Un contrat lié tout à la fois au compte et à l’opportunité n’occupe pas deux fois l’espace. Le modèle est solide, et c’est sur lui que reposent tous les produits documentaires natifs dignes de ce nom.

Le versionnement

Redéposer un fichier portant le même nom engendre une nouvelle version plutôt qu’un doublon, et l’historique demeure consultable. C’est déjà davantage que ce qu’offre un dossier partagé, où la troisième version s’intitule généralement contrat_final_V2_relu.pdf.

Le partage et les droits

C’est le point fort de la plateforme, et de loin. Les fichiers héritent du modèle de sécurité Salesforce : profils, jeux de permissions, règles de partage, propriétaire de l’enregistrement. Qui n’a pas accès à un compte n’accède pas aux fichiers qui s’y rattachent.

Aucune GED extérieure ne reproduit cela sans effort considérable. Sur SharePoint ou sur Drive, il faut entretenir un second modèle de droits en parallèle du premier et le tenir synchronisé, ce qui constitue l’une des sources d’incident les plus fréquentes des projets documentaires.

La recherche

La recherche globale indexe le contenu des fichiers, texte des PDF compris. Rechercher une raison sociale à l’intérieur d’un contrat fonctionne. Il ne s’agit pas d’une recherche documentaire de niveau professionnel, mais pour retrouver une pièce dont on se rappelle un mot, cela suffit.

Le partage externe

Salesforce sait engendrer un lien public vers un fichier, assorti le cas échéant d’un mot de passe et d’une date d’expiration, ce qui permet d’adresser une pièce à qui ne dispose d’aucune licence.

Les quatre limites

Aucune ne se franchit par le paramétrage, et c’est précisément là que les projets documentaires viennent buter.

1. La plateforme ignore ce qu’un dossier devrait contenir

Il s’agit de la limite fondamentale, et elle est structurelle : Salesforce entrepose des documents sans posséder aucune notion de document attendu.

Ouvrez la fiche d’un dossier de financement. Vous y découvrez la liste des fichiers présents, laquelle ne renseigne en rien sur ce qui devrait s’y trouver. Pour établir la complétude, il faudrait qu’un être humain connaisse la liste attendue, alors même que celle-ci varie selon le montant, le type de contrat et le statut du client.

Les contournements existent, et tous échouent de la même manière :

• Une case à cocher « dossier complet » : cochée manuellement, donc cochée à tort dès que l’urgence presse.
• Un champ formule comptant les fichiers : le nombre ne dit rien de leur nature, et cinq justificatifs de domicile ne constituent pas un dossier complet.
• Une convention de nommage : elle tient un trimestre, jusqu’au premier fichier déposé sous le nom de scan001.pdf.
• Un rapport de suivi : il recense ce qui existe, jamais ce qui manque, car un rapport ne saurait afficher une absence.

Cette dernière remarque mérite d’être posée sans détour. En base de données, l’absence n’est pas une donnée. Pour énumérer ce qui manque, il faut avoir consigné quelque part ce qui est attendu, puis confronter les deux états. Salesforce n’offre nul endroit où consigner cette attente.

2. La plateforme ignore la validité d’un document

Un extrait Kbis vaut trois mois. Une attestation de vigilance URSSAF, six mois. Une habilitation électrique, trois ans. Une visite médicale d’aptitude, d’un à cinq ans selon l’âge.

Aux yeux de Salesforce, ces documents sont rigoureusement identiques : des fichiers assortis d’une date de création. Rien ne porte de date d’expiration, rien ne calcule d’échéance, rien n’avertit quiconque.

On peut créer un objet personnalisé « Document » avec un champ date, un champ formule pour le statut et un flux qui envoie l’e-mail. C’est faisable, et c’est souvent fait. Mais on vient d’écrire un développement spécifique, qu’il faudra documenter, transmettre et reprendre à chaque montée de version. Et on n’a traité qu’une seule des quatre limites de cette liste.

3. La consolidation par client n’existe pas

Les documents d’un client se dispersent sur les enregistrements auxquels ils ont été rattachés : le compte, ses contacts, ses opportunités, ses devis, ses cas, ainsi que vos objets personnalisés.

Il n’existe aucune vue native rassemblant l’ensemble des documents d’un client indépendamment de l’enregistrement porteur. La liste liée « Fichiers » d’un compte ne présente que les fichiers rattachés au compte lui-même, non ceux déposés sur ses opportunités.

L’utilisateur en quête d’une pièce doit donc deviner sur quel enregistrement son collègue l’a rangée. Telle est l’origine véritable du fameux « je sais qu’on l’a reçu, je ne sais plus où ».

4. La traçabilité fine fait défaut

Salesforce journalise beaucoup de choses, mais le suivi détaillé des consultations de documents, savoir qui a ouvert quelle pièce et à quelle date, relève de fonctions d’audit avancées, souvent adossées à des options payantes, et demeure malaisé à exploiter depuis une fiche.

Pour un secteur tenu de prouver qui a vu quoi, la lacune est sérieuse.

Et le stockage, dans tout cela ?

L’objection surgit en premier dans toute discussion documentaire sur Salesforce, et elle mérite d’être précisée.

Votre org dispose d’un quota de stockage de fichiers, distinct du stockage de données. Ce quota se compose généralement d’une base fixe par org et d’une part attribuée par utilisateur, et il varie selon l’édition souscrite. Le chiffre exact de votre org se lit dans la configuration, sur la page d’utilisation du stockage. Ne raisonnez jamais sur une valeur lue dans un article : lisez la vôtre.

Deux remarques s’imposent avant de s’alarmer.

Le volume réel est le plus souvent surestimé. Les documents qui posent difficulté dans un dossier, pièces d’identité, attestations, bilans, sont des PDF de quelques centaines de kilo-octets. Ce sont les numérisations en haute définition et les plans qui pèsent, et ils sont bien moins nombreux qu’on ne le suppose. Consultez votre page de stockage avant de conclure.

Une solution documentaire native ne doit rien dupliquer. C’est le critère à opposer à n’importe quel éditeur : votre produit crée-t-il une copie de mes fichiers, ou se contente-t-il de les référencer ? Un produit qui duplique double votre consommation de stockage, et vous fait payer deux fois le problème qu’il prétend résoudre.

Faut-il pour autant sortir les documents de Salesforce ?

Trois chemins s’ouvrent, chacun assorti d’un coût réel.

Sortir vers une GED extérieure, SharePoint, Drive ou une GED du marché. Vous y gagnez des fonctions documentaires avancées. Vous y perdez le lien avec le client, vous entretenez deux modèles de droits, et vos commerciaux travaillent dans deux outils — donc dans celui où personne ne peut les obliger à ranger.

Développer à l’intérieur de Salesforce. La voie est techniquement praticable, et beaucoup d’intégrateurs l’empruntent. Le coût ne réside pas dans le développement initial, mais dans la maintenance rouverte à chaque montée de version et dans la dépendance à celui qui l’a écrit.

Installer un package natif dédié. On demeure dans Salesforce, on conserve les droits existants, et l’on ajoute la couche manquante : ce qui est attendu, ce qui fait défaut, ce qui a expiré.

Ce qu’il faut retenir

Salesforce constitue un excellent magasin de documents. Il ne constitue pas une gestion documentaire : il ignore la notion de pièce attendue comme celle de validité, et il ne consolide pas les documents par client.

La bonne question n’est donc pas de savoir s’il faut une GED, mais bien : que vous coûte, chaque mois, le fait que personne ne sache ce qui manque dans vos dossiers ? Un dossier rejeté, une journée de chantier perdue, deux jours de recherche avant un audit. Si la réponse est « rien », Salesforce vous suffit, et c’est fort bien ainsi. Si elle se chiffre, la couche manquante se rembourse d’elle-même.