Optimisation des ressources et des coûts

L'optimisation des ressources et l'optimisation des coûts fonctionnent ensemble pour votre entreprise afin d'atteindre une valeur par coût maximale. Salesforce gère l'infrastructure multilocataire, applique les limites du gouverneur qui garantissent l'équité de la plate-forme pour chaque locataire, et calcule le prix de l'accès via des licences et des crédits de consommation. Ce que vous optimisez est la valeur que vous récupérez : le montant du résultat commercial que renvoie chaque dollar de dépense et chaque unité de capacité de la plate-forme. L'optimisation des ressources est le mécanisme suivant : il utilise efficacement ce pour quoi vous payez déjà. L'optimisation des coûts est le résultat : il oriente les dépenses délibérément vers ce qui favorise l'avantage concurrentiel. Ce pilier les traite comme une seule décision, car ce sont deux vues du même objectif.

Cette vue valeur par coût détermine chaque décision architecturale que vous prenez. Lorsque vous comprenez le coût total de possession, vous faites de meilleurs compromis entre la capacité et l'investissement. Vous adaptez les solutions aux besoins métiers plutôt que de surprovisionner des fonctionnalités inutilisées ou de sous-investir dans des capacités qui accélèrent la livraison de valeur. Une licence, un crédit de consommation, un appel d'API et un environnement sandbox sont tous des entrées dans la même équation. Ce qui compte, c'est la valeur que chacun renvoie, pas le registre dans lequel il atterrit. La question n'est jamais « s'agit-il d'un coût ou d'une ressource », mais « cet intrant a-t-il un rendement approprié? »

Négliger ce pilier produit des conséquences prévisibles. Les entreprises accumulent les licences inutilisées qui consomment du budget alors que les autres capacités ne sont pas financées. Les architectures inefficaces gaspillent la capacité d'API, le stockage et les efforts de développement dans des problèmes qu'une meilleure conception empêche. Inefficacité des ressources dans des composés particuliers au fil du temps de manière prévisible :

Les performances se dégradent à mesure que les volumes de données augmentent.
Les expirations de requête apparaissent à quelques centaines de milliers d'enregistrements lorsque des requêtes non sélectives parcourent des tableaux entiers.
Les exceptions de limite de tas sont affichées lorsque les solutions récupèrent des champs inutiles.
Les expirations processeur sont exposées lorsque des calculs complexes sont exécutés de façon synchrone.
Les contournements se multiplient à mesure que les équipes corrigent chaque nouvelle limite.

Chacun de ces échecs est à la fois un problème de fiabilité et un problème de coût, car le calcul gaspillé consomme la capacité que vous payez. Plus important encore, les équipes manquent des opportunités d'investissement dans l'innovation, car le budget et la capacité d'ingénierie sont consommés par les déchets plutôt que par des initiatives stratégiques.

Les solutions économiques optimisent la valeur en :

Utilisation des capacités de la plate-forme déjà achetées
Alignement des licences et de la consommation de taille adaptée sur l'utilisation réelle
Modélisation du coût complet avant de s'engager dans une approche
Surveillance continue des dépenses par rapport aux résultats métiers

Ces pratiques se compliquent. Les équipes qui intègrent la sensibilisation aux coûts et l'efficacité des ressources dans leur conception offrent plus de capacités par dollar que les équipes qui traitent l'optimisation comme un exercice de nettoyage après une augmentation des dépenses.

L'optimisation des ressources et des coûts se connecte directement à d'autres piliers architecturaux. Operational Excellence réduit les coûts permanents avec l'automatisation qui réduit les efforts manuels. Fiabilité et Fidget justifient les investissements dans les primes par l ' assurance de continuité des activités et la valeur de conformité réglementaire. Ensemble, ces piliers aident les entreprises à investir en toute confiance, car leur architecture offre un rendement maximal.

Utilisez ces principes pour guider vos décisions architecturales en matière d'optimisation des ressources et des coûts sur la plate-forme.

Optimisez pour le coût total de possession. Le coût total de possession (TCO) s'étend au-delà des frais d'abonnement aux crédits de consommation, aux coûts d'implémentation, aux coûts opérationnels, aux dépenses d'intégration et aux efforts de gestion du changement. Évaluez les décisions en utilisant l'analyse TCO pour afficher une vue complète de l'investissement sur la durée de vie d'une solution. Parfois, un investissement initial plus élevé réduit considérablement les coûts opérationnels permanents, et l'analyse du TCO révèle ce compromis. Optimisez la valeur à long terme, pas la minimisation des coûts à court terme.
Alignez les dépenses sur la valeur métier. Connectez chaque investissement Salesforce à un résultat métier mesurable. Les dépenses en licences permettent de mesurer la productivité des utilisateurs par l'adoption et la réalisation des tâches. L'investissement Data 360 permet de prendre des décisions mesurées par la conversion et la valeur de durée de vie des clients. Les coûts sandbox financent la vitesse de développement mesurée par la fréquence et la qualité de déploiement. Lorsque les dépenses correspondent à la valeur, vous investissez en toute confiance dans les facteurs de réussite et identifiez les dépenses qui ne rapportent plus.
Concevez dans les limites de la plate-forme. Les limites du gouverneur définissent ce qu'une solution peut traiter par transaction. Traitez-les dès le départ comme des contraintes de conception, pas comme des obstacles à contourner. Concevez des transactions qui fonctionnent confortablement dans les limites des pics de charge et des volumes de données maximum, et créez une marge pour les futures fonctionnalités, les autres packages installés et les modèles de données inattendus. Les solutions conçues dans les limites de la conception offrent des performances prévisibles et évitent la refactorisation d'urgence ultérieurement.
Optimisez les ressources que vous payez déjà. Avant d'acheter plus de capacité, optimisez le débit, l'efficacité et la valeur des actifs de plate-forme déjà provisionnés. Des requêtes efficaces, le traitement en masse des enregistrements (bulkification), la mise en cache et le cycle de vie discipliné des données réduisent la consommation de calcul, de stockage et d'API dont une solution a besoin. Cette efficacité des ressources est le mécanisme qui pilote l'optimisation durable des coûts : Les déchets éliminés des ressources provisionnées améliorent les performances et le TCO à long terme.
Concession de licences et consommation de bonne taille pour l'utilisation réelle. Mappez chaque utilisateur avec le type de licence requis par son travail, et concevez des automatisations et des agents pour invoquer efficacement les services de mesure. La surlicence et les crédits de consommation non surveillés sont parmi les sources de déchets les plus courantes et les plus coûteuses. Des audits réguliers des rôles, de l'activité de connexion et de l'utilisation des fonctionnalités exposent les opportunités de droitisation, et une visibilité claire sur la combustion du crédit permet de prédire les coûts basés sur la consommation.
Instaurer une gouvernance financière et une culture axée sur les coûts. Gérez les dépenses Salesforce en tant qu'investissement stratégique grâce à une surveillance active et une responsabilité partagée. La gouvernance financière intègre l'analyse coûts-avantages dans les décisions de conception plutôt que de découvrir les coûts après le déploiement. La sensibilisation aux coûts est une responsabilité partagée entre les parties prenantes de l'entreprise, les architectes et les développeurs, qui évaluent les implications des coûts avec les exigences fonctionnelles. Par conséquent, les décisions d'investissement intelligentes sont prises à tous les niveaux sans goulot d'étranglement centralisé.
Pratiquez l'optimisation continue. L'optimisation est une pratique continue, pas un exercice unique. Surveillez les dépenses et la consommation de ressources à travers des tableaux de bord accessibles aux parties prenantes techniques et commerciales. Configurez des alertes qui se déclenchent lorsque les dépenses de consommation atteignent des seuils avant que la consommation galopante ne passe inaperçue. Des examens réguliers mettent en évidence les déchets qui s'accumulent progressivement, vérifient que les investissements d'optimisation préalable ont généré le rendement escompté et exposent de nouvelles opportunités à mesure que les priorités métiers et les volumes de données évoluent.

