Revenue Cloud : La transparence retrouvée grâce au Data Processing Engine
Revenue Cloud : La transparence retrouvée grâce au Data Processing Engine
Pour quiconque a déjà mis les mains dans le moteur de Salesforce Billing ou du CPQ classique, il existe une frustration universelle : l’opacité du Managed Package. Pendant des années, l’architecture de la facturation sur Salesforce était perçue comme une « boîte noire ». Vous configuriez vos règles, lanciez les batchs standards… et surtout vous croisiez les doigts pour que le modèle de facturation du client entre parfaitement dans les cases prévues par l’éditeur.
Si la logique métier différait de ce que le batch avait prévu, vous étiez condamné à des contournements complexes, voire à l’utilisation intensive d’Apex custom pour surcharger le standard. Cette approche créait mécaniquement une dette technique s’alourdissant à chaque release.
C’est précisément ce paradigme que le Data Processing Engine (DPE) renverse aujourd’hui. Avec la nouvelle génération de Salesforce Revenue Cloud, nous passons d’une logique opaque à une architecture transparente, performante et entièrement modifiable.
Le problème historique : La rigidité des Batchs Apex dans Salesforce Billing
Dans l’ancien modèle, la rigidité était la norme. Prenons le cas complexe de la facturation à l’usage (Usage-Based Pricing). Dans l’ancienne méthode, le processus de « Usage Rating » (la valorisation de la consommation) était géré par des classes Apex compilées et verrouillées au sein du package.
Les limites du modèle traditionnel
Si votre client souhaitait agréger ses données de consommation selon une clé complexe (par exemple, un calcul glissant sur plusieurs mois ou une pondération par zone géographique) avant de facturer, le batch standard était incapable de traiter cette exception. Les architectes n’avaient alors que deux options, souvent coûteuses :
- Tordre le modèle de données pour forcer la réalité métier à rentrer dans les cases du standard Salesforce.
- Ajouter des couches de batchs custom, créant des conflits potentiels avec les mises à jour futures.
Salesforce a compris ce point de friction majeur. L’éditeur migre désormais ces logiques de calcul lourdes hors du code propriétaire vers des définitions Data Processing Engine (DPE). Ce changement n’est pas qu’une mise à jour technique ; c’est une libération pour les équipes Ops et Finance.
Comprendre le Data Processing Engine : Accès direct à la source et sans code
Le Data Processing Engine n’est pas seulement un moteur de calcul. C’est un outil d’exposition de la logique métier. Au lieu d’un batch « invisible », Salesforce fournit désormais des Modèles DPE Standards (Templates).
Une recette de cuisine pour vos données
Ces modèles contiennent la recette exacte de transformation de la donnée : « Extraire les Commandes, les joindre aux Produits, appliquer une formule de TVA spécifique, et générer une Ligne de Facture ». L’impact pour l’architecte et le consultant est majeur sur trois niveaux fondamentaux.
| Fonctionnalité | Ancien Modèle (Managed Package) | Nouveau Modèle (Data Processing Engine) |
| Visibilité | Code Apex masqué (Boîte noire) | Interface graphique (Nœuds et flux) |
| Flexibilité | Configuration rigide via settings | Clonage et modification des templates |
| Performance | Limites SOQL classiques | Traitement Big Data (Data Pipelines) |
| Maintenabilité | Dette technique élevée sur le long terme | Standard « Low-Code » évolutif |
La transparence totale : Ouvrir le capot de Revenue Cloud
On peut aujourd’hui littéralement ouvrir le moteur. En accédant au Builder du Data Processing Engine, chaque étape de la transformation de la donnée est visualisable graphiquement.
Pas besoin de savoir lire du code : un administrateur senior ou un consultant peut directement tracer la formule nœud par nœud, comprendre d’où vient une erreur de calcul et identifier le champ source qui pose problème. C’est un atout gigantesque pour le débogage et l’auditabilité financière. Pour monter en compétence sur ces sujets, vous pouvez consulter les ressources de la 2Pace Academy.
Le « Standard Customisable » : La fin du dilemme Custom vs Standard
C’est ici que réside la véritable puissance du Data Processing Engine. Dans 90% des cas, le modèle standard fourni par Salesforce suffira amplement. Une fois activé, il tourne sur l’infrastructure ultra-performante des Data Pipelines (l’architecture robuste qui propulse déjà CRM Analytics).
Le principe du « Clone & Adjust »
Pour les cas particuliers qui hantaient nos projets par le passé, nous ne repartons plus de zéro. La démarche est désormais identique à celle des templates de Flows :
- On clône la définition DPE standard.
- On ajuste le nœud de transformation spécifique (ajout d’une remise, changement de règle d’agrégation).
- On teste et on livre.
L’architecture reste Low-Code. Pas d’Apex complexe à maintenir, on altère simplement une étape d’un flux ETL (Extract, Transform, Load) visuel.
Orchestration native via Flow Builder
Le Data Processing Engine ne tourne pas en vase clos. Il s’imbrique nativement dans l’écosystème Salesforce. Oubliez les planificateurs externes ou les CRON jobs obscurs. Vous déclenchez le calcul :
- Sur un événement précis (ex : passage d’un contrat en statut « Signé »).
- Via une planification récurrente (ex : chaque 1er du mois à 2h du matin).
Tout se pilote visuellement depuis le Flow Builder, garantissant une maîtrise totale du cycle de vie de la donnée transactionnelle.
Performance et Gouvernance : Le passage au Big Data
Le Data Processing Engine résout enfin le problème des limites de gouvernance (Governor Limits) qui limitaient les ambitions des développeurs sur Salesforce Revenue Cloud.
En déchargeant le traitement sur une couche de calcul dédiée, le système est capable de brasser des millions de lignes d’écritures comptables ou de transactions de consommation sans impacter les performances de l’interface utilisateur. Le résultat est ensuite réécrit (Writeback) dans l’objet cible. On obtient ainsi la puissance du Big Data avec la simplicité de l’administration Salesforce. Pour un accompagnement sur mesure dans cette transition, les experts de 2Pace peuvent vous guider.
Et demain ? Le passage à l’échelle avec Data Cloud (Data 360)
Le Data Processing Engine a fait sauter le verrou du calcul. Mais en amont, une autre barrière demeure : la qualité et l’unification de la donnée. Avoir une donnée unifiée dans Salesforce n’est plus un luxe, c’est un impératif stratégique.
L’alliance DPE + Data Cloud
La réponse de Salesforce est l’approche Data 360 (propulsée par Data Cloud). Dans cette configuration, Salesforce Revenue Cloud change de dimension :
- Ingestion : Data Cloud ingère des téraoctets de données brutes provenant de sources externes (AWS, Snowflake, IoT).
- Transformation : Le Data Processing Engine traite ces données pour les rendre « facturables ».
- Action : Le moteur de facturation génère le document final.
C’est une séparation des tâches idéale pour un modèle Usage-to-Cash industriel.
Conclusion
L’introduction du Data Processing Engine marque une rupture nette avec le passé. Le modèle rigide du « One Size Fits All » laisse place à une modularité indispensable aux processus de revenus modernes.
Cela signifie moins de frustration pour les équipes techniques et plus d’agilité pour répondre aux besoins business. En somme, le Data Processing Engine rend à Salesforce Revenue Cloud ce qui manquait le plus aux solutions de facturation complexes : la flexibilité sans la complexité du code.
