---
title: "Préparer son site au Black Friday : tenir le pic de trafic"
description: "Préparer son site au Black Friday : estimer le pic, faire un test de charge, mettre en cache, renforcer le paiement et le stock, et suivre notre plan J-21."
canonical_url: "https://studiofogg.fr/journal/preparer-son-site-au-black-friday"
---

> Index of every page on this site: [llms.txt](https://studiofogg.fr/llms.txt)

Préparer son site au Black Friday, c’est s’assurer qu’il tiendra un pic de trafic connu d’avance, au moment où il doit vendre le plus : estimer ce pic, le simuler par un test de charge, mettre en cache tout ce qui peut l’être, prévoir la montée en charge, renforcer les maillons fragiles et organiser le jour J. Le Black Friday tombe cette année le vendredi 27 novembre 2026. Nous publions ce guide le 4 novembre, un peu plus de trois semaines avant : le temps de suivre le plan J-21 proposé à la fin. La méthode vaut aussi pour Noël et les soldes, et prolonge [nos conseils pour un site rapide, sûr et qui dure](https://studiofogg.fr/journal/rubrique/projet-web-budget-methode).

## Estimer le pic à partir de vos propres chiffres

Un test n’a de sens que s’il vise un chiffre, tiré de vos données : visites de l’heure la plus chargée du dernier Black Friday, commandes par quart d’heure, requêtes par seconde relevées par l’hébergeur, clics dans la première heure de votre dernière newsletter. Ce qui fait céder un serveur, ce sont les visiteurs simultanés : multipliez les visites de l’heure de pointe par la durée moyenne d’une visite en minutes, puis divisez par 60. Pour une boutique fictive :

<table>
<thead>
  <tr>
    <th>
      Étape
    </th>
    
    <th>
      Exemple
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      Visites de l’heure la plus chargée, l’an dernier
    </td>
    
    <td>
      3 000
    </td>
  </tr>
  
  <tr>
    <td>
      Durée moyenne d’une visite
    </td>
    
    <td>
      4 minutes
    </td>
  </tr>
  
  <tr>
    <td>
      Visiteurs simultanés
    </td>
    
    <td>
      3 000 × 4 ÷ 60 = 200
    </td>
  </tr>
  
  <tr>
    <td>
      Hausse attendue cette année
    </td>
    
    <td>
      + 30 %, soit 260
    </td>
  </tr>
  
  <tr>
    <td>
      Objectif du test, marge comprise (× 2)
    </td>
    
    <td>
      520 visiteurs simultanés
    </td>
  </tr>
</tbody>
</table>

Raisonnez aussi au quart d’heure : si 1 000 de ces visites arrivent dans les quinze minutes qui suivent une newsletter, le calcul devient 1 000 × 4 ÷ 15, soit environ 267 visiteurs simultanés, un tiers de plus. Sans historique, partez de votre meilleure journée connue, avec une marge plus large.

## Tester avant le jour J : le test de charge

Un [test de charge](https://studiofogg.fr/glossaire#test-de-charge) simule de nombreux visiteurs simultanés pour trouver le maillon qui cède le premier. Des outils libres existent, comme k6, Gatling, JMeter ou Locust. La documentation de k6 conseille un premier essai à faible charge, qui valide le scénario, puis décrit plusieurs [types de tests de charge](https://grafana.com/docs/k6/latest/testing-guides/test-types/), dont trois utiles avant un temps fort :

<table>
<thead>
  <tr>
    <th>
      Test
    </th>
    
    <th>
      Ce qu’il simule
    </th>
    
    <th>
      Ce qu’il vous apprend
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      Stress
    </td>
    
    <td>
      Votre pic estimé, maintenu plusieurs minutes
    </td>
    
    <td>
      Si le site tient, avec quels temps de réponse
    </td>
  </tr>
  
  <tr>
    <td>
      Pic soudain
    </td>
    
    <td>
      Une montée brutale, comme après une newsletter
    </td>
    
    <td>
      Si le site encaisse le choc et s’en remet
    </td>
  </tr>
  
  <tr>
    <td>
      Point de rupture
    </td>
    
    <td>
      Une charge croissante jusqu’à la panne
    </td>
    
    <td>
      Votre marge réelle et le premier maillon qui lâche
    </td>
  </tr>
</tbody>
</table>

Reproduisez de vraies visites — recherche, fiche produit, panier, commande jusqu’au paiement —, pas seulement l’accueil, que le cache sert sans effort. Testez sur une copie identique à la production, ou sur la production la nuit, après avoir prévenu l’hébergeur : un test de charge peut ressembler à une attaque. Sur Shopify, renseignez-vous d’abord auprès de l’éditeur. Mesurez le temps de réponse au 95ᵉ centile — que seule une requête sur vingt dépasse —, le taux d’erreurs et la charge de la base de données, puis refaites le test après chaque correction.

Le paiement fait exception : Stripe, par exemple, [déconseille d’inclure son API dans un test de charge](https://docs.stripe.com/rate-limits), car son environnement de test est limité à 25 requêtes par seconde, contre 100 en production, et ne reproduit pas les temps de réponse réels. Simulez plutôt ces appels, en imitant leur durée en production.

## Cache et CDN : servir le catalogue sans solliciter le serveur

Pour tenir un pic, épargnez d’abord le serveur. Une fiche produit vue par un visiteur non connecté est la même pour tous : produite une fois, elle peut être servie depuis un cache et depuis [un CDN, ce réseau de serveurs relais proches des visiteurs](https://studiofogg.fr/glossaire#cdn). Le panier, le compte client et la commande, propres à chaque client, y échappent : c’est là que le serveur travaille pendant le pic.

Si vos prix changent à heure fixe, videz le cache à l’ouverture de l’offre, sinon certains visiteurs verront les anciens prix. Mais juste après une purge, toutes les requêtes repartent vers le serveur. D’où l’ordre à suivre : activer les nouveaux prix, vider le cache, le remplir en faisant parcourir les pages principales par un robot, puis seulement envoyer la newsletter, le tout à 9 h plutôt qu’à minuit, quand votre équipe est présente.

## Scalabilité verticale, horizontale ou automatique : que choisir ?

Quand le cache ne suffit plus, il faut davantage de capacité :

<table>
<thead>
  <tr>
    <th>
      Approche
    </th>
    
    <th>
      Principe
    </th>
    
    <th>
      Atout
    </th>
    
    <th>
      Limite
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      Verticale
    </td>
    
    <td>
      Un serveur plus puissant
    </td>
    
    <td>
      Simple, sans modifier l’application
    </td>
    
    <td>
      Un plafond, et toujours un seul serveur
    </td>
  </tr>
  
  <tr>
    <td>
      Horizontale
    </td>
    
    <td>
      Plusieurs serveurs derrière un répartiteur de charge
    </td>
    
    <td>
      Un serveur peut tomber sans arrêter le site
    </td>
    
    <td>
      L’application doit partager sessions et fichiers
    </td>
  </tr>
  
  <tr>
    <td>
      Automatique
    </td>
    
    <td>
      Des serveurs ajoutés ou retirés selon la charge
    </td>
    
    <td>
      La capacité suit le trafic, la facture aussi
    </td>
    
    <td>
      Délai de démarrage, plafonds de dépense à régler
    </td>
  </tr>
</tbody>
</table>

À trois semaines du pic, pour une boutique WooCommerce ou PrestaShop sur un seul serveur, la montée en gamme temporaire de l’offre est souvent la solution réaliste : demandez à votre hébergeur si elle se fait sans coupure et si elle est réversible. Les deux autres approches supposent une application prête à tourner sur plusieurs serveurs : elles se conçoivent en amont.

Même automatique, la montée en charge se prépare : un serveur met un moment à démarrer, quand un pic monte en quelques minutes. Programmez la capacité à l’avance — AWS parle de [mise à l’échelle planifiée](https://docs.aws.amazon.com/fr_fr/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html) — et gardez l’automatique pour l’imprévu. Si vos pics dépassent durablement ce qu’un serveur absorbe, [notre offre d’infrastructure cloud évolutive, hébergée en Europe](https://studiofogg.fr/services/infrastructure-cloud-nantes) demande 4 à 8 semaines de mise en place, loin de tout temps fort.

## Les maillons faibles : paiement, recherche, stock, e-mails, scripts tiers

### Le paiement

Interrogez votre prestataire sur ses limites : Stripe, sur la même page, invite à prévenir son support si un événement risque de les dépasser, au moins six semaines à l’avance pour une hausse importante. Vérifiez aussi que les notifications qui confirment chaque paiement (les *webhooks*) sont traitées en cas d’afflux, sans quoi des commandes payées peuvent rester « en attente de paiement ».

### La recherche et les filtres

Ils échappent souvent au cache : chaque combinaison de filtres forme une page nouvelle, et une recherche à suggestions instantanées peut interroger le serveur à chaque lettre tapée. Intégrez-les au test ; au besoin, espacez les suggestions ou confiez la recherche à un service dédié.

### Le stock

Pour ne pas vendre deux fois le dernier article, WooCommerce, par exemple, [retient le stock des commandes en attente de paiement](https://woocommerce.com/document/configuring-woocommerce-settings/products/) pendant le délai que vous fixez, puis annule la commande. Trop court, ce délai peut faire annuler la commande d’un client encore en train de payer, ou dont la confirmation de paiement tarde ; trop long, il immobilise des articles dans des commandes jamais payées. Testez aussi le connecteur qui synchronise le stock avec votre caisse ou votre entrepôt.

### Les e-mails

Depuis le 1er février 2024, Gmail demande aux expéditeurs de plus de 5 000 messages par jour vers des comptes Gmail personnels d’authentifier leur domaine (SPF, DKIM et DMARC) et d’offrir un désabonnement en un clic dans leurs messages marketing ; à tous, un taux de spam inférieur à 0,3 %. Ses [consignes pour les expéditeurs](https://support.google.com/a/answer/81126?hl=fr) recommandent aussi d’envoyer à un rythme régulier, sans pic soudain de volume, et de ne pas mélanger les types de contenus : pas de promotion dans une confirmation de commande, par exemple. Envoyez donc la newsletter par vagues, ce qui étale aussi le trafic du site.

### Les scripts tiers

Chat, avis clients, pixels publicitaires : chaque script tiers est une dépendance de plus. Un script classique chargé sans attribut `async` ni `defer` est exécuté avant que le navigateur ne poursuive l’analyse de la page, selon [la documentation MDN](https://developer.mozilla.org/fr/docs/Web/HTML/Reference/Elements/script) : si son fournisseur ralentit, votre page attend. Retirez ce qui ne sert plus, chargez le reste en différé. Si la boutique est lente au quotidien, [un audit de la vitesse de votre site](https://studiofogg.fr/services/optimisation-vitesse-site-web-nantes) en traitera les causes — plutôt en février, après les soldes, qu’à la veille du pic.

## Le jour J : surveiller, geler, dégrader en douceur

La veille et le jour même, un tableau de bord suit le temps de réponse, les erreurs, la charge de la base de données, les paiements acceptés et les commandes par quart d’heure. Comparez ces commandes à la prévision : une chute brutale peut trahir une panne invisible pour les indicateurs techniques, comme un bouton de paiement cassé. Ajoutez un robot qui parcourt le tunnel de commande toutes les cinq minutes et une liste de contacts : qui décide, qui intervient, comment joindre l’hébergeur et le prestataire de paiement.

Gelez les mises en production d’une semaine avant le Black Friday au lendemain du Cyber Monday, sauf correctif de sécurité ou réparation urgente. Les mises à jour se font donc avant, testées sur une copie du site, comme dans [une maintenance de site bien organisée](https://studiofogg.fr/journal/maintenance-site-internet-que-prevoir) ; avec [un pipeline de déploiement automatisé, doté d’un retour arrière](https://studiofogg.fr/journal/ci-cd-pipeline-de-deploiement), un correctif urgent suit le chemin balisé habituel.

Le mode dégradé est un plan B décidé à froid : les fonctions à couper, dans l’ordre, si le site ralentit.

1. Les recommandations personnalisées et les suggestions de recherche.
2. Le chat, les widgets d’avis et les scripts marketing non essentiels.
3. Les filtres les plus coûteux.
4. En dernier recours, une salle d’attente virtuelle, qui fait patienter les visiteurs en surnombre plutôt que de laisser le site tomber pour tous ; Cloudflare, par exemple, [la propose avec ses offres Business et Enterprise](https://developers.cloudflare.com/waiting-room/).

Chaque coupure doit tenir en un geste et avoir été essayée pendant le test. Préparez aussi une page de secours statique, hébergée ailleurs que la boutique.

## Ne pas tout confier à un seul fournisseur

Quand un prestataire tombe, la panne n’est pas de votre fait, mais les ventes perdues sont les vôtres. Le 20 octobre 2025, une erreur dans la gestion DNS d’un service d’AWS a perturbé sa région de Virginie du Nord pendant plus de quatorze heures, selon [le compte rendu d’AWS](https://aws.amazon.com/message/101925/). Le 18 novembre suivant, à dix jours du Black Friday, un fichier de configuration devenu trop volumineux a fait renvoyer des erreurs à de nombreux sites passant par Cloudflare pendant plus de trois heures, d’après [l’analyse publiée par Cloudflare](https://blog.cloudflare.com/18-november-2025-outage/).

Sans aller jusqu’à une architecture multifournisseur, rarement justifiée pour une PME, prévoyez :

- un second moyen de paiement, chez un autre prestataire ;
- les e-mails de commande confiés à un autre service que les campagnes ;
- la page de secours hors de votre infrastructure principale ;
- le nom de domaine géré depuis un compte à votre nom ;
- un abonnement aux pages d’état (*status pages*) de vos prestataires.

Pour doser l’effort, chiffrez ce que coûterait une heure d’arrêt pendant votre meilleure heure de vente : visites × taux de conversion × panier moyen.

## Calendrier des prochains pics : Black Friday, Noël, soldes d’hiver 2027

Le Black Friday est le lendemain de Thanksgiving, fixé cette année au jeudi 26 novembre selon [le calendrier des jours fériés fédéraux américains](https://www.opm.gov/policy-data-oversight/pay-leave/federal-holidays/). Les soldes d’hiver commencent le deuxième mercredi de janvier à 8 heures — le premier, si le deuxième tombe après le 12 — et durent quatre semaines, selon l’[arrêté du 27 mai 2019](https://www.legifrance.gouv.fr/loda/id/JORFTEXT000038523234).

<table>
<thead>
  <tr>
    <th>
      Temps fort
    </th>
    
    <th>
      Date
    </th>
    
    <th>
      À prévoir
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      Black Friday
    </td>
    
    <td>
      Vendredi 27 novembre 2026
    </td>
    
    <td>
      Le pic principal, souvent étiré sur plusieurs jours
    </td>
  </tr>
  
  <tr>
    <td>
      Cyber Monday
    </td>
    
    <td>
      Lundi 30 novembre 2026
    </td>
    
    <td>
      Gel maintenu jusqu’au soir
    </td>
  </tr>
  
  <tr>
    <td>
      Noël
    </td>
    
    <td>
      Vendredi 25 décembre 2026
    </td>
    
    <td>
      Dates limites de commande affichées sur le site
    </td>
  </tr>
  
  <tr>
    <td>
      Soldes d’hiver
    </td>
    
    <td>
      Du mercredi 6 janvier 2027, 8 h, au mardi 2 février 2027 inclus
    </td>
    
    <td>
      Prix et stocks préparés avant les congés
    </td>
  </tr>
</tbody>
</table>

Ces dates de soldes valent en Loire-Atlantique et, selon [la page du ministère consacrée aux soldes](https://www.entreprises.gouv.fr/fr/commerce-et-artisanat/ventes-reglementees/soldes), pour toute vente à distance, quel que soit le siège de l’entreprise.

<callout type="attention">

Une réduction s’annonce par rapport au prix le plus bas pratiqué au cours des trente jours qui la précèdent, selon l’[article L112-1-1 du Code de la consommation](https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000044549592) ; en cas de baisses successives, par rapport au prix d’avant la première. Si vos prix ont bougé depuis le 28 octobre, vérifiez vos prix barrés du 27 novembre.

</callout>

## Le plan J-21 : trois semaines pour être prêt

Phileas Fogg avait quatre-vingts jours pour boucler son tour du monde ; il vous en reste vingt-trois. Voici comment les répartir.

<table>
<thead>
  <tr>
    <th>
      Échéance
    </th>
    
    <th>
      Date
    </th>
    
    <th>
      À faire
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      J-21
    </td>
    
    <td>
      Vendredi 6 novembre
    </td>
    
    <td>
      Chiffrer le pic, lister maillons et prestataires, vérifier vos accès, prévenir l’hébergeur
    </td>
  </tr>
  
  <tr>
    <td>
      J-14
    </td>
    
    <td>
      Vendredi 13 novembre
    </td>
    
    <td>
      Premier test de charge du parcours d’achat, puis corrections
    </td>
  </tr>
  
  <tr>
    <td>
      J-10
    </td>
    
    <td>
      Mardi 17 novembre
    </td>
    
    <td>
      Second test, mode dégradé essayé, newsletter planifiée par vagues
    </td>
  </tr>
  
  <tr>
    <td>
      J-7
    </td>
    
    <td>
      Vendredi 20 novembre
    </td>
    
    <td>
      Dernières mises à jour, restauration testée, prix et codes promo vérifiés, puis gel
    </td>
  </tr>
  
  <tr>
    <td>
      J-1
    </td>
    
    <td>
      Jeudi 26 novembre
    </td>
    
    <td>
      Capacité relevée, cache préchauffé, vraie commande avec chaque moyen de paiement
    </td>
  </tr>
  
  <tr>
    <td>
      J
    </td>
    
    <td>
      Vendredi 27 novembre
    </td>
    
    <td>
      Tableau de bord suivi, décisions selon le plan
    </td>
  </tr>
  
  <tr>
    <td>
      J+3
    </td>
    
    <td>
      Lundi 30 novembre
    </td>
    
    <td>
      Cyber Monday ; fin du gel le lendemain
    </td>
  </tr>
  
  <tr>
    <td>
      J+7
    </td>
    
    <td>
      Vendredi 4 décembre
    </td>
    
    <td>
      Bilan : prévision et réalité, ce qui a cédé, ce qui change avant Noël
    </td>
  </tr>
</tbody>
</table>

Le mercredi 11 novembre est férié : la semaine du premier test est courte. Ce qui demande plus de trois semaines — changer d’hébergeur, alléger un thème, obtenir une hausse importante des limites d’un prestataire — se note pour l’an prochain.

Dès [la conception de votre boutique en ligne](https://studiofogg.fr/services/creation-site-e-commerce-nantes), nous tenons compte de ces pics dans le choix de la plateforme et de l’hébergement, et une astreinte peut couvrir les dates critiques, sur devis. Le premier rendez-vous de 30 minutes est gratuit, au studio à Nantes ou en visio.

## Sitemap

See the full [sitemap](https://studiofogg.fr/sitemap.md) for all pages.