Comprendre les opérations de Salesforce permet de concentrer les efforts d'optimisation sur les éléments que vous contrôlez. La plate-forme gère la gestion des ressources au niveau de l'infrastructure qui nécessite des équipes dédiées dans les environnements informatiques traditionnels :

Allocation de ressources multiples : Salesforce garantit un partage équitable du processeur, de la mémoire et de la connexion à la base de données entre tous les clients sur l'infrastructure partagée, surveille la consommation des locataires et applique des limites qui empêchent un locataire unique de dégrader les performances pour les autres.
Architecture Limite du gouverneur : Les frontières appliquées par la plate-forme (100 requêtes SOQL par transaction synchrone, 10 secondes de temps processeur, 6 Mo de taille de tas) protègent tous les locataires contre l'épuisement des ressources. Salesforce étalonne ces limites en fonction de la capacité de l'infrastructure multilocataire. Ces limites sont des limites architecturales, pas des restrictions arbitraires.
Optimiseur de requête et moteur d'exécution : L'optimiseur de requête Salesforce génère des plans d'exécution, maintient des statistiques sur la distribution des données et sélectionne des chemins de requête optimaux. Les index gérés par la plate-forme dans les champs standard accélèrent les modèles de requête courants, et l'optimiseur s'adapte automatiquement aux changements de volume de données.
Échelle de l'infrastructure : Salesforce provisionne la capacité matérielle, gère les clusters de base de données, distribue la charge et adapte l'infrastructure à mesure que l'utilisation augmente. Vous ne provisionnez jamais de serveurs, ne gérez jamais la réplication de la base de données et ne configurez jamais d'équilibreurs de charge.
Optimisation des performances de la plate-forme : Salesforce optimise en permanence le code de base de la plate-forme, l'exécution des requêtes, les temps de réponse d'API et les performances de l'infrastructure d'interface utilisateur, et apporte des améliorations à l'infrastructure grâce à ses publications régulières sans nécessiter l'intervention des clients.

Salesforce gère également l'aspect commercial de la plate-forme, c'est pourquoi les licences et la consommation appartiennent au même pilier que le calcul et le stockage. La plate-forme définit les éditions, les types de licence, les compléments et les modèles de crédits de consommation via lesquels la capacité est achetée, et mesure l'utilisation qui prélève ces crédits. Vous ne définissez pas ces prix plus que vous provisionnez les serveurs, mais vous décidez de la quantité de chaque serveur que vous consommez : quelle licence chaque utilisateur détient, l'efficacité avec laquelle une automatisation invoque un service mesuré, le nombre de sandbox qui restent actives.

Ces opérations de plate-forme sont la base sur laquelle vous vous appuyez. Comme Salesforce gère à la fois l'infrastructure et le modèle de tarification, votre effort d'optimisation est entièrement axé sur les décisions architecturales que vous prenez en plus de celles-ci : l'efficacité avec laquelle vous utilisez les ressources qui vous sont provisionnées, et avec quelle volonté vous dirigez les dépenses qui les provisionnent.

Le modèle de responsabilité partagée signifie que vous êtes propriétaire de ressources efficaces pour tout ce que vous créez dans Salesforce. La gestion des ressources de plate-forme prend en charge votre travail, mais ne remplace pas votre besoin d'optimisation. Une solution efficace renvoie plus de valeur métier grâce à la capacité de calcul, de stockage et d'API que vous payez déjà, et c'est le mécanisme qui maintient l'optimisation des coûts durable plutôt qu'une réduction budgétaire unique. Par contre, le calcul inutile consomme des ressources d'infrastructure sans générer de valeur métier et ses composés de coûts. Les performances se dégradent de façon prévisible à mesure que les volumes de données augmentent, et les contournements se multiplient lorsque les équipes contournent les limites qu'elles auraient pu définir.

Vos responsabilités d'optimisation couvrent quatre domaines interconnectés : performances, organisation du code, empaquetage et données. Chacune est une décision valeur par coût avant d'être technique. Cette section explique comment prendre cette décision et pourquoi elle est importante. Les recettes d'implémentation exactes, les modèles au niveau du code, la navigation dans la Configuration et les seuils d'ajustement spécifiques référencés dans cette section se trouvent dans la bibliothèque de modèles Optimisation des ressources et des coûts.

L'optimisation des performances commence par un changement dans la façon dont vous considérez les limites du gouverneur. Ce ne sont pas des obstacles à contourner. Ce sont des contraintes architecturales qui, adoptées dès la conception initiale, produisent des solutions avec des caractéristiques de performance prévisibles. Chaque transaction est exécutée dans des limites fixes, et ces limites existent pour appliquer un partage équitable des ressources entre chaque locataire de la plate-forme. Une transaction Apex consommant 95 de ses 100 requêtes SOQL autorisées ne laisse aucune marge pour les fonctionnalités futures, les déclencheurs ajoutés par d'autres équipes, ou les modèles de données inattendus. Les architectes qui limitent les transactions à la moitié de la limite élaborent des solutions qui peuvent se développer sans refactorisation d'urgence lorsqu'une limite est épuisée. La discipline consiste à concevoir dans les limites des pics de charge et des volumes de données maximums, de sorte que l'ajout d'une fonctionnalité ou l'automatisation d'un autre package n'entraîne jamais une transaction excessive. Un échec courant et coûteux : la solution fonctionne parfaitement contre 10 enregistrements dans une Developer Sandbox, mais atteint les limites du gouverneur en production. Les sandbox Developer copient uniquement la configuration et ne contiennent aucune donnée. Tester des volumes réalistes dans une organisation sandbox Full Copy expose les problèmes d'évolutivité avant les clients.

La sélectivité des requêtes est le plus grand levier pour déterminer si une solution s'adapte à des millions d'enregistrements ou expire à des centaines de milliers. Les requêtes sélectives utilisent des index pour localiser efficacement les enregistrements, tandis que les requêtes non sélectives analysent des tableaux entiers, consomment des ressources de base de données excessives et finissent par expirer. La plate-forme gère des index standard dans un ensemble défini de champs, et applique des seuils de sélectivité qui se resserrent à mesure qu'un objet dépasse son premier million d'enregistrements. L'architecture de la sélectivité implique de filtrer sur les champs indexés en tant que critères principaux et de valider avec l'Outil de plan de requête avant le déploiement par rapport à des objets volumineux, car une requête montrant une analyse de tableau dans un objet haut volume est un incident de production en attente. La sélectivité est la capacité que vous n'avez pas à acheter : une requête efficace est renvoyée en millisecondes et laisse les ressources de base de données disponibles pour chaque autre locataire et chaque autre transaction dans votre propre organisation.

La mise en masse est le schéma d'évolutivité de base qui distingue Apex qui fonctionne à l'échelle d'Apex qui atteint les limites. L'anti-modèle (une requête ou une instruction DML placée dans une boucle) fonctionne correctement avec les petits ensembles d'enregistrements, mais enfreint les limites du gouverneur dès l'exécution d'une opération en masse. Le remède consiste à interroger toutes les données requises dans des instructions uniques extérieures à des boucles, à organiser les résultats dans des cartes saisies par ID pour accélérer la recherche pendant l'itération et à traiter une collection complète avec DML par lot. Concevez chaque automatisation pour gérer le lot de déclencheurs standard de 200 enregistrements sans approcher les limites, et les mêmes échelles de code, quelle que soit la charge en production.

