Black Friday 2026 : la checklist d’une boutique WooCommerce (testée)

Le Black Friday tombe le vendredi 27 novembre 2026, et le Cyber Monday le lundi 30. Il reste trois semaines pour vérifier ce qui coûte cher quand ça casse ce jour-là : un prix barré illégal, des e-mails de commande refusés par Gmail, une promo qui démarre en retard, un paiement qui rame, une mise à jour qui tombe le mauvais jour.

Nous avons tout vérifié sur une boutique de test (WooCommerce 11.2.2, WordPress 7.1.4, en français) plutôt que de recopier les listes habituelles. Quatre surprises en sont sorties :

• WooCommerce affiche sans broncher un prix barré gonflé : il ne connaît pas la règle des 30 jours ;
• une promo programmée « le 27 » peut démarrer à 1 h du matin, selon un réglage que personne ne regarde ;
• sur le thème par défaut, le mini-panier interroge le serveur à chaque page vue, même panier vide : le cache n’y peut rien ;
• geler les mises à jour de WooCommerce et des extensions de paiement tient en une quinzaine de lignes, testées plus bas.

La checklist en bref

À faire avant le 20 novembre, dans cet ordre :

1. Prix barrés : le prix de référence est le plus bas des 30 derniers jours. WooCommerce ne le calcule pas, c’est à vous de le vérifier.
2. Bouton de rétractation activé et testé, CGV à jour.
3. Paiement en plusieurs fois : vérifier les mentions avec votre prestataire, les règles changent le 20 novembre.
4. E-mails : envoi par un SMTP authentifié, SPF, DKIM et DMARC en place, désabonnement en un clic sur les newsletters.
5. Fuseau horaire de WordPress réglé sur Paris avant de programmer les promos.
6. Promos programmées : vérifier que les actions planifiées passent bien.
7. Charge : exclusions de cache testées avec un vrai panier, nombre de PHP workers demandé à l’hébergeur, file des actions planifiées vidée.
8. HPOS et limitation du débit du paiement : vérifier l’état dans les réglages.
9. Gel des mises à jour à partir du 10 novembre, sauvegarde complète juste avant.
10. Commande test réelle le 26 novembre au soir, avec un vrai moyen de paiement.

Le détail de chaque point suit.

1. Le prix barré : la règle des 30 jours que WooCommerce ignore

Depuis mai 2022, une annonce de réduction doit indiquer comme prix de référence le prix le plus bas pratiqué au cours des 30 jours qui précèdent la réduction (article L112-1-1 du Code de la consommation). Monter un prix début novembre pour afficher « -40 % » le 27 est donc interdit.

Il n’y a que trois exceptions : les réductions successives pendant une même opération (le prix de référence reste celui d’avant la première baisse), les produits périssables, et les comparaisons avec le prix d’un concurrent, qui obéissent à d’autres règles. Il n’existe pas d’exception pour un produit en vente depuis moins de 30 jours. Le pourcentage affiché doit lui aussi être calculé sur ce prix de référence (Cour de justice de l’Union européenne, arrêt Aldi Süd du 26 septembre 2024).

Une réduction calculée sur un faux prix de référence est une pratique commerciale trompeuse. Depuis 2024, quand elle est commise en ligne, la peine maximale est de 5 ans de prison et 750 000 € d’amende (article L132-2), et le montant de l’amende est multiplié par cinq pour une société. Les sanctions ne restent pas théoriques : en 2025, Shein a été condamnée à 40 millions d’euros d’amende pour de fausses réductions, et PrettyLittleThing a accepté de payer 1,3 million d’euros.

Ce que nous avons testé. Notre mug était vendu 19,90 €. Nous avons passé son tarif régulier à 24,90 € puis activé une promo à 14,90 €. WooCommerce a affiché 24,90 € barré et le badge « Promo ! », sans le moindre avertissement :

C’est logique : WooCommerce barre le tarif régulier du moment et ne garde aucun historique des prix. Le contrôle des 30 jours est entièrement de votre responsabilité.

