Dépannage boutique en ligne : 30 pannes classées par symptôme

Table des matières :

Le dépannage d’une boutique en ligne en production (PrestaShop 8.1/8.2 ou PrestaShop 9.x, PHP 8.1→8.3) se gagne au triage, pas au « clic au hasard » dans le back-office. Le cœur PrestaShop n’est pas un système d’auto-diagnostic : sans logs exploitables, monitoring et un minimum de discipline de déploiement, vous perdez des heures — et, en e‑commerce, du chiffre d’affaires.

Dans un contexte très courant en France (pics de charge « soldes », opérations TV, campagnes Meta/Google, ou pics saisonniers type Black Friday), le même symptôme (« ça rame ») peut venir d’un CDN, d’un reverse proxy, d’un module, d’un import ERP, ou simplement d’un DNS mal propagé. L’objectif de cet article : 30 pannes classées par symptôme, avec une méthode reproductible.

Triage express : isoler la couche fautive avant de « réparer »

Commencez par cadrer l’incident avec des signaux mesurables : taux de 5xx, p95/p99 de latence, erreurs JS, taux d’abandon checkout, erreurs de webhooks, jobs en retard. Si vous n’avez rien, vous êtes en mode aveugle : mettez au minimum des métriques système + applicatives (ex. Netdata + Prometheus/Alerting). OWASP rappelle l’évidence opérationnelle : “Without logging and monitoring, breaches cannot be detected.” (OWASP Top 10, A09:2021, OWASP — Security Logging and Monitoring Failures). Même logique pour les pannes.

Avant toute action, prenez 2 minutes pour collecter un minimum vital (utile pour vous, mais aussi pour un hébergeur/infogérant) :

Quand : heure de début, durée, intermittent vs permanent (utile pour corréler avec cron, imports, sauvegardes).
Qui : impact géographique (ex. France uniquement si problème Anycast/CDN), devices, navigateurs.
Quoi : pages touchées (home / catégorie / checkout / admin), taux d’erreur, message exact.
Changements récents : déploiement, mise à jour module, changement DNS/TLS, règle WAF, import ERP/PIM, changement de transporteur/paiement.
Preuve : 1–2 URLs + HAR/console JS si front, et un extrait de logs (Nginx/PHP).

Ensuite, isolez la couche : DNS/TLS → reverse proxy (Nginx/HAProxy) → PHP-FPM/Apache → application PrestaShop → MariaDB/MySQL → dépendances (SMTP, paiement, ERP, recherche). En pratique, un curl -I https://domaine.tld/ + un tail -f des logs Nginx/Apache/PHP et un check DB suffisent à éviter 80% des fausses pistes.

Une matrice simple (à garder en runbook) :

Symptôme observé	Couche la plus probable	3 vérifications qui tranchent vite
502/504	Reverse proxy / PHP-FPM	logs Nginx + `journalctl php-fpm` + saturation `pm.max_children`
500 immédiat	Application / dépendances	`var/logs` + présence `vendor/` + droits `var/`
403 intermittent	WAF / ACL / règles	logs WAF/ModSecurity + `.htaccess` + chemins touchés (`/admin`, `/modules`)
Checkout cassé	JS / modules / sessions	console navigateur + mode incognito + session sticky / Redis
Lenteur progressive	DB / cache / bots	slow query log + cache activé + trafic bots / rate-limit

Enfin, ne dépannez pas en « live » sans filet : snapshot VM, dump DB, bascule maintenance, reproduction en pré-prod. Si vous n’avez pas d’environnement fidèle, commencez par en créer un (Docker) : Staging PrestaShop : créer un environnement Docker fidèle à la production. Pour les mises à jour ratées, gardez un runbook de rollback : Mise à jour PrestaShop ratée : diagnostiquer et réparer rapidement.

Commandes de base (à adapter)

# HTTP et TLS
curl -svI https://shop.tld/ | sed -n '1,20p'

# Erreurs web serveur
sudo tail -n 200 /var/log/nginx/error.log
sudo tail -n 200 /var/log/apache2/error.log

# Erreurs PHP-FPM
sudo journalctl -u php8.2-fpm -n 200 --no-pager

# Santé DB (verrouillages, connexions)
mysql -e "SHOW PROCESSLIST;"
mysql -e "SHOW ENGINE INNODB STATUS\G" | sed -n '1,120p'