Le traitement asynchrone existe pour un travail qui ne peut pas ou ne doit pas être terminé dans les limites synchrones d'une transaction utilisateur. Le déplacement de ce travail vers un contexte asynchrone double sensiblement les limites du gouverneur et empêche les opérations de longue durée de bloquer les utilisateurs. Cette marge de manœuvre est réelle, mais elle n'est pas gratuite, et atteindre l'asynchronisme dès qu'une limite semble proche est une erreur. L'asynchronisme est un compromis architectural délibéré : il introduit une cohérence éventuelle. Par conséquent, le résultat du travail n'est pas visible dans la transaction qui l'a demandé, ce qui force des décisions d'expérience utilisateur qui ne dépendent pas d'une confirmation instantanée. Il nécessite un traitement et une surveillance explicites des erreurs, car un échec est exposé dans un journal de tâches plutôt que pour l'utilisateur qui l'a déclenché. Et cela peut compliquer le modèle mental du système lorsqu'une seule opération commerciale couvre plusieurs transactions. La décision de la valeur par coût consiste à comparer cette complexité supplémentaire à la capacité dont le travail a réellement besoin, et à garder le travail synchrone lorsqu'il convient confortablement.

Lorsque l'asynchronisme est le bon appel, le choix parmi les mécanismes suit la forme du travail plutôt que la taille de la limite. Apex est pour le volume. Il traite des millions d'enregistrements en les divisant en segments, chacun avec ses propres limites de gouverneur indépendant, ce qui explique la migration des données, l'archivage des données et l'enrichissement en masse. La file d'attente est pour la séquence: Il gère les workflows à plusieurs étapes qui dépassent les limites synchrones, mais n'ont pas besoin d'échelle par lot, et prend en charge l'enchaînement d'une tâche à une autre pour les étapes qui doivent être exécutées dans l'ordre. Les événements de plate-forme sont destinés au découplage: un producteur émet un événement sans connaître ni attendre ses consommateurs. Utilisez ce modèle pour la notification inter-systèmes et pour séparer les tâches qui n'appartiennent pas à la même transaction, en tenant compte du fait qu'une livraison au moins une fois nécessite des abonnés idempotents. Les méthodes futures couvrent le cas étroit du travail asynchrone simple avec des entrées primitives, le plus souvent un appel externe à partir d'un déclencheur synchrone. Leur incapacité à enchaîner ou à accepter des objets complexes est précisément la raison pour laquelle ils ne sont pas un outil pour le travail asynchrone à usage unique. Adaptez le mécanisme asynchrone à la forme de l'œuvre. Sinon, vous échangez un problème de limite du gouverneur contre des coûts de cohérence et de surveillance supérieurs au gain.

La mise en cache convertit les travaux répétés en capacité que vous conservez. Le cache de la plate-forme stocke les données sérialisables à travers les frontières des transactions. Par conséquent, un coup de cache évite de réexécuter la requête ou le recalcul qui a produit la valeur, réduisant directement la consommation de SOQL et de processeur. La décision qui prend ou rompt un cache est celle que vous choisissez d'y mettre et pour combien de temps. Mettez en cache les données qui sont lues beaucoup plus souvent qu'elles ne changent, par exemple les métadonnées personnalisées, la configuration et les valeurs de liste de sélection, et définissez la durée de vie en fonction de la volatilité des données plutôt que d'une valeur par défaut unique. Les données de référence qui changent tous les mois peuvent être mises en cache en toute sécurité pendant des heures, alors que la configuration qui se déplace au cours de la journée nécessite une courte fenêtre afin que le cache ne serve jamais une valeur périmée assez longtemps pour être importante. Une mémoire cache trop agressive échange un gain de performance contre un risque correct, et une mémoire cache avec un faible taux de succès dépense du stockage sans capacité de retour. Par conséquent, le taux de succès est une métrique à surveiller plutôt qu'un paramètre à supposer. Le choix de la partition est une décision de sécurité : utiliser la partition de l'organisation pour les données partagées entre les utilisateurs, utiliser la partition de session pour les données limitées à l'utilisateur qui doivent rester isolées et ne jamais placer d'informations d'identification personnelle dans la partition de l'organisation où chaque utilisateur peut les lire. Lightning Data Service étend la même idée au client: il partage les enregistrements mis en cache entre chaque composant d'une page et élimine les allers-retours redondants du serveur. Chaque coup de cache correspond à une capacité de calcul et d'API que vous n'avez pas à dépenser, tant que la valeur renvoyée est correcte.

L'asymétrie des données est un haut lieu des performances créé par une distribution d'enregistrements déséquilibrée. Lorsqu'un enregistrement parent unique accumule plus de 10 000 enfants, les performances des requêtes se dégradent et des contentieux de verrouillage de ligne apparaissent lors d'opérations simultanées. Le seuil est un signal de conception, pas une limite définitive. Il indique de distribuer la charge entre plusieurs parents, de surveiller les objets à haut volume avec des tâches planifiées qui alertent lorsque n'importe quel parent approche de la frontière, et de trier les charges en masse par ID parent afin d'éviter que des lots simultanés ne se disputent les mêmes lignes. L'asymétrie de propriété, où un utilisateur de l'intégration possède des centaines de milliers d'enregistrements, produit la même contention de verrou et mérite la même distribution de charge.

Salesforce fournit des outils qui permettent de préserver les performances à mesure que la solution évolue. Le Centre d'échelle offre une visibilité au niveau de la transaction sur les opérations à long terme, les litiges de verrouillage de ligne et les transactions proches des limites, puis nomme le déclencheur et l'objet spécifiques impliqués. ApexGuru applique l'analyse IA à la télémétrie d'exécution de production pour les anti-modèles de surface avant qu'ils atteignent l'échelle, et Salesforce Code Analyzer effectue une analyse statique dans le pipeline CI/CD afin d'échouer lorsque des requêtes apparaissent dans des boucles ou lorsque d'autres défauts de performance sont détectés. Event Monitoring révèle les tendances de consommation au fil du temps, et Proactive Monitoring, une fonctionnalité Signature Success Plan, évalue en permanence les risques de performance et d'évolutivité de l'organisation.

L'organisation du code est une décision de coût exprimée en maintenabilité. Généralement, la maintenance consomme la majorité de la capacité de développement d'une solution mature. Par conséquent, la structure que vous choisissez détermine la capacité future à changer plutôt qu'à retravailler. Trois modèles portent la plupart de cette valeur. Le modèle de gestionnaire de déclencheur centralise la logique de déclenchement dans les classes de gestionnaire et réduit le fichier de déclencheur lui-même à un point de délégation minimal, ce qui permet de tester la logique indépendamment du contexte du déclencheur et offre au contrôle de la récursivité un foyer unique. Le modèle de couche de service encapsule la logique métier dans des classes qui exposent des opérations appelables à partir d'un déclencheur, d'un point de terminaison REST, d'un flux invocable ou d'une tâche par lot. Par conséquent, une règle métier vit dans une seule implémentation au lieu d'être dupliquée à chaque point d'entrée et de désynchroniser. Le modèle de sélecteur centralise SOQL pour chaque objet dans des classes dédiées, ce qui rend l'ajustement des requêtes unique et donne à chaque requête une intention explicite et nommée.

