Maintenance corrective PrestaShop : faire corriger un bug sans en créer deux autres

Un bug PrestaShop se corrige en quatre temps : le reproduire, isoler sa cause sur une copie de la boutique, corriger cette cause, puis retester les parcours de vente sans rapport apparent. Ce dernier temps protège de la régression : une fonction qui marchait avant la correction et cesse de marcher après. Au 14 octobre 2026, la version de votre boutique décide aussi de qui corrige.

• Un bug de paiement ou de panier se chiffre en commandes perdues
• La version de PrestaShop décide de qui corrige un bug ordinaire
• La correction d’un bug PrestaShop commence par une procédure de reproduction écrite
• En attendant la correction d’un bug PrestaShop, sauvegardez avant de toucher
• Le diagnostic d’un bug PrestaShop procède par élimination sur une copie
• Un bug de panier, de paiement ou de transporteur cache parfois un réglage
• Un bug PrestaShop apparu après un changement de PHP peut tenir à la version de PrestaShop
• Un correctif de bug PrestaShop modifie la cause, hors du cœur
• La non-régression d’un correctif PrestaShop se prouve parcours par parcours
• Avant la correction d’un bug PrestaShop, faites écrire qui paie si elle casse autre chose
• Le prix d’une maintenance corrective PrestaShop dépend de la reproductibilité du bug
• Un bug PrestaShop corrigé à la hâte en produit d’autres
• Sources consultées
• Foire aux questions

Un bug de paiement ou de panier se chiffre en commandes perdues

Une journée de paiement bloqué vaut les commandes d’un jour ordinaire, lues dans le menu Commandes (Orders), multipliées par votre panier moyen.

Pour une borne haute, listez les paniers du mois dans Commandes > Paniers (Orders > Shopping carts), retirez ceux qui ont abouti et multipliez le reste par votre panier moyen : tous ne viennent pas d’un bug. Le Baymard Institute (liste du 22 septembre 2025) donne 17 % pour la raison « site en erreur ou planté », sans préciser la population interrogée : un repère, pas une mesure de votre boutique.

La version de PrestaShop décide de qui corrige un bug ordinaire

Le cœur est le logiciel livré par l’éditeur, hors modules et thème. Ses corrections arrivent désormais dans la 9.2, publiée le 30 septembre 2026, plus dans la 9.1 ; elles ne sont pas garanties pour un bug précis, selon les règles de contribution de l’éditeur.

La 9.1.5, dernière version de la 9.1, apporte cinq correctifs de sécurité et une centaine de corrections de bugs ; la 9.2 a suivi. Un bug du cœur y est peut-être corrigé : testez une mise à jour vers la 9.2 sur préproduction.

La correction d’un bug PrestaShop commence par une procédure de reproduction écrite

L’éditeur recommande, pour tout signalement, un bug reproductible à chaque fois, sur un logiciel à jour, avec étapes précises et résultat attendu. Un prestataire qui ne voit pas le bug ne peut pas prouver qu’il l’a corrigé.

Numérotez les clics depuis la page de départ, en notant compte, appareil, navigateur et résultat observé. Ajoutez ce qui a changé juste avant, comme un nouveau PHP chez l’hébergeur. Paramètres avancés > Informations (Advanced parameters > Information) donne les versions de PrestaShop, de PHP et de MySQL, que la documentation destine aux développeurs.

En attendant la correction d’un bug PrestaShop, sauvegardez avant de toucher

Sauvegardez avant toute intervention et notez l’heure du bug, puis de chaque manipulation, pour les rapprocher de Paramètres avancés > Logs (Advanced parameters > Logs). Ne désinstallez aucun module pour voir : selon la documentation de PrestaShop 8, la désinstallation supprime la configuration du module et ses données en base, la désactivation garde ses réglages.

Si le bug bloque les commandes, « Activer la boutique » (Enable Shop, page Maintenance) sert à désactiver temporairement la boutique ; « IP de maintenance » (Maintenance IP) laisse votre poste y accéder.

