Migrer un CPQ vers le SaaS, sans recopier la dette de règles

Migrer un configurateur ou un CPQ vers le SaaS, c'est l'occasion de re-décrire proprement les règles de l'offre et du prix, pas de recopier dans le nouvel outil les contournements accumulés dans l'ancien. Le choix qui compte n'est pas l'outil de destination, c'est ce que vous migrez.

Pourquoi la fin de commercialisation de Salesforce CPQ rend le sujet urgent

Salesforce CPQ est en fin de commercialisation depuis mars 2025. Les organisations concernées ne font pas un simple changement de version, elles font une réimplémentation, décrite par les intégrateurs comme une refonte plutôt qu'un upgrade. Ce moment force une question qu'on repousse souvent depuis des années : nos règles de configuration et de prix sont-elles décrites quelque part, ou vivent-elles seulement dans l'outil qu'on quitte ?

Recopier ou re-modéliser, la vraie décision

Deux trajectoires s'offrent à vous. Recopier, c'est transposer dans le nouvel outil les règles telles qu'elles fonctionnaient, contournements compris, et hériter de la même dette, en plus récente. Re-modéliser, c'est profiter de la bascule pour décrire explicitement ce qu'est un produit valide, une option interdite, un prix qui se construit, avant de paramétrer quoi que ce soit. La première voie est plus rapide à lancer et plus lente à vivre. La seconde demande un audit en amont et rend l'outil de destination presque secondaire.

À quoi reconnaît-on une migration qui va recopier la dette ?

Quelques signes reviennent toujours : personne ne sait dire, hors de l'outil actuel, pourquoi telle combinaison est interdite ; les règles de prix vivent dans des tableurs et quelques têtes ; chaque exception a été codée dans un coin, sans trace de la raison métier ; et le cahier des charges de migration décrit des écrans à reproduire, pas des règles à réécrire. Quand c'est le cas, la migration transporte le problème au lieu de le résoudre.

Quels sont les risques d'une migration au fil de l'eau ?

Trois principalement. Des devis faux et des configurations impossibles qui n'apparaissent qu'une fois en production. Une dépendance durable à ceux qui connaissent l'ancien outil de mémoire, alors que le but était de s'en affranchir. Et un projet qui déborde, parce qu'on découvre les vraies règles pendant le paramétrage plutôt qu'avant, au moment où corriger coûte le plus cher.

Comment se déroule l'accompagnement ?

D'abord un audit de la dette de règles, pour faire émerger l'implicite, les contournements et les exceptions jamais décrits. Ensuite la re-modélisation, formaliser les règles de produit, de prix et de fabrication indépendamment de l'outil qui les exécutera, puis les tester jusqu'à ce que le modèle refuse exactement ce que le métier refuserait. Enfin la stratégie de recette et de bascule, multi-sites si besoin, pour migrer sans casser l'existant. Toujours en posture de pair avec vos équipes, jamais en rupture.

Qu'obtenez-vous concrètement ?

Un état des lieux de la dette de règles et des vrais sujets, avant tout choix d'outil. Des règles formalisées, testées et transmissibles, qui ne dépendent plus d'une seule personne. Et une bascule qui préserve la production et que vos équipes adoptent, parce qu'elles ont participé à décrire ce qu'elles connaissent.

Le vécu qui fonde la méthode

Vingt-cinq ans côté client, sur la lignée Cameleon, PROS Smart CPQ, aujourd'hui Conga Smart CPQ. La migration de référence : un configurateur on-premise basculé vers PROS Cloud SaaS, front web livré en avance de phase de l'éditeur, pour plus de 2 000 points de vente et 7 enseignes. La même méthode se transpose aux autres migrations du marché, dont la sortie de Salesforce CPQ. Le parcours complet.

Questions fréquentes

Faut-il tout re-modéliser, ou peut-on reprendre l'existant ?

On reprend ce qui est déjà décrit proprement et on re-modélise ce qui ne l'est pas. L'audit amont sépare les deux. L'objectif n'est pas de tout refaire, c'est de ne pas recopier ce qui était déjà faux.

Vers quel outil faut-il migrer ?

C'est la question qui vient en dernier, pas en premier. Je ne vends aucun outil et n'en désigne aucun par défaut. Le choix de destination se décide une fois les règles décrites, en fonction de votre contexte. Ce que vous migrez compte plus que là où vous migrez.

Combien de temps prend une migration de CPQ ?

Cela dépend de la dette de règles, pas du nombre d'écrans. Un audit et un cadrage se mènent en quelques semaines, la re-modélisation en plusieurs mois. L'effort de description est réutilisable, quel que soit l'outil de destination.

Peut-on migrer sans casser la production ?

Oui, c'est le cœur de la stratégie de recette et de bascule : on teste les règles réécrites contre la réalité avant de basculer, site par site si nécessaire.

Au fond, migrer, c'est re-modéliser les règles métier. Pas encore sûr de la trajectoire ? Commencez par un audit. Sinon, les interventions ou parler de votre contexte.