Les erreurs DML mixtes sont un risque organisationnel distinct qui mérite d'être explicitement pris en compte. Elles se produisent lorsqu'une transaction effectue un DML à la fois sur des objets de configuration, tels que User et PermissionSet, et sur des objets non configurés, tels que Account et des objets personnalisés, car les modifications de configuration qui affectent l'accès d'un utilisateur doivent être engagées dans une transaction séparée. La défaillance est révélée à grande échelle dans les tâches d'intégration, dans la configuration des tests et dans l'automatisation du provisionnement utilisateur. Les remèdes architecturaux consistent à séparer le DML de configuration et le DML de non configuration à travers les frontières des transactions en utilisant le traitement asynchrone ou les événements de plate-forme, à concevoir des modèles de données qui évitent de combiner les deux opérations dans une seule étape métier, et à isoler le DML de configuration dans les tests.

Les choix d'empaquetage déterminent les coûts de développement à long terme et la réutilisation que vous pouvez réaliser dans l'ensemble d'une entreprise. Les packages gérés de deuxième génération offrent un développement modulaire piloté par la source avec une protection de l'espace de noms et sont le choix approprié pour les produits ISV (Independent Software Vendor) distribués via AgentExchange. Les packages déverrouillés offrent aux équipes internes la même modularité et la même gestion des dépendances sans espace de noms, ce qui convient aux applications d'entreprise qui nécessitent un déploiement indépendant, mais sans référence sur la marketplace. Les packages gérés de première génération restent utilisés pour les produits existants, mais n'ont pas le workflow piloté par la source qui rend le nouveau développement modulaire gérable.

La modularité s'étend aux composants que vous élaborez. Concevez des composants Web Lightning autour d'une responsabilité unique avec des interfaces de propriété claires, privilégiez la composition à l'héritage afin d'assembler des interfaces utilisateur complexes à partir de petits composants ciblés et utilisez des événements personnalisés pour la communication parente plutôt que d'atteindre directement un parent. Exposez Apex réutilisables en tant qu'actions invocables afin de permettre aux administrateurs de composer une automatisation dans Flow Builder à partir des capacités élaborées par le développeur, ce qui réduit les doublons et relie les mondes déclaratif et programmatique. La modularité bien conçue permet de construire une capacité une fois et de la réutiliser, plutôt que de la réimplémenter et de la maintenir séparément à chaque emplacement où elle est nécessaire.

La croissance des données non gérées est la source la plus courante de dégradation progressive des performances, et entraîne en parallèle des coûts de stockage et des temps d'actualisation des sandbox. Deux décisions régissent l'efficacité des données. Le premier est la conception du modèle de données. Les relations principal-détails fournissent des suppressions en cascade, des résumés de cumul et le partage de données au prix d'un couplage plus étroit. Les références offrent de la flexibilité au prix d'une logique de cumul personnalisée, et une stratégie d'index délibérée sur les champs que vous filtrez permet de garder les requêtes sélectives à mesure que les objets se développent. Le deuxième est le cycle de vie des données. Définissez un cycle de vie complet depuis la création jusqu'à l'archivage au lieu de laisser les objets accumuler des enregistrements indéfiniment, car un objet qui se chiffre en millions sans stratégie d'archivage produit finalement des expirations de requête, des requêtes non sélectives et des vues de liste qui expirent.

Choisissez le mécanisme d'archivage uniquement après avoir réglé la conformité. Avant de choisir un mécanisme, vérifiez si les exigences de résidence des données, de droit à l'effacement ou de rétention limitent vos options. Les Big Objects ne peuvent pas être modifiés après l'insertion, ce qui fait d'une suppression de données personnelles archivées uniquement par des enregistrements une opération de suppression-recréation qui peut affecter les pistes d'audit. Les Big Objects stockent des jeux de données historiques massifs dans un espace de stockage séparé des limites standard et adapté aux transactions terminées et aux journaux d'audit qui ne sont plus nécessaires pour le travail quotidien. Le stockage externe permet de garder les données interrogeables via Salesforce Connect tout en réduisant le volume de l'organisation et convient à des modèles de requête flexibles ou à l'intégration à un entrepôt de données d'entreprise. Surveillez la consommation de stockage au niveau de l'objet afin d'identifier la croissance avant qu'elle ne devienne un problème, utilisez Salesforce Files plutôt que Pièces jointes héritées, et configurez la rétention du Journal d'audit des champs par champ en fonction des exigences de conformité, plutôt que d'appliquer une couverture maximale qui gaspille le stockage.

L'optimisation des coûts permet d'équilibrer la valeur métier et le coût de la solution, et dépend en premier lieu de l'établissement d'un coût précis. Pour ce faire, prenez en compte chaque composant de coût, car l'examen d'un composant unique tel que le coût de la licence entraîne une mauvaise compréhension du coût réel de la solution. Un droit de licence modeste peut masquer des coûts d'implémentation, d'exploitation, d'intégration et de modification qui l'éclipsent. Une décision prise sur le nombre visible seul n'utilise qu'une partie de l'image. Le coût total de possession est le modèle qui capture une vue complète. Il englobe tous les coûts associés à une solution Salesforce pendant sa durée de vie et les sépare en coûts directs, qui sont clairement associés à la solution, et en coûts indirects, qui sont réels mais faciles à négliger. La modélisation transforme une estimation de coût en une décision d'architecture informée qui prend en compte la valeur à long terme plutôt que seulement les dépenses initiales.

Les coûts directs sont supportés par la mise en œuvre, le fonctionnement et la maintenance du système :

Les coûts de licence et de consommation correspondent aux frais d'abonnement permanents qui varient selon l'édition, le type d'utilisateur et l'ensemble de fonctionnalités, plus les crédits basés sur la consommation. Le choix de l'édition est une décision de coût fondamentale, car les différences par utilisateur sont importantes. Les coûts de consommation sont difficiles à modéliser à l'avance. Par conséquent, revisitez ces estimations à mesure que les décisions de conception sont prises.
Les coûts d'implémentation couvrent la conception, le développement, les tests, la migration des données et la formation des solutions. Elles sont principalement uniques mais créent des obligations de maintenance permanentes proportionnelles à la complexité. Les entreprises sous-estiment systématiquement les efforts de mise en œuvre, car elles se concentrent sur le développement et sous-estiment les tests et la formation.
Les coûts opérationnels couvrent l'administration, le support utilisateur, la surveillance, la réponse aux incidents et l'outillage opérationnel. Ils se développent avec la complexité des solutions et sont souvent invisibles dans la planification, car ils se manifestent par des efforts internes plutôt que par des factures externes.
Les coûts de maintenance couvrent l'amélioration, la correction technique de la dette, l'adaptation de version et les changements de configuration. Généralement, la maintenance consomme 60 à 80 % de la capacité de développement pour des solutions matures, ce qui en fait la catégorie de coûts permanente la plus importante.
Les coûts d'intégration comprennent les licences de plate-forme d'intégration, la consommation d'API, le développement de la synchronisation et la maintenance continue. Ils se développent avec la complexité de l'écosystème, car la maintenance de l'intégration de point à point se compose à mesure que le nombre de systèmes augmente.
Les coûts de modification couvrent la refonte des processus métiers, la gestion du changement, l'adoption et la coordination des parties prenantes. Ils augmentent avec la portée à travers les unités commerciales et les régions, et sont souvent omis, car ils se manifestent par un effort d'équipe commerciale.

Les coûts indirects ne sont pas immédiatement visibles dans la planification initiale, mais ils s'accumulent de façon significative pendant la durée de vie d'une solution. Pour des implémentations matures, ils dépassent souvent les coûts directs. Une entreprise qui optimise uniquement ses coûts directs tout en ignorant les dépenses indirectes manque la majorité de son investissement total. Plusieurs catégories méritent une attention explicite.

