Une refonte du système de prix découverte en la testant

Contexte

Une refonte du système de prix côté ERP était en préparation depuis plusieurs semaines, avec l'objectif de simplifier un mécanisme historiquement fragile : sur un produit à plusieurs variantes (tailles, couleurs…), l'ancien système partageait un même champ de prix « de base » entre toutes les variantes, chacune n'étant qu'un écart par rapport à ce prix de base. Une mise à jour mal séquencée sur une seule variante pouvait décaler silencieusement le prix de toutes les autres.

Ce qui a été découvert

En construisant l'app de mise à jour des tarifs, un test réel sur le terrain a révélé que la refonte attendue était en fait déjà déployée en production — sans que ça ait été formellement confirmé. Le nouveau système stocke désormais un prix de vente réellement propre à chaque variante, ce qui élimine structurellement le risque de contamination entre variantes d'un même produit.

La détection s'est faite en comparant, sur des produits réels, la valeur attendue après une mise à jour et la valeur effectivement synchronisée côté site marchand : un écart est apparu, révélant que l'app écrivait encore sur l'ancien mécanisme, désormais déconnecté. Le code de l'app a été corrigé pour écrire directement sur le nouveau champ, en ligne avec la contrainte de cohérence de prix imposée par le nouveau système. Le sujet a aussi été remonté au prestataire technique en charge de l'ERP, avec une proposition d'angle plus large : ce pattern (rapprochement automatique de tarifs, avec garde-fous humains) pourrait intéresser d'autres de ses clients confrontés au même besoin.

Ce qui était difficile

Détecter un changement d'architecture qui n'avait pas été officiellement communiqué comme « en prod » — la seule façon de le savoir avec certitude a été de comparer le comportement réel des champs de prix sur des données de production, pas de se fier à la documentation existante.

Stack

ERP (lecture / écriture via API), vérification comparative sur données réelles.

Ce que ça illustre

La documentation d'un système peut être en retard sur son état réel. Tester en conditions réelles — même pour une tâche opérationnelle simple comme une mise à jour de tarif — reste le moyen le plus fiable de vérifier ce qu'un système fait vraiment, plutôt que ce qu'on pense qu'il fait.