Le 22 octobre 2026, le passage de la belle-iloise au journal de 20 h de France 2 a provoqué un pic de trafic exceptionnel sur sa boutique PrestaShop.
Résultat : 136 242 requêtes en moins de deux heures, aucune erreur serveur (5xx) et des temps de réponse compris entre 0,22 et 0,38 seconde pour 95 % des pages générées par PHP au plus fort du pic. Retour sur la préparation technique qui a permis d'absorber cette montée en charge.
Un passage télévisé peut représenter une formidable opportunité commerciale pour un e-commerçant. Mais lorsque plusieurs milliers de visiteurs arrivent sur une boutique en quelques minutes, il peut aussi mettre à l'épreuve toute son infrastructure technique.
Pour la belle-iloise, l'enjeu était clair : accueillir ce trafic supplémentaire sans dégrader l'expérience des visiteurs ni compromettre la disponibilité du site.
Pour préparer cette échéance, plusieurs équipes ont travaillé de concert : Axome, qui pilote l'activité du site, les équipes PrestaShop, responsables de l'hébergement dans le cadre de l'offre PS Hosting, les équipes techniques de la belle-iloise et Scalizy pour l'accompagnement sur les performances.
Les résultats mesurés pendant la diffusion illustrent l'importance d'une préparation en amont, associant optimisation applicative, capacité de traitement et surveillance en conditions réelles.
Journal de 20 h de France 2 : un trafic multiplié par 50 en quelques minutes
Le passage de la belle-iloise au journal de 20 h de France 2, le 22 octobre 2026, a entraîné une augmentation brutale de la fréquentation de sa boutique en ligne.
À partir de 20 h 40, le trafic a fortement progressé en quelques minutes. Le volume de requêtes a augmenté très rapidement, passant d'environ 130 à plus de 3 000 requêtes par minute en deux minutes, avant d'atteindre un maximum de 6 168 requêtes par minute à 20 h 58, soit environ 100 requêtes par seconde. Entre 20 h 40 et 21 h 02, le site a reçu en moyenne 4 100 requêtes par minute, soit 90 915 requêtes en 22 minutes.
Malgré cette sollicitation exceptionnelle, le site a conservé des temps de réponse maîtrisés et n'a enregistré aucune erreur serveur (5xx). Sur 136 242 requêtes reçues entre 20 h 05 et 22 h, seules 44 ont dépassé 2 secondes, soit 0,03 %.
Les chiffres clés du passage télévisé
| Indicateur | Temps normal | Pendant le pic |
|---|---|---|
| Requêtes par minute | ≈ 130 | 6 168 au maximum (à 20 h 58) |
| Taux de HIT Varnish sur les pages cacheables | 36 % | 75 % |
| Temps de réponse serveur au 95e percentile | 0,5 à 0,9 s | 0,22 à 0,38 s |
| Erreurs serveur (5xx) | 0 | 0 |
Le point le plus marquant est la stabilité des performances : malgré une multiplication du trafic par près de 50, les temps de réponse mesurés sont restés inférieurs à ceux observés en période habituelle. Le cache explique en grande partie ce résultat : pendant le pic, les visiteurs consultent massivement les mêmes pages, déjà préchauffées. Au plus fort du pic, 3 pages cacheables sur 4 ont été servies directement par Varnish en 1 ms environ, contre à peine plus d'une sur trois avant la diffusion.
Le graphique de supervision montre également que la charge est redescendue progressivement après le passage télévisé, sans incident pendant cette phase de retour à la normale.
Une préparation collective entre agence, hébergeur et équipes du marchand
La réussite de cette opération repose sur la coordination de plusieurs intervenants aux responsabilités complémentaires.
Axome : le pilotage de l'activité e-commerce
Axome pilote l'activité du site de la belle-iloise. Son rôle dans cette organisation s'inscrit dans la préparation de la boutique à un événement susceptible de générer une hausse importante et soudaine de la fréquentation.
PrestaShop : l'hébergement et la capacité de traitement
Les équipes PrestaShop pilotent l'hébergement de la boutique dans le cadre de l'offre PS Hosting.
La préparation de l'infrastructure a notamment porté sur la capacité de traitement simultané, la configuration de PHP-FPM et les paramètres liés à la gestion du cache. L'objectif était de disposer de ressources suffisantes pour répondre à l'afflux de requêtes tout en maintenant des temps de réponse maîtrisés.
Les équipes techniques de la belle-iloise : la coordination opérationnelle
Les équipes techniques de la belle-iloise ont contribué à la mise en place des différents éléments nécessaires à l'intervention.
Leur implication a facilité la coordination entre les intervenants et le bon déroulement des ajustements réalisés avant l'événement.
Scalizy : contribuer à la maîtrise des performances
Scalizy intervient sur l'analyse et l'optimisation des performances des boutiques PrestaShop. Dans ce type de contexte, l'enjeu est d'identifier les mécanismes susceptibles de limiter la capacité du site à absorber une hausse de trafic, puis de contribuer à la mise en place des optimisations adaptées.
Cette approche complète le travail de l'agence, de l'hébergeur et des équipes techniques du marchand : la disponibilité d'une boutique pendant un pic de trafic dépend à la fois de son code, de ses accès aux données, de ses mécanismes de cache et de l'infrastructure qui exécute les requêtes.
Premier levier : le cache PrestaShop, avec Varnish et un cache SQL
Lorsqu'un visiteur consulte une page e-commerce, PrestaShop doit normalement exécuter du code, récupérer des informations en base de données et générer le contenu à afficher.
Si des milliers de visiteurs sollicitent simultanément les mêmes pages, ces opérations peuvent rapidement devenir coûteuses. Le cache permet d'éviter de répéter inutilement une partie de ces traitements.
Pour préparer le passage télévisé, deux niveaux de cache complémentaires ont été mis en place.
Le cache de pages Varnish
Le cache de pages, assuré par Varnish via le module Scalizy HTTP Cache, conserve en mémoire les pages pouvant être partagées entre plusieurs visiteurs.
Lorsqu'une page est déjà disponible dans le cache, elle peut être servie directement sans solliciter à nouveau PrestaShop ni la base de données pour la générer.
Ce mécanisme réduit le travail nécessaire pour répondre aux requêtes répétitives et permet à l'application de consacrer ses ressources aux opérations qui nécessitent réellement un traitement dynamique.
Un point important concerne les paramètres de suivi des campagnes marketing. Les liens issus de Google, des campagnes e-mail ou des réseaux sociaux peuvent contenir des paramètres de tracking différents (utm_source, gclid, fbclid…), alors qu'ils désignent une même page.
Lorsque ces paramètres sont correctement pris en compte dans la configuration du cache, ils ne créent pas inutilement plusieurs versions d'une page identique. Les visiteurs peuvent ainsi bénéficier d'un cache mutualisé.
Toutes les pages ne peuvent cependant pas être mises en cache de la même manière : les contenus personnalisés ou les pages nécessitant un traitement propre à chaque visiteur doivent conserver un fonctionnement adapté.
Pendant le passage télévisé, Varnish a servi 75 % des pages cacheables depuis son cache au plus fort du pic (67 % sur l'ensemble de la soirée), contre 36 % avant la diffusion. Une page servie par le cache répond en 1 ms environ, contre 0,16 à 0,24 seconde en moyenne pour une page générée par PHP. Ce taux ne concerne toutefois que les pages cacheables : 70 % des requêtes reçues (panier, appels AJAX, pages liées à un cookie de session, une grande partie des fichiers statiques) sont transmises à PrestaShop sans passer par le cache.
Le cache SQL applicatif
Le second niveau, assuré par Scalizy Database Cache, agit sur les lectures répétitives en base de données.
Lorsqu'une même information est demandée à plusieurs reprises, le cache SQL applicatif permet de réutiliser un résultat conservé en mémoire plutôt que de relancer systématiquement la requête correspondante.
Ce mécanisme est particulièrement utile pour les pages qui ne peuvent pas être intégralement servies depuis le cache de pages. Même lorsque PrestaShop doit générer une réponse, une partie des lectures en base peut ainsi être évitée.
La mémoire dédiée à ce cache, stocké dans APCu, a été portée à 2 Go avant l'événement.
Les deux mécanismes répondent donc à des besoins distincts :
Le cache de pages évite de régénérer les pages qui peuvent être partagées entre visiteurs.
Le cache SQL applicatif limite les lectures répétitives en base de données lorsque le traitement applicatif reste nécessaire.
Le préchauffage du cache avant le passage télévisé a également permis de disposer de pages déjà mises en cache au moment où les premiers visiteurs supplémentaires sont arrivés.
Deuxième levier : dimensionner PHP-FPM pour le traitement simultané
Le cache réduit le travail nécessaire pour répondre aux requêtes, mais il ne remplace pas une infrastructure correctement dimensionnée.
Une partie des requêtes doit toujours être traitée par l'application. Il faut donc que le serveur puisse absorber les opérations restantes, notamment celles qui concernent les pages dynamiques.
Dans le cadre de la préparation, la capacité de traitement simultané configurée a été portée de 60 à 480 processus PHP-FPM (paramètre pm.max_children), avec des ajustements d'APCu.
Cette évolution augmente le nombre de traitements que l'infrastructure peut prendre en charge simultanément, sous réserve des ressources disponibles et des limites des autres composants.
Il est important de distinguer trois indicateurs :
Les visiteurs actifs représentent les visiteurs observés sur une fenêtre de temps donnée.
Les requêtes par minute mesurent le volume de sollicitations reçues par le serveur.
Les traitements simultanés correspondent aux opérations prises en charge en parallèle.
Ces métriques ne sont pas interchangeables. Une boutique peut recevoir un grand nombre de requêtes sans devoir exécuter chacune d'elles dans PrestaShop, notamment lorsqu'une partie importante est servie par le cache.
Entre 20 h 50 et 21 h, environ 60 requêtes par seconde ont atteint PHP (36 174 sur 46 307 requêtes reçues). Avec des pages générées en 0,16 à 0,24 seconde en moyenne, ce volume ne mobilisait qu'une douzaine de traitements simultanés en moyenne, loin des 480 disponibles.
C'est précisément la complémentarité entre cache et capacité de traitement qui permet d'absorber un pic de trafic sans mobiliser inutilement toutes les ressources de l'infrastructure.
Troisième levier : optimiser la base de données MariaDB / MySQL
La base de données représente un autre point de vigilance lors d'une montée en charge.
Si chaque visite entraîne de nombreuses lectures répétitives, la multiplication des requêtes peut rapidement augmenter la pression sur MariaDB, le moteur de base de données compatible MySQL utilisé par la boutique, même lorsque le serveur web dispose encore de ressources disponibles.
En complément du cache SQL applicatif, la configuration de la base de données a donc été ajustée :
Désactivation de l'ancien cache de requêtes interne de MariaDB (query cache), au profit du cache SQL applicatif.
Augmentation de la mémoire allouée à la base de données de 16 à 24 Go.
Ces paramètres doivent être considérés dans leur ensemble. Augmenter la mémoire disponible ne suffit pas à garantir de bonnes performances si l'application multiplie les lectures inutiles. Inversement, optimiser les requêtes ne dispense pas de dimensionner correctement la base de données.
L'objectif est de limiter les traitements redondants tout en conservant une capacité suffisante pour les opérations qui doivent réellement être exécutées.
Quatrième levier : limiter l'impact des services externes
Une page PrestaShop peut dépendre de services tiers appelés pendant sa génération. Si l'un d'eux ralentit au moment du pic, chaque processus PHP qui attend sa réponse reste bloqué, et la capacité disponible fond rapidement.
Avant la diffusion, un délai maximum de réponse (timeout) a été ajouté sur deux services externes appelés par la boutique : en cas de lenteur, la page se génère sans attendre indéfiniment. Le chargeur ionCube, nécessaire à certains modules encodés, a également été installé.
Test de charge et monitoring : tester avant, surveiller pendant le pic
Une configuration adaptée sur le papier ne garantit pas, à elle seule, un bon comportement en production.
Les tests de montée en charge réalisés avant le passage télévisé ont permis de valider les choix effectués et de préparer le site à une augmentation importante de la fréquentation.
Pendant la diffusion, les indicateurs ont fait l'objet d'un suivi renforcé, avec des relevés toutes les deux minutes.
Cette surveillance permettait de suivre l'évolution du trafic, la sollicitation de l'infrastructure, les temps de réponse et les éventuelles erreurs serveur.
Le graphique montre une montée rapide à partir de 20 h 40, plusieurs pointes successives jusqu'à 6 168 requêtes par minute, puis une décroissance progressive de l'activité.
La charge est restée maîtrisée pendant cette période. Aucun incident serveur n'a été enregistré et les temps de réponse sont restés compris entre 0,22 et 0,38 seconde au 95e percentile pendant le pic.
Cette combinaison de tests préalables et de surveillance en conditions réelles permet de vérifier non seulement que le site reste disponible, mais également qu'il continue à répondre dans des délais compatibles avec une bonne expérience utilisateur.
Méthodologie : d'où viennent ces chiffres
Les chiffres de cet article proviennent des journaux d'accès Varnish (varnishncsa) de la boutique en production, entre 20 h 05 et 22 h, tests de charge exclus. Quelques précisions pour les lire correctement :
Visiteurs actifs : nombre d'adresses IP distinctes sur une fenêtre de cinq minutes. Il ne s'agit ni de sessions ni de visiteurs simultanés.
Trafic réel : la boutique est placée derrière le CDN Azure Front Door, en amont de Varnish. Les requêtes servies directement par le CDN ne sont pas comptées, le trafic réel est donc au moins égal à ces chiffres.
Robots : les bots identifiés par leur user-agent sont inclus, soit environ 1,5 % des requêtes.
Taux de cache : les 75 % de HIT portent sur les pages cacheables, pas sur l'ensemble du trafic.
Total des requêtes : le chiffre de 136 242 peut différer légèrement de celui du graphique (136 401), en raison d'un filtrage un peu plus strict et d'un découpage horaire fixe.
Bilan : une boutique PrestaShop disponible pendant toute la montée en charge
Le bilan du passage de la belle-iloise au journal de 20 h est clair : la boutique a absorbé 136 242 requêtes en moins de deux heures, avec un pic à 6 168 requêtes par minute, sans aucune erreur serveur et avec seulement 0,03 % de requêtes au-delà de 2 secondes.
Trois enseignements ressortent de cette intervention.
1. La capacité serveur ne fait pas tout. Ajouter des ressources est utile, mais limiter les traitements inutiles permet de mieux exploiter l'infrastructure disponible.
2. Les caches doivent être complémentaires. Le cache de pages réduit la génération répétitive des contenus, tandis que le cache SQL applicatif limite les lectures répétitives en base de données.
3. La préparation doit être collective. L'agence, l'hébergeur, les équipes techniques du marchand et les spécialistes de la performance doivent coordonner leurs interventions pour que les optimisations fonctionnent ensemble.
Le cas de la belle-iloise illustre ainsi une approche pragmatique de la montée en charge : mesurer, identifier les points de vigilance, optimiser les traitements, valider la configuration et surveiller les résultats.
Questions fréquentes : préparer une boutique PrestaShop à un pic de trafic
Comment préparer une boutique PrestaShop à un pic de trafic ?
Il faut d'abord identifier ce qui ralentit la boutique : pages lentes, modules coûteux, requêtes SQL répétées. Viennent ensuite la mise en place d'un cache de pages comme Varnish et d'un cache SQL applicatif, le dimensionnement de PHP-FPM et de la base de données, le préchauffage du cache et un test de charge pour valider l'ensemble. Pendant l'événement, un suivi rapproché des temps de réponse et des erreurs serveur permet de réagir rapidement.
Quel trafic un passage au journal de 20 h peut-il générer sur un site e-commerce ?
Dans le cas de la belle-iloise, le nombre de visiteurs uniques a été multiplié par 27 sur cinq minutes. Le volume de requêtes a dépassé 3 000 par minute en deux minutes, pour atteindre un maximum de 6 168 requêtes par minute, contre environ 130 en temps normal.
Pourquoi les temps de réponse peuvent-ils baisser pendant un pic de trafic ?
Lorsque le cache est bien configuré et préchauffé, les visiteurs d'un pic consultent en grande partie les mêmes pages. Une plus grande part des requêtes est alors servie directement depuis le cache, sans solliciter PrestaShop ni la base de données. Chez la belle-iloise, le taux de HIT Varnish sur les pages cacheables est passé de 36 % avant la diffusion à 75 % au pic, pour un temps de réponse d'environ 1 ms par page servie depuis le cache. Ici, le temps de réponse au 95e percentile est passé de 0,5 à 0,9 s en période habituelle à 0,22 à 0,38 s pendant le pic.
Quelle part du trafic le cache Varnish sert-il pendant un pic ?
Tout dépend de la part de pages cacheables. Chez la belle-iloise, 3 pages cacheables sur 4 ont été servies par Varnish en 1 ms environ au plus fort du pic, contre 36 % avant la diffusion. En revanche, 70 % des requêtes (panier, appels AJAX, pages liées à un cookie de session, une grande partie des fichiers statiques) ne passent pas par le cache : PHP-FPM a donc continué à traiter environ 60 requêtes par seconde au pic.
Combien de processus PHP-FPM prévoir pour un pic de trafic ?
Le besoin dépend du nombre de requêtes qui atteignent PHP et de leur durée de génération. Avec environ 60 requêtes par seconde générées en 0,2 seconde en moyenne, une douzaine de processus travaillent en même temps. Porter pm.max_children de 60 à 480 a laissé une large marge pour absorber les pointes et les requêtes plus lentes, dans la limite de la mémoire disponible sur le serveur.
Un cache Varnish suffit-il pour absorber un pic de trafic sur PrestaShop ?
Non. Le panier, l'espace client et le tunnel de commande restent des pages dynamiques que PrestaShop génère pour chaque visiteur. Pour ces requêtes, un cache SQL applicatif, une capacité de traitement PHP-FPM suffisante et une base de données correctement dimensionnée restent nécessaires.
Anticiper les ralentissements PrestaShop avec Scalizy
Un pic de trafic provoqué par un passage télévisé n'est pas le seul événement susceptible de mettre une boutique e-commerce sous pression.
Une opération promotionnelle, un lancement produit, une campagne publicitaire, une période de soldes ou le Black Friday peuvent également provoquer une hausse brutale de la fréquentation.
Pour préparer ces échéances, il est essentiel de comprendre ce qui ralentit réellement la boutique : génération des pages, modules trop coûteux, requêtes SQL lentes, traitements répétitifs ou ressources insuffisantes.
Scalizy aide les équipes techniques et les agences PrestaShop à analyser les performances de leurs boutiques, à repérer les points de blocage et à prioriser les optimisations.
L'objectif n'est pas seulement de constater qu'une boutique ralentit, mais de disposer des informations techniques nécessaires pour comprendre pourquoi et agir plus efficacement.
Vous préparez une opération commerciale ou anticipez un pic de trafic sur votre boutique PrestaShop ? Analysez ses performances en amont pour identifier les points de vigilance et réduire le risque de ralentissement au moment où vos visiteurs sont les plus nombreux.