Les architectures composables : de CPQ à C-P-Q

Depuis quelque temps, l’un des sujets les plus en vogue chez les éditeurs CPQ (mis à part, bien sûr, l’IA) est l’émergence des architectures composables. Dans une évolution continue du marché, cette nouvelle approche fait son petit bout de chemin, accentuée par le nouveau sigle en vogue : le RLM.

Qu’est-ce qu’une architecture composable ? En quoi consiste ce modèle dans les processus de vente ? Et quel est son impact sur les systèmes de vente ? C’est ce que nous allons voir dans cet article.

Qu’est-ce qu’une architecture composable ?

En informatique, une architecture composable est une approche de conception logicielle qui définit des systèmes conçus de manière modulaire. Chaque composant est conçu, développé, déployé et maintenu de façon autonome, interchangeable, réutilisable et indépendante. Cette philosophie vise à apporter une grande flexibilité dans la façon dont les solutions s’intègrent et évoluent. Elle permet donc de mieux répondre aux changements de besoins métier, de faire évoluer les capacités du système rapidement, de faciliter la maintenance technique et d’accélérer l’innovation fonctionnelle. On retrouve cette approche dans les logiques API-first, les microservices et les architectures dites « headless ».

Comment cela s’applique dans les systèmes de vente ?

Si vous avez lu mon précédent article « Est-ce que le CPQ est mort ? », vous avez certainement compris que le RLM est la nouvelle norme (du moins on essaie) dans la gestion du processus de vente complexe allant de la sélection de produit, jusqu’à la facturation dans un processus cyclique, et que d’une certaine manière c’est le nouveau Quote To Cash. Mais contrairement à ce dernier, le RLM se distingue par l’hyper-spécialisation de ses briques fonctionnelles. Au lieu d’un bloc unique de type CPQ dans le processus QTC, on retrouve aujourd’hui des briques indépendantes, chacune spécialisée dans son domaine : configurateur de produit, moteur de Pricing, et un générateur de documents dans le processus RLM.

Plusieurs éditeurs sont passés d’une brique CPQ monolithique qui s’inscrit dans un processus Quote To Cash vers plusieurs briques distinctes (Configuration Engine, Pricing Engine, Document Generation, Rebates, Billing, Rev Rec…) composant le processus RLM. Je pense par exemple à PROS qui a entrepris cela dès 2019 et continue de le faire avec l’ajout récent d’une brique Rebates, faisant donc la promotion d’une plateforme complète avec plusieurs applications indépendantes, afin que les clients puissent se servir selon leurs besoins. Pourquoi ? Pour s’adapter à la maturité du marché.

La « vraie » réalité du marché

Pendant des années, l’architecture classique des systèmes de vente reposait sur trois blocs : un front-office (porté souvent par un CRM), un back-office (géré par un ERP), et entre les deux, un middle-office assuré par un CPQ et/ou un CLM, avec les commerciaux comme acteurs principaux du processus. Je grossis un peu le trait, mais l’idée est là.

Ce modèle a longtemps fonctionné, mais il ne reflète plus la complexité actuelle des processus de vente. Aujourd’hui, le cycle de vente implique bien plus que les seuls commerciaux : les pricing managers, les juristes, les responsables financiers, la comptabilité, les product managers et parfois même les bureaux d’études techniques participent à la construction d’une offre commerciale. Avoir tout ce monde sur un seul outil qui n’adresse pas les besoins spécifiques de chaque population devient un frein à la performance. Les entreprises attendent donc des systèmes capables de leur permettre de visualiser en temps réel l’impact d’une remise sur la marge, de générer et contractualiser instantanément avec le client, d’automatiser les flux de facturation, mais aussi de préparer proactivement les renouvellements ou revalorisations de contrat, tout en adressant les besoins des différents utilisateurs de manière unique. Le RLM, dans sa version composable, permet justement d’orchestrer ces différents besoins grâce à un assemblage de briques fonctionnelles spécialisées.

Pourquoi l’approche composable des éditeurs n’est pas bonne

Le RLM permet donc aux éditeurs de dire aux clients que le portefeuille de solutions indépendantes leur permet de combler les pratiques qui manquent. Ironiquement, tous les grands éditeurs CPQ qui promeuvent le plus l’approche composable sont aussi ceux qui imposent le plus facilement leur suite tout-en-un. Une vraie architecture composable devrait permettre de mêler les briques de plusieurs éditeurs, selon une logique ouverte.

J’ai en tête l’exemple d’un IT Manager travaillant chez un grand industriel ayant mis en place une architecture avec Oracle CPQ Cloud pour la configuration, PriceFx pour le Pricing, DocuSign pour la génération de documents, le tout dans un CRM Salesforce. Ce n’était pas un patchwork bricolé, mais une stratégie « Best of Breed » assumée. Pour moi c’est un exemple parfait de l’approche composable, cela témoigne d’une vraie maturité. Toutefois, peu d’entreprises ont les moyens humains et financiers d’aborder leur transformation sous cet angle. Créer une solution sur-mesure, comme on assemblerait un camion Lego sans notice, peut rapidement devenir un cauchemar, annulant les avantages de l’approche composable en termes de coûts et de rapidité.

Les éditeurs devraient donc promouvoir l’intégration des différentes solutions composant le RLM dans des systèmes déjà en place, car je vois mal une entreprise ayant investi dans des systèmes existants tout remplacer pour adopter un système composable d’un même éditeur. Cela n’a pas beaucoup de sens. Les éditeurs qui poussent vers une approche API-First (et pas uniquement en périphérie du processus RLM) peuvent aussi avoir un vrai avantage.

Mon avis pour conclure

Quand un système fonctionne, le faire évoluer vers une architecture composable n’a de sens que s’il s’inscrit dans une vision claire de vos processus de vente. Prenons un exemple concret : une entreprise pourrait très bien utiliser Logik.io pour la configuration produit, Zilliant pour la tarification, la gestion des devis et contrats avec Conga, et Zuora pour la facturation, l’ensemble reposant sur Salesforce comme socle CRM. Mais encore une fois, ce ne sont pas les solutions qui doivent guider votre stratégie, c’est votre propre vision de l’efficacité commerciale. Les éditeurs doivent être des facilitateurs, en proposant des modules interopérables et pensés API-first. Lorsque l’équilibre est trouvé entre spécialisation fonctionnelle et cohérence globale, alors oui, vous avez réussi.


Merci d’avoir lu. Si les sujets sur le CPQ et le Quote To Cash vous intéressent, n’hésitez pas à partager, ou à venir en discuter avec moi. J’essaie de garder un rythme régulier, mais mes engagements pour la gestion de Ben Consulting Services et mon engagement personnel dans les projets de nos clients rendent la tâche difficile. Vos encouragements sont une force supplémentaire.

Omar Bendada
Omar est le directeur général de Ben Consulting Services et spécialiste des solutions PROS Smart CPQ et Salesforce CPQ. Pendant plus de neuf ans, il a occupé plusieurs rôles qui lui ont permis de couvrir toutes les phases d’implémentation d’un projet CPQ, dans les secteurs des Télécommunications de la Distribution et de l’Industrie. Aider les entreprises à réaliser tout le potentiel de leurs projets CPQ est ce qui le motive au quotidien. Il en a fait la mission de Ben Consulting Services.

Share This

Copy Link to Clipboard

Copy