Synchroniser caisse et boutique en ligne : l'exemple Hiboutik

Un commerce qui vend à la fois en magasin et sur internet n’a qu’un seul stock. Les boîtes sont sur les mêmes étagères, qu’elles partent au comptoir ou dans un colis. Pourtant, dans beaucoup de commerces, la caisse et la boutique en ligne tiennent chacune leur propre compte. Le résultat est prévisible : le dernier exemplaire est vendu deux fois, et l’un des deux clients reçoit un message d’excuse.

Nous avons réalisé pour Bouge Ton Pion, boutique de jeux de société et de cartes à collectionner, un site e-commerce synchronisé avec sa caisse Hiboutik, dont nous assurons aussi l’infrastructure et la maintenance. Cet article ne détaille pas ce projet en particulier : il expose les questions que pose toute liaison entre une caisse et un site marchand, en s’appuyant sur ce que l’éditeur documente publiquement.

Ce que permet l’API Hiboutik#

Hiboutik est un logiciel de caisse en ligne. Sa page API développeurs indique qu’il expose une API REST, avec des échanges au format JSON, pour synchroniser et mettre à jour les ventes, les produits, les clients et les stocks. L’éditeur y précise aussi que des webhooks permettent des interactions en temps réel : la caisse prévient elle-même une application externe lorsqu’un événement se produit.

La référence complète de l’API, publiée par l’éditeur, détaille ces possibilités. On y trouve notamment :

• la lecture du stock disponible par entrepôt ou par produit, et des mouvements de stock entre deux dates ;
• la gestion des produits et de leurs déclinaisons ;
• la consultation des ventes clôturées jour par jour ;
• la déclaration de webhooks sur une liste d’événements : clôture d’une vente, création ou modification d’un produit, ajout d’un paiement, validation d’un transfert de stock, entre autres.

Autrement dit, les briques existent. La difficulté n’est pas technique au sens strict : elle est dans les décisions à prendre avant de les assembler.

Première décision : qui fait foi ?#

Une synchronisation à deux sens, où chaque système peut modifier le stock de l’autre, est la source la plus fréquente d’incohérences. Il faut désigner un seul système de référence par type d’information.

Ce tableau n’est pas une règle universelle. Un commerce dont l’essentiel des ventes se fait en ligne peut raisonner à l’inverse. L’important est que la question soit tranchée, écrite, et connue de toute l’équipe.

Deuxième décision : à quelle fréquence ?#

Deux approches coexistent.

La synchronisation périodique interroge la caisse à intervalle régulier et met à jour le site. Elle est simple et robuste, mais elle laisse une fenêtre pendant laquelle le site affiche un stock dépassé.

La synchronisation par événement s’appuie sur les webhooks : dès qu’une vente est clôturée en caisse, le site en est informé. La fenêtre de décalage se réduit à quelques secondes.

En pratique, les deux se combinent : l’événement pour la réactivité, la synchronisation périodique pour rattraper ce qui aurait été manqué. Car un webhook peut ne pas arriver — serveur indisponible, erreur réseau — et rien ne le rejoue tout seul si on ne l’a pas prévu.

Le bon réglage dépend du catalogue. Pour des articles en exemplaire unique ou des sorties très attendues, chaque minute de décalage compte. Pour un catalogue large et des stocks confortables, une mise à jour régulière suffit souvent.

Troisième décision : comment éviter la double vente ?#

Même avec une synchronisation rapide, deux ventes simultanées restent possibles. Quelques garde-fous limitent le risque :

• un stock de sécurité sur le site pour les articles rares : le site affiche « épuisé » un peu avant la caisse ;
• la réservation du stock à la commande, et non à l’expédition : une commande en ligne doit décrémenter le stock immédiatement ;
• une procédure écrite pour le cas où la double vente arrive quand même : qui prévient le client, sous quel délai, avec quelle proposition.

Le point qu’on oublie : les erreurs#

Une synchronisation qui fonctionne ne se remarque pas. Une synchronisation en panne non plus, et c’est tout le problème : le site continue de vendre sur la base d’un stock figé, sans que personne ne s’en aperçoive.

La documentation Hiboutik contient d’ailleurs un détail qui mérite attention. Dans la référence de l’API, la description de l’adresse de destination d’un webhook précise que si cette adresse n’est pas valide ou renvoie une erreur, l’action est bloquée. La même référence prévoit un mode asynchrone, recommandé lorsque l’application appelée peut mettre plus de 4 secondes à répondre ou que plusieurs webhooks portent sur la même action. Autrement dit, un service de synchronisation mal surveillé ne se contente pas de prendre du retard : selon sa configuration, il peut gêner le travail en caisse.

D’où trois exigences, quel que soit le logiciel :

1. Journaliser chaque échange : ce qui a été envoyé, reçu, refusé.
2. Alerter une personne quand les échecs se répètent, et pas seulement écrire dans un fichier que personne ne lit.
3. Savoir rattraper : après une panne, une resynchronisation complète doit pouvoir être lancée sans manipulation risquée.

C’est pour cette raison qu’une synchronisation de ce type relève autant de la maintenance au quotidien que du développement initial. Les éditeurs font évoluer leurs API, les catalogues grossissent, les habitudes de l’équipe changent.

Avant de lancer un projet de synchronisation#

Quelques questions à se poser, que vous travailliez avec Hiboutik ou un autre logiciel de caisse :

• Quel système fait foi pour le stock, les prix, les fiches produits ?
• Quels articles ne supportent aucun décalage ?
• Qui est prévenu quand la liaison tombe, et que doit-il faire ?
• Que se passe-t-il pour les ventes en magasin si le site est indisponible, et inversement ?
• Qui maintient la liaison dans la durée ?

Si ces questions ont une réponse écrite, le développement devient une affaire d’exécution. Si elles n’en ont pas, aucune API ne les tranchera à votre place. C’est le travail que nous menons en amont de tout projet de site e-commerce relié à un outil existant.