Astuce pratique : si vous avez un load balancer/CDN, testez aussi l’IP d’origine (si autorisé) pour distinguer un problème « edge » d’un problème backend. Sans quoi vous pouvez corriger PHP alors que la panne vient d’une redirection imposée par le CDN.

Symptôme : site inaccessible, codes HTTP anormaux, TLS qui casse

Quand la boutique est « down », le réflexe est de distinguer erreur applicative (500) et erreur d’infrastructure (502/504, DNS, TLS). MDN définit précisément le 502 : “The HTTP 502 Bad Gateway response status code indicates that the server, while acting as a gateway or proxy, received an invalid response from the upstream server.” (MDN, HTTP 502 — MDN). Sur PrestaShop, “upstream” = PHP-FPM/Apache, voire un autre proxy.

Sur un incident « site inaccessible », évitez la panique : un 502 est souvent un symptôme de saturation (workers PHP trop peu nombreux, timeouts trop bas, pic de trafic, bots agressifs) ou d’une régression de déploiement (opcache + code non synchronisé). En France, un cas fréquent en production : l’hébergeur a une sauvegarde ou une tâche cron lourde à heure fixe (nuit) et votre site chute uniquement sur un créneau précis.

Ne négligez pas les erreurs de sécurité « bêtes » : un 403 peut venir d’un WAF trop agressif, d’un .htaccess mal fusionné après déploiement, ou d’ACL Nginx/HAProxy.

Sur TLS, l’échec le plus fréquent est un certificat expiré, un chain incorrect (intermédiaires manquants) ou un mauvais SNI en multi-domaine. Une rupture TLS vous donne parfois un faux « site down » côté utilisateur alors que le backend tourne. Si vous changez d’edge (CDN, LB), validez aussi HSTS et redirections : HTTPS SEO : bonnes pratiques, certificats SSL et audit technique.

Pour investiguer TLS de façon fiable (et éviter le piège « ça marche sur mon navigateur »), testez explicitement le SNI :

# Remplacez shop.tld et l'IP si nécessaire
openssl s_client -connect shop.tld:443 -servername shop.tld </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -dates

Pannes (1–5) classées par symptôme

502/504 sur toutes les pages — PHP-FPM saturé (pm.max_children), timeouts proxy; vérifiez logs + php-fpm status; augmentez workers/CPU, fixez proxy_read_timeout, ajoutez cache.

Indice typique : logs Nginx avec upstream timed out et process PHP nombreux/longs.

500 immédiat après déploiement — fichier manquant, autoload cassé, permissions; vérifiez vendor/, var/cache/; composer install --no-dev, purge cache, rollback.

En CI/CD : un rsync incomplet + opcache peut « mélanger » anciennes/nouvelles classes.

301/302 en boucle (http↔https, www↔non-www) — redirections doublées (CDN + .htaccess + reverse proxy); inspectez curl -IL; centralisez la logique au niveau edge.

Bon réflexe : n’avoir qu’un seul endroit source de vérité (edge ou Nginx ou .htaccess).

403 sur /admin ou upload images — règles ModSecurity/WAF, droits FS (img/, var/), .htaccess invalide; corrigez ACL, whitelist chemins, régénérez .htaccess.

Sur certains WAF, les patterns d’URL PrestaShop (tokens, paramètres) déclenchent des faux positifs.

TLS error / NET::ERR_CERT — certificat expiré/chaîne incomplète/SNI; openssl s_client -connect; déployez fullchain, automatisez renouvellement.

Vérifiez aussi la chaîne intermédiate : un certificat « valide » peut échouer si le navigateur ne reconstruit pas la chaîne.

Symptôme : page blanche, assets cassés, erreurs JavaScript, thème instable

La “page blanche” en PrestaShop est presque toujours une erreur fatale PHP ou un template qui explose en prod sans affichage d’erreur (display_errors off). Ne commencez pas par “vider le cache” : récupérez l’exception. Guide dédié : PrestaShop page blanche : diagnostiquer l’erreur fatale PHP rapidement.

Deux points concrets qui font gagner du temps :

Où chercher le log : côté PrestaShop (var/logs/ en général), côté PHP-FPM (journal systemd), côté web server. Si vous ne trouvez « rien », c’est souvent que l’erreur est avant l’app (ex. permissions ou fichier manquant).
Comment revenir en arrière quand le BO est inaccessible : désactivation « offline » d’un module (DB ps_module / ps_module_shop) ou renommage du dossier du module (solution d’urgence, à corriger proprement ensuite).

