Logiciel CPQ : définition, fonctionnement et choix

Qu’est-ce qu’un logiciel CPQ ?

CPQ signifie Configure, Price, Quote : configurer, tarifer et produire un devis.

Le principe est simple :

• Configure : déterminer ce qui peut être vendu ensemble et selon quelles conditions ;

• Price : calculer le prix à partir des tarifs, volumes, options, remises ou autres règles ;

• Quote : générer une proposition cohérente à partir de cette configuration.

La différence avec un simple générateur de devis est importante.

Produire un PDF à partir des informations d’une opportunité est relativement facile. La difficulté apparaît lorsque le système doit d’abord déterminer ce que le commercial peut vendre et à quel prix.

Prenons une société de services qui commercialise trois niveaux d’accompagnement.

Si chaque offre possède un tarif fixe et quelques options, un CRM avec un modèle de devis peut largement suffire.

Si le prix dépend du nombre de sites, du volume traité, des options retenues, de la durée d’engagement et d’une remise soumise à validation, le devis devient le résultat d’un ensemble de règles.

C’est cette logique qu’un CPQ structure.

Quel problème un CPQ résout-il vraiment ?

Un CPQ ne sert pas principalement à faire de plus beaux devis.

Il sert à fiabiliser la manière dont l’offre est construite avant que le devis soit généré.

Dans beaucoup d’entreprises, cette logique est progressivement dispersée :

• grille tarifaire dans Excel ;

• informations commerciales dans le CRM ;

• règles de remise dans un document ;

• validations demandées par email ou Slack ;

• exceptions connues uniquement de quelques personnes.

Ce fonctionnement peut être parfaitement acceptable tant que le volume et la complexité restent faibles.

Le problème apparaît lorsque les exceptions deviennent la norme.

Un commercial applique un ancien tarif. Une option obligatoire est oubliée. Une remise dépasse le seuil autorisé. Deux services incompatibles apparaissent dans le même devis.

À ce stade, le problème n’est plus documentaire.

C’est devenu un problème de système commercial.

La complexité du devis n’est pas le bon critère

Un devis de dix pages peut être très simple à produire s’il repose sur des tarifs fixes.

À l’inverse, une proposition d’une page peut nécessiter :

• plusieurs règles de compatibilité ;

• un calcul selon le volume ;

• une remise conditionnelle ;

• une marge minimale ;

• une validation du manager.

C’est cette complexité de décision qu’un CPQ cherche à absorber.

CRM, automatisations ou CPQ : de quoi avez-vous réellement besoin ?

Toutes les entreprises qui produisent des devis n’ont pas besoin d’un CPQ.

Le bon niveau d’architecture dépend surtout de la complexité que le système doit réellement gérer.

CRM + modèle de devis

C’est souvent le meilleur point de départ.

Le CRM contient l’entreprise, les contacts, l’opportunité et les informations commerciales nécessaires.

À partir de ces données, le système génère le devis.

Une agence qui vend un audit à prix fixe, un accompagnement mensuel et quelques options clairement tarifées n’a probablement aucune raison d’ajouter un CPQ.

La simplicité est ici un avantage.

CRM + automatisations

Quelques règles supplémentaires ne justifient pas automatiquement un nouveau logiciel.

Par exemple :

• tarif dégressif à partir d’un certain volume ;

• frais supplémentaires selon une option ;

• remise maximale selon le rôle du commercial ;

• validation nécessaire au-delà d’un seuil.

Si ces règles restent peu nombreuses et faciles à tester, elles peuvent parfois être gérées directement autour du CRM.

CRM + outil de chiffrage métier

Il existe ensuite une zone intermédiaire.

Le CRM reste responsable de la relation commerciale et du pipeline, tandis qu’un outil dédié calcule le chiffrage.

Pour une société de services, le prix peut par exemple dépendre :

• du nombre de jours estimés ;

• des profils mobilisés ;

• des coûts externes ;

• de la marge cible ;

• des options de delivery.

Une base Airtable ou une petite application interne peut parfois très bien absorber cette logique.

Mais seulement tant que le système reste compréhensible et maintenable.

CRM + CPQ

Le CPQ devient intéressant lorsque les règles constituent elles-mêmes un véritable système.

Le commercial ne devrait alors plus avoir à mémoriser toutes les dépendances, vérifier manuellement les combinaisons ou recalculer le prix.

