Package géré Salesforce : ce que vous installez vraiment dans votre org

Installer un package dans une org de production, c’est accepter que du code écrit ailleurs s’exécute sur vos données. La décision mérite mieux qu’un clic sur « Installer pour tous les utilisateurs ».

Cet article explique ce qu’est réellement un package géré, ce que le format protège, et les six points à contrôler avant d’installer quoi que ce soit — gedone compris.

Ce qu’est un package géré

Un package réunit des objets, des champs, des classes, des écrans et des jeux de permissions, livrés d’un bloc et installables dans une org.

Il en existe deux formes. Le package non géré dépose ses composants dans votre org, qui en devient propriétaire : vous pouvez tout modifier, et vous ne recevrez jamais de mise à jour. C’est un modèle de partage de code, pas de distribution de produit.

Le package géré fonctionne autrement, et c’est celui qui nous intéresse.

L’espace de noms

Un package géré possède un espace de noms, un préfixe réservé et unique à l’éditeur. Tous ses composants le portent : un objet s’appellera prefixe__Document__c, et non Document__c.

Ce détail règle un vrai problème. Sans lui, un package qui livre un objet Document__c entrerait en collision avec le vôtre s’il porte le même nom. Avec l’espace de noms, les deux cohabitent sans se voir.

Il a une seconde vertu : au moindre écran, vous distinguez ce qui vient de vous de ce qui vient de l’éditeur.

Le code est masqué

Dans un package géré, le code source Apex n’est pas lisible dans votre org. C’est ce qui protège la propriété intellectuelle de l’éditeur, et ce qui lui permet de faire évoluer son produit sans casser vos personnalisations.

C’est aussi ce qui vous empêche de le corriger vous-même. La contrepartie tient dans le contrat de maintenance : c’est l’éditeur qui corrige, et vous devez pouvoir compter dessus.

Les limites de gouverneur restent les vôtres

Un point souvent mal compris. Le code d’un package géré s’exécute avec ses propres limites de gouverneur, distinctes de celles de votre code. Un traitement lourd dans le package n’épuise donc pas les ressources de vos propres automatisations.

Ce n’est pas une exonération générale : les limites de l’org, stockage et appels d’API, restent partagées.

Ce que le format garantit — et ce qu’il ne garantit pas

Garanti : l’isolement des noms, la possibilité de désinstaller proprement, la traçabilité de ce qui appartient au package, et la capacité de l’éditeur à livrer des montées de version sans écraser vos personnalisations.

Non garanti : que le code soit bon, qu’il respecte vos règles de partage, qu’il ne fasse pas d’appels vers l’extérieur, ou que l’éditeur existe encore dans trois ans. Le format est un contenant ; il ne dit rien de la qualité du contenu.

C’est précisément ce que la Security Review de l’AppExchange examine. Un package publié a passé cet examen, ce qui est un signal réel. Mais l’installation par lien direct est un mode parfaitement standard, utilisé par tous les packages avant leur publication et par beaucoup de solutions livrées à un nombre restreint de clients. Elle ne change rien à ce qui est installé : c’est le même package géré, avec le même isolement.

Six points à vérifier avant d’installer

1. Les appels sortants

Regardez les paramètres de site distant et les credentials nommés déclarés par le package. S’il n’y en a aucun, le package ne peut appeler aucun service extérieur : vos données ne sortent pas de l’org. S’il y en a, demandez à l’éditeur ce qui transite, et pourquoi.

C’est le point le plus important, et le plus rapide à vérifier.

2. Les jeux de permissions

Un package géré livre ses jeux de permissions. Lisez-les avant de les attribuer : ils disent exactement à quels objets et à quels champs le produit donne accès, et à qui.

Méfiez-vous d’un package qui exige « Modifier toutes les données » sans justification écrite.

3. Le comportement à la désinstallation

Posez la question, et demandez la réponse par écrit : que deviennent mes données si je désinstalle ?

Salesforce conserve les données des objets du package pendant un temps limité après désinstallation, sous forme d’export. Mais la vraie question est ailleurs : savoir si vos documents et vos enregistrements métier vivent dans des objets du package ou dans les vôtres.

Dans le premier cas, vous partez avec un fichier d’export. Dans le second, il ne se passe rien : vos données étaient déjà chez vous.

4. La consommation de stockage

Un package qui duplique des données consomme votre quota. Demandez si le produit copie ou référence. La différence se chiffre en giga-octets.

5. La compatibilité avec les versions

Salesforce publie trois versions par an. Demandez depuis combien de temps le package existe, à quelle fréquence il est mis à jour, et ce que couvre le contrat de maintenance.

6. L’installation en sandbox

Aucun package sérieux ne devrait s’installer directement en production. Installez d’abord en sandbox, attribuez les permissions, faites tourner un cas réel, vérifiez les points précédents, et seulement ensuite passez en production.

Un éditeur qui décourage cette étape vous renseigne sur lui-même.

Le cas de gedone

Par transparence, voici les réponses pour notre propre produit.

Appels sortants : aucun. gedone ne déclare aucun site distant. Le produit s’exécute entièrement dans votre org, et aucune donnée ne transite par un serveur de l’éditeur.

Permissions : deux jeux livrés, l’un pour l’administration, l’autre pour l’usage courant. gedone ne définit aucune permission qui lui soit propre sur vos documents : il lit le modèle de partage existant.

Désinstallation : vos fichiers restent des fichiers Salesforce, aux mêmes endroits, rattachés aux mêmes enregistrements. gedone ne les a ni déplacés ni copiés. Ce qui disparaît, c’est la couche d’organisation — tags, dates de validité, exigences, journaux.

Stockage : aucune duplication. Pour un document déjà présent, gedone ajoute un enregistrement de quelques kilo-octets.

Publication : gedone n’est pas encore sur l’AppExchange et s’installe par lien direct. Nous le disons sur la page tarifs comme dans la FAQ, plutôt que de laisser la question se poser en démonstration.

Ce qu’il faut retenir

Le format « package géré » vous protège de la collision de noms et vous garantit une désinstallation propre. Il ne dit rien de la qualité du code ni de l’honnêteté de l’éditeur.

Les deux questions qui comptent vraiment : le package appelle-t-il l’extérieur, et où sont mes données si je pars ? Un éditeur qui répond clairement aux deux, par écrit, vous en apprend plus qu’une démonstration d’une heure.