Comment synchroniser le stock de ma boutique aquariophilie avec mon site e-commerce ?

Dernière mise à jour : 10 juillet 2026

La plupart des tutoriels sur la synchronisation de stock partent d'un postulat : votre stock est un tas d'unités identiques, quarante fois le même SKU, interchangeables. C'est exactement ce postulat qui casse quand vous vendez des poissons et des coraux vivants. Chaque spécimen est une pièce unique, et une architecture pensée pour des quantités fongibles vous fera survendre, avec remboursements et rétrofacturations à la clé. Voici ce qui doit réellement se passer.

Pourquoi le modèle de quantité générique échoue

Un catalogue e-commerce classique stocke un seul nombre par produit : « en stock : 12 ». À chaque achat, la plateforme décrémente le compteur. Ça marche pour des t-shirts. Ça s'effondre dès que le client achète ce spécimen précis: la bouture de corail WYSIWYG de la photo, pas « une » bouture de l'espèce. Deux clients ne peuvent pas acheter la même colonie, et aucune autre unité ne peut s'y substituer. Votre stock n'est pas un compteur : c'est une liste d'individus, chacun avec sa propre fiche.

Modéliser chaque spécimen comme son propre SKU

La base d'une synchro qui fonctionne, c'est une fiche par spécimen. Chaque poisson ou corail reçoit un identifiant unique, sa photo, son propre statut (disponible / réservé / vendu / mort). Quand un spécimen quitte votre stock, vendu en magasin ou décédé, vous basculez une fiche, et cet individu disparaît du site. Aucun compteur partagé à réconcilier, aucune supposition sur laquelle des douze « unités » est celle qui est morte.

La couche de synchro : une source de vérité unique vers Shopify

Une fois les spécimens transformés en fiches individuelles, la synchro elle-même est simple sur le principe : votre logiciel de gestion est la source de vérité unique, et il pousse les changements d'état vers votre boutique. Les détails comptent :

• Push, pas polling. Quand le statut d'un spécimen change, un événement part immédiatement vers Shopify (via l'Admin API) : l'annonce est retirée en quelques secondes, pas au prochain batch horaire.
• Une seule direction pour la vérité. Les commandes en ligne réservent le spécimen, mais le statut maître vit toujours dans un seul système. Les montages « les deux systèmes peuvent modifier » sont la source des décalages et des doubles ventes.
• Mises à jour idempotentes. Si le même événement est livré deux fois (les webhooks font des retries), l'appliquer deux fois ne doit pas corrompre l'état. Chaque changement porte une version : les mises à jour périmées sont ignorées.

La panne la plus coûteuse : vendre un animal mort

Le cas limite le plus cher, ce n'est pas de survendre quarante t-shirts identiques, c'est de vendre un animal qui n'existe plus. Si la mortalité n'est pas câblée dans la synchro, un spécimen mort dans la nuit reste affiché « disponible » au matin, un client paie, et vous voilà à n'expédier rien ou à rembourser. Sur du vivant expédié, ce litige dégénère en rétrofacturation. La mortalité doit donc être un événement de premier rang dans le système, pas une correction manuelle de tableur remise à « plus tard ».

À quoi ressemble une configuration correcte, de bout en bout

1. Chaque spécimen est créé comme une fiche unique avec photo et statut.
2. Le mettre en vente publie un produit WYSIWYG sur Shopify lié à cette fiche.
3. Une vente (en ligne ou en magasin) ou une mortalité met à jour la fiche maître.
4. Le changement est poussé vers Shopify immédiatement ; l'annonce est retirée.
5. Chaque changement d'état est horodaté : vous avez un historique, utile bien au-delà de la synchro.

C'est exactement l'architecture sur laquelle repose TankLogic : spécimens uniques, retrait en temps réel à la mortalité, et une source de vérité unique qui pousse vers Shopify. Si c'est le problème que vous combattez, c'est l'outil.

Vous vendez des poissons ou coraux vivants en ligne et vous en avez assez de survendre ? Découvrez comment TankLogic gère la synchro au spécimen près.