Préparer le Black Friday sur PrestaShop : le guide

Le Black Friday tombe le 27 novembre 2026, suivi du Cyber Monday le 30. Pour préparer le Black Friday sur PrestaShop, il reste un peu plus d'un mois : assez pour mesurer, corriger et vérifier, pas assez pour tout reprendre. Ce guide suit l'ordre qui évite les mauvaises surprises : mesurer d'abord, corriger ce qui pèse vraiment, mettre un cache là où il est sûr, puis surveiller pendant l'opération.

Le principe : un pic de trafic ne crée pas les lenteurs, il révèle celles qui existent déjà. Une requête SQL tolérable à dix visiteurs devient un goulot à mille. Mieux vaut la trouver en octobre qu'en direct, un vendredi. Pour aller plus loin, Softizy détaille son approche pour préparer PrestaShop aux pics de trafic.

Mesurer votre boutique PrestaShop avant le Black Friday

Inutile d'optimiser sans point de comparaison. Avant toute modification, relevez l'état actuel de votre boutique, page par page :

• les pages qui font le chiffre d'affaires : accueil, catégories, fiches produit, panier et tunnel de commande ;
• pour chacune, le temps de réponse du serveur, le nombre de requêtes SQL et les modules qui s'exécutent ;
• le comportement après une mise à jour ou l'ajout d'un module : une régression qui date de septembre sera encore là en novembre.

Mesurez sur de vraies pages, pas sur un test de vitesse extérieur : un score global ne dit pas quel module ou quelle requête ralentit. C'est l'intérêt d'un outil de profiling PrestaShop : il relie chaque lenteur à la page, au module et à la requête en cause.

Repérer les requêtes SQL et modules lents du panier

Le panier et le tunnel de commande sont les pages les plus sensibles : elles sont personnalisées, donc difficiles à servir depuis un cache de page, et ce sont elles qui transforment une visite en vente. Regardez-les en priorité :

• les requêtes les plus répétées : une même requête exécutée des dizaines de fois sur une page est le premier suspect ;
• les modules qui s'accrochent au panier et à la commande (promotions, livraison, paiement, fidélité) : chacun ajoute du temps à chaque étape ;
• les écarts entre environnements : une page lente en production et rapide en préproduction pointe vers les données ou la configuration, pas vers le code.

Corrigez dans cet ordre : d'abord ce qui est le plus lent sur les pages qui comptent, ensuite le reste. Un module qui ralentit le panier doit être configuré, remplacé ou retiré avant l'opération ; cette décision se prend avec la mesure en main.

Détecter les lenteurs en amont et les corriger avec Scalizy

Relever tout cela à la main, page par page, prend du temps et ne se refait pas à chaque mise à jour. Scalizy automatise la démarche, de la détection à la correction :

• Mesurer : vos pages et leurs requêtes SQL sont profilées en continu, sur le développement, la préproduction et la production, avec un score pour le site.
• Diagnostiquer : Scalizy remonte la cause, pas le symptôme, jusqu'à la page, au module ou à la requête qui ralentit votre boutique.
• Alerter avant vos clients : une alerte par e-mail part dès qu'une page ralentit, après une mise à jour de module ou un pic de trafic. Vous pouvez la traiter bien avant le 27 novembre.
• Recommander : des recommandations priorisées vous disent quoi corriger d'abord.
• Corriger : le Database Cache allège la base de données en un clic, sans toucher au code. Le HTTP Cache sert les pages d'accueil, de catégorie et de produit sans solliciter PHP.

Dès le premier profiling, Scalizy livre aussi un rapport de performance : votre score, vos pages lentes, les modules qui pèsent le plus. Vous partez ainsi du Black Friday avec un état des lieux chiffré, à partager avec votre agence ou votre hébergeur.

Mettre un cache en place, au bon endroit

Un cache ne remplace pas la correction des lenteurs, il évite de refaire le même travail. Deux niveaux se complètent :

• Le cache de pages (HTTP) sert les pages d'accueil, de catégorie et de produit sans solliciter PHP ni la base. C'est le rôle du HTTP Cache avec Varnish ou Cloudflare, avec une purge des pages dès qu'un produit, un prix ou un stock change.
• Le cache de requêtes SQL allège la base de données sur les pages qui ne peuvent pas être servies en cache de page, comme le panier et la commande. C'est le rôle du Database Cache, qui met en mémoire les requêtes récurrentes du cœur de PrestaShop et de vos modules. Scalizy constate en moyenne 80 % de requêtes SQL en moins, et compare chaque page avec et sans cache pour que vous voyiez le gain sur votre boutique.

Activez les caches assez tôt pour les observer sur plusieurs jours de trafic réel, pas la veille. Vérifiez aussi que les données propres à chaque client (panier, compte, session) ne sont jamais servies à un autre visiteur. Si c'est l'infrastructure elle-même qui limite, Softizy propose aussi un hébergement PrestaShop sur AWS haute performance.

Surveiller pendant l'opération

Une fois le travail fait, l'enjeu est de ne rien casser et de réagir vite :

• Gelez les changements quelques jours avant : pas de nouvelle mise à jour de module ni de déploiement non testé en pleine opération.
• Gardez une alerte de régression active : si une page ralentit après un ajout de promotion ou un pic, vous le savez avant vos clients.
• Comparez à l'état de départ mesuré au début : c'est lui qui dit si l'opération se passe normalement.

Checklist Black Friday PrestaShop

1. Mesurer les pages clés avant de toucher à quoi que ce soit.
2. Corriger d'abord les requêtes et modules lents du panier et de la commande.
3. Installer et valider les caches (HTTP et SQL) plusieurs jours avant.
4. Geler les changements avant l'opération.
5. Surveiller en continu, avec une alerte de régression.

Questions fréquentes sur le Black Friday et PrestaShop

Quand commencer à préparer sa boutique PrestaShop ?

Dès que possible : un mois avant, il reste le temps de mesurer, de corriger et d'observer les caches sur du trafic réel. La veille, il ne reste que de quoi constater.

Pourquoi le panier et la commande ralentissent-ils en premier ?

Ces pages sont propres à chaque visiteur : elles ne peuvent pas être servies telles quelles depuis un cache de page, et chaque module de promotion, de livraison ou de paiement y ajoute son traitement. Un cache de requêtes SQL, comme le Database Cache, agit sur ces pages.

Un cache peut-il afficher le panier d'un autre client ?

Il ne doit jamais le faire : le cache de pages ne doit servir que les pages publiques (accueil, catégories, produits). Vérifiez-le avant l'opération, en testant avec deux sessions différentes.

Faut-il geler les mises à jour avant le Black Friday ?

Oui, quelques jours avant. Une mise à jour de module est une cause fréquente de régression, et mieux vaut une alerte avant l'opération que pendant.

Pour mesurer votre boutique avant le Black Friday, Scalizy s'essaie 15 jours gratuitement, avec un audit de performance offert à l'installation.