Modèles de packaging Salesforce pour ISV : 1GP, 2GP ou Unmanaged

Pour un ISV qui construit un produit commercial sur AppExchange, le modèle de packaging est une porte à sens unique : votre namespace, votre chemin de mise à niveau et la protection de votre propriété intellectuelle dépendent tous de cette seule décision prise tôt. Les managed packages de deuxième génération (2GP) sont aujourd'hui le bon choix par défaut pour presque tout nouveau produit commercial, la première génération (1GP) étant réservée aux cas historiques et les packages unmanaged exclus pour tout ce que vous comptez vendre.

Quelle est la différence entre les packages 1GP, 2GP et unmanaged ?

Un package unmanaged n'a pas de namespace et livre des métadonnées entièrement modifiables. C'est très bien pour des templates open source ou un déploiement ponctuel, mais dès son arrivée, chaque composant se confond avec les personnalisations du client : vous perdez la capacité d'identifier, de prendre en charge ou de mettre à niveau en sécurité ce que vous avez construit.

Un managed package, qu'il soit 1GP ou 2GP, possède un namespace et est verrouillé. Les clients l'installent, l'utilisent et ne peuvent pas modifier directement ses éléments internes. C'est ce qui en fait un produit plutôt qu'un déploiement ponctuel : vous contrôlez le rythme des releases et Salesforce fait respecter la frontière pour vous.

La différence entre 1GP et 2GP tient à l'outillage et à la dépendance à une org. Les packages 1GP sont construits et versionnés dans une packaging org dédiée, qui devient une partie permanente et irremplaçable de votre pipeline de release. Les packages 2GP sont pilotés par les sources, construits depuis le contrôle de version avec la Salesforce CLI, et ne nécessitent aucune packaging org permanente. C'est pourquoi Salesforce oriente les nouveaux ISV vers 2GP depuis des années.

Pourquoi votre namespace est-il une décision définitive ?

Une fois qu'un namespace est enregistré sur une org Developer Edition et utilisé dans un package publié, il ne peut plus être renommé, transféré vers une autre org ni réutilisé. Chaque classe Apex, chaque custom field et chaque objet que votre produit livrera portera ce préfixe dans chaque org cliente, pour toujours. Les fautes de frappe, les abréviations maladroites et les noms choisis à la hâte n'ont pas de seconde chance : planifiez le namespace comme un nom de produit, pas comme un détail technique.

Comment la protection de l'IP et les licences fonctionnent-elles vraiment ?

Les managed packages compilent l'Apex en byte code que les clients ne peuvent ni consulter ni modifier. C'est la protection de base dont tout produit commercial a besoin avant d'approcher l'AppExchange Security Review. Les packages unmanaged n'offrent rien de tout cela : votre logique métier est livrée sous forme de métadonnées lisibles et copiables.

Les licences constituent une couche totalement distincte. Pour mesurer réellement les sièges, les essais et les expirations, vous connectez votre package à une License Management App (LMA), qui suit les installations par rapport à vos leads et opportunities. Cela ne fonctionne proprement qu'avec des managed packages : il n'existe aucun moyen fiable de licencier et de faire respecter des droits sur un élément qu'un client peut modifier librement.

Et les packages unlocked ?

Les packages unlocked se situent entre ces deux mondes : namespace et contrôle de version comme en 2GP, mais métadonnées modifiables et aucune application des licences. Ils sont conçus pour le déploiement interne sur plusieurs orgs au sein d'une même entreprise, pas pour la vente à des inconnus sur AppExchange. Ne les utilisez pas comme raccourci pour éviter le packaging commercial.

Quel modèle de packaging correspond au stade de votre ISV ?

• Construire aujourd'hui un nouveau produit AppExchange : utilisez 2GP. Versionnage piloté par la CLI, suivi de l'ancestry pour les mises à niveau et aucune dépendance à une packaging org fragile.
• Reprendre ou maintenir un ancien produit 1GP : restez en 1GP jusqu'à ce qu'un plan de migration réfléchi existe. Le namespace et la base d'abonnés sont conservés, mais la conversion comporte de vraies contraintes techniques.
• Distribuer des outils ou templates gratuits et modifiables : unmanaged est légitime ici, précisément parce que vous ne protégez pas d'IP et ne facturez pas les mises à niveau.
• Standardiser les déploiements sur vos propres orgs : des packages unlocked, pas des managed packages conçus pour la revente.

Une erreur ici coûte cher à corriger. C'est pourquoi le travail de développement produit de Tekunda avec les partenaires AppExchange commence par cette décision précise, avant qu'un seul composant soit construit, car tous les choix de gouvernance, de test et de release qui suivent en dépendent.

FAQ

Puis-je passer d'unmanaged à managed plus tard ?

Pas directement. Vous reconstruisez les composants dans un managed package avec namespace et gérez une véritable migration client, car les métadonnées et les ID sous-jacents ne sont pas transférés proprement.

Puis-je convertir un package 1GP en 2GP ?

Oui, Salesforce permet de convertir des managed packages 1GP en 2GP en conservant le même namespace et les mêmes orgs abonnées, mais cela demande une planification soigneuse autour de l'ancestry du package et des installations existantes.

Ai-je besoin d'un namespace si je ne vends pas sur AppExchange ?

Seulement si vous distribuez un package managed ou unlocked sur plusieurs orgs. Un déploiement interne unique via des métadonnées unmanaged ou des change sets n'en a pas besoin.

2GP est-il obligatoire pour être listé sur AppExchange ?

Non, les packages 1GP sont toujours pris en charge et listés aujourd'hui, mais les investissements de Salesforce dans l'outillage portent clairement sur 2GP, et la plupart des nouveaux projets ISV devraient commencer par là. Parlez à Tekunda ou parcourez le blog si vous pesez cette décision pour un prochain projet.