Le CPQ porte cette logique.

La nouvelle couche technologique absorbe donc une complexité déjà présente dans le métier.

Ajouter un CPQ pour gérer cinq règles simples crée probablement de la complexité. Ajouter un CPQ pour centraliser une logique devenue difficile à maintenir peut au contraire en supprimer.

Quels signes montrent qu’un CPQ devient nécessaire ?

Il n’existe pas de nombre de produits, de commerciaux ou de devis à partir duquel un CPQ devient obligatoire.

Certains signaux sont néanmoins révélateurs.

Les offres comportent de nombreuses dépendances

Certaines options nécessitent d’autres composants.

D’autres sont incompatibles.

La configuration dépend parfois du segment, du contrat ou du contexte client.

Si le commercial doit connaître toutes ces règles par cœur, le système devient fragile.

Le prix dépend de nombreuses variables

Le tarif ne correspond plus simplement à :

quantité × prix unitaire

Il dépend par exemple du volume, de la durée, de différents paliers, de bundles, d’options ou du niveau de service.

Le problème apparaît surtout lorsque ces règles interagissent entre elles.

Les remises et exceptions nécessitent des validations

Une remise ponctuelle est facile à gérer.

Plusieurs niveaux de remise selon la marge, le produit, le montant du contrat ou le rôle du commercial le sont beaucoup moins.

Le système doit alors distinguer ce qui peut être approuvé automatiquement de ce qui constitue une véritable exception.

La connaissance du pricing dépend de quelques personnes

Si produire une proposition complexe nécessite toujours l’intervention de la personne qui « connaît toutes les règles », l’entreprise possède déjà une logique de configuration et de pricing.

Elle n’est simplement pas encore formalisée dans un système.

Les erreurs ont un impact financier réel

Lorsque les contrats deviennent importants, une mauvaise configuration ou un mauvais prix peut coûter davantage que le temps nécessaire à produire le devis.

La fiabilité du processus devient alors un critère d’architecture à part entière.

Comment un CPQ s’intègre-t-il dans votre architecture commerciale ?

Un CPQ ne remplace généralement pas le CRM.

Les deux ont des responsabilités différentes.

Une architecture simplifiée peut ressembler à :

CRM → CPQ → devis / signature → contrat → facturation

Le CRM porte notamment :

• l’entreprise ;

• les contacts ;

• l’opportunité ;

• le pipeline ;

• le contexte commercial.

Le CPQ porte :

• le catalogue ;

• les configurations autorisées ;

• les règles tarifaires ;

• les remises ;

• les approbations ;

• l’offre finale.

Une fois l’offre acceptée, d’autres systèmes peuvent prendre le relais.

C’est là que le CPQ rejoint le processus plus large de Quote-to-Cash.

Le Quote-to-Cash couvre le passage de l’offre commerciale jusqu’à l’encaissement : devis, contrat, delivery éventuel, facturation et paiement.

Le CPQ n’en représente qu’une partie.

Définir quelle donnée fait foi

L’ajout d’un CPQ pose rapidement une question plus importante que l’intégration elle-même :

quel système est responsable de quelle donnée ?

Par exemple :

• CRM → opportunité ;

• CPQ → configuration et prix validés ;

• signature → contrat signé ;

• outil métier → réalisé ou facturable ;

• outil de facturation → facture et paiement.

Chercher à recopier toutes les données dans tous les outils rend rarement le système plus fiable.

Il vaut mieux identifier les informations réellement nécessaires à chaque étape et limiter les synchronisations à celles qui servent une décision ou une action.

C’est aussi l’un des principes d’une architecture RevOps maintenable.

Peut-on construire son CPQ dans Airtable ou directement dans son CRM ?

Oui, parfois.

Mais la bonne question n’est pas :

« Est-ce techniquement possible ? »

C’est plutôt :

« Est-ce encore l’architecture la plus simple à comprendre, tester et maintenir ? »

Quand une solution légère reste pertinente

Airtable peut par exemple servir d’outil de chiffrage lorsqu’une entreprise possède :

• un catalogue limité ;

• quelques variables de calcul ;

• une logique spécifique à son métier ;

• peu de niveaux d’approbation ;

• un volume encore maîtrisé.

Dans une architecture utilisant Attio, Attio peut rester le CRM tandis qu’Airtable porte cette logique de chiffrage.

