Mettre à jour PrestaShop sans casser sa boutique

Mettre à jour PrestaShop sans casser sa boutique

Une mise à jour PrestaShop mal préparée peut bloquer le tunnel de commande d'une boutique en production. Contrairement à WordPress, PrestaShop repose sur un mécanisme d'overrides et de modules tiers que le module d'upgrade ne désactive pas de lui-même — chaque fichier de surcharge PHP qui survit à la mise à jour est une source potentielle de conflit. Ce guide détaille chaque étape de la procédure, la marche à suivre en cas d'échec, et les dix catégories de modules les plus souvent responsables des incidents lors des montées de version 8.x.

Pourquoi les mises à jour PrestaShop sont plus risquées qu'une mise à jour WordPress

Overrides PHP et thèmes Smarty : les deux sources principales d'incidents

PrestaShop permet aux développeurs de surcharger les classes core en déposant leurs personnalisations dans override/classes/ et override/controllers/. Ces fichiers survivent à la désinstallation du module qui les a créés. Lorsque le core change, les overrides qui ciblaient les mêmes méthodes entrent en conflit silencieusement : pas d'erreur fatale immédiate, mais un comportement inattendu sur le panier ou la page de paiement.

Le moteur de templates Smarty ajoute une couche supplémentaire : tout module qui injecte son propre fichier .tpl dans le thème cesse de fonctionner si le thème est mis à jour en même temps. La règle de base est de ne jamais mettre à jour le core et le thème dans la même opération.

Version mineure (8.x.y) vs version majeure (vers 9.x) : quelle différence ?

Une version mineure — 8.1.6 vers 8.1.7 par exemple — n'introduit pas de rupture d'API. Les modules natifs se mettent à jour automatiquement ; les modules tiers restent généralement fonctionnels. Une version majeure est une autre opération : PrestaShop 9 a supprimé les hooks legacy de la page produit, la classe PrestaShopAutoload et les hooks de connexion en back-office. Tout module qui dépend de ces éléments cesse de fonctionner sans une mise à jour spécifique de sa propre version.

Pour une migration vers PS 9, l'audit de compatibilité des modules doit précéder l'ouverture du module d'upgrade de plusieurs semaines. Pour les versions mineures 8.x, une fenêtre de maintenance d'une à deux heures suffit, à condition de suivre la procédure ci-dessous.

Procédure de mise à jour sécurisée

1. Sauvegarde complète — fichiers et base de données

Avant toute opération, une sauvegarde complète est le seul filet de sécurité fiable. Elle couvre deux périmètres distincts :

• Fichiers : répertoire racine de PrestaShop (core, modules, thème, uploads), exporté via FTP ou snapshot de volume chez votre hébergeur.
• Base de données : export SQL complet depuis le back-office (Paramètres avancés → Sauvegarde BDD) ou via mysqldump en ligne de commande.

Sur un parc de boutiques, l'automatisation des sauvegardes nocturnes garantit qu'une archive de moins de vingt-quatre heures est disponible avant chaque intervention. C'est la condition pour lancer une mise à jour sans improviser le plan de reprise.

2. Inventaire des overrides et mode maintenance

Listez les fichiers présents dans override/ avant de lancer l'upgrade. Pour chaque fichier, identifiez le module d'origine et vérifiez sa compatibilité avec la version cible. Les overrides orphelins — ceux dont le module a été désinstallé depuis — doivent être supprimés manuellement : ils resteraient actifs et provoqueraient des conflits que le module d'upgrade ne signale pas.

Activez ensuite le mode maintenance depuis Paramètres de la boutique → Maintenance. Ne lancez pas la mise à jour en pic d'activité : choisissez tôt le matin ou pendant une période creuse, quand le volume de commandes est minimal.

3. Paramètres recommandés pour le module 1-Click Upgrade

Le module autoupgrade officiel de PrestaShop expose plusieurs options critiques. Ces quatre paramètres doivent être vérifiés avant de lancer l'opération :

Paramètre	Valeur recommandée	Raison
Désactiver les modules non natifs	Oui	Isole les modules tiers pendant le remplacement des fichiers core
Désactiver les overrides	Oui	Évite les conflits de méthodes au moment de la mise à jour
Fichiers par lot (max_files_per_batch)	400	Réduit le risque de timeout sur hébergement partagé
Sauvegarde intégrée du module	Activée	Alimente le rollback depuis l'interface en cas d'erreur

Laissez le module créer sa propre sauvegarde même si vous en avez déjà une externe : c'est elle que le rollback intégré utilisera en cas d'erreur pendant l'opération.

4. Tests post-mise à jour avant de lever la maintenance

Après la mise à jour, avant de lever la maintenance, vérifiez dans cet ordre :

