Novembre 2026

Mise à jour PrestaShop : la check-list pour vérifier le tunnel de commande juste après

AgencesParcours

Une mise à jour de PrestaShop, d’un module ou du thème peut casser le panier sans erreur visible. Voici quoi vérifier juste après, dans l’ordre.

Le back-office affiche « Mise à jour réussie ». La page d’accueil s’ouvre. Pourtant, le bouton « Ajouter au panier » ne fait plus rien, ou le module de paiement a disparu de la dernière étape. Une mise à jour de PrestaShop touche le cœur, les modules et le thème en même temps. Le problème se voit rarement au premier coup d’œil.

Avant la mise à jour

• Sauvegardez la base et les fichiers, et vérifiez que la sauvegarde se restaure.
• Notez les versions de PrestaShop, de PHP, du thème et des modules de paiement et de livraison.
• Faites d’abord la mise à jour sur une copie de la boutique, si vous en avez une.
• Choisissez une heure creuse, et prévenez le client du créneau.

Juste après : le tunnel, étape par étape

• Videz le cache : Paramètres avancés > Performances. Un ancien cache masque souvent l’erreur, ou la crée.
• Fiche produit : ajoutez au panier un produit simple, puis un produit à déclinaisons.
• Panier : le total est supérieur à zéro, et un bon de réduction s’applique.
• Commande : adresse, transporteurs avec un prix pour chaque zone, puis la page de paiement.
• Paiement : chaque module de paiement est encore proposé, en mode réel et pas en mode test.
• Compte client : connexion et création de compte marchent toujours.
• Back-office : Paramètres avancés > Logs ne montre pas de nouvelle erreur, et aucun module n’est désactivé.
• Passez une vraie commande de test, et vérifiez que l’e-mail de confirmation arrive.

Le piège : tout marche juste après, et casse plus tard

Une check-list dit que tout marchait à 10 h. Elle ne dit rien de 16 h, quand le cache se reconstruit, qu’une tâche planifiée tourne ou qu’un module se met à jour seul. Le serveur répond toujours, et un outil d’uptime reste vert. Seul un parcours rejoué jusqu’au bout voit que le panier ne marche plus.

C’est le rôle de Flow. Un vrai navigateur ouvre la boutique, ajoute un produit au panier, vérifie que le total est supérieur à zéro et va jusqu’à la page de paiement. Il ne paie rien et ne saisit que des valeurs de test. Si une étape casse, l’alerte arrive avec la capture de l’étape en panne.

Rejouer le Flow juste après chaque mise à jour

Le module Pathly pour PrestaShop fait ce rejeu à votre place. Il voit la mise à jour de PrestaShop ou d’un module, puis demande un passage du Flow une fois la mise à jour finie. Il compare aussi les versions installées, au plus toutes les cinq minutes, quand un administrateur ouvre le back-office. Il marche de PrestaShop 1.7.7 à 9.

À l’installation, collez une clé d’API : le Ping de la boutique est créé. Lumi, l’assistant de Pathly, reconnaît PrestaShop et prépare le Flow du tunnel, et vous le validez. L’état du Ping et du Flow s’affiche dans le tableau de bord de PrestaShop.

Flow passe-t-il une vraie commande ?

Non. Il s’arrête à la page de paiement. Il ne paie rien et ne saisit que des valeurs de test. Chaque passage laisse un panier de test : excluez-le de vos relances de panier abandonné.

Le module est-il obligatoire pour utiliser Flow ?

Non. Flow ouvre la boutique depuis l’extérieur, comme un visiteur. Le module ajoute le rejeu après chaque mise à jour et l’état dans le tableau de bord.

Que voit Pathly de la boutique ?

Rien avant qu’un administrateur enregistre une clé. Ensuite, seulement l’adresse de la boutique et les versions de PrestaShop et du module. Aucune donnée de client ni de commande.

Faut-il une copie de la boutique pour tester ?

C’est mieux pour une mise à jour majeure. Si la copie a sa propre adresse, elle peut avoir son propre Flow. Le contrôle juste après la mise en production reste indispensable.