Une boutique PrestaShop peut tomber alors que personne n’a touché au code la veille. Pas de mise à jour visible, pas de nouveau module installé, et pourtant le site devient inaccessible, le paiement casse ou les emails de commande cessent de partir.

Le point utile n’est donc pas seulement de réparer après coup. Il faut distinguer ce qui coupe toute la boutique, ce qui casse une fonction critique, et ce qui reste discret jusqu’au premier client bloqué.

Dans cet article, vous trouverez une checklist simple, datée au 16 septembre 2026, pour savoir quoi surveiller automatiquement et quoi contrôler chaque mois afin d’anticiper une panne PrestaShop avant qu’elle ne devienne visible pour vos clients.

Une boutique PrestaShop peut tomber sans mise à jour visible

Beaucoup de contenus parlent surtout de l’après-panne : erreur 500, page blanche, module cassé. C’est utile une fois le site arrêté. En exploitation quotidienne, le bon réflexe consiste à classer les incidents par niveau de gravité pour surveiller les bons points au bon moment.

Vous gagnerez du temps si vous séparez trois scénarios : la coupure totale, la fonction critique cassée et la panne silencieuse. Les contrôles prioritaires ne sont pas les mêmes.

Ce qui coupe tout le site

Ici, le symptôme est clair : la boutique ne répond plus, le front ne charge pas, le back-office devient inaccessible ou une erreur serveur s’affiche. Ce type d’incident peut venir d’un problème d’hébergement, d’un disque saturé, d’un domaine expiré ou d’un changement technique appliqué hors de votre radar.

Si vous êtes déjà dans cette situation, vous pouvez comparer les symptômes avec les causes les plus fréquentes d’un site PrestaShop en panne. Le point important ici est simple : une coupure totale n’est pas toujours liée à un déploiement récent.

Ce qui casse seulement une fonction clé

Dans ce second cas, la boutique semble encore en ligne. Les fiches produit s’affichent, la page d’accueil répond, mais une fonction essentielle ne marche plus : panier, checkout, paiement, connexion client ou accès au back-office.

Ce scénario est piégeux, car le problème peut durer alors que le site répond encore. Vous voyez du trafic, mais les commandes ne passent plus correctement.

Ce qui reste invisible jusqu’au premier client bloqué

Le troisième scénario est le plus trompeur. Le site reste visible, pourtant les emails transactionnels ne partent plus, certaines ressources ne chargent plus en HTTPS, ou une dépendance externe liée à un module ne répond plus.

Sur une page servie en HTTPS, les navigateurs bloquent les contenus mixtes bloquants. Après un renouvellement SSL ou un changement de domaine mal finalisé, certains scripts ou feuilles de style encore appelés en HTTP peuvent donc casser une fonction sans faire tomber tout le site.

Les expirations silencieuses à surveiller en priorité

Les échéances oubliées provoquent des coupures évitables. Elles arrivent souvent hors des périodes de mise à jour, donc au moment où personne ne s’attend à un incident.

Votre objectif n’est pas de mémoriser ces dates, mais de les sortir d’une tête humaine pour les intégrer à une routine documentée.

Certificat SSL public et certificat d’origine

Un certificat SSL public expiré reste un classique. Let’s Encrypt rappelle que ses certificats ont une durée de validité de 90 jours et que leur modèle repose sur le renouvellement automatisé, pas manuel : durée de validité des certificats Let’s Encrypt. Si l’automatisation échoue et que personne ne contrôle la date d’expiration, la boutique peut se retrouver bloquée du jour au lendemain.

Point souvent oublié : si vous utilisez un CDN ou un proxy, le certificat visible côté visiteur n’est pas toujours le seul à surveiller. Le certificat d’origine peut lui aussi expirer en silence. L’erreur classique consiste à vérifier seulement le cadenas dans le navigateur. À éviter : contrôler aussi le certificat utilisé entre le proxy et le serveur.

Nom de domaine et renouvellement

Un nom de domaine expiré ne coupe pas forcément immédiatement le site de la même façon chez tous les registrars. ICANN indique qu’une période de grâce peut exister, mais son effet visible peut varier. La bonne décision consiste donc à traiter l’échéance du domaine comme une date ferme, pas comme une marge de sécurité.

À vérifier chaque mois : la date d’expiration, le mode de renouvellement, le moyen de paiement associé et la personne réellement responsable du compte registrar. Cas classique : un domaine encore rattaché à une ancienne agence, à un salarié parti ou à une adresse email peu surveillée.

Licence de module et dépendances externes

Une licence de module expirée ne coupe pas toujours toute la boutique. En revanche, elle peut bloquer une fonction critique, un accès API ou empêcher une mise à jour nécessaire. C’est typiquement le genre d’incident qui laisse le front accessible alors qu’une brique métier devient inutilisable.

Le bon réflexe consiste à tenir un inventaire simple : nom du module, rôle métier, échéance de licence, dépendance externe éventuelle, responsable et test à exécuter après renouvellement. Sans cet inventaire, vous découvrez souvent le problème le jour où le paiement, le transporteur ou la synchronisation ne répond plus.

