Maintenance préventive et corrective PrestaShop

Que vous gériez une petite boutique ou un gros site e-commerce, la maintenance de PrestaShop n’est pas une option. C’est elle qui garde votre outil de vente sécurisé, rapide et en ligne, mois après mois. Et pourtant, c’est souvent la première chose qu’on repousse «quand on aura le temps».

Il faut distinguer deux choses, parce qu’on les confond tout le temps. Il y a la maintenance préventive (agir avant que ça casse : mises à jour, sauvegardes, sécurité) et la maintenance corrective (réparer quand ça a déjà cassé : un bug, une erreur 500, une page blanche). Les deux ensemble forment ce qu’on appelle la TMA, la «tierce maintenance applicative» de votre boutique PrestaShop.

L’agence CYBERIAL est spécialisée là-dedans depuis 2012. Notre forfait de maintenance PrestaShop à 69 € HT/mois est adopté par plus de 350 entreprises en France, Belgique et Suisse, et on surveille ces boutiques 7j/7. Ce guide, c’est la synthèse de ce qu’on fait concrètement pour elles : la routine qui évite les pannes, et la méthode pour les corriger quand elles arrivent quand même.

Pas de jargon non expliqué, pas de théorie. Des gestes concrets, et les chiffres qu’on voit sur le terrain.

La maintenance PrestaShop, préventive et corrective : de quoi parle-t-on ?

La maintenance applicative d’un site PrestaShop, c’est l’ensemble des opérations qui gardent votre boutique en bon état de marche dans la durée. Quand vous la confiez à un prestataire externe au lieu de la gérer en interne, on parle de TMA (tierce maintenance applicative). C’est le même métier, juste délégué.

Elle se découpe en deux familles, complémentaires et indissociables.

La maintenance préventive, c’est tout ce qu’on fait avant qu’un problème survienne : les mises à jour, les sauvegardes, la surveillance de la sécurité et des performances. C’est le travail invisible, celui qu’on ne remarque jamais (justement parce qu’il évite les pannes).

La maintenance corrective, c’est tout ce qu’on fait quand un incident se produit : diagnostiquer un bug, corriger une erreur, remettre la boutique en ligne. C’est la partie visible, souvent dans l’urgence.

💡 Bon à savoir : dans l’idéal, la maintenance préventive devrait occuper environ 80 % de votre temps de maintenance, la corrective seulement 20 %. Beaucoup de marchands font l’inverse («on verra quand il y aura un problème»). C’est humain, mais c’est risqué, et au final plus cher.

Un exemple qui résume tout. Un commerçant nous appelle un vendredi après-midi : sa boutique affiche une page blanche depuis le matin. Il n’a rien touché, rien mis à jour. Et c’est exactement ça le souci : il n’avait rien touché depuis deux ans. Son hébergeur avait basculé le serveur sur une version de PHP plus récente (en prévenant par email trois mois avant), et son vieux PrestaShop ne la supportait pas. La remise en route a coûté plus cher que deux ans de maintenance préventive. Pas spectaculaire, pas un piratage de film. Juste un site dont personne ne s’occupait.

La suite de ce guide suit cette logique : d’abord tout le préventif (Partie 1), puis tout le correctif (Partie 2).

Partie 1 — La maintenance préventive PrestaShop

La maintenance préventive est le pilier d’une maintenance de qualité. Comme son nom l’indique, elle sert à prévenir les dysfonctionnements avant qu’ils ne surviennent. Sur PrestaShop, elle couvre les mises à jour, la sécurité, les performances, la gestion des modules et des connecteurs (ERP, CRM, logisticien, marketplaces), la compatibilité serveur, la base de données et les sauvegardes.

Reprenons chaque bloc, dans l’ordre où on le traite chez nos clients.

La checklist de maintenance préventive (à garder sous la main)

Voici la routine. Elle tient sur une page, et c’est déjà 90 % du travail.

Opération	Fréquence
Mise à jour du cœur PrestaShop	Mensuelle
Mise à jour des modules	Hebdomadaire
Mise à jour du thème	Trimestrielle
Vérification de la version PHP / MySQL du serveur	Trimestrielle
Vérification de la taille de la base de données	Mensuelle
Nettoyage de la base de données	Mensuelle
Veille sécurité et actualité PrestaShop	Continue
Sauvegarde complète (fichiers + base), testée	Quotidienne / hebdomadaire

Concrètement, une fois par mois : on vide le cache, on purge les paniers abandonnés de plus de 30 jours, on nettoie les logs, et on mesure le poids des pages principales avec GTmetrix ou PageSpeed Insights. Une fois par trimestre : on optimise les tables de la base de données et on vérifie le poids des images. Ce n’est pas glamour. Mais c’est ça qui fait la différence entre une boutique qui convertit et une boutique qui tombe un samedi de soldes.

