PrestaShop : modernisation et reprise de boutique avec déploiements automatisés

Table des matières :

1. Reprise d’une boutique PrestaShop : auditer pour moderniser sans casser la prod
2. Standardiser l’exécution : environnements, dépendances Composer et configuration
3. CI PrestaShop : quality gates (tests, ps-validator, sécurité) avant de déployer
4. Déploiements automatisés : stratégie artifact-based, atomique, et gestion des états (cache, sessions, fichiers)
5. Exploitation post-modernisation : observabilité, rollback, patches et performance continue

Reprise d’une boutique PrestaShop : auditer pour moderniser sans casser la prod

Une reprise de boutique PrestaShop “qui tourne” n’est pas un projet de refonte, c’est un projet de réduction de risque. Avant de parler CI/CD, commencez par un audit d’attaque : version PrestaShop (souvent 1.6/1.7 legacy), version PHP effective, état Composer, overrides, thèmes, modules (et surtout qui les maintient). Si vous ne figez pas cet inventaire, vous déployez à l’aveugle et vous payez la dette technique en incidents. Pour cadrer la partie code, la checklist d’audit thème/modules/hooks/overrides de l’article Migration PrestaShop : checklist d’audit thème, modules, hooks et overrides est un bon point de départ.

Pour éviter l’audit “au feeling”, formalisez un inventaire exploitable (et actionnable) dès la première semaine. Par exemple, sur une boutique FR/UE qui encaisse du paiement en ligne (module PSP), le risque business d’un incident est souvent maximal sur panier → checkout → paiement : ce sont les premiers parcours à cartographier et à tester après chaque changement.

Voici un tableau simple qui permet d’aligner technique et exploitation sans alourdir le projet :

Élément	Ce qu’il faut capturer	Pourquoi c’est critique en reprise
Version exacte PrestaShop + patch	PS_VERSION, changelog réel des fichiers	Certaines régressions/bugs sont patchées “à la main” en prod sans traçabilité
PHP + extensions	Version effective (FPM/CLI), intl, gd/imagick, opcache	Un php -v en SSH ne reflète pas toujours le PHP-FPM qui sert le front
Modules (liste + provenance)	Marketplace / custom / fork, mainteneur, compatibilité PS/PHP	Le core casse rarement “tout seul”, les modules oui (surtout paiement, recherche, facettes)
Overrides	Liste, classes touchées, date de dernière modif	Source n°1 d’effets de bord et d’incompatibilités lors des upgrades
Thème + assets	Pipeline de build, dépendances Node (si présent), surcharges	Une modernisation “safe” exige de pouvoir reconstruire le thème à l’identique
Crons & jobs	Commandes, fréquence, serveur, logs	Beaucoup d’incidents viennent de jobs non documentés (réindexation, exports, relances mail)
Modifs direct prod	Fichiers modifiés en FTP/SSH, patchs core	Tant que ce point n’est pas traité, Git et CI/CD ne reflètent pas la réalité

Concrètement, le risque n’est pas “le core PrestaShop” mais l’écosystème installé autour : modules qui patchent des classes via override, SQL exécutés en post-install sans idempotence, jobs cron non documentés, et modifications “direct prod” (fichiers modifiés en FTP). Une modernisation sérieuse vise à supprimer ces points de friction : réduire les overrides (ou au minimum les tracer), isoler le code métier dans des modules propres (cf. Module PrestaShop sans override : méthode de cadrage, tests et livraison du code), et rendre les déploiements reproductibles.

Un point souvent sous-estimé en reprise : détecter ce qui a été modifié “hors process”. Sans forcément lancer un chantier lourd, vous pouvez déjà :

• hash/ls -lt des répertoires sensibles (classes/, controllers/, override/, thème, modules custom) et repérer les fichiers “réveillés” récemment ;
• comparer une archive prod à une release officielle (même major/minor) pour identifier des patchs core ;
• lister les modules désactivés mais présents (ils reviennent souvent hanter les upgrades).

Sur la partie données, l’audit ne peut pas se limiter à “la base est grosse”. Mesurez : taille InnoDB, tables qui grossissent vite (connections, logs, facettes), index manquants, requêtes lentes et locks. Sans ça, votre pipeline va “déployer vite” vers une prod qui reste lente. Une bonne séquence : activer des métriques de requêtes (slow query log), analyser les plans avec EXPLAIN et corriger les index. Références utiles : Logs Amazon Lightsail : activer general log et slow query MySQL et Index MySQL : composer, mesurer avec EXPLAIN et optimiser les requêtes.

Pour objectiver rapidement “où part la perf”, quelques requêtes d’audit très simples suffisent souvent à mettre le doigt sur 80% des problèmes (à exécuter idéalement sur un clone/staging) :

