GED native ou GED externe pour Salesforce : comment choisir
Le choix se joue rarement sur les fonctions documentaires. Il se joue sur ce qu'il faut maintenir une fois le projet livré. Voici les six critères qui tranchent.
Une entreprise qui travaille dans Salesforce et veut organiser ses documents a trois options : une GED extérieure reliée par un connecteur, un développement sur mesure dans l’org, ou un package documentaire natif.
Les démonstrations comparatives portent presque toujours sur les fonctions : versionnement, recherche, workflow. C’est le mauvais terrain. Sur celui-là, une GED extérieure établie gagne toujours, puisqu’elle fait ce métier depuis vingt ans. La vraie question est ailleurs : ce qu’il faudra maintenir dans trois ans.
Critère 1 — Le modèle de droits
C’est le critère le plus lourd, et le plus sous-estimé en phase de choix.
Dans Salesforce, l’accès à un document découle de l’accès à l’enregistrement : profils, jeux de permissions, règles de partage, propriétaire. Ce modèle existe déjà, il est éprouvé, et vos administrateurs le connaissent.
Une GED extérieure a le sien. Il faut donc faire correspondre les deux, et les tenir synchronisés. Un commercial change d’équipe dans Salesforce : ses accès documentaires doivent suivre. Un compte passe en portefeuille confidentiel : les documents doivent suivre aussi.
En pratique, cette synchronisation se fait par un traitement périodique, elle dérive, et personne ne s’en aperçoit avant l’incident. C’est la première source de problème des projets documentaires reliés par connecteur.
Une solution native n’a pas ce problème parce qu’elle n’a pas de second modèle : elle lit celui de la plateforme.
Critère 2 — Le lien avec le client
Un document professionnel a rarement de valeur en lui-même. Il en a par ce à quoi il se rattache : ce client, ce dossier, ce contrat.
Sorti de Salesforce, ce lien devient une convention — un nom de dossier, un identifiant recopié, une arborescence miroir. Une convention se respecte tant qu’on y pense.
À l’intérieur, le lien est une donnée. Il ne se perd pas parce qu’il n’y a rien à recopier.
Critère 3 — Le nombre d’outils ouverts
Un commercial travaille dans l’outil où il fait son métier. Si le document est ailleurs, il ira l’y chercher quand il en aura besoin, mais il n’ira pas l’y ranger.
C’est ce qui explique la trajectoire habituelle d’un projet de GED extérieure : adoption correcte en lecture, adoption faible en dépôt, et au bout d’un an une GED à moitié pleine que plus personne ne considère comme fiable.
Le critère à évaluer n’est donc pas « les utilisateurs peuvent-ils accéder aux documents ? » mais « où déposent-ils les documents quand ils sont pressés ? ».
Critère 4 — Ce qu’il faut maintenir
Une GED extérieure reliée à Salesforce, c’est trois choses à maintenir au lieu d’une : la GED, le connecteur, et la correspondance des droits. Chacune évolue à son rythme, et les montées de version ne sont pas coordonnées.
Un développement sur mesure dans l’org supprime le connecteur mais crée une autre dépendance : le code doit être repris à chaque version majeure de la plateforme, et il appartient de fait à celui qui l’a écrit. Le coût réel d’un développement documentaire n’est jamais son développement, c’est sa cinquième année.
Un package géré déplace cette charge chez l’éditeur : c’est ce que finance la maintenance annuelle.
Critère 5 — Le stockage
C’est l’argument qu’on entend en premier, et il mérite d’être chiffré plutôt que supposé.
Votre org dispose d’un quota de fichiers, distinct du quota de données. Le volume documentaire réel d’une PME est souvent inférieur à ce qu’on imagine : des PDF administratifs pèsent quelques centaines de kilo-octets, pas plusieurs méga-octets.
Deux points à vérifier avant de conclure :
- Votre consommation réelle, lisible dans la configuration de l’org, page d’utilisation du stockage. Ne raisonnez pas sur une estimation.
- La duplication. Une solution native qui copie vos fichiers pour les organiser double votre consommation. Une solution qui les référence n’ajoute que quelques kilo-octets par document. La question se pose telle quelle à l’éditeur.
Et comparez à coût complet : l’abonnement d’une GED extérieure, plus le connecteur, plus le temps d’administration double.
Critère 6 — Ce que la solution sait dire
Dernier critère, celui qui décide une fois les cinq autres pesés : savoir si la solution dit ce qui manque.
La plupart des GED, natives ou non, savent stocker, classer, versionner et rechercher. Très peu savent répondre à la question qui compte dans un dossier : quelles pièces devraient s’y trouver, et lesquelles n’y sont pas.
Cette fonction suppose un endroit où écrire l’attendu, et un mécanisme qui la compare au contenu réel. Si la solution ne l’a pas, votre contrôle de complétude restera manuel, quel que soit le reste.
La grille de décision
| Situation | Ce qui convient le mieux |
|---|---|
| Vos documents sont liés à des clients Salesforce | Une solution native |
| Vous devez savoir ce qui manque dans un dossier | Une solution qui gère des exigences |
| Vos documents ont des dates de validité | Une solution qui porte la date et alerte |
| Vous gérez aussi des documents sans lien avec Salesforce (RH, qualité, juridique) | Une GED d’entreprise, éventuellement en complément |
| Vous avez besoin de workflows documentaires complexes, parapheurs, signature | Une GED spécialisée, ou un outil dédié en complément |
| Votre modèle de données est très particulier et figé | Un développement, en connaissant son coût de maintenance |
Les deux approches ne s’excluent pas. Une entreprise peut très bien tenir ses documents clients dans Salesforce et ses documents internes ailleurs. Ce qu’il faut éviter, c’est que les mêmes documents vivent aux deux endroits.
Les questions à poser en démonstration
Quelle que soit la solution évaluée, ces six questions révèlent l’essentiel en quinze minutes :
- Mes fichiers sont-ils copiés ou référencés ?
- Les droits viennent-ils de Salesforce, ou faut-il les redéfinir ?
- Que se passe-t-il si je désinstalle ? Où sont mes fichiers ensuite ?
- Puis-je voir deux dossiers côte à côte dont les listes de pièces attendues diffèrent ?
- Que se passe-t-il quand un document expire ? Qui est prévenu, et quand ?
- Combien de temps pour déclarer un objet personnalisé, et faut-il du code ?
Une solution qui répond mal à la troisième question est une solution dont vous ne sortirez pas. C’est celle qu’on oublie le plus souvent de poser.
Ce qu’il faut retenir
Le choix ne se joue pas sur la richesse fonctionnelle mais sur trois coûts durables : la synchronisation des droits, le nombre d’outils ouverts par les équipes, et ce qu’il faudra reprendre à chaque montée de version.
Si vos documents sont liés à vos clients Salesforce, la solution native supprime les trois. Reste le critère qui départage les solutions natives entre elles : savoir laquelle dit ce qui manque.