Versionner et faire évoluer votre application AppExchange

Publier la première version de votre package n'est que le début. La majorité du cycle de vie d'une application AppExchange se joue dans ses évolutions : correctifs, nouvelles fonctionnalités, montées de version majeures. Une stratégie de versioning mal maîtrisée peut casser l'expérience de centaines de clients installés en production. Voici comment structurer ces évolutions correctement.

1. Comprendre le numéro de version d'un package

Chaque version d'un Managed Package suit un format à quatre segments : majeur.mineur.patch.build (ex. 3.2.0.1). Le segment build est géré automatiquement par Salesforce et n'est pas visible côté client. Les trois premiers segments structurent votre communication :

• Majeur : changement structurant, potentiellement non rétrocompatible côté configuration avancée.
• Mineur : ajout de fonctionnalités, rétrocompatible.
• Patch : correctifs de bugs uniquement, aucun changement de comportement fonctionnel attendu.

2. Compatibilité ascendante : la règle non négociable

Une fois un élément marqué global dans votre API (classe Apex, méthode, objet exposé), il ne peut plus être supprimé ni voir sa signature modifiée de façon incompatible, sous peine de casser les intégrations existantes chez vos clients.

// Version 1.0 : signature publiée
global class FactureService {
    global static Decimal calculerTotal(Id factureId) { ... }
}

// Version 2.0 : on NE PEUT PAS supprimer la méthode existante,
// on ajoute une surcharge à la place
global class FactureService {
    global static Decimal calculerTotal(Id factureId) { ... } // conservée
    global static Decimal calculerTotal(Id factureId, Boolean avecTaxes) { ... } // nouvelle
}

Marquez une méthode @Deprecated plutôt que de la supprimer. Salesforce l'affiche comme obsolète dans les outils de développement tout en garantissant qu'elle continue de fonctionner pour les intégrations existantes.

3. Push Upgrade vs mise à jour manuelle

Deux mécanismes permettent de déployer une nouvelle version chez vos clients :

• Push Upgrade : Salesforce déploie automatiquement la nouvelle version dans les orgs clients, sans action de leur part. Réservé aux patches (correctifs de sécurité ou bugs bloquants), planifiable via le Partner Portal avec une fenêtre de notification préalable.
• Mise à jour manuelle : le client installe lui-même la nouvelle version depuis AppExchange, généralement pour les versions mineures et majeures qui apportent de nouvelles fonctionnalités.

Le Push Upgrade est puissant mais délicat : une régression poussée en Push impacte instantanément toute votre base installée. Ne l'utilisez jamais pour des changements fonctionnels, uniquement pour des correctifs bien testés.

4. Gérer les migrations de schéma de données

Lorsqu'une nouvelle version modifie la structure des données (nouveau champ obligatoire, changement de type), prévoyez un script de migration exécuté via un Post-Install Script (classe Apex implémentant l'interface InstallHandler) :

global class MonPostInstallHandler implements InstallHandler {
    global void onInstall(InstallContext context) {
        if (context.previousVersion() != null
            && context.previousVersion().compareTo(new Version(2, 0)) < 0) {
            // Logique de migration depuis les versions antérieures à 2.0
        }
    }
}

Testez systématiquement ce scénario de mise à jour depuis une ancienne version, pas uniquement l'installation d'un package neuf : c'est souvent le chemin le moins testé et le plus source d'incidents en production.

5. Communiquer les changements aux clients

Une évolution technique réussie s'accompagne toujours d'une communication claire :

• Maintenez un changelog public accessible depuis votre documentation ou votre fiche AppExchange.
• Annoncez les changements majeurs plusieurs semaines à l'avance, en particulier s'ils impactent des workflows existants.
• Prévoyez une période de support des versions N-1 avant de forcer une montée de version majeure.

Versionner un package AppExchange, c'est accepter que chaque décision d'API prise aujourd'hui vous engage pour des années. La discipline de compatibilité ascendante, couplée à une politique claire de Push Upgrade, est ce qui distingue les éditeurs dont les clients renouvellent année après année.