Côté front, un symptôme fréquent est “le CSS/JS a disparu” après activation de CCC/minification ou après un changement de thème/module. Sur PrestaShop 8.x, la chaîne Smarty/CCC peut produire des bundles invalides si un module injecte du JS non parseable. Sur PrestaShop 9, la modernisation front/back (Symfony 6.4, Hummingbird) réduit certains pièges mais n’élimine pas les modules legacy. Pour cadrer les réglages, voir PrestaShop : optimiser performance via cache Smarty, CCC et CDN.

En pratique, quand un checkout « saute » en erreur JS, isolez vite :

test navigation privée (élimine extensions et cache) ;
test sans consentement cookies (certains bandeaux modifient l’ordre de chargement) ;
test avec thème par défaut en staging si possible ;
désactivation temporaire des modules qui injectent du JS (analytics, chat, A/B test, avis).

Un cas discret : des overrides ou hooks qui cassent le DOM sans crash serveur. Un module qui s’accroche sur un hook “dynamique” peut produire des sorties inattendues selon le contrôleur. Si vous dépannez une page spécifique (produit/panier), inspectez la chaîne d’exécution (hooks, surcharge) avant de toucher au cœur. Référence utile : Hooks PrestaShop : comprendre les hooks dynamiques et les regex.

Pannes (6–10) classées par symptôme

Page blanche front uniquement — fatal PHP dans un module; activez debug en staging, tail var/logs/*; désactivez module via DB si BO inaccessible (ps_module).

Indice : le BO marche car route différente, mais un hook front casse l’exécution.

BO OK mais front sans CSS/JS — CCC/minification génère des assets cassés; désactivez CCC, supprimez var/cache/*, vérifiez themes/*/assets.

Vérifiez aussi les en-têtes cache/CDN : un CDN peut servir un bundle obsolète.

Erreurs JS “Uncaught” au checkout — conflit JS module paiement/analytics; reproduisez en navigation privée, comparez bundle; désactivez modules un par un, fixez ordre de chargement.

Cas fréquent : un script tiers bloque l’exécution si CSP/consentement le coupe à mi-chemin.

Images produits 404 — .htaccess réécriture images, permissions img/, CDN mal configuré; régénérez thumbnails, vérifiez réécritures, purge CDN.

Si vous servez des images via un domaine dédié (ex. img.shop.tld), vérifiez DNS + certificats.

Templates Smarty incohérents — cache non invalidé entre versions; purge var/cache/{prod,dev} et force compilation; évitez d’éditer en prod.

Discipline : versionnez le thème, déployez, puis purge/cache warmup.

Symptôme : back-office KO, login en boucle, permissions, problèmes après mise à jour

Le back-office est un bon indicateur : s’il est lent/KO pendant que le front fonctionne, vous avez souvent une dette sur la partie Symfony/Doctrine (8.x/9.x), des droits filesystem (var/), ou une dépendance cassée (assets admin, translations). Dans les stacks modernes, une partie de la “panne” est une régression de déploiement (vendor non à jour, cache chaud/froid, opcache).

Un diagnostic très rapide : si seules certaines pages BO cassent (Catalog/Orders/Modules), suspectez une exception applicative (Doctrine, module, override). Si tout le BO est lent ou instable, suspectez plutôt infrastructure (sessions, FS, DB).

Le login en boucle est typiquement un bug de cookie/session, pas une panne “mystique”. En multi-front (LB), le manque de sticky sessions ou un stockage session non partagé casse l’auth admin. Si vous êtes sur plusieurs pods/VM, externalisez sessions (Redis) et alignez les domaines/cookies. Sur infra dédiée, partez d’une base saine : Serveur dédié PrestaShop : config Nginx PHP-FPM MariaDB Redis.

Quelques causes « bêtes » mais réelles :

Cookie Secure/domaine mal aligné après passage en HTTPS ou changement de domaine (ex. www vs non-www).
Horloge serveur désynchronisée (problèmes de session/expiration) — rare mais destructeur.
En environnement d’entreprise : reverse proxy interne qui altère X-Forwarded-Proto → PrestaShop croit être en HTTP et recasse la session.

Après mise à jour, le piège principal est de corriger “au hasard” au lieu d’identifier ce qui a changé (PHP, modules, overrides, schéma DB). Une mise à jour PrestaShop touche aussi aux traductions, aux assets et au cache : si votre pipeline ne reconstruit pas proprement, vous “mélangez” des caches entre versions. La checklist sauvegarde/pré-prod reste non négociable : Mise à jour PrestaShop : checklist sauvegarde, pré-production et tests.