Décrire mon besoin →

Le diagnostic d’un bug PrestaShop procède par élimination sur une copie

Le prestataire travaille sur une préproduction (copie invisible des clients) avec trois options du back-office et les journaux d’erreurs, où PrestaShop note ses erreurs.

Une page blanche ou une erreur 500 (message générique du serveur) n’indique pas sa cause : par défaut, les clients ne voient pas les messages d’erreur du serveur (documentation développeur). Le mode debug (Debug mode), dans Paramètres avancés > Performances (Advanced parameters > Performance), rend visibles les messages techniques (guide de l’utilisateur) mais pèse sur les performances (documentation développeur) : à couper ensuite. Si le back-office ne répond plus, le prestataire passe « _PS_MODE_DEV_ » à « true » dans « config/defines.inc.php ».

Deux autres options isolent la cause : « Désactiver les modules non développés par PrestaShop » (Disable non PrestaShop modules) et « Désactiver toutes les surcharges » (Disable all overrides, soit des fichiers qui remplacent le comportement d’une classe du cœur). Si le bug disparaît, un module tiers ou une surcharge est en cause.

Paramètres avancés > Logs classe les erreurs PHP de 1 (informatif) à 4 (problème majeur, erreur critique). Le seuil d’envoi par e-mail vaut 5 par défaut : aucune notification.

Un bug de panier, de paiement ou de transporteur cache parfois un réglage

Un transporteur disparu ou un moyen de paiement absent se corrige parfois sans code. Trois écrans à vérifier :

• Transporteurs (Carriers) : statut activé, zones cochées par tranche, poids ou prix dans une tranche, groupe d’accès, comportement hors tranches (« Désactiver le transporteur », Disable carrier, le retire) ;
• Préférences de paiement (Payment Preferences) : restrictions par devise, groupe, pays et transporteur ;
• Commandes > Paniers : le panier du client qui signale le bug.

Un bug PrestaShop apparu après un changement de PHP peut tenir à la version de PrestaShop

PrestaShop 8 n’accepte pas PHP 8.2 ni au-delà, et php.net ne corrige plus PHP 8.1 depuis le 31 décembre 2025 : une boutique en PrestaShop 8 se trouve entre un PHP non corrigé et un PHP refusé. La sortie durable est PrestaShop 9 : la 9.2 accepte PHP 8.1 à 8.5.

Un correctif de bug PrestaShop modifie la cause, hors du cœur

Exigez un correctif dans un module ou le thème enfant (qui hérite du thème d’origine sans le modifier), ou une note de ce qu’il faudra réappliquer. Désactiver le module fautif retire le bug et la fonction : c’est un contournement, à écrire au rapport.

La « Liste des fichiers modifiés » (List of changed files) de Paramètres avancés > Informations recense les écarts avec l’installation d’origine : modules et thèmes ajoutés, surcharges modifiées, fichiers supprimés. Qu’une retouche du cœur y figure est une déduction : la documentation ne cite pas le cœur.

Décrire mon besoin →

La non-régression d’un correctif PrestaShop se prouve parcours par parcours

Le prestataire rejoue, sur la copie puis en production après la mise en ligne, les parcours qui rapportent :

• création de compte, commande sans compte ;
• produit à déclinaisons au panier ;
• bon de réduction ;
• chaque transporteur et chaque moyen de paiement, en mode test (essai sans débit réel) ;
• e-mail de confirmation et facture.

Avant la correction d’un bug PrestaShop, faites écrire qui paie si elle casse autre chose

Faites écrire au devis que la remise en état, depuis la sauvegarde prise avant, revient au prestataire si l’un de ces parcours échoue après la mise en ligne. Demandez qu’il sépare le diagnostic, facturé au temps passé avec un plafond, de la correction, chiffrée cause connue, et qu’une rechute, dans un délai fixé, se reprenne sans frais.

