Black Friday 2026 : votre checklist de préparation PrestaShop

Dernière vérification en juin 2026 pour la saison à venir. Dates confirmées : Black Friday 2026 = vendredi 27 novembre ; Cyber Monday = 30 novembre. Les chemins du back-office s’appliquent à PrestaShop 1.7, 8 et 9.

Le Black Friday 2026 tombe le vendredi 27 novembre, avec le Cyber Monday le 30 novembre — le pic de quatre jours s’étendra donc du 27 au 30 novembre, et la vraie fenêtre de préparation commence fin septembre. Les boutiques qui s’en sortent le mieux ne sont pas celles qui affichent les remises les plus agressives ; ce sont celles dont l’installation PrestaShop a été testée en charge, gelée et répétée avant l’arrivée de la première vague de trafic. Voici un compte à rebours semaine par semaine, utilisable quel que soit le vendredi où tombe le Black Friday — en 2026, par exemple, ce sera le 27 novembre — avec ce qu’il faut faire, quand le faire, et où le faire précisément dans le back-office PrestaShop.

Ce plan reste volontairement centré sur son rôle. La façon de construire les remises, de programmer les ventes flash et de récupérer les paniers fait l’objet de guides détaillés ailleurs dans ce cluster — cet article est le calendrier qui vous indique quand actionner chaque levier, avec les étapes de préparation propres à PrestaShop que les guides marketing considèrent comme déjà acquises.

Le compte à rebours 2026 en un coup d’œil

Ancrez chaque tâche sur le 27 novembre et remontez le calendrier. Les dates ci-dessous sont des échéances, pas des suggestions — la plupart des incidents le jour J viennent d’une étape compressée dans la dernière semaine alors qu’elle exigeait une marge de sécurité.

8 semaines avant (début octobre) : poser les bonnes bases

Le trafic du Black Friday atteint souvent plusieurs fois votre volume habituel — c’est une indication, pas une promesse, et vos propres données analytics de novembre dernier restent la seule base honnête. L’intérêt de commencer ici, c’est que les travaux de capacité et de performance ne peuvent pas être précipités sans risque dans la dernière semaine, car chaque changement peut introduire un bug que vous n’aurez plus le temps de détecter.

Testez la charge avant d’optimiser

Ne devinez pas où votre boutique casse — mesurez-le. Des outils comme k6 ou Loader.io peuvent simuler des centaines d’utilisateurs simultanés sur vos pages catégorie, produit et commande. Lancez le test sur une copie de préproduction, pas en production, et observez où les temps de réponse grimpent : une base de données parfaitement stable à 20 utilisateurs simultanés peut s’effondrer à 300. Le tunnel de commande (le contrôleur commande) est la page qui ne doit surtout pas tomber — testez-la spécifiquement en charge, avec des articles qui vont réellement jusqu’à la confirmation de commande.

Activez les réglages de performance déjà fournis par PrestaShop

La plupart de ce dont vous avez besoin se trouve dans le back-office sous Paramètres avancés → Performances. Ne partez pas du principe que c’est activé — vérifiez chaque point :

• Cache Smarty : réglez le cache sur Oui et la compilation des templates sur « Ne jamais recompiler ». Recompiler les templates à chaque requête pendant un pic de trafic consomme du CPU que vous ne pouvez pas vous permettre de gaspiller.
• CCC (Combiner, Compresser, Mettre en Cache) : activez « Cache intelligent pour les feuilles de style » et « Cache intelligent pour le code JavaScript » afin que le navigateur télécharge moins de fichiers, et des fichiers plus légers. Testez ensuite le front-office — CCC peut parfois entrer en conflit avec un thème mal construit, et mieux vaut le découvrir maintenant que le 27 novembre.
• OPcache : confirmez qu’il fonctionne réellement, pas seulement qu’il est installé. Vérifiez son état avec les outils de votre hébergement/serveur ou une page de statut phpinfo/OPcache plutôt que de vous fier uniquement à l’écran Performances de PrestaShop ; s’il est désactivé, une modification serveur ne prendra effet qu’après purge. Vérifiez, puis n’y touchez plus.
• Mise en cache (Redis/Memcached) : dans « Cache » sur la même page, vous pouvez orienter le cache de PrestaShop vers Redis ou Memcached si votre hébergeur le propose — même si, selon votre version, cela nécessite souvent une configuration serveur ou module pour fonctionner. C’est l’un des leviers les plus puissants pour soulager une base de données sous pression avec des paniers simultanés. Déplacer les sessions hors du disque est une tâche distincte : cela se configure au niveau serveur/PHP (ou via un module), pas avec ce réglage de cache.