Les coûts d'organisation sont les investissements qui favorisent la réussite de Salesforce, mais ne sont jamais affichés dans une facture Salesforce. Ils comprennent les salaires internes des administrateurs, des développeurs et des architectes, les infrastructures de développement telles que le contrôle de version et l'outillage CI/CD, la maintenance et le développement des compétences en matière de formation et de certification, et le coût d'opportunité de la capacité de développement allouée à la maintenance plutôt qu'à l'innovation. Ce dernier élément est difficile à détecter, car il n'est pas du tout affiché comme dépensé. Il apparaît comme l'innovation qui n'a jamais expédié.

Les intérêts techniques de la dette correspondent au coût cumulé des raccourcis architecturaux. Les raccourcis pris pour respecter une échéance de lancement créent un fardeau de maintenance qui peut nécessiter plusieurs fois plus d'efforts d'origine pour être résolu plus tard, et chaque sprint dépensé pour réparer la dette est un sprint qui n'apporte pas de nouvelle valeur commerciale. Les équipes qui reportent les améliorations de l'architecture assez longtemps constatent que la majeure partie de leur capacité est affectée à la maintenance plutôt qu'à de nouvelles capacités.

Les frais généraux de gouvernance consomment du temps en processus d'approbation, en réunions de coordination et en examens manuels. La gouvernance apporte une réelle valeur ajoutée par la réduction des risques et la cohérence, mais une gouvernance excessive entraîne des coûts cachés par des décisions retardées et des efforts dupliqués. C'est pourquoi l'objectif est de concevoir des systèmes qui favorisent l'autonomie sûre plutôt que d'exiger un goulot d'étranglement d'approbation centralisé pour chaque changement.

Les fonctionnalités inutilisées s'accumulent lorsque des fonctionnalités sont implémentées, mais jamais totalement adoptées. Une solution partiellement déployée consomme de la maintenance continue sans fournir de valeur proportionnelle, et la surveillance de l'utilisation des licences et de l'adoption des fonctionnalités révèle des capacités d'investissement supplémentaires ou de retrait pour rediriger la capacité.

La visibilité complète des coûts nécessite d'attribuer à la fois des éléments de ligne directe et ces éléments indirects, car seule une vue complète permet de prendre une décision d'investissement judicieuse.

Élaborez des modèles TCO pour votre référence et pour des alternatives architecturales optimisées avant de vous engager dans une approche. Les modèles qui projettent des coûts de 3 à 5 ans avec des hypothèses documentées permettent de comparer systématiquement les options. Exécutez une analyse de sensibilité sur les hypothèses les plus importantes afin de déterminer les écarts et les limites des estimations de coût. Planifiez la révision des décisions à mesure que les conditions changent. La discipline consistant à écrire les hypothèses fait partie de la valeur, car elle fait d'une réévaluation ultérieure une comparaison fondée sur des preuves plutôt qu'un nouvel argument.

Évaluez les solutions disponibles sur le marché par rapport au développement personnalisé en utilisant une comparaison complète du TCO plutôt que le coût initial seul. Les décisions Build-vers-Build déterminent l'investissement à long terme par le biais de frais d'abonnement permanents ou d'obligations de maintenance permanentes, et les deux voies ont des profils d'investissement fondamentalement différents.

AgentExchange (auparavant appelé AppExchange) est la principale source de solutions prêtes à l'emploi de la communauté ISV Salesforce. Son profil d'investissement privilégie la rapidité et la maintenance partagée. Le déploiement est mesuré en semaines plutôt qu'en mois requis par une version personnalisée comparable. Le fournisseur conserve les fonctionnalités, y compris la compatibilité avec la version de plate-forme, sans effort du client. La fonctionnalité est prouvée par une clientèle existante, ce qui réduit les risques d'implémentation. Les capacités spécialisées bénéficient de l'expertise du domaine des fournisseurs et d'investissements en recherche qui dépassent ce qu'une seule entreprise financerait seule. La disponibilité du support varie selon l'éditeur de logiciels, généralement avec un chemin d'escalade défini pour les problèmes, et entraîne un coût d'abonnement permanent au modèle.

Le développement personnalisé favorise l'ajustement et le contrôle. Elle répond précisément aux exigences uniques de l'organisation sans compromettre les modèles de solution génériques, donne un contrôle total sur les fonctionnalités et les priorités de la feuille de route, n'offre aucun abonnement permanent au-delà des licences de plate-forme de base, et peut créer un avantage concurrentiel grâce à des capacités non disponibles pour les concurrents qui utilisent les mêmes solutions standard. Le compromis est que l'entreprise assume l'entière responsabilité de la maintenance et de la compatibilité de la solution avec chaque version de Salesforce.

Une comparaison du TCO à long terme transforme ces profils en décision. Les solutions prêtes à l'emploi entraînent des frais d'abonnement annuels supplémentaires, mais incluent des mises à jour de maintenance, d'amélioration et de compatibilité fournies par le fournisseur. Les solutions personnalisées nécessitent un investissement de développement unique, mais entraînent des coûts de maintenance permanents plus la responsabilité totale de la compatibilité des versions. Les totaux sur 3 à 5 ans du projet pour les deux, de sorte que la comparaison reflète l'investissement complet plutôt que la dépense initiale, ce qui favorise généralement l'option qui semblait moins chère le premier jour.

Au-delà du coût brut, quatre facteurs façonnent la décision d'élaboration par rapport à la décision d'achat.

La différenciation stratégique détermine si une capacité est un avantage concurrentiel qui vaut la peine d'être bâtie ou un produit mieux acheté.
Le temps de valorisation favorise l'achat lorsqu'une capacité est immédiatement requise pour capturer une opportunité ou répondre à la pression concurrentielle, car une fonctionnalité personnalisée importante prend des mois.
La capacité organisationnelle favorise l'élaboration uniquement lorsqu'une équipe interne compétente existe avec la capacité de maintenir et de faire évoluer la solution au fil du temps, et favorise l'achat lorsque cette capacité est absente.
Le coût de sortie favorise les options qui préservent la flexibilité, car une solution qui crée un verrouillage profond via des formats propriétaires ou une personnalisation étendue est un risque si les exigences changent.

Systématisez la décision afin qu'elle repose sur une évaluation cohérente plutôt que sur un jugement ad hoc.

Les licences et la consommation sont des entrées dans l'équation valeur par coût, tout comme le calcul et le stockage, et elles sont parmi les sources de déchets les plus courantes. Leur optimisation n'est pas une question de réduction brutale. Il s'agit de mapper chaque utilisateur avec la licence appropriée pour son travail et d'invoquer efficacement chaque service de mesure.

L'optimisation des licences mappe chaque utilisateur avec le type de licence approprié. Il s'agit essentiellement de mapper chaque utilisateur de l'entreprise avec la licence requise par son travail. La surlicence, par exemple l'attribution de licences de plate-forme complètes à des utilisateurs qui n'ont besoin que de fonctionnalités limitées (accès en lecture seule ou simples approbations de workflow), est l'une des erreurs les plus courantes et les plus coûteuses que les entreprises commettent, et elle est invisible jusqu'à ce que quelqu'un regarde. Un audit régulier des rôles utilisateur, de l'activité de connexion et de l'utilisation des fonctionnalités permet de réaliser d'importantes économies en réduisant les droits attribués à l'ensemble de la base d'utilisateurs. Exécutez-le sur une cadence, pas seulement lors du renouvellement — les inadéquations augmentent discrètement à mesure que les rôles changent et que les personnes changent de poste dans l'entreprise.

