Architecture produit AppExchange : de l'idéation au lancement

Situation

CrossTalent, partenaire ISV Salesforce, développait une application RH native pour l’AppExchange : un produit complet de gestion des ressources humaines destiné à fonctionner à l’intérieur des orgs Salesforce des clients, gérant le cycle de vie des collaborateurs, la gestion de la performance et l’automatisation des processus RH. La mission couvrait l’intégralité du cycle de vie du produit : du concept initial et de la validation marché jusqu’à l’architecture, le développement, la revue de sécurité Salesforce et la publication sur AppExchange.

La distinction entre développement de produit ISV et travail d’implémentation Salesforce standard est fondamentale. Le produit n’était pas construit pour l’org d’un seul client. Il s’exécuterait à l’intérieur de milliers d’orgs différentes, chacune avec sa propre configuration, son propre modèle de sécurité, ses propres volumes de données et ses propres couches de personnalisation. Chaque décision architecturale devait être prise en tenant compte de cette réalité opérationnelle. Le modèle de données ne pouvait pas présumer de la forme de l’org cliente. Les points d’intégration devaient s’adapter à toutes les connexions existantes côté client. Le chemin de mise à niveau devait être planifié dès la première version, parce que les clients ne redéploieraient pas à partir de zéro à chaque changement de version.

Défi

Construire pour AppExchange exige un état d’esprit architectural différent de l’implémentation, à tous les niveaux.

Les contraintes de la plateforme sont plus restrictives et plus lourdes de conséquences. Les limites du gouverneur que l’on peut contourner dans une implémentation mono-locataire deviennent des barrières infranchissables dans un package managé. Un trigger qui approche les limites de mémoire dans l’org d’un client peut les dépasser dans celle d’un autre. Des requêtes dont la performance est acceptable pour les volumes d’un client peuvent échouer pour ceux d’un autre. L’architecture devait être dimensionnée pour les contraintes du déploiement le plus exigeant plausible, pas pour le cas moyen.

La revue de sécurité imposait un autre type de contrôle. Salesforce évalue les packages AppExchange selon une grille de sécurité exhaustive avant publication : injection SOQL, XSS, application CRUD/FLS, conformité au modèle de partage, isolation par espace de noms, et une série de schémas de sécurité spécifiques à la plateforme. Un package qui passe la revue n’est pas simplement révisé. Il est conçu pour que la revue soit naturelle. La sécurité ne peut pas être rajoutée après le développement. Elle doit être architecturée dès la première décision de conception.

L’exigence d’isolation par espace de noms a façonné chaque aspect du modèle de données. Les objets, champs et code d’un package managé vivent dans un espace de noms séparé de celui de l’org du client. Chaque référence devait être consciente de l’espace de noms, chaque point d’intégration devait être conçu pour la frontière entre code managé et non managé, et chaque chemin de mise à niveau devait être planifié dès la version initiale. Ajouter la discipline d’espace de noms après coup n’est pas une refonte. C’est une reconstruction.

Ce que j'ai dit à l'équipe produit au lancement de l'architecture

Ce produit s’exécute dans l’org de quelqu’un d’autre. Les contraintes ne sont pas négociables. La discipline consiste à concevoir comme si chaque limite du gouverneur, chaque règle de partage et chaque frontière d’espace de noms allait être testée en production. Parce qu’elles le seront.

Action

Une équipe de trois développeurs a exécuté la preuve de concept puis le développement complet du package selon la spécification architecturale. Lorsque le package a atteint la revue de sécurité Salesforce, les observations étaient mineures. L’architecture avait été conçue pour passer, pas pour passer après remédiation. Le package managé a été publié sur AppExchange avec une fiche incluant documentation, guides d’implémentation et ressources de support conçues pour permettre l’autonomie des clients dans la mesure du possible et réduire la charge d’implémentation après-vente.

Résultat

L’application RH native a été publiée sur Salesforce AppExchange. Le cycle de vie complet du produit, de l’idéation à la mise sur le marché, a pris 14 mois. La revue de sécurité Salesforce a été validée sans remédiation majeure. Les processus de développement Agile standardisés ont permis une accélération 3x de la mise sur le marché par rapport à l’estimation de référence pour un développement non structuré.

L’architecture a tenu à l’intérieur d’orgs clientes que personne dans l’équipe de développement n’avait jamais vues. Les limites du gouverneur n’ont pas sauté sous les volumes de données les plus lourds plausibles. Le modèle de partage a survécu à chaque configuration de sécurité cliente existante. L’isolation par espace de noms a tenu sur les versions de mise à jour qui ont suivi le lancement initial.

L’architecture produit pour AppExchange exige un niveau de connaissance de la plateforme que le travail d’implémentation requiert rarement. Limites du gouverneur, modèle de sécurité, isolation par espace de noms, contraintes de déploiement multi-locataire : ce sont les fondamentaux de la plateforme que les architectes d’implémentation connaissent en théorie et que les architectes ISV connaissent en pratique.

Recul

Ce motif fonctionne quand l’équipe produit accepte que l’architecture soit en amont du développement, pas en parallèle. Le coût de définir la stratégie d’espace de noms, de partage et de gouverneur avant qu’une ligne de code ne soit livrée paraît disproportionné quand la preuve de concept est à deux semaines. C’est la discipline de conception la moins chère que le produit achètera jamais. Le coût de la rajouter après les retours de la revue de sécurité n’est pas seulement plus lent. Cela signifie souvent re-concevoir autour de code déjà livré.

Cela fonctionne moins bien quand l’ISV s’attend à ce qu’AppExchange se comporte comme un canal de distribution standard. AppExchange n’est pas une place de marché. C’est un contrat de plateforme. La discipline qui décroche la fiche est la discipline qui détermine si le produit survit à l’échelle.

À faire plus tôt : la découverte client sur la variation de processus. La principale source de reprises post-lancement sur les produits ISV est la variation de processus que l’équipe pensait pouvoir coder en dur et que la base cliente avait en réalité besoin de configurer. La découverte en phase d’architecture épargne un cycle de version majeure en année 2.

La connaissance approfondie de la plateforme se transpose directement à l’architecture Agentforce. Les agents opèrent sous les mêmes contraintes de plateforme : les limites du gouverneur s’appliquent à l’Apex invoqué par les agents, le modèle de sécurité gouverne les données auxquelles un agent peut accéder et au nom de qui, et l’architecture de confiance de la plateforme détermine quelles actions les agents peuvent effectuer et dans quels contextes. Un agent qui fonctionne en sandbox peut échouer en production lorsque les volumes de données atteignent les limites du gouverneur. Un template de prompt qui accède à des données en dehors du modèle de sécurité crée des violations de conformité qui peuvent ne pas apparaître avant un audit. Construire pour AppExchange apprend à concevoir dans les contraintes de la plateforme plutôt que de supposer qu’elles ne s’appliqueront pas. C’est la différence entre des agents Agentforce qui fonctionnent de manière fiable en production et des agents qui fonctionnent en démonstration.