Ce qu’il faut faire :

• ne touchez plus aux tarifs réguliers des produits soldés à partir de fin octobre ;
• notez aujourd’hui le prix de chaque produit concerné (un export CSV des produits depuis Produits > Tous les produits > Exporter suffit) : c’est votre preuve en cas de contrôle ;
• si un prix a bougé dans les 30 jours, mettez comme tarif régulier le plus bas des deux, quitte à afficher une réduction plus faible ;
• les extensions de type « historique des prix » ou « Omnibus » enregistrent le prix le plus bas et peuvent l’afficher : utiles si vous changez souvent vos prix, superflues sinon.

2. Rétractation, CGV et paiement en plusieurs fois

Le bouton de rétractation est obligatoire depuis le 19 juin 2026 pour toute vente en ligne à des particuliers. WooCommerce le gère nativement depuis la version 11.1, sans extension : nous avons détaillé le réglage et les pièges dans notre guide bouton de rétractation WooCommerce. À vérifier avant le pic : la page dédiée existe, le lien est visible dans le pied de page et dans les e-mails de commande, et une demande test arrive bien.

Les CGV doivent mentionner l’existence et l’emplacement de cette fonction de rétractation. Profitez-en pour relire les délais de livraison annoncés : ils seront intenables le 30 novembre si votre transporteur sature.

Le paiement en plusieurs fois (Alma, Klarna, Oney, PayPal 4X…) change de statut le 20 novembre 2026, une semaine avant le Black Friday. Jusqu’ici, un paiement en 3 ou 4 fois sans frais, remboursé en moins de trois mois, échappait au droit du crédit à la consommation. À partir du 20 novembre, il y entre, avec un régime allégé (ordonnance du 3 septembre 2025, qui transpose la directive européenne 2023/2225).

L’essentiel des nouvelles obligations pèse sur le prêteur : c’est lui qui vérifie la solvabilité du client et lui remet les informations avant le contrat. Mais ce que vous affichez compte comme de la publicité pour un crédit. Un bandeau « Payez en 3x sans frais » sur une fiche produit doit désormais porter la mention « Attention ! Un crédit coûte de l’argent et doit être remboursé », et toute formule qui présente le crédit comme facile à obtenir est interdite. Demandez à votre prestataire si son extension WooCommerce affiche déjà la bonne mention, et retirez les bandeaux maison qui ne l’ont pas.

3. Les e-mails : Gmail et Outlook ne se contentent plus du dossier spam

Depuis février 2024, Gmail et Yahoo exigent de tout expéditeur, y compris pour un simple e-mail de commande, une authentification SPF ou DKIM. Au-delà de 5 000 e-mails par jour vers Gmail, il faut les deux, plus un enregistrement DMARC, une adresse d’expéditeur alignée sur le domaine authentifié, un désabonnement en un clic sur les e-mails marketing et un taux de plaintes pour spam sous 0,3 %. Et le statut d’« expéditeur en masse » n’expire pas : un seul gros envoi suffit pour y entrer définitivement.

Ce qui change pour ce Black Friday : depuis novembre 2025, Gmail ne se contente plus de classer en spam, il refuse une partie des messages non conformes. Microsoft (Outlook.com, Hotmail, Live) applique les mêmes exigences depuis mai 2025 et rejette les envois non conformes avec l’erreur 550 5.7.515. Un e-mail refusé ne finit pas dans les indésirables : il n’arrive pas du tout, et votre client croit que sa commande n’est pas passée.

Le piège WooCommerce. Par défaut, WooCommerce envoie ses e-mails avec la fonction wp_mail() de WordPress, donc par le serveur d’hébergement, souvent sans signature DKIM et parfois avec une adresse d’expéditeur qui ne correspond pas au domaine. WooCommerce le dit lui-même dans ses réglages : il recommande de « connecter votre adresse e-mail à votre domaine et de configurer un serveur SMTP dédié ».

