Stocks, packs (lots, bundles) et soldes concentrent les bugs que la copie de test calme ne voit pas. WooCommerce et PrestaShop gèrent le stock « assez bien » à 10 commandes/heure. À 200, les accès concurrents (race conditions) apparaissent : réservation trop tardive, pack qui ne décrémente pas les enfants, cache de page produit qui affiche « en stock ». Cet article liste ce qui casse, comment le tester avant les soldes, et ce que l'audit campagne doit exiger.
📦 Les trois mensonges du stock
La page produit dit en stock, le tunnel de vente dit non. Le pack se vend, les composants restent. Deux commandes prennent la dernière pièce. Sous charge, le « ça passe » du CMS e-commerce montre ses coutures.
Ajoutez un ERP ou un FTP de stocks (j'en ai branché) : le délai de sync devient un oversell. On documente qui est maître. Un seul maître. Voir aussi l'article sur le PIM.
🏃 Sous charge, pas en local
Deux navigateurs, même SKU à 1. Deux tunnels de vente. Qui gagne ? Le stock final ? Les e-mails ? On le fait en copie de test avec un stock à 1. Puis on parle d'un vrai pic (workers, PHP, voir l'article sur l'hébergement WordPress et PrestaShop).
Le cache de page produit qui affiche un stock : exclusion ou fragment vivant. Voir l'article sur le cache et le tunnel de commande.
- SKU à 1, deux tunnels de vente
- Pack + composant isolé
- Rupture affichée = rupture caisse
- Sync ERP : délai connu
🏷️ Soldes : prix et règles
Prix barrés, règles panier, codes. Sous charge, un module de promo mal indexé recalcule trop. La boutique rampe, les clients double-cliquent et la commande part deux fois. On allège les règles le temps du pic, ou on augmente la capacité du serveur.
Les prix spécifiques + cache = mauvais prix. Vérification obligatoire.
✅ Avant J0
La liste de contrôle de l'article Audit WooCommerce avant campagne vaut aussi pour PrestaShop. Retour arrière sur le stock (on ne corrige pas 400 commandes à la main). Quelqu'un joignable.
Stocks, packs et soldes : ce qui casse sous charge se prépare. Ça ne se constate pas le lundi à 10 h.
Un stock juste à 5 commandes/heure n'est pas un stock. C'est une démo.
✅ Liste de contrôle avant les soldes
Avant les soldes, j'écris comment les stocks des packs sont calculés, qui modifie les prix et à quelle heure. La mesure qui compte : aucune commande sur un produit épuisé et aucun prix faux le premier jour.
Sauvegarde restaurable de la base, export du stock avant intervention, accès admin à votre nom. Puis la correction du modèle. Puis un test de charge, puis 24 à 72 h de surveillance des commandes. Sans ce suivi, le stock est corrigé sur le papier, pas sous la pression du pic.
- Stocks des packs et des composants relevés avant J0
- Copie de test avant de toucher au stock
- Un changement à la fois, documenté
- Commande test sur les packs et les prix soldés, puis suivi des commandes les premières 24 h
📌 Ce que je refuse sur ce sujet
Je refuse de modifier les règles de stock la veille des soldes. Je refuse aussi d'installer une extension de soldes de plus sans savoir comment elle s'entend avec les packs.
Si la boutique a tenu les derniers soldes sans incident, on ne change rien avant les prochains.
🧭 Questions fréquentes
Faut-il corriger avant le prochain pic ? Oui si un pack a déjà été vendu sans stock ou si le stock affiché diverge de l'entrepôt. Sinon, on planifie la correction hors période de soldes, avec des chiffres de ventes réels pour dimensionner.
Peut-on tester directement sur la boutique ? Pas sur les stocks : on rejoue des commandes simultanées sur une copie, jamais sur la boutique en vente. Voir la page Maintenance PrestaShop pour la préparation d'une copie de test.
Combien de temps ? Souvent deux à cinq jours entre l'audit du modèle de stock, les corrections et le test de charge. Un devis « on règle le stock en une demi-journée » ne simule jamais le lundi des soldes.