Mettre à jour PrestaShop : le cœur d’abord

C’est le geste de maintenance numéro un, et le plus négligé. Chaque nouvelle version apporte des correctifs de sécurité, des améliorations et des nouveautés. À l’inverse, une version périmée, c’est une porte ouverte aux bugs et aux attaques.

Il y a deux types de mises à jour, et il faut les traiter différemment :

• Les mises à jour mineures (de 8.1.4 à 8.1.5, par exemple) corrigent des bugs et des failles. Elles sont généralement sûres et rapides, et il faut les appliquer vite, surtout les correctifs de sécurité.
• Les mises à jour majeures (de 8.x à 9.x) changent l’architecture en profondeur. Elles demandent de la préparation et des tests.

Quelques repères selon votre version, parce que la situation a bougé en 2025-2026 :

• PrestaShop 1.6 : très ancienne, plus maintenue. Si vous êtes encore dessus, votre priorité n’est plus la maintenance mais la migration.
• PrestaShop 1.7 : longtemps le standard. La maintenance d’un 1.7 tourne surtout autour de la compatibilité PHP (voir plus bas).
• PrestaShop 8 : a apporté la compatibilité PHP 8. En support étendu depuis juillet 2025 (sécurité et bugs critiques uniquement, plus de nouvelles fonctionnalités). Il requiert PHP 7.2.5 au minimum et grimpe jusqu’à 8.1, avec MySQL 5.7 ou MariaDB 10.2 au minimum.
• PrestaShop 9 : sorti en juin 2025, sur Symfony 6.4 LTS, avec PHP 8.1 à 8.4. La version stable 9.0.3 (mars 2026) a corrigé pas mal de soucis de jeunesse. Son système de cache restructuré annonce environ 40 % de gain de vitesse par rapport à PS 8 (c’est réel, on l’a mesuré sur plusieurs migrations).

L’ordre d’une mise à jour propre est toujours le même, et il n’y a pas de raccourci :

1. Sauvegarde complète d’abord (fichiers + base de données). Toujours.
2. Mise en mode maintenance de la boutique (voir la section dédiée).
3. Mise à jour du cœur PrestaShop.
4. Mise à jour des modules un par un, en commençant par les plus critiques (paiement, transport, stock).
5. Test du parcours d’achat complet sur un environnement de staging (une copie du site), avant de basculer en production.
6. Rollback prêt : on garde la sauvegarde à portée pour revenir en arrière en quelques minutes si besoin.

⚠️ Attention : ne lancez jamais une mise à jour majeure un vendredi soir, ni en pleine période de trafic. Et vérifiez la compatibilité de vos extensions avant de toucher au cœur. Mon conseil : pour une montée de version majeure, on teste systématiquement sur un serveur de développement avant la production.

Mettre à jour les modules (la première cause de bug que je vois)

Un module est une extension qui ajoute une fonctionnalité (slider, paiement, SEO, etc.). Comme le cœur, les modules reçoivent des mises à jour qui corrigent des failles et des bugs. Et c’est aussi là que ça casse le plus souvent.

Pour les mettre à jour, connectez-vous au back-office, puis Modules → Gestion des modules. Les modules avec une nouvelle version affichent un bouton de mise à jour. Quelques règles qu’on applique sans exception :

• Un par un, et on vérifie le bon fonctionnement de la boutique après chaque module critique (paiement, livraison).
• Sauvegarder la configuration du module avant (exportez ses réglages, ou faites une capture). En cas de souci, le retour arrière est immédiat.
• Ne pas se jeter sur une mise à jour majeure le jour de sa sortie. Attendez quelques jours qu’une version corrective (du type X.0.1) sorte avec les premiers correctifs.
• Vérifier la compatibilité avec votre version de PrestaShop sur la fiche du module (marketplace officielle ou site de l’éditeur).

Ce qu’on voit chez nos clients : un module mis à jour sans vérifier la compatibilité, c’est de loin la première cause de bug post-mise-à-jour. Et un module installé hors marketplace officielle, c’est souvent la porte d’entrée d’un piratage (on y revient dans la partie sécurité).

Mettre à jour le thème (gratuit comme premium)

Le thème détermine l’apparence et une partie de l’expérience de votre boutique. Contrairement aux modules, il n’y a pas de mise à jour automatique des thèmes via le back-office. La méthode dépend de votre thème.

