Études de cas : trois interventions PrestaShop documentées de bout en bout

Contexte

Boutique mode B2C, 5 000 commandes mensuelles, pic sur les collections capsules. Erreur 500 aléatoire sur l'étape panier, 2 à 3 % des visiteurs touchés. Les équipes marketing envoient du trafic payant : chaque erreur = une vente perdue.

Diagnostic

Analyse des logs PrestaShop (var/logs/prod.log) en 25 minutes. Cause racine : module de transport récemment mis à jour, incompatible avec PrestaShop 8.1 sur le hook actionCarrierProcess. L'erreur se déclenche uniquement sur les paniers contenant plus de 3 produits d'univers différents.

Intervention

Rollback propre du module en version précédente (8.0-compatible), patch vendor déposé pour corriger le hook, tests de non-régression sur le tunnel complet. Deux modifications appliquées en staging puis bascule en production en fenêtre de maintenance de 30 minutes.

Contexte

Plateforme B2B (pièces industrielles), 12 000 références actives, acheteurs professionnels. Site lent depuis 3 semaines, TTFB à 3,5 s, erreurs 500 aléatoires entre 2h et 6h du matin. Les équipes techniques en interne ont augmenté la mémoire PHP sans amélioration.

Diagnostic

Inspection du schéma DB : table ps_connections à 2,3 Go (80 Mo serait raisonnable), alimentée par un bot asiatique qui envoie environ 4 200 requêtes par jour depuis des IP Alibaba Cloud. Module statsdata actif, sans purge périodique. Saturation nocturne des workers PHP-FPM par les écritures stat.

Intervention

Blocage htaccess des plages IP abusives, purge ciblée des 6 tables statistiques (ps_connections, ps_connections_page, ps_connections_source, ps_guest, ps_page_viewed, ps_pagenotfound) via TRUNCATE en fenêtre basse. Désactivation du module statsdata. Cron mensuel de purge installé. Règle Cloudflare Bot Fight Mode activée en amont.

Contexte

Boutique food alimentaire haut de gamme, 8 000 produits, 40 modules actifs, thème custom complexe, multiboutique 3 pays. Version PrestaShop 1.7.6 en fin de support, compatibilité PHP 7.4 bloquant la montée d'hébergement. La bascule devait s'opérer sans interrompre les commandes abonnement (livraisons hebdomadaires).

Diagnostic

Audit complet en 2 jours : 38 modules compatibles PrestaShop 8.1 (dont 5 nécessitant une version payante à jour), 2 modules critiques sans version compatible (remplacement équivalent identifié pour chacun). Thème custom : 11 overrides à porter vers Symfony 6. 6 URL produit fortement rankées nécessitant 301 strictes.

Intervention

Migration en 3 phases sur staging dédié : import base + fichiers, portage overrides, recette tunnel complet avec tests automatisés Cypress. Plan de 301 exhaustif validé avant bascule. Fenêtre de maintenance un dimanche matin, 3h de coupure contrôlée avec page maintenance personnalisée et mode catalogue actif. Réconciliation tokens Stripe abonnements en J+1.