20 h 00, la newsletter part. 20 h 01, la nouvelle collection est en ligne et la page d’accueil tourne. Dix secondes, vingt, puis une page blanche ou un message d’erreur jamais vu en test. Un pic de trafic PrestaShop suit presque toujours ce scénario. Ça rame, puis ça tombe. Même code que la veille, mais 2 000 personnes arrivées dans la même minute.
Boutique en panne maintenant ? Allez directement à quoi couper, dans quel ordre, ou appelez le 09 72 03 59 17.
Trois choses cèdent : les processus PHP, la base de données et les quotas de l’hébergeur. Sur PrestaShop, une connexion à la base refusée donne une erreur 500 ; la 503 vient du serveur ou du mode maintenance. Et un quota max_questions atteint bloque les requêtes jusqu’à la fin de l’heure.
Ce qui se passe quand 2 000 personnes arrivent en même temps
Chaque page PrestaShop passe par trois étages, chacun avec son plafond. Dès que l’un sature, les autres suivent.
- Les processus PHP. PHP-FPM traite un nombre maximal de requêtes à la fois, réglé par pm.max_children. Au-delà, les requêtes font la queue, et le journal l’écrit en toutes lettres : « server reached pm.max_children setting ». La boutique ne plante pas encore, elle rame.
- La base de données. Chaque page ouvre une connexion à MySQL. Quand toutes les connexions permises sont prises, la suivante est refusée.
- Le cache vide. Juste après une mise en ligne, 2 000 visiteurs, ce sont 2 000 pages calculées au lieu d’être servies toutes prêtes.
Le chiffre qui compte est donc le nombre de visiteurs simultanés, pas les visites par jour. 10 000 visites étalées sur une journée passent sans bruit, alors que 2 000 clics dans la même minute peuvent tout bloquer.
Et tous les pics ne s’annoncent pas. Profileo a raconté en 2020 le cas d’une boutique PrestaShop passée de 15 à 20 utilisateurs actifs à 2 806 simultanés après une campagne d’influenceurs ; elle a tenu, sur huit serveurs frontaux et un CDN. La newsletter d’un partenaire ou une vague de robots font le même effet. Pour ces pics imprévus, l’hébergement CYBERIAL inclut une surveillance 24/7. Si votre boutique rame aussi un mardi matin ordinaire, commencez par un diagnostic de lenteur PrestaShop.
Erreur 503 PrestaShop, 500, 502, 504 : ce que votre boutique essaie de dire
Intégrer cette infographie sur votre site
<a href="https://cyberial.fr/pic-de-trafic-prestashop/"><img src="https://cyberial.fr/wp-content/uploads/erreurs-pic-de-trafic-prestashop.png" alt="Erreurs PrestaShop pendant un pic de trafic" /></a><p>Source : <a href="https://cyberial.fr/pic-de-trafic-prestashop/">Erreurs PrestaShop pendant un pic de trafic</a> - CYBERIAL</p>| Code | Cause probable pendant un pic | Premier réflexe |
|---|---|---|
| 500 | Connexion à la base de données refusée (trop de connexions, quota atteint). | Chercher « Link to database cannot be established » dans le fichier du jour du dossier var/logs/ (par exemple 20261127_exception.log ; app/logs/ avant la 1.7.4, log/ en 1.6), ouvert par FTP ou le gestionnaire de fichiers de l’hébergeur, ou dans le journal d’erreurs de l’hébergement. Méthode complète : erreur 500 PrestaShop. |
| 502 | PHP-FPM a coupé la connexion ou ne répond plus. | Journal du serveur web : « recv() failed (104: Connection reset by peer) ». Vérifier que PHP-FPM tourne. |
| 503 | Serveur surchargé, limite de processus de l’hébergeur, ou mode maintenance. | Vérifier que la maintenance n’est pas activée, puis les ressources chez l’hébergeur. |
| 504 | Le serveur web a attendu PHP trop longtemps (60 secondes par défaut chez Nginx). | Repérer les pages lentes : recherche à facettes, modules, requêtes SQL longues. |
| 508 | Limite Entry Processes atteinte sur un mutualisé cPanel sous CloudLinux. | Ressources dans cPanel ; couper robots et tâches planifiées. |
Beaucoup de marchands cherchent une 503 alors que leur boutique affiche une 500. Quand MySQL refuse la connexion, PrestaShop renvoie une page d’erreur muette, et le vrai message reste dans les journaux.
Les trois messages MySQL à reconnaître
- 1040, « Too many connections » : le serveur MySQL a atteint son maximum de connexions (max_connections, 151 par défaut).
- 1203, « User … already has more than ‘max_user_connections’ active connections » : votre compte SQL a atteint la limite fixée par l’hébergeur. Le grand classique du mutualisé.
- 1226, « User … has exceeded the ‘max_questions’ resource (current value: N) » : un quota horaire est épuisé. N est votre plafond, souvent écrit nulle part ailleurs.
max_questions : des requêtes refusées jusqu’à la fin de l’heure
Une fois le quota horaire atteint, MySQL refuse les requêtes du compte jusqu’à ce que l’heure soit écoulée (documentation MySQL). LWS donne l’exemple : limite atteinte en 45 minutes, 15 minutes de blocage. Le pic est passé, et la boutique reste en panne. Les requêtes des robots comptent comme celles des clients, et sur un mutualisé, impossible de remettre le compteur à zéro vous-même.
Le mode maintenance renvoie aussi une 503
En maintenance, PrestaShop répond aux visiteurs non autorisés par une 503. Depuis la 1.7, elle porte un en-tête Retry-After: 3600, soit « revenez dans une heure » ; en 1.6, elle part sans. Avant de chercher une surcharge, vérifiez l’onglet Maintenance : Paramètres de la boutique > Paramètres généraux, ou Préférences > Maintenance en 1.6 (votre version s’affiche dans Paramètres avancés > Informations). Si « Activer boutique » est sur Non (« Activer la boutique » en 1.6), la boutique est en maintenance.
Pour voir la boutique pendant la maintenance, cliquez sur « Ajouter mon IP », à côté du champ IP de maintenance, puis enregistrez. En 8 et 9, si l’option « Activer l’accès à la boutique pour les employés connectés » est sur Oui, il suffit d’être connecté au back-office. Pour rouvrir la boutique, remettez « Activer boutique » sur Oui (« Activer la boutique » en 1.6), puis enregistrez.
Pendant le pic : quoi couper, dans quel ordre
Tout vider et tout redémarrer achève souvent la boutique. Coupez plutôt dans cet ordre, du plus doux au plus fort, en regardant l’effet entre deux étapes.
- Le module de statistiques : il écrit en base à chaque nouvelle visite, et à chaque page vue d’un robot, qui n’a pas de cookie. Le couper quelques heures ne coûte que des statistiques. Modules > Gestionnaire de modules (Modules et services en 1.6), cherchez « Récupération des données statistiques », menu déroulant > Désactiver (surtout pas Désinstaller). Réactivez-le après le pic.
- Les modules lourds non essentiels : chat, suggestions de produits, trackers, widgets tiers.
- Les tâches planifiées : flux vers les places de marché, synchronisation de stock, e-mails en masse. Décalez-les à la nuit. Si vous vendez le même stock sur des places de marché, gardez la synchronisation mais espacez-la. Si les tâches passent par le module Cron tasks manager (cronjobs) ou un équivalent, désactivez-les là ; sinon, demandez à votre hébergeur. PrestaShop envoie l’e-mail de confirmation pendant la validation de commande ; un serveur d’envoi lent la ralentit donc. Si la validation rame, faites vérifier le serveur d’envoi (Paramètres avancés > E-mail) ; n’en changez pas en plein pic sans test.
- Les robots, si votre domaine passe par Cloudflare : une règle de challenge ciblée, ou le mode Under Attack, activable depuis le tableau de bord, que Cloudflare présente comme un dernier recours (chaque visiteur passe un contrôle de quelques secondes).
- Une limite de requêtes (rate limiting) sur les pages coûteuses comme la recherche. En offre Free, une seule règle, comptée sur 10 secondes.
- Plus de ressources, si l’hébergeur permet de monter en gamme sans migration.
- En dernier recours, une maintenance courte ou le mode catalogue (Paramètres de la boutique > Produits, ou Préférences > Produits en 1.6), qui retire toute possibilité d’achat, le temps que la base récupère. Préférez le mode catalogue, et remettez « Mode catalogue » sur Non dès que la base répond. Par défaut, la maintenance renvoie aussi une 503 aux pages des modules, donc au retour du client après paiement et aux notifications des modules de paiement qui ne la contournent pas (PrestaShop Checkout et Mollie la contournent). Le client paie, et la commande peut ne pas être créée. Si vous passez en maintenance, notez l’heure, puis comparez les paiements chez le prestataire avec Commandes > Commandes.
Une file d’attente virtuelle se prépare avant le pic, et Cloudflare ne la propose qu’à partir de l’offre Business.
À ne pas faire :
- vider tous les caches : chaque page repart de zéro, au pire moment ;
- installer un module « d’optimisation » ou lancer une mise à jour ;
- redémarrer MySQL sans savoir pourquoi il sature : les connexions reviennent aussitôt.
Cas client : décembre 2025, une boutique équipée d’un module de caisse. D’abord des lenteurs intermittentes (plus de 2 minutes pour afficher une page), puis des erreurs 503, back-office et caisse compris ; le client avait remis la boutique en maintenance. Nous commençons par les journaux du serveur, pour savoir si la 503 vient de la maintenance ou d’une surcharge.
Vous ne pouvez pas couper vous-même ? Appelez le 09 72 03 59 17.
On identifie ce qui bloque, l’hébergement ou PrestaShop. Dépannage dès 150 € HT, prix fixe validé avant toute intervention ; ces 150 € sont déduits si vous passez ensuite à la maintenance. Réponse en moins d’une heure, 7j/7, de 8 h à 22 h.
Mutualisé : les limites que personne ne vous annonce
Sur un mutualisé, l’hébergeur protège tous les sites du serveur avec des plafonds absents de la page de l’offre. Nous avons relevé ceux que les hébergeurs publient quand même.
| Hébergeur | Limite publiée | Au dépassement |
|---|---|---|
| OVHcloud (hébergement web) | 30 connexions simultanées par base de données | « Too many connections » |
| Infomaniak | 38 connexions simultanées par utilisateur SQL, aucun quota horaire | Connexion refusée (max_user_connections) |
| Hostinger (offres Web) | 25, 50 ou 75 connexions MySQL par utilisateur selon l’offre | Erreur max_user_connections |
| LWS (mutualisé) | Quota horaire max_questions, « en principe plus de 5 requêtes par seconde », sans valeur publiée | Requêtes refusées jusqu’à la fin de l’heure |
| Hébergements cPanel sous CloudLinux | Limite Entry Processes, 20 par défaut | Erreur 508 |
| o2switch | Ressources cloisonnées par compte, aucune valeur publiée | Limite de processus atteinte : erreurs 503, selon sa FAQ |
30 connexions simultanées paraissent confortables. En pratique, c’est 30 pages en cours de calcul au même instant, robots et back-office compris.
À demander à votre hébergeur, par écrit : les limites exactes de votre offre (connexions SQL par utilisateur, quota horaire de requêtes, processus) ; le journal d’erreurs du serveur à l’heure de la panne, et les robots ou adresses IP les plus actifs à ce moment ; si une limite peut être relevée le temps d’une opération ; son accord avant un test de charge.
Cas client : chez une librairie en ligne, en juillet 2026, la boutique affichait des erreurs 500 et les journaux « has exceeded the ‘max_questions’ resource (current value: 40000) ». Ses 40 000 requêtes de l’heure étaient épuisées, environ 11 par seconde. Avant de parler d’hébergement, nous cherchons ce qui consomme ces requêtes.
Si ces plafonds reviennent à chaque opération, voyez ce qu’on attend d’un hébergement PrestaShop qui tient les pics.
Deux pièges propres à PrestaShop
Le module de statistiques écrit en base pour chaque robot
Le module Récupération des données statistiques (statsdata) crée une ligne dans ps_guest pour tout visiteur sans cookie, robots compris, puis enregistre la connexion (ps_connections), sa provenance et, si l’option est cochée, la page vue.
PrestaShop a bien une fonction censée reconnaître les robots. Testée avec de vrais identifiants, elle reconnaît Googlebot, mais ni bingbot, ni GPTBot, ni ClaudeBot, ni AhrefsBot, ni SemrushBot. Or 51 % du trafic web est automatisé (Imperva, 2025). En pic, ces écritures consomment le même quota que les clients ; notre guide pour nettoyer la base de données PrestaShop dit quelles tables purger.
Le cookie PrestaShop bloque le cache « par défaut »
PrestaShop dépose un cookie chiffré à tout visiteur dès la première page. Un Varnish en configuration par défaut laisse passer sans cache toute requête qui porte un cookie : il ne met donc rien en cache. Et comme ce cookie porte le même nom pour tous, sa seule présence ne distingue pas un visiteur qui a un panier. Cloudflare, lui, ne met pas le HTML en cache par défaut : il sert images, CSS et JavaScript, mais chaque page reste calculée par votre serveur.
Pour servir des pages déjà calculées, il faut un module de cache pleine page qui recharge le panier et les blocs personnels en AJAX, ou un Varnish configuré pour PrestaShop, testé sur la préprod. Quant à Redis, le cœur de PrestaShop ne le propose pas : il passe par un module tiers.
Changer d’hébergeur ne suffit pas si les robots continuent d’écrire en base à chaque page vue : ils rempliront le nouveau serveur comme l’ancien.
Avant le pic : estimer, régler, tester
Estimer le pic en visiteurs simultanés
Un pic de trafic sur PrestaShop se prépare avec un ordre de grandeur : pic de l’an dernier dans GA4, taille de la liste e-mail, audience du partenaire, traduits en visiteurs simultanés. Pour le Black Friday, notre calendrier Black Friday PrestaShop place ces vérifications fin octobre.
Les réglages PrestaShop et serveur
- Dans PrestaShop (Paramètres avancés > Performances) : mode debug désactivé, compilation des templates sur « Ne jamais recompiler les fichiers de templates », cache Smarty sur Oui (en 1.6 et 1.7, type « Système de fichier »), CCC activé et testé sur la préprod, pas la veille du pic.
- Côté serveur : OPcache actif, innodb_buffer_pool_size à 1 Go dans l’exemple de la documentation PrestaShop, idéalement plus grand que la base, si la mémoire le permet.
- Sur VPS ou dédié : un max_connections MySQL cohérent avec pm.max_children. Le détail est dans notre guide performance PrestaShop.
Cache pleine page et préchauffage
Préchauffez le cache avant l’envoi, sinon les premiers visiteurs le rempliront à vos dépens. Faites parcourir par un petit script les pages qui recevront le trafic (accueil, catégories de l’opération, fiches mises en avant). Si les prix changent à minuit, videz puis préchauffez juste après.
Un test de charge sur la préprod
Le test se fait sur une copie identique de la boutique, jamais sur un mutualisé sans l’accord de l’hébergeur, car pour lui, votre test ressemble à une attaque.
- L’outil : k6, Locust ou JMeter. En test HTTP, aucun n’exécute le JavaScript des pages : les appels AJAX, comme l’ajout au panier, se scriptent un par un.
- Le parcours : catégorie, fiche produit, ajout au panier, tunnel. Testez-le en entier.
- La forme : une montée progressive, puis un test de pic (spike), brutal comme l’envoi d’une newsletter.
- Les critères : moins de 1 % de requêtes en erreur et un temps de réponse p95 fixé à l’avance. Surveillez aussi la base et PHP-FPM, corrigez, relancez.
Cas client : une boutique de prêt-à-porter nous a écrit en août 2026, avant une mise en ligne de collection le soir. Sa question : combien de connexions simultanées le nouveau serveur tient-il pendant les premières minutes ? Nous y répondons par un test de charge sur une copie de la boutique, parcours d’achat compris.
Une file d’attente virtuelle pour les lancements
Pour une mise en ligne de collection ou une vente flash à heure fixe, faites entrer les clients par vagues. Une file d’attente virtuelle (waiting room) laisse passer un nombre fixé de visiteurs ; les suivants patientent sur une page d’attente et entrent dans l’ordre d’arrivée dès qu’une place se libère.
La file protège la boutique sans l’accélérer : ceux qui sont déjà entrés vont au bout de leur panier et du paiement. Une limite de requêtes refuse sans ordre d’arrivée, et le mode maintenance ferme la porte à tout le monde.
Ce qui existe pour PrestaShop. Nous n’avons trouvé aucun module de file d’attente virtuelle sur la marketplace Addons : les modules « liste d’attente » y servent aux produits en rupture, un autre besoin. Il faut passer par un service placé devant la boutique.
- Cloudflare Waiting Room, à partir de l’offre Business (rien en Free ni en Pro) : une salle en ordre d’arrivée. Les pages d’attente personnalisées, les ouvertures planifiées et les exclusions de chemins demandent l’offre Enterprise avec l’option Advanced.
- Queue-it, service de file hébergé : plus de vingt connecteurs, aucun pour PrestaShop. L’intégration passe par son script JavaScript, son connecteur PHP ou la couche Cloudflare.
- CrowdHandler : un kit PHP, pas de module PrestaShop non plus, et une offre gratuite limitée pour tester.
Les réglages qui comptent.
- Le seuil se fixe d’après le test de charge : Cloudflare conseille d’admettre environ 75 % de la capacité mesurée.
- Les robots des moteurs de recherche ne doivent pas faire la queue : Cloudflare prévient qu’un robot bloqué en file peut nuire au référencement. Activez le contournement prévu pour eux, disponible dès l’offre Business.
- Les notifications de paiement arrivent sans cookie : si leur adresse est couverte par la salle, elles risquent de recevoir la page d’attente, et la commande de ne pas se créer. Sans règles d’exclusion, placez la file sur la page du lancement, pas sur toute la boutique.
- La durée de session (5 minutes par défaut chez Cloudflare, jusqu’à 30) : passé ce délai sans activité, un visiteur admis redevient un nouveau visiteur. Allongez-la, sinon un client qui revient sur la page du lancement refait la queue.
- L’ouverture : sans ouverture planifiée (réservée à l’option Advanced), activez la salle vous-même avant l’heure annoncée, et annoncez cette heure, avec le lien de la page du lancement, à vos clients (newsletter, réseaux sociaux). La page d’attente par défaut de Cloudflare existe en français.
- Le test se fait sur la préprod ou un sous-domaine. La file repose sur un cookie : un navigateur qui refuse les cookies ne passe pas pendant la mise en file.
Les e-mails de confirmation. Même en version 9, PrestaShop les envoie pendant la validation de la commande, sans file de tâches. Depuis la 1.7.1, un module peut les retenir grâce au hook actionEmailSendBefore et les confier à une tâche planifiée, qui les expédie quelques instants plus tard. À tester sur la préprod.
J-7 : test de charge passé, mises à jour gelées, sauvegarde vérifiée, hébergeur et prestataire de paiement prévenus, newsletter en envois échelonnés.
J-1 : cache préchauffé après les changements de prix, tâches planifiées décalées (synchro de stock multicanal espacée, pas coupée), un outil de surveillance qui teste l’ajout au panier toutes les minutes, numéro d’un technicien sous la main.
Après : ce que Google retient d’une panne
Une heure de panne ne ruine pas un référencement. Les erreurs 5xx ralentissent l’exploration de Google, et les URL indexées ne sont retirées que si l’erreur persiste.
- Une 503 d’un ou deux jours est acceptable, avec un en-tête Retry-After, selon la page de Google sur la mise en pause d’un site. Au-delà d’environ une semaine, précisait Google en 2017, Googlebot la traite comme une erreur durable.
- Un robots.txt qui répond en 5xx fait arrêter l’exploration pendant 12 heures.
- Désactiver le panier ne change rien à la visibilité dans Google.
Le lendemain, faites le point : erreurs serveur dans la Search Console ; journaux, heure par heure ; commandes payées chez le prestataire mais jamais créées dans PrestaShop ; pic réel contre pic prévu. Les clients perdus comptent aussi : selon Baymard (2025), parmi les acheteurs en ligne américains qui ont abandonné une commande (hors « je regardais seulement »), 17 % citent un site qui avait des erreurs ou avait planté.
Mutualisé, VPS ou dédié : quand changer
| Type | Ce que vous contrôlez | Ce qui limite | Pour quel pic |
|---|---|---|---|
| Mutualisé | Presque rien | Quotas SQL, processus, ressources partagées | Pics modérés, avec un cache pleine page |
| VPS | PHP-FPM, MySQL, cache serveur | La taille de la machine, et quelqu’un pour la régler | Pics réguliers et prévisibles |
| Dédié | Tout | Le budget et l’administration | Pics importants |
Notre conseil : un mutualisé bien réglé tient des pics modérés. Pour des pics importants, sortez des quotas du mutualisé grand public : il vous faut des ressources dimensionnées et quelqu’un pour les régler. Faites-le avant le pic.
Chez CYBERIAL, l’hébergement, dès 30 € HT/mois, est une option du forfait maintenance : base de données sur un serveur de 256 Go de RAM mutualisé entre clients, Cloudflare, clone de préprod, surveillance 24/7 et migration gratuite (détail sur la page hébergement PrestaShop). En urgence, nous pouvons aussi reprendre l’hébergement d’une boutique en panne lors d’un dépannage PrestaShop.
Le forfait maintenance PrestaShop à 69 € HT/mois, sans engagement, avec l’hébergement en option dès 30 € HT/mois : migration gratuite, et un clone de préprod sur lequel lancer votre test de charge.
Questions fréquentes sur le pic de trafic PrestaShop
Pourquoi mon PrestaShop affiche une erreur 503 pendant les soldes ?
Une erreur 503 PrestaShop vient du serveur : serveur web surchargé, limite de processus atteinte chez l’hébergeur, ou mode maintenance activé. Vérifiez d’abord la maintenance, puis les ressources chez l’hébergeur. Si c’est la base de données qui refuse les connexions, PrestaShop affiche plutôt une erreur 500.
Que veut dire le message « has exceeded the ‘max_questions’ resource » ?
Votre compte SQL a atteint le quota horaire de requêtes fixé par l’hébergeur, affiché après « current value ». MySQL refuse alors ses requêtes jusqu’à la fin de l’heure, même si le trafic est retombé. En mutualisé, réduisez les requêtes (robots, statistiques, tâches planifiées) ou changez d’hébergement.
Too many connections sur PrestaShop : que faire ?
Toutes les connexions autorisées par MySQL sont prises (151 par défaut) ; avec « max_user_connections », c’est la limite de votre compte SQL. Sur le moment, coupez le module de statistiques, les tâches planifiées et les robots inutiles. Ensuite, accordez le nombre de processus PHP avec celui des connexions MySQL, ou changez d’offre.
Combien de visiteurs un hébergement mutualisé peut-il tenir ?
Aucun chiffre sérieux ne permet de le dire : pendant un pic de trafic PrestaShop, tout dépend du cache, du thème, des modules et des robots. Les hébergeurs publient des limites techniques, comme 30 connexions simultanées par base chez OVHcloud, pas un nombre de visiteurs. Seul un test de charge sur une copie de la boutique répond.
Le mode maintenance nuit-il au référencement ?
Pas s’il reste court : PrestaShop renvoie une 503, avec un en-tête Retry-After depuis la 1.7, ce que Google recommande pour une fermeture d’un ou deux jours. Au-delà d’environ une semaine, des pages peuvent sortir de l’index ; désactiver seulement le panier ne change rien à la visibilité.
Pourquoi Cloudflare ne met pas mon PrestaShop en cache ?
Par défaut, Cloudflare ne met pas le HTML en cache : il sert les images, le CSS et le JavaScript, et PrestaShop dépose en plus un cookie à chaque visiteur. Pour servir des pages déjà calculées, il faut un module de cache pleine page qui recharge le panier en AJAX, ou un Varnish configuré pour PrestaShop, testé sur la préprod.
Faut-il une file d’attente virtuelle sur une boutique PrestaShop ?
Pour un lancement ou une vente flash à heure fixe, oui, si le test de charge montre que la boutique ne tiendra pas le pic attendu. Nous n’avons trouvé aucun module PrestaShop pour cela : on passe par Cloudflare Waiting Room (dès l’offre Business), Queue-it ou CrowdHandler. Excluez les robots des moteurs de recherche, et ne placez pas la file sur les notifications de paiement.
Panne en cours ou pic à préparer ?
Boutique en panne : appelez le 09 72 03 59 17. Pic à préparer : laissez l’adresse de la boutique et la date de l’opération. Dans les deux cas, nous vous répondons en moins d’une heure, 7j/7, de 8 h à 22 h.
