Brancher une boutique sur un stock réel

Une boutique en ligne branchée sur rien affiche un stock que quelqu’un met à jour à la main. Ça tient tant que le catalogue est petit et que les ventes sont rares. Le jour où le même article se vend en magasin et sur le site dans la même heure, la boutique promet un objet qui n’existe plus, et c’est le service client qui paie.

Le vrai problème n’est pas la synchronisation

Relier deux systèmes est du travail réglé. Ce qui coince est en amont: si la quantité disponible existe à deux endroits, lequel a raison quand ils divergent.

Cette question n’est pas technique, elle est organisationnelle, et personne ne la pose spontanément parce qu’elle a l’air évidente. Elle ne l’est pas. Le logiciel de caisse connaît le stock physique mais ignore les commandes en ligne non encore préparées. La boutique connaît ses commandes mais ignore ce qui vient de sortir du magasin. Les deux ont tort la moitié du temps.

Il faut donc désigner une source de vérité par donnée, et l’écrire. Le prix peut faire autorité côté gestion pendant que la disponibilité fait autorité côté caisse. C’est un choix par champ, pas un choix par logiciel.

Ce qui se décide au départ et se répare mal ensuite

Trois points reviennent à chaque chantier, et les trois coûtent cher quand ils sont tranchés après coup.

La réservation du stock. Un article ajouté au panier est-il déjà retiré du disponible, ou seulement au paiement. Le premier choix protège l’acheteur et immobilise du stock, le second maximise les ventes et produit des annulations.

L’identifiant partagé. Les deux systèmes doivent parler de la même référence avec la même clé. Quand le magasin l’appelle par son code interne et la boutique par son code-barres, la correspondance vit dans un tableur, et le tableur finit toujours par mentir.

Le sens de la mise à jour. Un flux qui va dans les deux sens sans arbitrage écrase alternativement chaque version. La plupart du temps, un seul sens suffit et il vaut mieux l’assumer.

Ce qu’on installe

La liaison passe par l’API de la boutique quand le logiciel de gestion en expose une, et par un moteur de flux quand il faut transformer les données en chemin. Nous employons surtout n8n. Son code est consultable et il s’installe sur une machine que le client contrôle, auquel cas rien n’est facturé à l’exécution. L’offre infonuagique de l’éditeur, elle, se paie au nombre d’exécutions: c’est un choix d’hébergement, pas une propriété du produit.

Le point qu’on oublie systématiquement dans les devis: les alertes. Un flux qui échoue en silence est pire que pas de flux, parce que tout le monde continue de faire confiance à un chiffre qui a cessé d’être mis à jour. Ce qui échoue doit se voir, sur le canal que l’équipe lit réellement.

Et parfois, il ne faut rien relier

Une marque qui vend une centaine de références depuis un seul lieu, sans point de vente physique, n’a pas de problème de stock partagé. Lui vendre une intégration revient à lui faire financer la maintenance d’un flux pour un bénéfice nul.

La question à poser avant tout chiffrage est celle-là: combien de fois par semaine les deux chiffres divergent-ils aujourd’hui, et qu’est-ce que ça coûte quand ça arrive. Si la réponse est « rarement, et pas grand-chose », le tableur suffit.