Mise à jour PrestaShop sans casser la boutique : guide pas à pas
Passer de la 8.1 à la 8.2 ou de la 9.0 à la 9.1 n'est pas un saut de version majeure, mais ce n'est pas non plus un simple clic. Nous expliquons comment le préparer, comment le répéter sur une copie, ce qui peut échouer pendant l'assistant et ce qu'il faut vérifier avant de valider la boutique.
Pour mettre à jour PrestaShop sans casser la boutique, il faut toujours suivre le même ordre : sauvegarde complète des fichiers et de la base de données, répétition de la mise à jour sur une copie de la boutique, mise à jour réelle sur un créneau de faible trafic et vérification du checkout, de l'e-mail et des modules avant de considérer le travail comme terminé. L'assistant officiel fait la partie mécanique ; ce qui évite les mauvaises surprises, c'est tout ce qu'il y a autour.
Cet article porte sur les mises à jour « de maintenance » : au sein d'une même branche (8.1 vers 8.2) ou vers la version mineure suivante (9.0 vers 9.1). Un saut de la 1.6 ou de la 1.7 vers la 9 est autre chose, un projet de migration, que nous traitons à part.
Mettre à jour ou migrer : ce n'est pas pareil
On les emploie comme synonymes et ils ne le sont pas, et les confondre conduit à mal planifier :
- Mettre à jour, c'est remplacer le cœur de PrestaShop par une version plus récente sur la même boutique. Les données, le thème et les modules restent ; la base de données s'adapte avec les scripts de la nouvelle version.
- Migrer, c'est amener la boutique vers une version aux changements profonds (ou vers un autre serveur), où le thème, une partie des modules et les overrides se refont, et où l'on conserve surtout les données.
Entre versions proches, la mise à jour est la norme et c'est ce qui est recommandé. Plus on attend, plus chaque mise à jour ressemble à une migration : davantage de modules sans version compatible, plus de changements accumulés dans le thème et plus d'écart dans la version de PHP.
Avant de toucher à quoi que ce soit : l'inventaire
Dix minutes d'inventaire font gagner des heures le jour de la mise à jour. Notez :
- La version actuelle de PrestaShop et de PHP, et la version de PHP exigée par la version cible. Consultez les prérequis de cette version avant tout : si le serveur ne les remplit pas, le changement de PHP passe en premier, lui aussi testé sur une copie.
- Le thème : s'il s'agit du thème par défaut, d'un thème enfant ou d'un thème acheté, et si quelqu'un a modifié directement ses templates.
- Les modules tiers, avec leur version et la compatibilité déclarée par l'auteur avec la version cible.
- Les overrides du dossier
override/: chacun est du code qui remplace une partie du cœur et qui peut ne plus s'emboîter. - Les modifications manuelles dans les fichiers du cœur : lignes ajoutées dans
config/, règles dans le.htaccess, protection par mot de passe du dossier d'administration. La mise à jour les écrase. - Les intégrations qui appellent la boutique : ERP, marketplaces, transporteurs, le webservice.
La sauvegarde complète, et vérifiée
L'assistant de mise à jour propose de faire sa propre sauvegarde, et c'est bien qu'il la fasse, mais ce ne devrait pas être la seule. Avant de commencer, faites votre propre sauvegarde de tous les fichiers et de la base de données, stockez-la hors du serveur et vérifiez qu'elle peut être restaurée. Une sauvegarde que personne n'a jamais restaurée est un espoir, pas une sauvegarde.
La répétition sur une copie de la boutique
La règle qui évite le plus de déboires : la mise à jour se fait d'abord sur une copie, sur un autre serveur ou dans un environnement local, avec les mêmes fichiers et la même base de données que la production. On y voit quel module échoue, quel template du thème renvoie une erreur et combien de temps prend l'opération, la donnée dont vous avez besoin pour choisir le bon créneau horaire.
Sur la copie, il faut désactiver tout ce qui peut sortir vers l'extérieur : l'e-mail (vers une boîte de test et non vers vos clients), les passerelles de paiement (en mode test), les tâches planifiées qui communiquent avec des tiers et les intégrations qui envoient les commandes à l'ERP. Une copie de la boutique avec l'e-mail réel configuré peut écrire à de vrais clients sur un simple changement d'état de commande.
Pendant la mise à jour : ce que nous avons vu échouer
L'assistant officiel de PrestaShop (le module de mise à jour en 1 clic) fonctionne bien sur la plupart des boutiques, mais certaines situations se répètent sur des boutiques réelles :
- Fermer le navigateur en cours de route. L'assistant avance par étapes depuis la page même du back-office. Si l'onglet se ferme ou si la connexion se coupe, le processus s'arrête. Laissez l'ordinateur connecté et n'y touchez pas avant la fin ; en cas d'interruption, on peut reprendre en ligne de commande, mais mieux vaut ne pas en arriver là.
- Des intégrations qui continuent d'appeler. Le mode maintenance cache la boutique aux clients, mais ne coupe pas le webservice. Un ERP qui continue de synchroniser pendant la mise à jour peut régénérer le cache pendant que l'assistant l'efface, et le processus s'arrête. Mettez les intégrations en pause avant de commencer.
- Peu de mémoire en ligne de commande. Chez certains hébergeurs, le PHP en ligne de commande dispose de moins de mémoire que celui du web. Si la mise à jour est lancée en ligne de commande, vérifiez cette limite avant.
- Des fichiers du cœur remplacés. La mise à jour remplace des fichiers comme
config/config.inc.phpou le.htaccessdu dossier d'administration. Ce qui y avait été ajouté à la main disparaît sans avertissement, y compris une protection par mot de passe du panneau. Sauvegardez-le avant et remettez-le après. - Base de données incomplète. Lors d'une montée de version mineure, nous avons vu une boutique mise à jour à laquelle il manquait des tables ou des réglages présents dans une installation neuve de cette version, et la vitrine échouait sur de nombreuses pages. C'est pourquoi la répétition doit parcourir toute la boutique, pas seulement la page d'accueil.
À la fin, il est normal que le back-office ferme la session : il faut se reconnecter.
Après la mise à jour : la liste de vérification
Une mise à jour n'est pas terminée quand l'assistant dit que tout s'est bien passé, mais quand vous avez vérifié ceci :
| Quoi vérifier | Comment | Signal d'alarme |
|---|---|---|
| Cache | Le vider depuis le back-office et, si besoin, le dossier var/cache | Pages qui affichent d'anciens contenus ou erreurs qui disparaissent au rechargement |
| Thème | Parcourir accueil, catégorie, fiche, panier, checkout et compte client, sur mobile et sur ordinateur | Blocs qui disparaissent, textes non traduits, erreurs de template |
| Modules | Ouvrir la configuration de chaque module important | Écrans blancs, avertissements de version, modules désactivés tout seuls |
| Overrides | Vérifier qu'ils sont toujours nécessaires et compatibles | Erreurs qui n'apparaissent que sur une action précise (enregistrer un produit, valider une commande) |
| Checkout | Une commande de test avec chaque moyen de paiement et de livraison | Paiement encaissé sans commande créée, transporteurs qui n'apparaissent pas |
| Vérifier que l'e-mail de confirmation de la commande de test arrive | E-mails qui ne partent pas ou partent sans modèle | |
| Journaux | Regarder les logs PHP et PrestaShop pendant les premières heures | Nouvelles erreurs absentes avant la mise à jour |
| Intégrations | Les réactiver et confirmer la première synchronisation | Commandes qui n'arrivent pas à l'ERP, stock qui ne se met pas à jour |
À quelle fréquence mettre à jour
Les versions de maintenance corrigent des bugs et, souvent, des problèmes de sécurité. Le plus sain est de ne pas laisser passer trop de temps après la sortie d'une version de votre branche, avec l'habituelle répétition préalable. Une boutique mise à jour régulièrement a des mises à jour petites et prévisibles ; une boutique qu'on ne touche qu'au bout de plusieurs années accumule les changements, et chaque mise à jour devient un projet.
Il en va de même pour les modules et pour PHP : se tenir à jour par petites étapes coûte moins cher que de tout rattraper d'un coup. Si la boutique n'a pas été touchée depuis longtemps, le plus prudent est de commencer par une revue qui dise ce qui est installé et dans quel ordre procéder.
Quand demander de l'aide
Une mise à jour mineure sur une boutique avec le thème par défaut et peu de modules peut être faite par quelqu'un d'expérimenté dans le back-office, toujours avec sauvegarde et répétition. Mieux vaut la confier à un technicien quand il y a des overrides, un thème très personnalisé, des intégrations avec un ERP ou des marketplaces, ou un volume de commandes qui ne permet pas à la boutique de tomber en panne ne serait-ce qu'une matinée. Dans notre service de migrations et mises à jour PrestaShop, nous faisons la répétition sur une copie, nous vous disons ce qui casse avant de toucher la production et nous laissons la boutique vérifiée. Et si vous préférez que quelqu'un s'en occupe régulièrement, la maintenance PrestaShop inclut les mises à jour avec leur sauvegarde et leur vérification.
Questions fréquentes
Peut-on mettre à jour PrestaShop sans perdre de données ?
Oui. Une mise à jour conserve les produits, les clients et les commandes, car elle adapte la base de données existante. Faites tout de même toujours une sauvegarde complète avant : c'est ce qui vous protège si le processus s'interrompt.
Combien de temps dure une mise à jour PrestaShop ?
Cela dépend de la taille de la boutique et du serveur. La répétition sur une copie vous donne le temps réel, et avec lui vous choisissez un créneau de faible trafic pour la faire en production.
Faut-il aussi mettre à jour les modules ?
En général oui, surtout ceux que l'auteur déclare compatibles uniquement avec certaines versions. Vérifiez la compatibilité de chacun avant de mettre à jour le cœur.
Que faire si la mise à jour échoue en cours de route ?
Ne la relancez pas à l'aveugle. Regardez à quelle étape elle s'est arrêtée : parfois on peut la reprendre, sinon on restaure la sauvegarde et on refait la répétition pour savoir ce qui l'a bloquée.