-- Top tables par taille (approx) : repérer logs, facettes, stats, sessions, etc.
SELECT
  table_name,
  ROUND((data_length + index_length) / 1024 / 1024, 1) AS size_mb
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC
LIMIT 20;

-- Tables sans index (ou presque) : très utile sur des tables custom de modules
SELECT table_name, COUNT(*) AS nb_indexes
FROM information_schema.statistics
WHERE table_schema = DATABASE()
GROUP BY table_name
ORDER BY nb_indexes ASC
LIMIT 20;

L’objectif n’est pas de “tuner MySQL” immédiatement, mais de savoir si la modernisation va buter sur (ex.) une table de logs qui explose, des facettes qui reconstruisent des index trop souvent, ou des locks liés à des tâches planifiées.

Standardiser l’exécution : environnements, dépendances Composer et configuration

Pour 2026, la base saine côté runtime est typiquement : PrestaShop 8.2.x ou 9.1/9.2, PHP 8.2+ (souvent 8.3 en 9.x), MySQL 8 / MariaDB récent, et un serveur web Nginx + PHP-FPM. Tout le reste (cache, search, CDN) est ajustable. Si vous partez d’une 1.6/1.7, la modernisation peut être une migration progressive vers 8/9 ; la procédure manuelle détaillée est dans Mise à jour PrestaShop : procédure de migration manuelle 1.6/1.7 vers 8.x. À ce stade, le point critique est de séparer ce qui relève du code (versionnable) de ce qui relève de l’environnement (secrets, endpoints, stockage).

Dans un contexte France/UE, cette séparation code/config a aussi un impact très concret côté conformité et sécurité : les secrets (clés API, SMTP, tokens de paiement, clés de chiffrement cookies) ne doivent pas “traîner” dans un dépôt, ni dans des dumps de staging partagés trop largement. En reprise, le plus gros gain n’est pas une techno “à la mode”, c’est d’obtenir des environnements :

• reproductibles (mêmes commandes, mêmes dépendances) ;
• isolés (staging ≠ prod, clés distinctes, endpoints distincts) ;
• traçables (qui a déployé quoi, quand, avec quelle version).

Le cœur PrestaShop n’est pas nativement “12-factor”. Il écrit sur disque (cache, compilations Smarty, images), mélange config legacy et Symfony, et n’a pas de mécanisme de migrations applicatives unifié (au sens Django/Rails). L’objectif n’est pas de le “rendre parfait”, mais de le contenir. La contrainte à poser dès le départ : une base de code versionnée, plusieurs déploiements.

Dans PrestaShop, ça se traduit par : un dépôt Git unique (core + thème + modules custom, ou core en sous-module/vendor selon votre stratégie), et des environnements distincts (dev/staging/prod) avec la config hors dépôt. Sur 8.x, la config sensible est en pratique dans app/config/parameters.php (chemin variant selon l’arborescence), plus des variables d’environnement si vous avez industrialisé. Ne versionnez jamais parameters.php ; injectez-le au déploiement via un coffre (SOPS, Vault, secret store CI) ou un mécanisme d’“environment files”. Si vous êtes sur une stack Symfony (PrestaShop 8/9 s’appuie largement dessus), les problèmes classiques d’env/cache/Composer sont couverts dans Symfony 7 : dépannage erreurs 500, var/cache, Composer et variables d’environnement.

Quelques conventions qui évitent des “prises de tête” dès les premiers déploiements :

• Composer : figer via composer.lock, installer avec --no-dev en prod, et traiter les scripts (post-install) comme du code à risque (ils doivent être déterministes).
• Fichiers persistants : décider très tôt de ce qui vit dans shared/ (images, upload, download, logs) et de ce qui doit rester strictement dans une release.
• Staging réaliste : si vous avez une boutique multi-langues/multi-devises ou multiboutique, le staging doit refléter ces paramètres (sinon vous validez des déploiements “sur un monde simplifié”).

CI PrestaShop : quality gates (tests, ps-validator, sécurité) avant de déployer

Un déploiement automatisé sans “gates” n’est qu’un moyen plus rapide de casser la prod. La modernisation passe donc par une CI qui produit un artefact (ou une image) après une série de contrôles minimaux : lint PHP, composer validate, analyse statique si possible (PHPStan/Psalm selon maturité), et tests (unitaires + tests d’intégration ciblés sur ce que vous touchez). Le point important en reprise : vous n’aurez pas 80% de couverture en 2 semaines ; par contre vous pouvez mettre en place 5–10 tests de non-régression sur checkout/panier/prix/taxes, ce qui a un ROI immédiat.

Pour rendre ces “gates” concrets, vous pouvez partir d’un socle minimal qui passe sur la majorité des reprises :

