Changer d'outil de pricingsans reproduire ses erreurs
September 4, 2026
Un premier outil sous-exploité contient une information précieuse — les causes précises de l'échec d'adoption, à diagnostiquer avant de changer — et le CHAOS Report du Standish Group rappelle que seuls 31 % des projets IT aboutissent pleinement, 50 % sont livrés avec compromis et 19 % échouent totalement. La reprise des données existantes (historique, catalogue, règles) doit être un critère explicite du cahier des charges, pas une option.
Un premier outil de pricing jamais pleinement paramétré ni réellement adopté n'est pas un cas isolé, c'est un scénario qui revient régulièrement dans la distribution spécialisée. Le contrat arrive à échéance et il faut choisir un nouveau partenaire, avec une volonté explicite : ne pas revivre le même échec.
Ce guide détaille ce qu'il faut diagnostiquer avant de relancer un appel d'offres, comment reprendre ce qui existe déjà plutôt que repartir de zéro, et pourquoi le calendrier du changement compte autant que le choix du prestataire.
Un premier outil sous-exploité n'est pas une fatalité
Le scénario est familier dans la distribution spécialisée : un outil de pricing déployé il y a plusieurs années, jamais pleinement paramétré, jamais réellement adopté par les équipes. Le contrat arrive à échéance, et la tentation est grande de traiter le renouvellement comme un simple exercice comparatif de fonctionnalités et de tarifs, le même réflexe, parfois, qui avait présidé au premier choix.
C'est une occasion manquée. Un premier échec de déploiement contient une information précieuse : les causes précises pour lesquelles l'adoption n'a pas eu lieu. Ignorer ce diagnostic pour se concentrer sur le nouveau logiciel revient à changer de véhicule sans avoir compris pourquoi le premier n'a jamais quitté le garage.
Pourquoi les projets de migration logicielle échouent si souvent
31 % / 50 % / 19 % — répartition des projets informatiques selon le Standish Group CHAOS Report (édition 2020, référence du secteur depuis 1994) : 31 % aboutissent pleinement dans les délais et le budget prévus, 50 % sont « challenged » (dépassement de délai, budget ou périmètre), 19 % échouent complètement.
Ce chiffre concerne l'ensemble des projets IT, pas seulement le pricing, mais il éclaire un point essentiel : la moitié des projets qui « réussissent » au sens strict le font avec des compromis significatifs sur le périmètre ou l'usage réel. Un outil livré et jamais pleinement paramétré entre typiquement dans cette zone grise.
30 % des responsables de projets de changement citent la résistance des collaborateurs comme le premier obstacle à la réussite d'un projet, devant le manque de sponsor ou de budget, selon Prosci, cabinet de référence en conduite du changement (recherche continue depuis 1998).
Autrement dit : dans une part significative des échecs de déploiement, le logiciel n'est pas en cause. Le problème se situe dans la conduite du projet, formation, accompagnement, adhésion des équipes qui devront s'en servir au quotidien.
Le vrai diagnostic avant de changer : outil ou adoption ?
| Symptôme observé | Probable cause | Implication |
|---|---|---|
| Peu d'utilisateurs actifs | Formation insuffisante, absences côté équipe projet au lancement | Conduite du projet |
| Paramétrage resté incomplet | Donnée insuffisante pour aller au bout du paramétrage prévu | Fiabilisation de la donnée |
| Fonctionnalité manquante confirmée | Limite réelle du logiciel malgré un usage complet et une donnée propre | Changement d'outil justifié |
| Lancement pendant une période chargée | Chantier démarré en même temps qu'un autre pic opérationnel | Timing du projet |
À lire ainsi : seule la troisième ligne justifie à elle seule un changement d'outil. Les trois autres concernent la manière dont le projet a été mené, et se répéteront avec un nouveau logiciel si elles ne sont pas traitées explicitement.
Reprendre l'existant plutôt que repartir de zéro
Changer d'outil ne signifie pas nécessairement repartir de rien. L'historique de prix, le catalogue produit déjà constitué, les règles métier déjà réfléchies avec le premier prestataire, même imparfaitement exploitées, représentent un capital de connaissance du métier qui mérite d'être repris plutôt que reconstruit.
Un critère souvent sous-estimé dans un cahier des charges de migration : la capacité du nouveau prestataire à relancer rapidement un environnement exploitable à partir de ce qui existe déjà, plutôt que d'imposer un nouveau projet de collecte de données depuis zéro.
Le cahier des charges qui évite les pièges du premier projet
1. Exiger un diagnostic de données avant le paramétrage. Le prestataire doit être capable de dire, avant de signer, ce qui est exploitable tel quel et ce qui doit être fiabilisé.
2. Prioriser l'ergonomie pour les profils non-experts. Un outil réservé à quelques experts internes reproduit la dépendance et la fragilité du système précédent.
3. Prévoir la reprise des données existantes comme critère explicite. Historique de prix, catalogue, règles déjà définies, un critère de sélection à part entière.
4. Caler la conduite du changement sur le calendrier réel de l'entreprise. Formation, accompagnement et démarrage doivent être planifiés en dehors des pics opérationnels.
Le calendrier : pourquoi le timing compte autant que le choix
Bonne pratique — un des facteurs qui explique le plus souvent l'abandon d'un projet en cours de route est le mauvais calage calendaire : lancer un chantier de migration en pleine période de mises à jour tarifaires annuelles, en pic saisonnier ou en même temps qu'un autre projet IT majeur multiplie le risque de voir le paramétrage repoussé, puis abandonné.
Un calendrier réaliste sépare clairement trois temps : le choix du prestataire, la fiabilisation de la donnée et la formation des équipes en amont, puis le démarrage effectif du paramétrage une fois la période de forte charge opérationnelle passée.
Les erreurs qui font échouer une seconde tentative
- Choisir sur la seule logique budgétaire. Un prix attractif ne compense pas un projet mal accompagné.
- Ne pas associer les futurs utilisateurs au choix. Un outil sélectionné uniquement par la direction reproduit le déficit d'adhésion qui a probablement contribué au premier échec.
- Sous-estimer la reprise de données. Repartir de zéro sur le catalogue et l'historique alourdit le projet.
- Lancer le paramétrage au pire moment du calendrier métier. Même un excellent outil mal calé dans le temps hérite du même sort que le précédent.
Frequently Asked Questions
Posez le diagnostic avant de trancher : si l'outil n'a jamais été pleinement paramétré ou si l'équipe ne l'utilise pas faute de formation, le problème est souvent la conduite du projet, pas le logiciel. Seule une limite fonctionnelle réelle, constatée malgré un usage complet et une donnée propre, justifie à elle seule un changement d'outil — les autres causes courantes se répéteront avec un nouveau logiciel si elles ne sont pas traitées explicitement.
Dans la majorité des cas oui, au moins partiellement : historique de prix, catalogue produit, règles métier déjà définies peuvent être repris pour éviter de repartir de zéro. Un critère souvent sous-estimé dans un cahier des charges de migration : la capacité du nouveau prestataire à relancer rapidement un environnement exploitable à partir de l'existant, plutôt que d'imposer une nouvelle collecte de données depuis zéro.
Pendant une période de forte charge opérationnelle, mises à jour tarifaires annuelles, pic saisonnier, autre chantier IT majeur en cours. Un calendrier réaliste sépare clairement trois temps : le choix du prestataire, la fiabilisation de la donnée et la formation des équipes en amont, puis le démarrage effectif du paramétrage une fois la période de forte charge passée.
Il n'existe pas de délai universel : diagnostic des causes du premier échec, fiabilisation de la donnée, formation des équipes et démarrage hors période de forte charge sont des étapes qui ne se compriment pas. Ce qui accélère réellement le projet, c'est de reprendre l'historique de prix, le catalogue et les règles métier déjà réfléchies avec le premier prestataire plutôt que de tout reconstruire depuis zéro.
Au minimum les équipes qui utiliseront l'outil au quotidien, pas seulement la direction qui signe le contrat. Un outil sélectionné uniquement par la direction reproduit souvent le déficit d'adhésion qui a contribué au premier échec — associer les futurs utilisateurs au choix est l'un des meilleurs prédicteurs d'une adoption réussie la seconde fois.
À lire aussi dans ce dossier : Avant de déployer un outil de pricing, fiabilisez votre donnée · Intégrer ses données pricing sans chantier IT lourd · Pricing, achats, category management : sortir des fichiers séparés.
Un outil de pricing exécute fidèlement la donnée qu'on lui fournit — la qualité du résultat dépend d'abord de la qualité de la donnée en amont. Trois chantiers sont prioritaires avant tout paramétrage : un référentiel produit sans doublon, des prix et coûts synchronisés, un historique de vente continu. Inutile d'attendre une donnée parfaite pour démarrer : un point d'entrée par fichiers permet de fiabiliser progressivement.
Un premier outil sous-exploité contient une information précieuse — les causes précises de l'échec d'adoption, à diagnostiquer avant de changer — et le CHAOS Report du Standish Group rappelle que seuls 31 % des projets IT aboutissent pleinement, 50 % sont livrés avec compromis et 19 % échouent totalement. La reprise des données existantes (historique, catalogue, règles) doit être un critère explicite du cahier des charges, pas une option.
La majorité des projets de pricing démarrent par un simple import de fichiers déjà exportables, pas par une intégration API — trois niveaux d'intégration existent (import de fichiers, connecteur planifié, intégration API temps réel), et l'absence de connecteur ne doit jamais être un motif pour reporter un projet de pricing.