
C’est une question qui se répète très régulièrement. Un propriétaire de site e-commerce fait une mise à jour de sa boutique PrestaShop parce qu’on lui a dit que c’était important, parce qu’il a reçu une notification, parce qu’il a lu quelque part que les anciennes versions posaient des problèmes de sécurité. Et suite à cette mise à jour, en ouvrant son back-office, il se retrouve face à une page blanche, une erreur 500, ou un module de paiement qui ne répond plus. Cela a pour conséquences, des ventes perdues, un énorme stress et l’interrogation : qu’ai-je bien pu casser sur le site ?
La réponse courte est, probablement rien mais en tous cas, rien que l’on ne puisse corriger.
Cet article explique pourquoi les modules deviennent incompatibles après une mise à jour, comment diagnostiquer le problème sans panique, et surtout quelles solutions existent selon les différents cas. Parce que oui, il y a presque toujours une solution.
Que se passe-t-il techniquement, sans entrer dans les détails trop complexes, lorsque l’on rencontre une erreur de ce type ?
Les fondations de PrestaShop évoluent à chaque version. Quand un site passe, pour exemple, d’une version 8x à la 9.0, ou même d’une version 8.1.2 à la 8.1.5, le cœur même du CMS change. Certaines fonctions internes peuvent être modifiées, supprimées ou ajoutées. Les modules tiers, eux, ont été développés à un instant T en se basant sur ces fondations. Si le développeur du module n’a pas suivi les évolutions de PrestaShop, le module se retrouve à appeler des fonctions qui n’existent plus, et ça plante.
Il y a aussi la question de PHP. PrestaShop 9.0, par exemple, nécessite PHP 8.1 minimum. Si votre hébergeur a mis à jour PHP en même temps que vous mettiez à jour PrestaShop, certains modules anciens codés pour PHP 7.x peuvent simplement s’arrêter de fonctionner. Ce n’est pas un bug, c’est une incompatibilité structurelle.
Autre cas fréquent : les conflits entre modules. Vous avez dix modules installés, vous en mettez un à jour, et ce module mis à jour entre en conflit avec un autre. C’est subtil, parfois difficile à repérer, mais ça arrive plus souvent qu’on ne le pense.
Et puis il y a les modules abandonnés. Des modules achetés il y a trois ou quatre ans sur la marketplace PrestaShop, dont le développeur a arrêté la maintenance. Ces modules-là sont une bombe à retardement : ils fonctionnent jusqu’au jour où une mise à jour majeure les rend obsolètes.
Tous les problèmes ne se ressemblent pas, et identifier précisément ce que vous voyez aide beaucoup à trouver d’où ça vient.
L’écran blanc (ou WSOD : White Screen of Death) est sans doute le plus anxiogène. Votre boutique affiche une page vide, rien d’autre. En général, c’est une erreur PHP fatale, le genre d’erreur qui fait « crasher » l’exécution du script avant même qu’une page puisse s’afficher. Un module non compatible peut provoquer ça dès qu’il est chargé.
L’erreur 500 est similaire dans ses causes, mais s’affiche généralement avec un message d’erreur générique du serveur. Plus rassurant psychologiquement, guère plus informatif sans aller creuser les logs.
Le back-office inaccessible est un cas particulier. Si vous ne pouvez plus accéder à votre administration PrestaShop, c’est souvent qu’un module chargé au démarrage du back-office pose problème. C’est stressant car on ne peut même plus agir depuis l’interface.
Une fonctionnalité qui disparaît sans message d’erreur apparent, le bouton de paiement qui ne s’affiche plus, les frais de port qui ne se calculent plus, les emails de confirmation qui ne partent plus… tout cela peut indiquer qu’un module fonctionne partiellement mais plante sur une action précise.
Des lenteurs soudaines peuvent aussi être liées à un module qui génère des erreurs en boucle, des requêtes SQL mal formées, ou qui tente de contacter un service externe qui ne répond plus.
a. Activer le mode debug de PrestaShop
C’est la première chose à faire. Par défaut, PrestaShop masque les erreurs techniques pour ne pas les afficher aux visiteurs. Avec le mode débogage (debug), les erreurs s’affichent alors à l’écran.
Pour activer le mode, il faut ouvrir le fichier config/defines.inc.php à la racine de votre boutique et cherchez la ligne : define(‘_PS_MODE_DEV_’, false);
Passez-la à true. Rechargez la page problématique. Vous verrez alors (très probablement) une erreur PHP avec un nom de fichier et un numéro de ligne, ce qui vous donne immédiatement une piste.
⚠️ Pensez à remettre false une fois le problème résolu. Le mode debug ne doit jamais rester activé sur une boutique en production.
b. Consulter les logs du serveur
Si le mode debug ne donne rien ou si vous ne pouvez pas accéder aux fichiers via FTP, les logs d’erreur PHP de votre serveur contiennent souvent l’information brute. Selon votre hébergeur, ils se trouvent dans le panneau de contrôle (cPanel, Plesk) ou dans un répertoire logs/ sur le serveur.
Un log PHP ressemble à quelque chose comme :
Fatal error: Call to undefined function someOldFunction() in /modules/monmodule/monmodule.php on line 142
Ce genre de message vous indique directement quel module est en cause (monmodule) et quelle fonction pose problème.
c. Désactiver les modules un par un
Si vous avez accès au back-office, allez dans Modules > Gestionnaire de modules et désactivez les modules installés récemment ou ceux que vous soupçonnez. Rechargez la page problématique après chaque désactivation.
Si vous n’avez pas accès au back-office, c’est faisable en base de données. Dans la table ps_module, vous pouvez passer le champ active à 0 pour un module donné. Une intervention en base de données demande des précautions et de compétences si vous n’êtes pas à l’aise avec ça, il vaut mieux faire appel à quelqu’un.
d. Vérifier la compatibilité des modules
Chaque module sérieux affiche les versions de PrestaShop avec lesquelles il est compatible. Sur la marketplace PrestaShop Addons, cette information est visible sur la fiche du module. Si votre boutique tourne sur PS 9.0 et que votre module indique une compatibilité jusqu’à PS 8.x, le problème est là.
Vérifiez aussi la version de PHP requise. C’est une information souvent négligée mais qui explique beaucoup de pannes post-mise à jour.
e. Tester sur un environnement de pré-production
Idéalement, toute mise à jour devrait d’abord être testée sur une copie de votre boutique, dans un environnement de staging. Beaucoup d’hébergeurs proposent cette fonctionnalité. Cela permet de reproduire les erreurs sans impacter votre boutique réelle.
Si vous n’avez pas encore cet environnement, c’est le bon moment pour y penser.
Une fois le module problématique identifié, plusieurs options s’offrent à vous.
Mettre à jour le module. Si le module a une mise à jour, proposée par son éditeur pour assurer la compatibilité avec votre version de PrestaShop, c’est souvent la solution la plus simple. Il faut alors aller sur la marketplace ou directement chez l’éditeur, télécharger la version la plus récente, et l’installer via le gestionnaire de modules.
Contacter l’éditeur du module, si une mise à jour n’est pas disponible. C’est souvent le temps qui fait défaut à l’éditeur, qui travaille activement la compatibilité mais qui n’a pas encore pu publier la mise à jour, ça ne saurait tarder. Un email ou un ticket de support peut accélérer les choses ou au moins vous donner une visibilité sur les délais.
Trouver un module équivalent. Quand un module est clairement abandonné, la vraie solution est souvent de le remplacer par un équivalent maintenu activement. Oui, cela implique une reconfiguration. Mais conserver un module mort dans votre installation, c’est une source permanente de problèmes futurs.
Intervenir sur le code. Dans certains cas, notamment pour des modules personnalisés ou développés sur mesure, il faut mettre les mains dans le code pour adapter le module aux nouvelles APIs de PrestaShop. Il s’agit d’un travail de développeur, qui nécessite une bonne connaissance et des compétences du framework de PrestaShop. Sices compétences vous manquent en interne, un prestataire spécialisé fera clairement la différence.
Désactiver définitivement le module. Parfois, un module remplit une fonction secondaire, et il vaut mieux le désactiver temporairement le temps de trouver une solution, plutôt que de bloquer toute la boutique. C’est une décision à peser selon l’importance fonctionnelle du module.
Une fois le problème résolu, c’est le moment idéal pour mettre en place de bonnes pratiques pour le futur. En effet, une boutique bien maintenue, c’est une boutique qui génère des revenus sans vous donner des sueurs froides de ce type.
Tenez un inventaire de vos modules. Vous devez consigner quelque part, les modules installés, leur version, la date de leur dernière mise à jour, et si l’éditeur est actif. C’est un travail fastidieux à mettre en place, mais ça permet de gagner un temps considérable en cas de problème.
Sauvegardez systématiquement avant toute mise à jour. Cela paraît évident, mais le nombre de boutiques sauvegardées « à peu près » ou « de temps en temps » est étonnant. Une sauvegarde complète, fichiers + base de données, juste avant une mise à jour, c’est votre filet de sécurité absolu.
Mettez à jour dans un environnement de test d’abord. Si votre hébergeur propose un environnement de simulation (staging), il est primordial de l’utiliser. Si ce n’est pas le cas, il est fortement conseillé d’en demander un et le cas échéant, de changer d’hébergeur.
Évitez d’accumuler des modules inutiles. Chaque module installé est un point de défaillance potentiel. Si vous n’utilisez plus un module, désinstallez-le proprement plutôt que de le laisser désactivé dans votre installation.
Planifiez vos mises à jour. Une mise à jour faite à la va-vite un vendredi soir, sans backup préalable et sans environnement de test, c’est une prise de risque inutile. Bloquez du temps, faites-le sérieusement, ou faites-le faire par quelqu’un qui le fera sérieusement.
On a vu des boutiques rester inaccessibles pendant plusieurs heures, parfois une journée entière parce que la personne ne savait pas par où commencer, ou parce qu’elle attendait une réponse de son hébergeur qui n’arrivait pas.
Chaque heure d’indisponibilité, ce sont des paniers abandonnés, des clients qui vont voir ailleurs, une image de marque écornée. Ce n’est pas une question de perfectionnisme technique, c’est une question de revenus.
Chez HOB France Services, on intervient quotidiennement sur ce type de situation. Diagnostic rapide, identification du module problématique, correction ou remplacement, on a l’habitude. Notre équipe est joignable au 09 54 43 67 20, numéro non surtaxé, avec une réponse immédiate ou une proposition d’intervention dans la journée.
Si votre boutique est en panne en ce moment, ne perdez pas de temps à chercher tout seul. Appelez-nous.
Et si votre boutique fonctionne mais que vous avez des modules anciens, une version de PrestaShop qui commence à dater, ou que vous envisagez une migration vers PrestaShop 9, nous pouvons aussi vous accompagner en amont, avant que le problème ne se pose.
HOB France Services – Centre de compétences CMS : PrestaShop, WordPress, Joomla
📞 09 54 43 67 20 (non surtaxé)