• Qualité PHP : php -l sur les fichiers modifiés, et un standard de code (même basique) pour limiter les diffs “bruyants”.
• Dépendances : composer validate + installation en mode CI (échec si lock incohérent).
• Tests ciblés : scénario panier (ajout/suppression), calcul TVA (au moins 1 cas FR + 1 cas UE si vous vendez hors France), création commande (même sans paiement réel en CI), génération facture si vous l’utilisez.
• Artefact : un zip/tar “prêt à déployer” qui contient exactement ce qui a été testé.

Un mini-scenario typique en reprise : vous corrigez un bug de prix lié à une règle panier + module promo. Sans tests, vous “validez” en back-office, puis vous cassez un cas de TVA ou un affichage en front. Avec 5 tests d’intégration (même très simples), vous attrapez la régression avant prod, et vous réduisez immédiatement le risque.

Pour les modules, ne sautez pas l’étape de validation PrestaShop. L’outil officiel (ps-validator) s’intègre en ligne de commande et en CI/CD. Même si vous ne visez pas une publication marketplace, il détecte des patterns dangereux (structure, compatibilité, erreurs courantes) et vous force à normaliser. Voir : ps-validator : intégration CI/CD du Validator PrestaShop en terminal. En reprise, c’est particulièrement utile pour repérer des modules “historiques” qui ont survécu par chance (et parce que personne n’osait les toucher).

Enfin, la sécurité doit être intégrée au pipeline, pas gérée “à côté”. Au minimum : dépendances Composer avec audit (composer audit), scan des images si vous conteneurisez, et une veille sur PrestaShop + modules critiques (paiement, facettes, recherche). En reprise, imposez aussi des règles “basiques mais non négociables” :

• interdiction de pousser des fichiers en FTP sur prod (sauf procédure d’urgence documentée) ;
• accès admin protégé (IP allowlist/VPN si possible, ou au minimum 2FA si disponible via votre stack) ;
• rotation des secrets lors de la reprise si vous n’avez pas de garantie sur leur diffusion historique.

Si vous cherchez un compromis réaliste : commencez par sécuriser le chemin de livraison (CI → artefact → déploiement), puis durcissez progressivement le contenu (tests, analyse, scan). C’est plus efficace que de vouloir tout “parfait” dès le premier mois.

Déploiements automatisés : stratégie artifact-based, atomique, et gestion des états (cache, sessions, fichiers)

Le déploiement automatisé PrestaShop qui tient en production repose sur un principe simple : ne pas builder en production. Vous construisez (Composer, assets thème, minification éventuelle) dans la CI, vous produisez un paquet versionné (artefact) et vous déployez de façon atomique (nouveau répertoire de release + switch de symlink). C’est la différence entre “mise à jour” et “déploiement”. Pour une approche CI/CD orientée environnements éphémères et démos, voir PrestaShop CI/CD : générer des démos à la demande en minutes.

Une structure de déploiement éprouvée (inspirée Capistrano/Deployer) fonctionne bien sur PrestaShop 8/9 :

• releases/<timestamp>/ : code + vendor + thème buildé
• shared/ : fichiers persistants
• img/ (ou au minimum img/ utilisateur), upload/, download/
• logs applicatifs si vous n’exportez pas vers stdout
• app/config/parameters.php / secrets
• current -> releases/<timestamp>/ : symlink atomique

Ce découpage évite le piège classique : un rsync “par-dessus” qui laisse des fichiers orphelins, des classes PHP d’une version et des templates d’une autre. Sur un checkout cassé, c’est exactement le genre de mismatch qui vous donne une erreur 500 à chaud (diagnostic rapide dans Erreur 500 PrestaShop : 10 causes fréquentes et solutions rapides).

Pour rendre le déploiement vraiment “atomique” côté expérience utilisateur, clarifiez aussi la gestion des états :

• sessions : si elles sont en fichiers, elles dépendent du serveur (problématique en multi-nœuds) ; si elles sont en Redis, vérifiez la stratégie d’expiration et l’impact d’un flush ;
• filesystems : les images produit/catégorie et les uploads doivent pointer vers shared/ (sinon vous “perdez” des médias entre releases) ;
• crons : un cron qui pointe vers current/ suit automatiquement la release, mais attention aux tâches longues (elles peuvent chevaucher un déploiement).

La partie la plus mal gérée en déploiement PrestaShop reste le cache (Smarty/Symfony/OPcache/Redis/Varnish/CDN). Une séquence correcte, testée en staging, ressemble à : mettre la boutique en maintenance (si nécessaire), basculer le symlink, exécuter un php bin/console cache:clear (et potentiellement warmup), purger les caches applicatifs (Redis si utilisé), puis seulement rouvrir. Si vous n’avez pas de stratégie cache claire, vous aurez des comportements “fantômes” (prix obsolètes, templates pas à jour, facettes incohérentes). Références : Cache PrestaShop : stratégie 2026 OPcache, Redis, Varnish et CDN et Cache PrestaShop : erreurs fréquentes et bonnes pratiques multiboutique.

