Synchroniser les stocks Shopify avec n8n : en finir avec les ruptures et les surventes

Un stock inexact n'est pas un détail technique : c'est soit une vente perdue (le produit est là, le site dit « épuisé »), soit une survente (le site vend ce qui n'existe plus, et il faut rembourser et s'excuser). L'ampleur du problème est documentée depuis longtemps : l'étude de référence de Gruen, Corsten et Bharadwaj publiée en 2002 (« Retail Out-of-Stocks: A Worldwide Examination of Extent, Causes and Consumer Responses », voir sur Google Scholar) chiffrait déjà les ruptures à environ 8 % des références en rayon dans la distribution mondiale — et montrait que face à une rupture, une large part des clients substituent ou changent d'enseigne. En e-commerce, où le « rayon » est une base de données, l'essentiel de ces ruptures est évitable : c'est un problème de synchronisation, exactement ce que n8n fait bien.

Les quatre flux d'une synchronisation complète

1. Ventes → stock : chaque commande Shopify décrémente le stock dans les autres systèmes (ERP, autre boutique, marketplace).
2. Approvisionnements → Shopify : les réceptions fournisseur et les mouvements de l'ERP remontent dans Shopify.
3. Alertes : les passages sous seuil déclenchent notification ou réassort.
4. Réconciliation : un comptage complet périodique compare toutes les sources et corrige les dérives.

Le tout suppose la connexion de base décrite dans notre guide Shopify + n8n : crédentiel Admin API, node Shopify pour produits et commandes, Shopify Trigger pour les webhooks.

Flux 1 : réagir aux ventes en temps réel

Le Shopify Trigger écoute les événements de commande (orders/create, orders/cancelled) et d'inventaire. À chaque commande : extraire les lignes (SKU, quantité), puis répercuter la décrémentation vers les autres systèmes — une requête SQL vers l'ERP via le node Postgres, un appel API vers WooCommerce si vous opérez les deux plateformes, ou une mise à jour de la marketplace.

Deux précautions absolues sur ce flux. D'abord, l'idempotence : Shopify peut livrer un webhook plusieurs fois ; sans déduplication par ID de commande, chaque doublon décrémente le stock une fois de trop — notre guide de l'idempotence des webhooks détaille le pattern. Ensuite, les annulations et retours : orders/cancelled et les remboursements doivent recréditer le stock, sinon il fond artificiellement.

Flux 2 : pousser l'inventaire vers Shopify

Dans l'autre sens, les niveaux calculés par l'ERP ou reçus du fournisseur doivent atterrir dans Shopify. Le node Shopify gère produits et commandes ; pour l'inventaire par emplacement, un node HTTP Request vers l'Admin API GraphQL fait le travail : on résout le SKU vers son inventory item, puis on fixe la quantité disponible pour le location concerné. Encapsulez cette logique dans un sous-workflow « mettre à jour le stock d'un SKU » réutilisé par tous les flux — un seul endroit à corriger quand l'API évolue.

Cas fréquent en pratique : le fournisseur n'a pas d'API mais dépose un fichier CSV ou Excel (par email ou sur un serveur). n8n l'ingère nativement — extraction du fichier, éventuellement récupéré via SFTP — puis une boucle met à jour chaque référence. Attention au rate limiting de l'API Shopify sur les gros catalogues : traitez par lots avec une pause entre les paquets.

Flux 3 : alertes de stock bas et réassort

Un workflow planifié (Schedule Trigger) parcourt les niveaux et route selon des seuils par référence : sous le seuil d'alerte, notification Slack ou email à l'acheteur ; sous le seuil critique, création automatique d'une ligne de réassort dans l'ERP ou d'un brouillon de commande fournisseur, avec approbation humaine avant envoi. Les seuils vivent dans une Data Table ou un Google Sheets que l'équipe achats peut éditer sans toucher au workflow.

Flux 4 : la réconciliation qui rattrape tout

Même bien construite, une synchronisation temps réel dérive : webhook perdu pendant une maintenance, correction manuelle en back-office, retour traité hors process. La parade est un comptage complet quotidien : exporter les niveaux de chaque système, les rapprocher par SKU — le node Compare Datasets fait exactement cela, avec ses sorties « différent / seulement dans A / seulement dans B » —, journaliser chaque écart, appliquer la source de vérité désignée et alerter au-delà d'un seuil. C'est la même logique de filet de sécurité qu'un Error Workflow : on ne suppose pas que le temps réel est parfait, on le vérifie.

Par où commencer

Commencez par le flux 1 (ventes → stock) et le flux 4 (réconciliation) : c'est le duo qui élimine les surventes, le risque le plus coûteux. Ajoutez ensuite les alertes, puis l'intégration fournisseur. Et si votre boutique traite déjà ses commandes avec n8n — notre guide de l'automatisation des commandes e-commerce en pose les bases —, la synchronisation des stocks se greffe naturellement sur les mêmes webhooks : même trigger, une branche de plus.

Un stock juste en permanence, ce n'est pas un module ERP à cinq chiffres : c'est quatre workflows n8n disciplinés — temps réel idempotent, écritures centralisées, seuils éditables et réconciliation quotidienne.