Les changements côté hébergeur qui peuvent casser la boutique du jour au lendemain

L’hébergement n’est pas un décor. C’est une source de panne à part entière. Une boutique stable pendant des mois peut sortir de son équilibre après un changement de version PHP, une mémoire trop juste ou un espace disque saturé.

Sur ce point, les contrôles préventifs valent mieux qu’un ticket ouvert après la coupure.

Version PHP et mémoire : le duo à contrôler de près

Un changement PHP appliqué côté hébergeur peut casser une boutique sans modification de votre part. Pour PrestaShop 9, la documentation officielle recommande PHP 8.5 et un memory_limit minimum de 512M : prérequis système de PrestaShop 9. Elle rappelle aussi qu’il faut tester thème, modules et personnalisations avant la mise en production.

Au 16 septembre 2026, PHP rappelle qu’une branche suit 2 ans de support actif puis 2 ans de correctifs de sécurité. À cette date, PHP 8.2 n’est plus en support actif et sa fin de support sécurité est fixée au 31 décembre 2026 : versions PHP supportées. Cela ne veut pas dire qu’il faut changer à l’aveugle. Cela veut dire qu’une décision PHP doit être datée, testée et documentée.

Erreur classique : laisser l’hébergeur changer PHP puis vérifier seulement si la page d’accueil charge encore. À éviter : tester aussi le back-office, le panier, le tunnel et les emails transactionnels. Si vous préparez une montée de version, vous pouvez aussi relire les points à vérifier avant une montée de version PrestaShop.

Disque plein, inode saturé et base qui n’écrit plus

Quand le disque est plein, les symptômes peuvent être brusques : écritures impossibles en base, back-office instable, commandes qui ne s’enregistrent plus correctement. cPanel documente par exemple l’erreur MySQL « Got error 28 from storage engine » comme un symptôme de disque plein : erreur MySQL 28 liée au stockage.

Ce problème reste souvent discret jusqu’au seuil critique. La boutique semble normale, puis une tâche d’écriture échoue et plusieurs symptômes apparaissent en même temps. Le contrôle utile ne porte donc pas seulement sur l’espace disque global, mais aussi sur sa progression, les logs, les sauvegardes, les fichiers de cache et les inodes si votre hébergement les limite.

Si la panne est déjà visible côté serveur, un premier cadrage utile consiste à lancer un diagnostic d’erreur 500 sur PrestaShop pour distinguer un problème applicatif d’un problème d’infrastructure.

Pourquoi le site peut rester ouvert alors que les commandes se perdent déjà

Une boutique accessible n’est pas forcément une boutique opérationnelle. Le coût apparaît quand une commande n’est pas confirmée, qu’un mot de passe ne peut pas être réinitialisé ou qu’un paiement échoue sans alerte immédiate.

Ces pannes partielles durent souvent plus longtemps, justement parce qu’aucune page ne semble totalement hors service.

Quota d’emails, files d’attente et délivrabilité cassée

Un quota email atteint ne met pas nécessairement le site hors ligne. En revanche, il peut bloquer l’envoi des emails de commande, de création de compte ou de réinitialisation. C’est une différence importante : le client pense avoir commandé, mais ne reçoit rien.

Les points à surveiller sont simples : volume d’envoi, messages différés, échecs, boîtes pleines, quota de stockage mail et saturation des inodes côté messagerie. L’erreur classique consiste à vérifier seulement que le SMTP répond. À éviter : contrôler aussi si les messages sortent réellement, dans quels délais, et si des refus ou files d’attente s’accumulent.

Checkout, paiement et scripts bloqués sans panne totale

Après un renouvellement SSL mal finalisé, un changement de domaine ou une ressource encore appelée en HTTP, certaines parties du checkout peuvent cesser de fonctionner alors que la boutique reste visible. Le navigateur bloque alors les contenus mixtes bloquants.

Le symptôme typique est un tunnel qui charge partiellement, une étape qui boucle, un bouton de paiement inactif ou un script tiers qui ne s’initialise plus. Si vous constatez ce type de panne partielle, un premier cadrage utile consiste à demander un pré-audit d’un paiement PrestaShop qui échoue afin d’isoler rapidement la brique en cause.

La surveillance minimale à mettre en place pour être alerté avant vos clients

Une surveillance efficace ne se limite pas à un ping sur la page d’accueil. Une boutique peut répondre en HTTP 200 tout en ayant un panier cassé, un paiement en erreur ou des emails qui ne partent plus. La bonne approche combine des alertes automatiques et un contrôle mensuel documenté.

Au 16 septembre 2026, ce cadre peut rester simple : quelques points suivis sérieusement valent mieux qu’un dispositif trop large qui n’est jamais tenu à jour.

Les alertes automatiques à configurer

Premier niveau : la disponibilité. Vous devez être alerté si la page d’accueil ne répond plus ou si son comportement change anormalement.

Deuxième niveau : les échéances. Programmez des rappels pour le certificat SSL, le nom de domaine et les licences des modules critiques.

Troisième niveau : les fonctions métier. Prévoyez au minimum un contrôle régulier du back-office, du panier, du paiement et d’un envoi d’email transactionnel. C’est ce niveau qui repère les pannes silencieuses avant vos clients.

