Pricing·Avancé·11 min·Mis à jour le 05/10/2026
Guide · Pricing
Procedure Plans : que faire quand une pricing procedure est pleine
Une pricing procedure a un plafond. On l’a atteint à 128 éléments avec une offre de plus à construire. Voici ce qu’est réellement ce plafond, pourquoi le compter est plus difficile qu’il n’y paraît, et ce que coûte le fait de découper.
Le plafond est réel, et vous le rencontrerez
Une pricing procedure est un expression set : une liste ordonnée d’éléments qui transforme un prix de liste en prix net. Sur l’org concernée, la procédure par défaut portait 128 éléments pour un plafond constaté à 130. L’offre commerciale suivante n’avait nulle part où aller.
Ce n’est pas beaucoup de marge pour un catalogue qui grossit encore, et ça arrive plus vite que prévu : chaque règle conditionnelle, chaque palier, chaque arrondi et chaque mécanisme de remise consomme des éléments sur le même budget.
Compter les éléments est plus difficile qu’il n’y paraît
Voici ce qui rend la planification de capacité réellement difficile : la procédure qui s’exécute n’est pas celle que vous éditez.
Revenue Cloud compile la procédure que vous maintenez en une version générée — celle au
suffixe _Auto — et c’est elle qui tourne. Sur la même org, la source portait
81 steps standard quand la version compilée en portait 128.
Ouvrez la source, comptez, concluez qu’il vous reste la moitié du budget, et vous vous trompez
d’un facteur supérieur à un et demi.
Tout ce que vous voulez savoir du comportement de pricing à l’exécution doit se lire sur la procédure compilée. Ça dépasse largement la capacité : c’est la même raison qui fait qu’une migration vérifiée sur la source peut échouer complètement dans l’org cible.
Avant de découper : arrêtez de dépenser des éléments pour rien
Découper est la réponse intéressante, mais c’est rarement la première. Le geste le moins cher consiste à cesser de consommer le budget avec de la logique qui n’a pas lieu d’être.
La règle est simple et elle est violée en permanence : une decision table sert à une condition ou à un palier. Rien d’autre. Si un produit a un prix, ce prix vit sur le PricebookEntry, où il coûte zéro élément de procédure. Les decision tables ajoutées par réflexe — une par produit, parce que ça paraissait propre — sont la plus grosse source de consommation évitable que nous ayons vue.
Auditer une procédure pleine à la recherche des tables qui ne répondent à aucune question récupère souvent assez de place pour repousser entièrement le changement d’architecture.
Découper : un orchestrateur et une procédure par offre
Quand la logique est réellement de cette taille, la réponse native est un procedure plan : une définition qui évalue des critères et choisit la procédure à exécuter, avec une procédure par offre, chacune avec son propre budget d’éléments.
La structure tient en trois objets. Une définition qui porte le plan, ses critères qui décident de la branche applicable, et ses options qui nomment la procédure exécutée par chaque branche. Salesforce expose l’ensemble en métadonnées et via une API REST d’évaluation : un plan peut donc être construit, versionné et testé sans passer par l’interface.
Le second bénéfice est celui qu’on sous-estime : la logique de pricing d’une offre devient lisible seule, au lieu d’être entrelacée avec celle de toutes les autres dans une liste de 128 éléments. Déboguer un prix passe de « lire une procédure » à « lire la procédure de cette offre ».
Comment on l’a construit
- Construire d’abord la procédure par offre, et la prouver sur un vrai devis. Repricer et lire les totaux de ligne. Ne câblez l’orchestration qu’une fois qu’une branche price correctement toute seule, de façon démontrable.
- Puis câbler le plan. Les deux réglages d’org qui activent l’orchestration sont réversibles, et ça compte plus qu’il n’y paraît — voir plus bas.
- Réactiver tout ce que vous avez touché. Éditer une pricing procedure la désactive. Une procédure désactivée ne price plus du tout, et le symptôme — toutes les lignes au prix de liste — ne ressemble en rien à « vous avez oublié de réactiver ».
Le rollback qui a prouvé autre chose
Pendant la construction du plan, la même org a sorti une erreur sans rapport dans le configurateur produit. Les deux changements étaient assez proches dans le temps pour que le plan soit le suspect évident.
Avoir reculé les deux réglages d’orchestration n’a pas fait disparaître l’erreur du configurateur — ce qui a prouvé, proprement et immédiatement, que le pricing n’était pas en cause. L’enquête s’est déplacée vers le catalogue, où était la vraie cause.
Ça mérite d’être énoncé comme une méthode, pas comme une anecdote. On change une chose, on observe, puis on change la suivante. Si le plan et une modification du catalogue étaient partis ensemble, rien n’aurait pu être éliminé, et l’erreur aurait été attribuée au changement d’architecture le plus récent — c’est exactement comme ça qu’une équipe finit par annuler un travail qui n’a jamais été le problème.
Ce que ça coûte
Plus de procédures, c’est plus d’artefacts à déployer et à garder alignés, et une surface de migration qui grandit avec le catalogue. Les procedure plans sont aussi plus récents que le reste de la pile pricing : on écrit peu dessus en dehors de la documentation Salesforce.
En face : une procédure unique à 128 éléments sur 130 n’est pas un système qu’on peut étendre, et l’alternative au découpage, c’est de refuser l’offre suivante.
Composants Salesforce
Sélectionnez-en un pour ouvrir son détail.
Sur quoi ça repose
- Le plafond de 130 éléments, les 128 utilisés et l’écart 81 contre 128 entre source et procédure compilée ont été constatés sur une org de production. Prenez les chiffres exacts comme indicatifs et comptez sur votre propre org avant de planifier.
- Éditer une pricing procedure la désactive. Ça nous est arrivé sur tous les projets.
- L’orchestration par procedure plan s’active par des réglages d’org réversibles — ce qui en fait une chose sûre à essayer, et un outil d’élimination utile.