En résumé
Dès qu'un produit se vend à deux endroits, une seule question compte : QUI détient le chiffre qui fait foi. Deux systèmes qui tiennent chacun leur compte finissent toujours par diverger, et la divergence se découvre sur une commande qu'on ne peut pas honorer. La bonne réponse est un stock unique, décompté au moment du paiement et RESTITUÉ à l'annulation — les deux gestes devant être idempotents. Et une règle qui surprend : refuser une vente pour un stock manquant coûte presque toujours plus cher que l'accepter et prévenir.
La seule question qui compte : qui détient le chiffre
Une caisse qui tient son stock, un site qui tient le sien, et une synchronisation « toutes les heures » : c'est la configuration la plus répandue, et elle produit toujours le même incident. Entre deux synchronisations, les deux chiffres divergent. Ça ne se voit pas — jusqu'à la commande qu'on ne peut pas honorer, un samedi.
La question n'est pas technique, elle est d'organisation : quel système fait foi ? Le second doit AFFICHER le stock, jamais le décider. Une synchronisation dans les deux sens n'est pas une synchronisation, c'est une négociation permanente entre deux sources qui ont chacune raison.
Le corollaire est inconfortable et il faut l'accepter : le système qui fait foi doit être joignable au moment de la vente. Si votre caisse est hors ligne le soir, elle ne peut pas être la source de vérité d'un site ouvert la nuit.
Quand décompter : au panier, ou au paiement ?
Décompter à la mise au panier semble prudent, et fabrique des ruptures qui n'existent pas. Les paniers abandonnés sont la règle, pas l'exception : bloquer du stock pendant trente minutes pour chacun revient à afficher « épuisé » sur des articles disponibles, aux heures les plus fréquentées.
Le décompte se fait au PAIEMENT confirmé. C'est le seul instant où la vente existe vraiment, et c'est aussi celui où l'on connaît le montant, l'acheteur et la commande — donc celui où l'on peut tracer.
Reste le risque de deux acheteurs sur le dernier article, à la même seconde. Il est réel et il est rare. Le traiter en bloquant le stock trente minutes pour tout le monde revient à payer tous les jours pour un incident mensuel.
⚠️ Restituer, et le faire deux fois sans dommage
Le geste qu'on oublie n'est pas le décompte, c'est la restitution. Une commande annulée, un remboursement, une rétractation : à chaque fois, l'article revient en stock. Un logiciel qui décompte sans restituer voit son stock fondre au rythme des gestes commerciaux, et le commerçant finit par ne plus le croire — c'est le pire résultat possible, parce qu'il cesse alors de le regarder.
Les deux opérations doivent être IDEMPOTENTES : rejouer un décompte déjà fait ne doit rien retirer de plus, rejouer une restitution déjà faite ne doit rien rendre de plus. Ce n'est pas une élégance d'ingénieur : un webhook rejoué, un double clic ou une reprise après incident produisent exactement ces cas-là, et ils arrivent en production.
La question à poser à un logiciel est directe : que se passe-t-il si le même évènement de paiement arrive deux fois ? La bonne réponse est « le second ne change rien et le dit ».
⭐ La règle qui surprend : ne pas refuser la vente
L'intuition dit qu'un stock à zéro doit bloquer la commande. En pratique, c'est presque toujours plus coûteux que l'inverse. Un stock est faux plus souvent qu'on ne le croit : un article rendu et non ressaisi, une vente en boutique tapée en fin de journée, un inventaire d'il y a trois semaines.
Refuser une commande sur la foi d'un chiffre faux, c'est perdre une vente ET un client, sans jamais le savoir — il n'y a pas de trace d'un acheteur qui referme un onglet. Accepter, décompter en négatif et PRÉVENIR le commerçant lui laisse le choix : honorer avec le stock réel, commander chez son fournisseur, ou appeler l'acheteur.
C'est la décision que nous avons prise pour Structure Hub, et elle est écrite : le stock est tenu, décompté, restitué — mais une vente n'est jamais refusée pour un stock manquant. Le commerçant est prévenu, il décide.
Le cas qui casse tout : le retrait en boutique
Le click and collect fait sortir l'article du même stock, mais par une autre main et à un autre moment. L'acheteur paie en ligne le mardi, passe le jeudi, et entre-temps quelqu'un a vendu le dernier exemplaire au comptoir.
Il n'y a que deux façons honnêtes de traiter ça : réserver physiquement l'article dès le paiement — le mettre de côté, réellement —, ou prévenir l'acheteur que sa commande est confirmée sous réserve, et le rembourser vite s'il faut. Ce qu'il ne faut pas faire est de compter sur le stock informatique pour arbitrer entre deux mains humaines.
Le créneau de retrait mérite le même soin : un acheteur qui peut changer son créneau lui-même appelle moins, et le commerçant sait à quoi s'attendre. Un créneau qu'on ne peut pas déplacer produit des retraits ratés, et un retrait raté finit en remboursement.
À lire également
Envie d'aller plus loin ?
Structure Web crée votre site sur-mesure, rapide et bien référencé, puis vous le pilotez en autonomie avec Structure Hub.