Packaging managé (Managed Packages) : bonnes pratiques

Le Managed Package est le format de distribution obligatoire pour toute application vendue sur AppExchange. Contrairement à un package non managé, il protège votre propriété intellectuelle (code masqué chez le client), autorise les mises à jour contrôlées, et impose une discipline architecturale stricte dès le premier jour. Voici les bonnes pratiques qui font la différence entre un package fragile et un package pérenne.

1. Choisir le bon type de package : 1GP ou 2GP

Salesforce propose deux générations de packaging managé :

• First-Generation Packaging (1GP) : développement directement dans l'org packaging, historique mais encore largement utilisé pour les packages existants.
• Second-Generation Packaging (2GP) : approche "package as code", développement dans des Scratch Orgs, versionné dans un dépôt Git, avec un fichier sfdx-project.json qui décrit la structure.

Pour tout nouveau projet, 2GP managé est fortement recommandé : il s'intègre nativement aux pipelines CI/CD et facilite grandement la gestion des dépendances entre packages (unlocked packages internes, package de base + extensions).

2. Structurer le namespace et les métadonnées

Toute API exposée (objets, champs, classes Apex globales, composants LWC exposés) est préfixée par votre namespace. Quelques règles à suivre :

• Ne rendez global que ce qui doit réellement être accessible depuis l'extérieur du package ; le reste doit rester public ou private.
• Un membre marqué global ne peut plus jamais être retiré de l'API sans casser la compatibilité ascendante — réfléchissez avant d'exposer.
• Groupez les objets et classes par domaine fonctionnel plutôt que par type technique, pour faciliter la maintenance à long terme.

// Une classe globale devient un contrat public permanent
global class FactureService {
    global static Decimal calculerTotal(Id factureId) {
        // implémentation
    }
}

3. Gérer les dépendances proprement

Un package managé peut dépendre d'un autre package (interne ou tiers). Documentez explicitement ces dépendances dans sfdx-project.json et évitez les références circulaires. Pour les intégrations avec des API standard Salesforce, privilégiez toujours les interfaces publiques documentées plutôt que des contournements non supportés qui casseront lors des releases saisonnières (Spring, Summer, Winter).

4. Configurer les Custom Settings et Custom Metadata correctement

Pour la configuration propre à chaque client, distinguez bien :

• Custom Metadata Types : données de configuration déployables, idéales pour des paramètres identiques entre environnements (mapping de champs, règles métier).
• Custom Settings : valeurs modifiables par l'administrateur client sans passer par un déploiement, adaptées aux réglages propres à chaque org.

Ne stockez jamais de secrets (clés API, identifiants) dans des Custom Settings ou Custom Metadata en clair : utilisez des Custom Metadata protégés combinés à des Named Credentials, ou un stockage chiffré dédié.

5. Anticiper la désinstallation et les limites partagées

Votre package cohabite dans un org avec d'autres applications et le code natif du client. Quelques précautions essentielles :

• Prévoyez un comportement propre à la désinstallation : utilisez un Apex uninstall handler pour nettoyer les données ou notifier l'administrateur.
• Ne consommez pas excessivement les limites partagées de l'org (requêtes SOQL, DML, appels de callout) : un package mal optimisé peut faire échouer d'autres automatisations du client.
• Testez votre package dans un org contenant d'autres packages tiers pour détecter d'éventuels conflits de Trigger ou de Flow.

Un packaging managé bien conçu se reconnaît à sa capacité à évoluer sans casser les clients existants. Cela commence dès l'architecture initiale : namespace soigné, API publique minimale et volontairement restreinte, dépendances documentées. Revenir sur ces choix après la première publication est toujours plus coûteux que de les poser correctement dès le départ.