Alternative native à l'AppExchange : une GED qui vit dans votre org

Le réflexe est bon : pour ajouter une gestion documentaire à Salesforce, on ouvre l’AppExchange. On y trouve des éditeurs installés depuis quinze ans, des milliers d’installations, des avis. C’est un point de départ légitime.

Il faut simplement savoir ce que ce catalogue certifie, et ce qu’il ne certifie pas. Car deux produits voisins sur la même page peuvent avoir des architectures opposées, et l’écart ne se voit ni dans la fiche produit ni dans la démonstration commerciale.

Ce que la Security Review garantit vraiment

Tout package publié sur l’AppExchange passe une revue de sécurité conduite par Salesforce. Elle est sérieuse, et elle vérifie des choses précises :

• l’absence de failles classiques dans le code Apex et les composants Lightning — injection SOQL, XSS, référence directe à un objet ;
• le respect du modèle de partage, c’est-à-dire l’usage correct de with sharing et des contrôles d’accès aux champs ;
• l’absence de contournement des mécanismes de la plateforme ;
• la déclaration explicite des services externes appelés par le package.

Le dernier point mérite qu’on s’y arrête. La revue exige la déclaration des appels sortants. Elle ne les interdit pas. Un package peut parfaitement passer la Security Review, être publié, être excellent, et envoyer chaque fichier déposé vers un serveur situé hors de l’Union européenne. C’est déclaré, c’est validé, c’est conforme.

La revue certifie donc la qualité du code et la loyauté de la déclaration. Elle ne certifie pas la localisation de vos documents.

La question qui tranche : où vit le fichier ?

Deux architectures cohabitent sous le même mot « natif », et elles n’ont pas les mêmes conséquences.

Le modèle référencé

Le document reste un fichier Salesforce. Techniquement, un ContentDocument, ses ContentVersion successives, et les ContentDocumentLink qui le rattachent aux enregistrements. Le produit documentaire n’ajoute que des métadonnées : à quel client la pièce se rattache, quel tag elle porte (le tag, c’est le type de la pièce), et jusqu’à quand elle vaut.

Conséquences pratiques :

• un fichier de 4 Mo occupe 4 Mo, une seule fois ;
• les droits d’accès sont ceux de Salesforce, sans second modèle à tenir ;
• rien à synchroniser, donc rien qui puisse se désynchroniser ;
• si vous désinstallez le package, les fichiers sont exactement là où ils étaient.

Le modèle copié ou déporté

Le produit crée une copie du fichier, ou le déplace vers un stockage qui lui appartient, et laisse dans Salesforce un lien ou une vignette.

Conséquences pratiques :

• la consommation de stockage double, ou bascule sur une facture qui n’est plus la vôtre ;
• un second modèle de droits apparaît, qu’il faut aligner sur le premier — c’est l’une des premières sources d’incident des projets documentaires ;
• un connecteur devient un point de panne ;
• à la désinstallation, la question de la restitution se pose vraiment.

Aucun des deux modèles n’est illégitime. Mais ils ne répondent pas à la même exigence, et le second demande une analyse de sous-traitance que le premier n’appelle pas.

La vérification tient en trois minutes

Vous n’avez pas besoin de croire l’éditeur sur parole. Après installation en sandbox, ouvrez la configuration de votre org :

1. Sites distants (Remote Site Settings). Listez les entrées ajoutées par le package. Chacune est une adresse que le code peut appeler.
2. Identifiants nommés (Named Credentials). Même exercice : ce sont des appels sortants authentifiés.
3. Paramètres de sécurité de la session, pour les domaines autorisés.

Un package qui ne déclare aucun site distant ne peut appeler aucun service hors de votre org. Ce n’est pas une promesse commerciale, c’est une contrainte de la plateforme, et elle est lisible en trois clics par votre administrateur.

Posez ensuite la seule question qui compte sur le stockage : votre produit copie mes fichiers, ou les référence ? La réponse détermine si votre quota double.

Le modèle économique compte autant que l’architecture

La tarification par utilisateur est le standard de l’AppExchange. Elle a une conséquence dont on parle peu : elle vous pousse à restreindre les accès pour contenir la facture.

Or une gestion documentaire ne sert que si tout le monde la voit. Le commercial qui vérifie avant d’appeler, l’assistante qui dépose, le gestionnaire qui valide : si deux d’entre eux n’ont pas la licence, ils reprennent leurs anciennes habitudes, et l’org se remet à contenir deux vérités.

Un forfait par org supprime cet arbitrage. Le coût est connu à l’avance, il ne bouge pas quand vous recrutez, et personne n’est exclu de l’outil pour une raison budgétaire.

Six questions à poser à tout éditeur

Elles valent pour un produit publié sur l’AppExchange comme pour un package installé par lien direct.

• Combien de sites distants votre package déclare-t-il, et lesquels ?
• Mes fichiers sont-ils copiés, déplacés, ou seulement référencés ?
• Comment les droits d’accès aux documents sont-ils calculés ?
• Que se passe-t-il, fichier par fichier, si je désinstalle ?
• Une suppression efface-t-elle le fichier, ou seulement votre index ?
• Le prix dépend-il du nombre d’utilisateurs ?

Les six se vérifient en sandbox. Aucune ne demande de faire confiance.

Où se situe gedone

Autant le dire sans détour : gedone n’est pas publié sur l’AppExchange aujourd’hui. Le package s’installe par lien direct, un mode d’installation standard de la plateforme et le passage obligé de tout package avant publication. Ce que vous installez ne change pas : le même package géré, dans votre org, sous vos droits.

Sur les six questions ci-dessus, les réponses sont : aucun site distant déclaré, aucune copie de fichier, les droits Salesforce sans surcouche, rien à restituer à la désinstallation, une suppression qui efface réellement le ContentDocument, et un forfait par org.

Elles sont vérifiables en démonstration, et c’est la seule façon de les prendre au sérieux.

Ce qu’il faut retenir

L’AppExchange certifie la qualité d’un code, pas la trajectoire de vos fichiers. Deux produits du même catalogue peuvent avoir des architectures opposées, et l’écart se lit dans la liste des sites distants, pas dans la fiche produit.

Le critère n’est donc pas « sur l’AppExchange ou non », mais « référencé ou copié ». Vérifiez-le vous-même, en sandbox, avant de signer.