Développer son outil de pricing en interne : le coût réel d'un build
Le modèle est la partie facile. Un moteur de recommandation fonctionne en quelques mois ; ce qui prend des années, c'est le référentiel, l'appariement concurrentiel, le parc de règles, l'explicabilité et la conformité. D'après Exclaimer (2025), 71 % des développements internes finissent abandonnés, et 83 % dans les secteurs réglementés : le point de rupture n'est presque jamais la mise en service, c'est l'entretien.
Le coût caché est un coût de continuité : un outil interne repose sur deux ou trois personnes, et leur départ transforme l'actif en passif. Le build garde du sens sur un périmètre étroit et stable, en complément d'une solution plutôt qu'à sa place. Le critère de choix n'est pas la compétence de l'équipe, c'est sa capacité à tenir dix ans.
L'argument se tient parfaitement en réunion : nous avons une équipe data, nos données sont chez nous, nos règles métier sont spécifiques, et les briques techniques n'ont jamais été aussi accessibles. Construire plutôt qu'acheter paraît à la fois moins cher et plus juste. Et de fait, une équipe compétente sortira un moteur de recommandation de prix en quelques mois. Le malentendu n'est pas là. Il est sur ce qui compose réellement un système de pricing : le modèle en représente la part la plus visible et la plus petite.
Pourquoi le build paraît toujours moins cher au départ
Parce qu'au départ, il l'est réellement. Une équipe data qui dispose des historiques de vente produit en quelques semaines un modèle d'élasticité honnête, et en quelques mois une interface qui propose des prix. À ce stade, la comparaison avec un budget d'éditeur est écrasante, et l'arbitrage semble évident.
Le biais tient à ce que l'on compare : d'un côté le coût de construction d'une maquette fonctionnelle, de l'autre le prix d'un système en production. Ce ne sont pas les mêmes objets. Entre les deux, il y a tout ce qui transforme une recommandation en décision appliquée en rayon, et c'est là que se trouve la quasi-totalité de l'effort.
Le réflexe du prototype réussi
Un prototype qui fonctionne sur une catégorie crée une confiance disproportionnée. Il valide la faisabilité du calcul, ce qui n'a jamais été le point difficile. Il ne dit rien de la tenue du système sur quarante mille références, sur douze formats de magasin, avec trente utilisateurs qui ont des droits différents et des avis divergents.
C'est aussi la phase la plus gratifiante du projet, celle où les résultats arrivent vite. La suite est moins spectaculaire et beaucoup plus longue, ce qui explique une part des abandons : l'équipe passe de la construction d'un modèle à l'entretien d'un système, et ce n'est pas le même métier.
Ce qu'un système de pricing contient vraiment
Voici ce qu'il faut construire, dans l'ordre où les équipes le découvrent, c'est-à-dire rarement dans l'ordre où elles l'avaient prévu.
Le référentiel produit
Une recommandation de prix suppose de savoir ce qu'est un produit, à quelle famille il appartient, quelles références il remplace, lesquelles il concurrence en interne. Dans la plupart des enseignes, cette information existe à plusieurs endroits, sous plusieurs formes, et ne concorde pas. Fiabiliser ce socle est un chantier à part entière, que nous détaillons dans fiabiliser sa donnée avant de déployer un outil de pricing.
L'appariement concurrentiel
C'est le composant le plus systématiquement sous-estimé. Savoir que la référence du concurrent est bien la même que la vôtre, malgré un libellé différent, un conditionnement différent et une absence de code commun, est un problème difficile qui ne se résout pas par une correspondance de chaînes de caractères. Une erreur d'appariement produit un alignement sur un produit qui n'est pas le bon, et la conséquence se lit directement en marge.
Le moteur de règles et sa gouvernance
Un calcul d'optimisation ne suffit pas : il faut un parc de règles, des priorités entre elles, des exceptions, des circuits de validation, des droits par profil, une traçabilité. Et il faut la mécanique qui empêche ce parc de pourrir, sujet que nous traitons dans la dette de règles d'un moteur de pricing. C'est une application de gestion complète, pas un script, et la liste de ce qu'elle doit couvrir recoupe celle du comparatif des logiciels de pricing retail.
L'explicabilité
Un acheteur n'applique pas un prix qu'il ne peut pas défendre. Le système doit donc reconstituer, pour chaque recommandation, le chemin qui y mène : quelles données, quelle élasticité, quelle règle, quel arbitrage. Construire cette traçabilité après coup est beaucoup plus coûteux que de l'avoir prévue dès l'origine, et c'est pourtant presque toujours ce qui se passe.
La conformité
Seuil de revente à perte, encadrement des promotions et prix de référence, contraintes sectorielles : ces règles ne sont pas des options, elles évoluent, et une erreur se paie au-delà du commercial. Les intégrer est faisable ; les suivre dans la durée demande une veille que peu d'équipes internes organisent.
71 % des outils développés en interne finissent par être abandonnés, une proportion qui monte à 83 % dans l'industrie et la finance. Seuls 8 % sont livrés dans les délais prévus et 11 % dans le budget annoncé.
(Exclaimer, « Build vs buy : the true cost of DIY IT solutions », enquête auprès de plus de 2 000 décideurs informatiques et sécurité en Europe, aux États-Unis et en Asie-Pacifique, novembre 2025)
Les 5 autres volets de la série « piloter un système de pricing IA »
Ce que disent les chiffres sur les développements internes
Le chiffre le plus instructif de cette étude n'est pas le taux d'abandon, c'est l'écart entre les intentions et les livraisons : 8 % des projets livrés à l'heure, 11 % dans le budget. Cela ne signifie pas que les équipes internes sont moins compétentes. Cela signifie qu'un outil interne est évalué contre une estimation faite au moment où l'on en savait le moins, et qu'il n'a jamais la priorité face à une urgence commerciale.
Le mécanisme de l'abandon
Il suit presque toujours la même courbe. Le projet livre une première version utilisable, elle rend service, l'adoption progresse. Puis les demandes d'évolution s'accumulent plus vite que la capacité de l'équipe à les traiter, parce que cette équipe a aussi d'autres sujets. Le délai de traitement s'allonge, les utilisateurs recommencent à travailler à côté, l'usage s'érode, et la question de la maintenance finit par se poser devant un comité qui constate un usage faible.
L'abandon n'est donc pas un échec technique. C'est une conséquence du fait qu'un outil interne entre en concurrence permanente avec les autres priorités de l'équipe qui le porte.
63 % des organisations consacrent entre 10 et 50 heures par mois à la seule maintenance de leurs outils internes, et 66 % y ajoutent 20 000 à 100 000 dollars annuels d'entretien. Ces lignes figurent rarement dans le dossier d'arbitrage initial.
(Exclaimer, « Build vs buy : the true cost of DIY IT solutions », enquête auprès de plus de 2 000 décideurs informatiques et sécurité, novembre 2025)
Le coût que personne ne budgète : la continuité
Un outil de pricing développé en interne repose en pratique sur deux ou trois personnes. Elles connaissent les choix d'architecture, les cas particuliers, les raisons des exceptions. Cette connaissance est rarement écrite, parce qu'elles sont disponibles et qu'il est plus rapide de leur demander.
Le jour où elles partent, l'entreprise découvre qu'elle possède un système qu'elle ne sait plus modifier. Elle entre alors dans une phase bien identifiée : on n'y touche plus, on contourne, et on finit par rebâtir. Le coût de cette séquence n'apparaît dans aucun dossier d'arbitrage initial, et il dépasse généralement l'écart de prix qui avait motivé la décision de construire.
Les trois questions qui révèlent le risque
- Combien de personnes peuvent modifier une règle du moteur sans l'aide de son auteur ? Si la réponse est une ou deux, l'actif est fragile.
- Combien de temps faut-il à un nouvel arrivant pour être autonome dessus ? Au-delà de quelques semaines, la connaissance n'est pas dans le code, elle est dans les têtes.
- Que se passe-t-il si une obligation réglementaire change dans trois mois ? La question n'est pas de savoir si c'est faisable, mais qui le fera et à la place de quoi.
Le temps avant la valeur
Un dernier élément manque presque toujours dans la comparaison : le délai. Pendant que le build se construit, les prix continuent d'être pilotés comme avant. Si une solution permet de gagner +0,5 à +3 points de marge en quelques mois et qu'un développement interne met dix-huit mois à atteindre un niveau équivalent, le coût du retard se chiffre, et il se chiffre souvent plus haut que l'économie de licence.
Quand le build reste le bon choix
Il existe des cas où construire est la bonne décision, et il est utile de les nommer précisément plutôt que de renvoyer systématiquement vers l'achat.
- Un périmètre étroit et stable. Une mécanique tarifaire propre à votre métier, sur quelques centaines de références, qui ne bouge pas tous les trimestres : c'est un bon candidat.
- Un avantage concurrentiel réel. Si votre façon de fixer les prix est en elle-même un différenciateur que personne d'autre ne pratique, elle ne se trouvera pas sur étagère.
- En complément, pas en remplacement. Le schéma qui fonctionne le mieux associe une plateforme pour le socle, à savoir le référentiel, l'appariement, les règles, la conformité et la traçabilité, et un développement interne pour la couche spécifique qui, elle, porte votre singularité.
Le critère de décision, en une question
La bonne question n'est pas « sommes-nous capables de le construire ? ». La réponse est presque toujours oui, et elle ne prédit rien. La bonne question est : sommes-nous capables de l'entretenir pendant dix ans, avec des départs, des changements de priorité et des évolutions réglementaires ? C'est sur ce second critère que se jouent les 71 % d'abandons, et c'est lui qu'il faut instruire avant de trancher.
Enfin, une distinction utile : cet article traite du développement d'un outil par une équipe data interne. La question voisine, celle de l'usage d'une IA généraliste à la place d'une solution spécialisée, est un autre sujet, que nous traitons dans IA généraliste et solution de pricing spécialisée.
FAQ
Le coût visible est celui du modèle, et il est modeste : une équipe data compétente produit un moteur de recommandation en quelques mois. Le coût réel se trouve dans les cinq composants qui l'entourent : le référentiel produit, l'appariement concurrentiel, le parc de règles et sa gouvernance, l'explicabilité des recommandations, et le suivi de la conformité.
S'y ajoute l'entretien courant. Les organisations interrogées par Exclaimer en 2025 consacrent pour 63 % d'entre elles entre 10 et 50 heures par mois à la maintenance de leurs outils internes, et pour 66 % entre 20 000 et 100 000 dollars par an.
Selon l'enquête Exclaimer de novembre 2025 menée auprès de plus de 2 000 décideurs informatiques, 71 % des outils internes finissent abandonnés, proportion qui atteint 83 % dans l'industrie et la finance. Le point de rupture n'est presque jamais la mise en service.
Le mécanisme est régulier : la première version rend service, l'adoption progresse, puis les demandes d'évolution dépassent la capacité d'une équipe qui porte aussi d'autres priorités. Les délais s'allongent, les utilisateurs reprennent leurs tableurs, l'usage s'érode, et la maintenance finit par être remise en cause devant un comité qui constate un usage faible.
L'appariement concurrentiel. Déterminer que la référence relevée chez un concurrent est bien la même que la vôtre, malgré un libellé différent, un conditionnement différent et l'absence de code commun, est un problème difficile qui ne se résout pas par une comparaison de chaînes de caractères.
Ses conséquences sont directes : un mauvais appariement conduit à s'aligner sur un produit qui n'est pas le bon, et l'erreur se lit en marge sans qu'aucune alerte ne se déclenche. Le référentiel produit interne arrive juste derrière, pour des raisons comparables.
Trois situations le justifient. Un périmètre étroit et stable, par exemple une mécanique tarifaire propre à votre métier sur quelques centaines de références qui n'évolue pas chaque trimestre. Un avantage concurrentiel réel, lorsque votre façon de fixer les prix constitue en elle-même un différenciateur introuvable sur étagère.
Et surtout le complément plutôt que le remplacement : une plateforme pour le socle commun, à savoir référentiel, appariement, règles, conformité et traçabilité, et un développement interne pour la seule couche qui porte votre singularité.
Pas « sommes-nous capables de le construire ? », dont la réponse est presque toujours oui et qui ne prédit rien. La question qui discrimine est : « sommes-nous capables de l'entretenir pendant dix ans, avec des départs, des changements de priorité et des évolutions réglementaires ? »
Trois indicateurs la rendent concrète : combien de personnes peuvent modifier une règle sans l'aide de son auteur, combien de temps il faut à un nouvel arrivant pour devenir autonome, et qui traitera une évolution réglementaire survenant dans trois mois, à la place de quelle autre tâche.
Le modèle est la partie facile. Un moteur de recommandation fonctionne en quelques mois ; ce qui prend des années, c'est le référentiel, l'appariement concurrentiel, le parc de règles, l'explicabilité et la conformité. D'après Exclaimer (2025), 71 % des développements internes finissent abandonnés, et 83 % dans les secteurs réglementés : le point de rupture n'est presque jamais la mise en service, c'est l'entretien.
Le coût caché est un coût de continuité : un outil interne repose sur deux ou trois personnes, et leur départ transforme l'actif en passif. Le build garde du sens sur un périmètre étroit et stable, en complément d'une solution plutôt qu'à sa place. Le critère de choix n'est pas la compétence de l'équipe, c'est sa capacité à tenir dix ans.
Donnée et contexte sont deux actifs différents : la donnée décrit ce qui s'est passé, le contexte explique ce qu'on a le droit de faire et ce qui serait absurde. Ce contexte est tacite par nature : il n'a jamais été écrit parce qu'il n'a jamais eu besoin de l'être tant que les décisions étaient prises par des humains qui le partageaient.
Quatre familles en couvrent l'essentiel : les repères de prix, les contraintes relationnelles, les interdits non écrits et les intentions commerciales par catégorie. Les formaliser a une valeur durable, car le contexte survit aux modèles : les algorithmes se remplacent tous les deux ou trois ans, un contexte écrit reste un actif de l'entreprise.
Un business case de solution de pricing mêle deux retours sur investissement qui n'ont rien à voir. Le ROI de friction, ce sont les heures libérées : facile à mesurer, mais plafonné. Le ROI de décision, ce sont les points de marge gagnés sur des prix mieux posés : difficile à mesurer, et sans plafond.
Confondre les deux explique l'écart relevé par IBM en 2025 : 66 % des dirigeants constatent des gains de productivité avec l'IA, mais environ un sur cinq seulement a atteint ses objectifs de retour sur investissement. Le ROI de décision ne se mesure pas en comparant avant et après, mais contre un groupe témoin, faute de quoi la saison, l'inflation ou un concurrent sont crédités à l'outil. Le test à faire passer à un business case : si vous retirez toutes les lignes « temps gagné », reste-t-il un projet rentable ?