L'optimisation du crédit à la consommation est de plus en plus importante à mesure que les entreprises adoptent Agentforce, Data 360 et d'autres capacités pilotées par l'IA qui calculent le prix en fonction de l'utilisation plutôt que du siège. Les regroupements de crédits peuvent s'épuiser étonnamment rapidement lorsque les équipes conçoivent leurs processus de façon inefficace ou ne surveillent pas leurs modèles d'utilisation. Contrairement à un nombre de licences fixe, la consommation peut augmenter sans qu'aucune décision de provisionnement ne soit prise. Établissez une visibilité claire sur les taux de crédit, définissez des seuils de consommation qui déclenchent un examen, et concevez des automatisations et des agents efficaces pour invoquer les services de compteurs. Le même travail d'efficacité qui maintient une transaction dans les limites du gouverneur maintient un service mesuré dans son budget de crédit. C'est la même idée de valeur par coût, exprimée en termes de consommation.

L'environnement et la stratégie sandbox sont une décision de ressource qui a des conséquences directes sur le coût, et un modèle de livraison Salesforce mature nécessite une stratégie d'environnement bien structurée. Les environnements de développement, de test, de mise en scène et de production ont chacun un objectif distinct, et la combinaison appropriée de types de sandbox permet aux équipes d'élaborer et de valider les modifications en toute sécurité avant qu'elles n'atteignent la production. Le défi est que sans gouvernance délibérée, le nombre de sandbox actives prolifère rapidement, en particulier dans les programmes de grande envergure ou à long terme, et entraîne une hausse des coûts qui prend les entreprises au dépourvu. Le remède consiste à traiter le provisionnement sandbox avec la même intentionnalité que n'importe quelle autre ressource. Actualisez ou déprovisionnez les sandbox qui ne sont plus utilisées au lieu de les laisser inactives, laissez le choix du type de sandbox être déterminé par le besoin réel de fidélité des données plutôt que par la commodité, et définissez des politiques claires pour la propriété, actualisez la cadence et la désaffectation afin que le domaine reste dimensionné pour le travail.

L'architecture multi-organisations multiplie les coûts. Une architecture à organisation unique bénéficie de licences consolidées, d'une infrastructure de plate-forme partagée et d'une réduction des surcharges administratives, car il y a tout simplement moins de tâches à gérer, configurer et gérer. Lorsque toutes les unités commerciales fonctionnent dans une seule organisation, les intégrations sont internes plutôt qu'inter-organisations, le partage de données est natif et l'empreinte totale des sandbox, du support et des outils de gouvernance reste proportionnellement plus faible. Les architectures multi-organisations, bien que parfois nécessaires pour la géographie, la conformité réglementaire ou la séparation organisationnelle, introduisent un effet multiplicateur sur certaines catégories de coûts. Chaque organisation supplémentaire a ses propres exigences en matière de licences, son propre domaine sandbox, ses propres frais généraux d'intégration et ses propres efforts administratifs, et exige des outils plus sophistiqués pour gérer le déploiement inter-organisations, la fédération de l'identité et la synchronisation des données. Comprenez le véritable coût total de possession de chaque organisation supplémentaire avant de prendre une décision architecturale difficile et coûteuse à annuler.

Les coûts d'API et d'intégration sont parmi les facteurs de coût les plus sous-estimés dans un écosystème Salesforce. La connexion de Salesforce à un système externe peut sembler simple, mais les exigences d'intégration complexes accumulent rapidement les coûts entre les licences middleware, les efforts de développement, la maintenance continue et la consommation d'API qui découle de chaque échange de données. Les entreprises qui ont de nombreux systèmes intégrés, des volumes de données élevés ou des exigences de synchronisation en temps quasi réel sont particulièrement exposées. L'approche architecturale compte ici. Les intégrations bavardes et précises qui effectuent de fréquents petits appels d'API sont plus coûteuses et plus fragiles que les modèles en masse ou pilotés par l'événement bien conçus qui réduisent les allers-retours, et les différences se multiplient à mesure que les applications connectées se multiplient. Gouvernez les normes de conception d'intégration, consolidez les plates-formes d'intégration si possible et vérifiez régulièrement si les intégrations existantes fonctionnent toujours aussi efficacement qu'elles ont été conçues à l'origine.

Une architecture durable nécessite davantage que des optimisations initiales de la conception. Elle exige un contrôle continu et une responsabilité structurée. Le suivi des coûts et la gouvernance sont le cadre qui transforme l'optimisation d'un exercice unique en pratique opérationnelle continue. Un suivi cohérent et une propriété claire réduisent le risque de dépassements de coûts inattendus afin que chaque dollar dépensé corresponde à la valeur métier.

Créez une visibilité sur les modèles de dépenses à l’aide de tableaux de bord accessibles aux équipes techniques et aux parties prenantes de l’entreprise, afin que les conversations sur les investissements reposent sur des données plutôt que sur des factures. La visibilité des coûts initie une conversation pilotée par les données sur les priorités d'investissement et les opportunités d'optimisation, et fonctionne mieux lorsque trois vues distinctes sont disponibles. Les tableaux de bord d'utilisation des licences révèlent les utilisateurs inactifs, les utilisateurs détenteurs de licences en trop et les incohérences de type licence, qui sont les opportunités d'optimisation cachées dans un effectif plat. Les tableaux de bord de capacité affichent la consommation de stockage, d'API et de traitement avec les tendances de croissance, afin que les équipes optimisent avant qu'une limite entraîne une panne plutôt qu'après. Les tableaux de bord d'investissement affichent les dépenses par unité commerciale, les coûts environnementaux par équipe propriétaire, les coûts supplémentaires par rapport à leur utilisation et les dépenses projetées basées sur la croissance actuelle, qui transforment une conversation budgétaire en conversation d'allocation.

Ces tableaux de bord peuvent provenir de divers outils, dont Digital Wallet et des rapports personnalisés qui interrogent les métadonnées. L'outil importe moins que la discipline qui consiste à exposer les données où les décisions sont prises. Partagez les tableaux de bord avec les parties prenantes et les dirigeants des entreprises afin de créer la transparence nécessaire à une discussion informée sur les investissements plutôt qu'à un débat budgétaire réactif. Une équipe financière qui observe les modèles d'utilisation peut optimiser les dépenses. Une équipe qui affiche uniquement une facture totale ne peut que la couper.

Mettez en œuvre une sensibilisation aux dépenses dans toute l'entreprise, notamment des alertes proactives qui signalent l'optimisation avant de dépasser les limites :

Les budgets de licence définissent des objectifs d'allocation par service avec des alertes lorsqu'ils approchent de la capacité. Par conséquent, l'approvisionnement non contrôlé n'est pas découvert uniquement lors du renouvellement.
Les budgets de stockage surveillent le taux de croissance avec des alertes lorsque les tendances projettent de dépasser les limites avant le prochain cycle de renouvellement. Ces alertes avertissent à l'avance afin que l'archivage puisse être implémenté avant les dépassements.
Les budgets d'API suivent la consommation par rapport aux limites avec des alertes à des seuils d'utilisation tels que 70 % et 85 %. Par conséquent, l'optimisation est proactive plutôt qu'une réponse d'urgence lorsque les limites entraînent des échecs.
Les budgets sandbox contrôlent la prolifération de l'environnement à travers des limites d'allocation et des processus d'approbation.

Les contrôles budgétaires créent une prise de conscience des coûts sans bloquer les investissements nécessaires. Les seuils d'alerte fournissent des alertes précoces qui permettent une optimisation réfléchie plutôt qu'un brouillage réactif.

