PrestaShop performance : monitoring, tests de charge et runbooks soldes

Table des matières :

Définir ce que “performance PrestaShop” veut dire (SLI/SLO, parcours critiques, budgets)

Sur PrestaShop, parler de “performance” sans la cadrer revient à optimiser au hasard : on confond vite vitesse de rendu front, latence PHP, contention MySQL, cache applicatif et saturation réseau. Le point de départ opérationnel, c’est de définir des SLI (Service Level Indicators) alignés sur les parcours critiques : page catégorie, fiche produit, recherche, ajout au panier, tunnel de commande, paiement, API de synchronisation. Sur des soldes, ce sont rarement les pages CMS qui font tomber la boutique : ce sont les endpoints à forte cardinalité (search, facettes, panier) et les écritures (cart/order).

Le cadre SRE est utile même sur un e-commerce “classique”. Dans le Google SRE Book, la définition suivante est nette et actionnable : « Monitoring is the process of collecting, processing, aggregating, and displaying real-time quantitative data about a system » (Beyer et al., Site Reliability Engineering, 2016, O’Reilly). Pour la référence officielle en ligne, la version Google est accessible via la version en ligne du Google SRE Book.

Cette définition oblige à sortir du “on a des logs” et à produire des métriques exploitables (p95/p99, taux d’erreur, saturation). Elle est aussi un rappel que l’outil (Grafana, Kibana, etc.) n’est rien sans le pipeline.

Concrètement, fixez des SLO mesurables, pas des vœux pieux : par exemple p95 TTFB < 200 ms sur les pages cacheables et p95 TTFB < 600 ms sur le checkout, ou taux d’erreur 5xx < 0,2% sur 30 minutes. Pour éviter l’écueil du “tout est prioritaire”, explicitez aussi le budget d’erreur : si vous tolérez 0,2% de 5xx sur une fenêtre de 30 minutes et que vous faites 50 000 requêtes, votre budget est de 100 erreurs max. Une fois le budget consommé, les actions “business as usual” (déploiements non urgents, imports catalogues, reindex) doivent être gelées jusqu’au retour à la normale.

Un format simple qui fonctionne bien en atelier (tech + produit + marketing) est une table SLI/SLO par parcours, avec le “type de mesure” (edge vs origin) pour éviter les malentendus :

Parcours critique	SLI (mesure)	Exemple de SLO	Où mesurer
Catégorie (anonyme)	TTFB p95	< 200 ms	CDN/Varnish + origin
Fiche produit (anonyme)	TTFB p95	< 250 ms	CDN/Varnish + origin
Recherche	Durée p95 + taux d’erreur	< 800 ms et 5xx < 0,2%	origin + DB
Ajout panier	Durée p95 + timeouts	< 600 ms	origin
Checkout (étapes)	Durée p95	< 600–900 ms selon étape	origin
Paiement	Taux d’échec	< 1% (hors refus bancaires)	app + PSP

Si vous cherchez une base de travail sur la latence, l’article TTFB PrestaShop : réduire le Time To First Byte sous 200 ms est un bon point d’ancrage pour convertir vos observations en objectifs.

Enfin, un rappel “soldes” très concret : l’exigence n’est pas identique partout. Si votre trafic est majoritairement France/Belgique, vous pouvez viser des objectifs plus stricts sur les POP européens (latence réseau plus faible) tout en gardant un SLO “global” réaliste si vous faites aussi de l’international. L’important est d’adosser l’objectif à un point de mesure stable (CDN/edge, ou reverse-proxy) et à une fenêtre de temps (ex. 30 minutes) compatible avec l’exploitation.

Instrumenter PrestaShop : logs, métriques et traces sans bricolage

Le cœur PrestaShop (8.1–9.1) reste majoritairement PHP avec une hybridation Symfony côté Back Office et certaines couches. Pour parler sérieusement de monitoring, partez d’une stack standard (Nginx/Apache + PHP-FPM + MySQL/MariaDB + Redis/Varnish éventuels) et instrumentez à 3 niveaux : infra (CPU, RAM, IO, réseau), runtime (PHP-FPM, OPcache, workers), application (temps contrôleur, requêtes SQL, cache hits/miss, erreurs). Cible de versions recommandée pour 2026 : PrestaShop 8.1.x ou 9.1.x, PHP 8.2/8.3, et si vous êtes en phase d’upgrade, vérifiez les points de compatibilité dans la note sur PrestaShop 9.1 et PHP 8.1–8.5.

