Quand développer une application Salesforce sur mesure plutôt que configurer

Réponse courte : configurez d'abord, toujours. Développez du sur-mesure quand la logique constitue un vrai différenciateur, quand elle doit s'exécuter hors du cycle de vie d'un seul enregistrement, ou quand vous reconstruisez le même contournement pour la troisième fois. Le déclencheur n'est pas la complexité mais la répétition et la propriété : une complexité configurée une fois va très bien, une complexité qu'il faut réexpliquer chaque trimestre non.

Quelle différence entre configurer, étendre et construire ?

• Configurer : objets standard, page layouts, règles de validation, Flow. Aucun code à déployer, et cela suit les montées de version de la plateforme.
• Étendre : objets et champs personnalisés plus un peu d'Apex ou un Lightning Web Component autour d'un processus resté standard. Toujours à la forme de Salesforce.
• Construire : une application conçue. Son modèle de données, ses services, ses tests et son cycle de release, qu'elle vive en Apex et LWC dans votre org ou comme produit packagé.

La plupart des débats "construire ou configurer" portent en réalité sur la catégorie du milieu, où la réponse honnête est le plus souvent d'étendre, pas de lancer un projet.

Pourquoi configurer d'abord reste-t-il la bonne valeur par défaut ?

Le conseil de Salesforce est constant depuis dix ans : évaluez les fonctionnalités natives et déclaratives avant d'écrire du code. Le déclaratif ne porte ni code de test, ni dépôt, ni dette de montée de version, et il avance automatiquement à chaque release. Les limites diffèrent aussi. Le déclaratif rencontre des limites de conception, comme le nombre de règles sur un objet, alors que le code rencontre des limites d'exécution comme le nombre de requêtes SOQL, bien plus difficiles à contourner par la conception (Salesforce Developers).

Le socle monte aussi. Workflow Rules et Process Builder ne sont plus supportés après le 31 décembre 2025, il n'est plus possible d'en créer, et Salesforce oriente les équipes vers l'outil Migrate to Flow (Salesforce Ben). Tout ce que vous construisez aujourd'hui entre en concurrence avec ce que la plateforme absorbera demain, ce qui plaide pour construire moins, pas pour ne rien construire.

Où la configuration cesse-t-elle d'être rentable ?

Voici les cinq signaux que nous utilisons. Un seul ouvre une discussion. Deux ou plus tranchent la question.

1. Le flow est devenu un programme. Si personne ne peut prédire son résultat en le lisant et qu'une modification demande une après-midi entière, vous avez déjà du logiciel. Simplement dans un format sans tests, sans revue de code et sans diff lisible.
2. Le besoin est un modèle de données, pas un écran. Un reporting qui doit croiser trois objets non liés, ou une hiérarchie que le modèle standard n'exprime pas, est un problème de conception. La configuration produira une forme que vous contournerez pour toujours.
3. Le comportement vit hors du cycle de vie d'un enregistrement. Traitements planifiés, ingestion d'événements en volume, réconciliation entre systèmes, reprises et idempotence. L'automatisation déclarative est déclenchée par des enregistrements ; pas ces cas-là.
4. La logique est votre différence et elle change souvent. Règles de prix, intelligence de routage, logique d'éligibilité. Tout ce où être 10% meilleur que le concurrent compte mérite des tests, du versionnage et un propriétaire.
5. Vous le payez trois fois. Le même contournement reconstruit dans un deuxième pays, une deuxième business unit, une troisième org client. Ce n'est plus de la configuration, c'est un produit non packagé.

Comment comparer honnêtement le coût réel ?

Pas le coût de développement contre le coût de configuration, mais trois ans de possession des deux côtés.

• La configuration porte : les heures d'admin par changement, un risque de régression que personne ne mesure, le coût d'intégration de chaque nouvel admin qui doit apprendre le contournement, et un plafond sur ce que vous pourrez automatiser.
• Le sur-mesure porte : l'ingénierie initiale, la couverture de tests, la revue de code, un chemin de montée de version sur trois releases par an, et le risque que la plateforme livre votre fonctionnalité gratuitement l'an prochain.

La comparaison bascule presque toujours sur un chiffre que personne n'écrit : combien de fois par an le processus change. Un changement fréquent favorise le code avec tests, parce que les tests sont ce qui permet de changer sans casser. Un changement rare favorise la configuration, parce que personne n'a à entretenir le muscle.

Que veut dire "construire" aujourd'hui ?

Rarement une application partie de zéro. En pratique, c'est l'une de quatre formes : de l'Apex et des Lightning Web Components dans l'org ; un composant packagé installé dans plusieurs org ; un managed package sur l'AppExchange ; ou un service hors Salesforce que l'org appelle via une API ou un serveur MCP, avec une agent action devant.

Les formes packagées comptent plus que les équipes ne le croient. Construire en package impose le versionnage, le chemin de mise à niveau et l'isolation que l'on saute sinon, et rend le deuxième et le troisième déploiement quasi gratuits. C'est la discipline que nous transposons du produit vers l'intégration : parce que Tekunda construit et livre des produits AppExchange en tant que PDO, nos projets héritent de composants réutilisables et testés au lieu de les refaire.

Comment éviter que le sur-mesure devienne le prochain chantier ?

1. Donnez-lui un propriétaire et un plan de retrait dès le premier jour. Du code sans propriétaire devient une configuration illisible.
2. Mettez les valeurs de paramétrage dans des custom metadata, pas dans le code. Tout l'intérêt est que le métier puisse les changer sans vous.
3. Écrivez les tests comme spécification, pas comme impôt de couverture.
4. Revérifiez à chaque release si la plateforme vous a rattrapé. Supprimer votre propre code est un résultat légitime.

Bien menée, la récompense n'est pas une architecture élégante, elle est opérationnelle. Pour ASSA ABLOY, nous avons ramené les cases hebdomadaires de 3 000 à 350, soit 93% de réduction, sur 11 000 appareils connectés et jusqu'à 2,5 millions d'événements par semaine, dans trois marchés et sans renfort au support. Ce volume n'allait jamais tenir dans un Flow. Si vous pesez la même décision, parlons-en avant la construction, pas pendant le sauvetage.

FAQ

Le sur-mesure coûte-t-il toujours plus cher que la configuration ?

Non. Il coûte plus cher à démarrer et souvent moins cher à faire évoluer. Comparez trois ans de possession, heures d'admin et risque de régression compris.

À partir de quand est-ce trop complexe pour Flow ?

Utilisez un test humain plutôt qu'un décompte d'éléments : si un admin compétent ne peut pas prédire le comportement en le lisant, ni le modifier sereinement en une heure, c'est devenu du logiciel.

Faut-il construire ou acheter sur l'AppExchange ?

Achetez quand la capacité est une commodité et qu'une application publiée couvre l'essentiel du besoin. Construisez quand la logique est la raison pour laquelle vos clients vous choisissent.

Le sur-mesure nous coupe-t-il des montées de version ?

Pas s'il est construit en package, avec une version et une suite de tests. Ce qui bloque, c'est du code non documenté sans propriétaire, et cela arrive aussi à la configuration.