Ce qu’il faut faire :

• dans WooCommerce > Réglages > E-mails, mettez une adresse de votre domaine ([email protected]), jamais une adresse Gmail ou celle de l’hébergeur ;
• faites passer les envois par un SMTP authentifié : celui de votre messagerie ou un service d’envoi (Brevo, Mailjet, Amazon SES…), avec une extension comme WP Mail SMTP ou FluentSMTP ;
• vérifiez dans la zone DNS de votre domaine les trois enregistrements SPF, DKIM et DMARC (au minimum v=DMARC1; p=none; sur _dmarc.votredomaine.fr) ;
• envoyez-vous une commande test vers une adresse Gmail, puis « Afficher l’original » : les lignes SPF, DKIM et DMARC doivent toutes indiquer PASS ;
• pour la newsletter du Black Friday, vérifiez que votre outil ajoute bien le désabonnement en un clic, et n’écrivez qu’aux clients actifs ces derniers mois.
• si votre outil d’e-mailing mesure les ouvertures avec un pixel invisible, il faut désormais le consentement du destinataire (recommandation de la CNIL publiée en avril 2026) : vérifiez que la case existe à l’inscription et qu’un lien de retrait figure en bas de chaque e-mail, sinon coupez le suivi des ouvertures.

4. Programmer ses promos sans mauvaise surprise

WooCommerce sait programmer une promo : dans la fiche produit, à côté du tarif promo, le lien « Planifier » ouvre deux dates de début et de fin.

Premier piège : le fuseau horaire. WooCommerce enregistre ces dates en heure universelle, d’après le fuseau réglé dans Réglages > Général. Sur notre boutique, le fuseau était resté sur UTC : la promo « du 27 au 30 » commençait donc à 1 h du matin, heure de Paris, et finissait le 1er décembre à 0 h 59. Changer le fuseau après coup ne corrige rien : les promos déjà programmées gardent leur heure. Réglez le fuseau sur Paris avant toute chose, puis programmez.

Notez aussi que la date de fin est incluse : une promo « jusqu’au 30 » dure jusqu’au 30 à 23 h 59.

Second piège : ce sont des tâches de fond. Chaque promo programmée crée deux actions dans WooCommerce > État > Actions planifiées : une pour le début, une pour la fin.

Ces actions ne partent que si la file tourne. Sur un site où WP-Cron ne se déclenche qu’au passage des visiteurs, ou dont la file est engorgée, la promo démarre en retard. Le 27 au matin, ouvrez cette page et vérifiez que les actions wc_product_start_scheduled_sale sont passées en « Terminé ».

Pour une grosse opération (tout le catalogue à -20 %), un code promo ou une règle de remise globale est souvent plus sûr que des centaines de promos programmées produit par produit : une seule chose à activer, et à couper.

5. Tenir la charge : ce que le cache ne protège pas

Le cache de page (LiteSpeed Cache, WP Rocket…) sert des pages toutes prêtes aux visiteurs qui regardent. Mais le panier, la commande, Mon compte et chaque ajout au panier passent forcément par PHP et par la base de données. Le jour du Black Friday, la vraie limite est le nombre de processus PHP que votre hébergement peut faire tourner en même temps (les « PHP workers »).

WooCommerce prévoit ce cas : sur les pages Panier, Commande et Mon compte déclarées dans ses réglages, il demande aux extensions de cache de ne pas les garder (constante DONOTCACHEPAGE et en-têtes « no-cache »). LiteSpeed Cache les exclut automatiquement. Mais un cache serveur ou un CDN peut ignorer ces consignes, et un panier mis en cache par erreur affiche le panier d’un autre client : c’est à tester, pas à supposer.