Pour la télémétrie “moderne”, OpenTelemetry est devenu le standard de facto, notamment parce qu’il évite le lock-in. La doc officielle résume bien l’objectif : « OpenTelemetry is a collection of tools, APIs, and SDKs. Use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) » (voir la documentation OpenTelemetry). Sur PrestaShop, l’approche pragmatique consiste souvent à commencer par :

Metrics : exporter Nginx/PHP-FPM/MySQL via exporters Prometheus (ou équivalents) et tracer la latence côté edge.
Logs : normaliser Nginx + PHP + MySQL slow logs vers un pipeline (ELK/EFK).
Traces : instrumenter le checkout et les points d’intégration (paiement, ERP, shipping) là où la latence est la plus coûteuse.

Deux points “sans bricolage” qui font une vraie différence en prod :

Un identifiant de corrélation (request_id) propagé partout : reverse-proxy → PHP → logs applicatifs → traces. Sans ça, vous perdez un temps précieux à recoller les morceaux pendant un pic.
Des logs structurés (JSON) côté front/proxy et côté application, au minimum pour : statut, durée, upstreamtime, route/endpoint, shopid (si multiboutique), customer_group (si pertinent), et un tag “cache” (HIT/MISS/BYPASS) si vous avez Varnish/CDN.

Côté logs, évitez de “grep en prod”. Un pipeline Logstash/Elasticsearch est plus robuste dès que vous corrélez des incidents multi-couches (5xx Nginx + timeouts PHP-FPM + locks InnoDB). Pour cadrer rapidement ce que vous pouvez parser et enrichir, référez-vous à ce guide sur les plugins Logstash (input/filter/output).

Enfin, instrumenter “application PrestaShop” ne signifie pas forcément patcher le core : commencez par les points à fort ROI (checkout, recherche, ajout panier) et par les intégrations externes. En soldes, une latence ajoutée par un tiers (PSP, transporteur, service de recommandation) peut se transformer en saturation PHP-FPM si les timeouts sont trop permissifs. Le triptyque à imposer en équipe : timeout court, retries limités, dégradation contrôlée (feature flag ou fallback).

Mesures utiles en production : Golden Signals, Core Web Vitals et métriques PrestaShop

Les Golden Signals (latency, traffic, errors, saturation) restent le meilleur compromis pour ne pas se noyer. Sur une boutique PrestaShop, vous voulez au minimum :

Latence : p50/p95/p99 sur /, catégories, fiches produit, /search, /panier, /commande.
Trafic : RPS, sessions, distribution mobile/desktop.
Erreurs : 4xx/5xx, exceptions PHP, timeouts upstream, taux d’échec paiement.
Saturation : php-fpm (busy workers, max_children), DB (threads running, buffer pool), cache (hit ratio), file descriptors, IO wait.

Ne mélangez pas métriques backend et expérience utilisateur : vous avez besoin des deux. Côté exploitation, une vue “minute par minute” (p95, 5xx, saturation) est ce qui permet de décider vite. Côté produit/SEO, vous avez besoin d’une vision plus “expérience” (mobile, rendu, interactivité).

Côté UX, Core Web Vitals est non négociable sur mobile, surtout en période de pics (publicité, retargeting, tag managers). L’article interne actions Core Web Vitals (LCP, INP, CLS) donne une liste d’actions directement applicables (images, JS, CSS critique, préchargements) : en parallèle, gardez une approche outillée via navigateur (waterfall, CPU throttling), cf. méthodes pro avec DevTools pour mesurer et optimiser.

Une pratique simple pour relier “perf front” et “perf back” : sur vos dashboards, alignez TTFB p95 (edge) avec durée upstream (reverse-proxy → PHP-FPM) et temps DB (si vous l’exposez). Si le TTFB monte mais que l’upstream ne bouge pas, vous cherchez côté réseau/CDN. Si l’upstream monte, vous êtes probablement sur PHP/DB/modules.