Les contrôles mensuels à documenter

Une fois par mois, reprenez toujours la même liste :

Le point décisif est d’attribuer un responsable à chaque contrôle. Une checklist sans propriétaire finit souvent oubliée. Si vous préférez déléguer ce suivi, la maintenance mensuelle d’une boutique PrestaShop permet de poser une routine suivie dans le temps.

Mettez en place une checklist anti-coupure dès cette semaine

Vous n’avez pas besoin de tout refaire pour réduire le risque. Il faut surtout sortir les points critiques de l’improvisation. Commencez par établir une liste des échéances, des tests métier et des personnes responsables. Ensuite, ajustez l’outillage.

La checklist en 30 minutes pour repartir sur une base saine

  1. Listez vos échéances : SSL, domaine, licences de modules critiques.
  2. Notez votre version PHP active et l’environnement d’hébergement réellement utilisé.
  3. Vérifiez l’espace disque disponible et les signaux de saturation.
  4. Contrôlez les quotas d’emails et l’état des envois transactionnels.
  5. Testez un parcours court : accueil, fiche produit, ajout au panier, checkout, email.
  6. Identifiez qui reçoit les alertes et qui intervient en premier.

Cette base permet déjà de structurer les contrôles les plus utiles sur les causes silencieuses vues plus haut. L’erreur classique est de faire ces vérifications une seule fois. Le bon rythme est mensuel, avec une trace écrite et datée.

Quand passer d’un contrôle interne à un support externe

Si vous dépendez de plusieurs prestataires, d’un hébergeur, d’un CDN et de modules tiers, la coordination devient vite le point faible. À partir du moment où personne n’est clairement responsable de la surveillance, il est plus sûr de formaliser un support récurrent ou un support ponctuel cadré.

Si vous gardez la main en interne, utilisez cette checklist comme procédure de base avant d’ouvrir un ticket. Si cette surveillance n’a pas de propriétaire clair, le support PrestaShop ponctuel ou au mois permet de cadrer à la fois le suivi et l’intervention. Chez KLN-WEB, j’interviens aussi en direct pour les e-commerçants et en marque blanche pour les agences, avec diagnostic gratuit et réponse sous 24 h.

Questions fréquentes

Pourquoi une boutique PrestaShop peut-elle tomber sans aucune mise à jour apparente ?

Parce qu’une panne ne vient pas toujours du code déployé. Une boutique peut tomber à cause d’un certificat SSL expiré, d’un nom de domaine non renouvelé, d’un changement PHP appliqué par l’hébergeur, d’un disque saturé ou d’une licence de module expirée. Dans beaucoup de cas, personne n’a touché au site la veille, mais l’exploitation a dérivé jusqu’au point de rupture.

Comment savoir à l’avance si le certificat SSL ou le nom de domaine va expirer ?

Le plus fiable est de combiner un rappel automatique avec un contrôle mensuel documenté. Vérifiez la date d’expiration du certificat public et, si vous utilisez un proxy ou un CDN, contrôlez aussi le certificat d’origine. Pour le domaine, ne supposez jamais qu’une période de grâce vous sauvera : notez l’échéance, le mode de renouvellement et la personne responsable du compte registrar.

Un changement de version PHP par l’hébergeur peut-il casser PrestaShop du jour au lendemain ?

Oui. Une version PHP modifiée côté hébergeur peut faire sortir votre boutique de sa plage de compatibilité ou révéler une mémoire trop faible. Le risque augmente si le thème, les modules ou les personnalisations n’ont pas été testés sur cette version. Il faut donc surveiller la version PHP active, dater la décision technique et tester le front, le back-office et le tunnel après tout changement.

Quels quotas surveiller pour éviter une panne silencieuse : disque, inode, emails, base de données ?

Surveillez d’abord l’espace disque disponible, car un disque plein peut empêcher les écritures en base et provoquer des symptômes brusques. Vérifiez aussi les inodes si votre hébergement les limite, ainsi que les quotas et files d’attente email. Côté base, le point utile n’est pas seulement sa taille, mais sa capacité à continuer d’écrire sans erreur au moment des commandes.

Pourquoi le site reste accessible alors que les emails de commande ou de mot de passe ne partent plus ?

Parce que l’affichage du site et l’envoi des emails transactionnels reposent sur des briques différentes. Une boutique peut donc continuer à servir ses pages alors qu’un quota email est atteint, qu’une file d’attente s’allonge ou qu’une boîte est pleine. C’est une panne silencieuse classique : le client voit le site, mais une partie du parcours après commande ne fonctionne déjà plus.

Quelle surveillance minimale mettre en place pour être alerté avant les clients ?

Mettez en place trois niveaux. D’abord, une alerte de disponibilité si le site ne répond plus. Ensuite, des rappels d’échéance pour SSL, domaine et licences critiques. Enfin, un contrôle métier régulier du back-office, du panier, du paiement et d’un email transactionnel. Un simple ping de la page d’accueil ne suffit pas, car une boutique peut répondre tout en perdant des commandes.