Pour un thème gratuit (téléchargé sur PrestaShop Addons ou GitHub), deux options : soit via Conception → Thèmes & Logo puis «Ajouter un thème» avec le nouveau zip, soit en FTP (sauvegardez l’ancien dossier, puis remplacez-le). Pour un thème premium (du type Warehouse, Alysum), vous téléchargez la nouvelle version depuis votre compte client, puis vous l’installez via Addons ou en FTP dans /themes/votre_theme, en suivant les instructions de l’éditeur.

⚠️ Attention : une mise à jour de thème peut écraser vos personnalisations si vous avez modifié le code source directement. La bonne pratique, c’est de toujours travailler avec un thème enfant : vos personnalisations sont isolées, et vous pouvez mettre à jour le thème parent sans tout perdre. Et comme pour le reste, on teste en préproduction avant la production.

Lancer une mise à jour : par l’interface ou par FTP

Concrètement, vous avez deux façons de mettre à jour, et il faut savoir laquelle choisir.

Par l’interface (le plus simple). Pour le cœur, PrestaShop fournit un module natif, «Mise à jour en 1 clic» (1-Click Upgrade, devenu Update Assistant), dans Paramètres avancés. Il télécharge et installe la dernière version stable en vous guidant pas à pas. Avant de le lancer : sauvegarde complète, site en mode maintenance, et idéalement un test sur un clone. Une fois lancé, on ne l’interrompt pas (en cas d’erreur, il tente une restauration automatique). Pour un module, c’est dans Modules → Gestion des modules, onglet «Mises à jour disponibles». Pour un thème, pas de bouton dédié : on installe la nouvelle version comme un nouveau thème.

Par FTP (quand l’automatique échoue, ou pour du sur-mesure). Parfois la mise à jour par l’interface plante, ou vous avez un module/thème custom. On passe alors par les fichiers :

1. Téléchargez la nouvelle version depuis une source fiable, et décompressez-la sur votre ordinateur.
2. Connectez-vous en FTP (FileZilla, WinSCP) avec les identifiants de votre hébergeur.
3. Localisez le bon dossier : /modules pour un module, /themes pour un thème.
4. Sauvegardez l’ancien dossier (renommez-le en _old, ou téléchargez-le en local).
5. Copiez le nouveau dossier au même endroit (confirmez l’écrasement des fichiers).
6. Videz le cache (back-office, ou en supprimant le contenu de /var/cache).

Vérifiez ensuite dans le back-office que la nouvelle version est bien là, et testez la fonctionnalité concernée.

⚠️ Attention : si vous n’êtes pas à l’aise avec le FTP (ou que vous avez perdu vos accès), n’allez pas plus loin. Une fausse manipulation par FTP peut casser le site. Au passage : si vous vous retrouvez souvent à bidouiller en FTP, c’est souvent le signe d’un parc de modules non officiels à assainir.

Rester en veille (et anticiper les grosses mises à jour)

Mettre à jour, c’est bien. Anticiper, c’est mieux. Une partie du travail préventif consiste simplement à suivre l’actualité PrestaShop : les annonces de versions majeures (pour planifier une migration à l’avance), les patchs de sécurité critiques (pour les appliquer dans les heures qui suivent, pas les semaines), et les évolutions de l’écosystème (nouvelle version PHP requise, changement d’API d’un connecteur). Suivez le blog officiel et les comptes PrestaShop, et abonnez-vous aux alertes de sécurité. Ce qu’on voit chez nos clients : ceux qui savent qu’une grosse mise à jour arrive la préparent sereinement (backup, environnement de test, lecture de la doc de migration) ; les autres la subissent.

Surveiller la version PHP et MySQL du serveur

Voilà le point qui fait tomber le plus de boutiques, et dont personne ne parle assez. PrestaShop tourne sur PHP (avec une base MySQL ou MariaDB). Une version de PHP trop ancienne comporte des failles non corrigées et ralentit le site. Mais passer trop tôt à une version non supportée par votre PrestaShop fait planter le site. Il faut donc surveiller, et suivre les préconisations officielles.

📊 Donnée terrain CYBERIAL : environ 80 % des problèmes qui surviennent après une migration ou un changement de serveur sont liés à la version PHP. C’est énorme, mais logique : il suffit d’un seul module avec une fonction obsolète pour que tout tombe.

Et le contexte de fond a changé. Depuis fin 2024, les hébergeurs (OVH, o2switch, Ionos, Hostinger et les autres) retirent progressivement PHP 7.4 et 8.0. Le jour où votre hébergeur bascule, si votre PrestaShop ne supporte pas la nouvelle version, c’est la page blanche immédiate.

Comment vérifier votre version PHP/MySQL ? Deux moyens : dans le back-office, via Paramètres avancés → Informations (qui liste la config serveur), ou directement dans le panneau de votre hébergeur (cPanel, Plesk, phpMyAdmin), où l’on peut souvent changer la version de PHP. Bonne nouvelle : ces changements sont peu fréquents, et une vérification par trimestre suffit largement à anticiper.