Enfin, mesurez ce que PrestaShop masque mal : le coût des modules et des hooks. Le cœur n’impose pas de budget de latence par hook, et les régressions arrivent vite (un module “analytics” qui fait 3 appels HTTP synchrones, un module de paiement qui bloque). Sur les pages Symfony/Doctrine (BO, certains modules), la détection d’anti-patterns (N+1, memory bloat) se traite comme dans un projet Symfony : détection N+1 Doctrine et dérives mémoire est directement transposable : article sur la détection N+1 et memory bloat.

Pour rendre ça actionnable, ajoutez un “budget module” dans vos revues : par exemple, sur fiche produit, aucun module ne doit ajouter > 50 ms p95 sans justification (et sans cache). Ce n’est pas une règle “scientifique”, mais un garde-fou efficace pour éviter que la performance se dégrade à chaque ajout de fonctionnalité.

Tests de charge : scénarios réalistes, outillage et pièges spécifiques PrestaShop

Un test de charge utile ne consiste pas à “tirer 10k users et regarder si ça tient”. Vous devez reproduire des parcours avec des distributions réalistes : 70% navigation (catégorie/produit), 20% recherche, 8% panier/checkout, 2% login/compte (exemple). Et surtout, vous devez modéliser l’effet cache : un trafic “anonyme” derrière Varnish n’a rien à voir avec un trafic connecté avec panier. Si vous utilisez Varnish, la stratégie ESI et les fragments changent complètement la charge PHP : voir configuration ESI Varnish.

Outillage : k6 (scriptable, CI-friendly) ou JMeter (plus GUI, plus lourd) font le job. Exemple minimal k6 orienté PrestaShop (à adapter, avec cookies et headers) :

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  scenarios: {
    browse: { executor: 'ramping-vus', startVUs: 0, stages: [
      { duration: '2m', target: 50 },
      { duration: '5m', target: 200 },
      { duration: '2m', target: 0 },
    ]},
  },
  thresholds: {
    http_req_failed: ['rate<0.002'],
    http_req_duration: ['p(95)<800'],
  },
};

export default function () {
  const res = http.get('https://www.example.com/');
  check(res, { 'status 200': r => r.status === 200 });
  sleep(1);
}

Le piège n°1 sur PrestaShop : les scénarios “stateful”. Un ajout panier et un checkout impliquent session/cookies, tokens et écritures DB. Pour éviter de produire des résultats trompeurs, construisez vos tests avec deux profils :

Profil A (anonyme cacheable) : home → catégorie → produit → recherche (objectif : mesurer edge/Varnish/CDN et la charge résiduelle).
Profil B (panier/checkout) : produit → add-to-cart → panier → commande (objectif : mesurer PHP/DB “réels”, sans le cache).

Le piège n°2 : les effets de bord (emails, webhooks, CRM, ERP, transport). En pré-prod, vous voulez des intégrations mockées (ou des endpoints de test) et, idéalement, une configuration PrestaShop qui empêche l’envoi réel (SMTP de bac à sable, modules de paiement en mode test). C’est encore plus vrai en contexte “soldes France” où les fenêtres de validation sont courtes : si votre test déclenche 5 000 emails, vous perdez du temps à nettoyer plutôt qu’à analyser.

Prérequis / risques : ne testez pas en production sans garde-fous. Même en staging, un test de charge peut saturer la DB, remplir les tables de panier, déclencher des emails, ou “polluer” vos caches CDN. Travaillez sur un environnement isolé, avec une base anonymisée, des intégrations externes mockées (paiement, ERP) et des quotas réseau. Si vous devez absolument valider en prod, faites du capacity probing très progressif, à des horaires creux, avec un coupe-circuit (arrêt immédiat) et une règle de WAF/Rate Limit prête.

Checklist rapide avant d’appuyer sur “Start” :

Les IP de test sont-elles identifiées (user-agent, header) pour filtrer dans les dashboards ?
Avez-vous une limite “stop test” sur 5xx et sur latence p95 ?
Les jobs cron/imports/catalog rules sont-ils gelés pendant le test ?
Le cache (Varnish/CDN) est-il dans un état contrôlé (warm-up ou purge explicite) ?

Goulots d’étranglement récurrents : MySQL, cache, PHP-FPM et modules