Les accès suivent la méthode d’un dépannage ponctuel. Le rapport d’une page nomme la cause, le fichier ou module modifié, les parcours testés ; exigez la remise du code du correctif.

Le prix d’une maintenance corrective PrestaShop dépend de la reproductibilité du bug

Un bug qui se reproduit en trois clics se chiffre vite ; un bug intermittent demande des heures d’observation. Font aussi varier le prix : une préproduction existante, l’origine du bug (module acheté ou code sur mesure non documenté), une version sans correctif de l’éditeur, le nombre de parcours à retester, l’urgence.

Un bug PrestaShop corrigé à la hâte en produit d’autres

Grouper plusieurs corrections dans une mise en ligne empêche de savoir laquelle a cassé quoi. Réceptionner sans rejouer la procédure en production laisse passer un correctif resté sur la copie ; relisez Paramètres avancés > Logs.

Dans le message du formulaire de cette page, reportez les versions de PrestaShop, de PHP et de MySQL, les étapes, le texte exact de l’erreur et la date de la première occurrence.

Sources consultées

• Baymard Institute, « 50 Cart Abandonment Rate Statistics 2026 », section des raisons d’abandon, liste mise à jour le 22 septembre 2025, consulté le 14 octobre 2026.
• PrestaShop, annonces de versions : « PrestaShop 9.2 is available », « PrestaShop 9.1.5 is available », « PrestaShop 9.0.3 is available » et « PrestaShop 9.0 is available », consulté le 14 octobre 2026.
• PrestaShop, dépôt GitHub PrestaShop/PrestaShop, liste des étiquettes et des versions publiées, consulté le 15 octobre 2026.
• PrestaShop, annonces de fin de support : « PrestaShop 8.2.x is now in the extended support phase », « PrestaShop 1.7.8 is now in the extended support phase » et « 1.6.1.x : what’s next », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur, « Supported branches », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur, « System requirements for PrestaShop 8 », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur, « Configuring PrestaShop », « Post-update checklist » et « Overrides », consulté le 14 octobre 2026.
• PrestaShop Project, « How to use GitHub to report an issue », consulté le 14 octobre 2026.
• PrestaShop, guide de l’utilisateur de PrestaShop 8, « Paramètres de performances », « Paramètres de log », « Informations de configuration », « Maintenance de la boutique » et « Installed Modules », consulté le 14 octobre 2026.
• PrestaShop, guide de l’utilisateur de PrestaShop 8, « Gérer les transporteurs », « Préférences de paiement » et « Paniers », consulté le 14 octobre 2026.
• PrestaShop, guide de l’utilisateur de PrestaShop 8 en anglais, « Maintenance », « Information », « Performance », « Logs », « Carriers », « Payment Preferences » et « Shopping carts », consulté le 15 octobre 2026.
• php.net, « Unsupported Branches », consulté le 14 octobre 2026.

Foire aux questions

Le prestataire peut-il corriger un bug sans accès au serveur ?

Un réglage se corrige depuis le back-office ; un bug de code, non : le diagnostic demande le journal d’erreurs du serveur, fichier où il consigne ses erreurs, la copie de la boutique et l’accès aux fichiers par FTP ou SSH, deux moyens de les modifier à distance.

Un bug apparu après une mise à jour se corrige-t-il en restaurant la sauvegarde ?

La restauration retire le bug, mais aussi la mise à jour et ses correctifs de sécurité, et efface les commandes passées depuis la sauvegarde. Cherchez plutôt, sur la copie, le module devenu incompatible avec la nouvelle version.

Que faire d’un bug intermittent ?

Notez chaque occurrence : heure, page, appareil. Le prestataire les rapproche du tableau d’erreurs de Paramètres avancés > Logs.

Un bug dans un module acheté, qui le corrige ?

L’auteur du module d’abord, si son support court encore : sa durée varie selon l’auteur et figure sur la fiche du module. Le prestataire reproduit le bug sur la copie, modules tiers désactivés sauf celui-là, et rédige le signalement à l’auteur.