Surveiller et nettoyer la base de données

Avec le temps, la base se remplit de données inutiles : paniers abandonnés, anciennes statistiques, logs expirés, connexions visiteurs. Elle gonfle, et la boutique ralentit. Certaines tables grossissent en silence, comme ps_cart_rule_combination si vous utilisez des codes promo, et personne ne les surveille.

La routine : une fois par mois, vérifiez la taille de votre base (via Paramètres avancés → Informations, phpMyAdmin, ou le panneau de l’hébergeur), et nettoyez ce qui n’a pas besoin d’historique (paniers abandonnés de plus de 30 jours, vieilles statistiques, logs). Surveillez aussi que vous n’approchez pas de la limite fixée par votre hébergeur (parfois 1 Go sur une offre mutualisée).

C’est un sujet à part entière, avec des pièges (certaines tables ne se vident pas n’importe comment). On l’a détaillé, étape par étape, dans notre guide dédié : nettoyer la base de données PrestaShop.

Faire des sauvegardes (et les tester, surtout)

La sauvegarde, c’est votre filet de sécurité. Sans elle, la remise en ligne après un incident grave (piratage, crash disque, fausse manœuvre) peut prendre des jours, coûter très cher, et parfois ne plus être possible du tout.

Ce qu’il faut, concrètement :

• Une sauvegarde quotidienne de la base de données et une sauvegarde hebdomadaire complète des fichiers.
• De l’automatisation (tâches cron, service de backup de l’hébergeur, module de sauvegarde) pour ne pas dépendre d’une action humaine quotidienne.
• Un stockage externalisé, en dehors du serveur de la boutique. Une sauvegarde qui dort sur le même serveur que le site disparaît avec lui.

💡 Bon à savoir : le point que tout le monde oublie, c’est de tester ses sauvegardes. Au moins une fois par trimestre, restaurez-en une sur un environnement de test pour vérifier qu’elle fonctionne vraiment. Une sauvegarde jamais testée, c’est un parachute qu’on n’a jamais plié soi-même. On croise les doigts, et un jour ça ne s’ouvre pas.

Renforcer la sécurité avant l’incident

La sécurité préventive, c’est beaucoup de rigueur et quelques réflexes. Et il faut bien comprendre une chose : PrestaShop, en lui-même, est plutôt bien sécurisé. La quasi-totalité des compromissions vient de l’écosystème autour, surtout des modules tiers mal maintenus ou téléchargés hors marketplace officielle.

Ce n’est pas une vue de l’esprit. En 2024-2025, plusieurs failles ont été activement exploitées (une XSS dans le formulaire de contact, une injection SQL via un module de comptabilité, etc.). En septembre 2025, une faille permettant d’énumérer les emails des comptes admin a été corrigée dans PrestaShop 8.2.3 (les boutiques sous PS 9 n’étaient pas concernées). Et l’attaque massive de juillet 2022 (des milliers de boutiques piratées, vol de données de paiement) reposait sur une faille du module Wishlist combinée au cache MySQL Smarty. À chaque fois, le même schéma : un composant pas à jour.

Et l’actualité 2026 ne rassure pas. Depuis février 2026, une vague de skimmers JavaScript cible les boutiques PrestaShop (PrestaShop a alerté les marchands par email, et le Crédit Agricole a même prévenu ses clients commerçants). La particularité de ce skimmer est redoutable : il se désactive quand un administrateur est connecté au back-office. Vous passez une commande test, tout semble normal. Vos clients, eux, voient un faux formulaire de paiement qui aspire leur carte bancaire. Selon TouchWeb, 98 % des marchands audités sont exposés à au moins une faiblesse de ce type.

Voici les gestes qui protègent vraiment, et qu’on met en place sur chaque boutique :

• Appliquer les mises à jour de sécurité dès leur publication. Quand une faille critique sort, vous avez quelques heures pour réagir, pas quelques semaines. (Selon le rapport Sucuri 2023, 39,1 % des CMS compromis étaient obsolètes au moment de l’infection.)
• Supprimer les modules inutilisés. Et supprimer les dossiers, pas seulement désactiver : un module désactivé mais présent sur le serveur reste exploitable. Pareil pour les anciennes installations et les zones de test oubliées.
• N’installer que des modules de sources fiables, et vérifier la date de dernière mise à jour avant d’installer (un module abandonné depuis plus d’un an est un risque).
• Renommer le dossier admin du back-office (le nom par défaut est connu de tous les scanners) et activer la double authentification sur le back-office comme sur le panel de l’hébergeur.
• Protéger le fichier app/config/parameters.php : il contient les identifiants de la base et des secrets sensibles. C’est l’un des fichiers les plus convoités.
• Passer tout en HTTPS (un site e-commerce sans certificat SSL n’a plus sa place en ligne) et externaliser les sauvegardes (votre meilleure assurance en cas de compromission).