Sur un pic soldes, les causes racines sont rarement “mystiques”. Le triptyque le plus fréquent : MySQL qui bloque, PHP-FPM qui sature, cache inefficace. Côté DB, la première action est de sortir de l’approximation : activer le slow query log, analyser les requêtes, vérifier les index, et corriger les ORDER BY / JOIN coûteux. L’article Index MySQL : optimiser WHERE, JOIN et ORDER BY avec EXPLAIN est un rappel utile des étapes (EXPLAIN, cardinalité, index composés) : ne négligez pas non plus la maintenance : bloat, tables de logs, paniers abandonnés ; automatisez le nettoyage (cron) en vous inspirant de la routine de maintenance DB PrestaShop.

Un tableau “symptôme → vérification → action” aide beaucoup en cellule de crise :

Symptôme	Vérifier en priorité	Mitigation typique
p95 TTFB monte, CPU DB haut	slow log, `Threads_running`, verrous InnoDB	index, réduire requêtes, limiter facettes/recherche
502/504 Nginx, queue PHP-FPM	`pm.max_children` atteint, `listen queue`	augmenter workers si RAM, réduire timeouts, désactiver module lourd
Cache inefficace	HIT ratio Varnish/Redis, BYPASS	corriger cookies/headers, ajuster TTL/grace, ESI
Checkout lent, erreurs paiement	latence PSP, retries, timeouts	timeouts courts, circuit breaker, fallback

Côté cache, PrestaShop a des limites structurelles : beaucoup de pages ne sont pas cacheables “pleinement” sans stratégie (Varnish, ESI, cache user-specific). Vous devez mesurer le hit ratio (Varnish/Redis) et vérifier le coût des invalidations (purge massive au changement de prix, réindexation, import). Les soldes déclenchent souvent des opérations bulk (règles de prix, catalog price rules, imports) : planifiez-les hors pics et évitez les purges globales en pleine fenêtre commerciale.

Si votre recherche produit devient le point noir, l’externalisation via Elastic peut aider, mais uniquement si l’indexation et la pertinence sont cadrées : cf. accélérer la recherche produit avec ElasticSearch. Un signal d’alerte fréquent en soldes : “tout le monde utilise la recherche” (campagnes + visiteurs qui comparent vite), et une recherche SQL non maîtrisée peut suffire à mettre MySQL à genoux.

Côté PHP-FPM, surveillez des métriques simples : max_children atteint, listen queue qui grimpe, temps moyen de requête, mémoire par worker et OPcache (hit rate, wasted memory). Une boutique qui “tient” en moyenne peut s’effondrer sur un p99 lors d’un déploiement de modules ou d’un pic de bots. Et sur PrestaShop, les modules peuvent injecter du temps CPU et des appels HTTP synchrones sur des hooks front : imposez une règle de base en équipe : tout appel externe doit être async/queue ou protégé par circuit breaker / timeout agressif.

Astuce terrain : en période de soldes, certains “pics” sont en réalité des bots de scraping (comparateurs, agressifs ou mal réglés). La frontière perf/sécurité devient floue : une hausse de RPS avec peu de conversion peut ressembler à une “croissance” alors que c’est un parasitage. D’où l’intérêt de corréler RPS avec taux de mise au panier, taux de commande et distribution des user-agents.

Runbooks soldes : procédures d’exploitation, alerting et “garde-fous” de crise

Un runbook soldes n’est pas un PDF oublié : c’est une liste d’actions opérables, testées, avec des critères d’entrée/sortie. Il doit mapper vos alertes à des décisions. Exemple : alerte p95 TTFB > 800ms pendant 5 minutes → vérifier saturation PHP-FPM → vérifier slow queries → vérifier taux de HIT cache → appliquer mitigation. Le runbook doit aussi couvrir les actions “business” : désactiver temporairement des features non essentielles (recommandations, modules de chat, tracking non critique), activer une page de file d’attente (waiting room), ou basculer un mode “catalogue-only” si le checkout explose.

En pratique, un bon runbook “soldes” contient aussi une section préventive J-7 / J-1, parce que le meilleur incident est celui que vous n’avez pas :

J-7 : test de charge sur staging (parcours A/B), vérification index/slow queries, validation cache.
J-1 : gel des déploiements non critiques, warm-up cache, vérification quotas mails/SMS, validation des timeouts PSP.
Jour J : staffing (astreinte), canal incident, seuils d’alerte adaptés à la fenêtre commerciale.