L'allocation des coûts crée une responsabilité et une prise de décision informée entre les unités commerciales, et les entreprises la mettent en œuvre à travers l'un des deux modèles qui diffèrent par le degré de responsabilité qu'ils imposent. Showback rapporte les coûts par unité commerciale sans appliquer de frais financiers réels. Elle crée de la transparence et favorise la discussion et la priorisation de l'optimisation soucieuses des coûts sans se contenter de la facturation interne, ce qui convient à une entreprise qui préfère la gestion collaborative des coûts à la responsabilité financière. La rétrofacturation alloue les coûts réels aux unités commerciales et crée une responsabilité financière directe pour les décisions de consommation. Elle favorise un comportement d'optimisation plus fort, car les coûts affectent directement les budgets ministériels, mais elle nécessite une méthode d'allocation précise afin d'éviter les conflits sur qui paie quoi. Dans les deux cas, les règles d'allocation suivent la même logique : les coûts de licence par service utilisateur, les coûts d'environnement par propriétaire de l'équipe de développement, les coûts d'intégration par le processus métier qui consomme l'intégration et les coûts de développement par l'initiative qui finance le travail. Lorsque ces règles sont absentes, chaque coût est inclus dans un budget informatique central et les parties prenantes traitent la plate-forme comme gratuite, ce qui est précisément la condition qui produit des requêtes effectuées sans sensibilisation aux coûts.

Adaptez les pratiques FinOps Cloud à l'économie de la plate-forme Salesforce afin de créer une capacité d'optimisation continue plutôt qu'un nettoyage périodique. Cinq pratiques pèsent lourd.

La collaboration interfonctionnelle entre les parties prenantes des finances, de l'architecture et de l'entreprise garantit que les décisions de coût pèsent la valeur métier avec les dépenses. Il intègre l'expertise financière dans les discussions sur l'architecture et la compréhension technique dans la planification budgétaire.
Une cadence d'optimisation continue empêche l'écart des coûts à travers des cycles d'examen réguliers : un examen mensuel des anomalies qui détecte les pics de dépenses, un audit trimestriel de l'utilisation qui valide les attributions de licences et l'utilisation des capacités, et une évaluation annuelle complète de la capacité de production qui réaligne les dépenses sur les priorités stratégiques.
Les décisions d'investissement pilotées par les données utilisent des données d'utilisation et des modèles TCO plutôt que des hypothèses ou des habitudes historiques. Ces décisions remplacent « nous l'avons toujours fait de cette façon » par une analyse visant à déterminer si les dépenses courantes offrent une valeur optimale.
L'automatisation de la surveillance des coûts réduit les efforts manuels de suivi de l'utilisation, d'identification des opportunités d'optimisation et de génération de rapports. Par conséquent, la pratique évolue avec une complexité organisationnelle sans croissance linéaire des effectifs.
La sensibilisation aux coûts aide les équipes à comprendre comment les décisions architecturales affectent le coût total de possession, car un architecte qui comprend les coûts conçoit de meilleurs compromis et un développeur qui comprend l'économie de la plate-forme écrit une automatisation plus efficace.

Intégrez la sensibilisation aux coûts dans le processus d'examen de l'architecture afin de mettre en évidence les implications des investissements parallèlement aux considérations fonctionnelles et techniques plutôt que de les découvrir après le déploiement. Incluez une évaluation de l'impact sur le coût dans les enregistrements de décision d'architecture qui documentent les principaux choix de conception. Exiger une projection de TCO pour les solutions qui dépassent un seuil d'investissement défini. Évaluez les implications des licences pendant la conception, en déterminant si une approche nécessite des licences premium ou des compléments avant de s'engager. Évaluez le coût d'intégration avant d'adopter un modèle qui affecte la consommation d'API ou les licences middleware. Un comité d'examen de l'architecture qui tient compte des coûts ainsi que des exigences fonctionnelles et non fonctionnelles produit des décisions d'investissement mieux alignées. Considérez le coût comme un élément entrant dans une décision architecturale plutôt que comme son seul moteur, afin que les entreprises investissent de façon appropriée dans ce qui compte tout en évitant le gaspillage dans ce qui ne l'est pas.

La durabilité du cloud computing vise à minimiser l'impact environnemental des infrastructures numériques par une utilisation efficace des ressources, et elle s'aligne naturellement sur la valeur par coût : la même efficacité qui réduit la consommation de ressources réduit également le coût. Salesforce et les architectes partagent la responsabilité des résultats en matière de développement durable. Salesforce gère l'infrastructure du centre de données, notamment l'optimisation de l'efficacité de l'utilisation de l'énergie, l'efficacité du refroidissement et la gestion du cycle de vie du matériel, ainsi que la mise en commun de ressources multilocataires et les améliorations de l'efficacité au niveau de la plate-forme. Vous influencez les modèles de consommation de ressources de vos solutions dans cet environnement multilocataire.

La relation entre une solution individuelle et les émissions du centre de données est indirecte, et être précis à ce sujet est important. Les optimisations d'un locataire unique ne réduisent pas directement les émissions du centre de données. Ce qu'ils font, c'est contribuer à un effet agrégé: les gains d'efficacité entre tous les locataires permettent à Salesforce d'exploiter son infrastructure à une utilisation plus élevée et de reporter l'expansion de la capacité. Les métriques d'efficacité des ressources, notamment les requêtes SOQL, le temps processeur, la consommation en tas et le stockage, servent donc d'indicateurs proxy pour la durabilité. L'élimination du gaspillage informatique améliore les performances et les coûts, et contribue aux objectifs d'efficacité de la plate-forme. Les principes de conception de ce pilier, notamment le traitement en masse, les requêtes sélectives, la mise en cache, le traitement asynchrone et le cycle de vie discipliné des données, créent des solutions qui consomment moins de ressources. La durabilité n'est pas une initiative distincte liée à l'architecture. L'efficacité des ressources se présente ainsi lorsque vous la mesurez par rapport à l'impact environnemental plutôt que seulement par rapport au coût financier.

Plusieurs pratiques architecturales ont la plus grande valeur de développement durable, et chacune améliore également les performances ou le coût, ce qui explique leur appartenance au même pilier.

L'automatisation inactive consomme des ressources d'infrastructure sans générer de valeur métier. Déclencheurs qui traitent les enregistrements non pertinents, les workflows qui s'exécutent inutilement et les tâches planifiées qui s'exécutent quand aucun travail n'existe, tout le calcul, le stockage et l'énergie des déchets. Le remède consiste en un audit d'automatisation trimestriel avec des critères explicites pour ce qui est considéré comme inutilisé : aucune exécution au cours des 90 derniers jours, des tâches par lot qui traitent régulièrement zéro enregistrement et une automatisation remplacée par de nouvelles implémentations, mais jamais désactivée. Documentez chaque désactivation pour pouvoir l'annuler si une exigence métier refait surface. Une entreprise qui transporte des douzaines de Générateurs de processus restants d'implémentations antérieures, la plupart sans exécution au cours de l'année écoulée, paie pour évaluer chacun d'entre eux dans chaque enregistrement enregistré correspondant.

La planification d'opérations exigeantes en ressources pendant les heures creuses répartit la charge entre les périodes. Dans un environnement multilocataire, cette discipline améliore la réactivité de la plate-forme pendant les heures ouvrables et permet à Salesforce d'exploiter l'infrastructure à une utilisation moyenne plus élevée. Planifiez l'archivage, l'enrichissement et le nettoyage par lot pour les fenêtres à faible utilisation, échelonnez les tâches plutôt que de lancer 20 à minuit et de provoquer un pic de traitement, et préférez des modèles pilotés par l'événement plutôt que des interrogations planifiées afin d'éviter tout cycle de vérification du travail qui n'est pas là.