💡 Bon à savoir : un outil gratuit pour faire un premier état des lieux, c’est PrestaScan (mis à disposition par Profileo et Friends of Presta). Il liste les vulnérabilités connues de vos modules, avec un lien vers le correctif sur security.friendsofpresta.org. Inscrivez-vous aussi aux notifications de ces sources : c’est ce qui vous fait gagner les quelques heures décisives.

Si vous pensez être déjà touché, ou si vous voulez le protocole d’urgence complet (avec les obligations CNIL), on a un guide dédié : boutique PrestaShop piratée.

Surveiller les performances (avant que la boutique rame)

Une boutique lente fait fuir les clients, et Google le voit. La maintenance préventive inclut donc une surveillance régulière des performances : le temps de réponse serveur (le TTFB), la vitesse des pages, l’état des ressources.

Le réflexe simple : mesurez votre TTFB une fois par mois (GTmetrix, trente secondes). S’il grimpe, vous le détectez avant vos clients. Et testez chaque nouveau module en staging avec le profiler activé : un module qui ajoute 500 ms par page, c’est un module qu’on ne déploie pas. Suivez aussi vos Core Web Vitals dans la Search Console (onglet Expérience), Google observe votre site pendant 28 jours après chaque correction.

Si votre boutique rame déjà, ce n’est plus du préventif, c’est du correctif : on traite ça dans la Partie 2, et en détail dans le guide boutique PrestaShop lente.

Mettre la boutique en mode maintenance (la bonne façon)

Avant toute opération sensible (mise à jour, modification du thème), on met la boutique en mode maintenance : le front-office est fermé aux visiteurs, mais vous gardez l’accès au back-office.

Sur PrestaShop 1.7, 8 et 9, ça se passe dans Paramètres de la boutique → Maintenance (sur 1.6, c’était Préférences → Maintenance). Vous passez «Activer la boutique» sur Non, vous ajoutez votre adresse IP dans la liste blanche (pour continuer à voir le site), et vous personnalisez le message affiché aux visiteurs.

💡 Bon à savoir (le détail SEO que presque personne ne vérifie) : une page de maintenance bien configurée doit renvoyer un code HTTP 503 («service temporairement indisponible»), et non un code 200. C’est crucial : le 503 dit à Google «repasse plus tard, ne déréférence rien». Une page de maintenance servie en 200 pendant plusieurs heures peut faire chuter votre référencement. Le mode maintenance natif de PrestaShop gère le 503 correctement, contrairement à beaucoup de bricolages maison.

⚠️ Attention : planifiez toujours vos interventions sur des périodes creuses, faites une sauvegarde complète avant, et testez sur une copie (préproduction) plutôt que directement en production. Avant de remettre le site en ligne, testez tout le parcours (navigation, affichage, paiement) avant de désactiver la maintenance.

Et si vous n’avez plus du tout accès au back-office, on peut activer le mode maintenance directement en base de données, via la valeur PS_SHOP_ENABLE de la table ps_configuration (à passer de 1 à 0). C’est une manipulation de dernier recours. La procédure officielle est décrite dans la documentation PrestaShop.

Partie 2 — La maintenance corrective PrestaShop

Malgré une bonne prévention, aucun site n’est totalement à l’abri d’un bug. La maintenance corrective, c’est l’art de diagnostiquer puis réparer quand l’incident est déjà là (page blanche, erreur 500, module défaillant). Et chaque minute d’indisponibilité, ce sont des paniers abandonnés et de la confiance client qui s’érode. Voici comment on s’y prend.

Diagnostiquer avant de réparer : le mode debug et les logs

Avant de corriger quoi que ce soit, il faut comprendre. Et sur PrestaShop, deux outils donnent presque toujours la réponse.

Le mode debug. En activant le mode développeur (la constante _PS_MODE_DEV_ passée à true dans le fichier de configuration), PrestaShop arrête d’afficher une page blanche ou un message générique, et affiche la pile d’erreurs : le fichier fautif, la ligne, le message exact. Neuf fois sur dix, on tient la cause ici.

Les logs. Les journaux d’erreurs racontent ce qui s’est passé : les logs PrestaShop (dans var/logs), et les logs serveur (Apache / PHP, souvent un error.log). On y lit les permissions refusées, la mémoire saturée, les time-out, un fichier YAML mal formé. C’est le deuxième endroit où regarder, systématiquement.