Sur l’alerting, visez peu d’alertes mais correctes (symptôme + impact). Exemple de règle Prometheus (pseudo, à adapter à votre exporter) :

- alert: PrestashopHigh5xxRate
  expr: (sum(rate(nginx_http_requests_total{status=~"5.."}[5m])) / sum(rate(nginx_http_requests_total[5m]))) > 0.002
  for: 5m
  labels: { severity: "page" }
  annotations:
    summary: "Taux 5xx > 0,2%"
    description: "Vérifier PHP-FPM saturation, erreurs applicatives, DB locks. Lancer runbook SOLDES-HTTP-5XX."

Dans le runbook, documentez des actions sûres et des actions à risque. Exemple de check-list (extrait) :

Valider l’impact : dashboard RPS/5xx/p95 + conversion checkout (si disponible).
Isoler la couche : Nginx upstream timeouts ? PHP-FPM queue ? MySQL threads running / locks ?
Mitigations rapides :

augmenter temporairement pm.max_children uniquement si RAM disponible (sinon OOM).
activer/renforcer le cache (Varnish grace, TTL prudents).
désactiver un module fautif (via BO/CLI si possible) après avoir identifié une signature dans les logs.

Actions dangereuses (à valider) : purge cache globale, restart DB, failover sans test.

Pour que ce runbook soit réaliste, il doit être aligné sur vos contraintes sécurité. En soldes, les attaques (bots, credential stuffing, scraping) se confondent avec le trafic. Un WAF/Rate Limit et une journalisation SIEM évitent de traiter un incident sécurité comme un incident performance. L’article Sécurité PrestaShop : protéger API backoffice, WAF et journalisation SIEM détaille l’approche.

Dernier garde-fou très concret : prévoyez une “procédure d’appauvrissement” (dégradation volontaire) déjà validée. Exemple : couper une feature de recommandations (forte consommation CPU/HTTP), réduire le nombre de produits affichés par page, désactiver temporairement certaines facettes, ou retarder des tâches asynchrones (webhooks) via une file. Le jour J, vous n’avez pas le temps de débattre : vous exécutez.

Exploiter les retours d’incident : post-mortem, budget perf et prévention des régressions

Sans boucle de retour, vos soldes 2026 ressembleront à vos soldes 2025. Après chaque pic (ou incident), faites un post-mortem factuel : timeline, symptômes, décision, cause racine, actions correctives, et surtout actions de prévention (tests, alerting, changement d’archi). Le but n’est pas d’assigner une faute, mais de capturer les invariants : “à partir de 250 RPS, la DB devient limitante car la requête X fait un filesort” ou “le module Y ajoute 400 ms via un appel HTTP tiers”.

Industrialisez ensuite : (1) un budget performance par parcours (latence max, payload max, nombre de requêtes SQL), (2) des tests de charge récurrents en CI/CD sur une staging proche de la prod, (3) des garde-fous de qualité code. Sur les modules, outillez la base : static analysis et refactoring contrôlé (types, dead code, complexité), cf. industrialiser la qualité PHP avec PHPStan et Rector. Sur les évolutions cœur/upgrade, gardez en tête que PrestaShop 9 (Symfony 6.4, évolutions API) peut modifier vos points chauds : lire les nouveautés techniques PrestaShop 9.

Une façon efficace d’empêcher les régressions est d’ajouter des “gates” simples avant mise en prod :

si p95 sur recherche dépasse le SLO en staging après une MR → blocage (ou validation explicite).
si taux d’erreur augmente de X% sur un test de charge identique → blocage.
si SQL/req ou CPU/req augmente significativement → investigation (souvent un module/hook).

Dernier point : mesurez le gain, sinon vous ne faites que déplacer le problème. Après une optimisation (index, cache, tuning PHP-FPM, refonte module), comparez avant/après sur des métriques strictement identiques : p95/p99, taux d’erreur, consommation CPU/req, requêtes SQL/req.

Et si votre objectif est aussi mobile/conversion, n’isolez pas performance backend et front : une approche PWA ou un front plus léger peut réduire la charge globale (moins de requêtes, meilleure cacheabilité) — à condition de ne pas introduire une complexité opérationnelle supplémentaire (build, cache, invalidation). Référence interne utile : PWA PrestaShop : performance et conversion mobile.