Deux installations PrestaShop distinctes qui vendent les mêmes produits depuis le même stock physique : le cas est courant. Un site grand public et un site professionnel, une boutique française et une boutique allemande sous domaines séparés, ou une marque principale et un déstockage.
Tant que le stock n’est pas partagé, chaque boutique croit disposer de la totalité. La première survente arrive dans la semaine.
Trois architectures possibles
Le multiboutique natif. Une seule installation, plusieurs boutiques logiques. Le stock est partagé nativement, la question ne se pose pas. C’est la solution la plus simple, et elle est souvent écartée à tort : beaucoup de projets partent sur deux installations séparées alors que le multiboutique aurait suffi.
Deux installations synchronisées. Chacune a sa base, son thème, ses modules, et un mécanisme maintient la cohérence du stock. Plus lourd, mais nécessaire dès que les deux sites doivent évoluer indépendamment ou appartenir à des entités juridiques différentes.
Un système tiers maître. Un ERP ou un logiciel de gestion détient le stock, et les deux boutiques le consomment. C’est l’architecture la plus saine dès qu’un troisième canal existe, magasin physique ou place de marché.
Avant de construire une synchronisation, vérifiez que la première option ne convient pas. Elle supprime le problème au lieu de le gérer.
Un maître, un seul
C’est la décision fondatrice, et la synchronisation bidirectionnelle naïve est le piège classique.
Si les deux boutiques peuvent modifier le stock et se le renvoyer, vous obtenez des boucles : la boutique A décrémente, envoie à B, B applique et renvoie à A, qui décrémente à nouveau. Les stocks divergent en quelques heures, dans le mauvais sens.
Deux modèles corrects existent.
Le modèle maître-esclave : une boutique détient la vérité, l’autre reçoit. Simple, mais les ventes de l’esclave doivent remonter, ce qui suppose un canal distinct pour les décréments.
Le modèle à stock centralisé : ni l’une ni l’autre ne détient le stock, un référentiel externe le fait. Chaque vente déclenche un décrément sur ce référentiel, qui redistribue. C’est plus robuste, et cela suppose une brique supplémentaire.
Synchronisation Multi-Boutiques - Module Prestashop 8 & 9Synchronisez catalogue, stock et prix entre plusieurs boutiques PrestaShop€99.00
La fréquence, et la fenêtre de survente
Toute synchronisation périodique laisse une fenêtre pendant laquelle les deux boutiques ont une vision différente. Cette fenêtre se calcule.
Si vous synchronisez toutes les quinze minutes et que vous vendez trois unités par heure d’une référence, la fenêtre représente en moyenne moins d’une unité : le risque est faible. Sur une vente flash à cinquante unités l’heure, la même fenêtre laisse passer une douzaine de commandes en trop.
Trois réglages en découlent. Une fréquence élevée, cinq à quinze minutes, sur les références à rotation rapide. Une synchronisation événementielle plutôt que périodique sur les produits critiques : chaque vente déclenche immédiatement la propagation. Et une marge de sécurité, en réservant une ou deux unités par boutique, qui absorbe la fenêtre sans complexité supplémentaire.
La correspondance des références
Point technique qui décide de la faisabilité. Les identifiants produits ne sont jamais les mêmes entre deux installations : le produit 421 sur la boutique A n’est pas le produit 421 sur la boutique B.
La correspondance doit donc s’appuyer sur une clé métier stable, présente des deux côtés et jamais modifiée. La référence produit convient, à condition qu’elle soit renseignée partout et unique. Le code-barres est une alternative solide.
Deux pièges. Les déclinaisons doivent avoir leur propre référence, sinon la synchronisation se fait au niveau du produit et le stock par taille reste faux. Et les produits présents d’un seul côté doivent être explicitement ignorés, pas traités comme des erreurs à chaque cycle.
Ce qu’on ne synchronise pas
La tentation est de tout aligner. C’est une erreur, et elle rend le système fragile.
Ne synchronisez pas les prix si vos deux boutiques ont des positionnements différents, ce qui est presque toujours la raison de leur existence séparée. Ne synchronisez pas les descriptions traduites ni les métadonnées SEO, sous peine de créer du contenu dupliqué entre deux domaines. Ne synchronisez pas les commandes ni les clients, sauf besoin explicite : ce sont des données à forte charge réglementaire.
Le périmètre minimal qui fonctionne : le stock, la disponibilité, et éventuellement le statut actif ou inactif du produit.
Les conflits, et la reprise après incident
Deux situations à prévoir dès la conception.
Le conflit. Les deux côtés ont changé entre deux synchronisations. La règle doit être écrite : soit le maître gagne toujours, soit la valeur la plus basse l’emporte, ce qui est prudent sur du stock. Une règle non écrite devient une règle aléatoire.
La panne. Que se passe-t-il si la synchronisation s’arrête pendant six heures sans que personne ne le remarque ? Trois protections : un journal consultable des synchronisations avec leur résultat, une alerte en cas d’échec répété, et une resynchronisation complète déclenchable manuellement.
Cette dernière est celle qu’on oublie systématiquement, et celle dont on a besoin en urgence un samedi matin.
Contrôler
Un écart de stock ne se voit pas, il se constate au moment de la survente. Un contrôle hebdomadaire comparant les quantités des deux côtés, référence par référence, prend quelques minutes et révèle les dérives avant qu’elles ne coûtent une commande annulée.
Le module Synchronisation Multi-Boutiques traite cette chaîne sur PrestaShop 8 et 9 : correspondance par référence ou code-barres au niveau des déclinaisons, synchronisation du stock avec sens et fréquence paramétrables, journal des opérations et resynchronisation complète à la demande.