Allégez aussi vos médias : les images produit surdimensionnées sont le tueur de vitesse le plus discret lorsque des milliers de visiteurs naviguent en même temps. Compressez-les et redimensionnez-les maintenant, tant que vous avez le temps de contrôler le résultat.

6 semaines avant (mi-octobre) : mettre à jour, puis préparer le gel

Mettez à jour le cœur de PrestaShop, chaque module et votre thème maintenant — pas la semaine précédente. Les mises à jour peuvent introduire des comportements inattendus, et toute la raison de s’y prendre six semaines à l’avance est de vous donner plusieurs semaines de marge pour repérer et corriger ce qui casse. Faites d’abord les mises à jour sur une copie de préproduction, parcourez le tunnel de commande et passez une commande de test, puis déployez en production.

La discipline la plus importante : prévoir un gel strict du code au 1er novembre. Après cette date, pas d’installation de module, pas de modification de thème, pas de changement du cœur, sauf vraie urgence. Chaque « petite retouche rapide » en novembre est une occasion de casser la commande au moment où vous avez le moins de temps pour vous en apercevoir. Prévenez à l’avance toutes les personnes ayant accès au back-office afin que la date de gel ne surprenne personne.

4 semaines avant (fin octobre) : créer et tester les remises en préproduction

C’est ici que les commerçants mélangent souvent deux tâches différentes. Concevoir l’offre — profondeur de remise, pourcentage ou montant fixe, paliers, lots — relève de la stratégie, traitée dans lancer une promotion dans PrestaShop : règles panier, prix spécifiques et stratégies de remise, et la règle de base pour protéger la marge est expliquée dans exclusion des remises : pourquoi certains produits ne devraient jamais être soldés. Ce qui relève d’ici, dans cette checklist, c’est l’étape de préparation : créer ce que vous avez décidé, dans une copie de préproduction, et prouver que cela s’applique correctement avant que la moindre remise touche un panier réel.

Dans PrestaShop, vous disposez de deux mécanismes : Catalogue → Réductions → Règles panier (bons de réduction, conditions, codes automatiques) et Catalogue → Réductions → Règles de prix catalogue / Prix spécifiques par produit (un prix barré affiché directement sur la fiche produit). Ce qu’il faut vérifier, avec de vrais paniers de test :

• La remise s’applique bien aux produits prévus — et pas à ceux que vous avez exclus.
• Les remises ne se cumulent pas d’une façon qui détruit votre marge. Une règle panier, plus une règle de prix catalogue, plus une réduction de groupe client peuvent se composer silencieusement.
• Les seuils de livraison gratuite et les conditions de panier minimum se déclenchent au bon montant, taxes incluses lorsque votre boutique les affiche.
• Les champs « Quantité disponible » et les dates d’une règle panier se comportent comme prévu — un bon de réduction épuisé ou expiré en plein week-end devient vite un cauchemar pour le support.

Les bugs de remise pendant le Black Friday coûtent cher et nuisent autant à votre image qu’à votre marge. La solution est peu spectaculaire : les tester quatre semaines avant, en préproduction, avec une checklist.

Décidez ce qui tourne au minuteur et ce qui reste manuel

Vous ne voulez pas modifier les prix à la main à 6 h du matin le 27. Les règles panier et les prix spécifiques de PrestaShop disposent tous deux de plages de dates « du / au », ce qui permet de configurer une offre plusieurs semaines à l’avance et de la laisser démarrer à l’heure prévue sans intervention. Pour les mécanismes qui permettent aux promotions de commencer et de s’arrêter seules — et les pièges liés aux fuseaux horaires serveur — consultez remises programmées : configurer des promotions qui commencent et s’arrêtent automatiquement. Si votre plan prévoit de faire tourner les offres pendant le week-end plutôt que de lancer une seule promotion statique, la partie automatisation est couverte dans préparation du Black Friday : automatiser les remises et promotions dans PrestaShop, et notre module Sales Revolution gère les ventes flash programmées pour que la rotation fonctionne sans surveillance permanente. Le cadrage honnête des tactiques d’urgence — comptes à rebours, « jusqu’à épuisement des stocks » — se trouve dans ventes flash : créer l’urgence sans manipulation.