En dépannage post-upgrade, une action sûre (si vous avez une fenêtre) est de reconstruire proprement caches + opcache + assets, plutôt que d’empiler des “petits correctifs”.

Pannes (11–15) classées par symptôme

BO 500 sur une page spécifique (Catalog/Orders) — exception Symfony/Doctrine; consultez var/logs/prod.log; corrigez module, purge cache, vérifiez migrations.

Bon réflexe : identifier l’URL exacte et l’action (liste vs édition), puis chercher l’exception correspondante.

Login admin en boucle — sessions non persistantes derrière LB, cookie domain/secure mal réglé; activez sticky sessions ou sessions Redis, validez PS_COOKIE_*.

Si vous venez de passer sur plusieurs instances (ou Kubernetes), traitez la session comme un composant de l’architecture, pas comme un détail.

Impossible d’uploader (images, CSV) — post_max_size, upload_max_filesize, droits admin*/import; alignez PHP.ini et permissions, vérifiez max_input_vars.

Pensez aussi aux limites Nginx (client_max_body_size) côté reverse proxy.

Traductions/BO “cassés” après upgrade — assets/admin non rebuild, cache incohérent; supprimez var/cache, réinstallez assets, vérifiez opcache.

En prod : évitez les caches « persistants » entre releases sans stratégie de purge/namespace.

Tâches planifiées (cron) ne s’exécutent plus — URL cron protégée, token changé, CRON OS manquant; testez endpoint, revalidez secret, journalisez retours.

En France, pensez aussi au timezone serveur (ex. tâches « minuit » qui décalent) si vous corrélez avec promos/flux.

Symptôme : lenteurs, timeouts, CPU/RAM qui montent, DB qui verrouille

En dépannage boutique en ligne, la perf est un incident fonctionnel : si le panier met 8–12s à répondre, vous “perdez” des commandes autant qu’avec un 500. Sur PrestaShop, deux familles dominent : saturation PHP-FPM (concurrence mal dimensionnée) et SQL non indexé (requêtes qui scannent ps_product, ps_stock_available, ps_cart, ps_order_*). Travaillez au p95/p99, pas au “chez moi ça charge”.

Une règle de dimensionnement utile (sans prétendre remplacer une mesure) : PHP-FPM se dimensionne sur la RAM et le coût moyen d’un worker. Mesurez le RSS moyen de vos process PHP en charge, puis calculez un pm.max_children réaliste (sinon vous créez du swap, puis des timeouts) :

# Exemple pour estimer la taille mémoire des workers PHP-FPM
ps -o rss= -C php-fpm8.2 | awk '{sum+=$1; n++} END{if(n>0) printf "RSS moyen: %.0f KB (%d workers)\n", sum/n, n; else print "Aucun process trouvé"}'

Cas réel (vu en prod sur gros catalogue) : page catégorie qui passe de 600 ms à 6 s après ajout d’un module de tri “commercial”. Le slow query log montrait une requête avec ORDER BY sur une colonne non indexée et un JOIN sur une table de stats. Fix = index composite + limitation de champ + cache. Méthode outillée : PrestaShop MySQL : analyser slow query log et optimiser index et Optimisation PrestaShop : accélérer pages produit et panier.

Sur la RAM, ne confondez pas symptôme et cause. Le memory_limit n’est pas un “bouton performance”, c’est une limite de sécurité. PHP le définit ainsi : “memory_limit sets the maximum amount of memory in bytes that a script is allowed to allocate.” (PHP manual — memory_limit). Si vous dépassez, la vraie question est : pourquoi cette route alloue autant (images, export, PDF, surcharge) ?

Enfin, si vous avez des verrous InnoDB, ne “redémarrez pas MySQL” par réflexe : vous masquez la cause racine. Identifiez la transaction longue (import ERP, recalcul massif, module de stats) et corrigez le traitement (batch, index, files).

Pannes (16–20) classées par symptôme

Timeout (504) uniquement sur catégories/cherche — requête SQL lente; activez slow log, ajoutez index, réduisez JOIN, mettez en cache (Redis/Smarty).

Indice : la home va bien, mais les listes (catégories/recherche) explosent dès que filtres/tri s’activent.