Le mini-panier, client invisible. Nous avons observé ce que fait une page de la boutique de test (thème Twenty Twenty-Five, mini-panier dans l’en-tête). À chaque page vue, y compris par un nouveau visiteur au panier vide, le navigateur appelle /wp-json/wc/store/v1/cart pour remplir le mini-panier. Cette requête n’est jamais servie par le cache de page : 1 000 pages vues, ce sont 1 000 passages par PHP. Sur un thème classique, l’équivalent est le script « cart fragments ».

Ce script n’est plus chargé partout depuis WooCommerce 7.8 : seulement quand le widget Panier classique s’affiche, ou si votre thème l’impose. Dans les deux cas, retenez la règle : un mini-panier dans l’en-tête, c’est une requête PHP par page vue. Si votre serveur peine déjà en temps normal, une page d’atterrissage Black Friday sans mini-panier allège nettement la charge.

Les actions planifiées, deuxième embouteillage. Sur notre boutique nue, une seule commande par chèque a déclenché 3 actions en arrière-plan. Chaque extension (paiement, e-mailing, avis clients, synchronisation de stock, facturation) en ajoute. Un soir de Black Friday, la file peut prendre des heures de retard, et avec elle les e-mails de commande différés et les promos programmées.

Par défaut, Action Scheduler (le moteur des actions planifiées) traite les actions par lots de 25, pendant 30 secondes par passage, un seul passage à la fois, et marque en échec toute action qui tourne depuis plus de 5 minutes. Pour vider un arriéré, la commande WP-CLI suivante traite toute la file par lots de 100 :

wp action-scheduler run --batches=0

Et si votre hébergement propose des tâches cron (c’est le cas de la plupart des offres mutualisées), remplacez WP-Cron, qui ne se déclenche qu’au passage des visiteurs, par une vraie tâche planifiée. Dans wp-config.php :

define( 'DISABLE_WP_CRON', true );

Puis, dans le gestionnaire de tâches cron de l’hébergeur, une tâche toutes les 5 minutes (le chemin est celui de votre site) :

cd /chemin/vers/votre/site && wp cron event run --due-now

Ce qu’il faut faire :

• demandez à votre hébergeur combien de PHP workers votre offre autorise, et s’il peut l’augmenter temporairement ;
• testez les exclusions de cache avec un vrai panier : ajoutez un produit, naviguez, vérifiez que le panier et la commande affichent bien votre contenu, dans une fenêtre privée ;
• passez une commande test et comptez les actions créées dans WooCommerce > État > Actions planifiées ; videz l’arriéré « En attente » avant le 27 ;
• si votre hébergeur le permet, remplacez WP-Cron par une tâche cron système (détail ci-dessous) ;
• coupez ce qui ne sert pas pendant le pic : extension de statistiques en doublon, avis clients en temps réel, popups lourdes.

6. HPOS et limitation du débit : deux réglages à vérifier

Dans WooCommerce > Réglages > Avancé > Fonctionnalités, deux lignes méritent un coup d’œil :

Stockage des commandes haute performance (HPOS). Il range les commandes dans des tables dédiées plutôt que dans celles des articles de WordPress, ce qui accélère leur enregistrement et leur recherche. Il est activé par défaut sur les boutiques créées depuis WooCommerce 8.2 (octobre 2023), comme la nôtre, mais les boutiques plus anciennes ne sont pas migrées automatiquement. Si chez vous c’est « Stockage des publications WordPress (ancien) » qui est coché, notez-le, mais ne migrez pas maintenant : une migration se fait au calme, en janvier, après avoir vérifié que toutes vos extensions sont compatibles.

Limitation du débit Checkout. Désactivée par défaut sur notre boutique, elle limite le nombre de tentatives de commande qu’un même visiteur peut envoyer. Elle sert surtout contre le « card testing » : des robots qui essaient des numéros de cartes volées sur votre page de paiement, ce qui vous coûte des frais et peut faire suspendre votre compte de paiement. Les périodes de forte affluence sont celles où ces attaques passent le plus inaperçues. Activez-la, puis passez une commande test pour vérifier qu’un client normal n’est pas bloqué.

7. Geler les mises à jour du 10 novembre au début janvier