2 semaines avant (mi-novembre) : programmer, répéter et préparer les flux

Avec le gel en place et les remises testées, cette quinzaine sert à programmer et répéter, pas à construire.

• Définissez les dates de mise en ligne. Saisissez le début au 27 nov. et la fin au 30 nov. (ou au 1er déc.) sur chaque règle panier et chaque prix spécifique. Revérifiez le fuseau horaire de la boutique sous International → Localisation → Localisation — une offre réglée sur « minuit » se déclenche à l’heure du serveur, qui n’est pas forcément le minuit de vos clients.
• Créez la destination d’arrivée. Une catégorie ou page CMS dédiée au Black Friday est l’endroit où atterrissent le trafic de vos emails et de vos publicités. Créez-la maintenant (en la gardant non indexée ou non publiée jusqu’au lancement si vous préférez), afin que le jour J vous n’ayez qu’un interrupteur à activer, pas une page à construire sous pression.
• Des bannières sans graphiste. Les visuels héro/promo qui annoncent l’opération n’exigent pas forcément une agence de design — voir banner revolution : créer des promotions accrocheuses sans graphiste.
• Flux Google Merchant Center. Si vous diffusez des annonces Shopping, renseignez les attributs sale_price et sale_price_effective_date afin que Google affiche le prix barré pendant la période concernée. Soumettez tôt ; le retraitement d’un flux n’est pas instantané.
• Répétition complète. Parcourez un trajet complet comme un client : arrivez sur la page Black Friday, ajoutez un produit remisé, appliquez un bon de réduction si vous utilisez des codes, allez jusqu’à la confirmation de commande. Puis refaites-le sur mobile. Cette seule répétition détecte plus de vrais problèmes que n’importe quel item de checklist.

1 semaine avant (~20 novembre) : préparation opérationnelle

Le code est gelé et testé ; assurez-vous maintenant que l’activité derrière peut suivre.

• Stocks. Vérifiez les niveaux de stock sous Catalogue → Stocks pour tous les produits mis en avant. Vendre plus que le stock disponible puis annuler des commandes abîme la confiance bien plus durablement que manquer une vente. Décidez délibérément, produit par produit, du comportement en rupture de stock (refuser / autoriser la commande en réapprovisionnement).
• Sauvegardes. Effectuez une sauvegarde complète de la base de données et des fichiers la veille, et confirmez que vous pouvez réellement la restaurer. Une sauvegarde jamais testée est un espoir, pas un filet de sécurité. Paramètres avancés → Base de données → Sauvegarde BDD dans PrestaShop couvre la base de données ; votre hébergeur ou une procédure dédiée doit couvrir les fichiers.
• Supervision. Orientez un outil de surveillance de disponibilité (UptimeRobot, Pingdom) vers votre page d’accueil et une page profonde comme la commande, afin d’être alerté en quelques minutes si le site trébuche — pas lorsqu’un client vous écrit.
• Support & livraison. Confirmez les dates limites des transporteurs et prévoyez une couverture de support étendue. Préparez à l’avance les réponses aux questions prévisibles : « mon code fonctionne-t-il ? », « quand ma commande arrivera-t-elle ? », « quelle est la politique de retour ? ». Afficher des attentes de livraison réalistes au moment de la commande est exactement le rôle d’un affichage automatisé des délais estimés.

Le week-end lui-même (27–30 novembre) : exécuter et surveiller

Si vous avez fait le travail ci-dessus, le week-end relève surtout de l’observation. Vos offres programmées se lancent toutes seules ; votre rôle est de détecter vite les anomalies.