Une checklist de déploiement “sans surprise”, adaptée aux reprises, ressemble souvent à ceci :

• Vérifier l’artefact (checksum, version, tag Git).
• Mettre en maintenance si vous déployez un changement à risque (paiement, panier, thème, override critique).
• Déployer la release dans releases/…, poser les symlinks vers shared/.
• Exécuter les commandes post-déploiement (cache clear/warmup, éventuels scripts idempotents).
• Purger les caches externes (ex. reverse proxy/CDN) après validation.
• Smoke tests rapides : page catégorie, page produit, ajout panier, début checkout, login BO.
• Sortir de maintenance, monitorer 10–15 minutes (erreurs 5xx, latence, logs).

Exploitation post-modernisation : observabilité, rollback, patches et performance continue

Une reprise modernisée n’est pas “terminée” quand le pipeline tourne. Elle est terminée quand vous pouvez diagnostiquer un incident en moins de 10 minutes et revenir en arrière en moins de 5. Pour ça, vous devez instrumenter : logs applicatifs, logs web (access/error), slow queries, métriques PHP-FPM, et idéalement une supervision type Netdata/Prometheus.

En exploitation, les signaux qui aident vraiment sur PrestaShop (et qui se prêtent bien à une reprise) :

• taux d’erreurs HTTP 5xx et 4xx sur les routes checkout ;
• temps de réponse (TTFB) sur produit/catégorie/panier ;
• saturation PHP-FPM (process busy, queue) ;
• top requêtes lentes + fréquence ;
• volume d’erreurs dans les logs applicatifs après une release (corrélé au tag déployé).

Le rollback doit être un first-class citizen : avec un déploiement atomique par symlink, revenir en arrière est souvent un simple switch vers la release précédente. Là où ça se complique, c’est la base de données : si un module ou une mise à jour a modifié le schéma ou les données, le rollback code ne suffit plus. Votre stratégie doit donc expliciter : (1) quelles opérations DB sont “forward-only”, (2) comment vous sauvegardez/restaurez, (3) comment vous testez des migrations en staging avec un dump réaliste. Sur des changements d’infra DB (MySQL 5.7 vers 8, typiquement), le déroulé staging + tests de charge est dans MySQL migration 5.7 vers 8 : procédure, staging et tests de charge.

En pratique, vous pouvez cadrer avec deux indicateurs simples (très parlants pour les métiers) :

• RPO (perte de données acceptable) : ex. 15 minutes si vous sauvegardez/reppliquez fréquemment, ou 24 h si vous êtes au strict minimum.
• RTO (temps de retour en service) : ex. 30 minutes si vous avez un rollback + restauration testée.

Même sans infra “enterprise”, le fait de tester une restauration (au moins trimestrielle) change radicalement la qualité d’exploitation, surtout sur des boutiques qui ont vécu longtemps sans procédures.

Enfin, la modernisation doit intégrer un cycle performance + SEO, parce que PrestaShop est très sensible à la latence back (TTFB) et à la santé de la base. Côté perf, profilez avant/après, ciblez les endpoints critiques (catégorie, produit, panier, paiement) et traquez les régressions à chaque release (profilage PHP/Symfony : Optimisation code source : audit performance PHP/Symfony avec profilage). Côté SEO en reprise, le déploiement automatisé doit préserver les URL et les balises : redirections 301 contrôlées, canonical/hreflang cohérents, et pas de robots.txt “accidentel” en prod. Voir Référencement PrestaShop : optimiser fiches produits, catégories, canonical et hreflang.

Un piège fréquent en reprise : “optimiser la perf” en touchant au cache, puis découvrir une semaine plus tard un impact SEO (pages indexées avec variantes, facettes ouvertes, duplication). D’où l’intérêt d’industrialiser aussi les vérifications : à chaque release, contrôlez quelques invariants (status code, canonical, noindex, robots), au même titre que vous vérifiez le checkout.

Ce rappel n’est pas décoratif : sans Git (et une discipline de branching/tagging), il n’y a pas de reprise maîtrisée, pas d’audit diff, pas de release traçable, donc pas de déploiement automatisé fiable. Et si vous poussez la modernisation plus loin (containers/GitOps), faites-le après avoir stabilisé la chaîne de build et la séparation code/config : l’article Migration PrestaShop vers Kubernetes : checklist GitOps et pièges courants illustre bien les erreurs typiques quand on “saute” des étapes.