Une boutique PrestaShop peut sembler disponible tout en empêchant une commande, une connexion client ou un paiement. Un simple contrôle de la page d’accueil ne suffit donc pas à protéger votre chiffre d’affaires. Le monitoring consiste à vérifier automatiquement, à intervalles réguliers, que les fonctions essentielles de la boutique répondent correctement, puis à alerter la bonne personne avant que les clients ne signalent le problème. L’objectif n’est pas de recevoir davantage d’e-mails d’alerte : il est d’identifier vite une panne réelle, d’en comprendre l’origine et de réduire son impact.
Ce qu’un monitoring PrestaShop doit réellement surveiller
Le premier niveau est la disponibilité HTTP : un service externe appelle une URL publique et contrôle le code de réponse, le délai de réponse et le certificat HTTPS. Une réponse 200 est généralement attendue pour une page accessible. En revanche, une page produit volontairement redirigée peut répondre en 301 ou 302 sans constituer une panne. Les règles doivent donc être adaptées à chaque URL surveillée.
Ce contrôle est nécessaire, mais il ne détecte pas tous les incidents. Une boutique peut renvoyer une page 200 contenant une erreur applicative, un catalogue vide ou un bouton d’achat inopérant. Un dispositif utile combine plusieurs types de vérifications.
- Disponibilité : page d’accueil, catégorie importante, fiche produit stable et page de contact.
- Performance : temps de réponse du serveur, notamment le TTFB, et évolution des temps de chargement depuis plusieurs localisations.
- Parcours fonctionnel : ajout d’un produit au panier, accès au tunnel de commande, connexion à un compte de test lorsque cela est pertinent.
- Paiement : accès à l’étape de paiement et disponibilité du module, sans nécessairement déclencher de transaction.
- Services techniques : expiration du certificat SSL, résolution DNS, disponibilité de la base de données, espace disque, tâches cron et sauvegardes.
- Sécurité : apparition de fichiers modifiés, erreurs inhabituelles, tentatives de connexion au back-office et alertes de l’hébergeur.
Définir les parcours critiques avant de choisir un outil
Un monitoring efficace commence par une liste courte de scénarios qui représentent les revenus ou le service client. Pour une boutique classique, surveillez au minimum l’accueil, une fiche produit en stock, le panier et l’entrée du tunnel de commande. Pour une activité B2B, l’authentification au compte client peut être plus critique qu’une page éditoriale. Pour une boutique multilingue ou multiboutique, testez les domaines, sous-domaines et langues qui génèrent réellement des commandes.
Exemple de scénario de commande sans paiement réel
Créez un produit de test actif, non indexable si nécessaire, avec un stock suffisant et un prix identifiable. Le scénario automatisé peut ouvrir sa fiche, cliquer sur « Ajouter au panier », vérifier que le compteur ou le récapitulatif du panier contient ce produit, puis atteindre l’étape de livraison ou de paiement. Il doit pouvoir supprimer le produit ou utiliser une session isolée à chaque exécution.
Évitez d’automatiser une commande complète sur un vrai moyen de paiement sans procédure spécifique : cela peut produire des commandes parasites, déclencher des e-mails et fausser les statistiques. Si le prestataire de paiement propose un environnement de test, utilisez-le sur une préproduction séparée. En production, vérifier l’affichage du moyen de paiement, l’accès aux scripts nécessaires et l’absence d’erreur JavaScript est souvent déjà très utile.
Installer une surveillance externe, indépendante de l’hébergement
Le contrôle de disponibilité doit être exécuté depuis l’extérieur de votre serveur. Si le serveur web, le réseau de l’hébergeur ou le DNS tombe, un script installé sur la même machine ne pourra pas vous alerter de manière fiable. Configurez un service de monitoring externe avec plusieurs emplacements de contrôle lorsque l’outil le permet.
Pour chaque URL, définissez un délai réaliste et deux ou trois tentatives avant l’alerte. Une alerte sur un seul échec de quelques secondes peut provenir d’un incident réseau ponctuel. À l’inverse, attendre trop longtemps masque une panne réelle. La règle doit dépendre de votre activité : une boutique dont les commandes arrivent en continu nécessite une détection plus rapprochée qu’un catalogue de demande de devis.
Contrôler le contenu, pas uniquement le statut HTTP
Ajoutez une recherche de texte dans la réponse lorsque l’outil le permet. Sur une fiche produit, cherchez par exemple une référence produit ou un titre stable. Sur le panier, vérifiez la présence d’un libellé tel que « Panier » ou du bloc de récapitulatif. Cette précaution détecte les pages d’erreur personnalisées qui renvoient par erreur un code 200.
Ne choisissez pas un texte susceptible de changer avec une promotion, une traduction ou une bannière de consentement. Évitez également de surveiller une URL avec des paramètres de tracking : ils compliquent l’analyse des journaux et peuvent perturber le cache.
Surveiller les indicateurs serveur qui annoncent une panne
Les pannes PrestaShop sont fréquemment précédées de signaux faibles côté hébergement. Un espace disque presque plein peut empêcher l’écriture des logs, du cache ou des sessions. Une saturation des workers PHP-FPM peut transformer un ralentissement en erreurs 502 ou 504. Une base MySQL lente, verrouillée ou arrivée à sa limite de connexions peut provoquer des pages blanches, des paniers instables ou des erreurs 500.
Demandez à votre hébergeur ou à votre équipe technique un accès aux métriques adaptées : charge CPU, mémoire, espace disque et inodes, connexions MySQL, erreurs PHP, erreurs du serveur web et temps de réponse. Les seuils dépendent du dimensionnement de l’hébergement ; l’essentiel est d’alerter sur une dérive persistante et non sur un pic isolé.
- Surveillez l’espace disponible pour les fichiers, les sauvegardes locales, les images et les logs.
- Relevez les codes 500, 502, 503 et 504 dans les journaux web.
- Suivez les erreurs PHP répétées après une mise à jour de module ou de thème.
- Vérifiez l’exécution des tâches planifiées : génération de flux, e-mails, synchronisation de stock ou imports.
- Contrôlez la date d’expiration du certificat et le renouvellement automatique.
Exploiter les logs PrestaShop sans exposer le mode debug
Le mode debug est un outil de diagnostic, pas un système de monitoring. L’activer en production peut afficher des informations techniques sensibles aux visiteurs et dégrader l’expérience d’achat. Gardez-le désactivé par défaut. Lorsqu’une alerte survient, consultez plutôt les journaux du serveur, les erreurs PHP et les logs applicatifs disponibles dans le back-office selon votre version de PrestaShop.
Lors d’une erreur 500 apparue après l’installation d’un module, notez l’heure exacte de l’alerte, l’URL concernée et l’identifiant de requête fourni par l’hébergeur s’il existe. Recherchez ensuite cette plage horaire dans les logs. Une trace mentionnant une classe absente, une incompatibilité PHP ou une mémoire épuisée permet d’agir sans reproduire l’incident au hasard.
Organiser des alertes actionnables
Une alerte doit répondre à trois questions : quel parcours échoue, depuis quand et qui intervient. Envoyez les indisponibilités critiques vers un canal consulté en dehors des heures de bureau, par exemple SMS, appel, application d’astreinte ou messagerie d’équipe avec accusé de réception. Les rapports de performance peuvent, eux, être regroupés dans un e-mail quotidien ou hebdomadaire.
Préparez une procédure courte : vérifier l’état de l’hébergeur et du DNS, confirmer l’incident depuis un autre réseau, examiner les dernières modifications, consulter les logs, puis restaurer ou désactiver le composant responsable si nécessaire. Documentez les accès d’urgence au back-office, à l’hébergement, au DNS et aux sauvegardes. Sans ces accès, une alerte rapide ne réduit pas le temps de rétablissement.
Tester le dispositif après chaque changement sensible
Une mise à jour de PrestaShop, de PHP, d’un thème ou d’un module de paiement mérite un contrôle renforcé. Exécutez les scénarios critiques juste après le déploiement : navigation, ajout au panier, création de compte, livraison, paiement et e-mails transactionnels selon les fonctionnalités utilisées. Vérifiez aussi que les alertes arrivent réellement au bon destinataire ; une adresse obsolète ou une notification désactivée rend le monitoring inutile.
Pour les boutiques qui dépendent fortement des ventes en ligne, une maintenance PrestaShop peut centraliser la surveillance, les mises à jour testées, l’analyse des alertes et le suivi des sauvegardes. Le point important reste le même : surveiller des parcours réels, avec des seuils adaptés et une procédure d’intervention prête avant l’incident.
À quelle fréquence surveiller une boutique PrestaShop ?
Pour l’accueil, le panier et le tunnel de commande, un contrôle toutes les 1 à 5 minutes est adapté lorsque la boutique reçoit des commandes régulières. Les pages secondaires, le certificat SSL ou les tâches cron peuvent être contrôlés moins souvent. Ajustez surtout la fréquence à l’impact commercial d’une indisponibilité.
Pourquoi mon site est-il accessible mais les clients ne peuvent-ils pas commander ?
La page d’accueil peut fonctionner alors qu’un module de paiement, une règle de transport, le stock, les sessions ou un script JavaScript bloque le tunnel. Un test synthétique qui ajoute un produit au panier et atteint l’étape de paiement permet de détecter ce type d’incident.
Peut-on surveiller PrestaShop sans donner accès au back-office ?
Oui, les contrôles externes d’URL, de contenu, de certificat et de parcours public ne nécessitent pas d’accès au back-office. En revanche, la surveillance des erreurs applicatives, des tâches planifiées ou des ressources serveur requiert un accès à l’hébergement, aux logs ou à un outil de métriques.
Comment éviter les faux positifs dans les alertes de disponibilité ?
Configurez plusieurs tentatives avant escalade, contrôlez depuis plus d’une localisation et vérifiez le contenu attendu en plus du code HTTP. Excluez les périodes de maintenance planifiée et différenciez les redirections normales des erreurs. Analysez ensuite les alertes récurrentes pour corriger leur cause plutôt que les ignorer.
Le monitoring remplace-t-il les sauvegardes PrestaShop ?
Non. Le monitoring détecte un incident, tandis qu’une sauvegarde permet de restaurer des fichiers et une base de données après une erreur, une compromission ou une mise à jour défaillante. Il faut contrôler la réussite des sauvegardes, leur rétention, leur stockage hors du serveur principal et tester périodiquement une restauration.