Les responsabilités sont alors distinctes :

Attio → relation commerciale et opportunité

Airtable → chiffrage métier

Cette architecture n’est pas automatiquement préférable à un CPQ. Elle est simplement parfois suffisante.

Le risque du CPQ maison

Le problème apparaît lorsque les règles continuent de s’accumuler.

Une formule dépend d’une autre.

Plusieurs automatisations doivent s’exécuter dans le bon ordre.

Chaque nouvelle exception nécessite un champ ou une règle supplémentaire.

Le système fonctionne encore, mais personne n’ose le modifier sans demander à celui qui l’a construit.

Le coût n’est alors plus celui de la licence.

C’est celui de la maintenance.

Construire soi-même la logique n’est donc pas nécessairement plus simple que choisir un logiciel spécialisé.

Utiliser l’architecture la plus simple capable d’absorber correctement la complexité métier.

Pas la solution la plus sophistiquée.

Mais pas non plus la solution légère à tout prix.

Comment choisir un logiciel CPQ ?

Une fois le besoin confirmé, le choix doit partir des règles commerciales réelles plutôt que d’une liste de fonctionnalités.

Commencer par la configuration des offres

Quels produits ou services peuvent être combinés ?

Quelles options sont obligatoires ?

Quelles dépendances ou exclusions existent ?

Un moteur de configuration avancé apporte peu de valeur si le catalogue est simple.

À l’inverse, un outil trop limité déplacera simplement les exceptions ailleurs.

Tester le moteur de pricing sur vos vrais cas

Listez les mécanismes qui déterminent réellement vos prix :

• tarifs fixes ;

• volumes ;

• paliers ;

• remises ;

• bundles ;

• abonnements ;

• durées d’engagement ;

• conditions particulières.

Une démonstration basée sur vos scénarios réels est beaucoup plus utile qu’un catalogue fictif préparé par l’éditeur.

Vérifier les approbations

Toutes les propositions ne doivent pas nécessairement passer par le même circuit.

Une remise de 5 % peut être autorisée tandis qu’une remise beaucoup plus importante nécessite une validation.

Le bon système fluidifie les cas standards et remonte les vraies exceptions.

Clarifier l’intégration avec le CRM

Le commercial doit pouvoir travailler à partir de son opportunité sans ressaisir inutilement les informations déjà connues.

Il faut donc définir :

• quelles données partent du CRM ;

• quelles données reviennent du CPQ ;

• à quel moment ;

• quel système reste source de vérité.

Évaluer la maintenabilité

Qui pourra :

• ajouter une nouvelle offre ?

• modifier un tarif ?

• changer un seuil de remise ?

• tester une nouvelle règle ?

• comprendre le système dans six mois ?

Un CPQ puissant mais dépendant en permanence d’une expertise externe peut devenir plus contraignant qu’un système légèrement moins sophistiqué mais maîtrisé par l’équipe.

Regarder le coût d’implémentation, pas seulement la licence

La mise en place peut nécessiter :

• formalisation du catalogue ;

• modélisation des règles ;

• intégration CRM ;

• workflows d’approbation ;

• reprise de données ;

• tests ;

• accompagnement des utilisateurs.

C’est d’ailleurs souvent l’un des enseignements d’un projet CPQ : on ne peut pas automatiser proprement des règles commerciales qui ne sont pas encore clairement définies.

Le travail commence donc parfois avant le choix du logiciel.

Pour une définition plus centrée sur la catégorie elle-même, SAP détaille également le fonctionnement du CPQ dans sa documentation dédiée.

CPQ et Quote-to-Cash : quelle différence ?

Les deux notions sont liées, mais leur périmètre diffère.

Le CPQ répond principalement à :

Comment construire une offre valide et déterminer correctement son prix ?

Le Quote-to-Cash répond à :

Comment faire circuler cette vente du devis jusqu’à l’encaissement ?

Le CPQ peut donc être une composante du Quote-to-Cash :

Opportunité → CPQ → devis → contrat → delivery éventuel → facture → paiement

Une entreprise ayant des offres simples peut parfaitement avoir un Quote-to-Cash structuré sans CPQ.

Inversement, si un CPQ est nécessaire, son intégration avec le reste du processus doit être pensée dès le départ : le prix et la configuration validés doivent devenir des données fiables pour les étapes suivantes.

Questions fréquentes sur les logiciels CPQ