• Confirmez que les offres se sont déclenchées. Dès le matin du 27, chargez le front-office comme un client et vérifiez que les prix remisés s’affichent bien. Un décalage de fuseau horaire est le classique coup de panique de 6 h du matin.
• Surveillez les bons tableaux de bord. Gardez un œil sur la charge serveur, les taux d’erreur et la finalisation des commandes. Dans Google Analytics 4, suivez les conversions en temps réel — une chute brutale signifie généralement que quelque chose a cassé, pas que la demande a disparu.
• Gardez des temps de réponse honnêtes. Si la charge monte, vous disposez de la marge construite en octobre. Résistez à l’envie d’« installer vite un module de cache » en plein week-end — c’est exactement le type de changement que le gel devait empêcher.
• Récupérez ce qui fuit. Même un week-end parfait laisse partir des paniers. Les séquences de relance de panier abandonné et de suivi post-achat qui en récupèrent une partie valent la peine d’être prêtes — et elles relèvent d’une campagne, pas d’un simple item de checklist, donc planifiez-les dans votre calendrier de promotions saisonnières plus large.

Après le week-end : capitaliser sur ce que vous avez appris

Le Black Friday n’est pas un événement isolé — c’est l’ouverture tonitruante d’une saison qui se poursuit jusqu’à Noël puis vers la planification de la nouvelle année. Avant que la poussière ne retombe, consignez les chiffres pendant qu’ils sont frais : quels produits se sont vendus, quels canaux ont généré du chiffre d’affaires, où la boutique a montré ses limites, et quel mécanisme de remise a réellement fait avancer les commandes. Ce document sera votre avance pour l’année suivante — et c’est ainsi qu’un premier Black Friday chaotique devient une opération calme et reproductible.

Le schéma de fond reste le même chaque année : la victoire se joue dans les semaines précédentes, en préproduction, sous test de charge, derrière un gel du code. La date de 2026 est fixée au 27 novembre. Tout le reste consiste simplement à remonter le calendrier depuis cette date, avec assez de marge pour corriger ce que vous trouverez.

Questions fréquentes

Quelle est la date du Black Friday 2026, et quand faut-il commencer ?

Le Black Friday 2026 aura lieu le vendredi 27 novembre ; le Cyber Monday tombe le 30 novembre. Remontez le calendrier : socle technique et tests de charge environ 8 semaines avant (début octobre), mises à jour 6 semaines avant, remises créées et testées en préproduction 4 semaines avant, gel du code le 1er novembre, programmation et répétitions deux semaines avant, puis préparation opérationnelle (stocks, sauvegardes, supervision) la semaine du 20 novembre.

Une offre programmée pour « minuit » s’est lancée à la mauvaise heure. Pourquoi ?

PrestaShop évalue les champs « valable du / au » de la règle panier selon le fuseau horaire de la boutique, défini sous International → Localisation → Localisation — c’est l’heure serveur, pas nécessairement le minuit local de vos clients. Vérifiez ce réglage avant le week-end, et saisissez vos dates en tenant compte du décalage. Ce décalage de fuseau horaire est le classique coup de panique de 6 h du matin le 27.

Faut-il créer les remises en production ou sur une copie de préproduction ?

En préproduction, toujours. Créez et prouvez d’abord que les remises s’appliquent correctement — et ne s’appliquent pas à vos produits exclus — sur une copie, puis transférez la configuration testée en production. Les tests de charge doivent eux aussi se faire sur la préproduction, pas sur la boutique en ligne, afin qu’un test poussant des centaines de commandes simultanées ne fasse pas tomber le trafic réel.

Puis-je installer un module de cache en plein week-end si le site ralentit ?

Non — c’est précisément ce que le gel du code vise à éviter. Un nouveau module pendant le pic de trafic est le changement le plus risqué que vous puissiez faire, avec le moins de temps possible pour détecter une régression dans la commande. Construisez votre marge en octobre. Si la charge augmente le jour J, appuyez-vous sur le cache et la capacité que vous avez déjà testés, surveillez la finalisation des commandes et résistez au « correctif rapide ».

Ai-je besoin d’un stockage de sessions séparé si je déplace le cache vers Redis ?

Oui — ce sont deux tâches différentes. Orienter le cache objet de PrestaShop vers Redis ou Memcached (sous Paramètres avancés → Performances → Cache) réduit la charge de la base de données, mais déplacer les sessions PHP hors du système de fichiers se configure séparément au niveau serveur/PHP ou via un module. Régler l’un ne règle pas l’autre ; prévoyez les deux si votre niveau de concurrence le justifie.