1. Accès au back-office : connexion, liste des commandes, catalogue produits.
2. Catalogue côté front : fiche produit, images, déclinaisons, moteur de recherche interne.
3. Tunnel de commande complet : ajout au panier, choix du transporteur, paiement en mode test, confirmation de commande et réception de l'email transactionnel.
4. Réactivation des modules tiers un par un : commencez par les modules SEO et finissez par les modules analytics — les derniers à réactiver, les premiers à isoler en cas de problème.
5. Vidage du cache : Paramètres avancés → Performance → Vider le cache.

Rollback : procédure si quelque chose tourne mal

Deux scénarios appellent un rollback immédiat : une erreur critique durant l'upgrade, ou un tunnel de commande cassé découvert après remise en ligne.

1. Via l'interface 1-Click Upgrade : le module propose le rollback automatiquement en cas d'erreur durant le processus.
2. Via la ligne de commande : php bin/console backup:restore --backup=[nom-du-backup] <dossier-admin>
3. Restauration manuelle : remplacez les fichiers par ceux de votre sauvegarde FTP, restaurez la base de données depuis le dump SQL, puis videz le cache d'op-code côté serveur.

Après tout rollback, documentez précisément ce qui a déclenché l'échec — module impliqué, override en cause, message d'erreur exact — avant de relancer. Un module incompatible désactivé au préalable peut suffire à débloquer la mise à jour suivante sans recommencer depuis le début.

Les 10 catégories de modules à surveiller lors d'une MAJ 8.x

La majorité des incidents post-MAJ provient d'un module tiers incompatible. Les catégories suivantes concentrent les signalements les plus fréquents lors des montées de version 8.x, avec le point d'action pour chacune.

#	Catégorie de module	Symptôme type	Workaround
1	Modules de paiement (Stripe, Mollie, PayPal sur mesure)	Page de paiement vide ou erreur sur le checkout	Mettre à jour le module avant le core ; vérifier la version compatible dans l'espace partenaire de l'éditeur
2	Modules transporteurs (Colissimo, Mondial Relay, DPD)	Aucun mode de livraison affiché au panier	Appliquer la mise à jour du module avant celle du core ; tester avec une commande fictive à faible poids
3	Modules de checkout one-page	Page commande blanche ou boucle de redirection	Les hooks de la page commande changent à chaque version mineure 8.x ; contacter l'éditeur pour un patch ciblé avant la mise à jour
4	Modules SEO et balises meta	Titles vides, erreur sur les classes Product ou Category	Supprimer les overrides issus du module dans override/classes/ avant la mise à jour du core
5	Modules de fidélité et points de récompense	Total du panier erroné, page commande bloquée	Overrides sur la classe Cart : tester tout le tunnel avec une commande incluant des points en environnement de staging avant la production
6	Modules d'avis clients (Trusted Shops, Avis Vérifiés)	Bloc absent, erreur JavaScript en console	Dépendance jQuery : vérifier la version chargée par le thème après mise à jour du core
7	Modules de personnalisation produit (gravure, configurateur visuel)	Champs de personnalisation absents ou données de commande incomplètes	Vérifier l'intégrité des tables personnalisées en base de données après migration ; conserver un dump ciblé avant l'opération
8	Modules d'import/export catalogue	Erreur SQL sur colonnes manquantes ou types modifiés	Ces modules accèdent aux tables via des requêtes directes : comparer le schéma avant et après mise à jour pour identifier les colonnes supprimées ou renommées
9	Modules analytics avancés et GTM	Tracking cassé, erreurs en console, events manquants	Injectés via les hooks displayHeader et displayFooter : réactiver en dernier, après validation complète du tunnel de commande
10	Connecteurs ERP et gestion des stocks tiers	Stocks non synchronisés, commandes orphelines dans l'ERP	Ces connecteurs appellent l'API interne directement : déclencher une synchronisation manuelle après la mise à jour et comparer les niveaux de stock avant remise en production

Automatiser la veille des mises à jour PrestaShop en agence

Sur un parc de plusieurs boutiques, exécuter cette procédure manuellement pour chaque client n'est pas viable. La plateforme de mises à jour Sentinelo détecte les nouvelles versions disponibles pour les modules PrestaShop dès leur publication et conserve une sauvegarde nocturne chiffrée disponible avant chaque intervention. Le core et les thèmes PrestaShop sont signalés sans être appliqués automatiquement : c'est votre équipe qui décide du moment et réalise les tests.

Pour structurer le processus complet — de la détection à la validation post-déploiement — la politique de mises à jour pour les agences détaille comment segmenter les boutiques par niveau de risque et planifier les interventions. La checklist de maintenance PrestaShop couvre les vérifications régulières à inclure dans chaque contrat.

Pour une prise en charge complète — surveillance, sauvegardes automatiques, alertes et traçabilité des interventions — découvrez l'offre de maintenance PrestaShop de Sentinelo.