⚠️ Attention : le mode debug affiche des informations techniques sensibles. On l’active pour diagnostiquer, et on le désactive immédiatement après. Jamais de mode debug laissé actif sur une boutique en production.

Les pannes PrestaShop les plus fréquentes (la grille symptôme → cause)

Sur le terrain, la grande majorité des pannes tombent dans une poignée de catégories. Voici la grille qu’on utilise pour orienter le diagnostic en quelques secondes.

Symptôme	Cause la plus probable
«Internal Server Error»	Erreur PHP, .htaccess, mémoire, module
Écran totalement blanc	Erreur PHP fatale (thème/module ou version PHP)
«No connection could be established» / SQLSTATE	Identifiants base de données ou serveur MySQL
Plantage juste après une mise à jour	Module/thème incompatible, cache, override obsolète
Boutique très lente, erreurs 504/502	Serveur saturé, base non optimisée, module gourmand
«Aucun moyen de paiement disponible»	Module de paiement cassé ou mal restreint
Stocks ou prix incohérents	Cache, hook mal implémenté, synchro externe
Affichage figé après une modif	Cache à vider
Erreurs après changement de serveur	.htaccess ou permissions de fichiers

Reprenons les cas un par un.

L’erreur 500 (Internal Server Error)

L’erreur 500 bloque totalement l’affichage, et c’est un message volontairement vague : «quelque chose s’est mal passé sur le serveur, mais le serveur ne peut pas être plus précis». Les causes les plus fréquentes :

• Un module défectueux ou incompatible (qui appelle une fonction absente). Rare avec un module de la marketplace officielle, plus courant avec un module récupéré ailleurs.
• Un fichier .htaccess mal formé (une mauvaise directive Apache bloque tout, y compris le back-office).
• De mauvais droits sur les fichiers (un chmod incorrect empêche le serveur de lire un fichier).
• Une limite de mémoire PHP atteinte ou un time-out (un import massif, une génération de PDF, un traitement trop long).
• Une version PHP incompatible (des fonctions supprimées en PHP 8+).
• Un cache corrompu (souvent juste après l’activation d’un module ou l’édition du .htaccess).

C’est la panne numéro un chez nos clients, et on lui a consacré un guide complet, avec le diagnostic pas à pas : erreur 500 PrestaShop.

La page blanche (white screen of death)

La page blanche, c’est plus déroutant que l’erreur 500 (elle ne montre rien du tout), mais souvent plus simple à corriger : PHP a planté si tôt qu’il n’a même pas eu le temps d’envoyer un code d’erreur. La première question à se poser, et c’est celle qui change tout : où exactement apparaît cette page blanche ? Sur le front-office seulement (souvent un thème ou un module), sur le back-office, ou les deux (souvent une erreur PHP fatale ou une incompatibilité de version) ?

La méthode complète est ici : page blanche PrestaShop.

L’erreur de connexion à la base de données

Quand PrestaShop n’arrive plus à joindre sa base, il affiche une erreur du type SQLSTATE[HY000] [1045] Access denied. Le site est totalement bloqué. Les causes classiques :

• Des identifiants incorrects : mauvais utilisateur (DB_USER), mot de passe erroné (DB_PASSWD), nom de base (DB_NAME) ou serveur (DB_SERVER) incorrect. Ça arrive souvent après un changement d’hébergeur ou une restauration.
• Un serveur MySQL indisponible : MySQL arrêté (crash, surcharge), un problème réseau si la base est sur un serveur distant, ou un mauvais port.
• Des droits insuffisants pour l’utilisateur MySQL sur la base.

Un bug après une mise à jour (Update Assistant / 1-Click Upgrade)

Le module 1-Click Upgrade (devenu Update Assistant) est l’outil officiel pour monter de version. Pratique, mais sa branche 7.x a introduit pas mal de ruptures, et beaucoup de marchands ont signalé les mêmes symptômes :

• Déconnexion inattendue du back-office pendant l’upgrade (échec de session PHP),
• Arrêt brutal du processus sans message clair,
• Erreur 500 ou écran blanc après migration,
• Compatibilité incomplète avec certaines versions de PrestaShop ou de PHP.

Ces erreurs viennent presque toujours de droits de fichiers insuffisants, d’une configuration PHP inadéquate (timeouts trop courts, mémoire insuffisante), ou d’un conflit avec un module tiers. Mon conseil : avant de lancer l’outil, on vérifie ces trois points, et on a une sauvegarde fraîche sous la main.

Un crash après mise à jour du cœur