CPU à 100% en continu — boucle dans module, cache désactivé, bot agressif; profilez (Xdebug en staging), activez cache, rate-limit côté edge.

Pensez aux robots : un sitemap mal géré + facettes peut générer des milliers d’URLs crawlables.

Erreurs “Allowed memory size exhausted” — export/PDF/images trop lourds; isolez le job en CLI, chunk/pagination, augmentez memory_limit temporairement avec justification.

Astuce : exécuter l’export en tâche asynchrone (queue) plutôt qu’en requête web.

InnoDB lock / commandes qui “gèlent” — transactions longues (ERP/import), isolation trop stricte; inspectez SHOW ENGINE INNODB STATUS, découpez traitements, indexez FK.

Dans les flux ERP, privilégiez l’upsert par lots et évitez les recalculs globaux en pleine journée.

Recherche interne down — moteur externe (Elasticsearch/Meilisearch) indispo; basculez en mode dégradé, alertez, revalidez health checks.

Votre runbook doit prévoir le « mode dégradé » (recherche native, ou désactivation temporaire des facettes).

Symptôme : panier, commande, livraison, stock — le fonctionnel qui explose

Les incidents checkout ont souvent une cause “data” (règles de panier incohérentes, transporteurs mal configurés, taxe) plus qu’un bug code. Le piège est d’ouvrir un ticket module de paiement alors que le panier n’atteint jamais le paiement. Décomposez : ajout panier → recalcul → adresses → transporteurs → taxes → création commande.

Un protocole de repro qui marche bien (et évite les « ça dépend ») :

utiliser un nouveau client (sans historique) ;
tester avec une adresse France métropolitaine puis une adresse hors zone (ex. DOM-TOM si vous les servez) ;
tester sans règle promo, puis avec la règle incriminée ;
tester en FR et en autre devise/TVA si vous avez du cross-border (règles fiscales).

Sur la livraison, l’erreur classique est un transporteur qui ne matche plus le contexte (zone, groupe client B2B, poids, prix) après changement de règles. Pour les catalogues B2B, la combinaison groupes/prix/conditions peut produire des “aucun transporteur disponible” difficiles à reproduire si vous testez avec le mauvais groupe : PrestaShop B2B : groupes clients, tarifs, devis et commandes en gros.

Exemple concret (très courant) : un marchand active un transporteur type Colissimo/Mondial Relay, puis restreint sans le vouloir à un groupe (B2C), ou oublie une tranche poids/prix. Résultat : au checkout, “aucun transporteur disponible” pour certains paniers seulement (selon poids). La bonne approche est d’identifier le panier minimal qui reproduit, puis de vérifier tranches, zones, restrictions et règles de gratuité.

Pour le stock, les pannes “fantômes” viennent des écritures concurrentes (import, ERP, commandes) et des sources de vérité multiples. Si vous avez une intégration, formalisez la source de vérité et la fréquence de synchronisation, sinon vous créez de l’incohérence structurelle. Références : PrestaShop intégration ERP PIM : définir la source de vérité et les flux et Intégration ERP e‑commerce : architecture API, webhooks et files RabbitMQ.

Pannes (21–25) classées par symptôme

“Ajouter au panier” ne fait rien — JS cassé ou token/session; testez sans modules, check console; corrigez conflit JS, purge cache, validez cookies.

Si ça marche sur une fiche produit et pas une autre, suspectez un module/hook conditionnel (produits, catégories, groupes).

Panier qui se vide — sessions non persistantes, cookies bloqués, SameSite; alignez domaine, HTTPS, stockage session (Redis), vérifiez LB.

Très fréquent après ajout d’un LB ou changement de domaine : sessions non partagées = panier « aléatoire ».

Aucun transporteur disponible — règles zone/groupe/poids/prix; reproduisez avec le bon groupe/adresse; corrigez tranches, zones, restrictions.

Vérifiez aussi les restrictions produit (certaines catégories/produits exclus transporteur).

Taxes incohérentes — règles taxe/adresse de livraison vs facturation; vérifiez PS_TAX_ADDRESS_TYPE, règles pays/état, exemptions groupes.

En B2B intra-UE, attention aux exemptions selon TVA intracom et paramétrage pays/états.

Stock négatif / survente — sync ERP asynchrone, concurrence commande/import; verrouillez par file (queue), appliquez stock “réservé”, auditez écritures.

Décidez explicitement : stock « PrestaShop maître » vs « ERP maître », sinon vous ne corrigez jamais durablement.

