Revenue Cloud : comprendre la nouvelle plateforme de revenus Salesforce

Salesforce Revenue Cloud n'est pas un simple rebranding de CPQ et Billing. C'est une refonte architecturale qui unifie catalogue produits, tarification, devis, commandes, facturation et gestion des abonnements sur un socle de données commun, natif sur Salesforce Platform. Pour un consultant qui a l'habitude de Salesforce CPQ, comprendre cette nouvelle architecture est indispensable avant d'aborder un projet de mise en œuvre ou de migration.

Pourquoi Salesforce a repensé son modèle de données

Le modèle CPQ historique reposait sur des objets comme Quote, Quote Line Item ou Product Option, avec une logique de configuration de bundle assez rigide (Product Rules, Price Rules basées sur des formules). Revenue Cloud introduit un nouveau modèle de données appelé Product Catalog Management (PCM), avec des objets comme ProductSellingModel, ProductAttributeDefinition, ProductRelatedComponent ou AttributeBasedConfiguration. L'objectif : gérer nativement des offres complexes (produits physiques, abonnements, usage, services) sans multiplier les configurations custom.

Concrètement, cela signifie que la modélisation d'un bundle ne se fait plus uniquement via des Product Options liées à un Product2, mais via des relations de composants configurables, avec des règles d'attributs qui pilotent la disponibilité et le prix des composants en temps réel.

Les grands modules de Revenue Cloud

Revenue Cloud s'organise autour de plusieurs briques fonctionnelles qui peuvent être activées progressivement :

• Product Catalog Management : modélisation des produits, bundles, attributs et modèles de vente (one-time, subscription, usage-based).
• Pricing : price books, price rules avancées, remises multi-niveaux et pilotage par des workflows de tarification (Pricing Procedures).
• Quoting : génération de devis avec configuration guidée, comparable à CPQ mais avec un moteur de configuration renouvelé.
• Order Management : orchestration des commandes, y compris les modifications de contrat en cours de vie (amendments, renewals, cancellations).
• Billing : facturation à la demande, à l'usage ou récurrente, avec génération de factures et rapprochement.
• Revenue Lifecycle Management (RLM) : la couche qui orchestre l'ensemble du cycle, de la commande jusqu'au renouvellement.

Ce qui change concrètement pour un consultant CPQ

Plusieurs habitudes doivent être révisées. D'abord, les Product Rules et Price Rules de CPQ sont remplacées par des objets de configuration déclarative plus proches d'un moteur de règles métier : Configuration Rule, Pricing Procedure, Pricing Element. Ensuite, la notion de Selling Model devient centrale : un même produit peut être vendu selon plusieurs modèles (achat unique, abonnement mensuel, facturation à l'usage) sans dupliquer la fiche produit.

Autre changement important : Revenue Cloud s'appuie beaucoup plus sur des Flows et sur l'API Connect pour l'intégration, plutôt que sur du code Apex custom massif comme c'était souvent le cas en CPQ. Cela réduit la dette technique mais impose une montée en compétence sur les outils déclaratifs avancés et sur les API REST dédiées (par exemple /commerce/pricing ou /connect/rlm).

À retenir : Revenue Cloud n'est pas rétrocompatible avec les objets CPQ classiques. Un projet de migration nécessite une vraie remodélisation, pas une simple bascule de licence.

Quand faut-il envisager Revenue Cloud aujourd'hui

Pour un nouveau client sans historique CPQ, Salesforce pousse désormais Revenue Cloud par défaut sur les nouveaux contrats. Pour un client existant sur CPQ, la question se pose différemment : Revenue Cloud apporte une vraie valeur si l'entreprise vend des offres hybrides (produit + abonnement + usage), si elle a besoin d'une facturation plus fine, ou si elle veut consolider un empilement d'outils tiers (Zuora, Chargebee) sur un socle unique.

En revanche, si le processus de vente reste simple (catalogue stable, peu de bundles, pas de facturation récurrente complexe), rester sur CPQ classique ou migrer progressivement peut être plus pertinent à court terme, le temps que l'écosystème d'outils tiers (AppExchange, intégrations ERP) rattrape sa compatibilité avec le nouveau modèle de données.

Points de vigilance pour démarrer un projet

1. Auditer les licences disponibles : Revenue Cloud regroupe plusieurs SKU (Foundations, Advanced) qui ne débloquent pas les mêmes fonctionnalités.
2. Cartographier les modèles de vente cibles avant de modéliser le catalogue produits.
3. Prévoir un chantier dédié sur la gouvernance des Pricing Procedures, souvent sous-estimé.
4. Vérifier la compatibilité des intégrations existantes (ERP, plateformes de paiement) avec les nouvelles API RLM.

Dans les prochains articles de cette série, nous détaillerons chaque brique — catalogue, tarification, devis, facturation — avec des exemples de configuration concrets.