Réversibilité : 

que récupérez-vous si vous changez de solution de pricing ?

La question qu'on ne pose jamais avant de signer

Dans une consultation de solution de pricing, la grille d'évaluation couvre les fonctionnalités, la qualité du modèle, les références clientes, le coût, les délais d'intégration et le support. La sortie n'y figure presque jamais, et quand elle y figure, elle se résume à une ligne sur la restitution des données.

Cette ligne ne couvre qu'une fraction du problème. Vos données brutes vous appartiennent, c'est entendu, et aucun éditeur sérieux ne les retiendra. Mais vos données brutes, vous les aviez déjà avant de signer. Ce que vous avez construit pendant trois ans d'usage, c'est autre chose, et c'est précisément ce que les contrats ne décrivent pas.

Pourquoi le moment compte autant

Avant la signature, vous avez un pouvoir de négociation maximal et un coût de renoncement nul. Après la mise en production, vous avez des équipes formées, des processus calés, des interfaces construites et une dépendance opérationnelle réelle. La même demande n'a pas du tout le même poids aux deux moments.

Il faut ajouter que poser ces questions en amont n'est pas un signe de défiance, et qu'un bon éditeur le comprend ainsi. Un fournisseur qui répond précisément sur sa réversibilité affiche une confiance dans sa valeur ; un fournisseur qui élude indique qu'une partie de sa fidélisation repose sur la difficulté de partir.

Les quatre actifs que vous constituez chez votre éditeur

1. Les données brutes

Ventes, prix pratiqués, stocks, relevés. C'est le seul actif généralement couvert par les contrats, et c'est aussi le moins critique : il provient de vos propres systèmes, vous pouvez le reconstituer. La seule vraie question porte sur le format et le délai de restitution, et elle rejoint celle des interfaces, traitée dans intégrer ses données pricing sans chantier IT lourd.

2. Le parc de règles

Plusieurs centaines de règles écrites au fil des années, avec leurs priorités, leurs exceptions et leurs périmètres. Cet actif représente un travail considérable, comme le montre notre article sur la dette de règles d'un moteur de pricing, et il est très rarement exportable dans une forme réutilisable. Un export en format propriétaire, ou une liste de paramètres sans leur logique d'articulation, ne vaut pas grand-chose ailleurs.

3. L'historique des arbitrages

C'est l'actif le plus précieux et le plus systématiquement oublié. Chaque recommandation acceptée, modifiée ou rejetée, avec son motif, constitue la mémoire des décisions de l'entreprise. C'est ce qui permet à un nouveau système d'apprendre vite, et c'est ce qui permet surtout à vos équipes de ne pas réinventer trois ans de pratique. Il figure rarement dans une clause.

4. L'appariement concurrentiel

La table qui dit que votre référence correspond à telle référence chez tel concurrent. Elle s'est construite par itérations, corrections manuelles et validations successives. La reconstituer demande des mois. Elle est souvent considérée comme un élément du savoir-faire de l'éditeur plutôt que comme une donnée du client, et c'est le point de friction contractuel le plus fréquent.

L'écart entre la confiance et la réalité d'une migration

L'enseignement de ces chiffres n'est pas que les migrations sont impossibles. C'est que l'estimation qu'en font les décideurs avant de les vivre est systématiquement optimiste, dans des proportions qui invalident la planification.

Trois raisons expliquent l'écart, et elles valent pleinement pour le pricing.

• L'export existe mais n'est pas exploitable. Un fichier de plusieurs centaines de milliers de lignes sans documentation de structure est techniquement une restitution et pratiquement un problème.
• La connaissance implicite ne s'exporte pas. Les raisons derrière les paramètres, les contournements connus des utilisateurs, les cas particuliers traités hors système : rien de cela n'est dans la base.
• La bascule n'est pas instantanée. Il faut faire tourner deux systèmes en parallèle le temps de valider, ce qui suppose que l'ancien contrat le permette, et que le planning l'ait prévu. C'est la même contrainte que sur une migration depuis Excel vers une plateforme de pricing.

Les sept clauses à exiger dans le contrat

Voici ce qui se négocie utilement, formulé de façon à pouvoir être repris tel quel dans une consultation.

• Le périmètre exact de la restitution. Lister nommément les quatre actifs ci-dessus. Une formule générale du type « les données du client lui sont restituées » sera interprétée au sens le plus étroit le jour venu.
• Le format, documenté et ouvert. Exiger un format lisible sans l'outil, accompagné de sa documentation de structure. C'est la clause qui fait la différence entre un export et une restitution utilisable.
• Le délai, chiffré. Un nombre de jours ouvrés à compter de la demande, pas une obligation de moyens. Et la possibilité de demander une restitution en cours de contrat, pas seulement à son terme.
• L'absence de surcoût. La restitution ne doit pas être facturée comme une prestation spécifique, sous peine de devenir un droit théorique.
• La période de fonctionnement en parallèle. Le droit de maintenir l'accès à l'ancien système pendant la bascule, typiquement trois à six mois, avec les conditions tarifaires associées fixées dès l'origine.
• La propriété de l'appariement. Énoncer explicitement que la table de correspondance entre vos références et celles des concurrents est une donnée du client. C'est le point qui demandera le plus de discussion, et c'est celui qui coûtera le plus cher à reconstruire.
• Le sort des données en cas de cessation. Que se passe-t-il si l'éditeur est racheté, change d'offre ou cesse son activité ? La clause de continuité est rarement demandée et presque toujours accordée quand elle l'est.

Ce qu'il ne sert à rien d'exiger

Les modèles eux-mêmes. Les algorithmes entraînés constituent le cœur de la propriété intellectuelle de l'éditeur, et leur restitution ne sera jamais accordée. Ce n'est d'ailleurs pas un manque : un modèle se réentraîne à partir de vos données, alors qu'un parc de règles et un appariement ne se reconstituent qu'à la main. C'est la raison pour laquelle le contexte formalisé compte davantage que le modèle, point que nous développons dans le contexte métier n'est pas de la donnée.

Tester sa réversibilité sans attendre d'en avoir besoin

Une clause non testée est une hypothèse. La pratique qui donne le plus de résultats consiste à demander une restitution complète une fois par an, sans intention de partir, simplement pour vérifier trois choses : que le délai annoncé est tenu, que le format reçu est lisible par vos propres équipes, et que le périmètre livré correspond à ce que le contrat décrit.

Cette demande annuelle a un second effet, plus politique : elle entretient une relation fournisseur équilibrée. Un client dont on sait qu'il peut partir est un client avec lequel on négocie autrement, et cela se ressent dans la qualité du support bien avant d'en arriver à une rupture.

Et si le contrat est déjà signé ?

Trois actions restent possibles. Demander une restitution d'essai, même sans clause : le refus est en lui-même une information. Documenter en interne ce qui n'est pas exportable, en particulier les raisons derrière les règles, ce qui constitue une réversibilité de fait. Et inscrire les clauses manquantes au prochain renouvellement, qui est le seul moment où le rapport de force redevient favorable.

Si la décision de changer est déjà prise, le sujet n'est plus contractuel mais opérationnel, et nous le traitons séparément dans changer d'outil de pricing sans reproduire ses erreurs.

Un dernier mot sur l'intention. Négocier sa réversibilité n'est pas préparer un départ, pas plus que souscrire une assurance n'est prévoir un sinistre. C'est la condition pour que la relation repose sur la valeur délivrée plutôt que sur le coût de la quitter. Les deux parties y gagnent : un éditeur qui retient ses clients par leur satisfaction construit une activité plus solide que celui qui les retient par leurs données.

FAQ