Symptôme : paiement, emails, webhooks et services externes (Stripe, SMTP, ERP)

Quand le paiement échoue, la lecture des logs applicatifs ne suffit pas : vous avez au moins trois systèmes (front, PSP, webhooks) et des états asynchrones. Un paiement “refusé” côté client peut être un 3DS raté, un callback non reçu, ou une commande créée sans validation. Instrumentez la corrélation (id panier/commande, id transaction, id webhook) dès maintenant, sinon vous ne dépannez qu’au cas par cas.

En Europe (et donc en France), l’authentification forte (3DS/3DS2 selon les cas) rend les scénarios d’échec plus variés : redirections, iframes, callbacks, états « pending ». Votre dépannnage doit donc distinguer :

échec avant création commande (JS, session, retour PSP),
échec après création commande mais avant validation (webhook manquant),
double notification (webhook rejoué) → risque de doublons si pas d’idempotence.

Les emails sont le deuxième gros point de friction. En PrestaShop 9, la migration vers Symfony Mailer remplace SwiftMailer (voir PrestaShop 9.0 : migration Swift Mailer vers Symfony Mailer). Sur PrestaShop 8, beaucoup de boutiques ont encore une configuration SMTP “optimiste” (port bloqué, TLS mal négocié, DNS SPF/DKIM absent). Résultat : emails “envoyés” côté app, jamais livrés.

Point pratique côté France : certains environnements (hébergeur mutualisé, firewall d’entreprise) bloquent le port 25 sortant. Dans ce cas, même si PrestaShop “envoie”, la livraison ne part pas. La solution propre est de passer par un relay SMTP autorisé (587/465 selon le provider) et d’améliorer la délivrabilité (SPF/DKIM/DMARC).

Sur les intégrations (paiements, marketplaces, ERP), la panne la plus coûteuse est le webhook silencieux (HTTP 200 renvoyé mais traitement KO, ou inverse). Traitez les webhooks comme une API : signature, idempotence, retry, stockage brut de l’événement, et monitoring. Pour Stripe/Wallets, vous avez un point d’entrée solide : Modules PrestaShop : Apple Pay, Google Pay et Amazon Pay via Stripe.

Pannes (26–30) classées par symptôme

Retour paiement → panier, pas de commande — callback/module non exécuté, session perdue; consultez logs module + PSP, validez HTTPS, testez en mode sandbox.

Vérifiez si le PSP indique « payment succeeded » : si oui, cherchez côté webhooks/validation commande.

Webhooks Stripe 400/500 — route protégée, signature invalide, timeout DB; journalisez payload, validez secret, rendez le handler idempotent et rapide (queue).

Règle d’or : répondre vite (200) après validation signature, puis traiter async.

Apple Pay/Google Pay invisibles — domaine non vérifié, TLS/CSR, conditions Stripe; vérifiez domain association, certificats, country/currency, navigateurs supportés.

Pensez aussi aux restrictions navigateur (ex. Apple Pay surtout Safari) et au contexte (panier, devise, pays).

Emails non reçus — SMTP refusé ou délivrabilité (SPF/DKIM/DMARC); vérifiez logs SMTP, test swaks, publiez DNS, surveillez bounces.

Distinguez envoi (SMTP accepté) et délivrabilité (spam/soft bounce).

Sync ERP crée doublons/états incohérents — absence d’idempotence et de “source de vérité”; imposez des clés métier stables, versionnez les événements, ajoutez une DLQ.

Un flux robuste prévoit : retry, dead-letter, et possibilité de rejouer proprement.

Pour industrialiser ce dépannage boutique en ligne, terminez chaque incident par un post-mortem minimaliste : symptôme, cause racine, détection (alerting), action corrective (code/config), action préventive (tests/CI/CD). Sur PrestaShop, ce sont rarement des “bugs du core” : ce sont des effets de bord de modules, de déploiements incomplets, ou d’infra sous-dimensionnée. Si vous êtes en GitOps/K8s, alignez vos runbooks avec vos manifests et checklists (voir Migration PrestaShop vers Kubernetes : checklist GitOps et pièges courants).

Une bonne discipline opérationnelle consiste aussi à conserver, pour chaque panne récurrente, un « kit de preuves » : 1 graphe (latence/5xx), 1 extrait de log, 1 reproduction, 1 diff de config/déploiement. C’est ce qui transforme un dépannage artisanal en exploitation maîtrisée.