Panier d'achat
- iKhronos
- PrestaShop
- 42 vues
L’ESSENTIEL
Aucune mise à jour n’est sans risque : c’est la préparation (inventaire, sauvegarde testée, copie, bascule planifiée et retour arrière écrit) qui limite l’interruption et rend « à jour » l’état normal d’une boutique.
Aucune mise à jour de PrestaShop n’est sans risque : l’objectif n’est pas de promettre une intervention invisible, mais de la préparer pour que les ventes s’interrompissent le moins possible et que vous sachiez revenir en arrière. Voici la checklist que nous suivons avant de toucher une boutique en production.
Pourquoi tant de mises à jour sont-elles repoussées ?
Sur le terrain, nous voyons régulièrement des boutiques qui tournent sur des versions vieilles de plusieurs années, avec des mises à jour repoussées de trimestre en trimestre. Ce constat de terrain n’a rien de statistique, mais il se répète trop souvent pour être un hasard. La mécanique est toujours la même : la mise à jour paraît complexe (thème personnalisé, modules anciens, peur de casser la vente), personne ne veut porter le risque, alors elle est reportée. Et plus elle est reportée, plus l’écart avec la version actuelle grandit, donc plus elle devient lourde à mener, donc plus elle est repoussée encore.
Cette spirale fait le lit de deux postures :
« Ça marche, ne touchons à rien »
La boutique fonctionne, alors on vit avec les failles, sur un PHP qui n’est plus maintenu, jusqu’au jour où une alerte de sécurité ou l’hébergeur force la main, comme l’a montré le cas PHP2Shell, ou jusqu’à ce que la compatibilité PHP ferme toute évolution.
« Ça marche et c’est à jour »
La mise à jour est devenue une routine maîtrisée, pas un projet redouté : la méthode ci-dessous est ce qui fait la différence.
La différence entre les deux n’est pas le courage : c’est la méthode. Une mise à jour préparée, inventoriée, testée sur copie, avec un retour arrière écrit, cesse d’être un saut dans l’inconnu. C’est ce qui permet d’intervenir régulièrement, y compris sur des dossiers laissés en attente depuis des années. La checklist ci-dessous est celle que nous appliquons pour que « à jour » redevienne l’état normal d’une boutique.
LA CHECKLIST EN 7 ÉTAPES
1. Inventorier → 2. Sauvegarder → 3. Copie de test → 4. Mettre à jour → 5. Tester → 6. Basculer → 7. Surveiller
- 1Inventorier ce qui tourneVersion de PrestaShop, version de PHP, liste des modules et du thème, surcharges éventuelles, moyens de paiement, transporteurs, connexions externes (gestion, compta, envoi). Cet inventaire conditionne tout le reste : c’est lui qui révèle les incompatibilités avant la mise à jour, pas après.
- 2Sauvegarder, puis vérifier que la sauvegarde se restaureFichiers et base de données, sur un espace distinct du serveur de production. Le point essentiel : une sauvegarde jamais restaurée est une hypothèse. Tester la restauration sur la copie avant d’intervenir évite de découvrir au pire moment qu’elle est incomplète.
- 3Préparer une copie hors productionReprendre fichiers et données sur un environnement de test, inaccessible au public et aux moteurs de recherche. C’est là que la mise à jour s’effectue d’abord : la boutique publique continue de vendre pendant ce temps.
- 4Mettre à jour sur la copie, dans un ordre maîtriséPrestaShop d’abord, puis les modules, puis le thème, en notant chaque écart (message d’erreur, comportement inhabituel, réglage perdu). Les écarts relevés sur la copie sont autant de surprises évitées en production.
- 5Tester les parcours qui font vendre
- Commande de test de bout en bout, jusqu’au paiement ;
- réception des e-mails (commande, compte client, contact) ;
- frais et options de transport ;
- création de compte et connexion client ;
- affichage et commande sur mobile.
Un paiement de test selon les modalités de l’outil de paiement évite d’encaisser réellement pendant les essais.
- 6Planifier la basculeChoisir un créneau creux, annoncer une durée réaliste, activer le bandeau de maintenance, et écrire à l’avance le plan de retour arrière : comment restaurer, qui déclenche, à partir de quel seuil de problème. Un retour arrière décidé dans l’urgence est presque toujours pire qu’un retour arrière prévu.
- 7Surveiller après la mise en ligneErreurs dans les journaux, commandes qui passent réellement, paiements reçus, e-mails envoyés, cache vidé. Les premières heures sont le moment de vérifier, pas de se reposer.
Ce qu’une mise à jour ne résout pas
La mise à jour de PrestaShop ne corrige pas le PHP du serveur, qui relève de l’hébergeur ; le cas PHP2Shell en est un exemple récent. Et selon le dossier, une mise à jour sur place n’est pas toujours la bonne voie : un écart de plusieurs versions majeures peut rendre préférable une reconstruction sur copie avec reprise des données. Ce choix se fait après l’inventaire, pas pendant la bascule.
Si votre boutique attend sa mise à jour depuis longtemps, le retard n’est pas une fatalité : c’est précisément ce genre de dossier qui se prépare, puis se traite. Et lorsqu’un événement extérieur force la main (faille, changement d’hébergement), notre retour sur une migration d’urgence vers 9.2 montre qu’une bascule rapide reste possible quand la préparation est faite. Pour la méthode complète (inventaire, copie, essais, bascule) : notre page Maintenance, migrations et développement PrestaShop. Pour un suivi régulier de votre boutique : maintenance et assistance.
Mise à jour concernée : PrestaShop. Les modalités précises (délais, contenu des essais) s’ajustent à chaque dossier ; aucune promesse de durée d’interruption n’est associée à cette checklist.