Une montée de version du noyau peut planter si certaines conditions ne sont pas réunies. Ça se traduit par une erreur 500 ou un écran blanc, un back-office inaccessible, des modules cassés ou des hooks désactivés. Les causes habituelles : des fichiers mal copiés durant l’upgrade (surtout en manuel), un thème personnalisé non mis à jour, un override du cœur devenu obsolète, ou un cache non vidé avant/après. Dans ce cas, un rollback vers la sauvegarde est souvent la voie la plus rapide, avant de reprendre la migration proprement.

Un module incompatible ou mal installé

Une extension tierce peut provoquer une erreur 500 ciblée, qui n’apparaît que sur le front ou que sur le back. On a déjà vu un module de blog générer une 500 dans l’espace client à cause d’un conflit. Les causes fréquentes : un module non compatible avec votre version, une installation incomplète, un conflit entre deux modules qui utilisent les mêmes hooks, ou des droits de fichiers mal réglés lors d’une installation par FTP.

💡 Bon à savoir : si le back-office est inaccessible et que vous suspectez un module, vous pouvez le désactiver manuellement en renommant son dossier (/modules/nomdumodule) via FTP. Le site repart souvent immédiatement, et vous avez identifié le coupable.

Des lenteurs et des erreurs 504/502 sous charge

Problématique courante des boutiques à gros catalogue. Les symptômes : un temps de réponse serveur (TTFB) qui explose (parfois plus de 6 secondes après un vidage de cache), et des erreurs 504/502 quand le serveur met trop de temps à répondre. Les causes :

• Un gros catalogue mal indexé : des milliers de produits génèrent des requêtes SQL lourdes si les index de la base ne sont pas optimisés.
• Le vidage du cache : après un «Clear cache», PrestaShop doit tout recompiler, ce qui charge temporairement le serveur.
• Une config serveur trop juste : des valeurs de max_children ou max_requests (PHP-FPM) trop basses saturent la file, et des proxy_read_timeout / fastcgi_read_timeout trop courts provoquent les 504.
• Des modules non optimisés qui ajoutent des requêtes à chaque page.

Les leviers : optimiser et indexer la base, ajuster les paramètres PHP-FPM et les timeouts selon la charge, mettre en place un cache serveur (Varnish ou Redis), et surveiller pour anticiper les pics. C’est souvent là qu’un hébergement vraiment optimisé pour PrestaShop change tout. On détaille la chasse à la lenteur dans le guide boutique PrestaShop lente.

Des incohérences de données (stocks, prix)

Symptômes : des stocks négatifs ou faux, des prix erronés (surtout avec des promotions), des litiges clients sur l’écart entre le site et la confirmation de commande. Les causes les plus fréquentes : un cache obsolète (qui affiche des données périmées), des hooks mal implémentés (par exemple, le hook actionUpdateQuantity qui ne se déclenche pas lors d’une mise à jour de stock via le webservice, d’où une désynchronisation), ou un module de synchronisation externe qui patine entre le magasin physique et la boutique. On vérifie d’abord le cache, puis les hooks, puis la synchro.

Le tunnel de paiement en panne

«Malheureusement, aucun moyen de paiement n’est disponible.» Ce message, on le voit souvent après une mise à jour : le module de paiement n’est plus compatible, ou son association à un groupe de clients ou à un transporteur a sauté. On vérifie que le module est actif, à jour, et correctement restreint dans Paiement → Préférences.

Là, c’est une urgence (chaque minute, c’est une vente perdue). Mieux vaut nous appeler directement : dépannage PrestaShop urgent, on intervient 7j/7.

Vider le cache (le réflexe qui règle beaucoup de choses)

Énormément d’affichages bizarres (une modification qui n’apparaît pas, des données figées) viennent simplement d’un cache mal régénéré. Le système de cache accélère le site en stockant des fichiers compilés, mais après une modification importante, ces fichiers deviennent obsolètes. On vide le cache depuis Paramètres avancés → Performances, ou en supprimant le contenu du dossier /var/cache. Et si vous utilisez un cache serveur (Redis, Varnish), pensez à le vider aussi.

Les erreurs de fichiers : .htaccess et permissions (chmod)

Après un changement de serveur ou une fausse manipulation, on tombe souvent sur deux choses : un .htaccess mal généré, ou des permissions de fichiers incorrectes. Pour le .htaccess, le plus simple est de le régénérer depuis Paramètres de la boutique → SEO & URLs (en réenregistrant les paramètres). Pour les permissions (les fameux droits chmod), PrestaShop a besoin de pouvoir écrire dans certains dossiers : des droits mal réglés provoquent des erreurs d’écriture ou des pages cassées.

⚠️ Attention : toucher au .htaccess ou aux permissions à l’aveugle peut aggraver la situation. On garde toujours une copie du fichier d’origine avant toute modification.