Une mise à jour de WooCommerce ou d’une extension de paiement le 26 novembre au soir, c’est le pire scénario : personne ne l’a testée, et le support est débordé. La pratique des boutiques prudentes : plus aucune mise à jour non urgente du 10 novembre au début janvier, sauf correctif de sécurité.

Le calendrier s’y prête : WooCommerce 11.3 sort la semaine du 9 novembre, et WordPress 7.2 est attendu entre le 8 et le 10 décembre. Deux versions majeures à laisser passer, et à installer en janvier, une fois leurs premiers correctifs sortis.

Deux réglages suffisent : couper les mises à jour automatiques des extensions sensibles, et limiter WordPress à ses versions de sécurité. Pour le second, la méthode classique est une ligne dans wp-config.php : define( 'WP_AUTO_UPDATE_CORE', 'minor' );. Si vous préférez ne pas toucher à ce fichier, un filtre fait la même chose.

Nous avons testé ce code sur la boutique, ajouté avec l’extension Code Snippets (il marche aussi dans une extension « must-use » ou dans le functions.php d’un thème enfant) :

// Gel des mises à jour pendant le Black Friday : à désactiver début janvier.
// 1. Pas de mise à jour automatique pour WooCommerce et les extensions de paiement.
add_filter( 'auto_update_plugin', function ( $update, $item ) {
	$gel = array(
		'woocommerce',
		'woocommerce-payments',
		'woocommerce-gateway-stripe',
		'woocommerce-paypal-payments',
	);
	if ( isset( $item->slug ) && in_array( $item->slug, $gel, true ) ) {
		return false;
	}
	return $update;
}, 10, 2 );

// 2. WordPress : seulement les versions de maintenance et de sécurité (7.1.x), pas la 7.2.
add_filter( 'allow_major_auto_core_updates', '__return_false' );

Adaptez la liste $gel à vos extensions : le nom à mettre est celui du dossier de l’extension dans wp-content/plugins. Résultat dans Extensions : la colonne affiche « Mises à jour auto désactivées » pour WooCommerce, et le lien pour les réactiver disparaît.

Et dans Tableau de bord > Mises à jour, WordPress annonce qu’il ne prendra plus que les versions de maintenance et de sécurité :

Les correctifs de sécurité de WordPress (7.1.5, 7.1.6…) continuent donc de passer, ce qui est voulu. Pour les extensions gelées, gardez un œil sur les alertes de sécurité : une faille corrigée en urgence se met à jour à la main, après sauvegarde.

Juste avant le gel, faites les mises à jour en attente, sur une copie du site si votre hébergeur en propose une, puis une sauvegarde complète (fichiers et base de données) que vous savez restaurer.

8. Le jour J et les jours qui suivent

• Le 26 au soir : une vraie commande, avec un vrai moyen de paiement, puis remboursement. C’est le seul test qui vérifie tout le parcours, e-mails compris.
• Le 27 au matin : promos actives, actions planifiées « Terminé », page /black-friday en ligne. Gardez la même adresse d’une année sur l’autre : elle conserve ses liens et son ancienneté dans Google.
• Pendant le pic : surveillez les commandes en attente de paiement et les e-mails non reçus signalés par les clients.
• Après : les litiges et rétrofacturations du Black Friday arrivent des semaines plus tard. Gardez les preuves de livraison.

En résumé

Le Black Friday d’une boutique WooCommerce se prépare surtout sur trois fronts que la plupart des checklists oublient : la légalité du prix barré, que WooCommerce ne contrôle pas, la délivrabilité des e-mails, que Gmail et Outlook ont durcie, et ce qui se passe derrière le cache, où se jouent vraiment le panier et le paiement. Le reste, gel des mises à jour compris, tient en une après-midi de réglages.

Testé le 5 novembre 2026 sur une boutique de test : WordPress 7.1.4, WooCommerce 11.2.2, thème Twenty Twenty-Five, PHP 8.3.