Le calcul de la même valeur entraîne un gaspillage répété des cycles processeur et de la capacité de l'infrastructure. Calculez une fois, mettez le résultat en cache et réutilisez-le dans les transactions et les utilisateurs. Le cache de la plate-forme sert des données de référence interrogées à répétition, les valeurs de cumul mises en cache évitent les requêtes agrégées en temps réel où la précision en temps quasi réel est suffisante, les champs de formule recalculent dynamiquement sur l'accès aux enregistrements plutôt que de stocker une valeur et de nécessiter une automatisation pour la maintenir, et Lightning Data Service élimine les requêtes redondantes du serveur sur le client. Chaque calcul évité est la capacité renvoyée à la plate-forme.

Le stockage de données consomme des ressources d'infrastructure et dégrade les performances des requêtes à mesure qu'elles se développent. Les stratégies de rétention qui archivent ou suppriment des données inutiles pour les opérations actives permettent de réduire les tableaux actifs et d'accélérer les requêtes. Archivez des enregistrements anciens dans des Big Objects ou un stockage externe lors d'une tâche planifiée, supprimez définitivement lorsque vous êtes conforme plutôt que de vous appuyer sur une suppression logicielle qui continue de consommer du stockage, et configurez la rétention du Journal d'audit des champs par champ plutôt que d'appliquer un maximum qui stocke beaucoup plus d'historique que la conformité ne l'exige. Comme pour le traitement planifié, les décisions d'archivage individuelles ne réduisent pas directement la consommation d'énergie du centre de données, mais la discipline du cycle de vie des données agrégé entre tous les locataires améliore l'efficacité de la plate-forme et reporte l'expansion de l'infrastructure de stockage.

Les intégrations externes consomment des ressources dans Salesforce et dans les systèmes auxquels elles se connectent. La Capture des données de modification et d'autres modèles pilotés par l'événement éliminent les appels d'interrogation qui vérifient à répétition les modifications et n'en trouvent aucune, ce qui réduit la consommation d'API, profite aux limitations du gouverneur et supprime le calcul inutile. Les schémas d'API composés regroupent plusieurs opérations en un seul appel, l'API de transfert en masse v2 traite les volumes importants beaucoup plus efficacement que des milliers d'appels REST individuels, et réessayer une logique avec un backoff exponentiel évite de mettre en difficulté un système externe. Une intégration unique qui interroge toutes les cinq minutes et ne trouve rien à faire la plupart du temps est un pur gaspillage, alors que la même intégration pilotée par des événements de modification ne traite que les changements réels.

Les architectures d'agents consomment des ressources de calcul par inférence de modèle de langage volumineux, et le même état d'esprit d'efficacité s'applique. Réduisez la longueur des invites, résumez l'historique des conversations au lieu de transmettre des transcriptions textuelles complètes qui croissent sans limite, utilisez le plus petit modèle suffisant pour une tâche au lieu d'utiliser par défaut les plus compétents, et mettez en cache les données de référence et les réponses déterministes. La récupération de 50 résultats de recherche vectorielle lorsque seulement 5 sont évalués dépense en ressources d'inférence et de récupération sans valeur ajoutée. Par conséquent, configurez des limites de récupération adaptées à l'utilisation réelle.

La durabilité, comme le reste de ce pilier, nécessite une surveillance continue plutôt qu'un passage unique, car les modèles de consommation de ressources changent à mesure que les solutions évoluent, que les volumes de données augmentent et que les populations d'utilisateurs augmentent. La surveillance est importante uniquement lorsqu'elle déclenche une action. Définissez des seuils actionnables pour chaque métrique (nombre de requêtes SOQL qui dépasse un objectif par transaction, croissance du stockage au-delà d'un pourcentage mensuel ou taux de succès du cache inférieur à un objectif) et documentez les optimisations à poursuivre en premier. Concentrez vos efforts sur les transactions à haut volume et les automatisations fréquemment exécutées, où les améliorations de l'efficacité ont l'impact global le plus important. Le Générateur de processus a pris fin le 31 décembre 2025 Migrez les Générateurs de processus restants vers Flux. Ne vous contentez pas de les désactiver.

Utilisez cette liste de contrôle pour déterminer si une solution renvoie une valeur maximale par coût. Il combine les pratiques d'utilisation efficace des ressources et de discipline par rapport aux coûts de ce pilier en un seul examen, car les deux sont une décision unique.

Modélisation de la valeur et du coût

Connectez chaque investissement Salesforce important à un résultat métier mesurable.
Modélisez le coût total de propriété entre les catégories directes, indirectes, uniques et continues avant de vous engager dans une approche.
Comparez le TCO pour la référence et les alternatives architecturales optimisées sur un horizon de 3 à 5 ans.
Appliquez une évaluation build-vs-buy cohérente qui prend en compte la différenciation stratégique, le délai de mise en valeur et le coût de sortie plutôt que de se fier à un jugement ad hoc.

Efficacité des ressources

Concevez des transactions confortables pour fonctionner dans les limites du gouverneur sous une charge de pointe et des volumes de données maximum.
Définissez des requêtes sélectives par rapport aux champs indexés et validez avec l'Outil de plan de requête avant de les déployer par rapport à des objets volumineux.
Regroupez en masse toutes les opérations de données et choisissez délibérément le traitement asynchrone là où les limites synchrones l'exigent.
Mettez en cache les données de référence via Cache de la plate-forme et Service de données Lightning afin d'éviter les requêtes répétées et le recalcul.
Évitez les biais dans les données en distribuant le chargement et en surveillant les objets à haut volume.
Centralisez la logique de déclencheur, de service et de sélecteur pour que la logique métier reste testable et peu coûteuse à modifier.
Définissez un cycle de vie complet des données, de la création à l'archivage, et surveillez la consommation de stockage au niveau de l'objet.

Licences et consommation

Associez chaque utilisateur au type de licence requis par son travail, et auditez régulièrement les rôles, l'activité de connexion et l'utilisation des fonctionnalités.
Établissez une visibilité sur les taux de combustion de crédits à la consommation, et concevez des automatisations et des agents pour invoquer efficacement les services de compteurs.
Gouvernez le provisionnement sandbox avec des stratégies claires de propriété, d'actualisation de la cadence et de décommissionnement.
Comprenez le multiplicateur de coût multi-organisation complet avant d'ajouter une organisation, et préférez l'intégration en masse ou pilotée par l'événement à des modèles bavards.

Suivi et gouvernance

Fournir des tableaux de bord de coût et de capacité accessibles aux équipes techniques et aux parties prenantes de l'entreprise.
Définissez des alertes budgétaires pour les licences, le stockage, la consommation d'API et les sandbox afin d'optimiser de façon proactive plutôt que réactive.
Établissez un retour sur investissement ou un retour sur investissement afin de créer une responsabilité entre les unités commerciales.
Adoptez une cadence FinOps : examen mensuel des anomalies, audit trimestriel de l'utilisation et évaluation annuelle complète du TCO.
Intégrez l'évaluation de l'impact sur les coûts aux examens d'architecture et aux enregistrements de décision d'architecture.

Optimisation continue et durabilité

Traitez l'optimisation comme une pratique continue et vérifiez que les investissements d'optimisation antérieurs ont généré le rendement attendu.
Éliminez les automatisations inutilisées et les calculs redondants grâce à des audits réguliers.
Suivez la consommation de ressources au fil du temps et définissez des seuils actionnables qui déclenchent l'optimisation lorsqu'une métrique les franchit.

Partagez vos commentaires sur l'infrastructure bien archivée.