Récapitulatif des pannes PrestaShop les plus fréquentes

Quand passer la main pour le dépannage PrestaShop et à qui ?

Beaucoup de corrections sont à votre portée si vous avez un bon niveau technique : activer le mode debug, lire les logs, vider le cache, renommer un dossier de module. Mais dès qu’il faut toucher au code, intervenir sur un site en production, ou quand chaque minute de panne coûte de l’argent, c’est le moment de passer la main.

📊 Donnée terrain CYBERIAL : sur nos 150 boutiques dépannées en 2025, 35 % des interventions concernaient une erreur 500 ou une page blanche. Le temps moyen de résolution est de 45 minutes. C’est exactement ce genre d’incident qu’un œil habitué règle vite, là où un marchand seul peut y passer son week-end.

Pour une panne en cours, on intervient 7j/7 : dépannage PrestaShop urgent, forfait à 150 €, ligne directe au 09 72 03 59 17.

Préventive ou corrective : la règle des 80/20

On revient à la règle du début, parce que c’est elle qui résume tout : viser 80 % de préventif, 20 % de correctif. Plus vous êtes rigoureux en amont (mises à jour, sauvegardes, surveillance), moins vous subissez de pannes, et moins vous payez de corrections d’urgence.

📊 Donnée terrain CYBERIAL : sur nos 350+ boutiques en maintenance, le nombre moyen de pannes passe de 4 par an (avant le forfait) à moins d’une par an après six mois de maintenance préventive. Prévenir coûte moins cher que guérir, et ça stresse beaucoup moins.

C’est aussi pour ça que la séparation préventive / corrective est un peu artificielle dans la pratique : les deux se nourrissent. Un bon correctif documente la cause, ce qui alimente le préventif. Et un bon préventif réduit mécaniquement le correctif.

Gérer sa maintenance soi-même ou la déléguer ?

Vous pouvez tout à fait gérer la maintenance de votre PrestaShop en interne. Ça demande du temps (quelques heures par mois), un bon niveau technique, et surtout de la régularité. Le vrai piège, ce n’est pas la difficulté de chaque tâche, c’est de les repousser. Et c’est exactement comme ça qu’on se retrouve avec une boutique «qui n’a rien eu pendant deux ans».

L’autre option, c’est de confier le tout à une agence de maintenance PrestaShop. Vous ne vous posez plus la question des mises à jour, des sauvegardes ou de la sécurité : c’est surveillé et géré, et quelqu’un répond quand ça casse.

📊 Donnée terrain CYBERIAL : le calcul est vite fait. Une intervention d’urgence (piratage, site à terre) se facture autour de 90 € HT de l’heure, et peut mobiliser plusieurs heures, sans compter les ventes perdues pendant la panne. Le forfait préventif, lui, c’est 69 € HT par mois, tout compris. Prévenir ne coûte pas seulement moins de stress : ça coûte moins cher, tout court.

Quelques repères pour vous décider :

• Côté budget, le marché de la maintenance PrestaShop tourne souvent entre 100 et 300 € par mois en agence (et 50 à 150 € chez un freelance, avec un périmètre plus limité). Pour comprendre ce qui se cache derrière ces écarts, et ce qu’un forfait doit vraiment inclure, voyez nos tarifs de maintenance.
• Côté contrat, tout n’est pas équivalent : support inclus ou non, maintenance corrective comprise ou facturée en plus, hébergement séparé. On a listé les clauses à vérifier (et les pièges) dans notre guide sur le contrat de maintenance PrestaShop.
• Si vous avez déjà un prestataire (freelance ou agence) qui ne suit plus, la reprise de maintenance se fait sans interruption : on récupère le dossier et on prend le relais.

Au passage : un point de vigilance qu’on retrouve partout, c’est la migration de version majeure. Aucun prestataire sérieux ne l’inclut «gratuitement» dans un simple forfait de maintenance (c’est du temps homme conséquent). Vérifiez toujours comment c’est traité dans l’offre.

---

Au final, la maintenance d’une boutique PrestaShop tient en une phrase : un peu de rigueur en continu évite beaucoup de pannes en urgence. Mises à jour, sauvegardes, sécurité et surveillance d’un côté ; diagnostic et correction de l’autre. Les deux vont ensemble, et c’est ce duo qui garde une boutique en ligne et rentable dans la durée.

Et si vous préférez dormir tranquille pendant qu’on s’en occupe : le forfait de maintenance CYBERIAL à 69 € HT/mois couvre tout ce qu’on vient de voir (mises à jour, sauvegardes quotidiennes, surveillance, sécurité et intervention prioritaire), sans engagement. Une panne en cours ? On intervient 7j/7 au 09 72 03 59 17.