Pourquoi la synchronisation stock Shopify-ERP plante — et comment l'éviter
Une intégration ERP-Shopify qui passe ses premiers tests n'est pas nécessairement une intégration qui tient dans la durée. Les décalages de stock, les surventes et les doublons de commande apparaissent des jours ou des semaines après le lancement — souvent un jour de forte activité, jamais à un moment commode. Les causes profondes sont presque toujours les mêmes six erreurs d'architecture. Les comprendre avant de construire vous évite de les découvrir en production.
La fausse impression que « l'intégration est faite »
Un premier test de synchronisation réussi est la partie la plus facile. Vous poussez le stock de l'ERP vers Shopify, vous passez une commande de test, elle apparaît dans l'ERP — l'intégration fonctionne. Ce test ne couvre pas la concurrence, les scénarios d'échec et les cas limites qui n'apparaissent que sous charge réelle.
L'intégration qui fonctionne dans un environnement contrôlé se dégrade souvent silencieusement quand plusieurs événements se déclenchent simultanément : deux clients achetant le dernier article en même temps, un webhook arrivant pendant que l'ERP effectue un batch nocturne, une mise à jour produit en cours de synchronisation. La robustesse n'est pas une fonctionnalité bonus. C'est l'intégration.
Erreur 1 : synchronisation unidirectionnelle
L'architecture la plus courante pousse le stock de l'ERP vers Shopify et s'arrête là. Elle règle le problème d'affichage du stock mais laisse les commandes entièrement non gérées. Les commandes passées sur Shopify ne remontent jamais automatiquement dans l'ERP.
Le résultat est une ressaisie manuelle : quelqu'un en back-office recopie chaque commande Shopify dans l'ERP à la main. À faible volume, c'est tolérable. À grande échelle, c'est insoutenable et source d'erreurs. Une intégration complète est bidirectionnelle par conception.
Erreur 2 : pas de gestion des conflits de concurrence
Quand deux clients ajoutent le dernier article en stock à leur panier et passent commande à quelques secondes d'intervalle, les deux transactions peuvent aboutir si aucune vérification atomique du stock n'est en place. Shopify décrémente son propre inventaire, mais si le stock ERP n'est mis à jour qu'en asynchrone après coup, il existe une fenêtre pendant laquelle l'ERP affiche encore une unité disponible — suffisant pour que les deux commandes passent.
La correction exige une vérification atomique de la disponibilité au moment de la validation de la commande, pas seulement un job de synchro tournant sur un planning.
Erreur 3 : webhooks sans retry
Shopify envoie les webhooks en fire-and-forget. Si votre serveur est en panne, en redémarrage, ou trop lent à répondre, l'événement est livré une fois et Shopify ne le réessaie que dans une fenêtre limitée. Une commande créée pendant une maintenance serveur peut ne jamais atteindre votre ERP.
La solution est une file d'attente persistante entre l'endpoint webhook et la logique de traitement côté ERP. Des outils comme Redis avec BullMQ, ou n'importe quel message broker, garantissent qu'aucun événement ne se perd même si le processeur côté ERP est temporairement indisponible.
Erreur 4 : mapping de SKU approximatif
Un produit avec trois tailles et deux couleurs génère six variantes Shopify. Chaque variante a son propre SKU, son propre niveau de stock et sa propre référence dans l'ERP. Si le mapping entre les SKU des variantes Shopify et les références produit de l'ERP n'est pas explicite et testé variante par variante, une vente de taille M en rouge peut décrémenter le stock de taille L en bleu dans l'ERP.
Le mapping SKU n'est pas une tâche de configuration ponctuelle. Il doit être maintenu chaque fois que de nouvelles variantes sont ajoutées ou que des références existantes sont renommées dans l'ERP.
Erreur 5 : ignorer les délais de propagation
Une mise à jour de stock dans l'ERP n'apparaît pas instantanément sur Shopify. Selon la fréquence de synchronisation — job planifié toutes les 15 minutes, toutes les heures, ou déclenché en fin de batch — le délai entre une vente en boutique et la mise à jour correspondante de l'inventaire Shopify peut être significatif.
Pour les produits à faible rotation, c'est sans conséquence. Pour une vente flash ou un produit dont il ne reste que deux ou trois unités, un délai de propagation de 15 minutes suffit à générer des surventes. Le délai acceptable doit être défini par catégorie de produit et intégré dans l'architecture de synchronisation.
Erreur 6 : aucun monitoring ni alerte
Sans supervision, une synchro cassée se découvre quand un client se plaint d'une commande passée sur un produit en rupture depuis trois jours. À ce stade, les dégâts en termes d'inventaire, de confiance client et de temps service client sont déjà faits.
Des logs structurés, des alertes sur les taux d'erreur et un dashboard de santé de l'intégration ne sont pas une infrastructure optionnelle. Ce sont ce qui permet de détecter et corriger une défaillance de synchro avant qu'elle crée des problèmes visibles par les clients.
Ce qu'une bonne architecture inclut systématiquement
Une intégration Shopify-ERP fiable est bidirectionnelle — stock et prix de l'ERP vers Shopify, commandes et fiches clients de Shopify vers l'ERP. Elle utilise une file d'attente persistante avec logique de retry et dead letter queue pour les événements qui échouent de façon répétée. Le mapping SKU est explicite, versionné et testé sur toutes les variantes. Les délais de propagation sont définis et acceptables par catégorie de produit. Et le tout émet des logs structurés et déclenche des alertes sur toute erreur au-dessus d'un seuil défini.
Aucune de ces exigences n'est exotique. Ce sont les caractéristiques standard d'une intégration prête pour la production.
Votre synchro Shopify-ERP produit des décalages de stock ou des commandes manquées ? Contactez-nous — nous auditons votre architecture actuelle et identifions les points de défaillance exacts avant qu'ils vous coûtent davantage.