Bijoux d'occasion, boutique WooCommerce et connecteur ERP Jewely

Bijoux d'occasion vend des bijoux de seconde main en magasin et en ligne. Je travaille sur leur boutique WooCommerce depuis 2019, et j'ai développé en 2026 le connecteur qui la relie à Jewely, l'ERP du magasin, pour le stock, les prix, les fiches produits et les commandes.

Depuis 2019

J'ai monté le premier site WooCommerce de la boutique en 2019, sur un thème enfant Understrap, et je l'ai fait évoluer jusqu'en 2024. Le site a ensuite été refait en thème bloc par l'équipe Sumotori, dont je fais partie. De mon côté, j'ai développé pour cette nouvelle version l'extension de remises selon l'ancienneté des produits, publiée depuis sur wordpress.org sous le nom Auto Discounts for WooCommerce, ainsi que l'outil de synchronisation entre le site local et la production qui est devenu Miroir Local Sync.

Le problème du double stock

Chaque bijou est une pièce unique. Quand une bague est vendue en magasin, elle doit disparaître du site au plus vite, sinon un client en ligne peut payer un article qui n'existe plus. À l'inverse, une commande passée sur le site doit bloquer la pièce dans l'ERP avant qu'un vendeur ne la propose au comptoir.

Le connecteur

L'extension sumotori-jewely-connector gère trois flux. Je les ai d'abord décrits dans un cahier des charges adressé à l'équipe technique de Jewely, revu en trois versions au fil des tests sur leur API.

Stock et prix. Le site reçoit les changements de l'ERP par webhook. Comme une notification peut se perdre, une tâche de nuit reprend toutes les entrées modifiées depuis le dernier passage, en filtrant sur leur date de mise à jour, et n'écrit que si une valeur diffère. Une remise à plat complète du catalogue se lance depuis l'administration, et automatiquement chaque dimanche.

Fiches produits. Quand un bijou est marqué « visible sur le site » dans l'ERP, le connecteur crée la fiche WooCommerce, importe ses photos et l'enregistre dans une table de correspondance. Les fiches existantes sont rattachées par leur référence, sans doublon.

Commandes. Une commande web crée le client dans Jewely s'il n'existe pas, puis une réservation, une vente ou un acompte selon le cas. Quand l'API refusait un format de paiement, la vente est créée en attente et le règlement est saisi en acompte, ce qui laisse au vendeur une trace complète à rapprocher.

Ce que l'API impose

L'API de Jewely est limitée à 60 requêtes par minute et renvoie les prix en centimes. La documentation OpenAPI ne correspondait pas toujours à l'API réelle, j'ai donc vérifié chaque point sur l'API de production avant de l'écrire dans le code (champ de stock à utiliser, filtres ignorés côté serveur, authentification par clé statique).

Toutes les écritures passent par Action Scheduler, la file de tâches embarquée dans WooCommerce. Un appel qui échoue est relancé trois fois avec un délai croissant, chaque échange est consigné dans les journaux WooCommerce, et le vendeur reçoit un e-mail si l'échec est définitif.

Où en est le projet

Le connecteur en est à sa version 0.4. Le magasin et le site s'appuient sur la même source, l'ERP, et une commande en ligne arrive dans Jewely sous la forme que les vendeurs utilisent déjà au comptoir. Quelques points dépendent encore de Jewely, comme la liste des événements envoyés par webhook ou l'enregistrement du paiement sur une vente : ils sont suivis dans le cahier des charges, et l'extension documente le contournement en place pour chacun.