Erreurs dans votre boutique en ligne : comment les repérer avant vos clients

Un lundi matin, un client écrit : « J'ai essayé de payer samedi et ça ne marchait pas ». Vous vérifiez et, effectivement, depuis vendredi soir le bouton de paiement ne faisait rien. Une mise à jour de module, un script de la passerelle qui ne se chargeait pas ou un certificat expiré. Deux jours de ventes perdues, et vous l'avez appris parce qu'un client a pris la peine de vous prévenir. La plupart ne préviennent pas : ils partent.

Ce qui peut tomber en panne sans que vous le voyiez

• Des erreurs 500 sur des pages précises : une fiche, une catégorie, le panier. L'accueil fonctionne et vous croyez que tout va bien.
• Des erreurs PHP après une mise à jour de la version de PHP, d'un module ou du thème. Avec le mode debug désactivé, le client voit une page blanche ou une erreur générique.
• Des erreurs JavaScript dans le tunnel de commande. Le serveur répond correctement, mais un script plante dans le navigateur et le bouton de paiement ne réagit pas. Le serveur n'en sait rien.
• Des paiements sans commande : le client paie, la passerelle encaisse et la boutique ne crée pas la commande car la notification n'est pas arrivée.
• Des montants qui ne concordent pas entre ce qui a été encaissé et le total de la commande.
• Des tâches planifiées arrêtées : le cron qui synchronise le stock, envoie les e-mails ou régénère le sitemap ne s'exécute plus.
• Mémoire épuisée ou délais d'attente dépassés sur des traitements longs.

Où regarder quand quelque chose ne va pas

1. Les journaux du serveur web (error log d'Apache ou de Nginx) et de PHP.
2. Les journaux de PrestaShop : Paramètres avancés → Logs, et dans PrestaShop 1.7 et suivants le dossier var/logs.
3. Le mode debug (_PS_MODE_DEV_ dans config/defines.inc.php), qui affiche l'erreur complète. Ne le laissez jamais actif en production pour tout le monde : il expose des chemins et des détails internes.
4. La console du navigateur (F12) dans le tunnel de commande, pour les erreurs JavaScript.
5. Le tableau de bord de la passerelle, pour comparer les encaissements et les commandes.

Surveillance externe : le minimum

Un service qui visite votre boutique toutes les quelques minutes et vous prévient si elle ne répond pas détecte la panne totale. C'est indispensable, mais insuffisant : il ne voit ni une erreur dans le panier, ni un paiement qui échoue, ni un script cassé. Pour cela, il faut surveiller de l'intérieur.

Ce que doit offrir un bon système d'alertes

• Assez de détails pour agir : message d'erreur, fichier et ligne, URL, présence d'un client ou d'un employé, version de PHP et de PrestaShop. « Erreur 500 » et rien d'autre oblige à tout reprendre de zéro.
• Regroupement : la même erreur répétée mille fois doit arriver sous forme d'une alerte avec un compteur, pas de mille messages.
• Limite par heure : si tout casse, un résumé plutôt qu'une avalanche.
• Priorité à l'argent : les alertes de paiement ne devraient être ni regroupées ni mises en sourdine, car chacune correspond à une commande précise.
• Des canaux séparés : les erreurs techniques au développeur, les paiements à la personne qui gère l'administration.
• Pas de données sensibles : une alerte ne doit contenir ni numéros de carte, ni IBAN, ni mots de passe, ni jetons. Les masquer avant l'envoi est impératif et, au regard du RGPD, recommandé aussi pour les e-mails et les numéros d'identité.

Pourquoi sur le mobile

L'e-mail d'alerte finit dans un dossier qu'on consulte quand on peut. Un message dans une application de messagerie se voit sur-le-champ. Telegram est très utilisé pour cela car ses bots se configurent en quelques minutes, acceptent les groupes et sont gratuits.

Une routine qui fonctionne

1. Après chaque mise à jour (de PrestaShop, de PHP, d'un module ou du thème), passez une commande de test complète.
2. Chaque semaine, passez en revue les erreurs regroupées des sept derniers jours, même si personne ne s'est plaint.
3. Chaque jour, comparez les encaissements de la passerelle avec les commandes, ou laissez un rapprochement automatique le faire.
4. Chaque mois, vérifiez que les tâches planifiées s'exécutent toujours.

Check-list

1. Vous avez une surveillance externe de disponibilité.
2. Vous recevez les erreurs PHP et les erreurs 500 avec leurs détails.
3. Vous surveillez les erreurs JavaScript dans le tunnel de commande.
4. Vous êtes alerté des paiements sans commande et des montants qui ne concordent pas.
5. Les alertes sont regroupées et limitées.
6. Les données sensibles sont masquées.
7. Le mode debug est désactivé pour le public.

Comment le résoudre dans PrestaShop

RKR Sentinel envoie sur Telegram les erreurs PHP, exceptions, erreurs fatales, mémoire épuisée, délais dépassés et réponses 500 avec le message, le fichier et la ligne, un extrait de code, la trace, l'URL, le client ou l'employé, le panier et les versions, et chaque type d'erreur peut aller vers une conversation différente. Dans le navigateur, il capture les erreurs JavaScript du tunnel de commande, y compris les fichiers qui ne se chargent pas. Il surveille cinq problèmes de paiement (paiement sans commande, commande sans état, montant qui ne concorde pas, commande bloquée en erreur de paiement et encaissement inconnu, avec rapprochement quotidien avec PayPal et Stripe via des identifiants en lecture seule), et les alertes de paiement ne sont ni regroupées ni mises en sourdine. Les erreurs sont regroupées par empreinte avec un compteur de répétitions, le nombre de messages par heure est limité et tout passe par un filtre qui masque cartes, IBAN, numéros d'identité, jetons, mots de passe et e-mails. Depuis la conversation, sept commandes permettent de consulter l'état, les erreurs, les paiements, une commande ou un panier.