Panier
- Patryk Marek
- News
- 0 aime
- 129 vues
- 0 commentaires
Notez l’adresse exacte, l’heure avec le fuseau horaire et l’action après laquelle l’erreur est apparue. Ces trois informations permettent de rechercher le même événement dans les logs. Le seul numéro 500 ou 522 n’indique pas encore le module qu’il faut modifier.
Ce guide aide à préparer un signalement pour le diagnostic. Il ne décrit pas la réparation d’une boutique précise et ne présente pas des causes d’exemple comme un résultat établi.
Que noter pendant la panne ?
- Adresse et action : par ex. ouverture d’un produit, enregistrement d’un réglage dans le panneau ou passage du panier à la livraison. N’enregistrez pas dans un signalement public les tokens présents dans l’adresse du panneau.
- Heure : date, heure et fuseau, par ex.
2026-09-26 14:32 Europe/Warsaw. Si le problème revient, notez deux ou trois occurrences concrètes. - Réponse : code HTTP, message visible ainsi que l’identifiant de requête, si la page d’erreur le fournit. Complétez la capture d’écran par le texte du message.
- Périmètre : une seule adresse ou toute la boutique, front-office ou panneau, utilisateur connecté ou invité, un seul réseau ou aussi un second.
- Dernière modification : mise à jour, installation d’un module, import, changement d’un réglage d’hébergement. Indiquez la date ; le seul ordre des événements ne prouve pas la cause.
L’erreur 500 et l’erreur 522 nécessitent des points de départ différents
| Réponse | Par quoi commencer | Ce que l’on ne sait pas encore |
|---|---|---|
| HTTP 500 | Comparez l’heure et le chemin avec le log de l’application ainsi qu’avec celui du serveur qui traite la requête. | Le code n’identifie pas à lui seul le module, la requête ni le réglage PHP. Des pannes différentes peuvent renvoyer le même statut. |
| Cloudflare 522 | Vérifiez la connexion entre Cloudflare et le serveur d’origine. Notez le Ray ID s’il est visible et transmettez l’heure à l’hébergeur. | Le code seul ne confirme pas une erreur PrestaShop. La source peut être notamment une indisponibilité ou une surcharge du serveur, ou encore un blocage des connexions. |
| Page blanche sans statut enregistré | Vérifiez la réponse du document principal dans les outils du navigateur ; conservez l’adresse et l’heure. | On ne sait pas encore si le problème concerne la réponse du serveur, un script dans le navigateur ou une ressource nécessaire à l’affichage de la page. |
Description du 522 et recommandations pour la connexion au serveur d’origine : documentation Cloudflare. Signification générale du statut 500 : HTTP Semantics, RFC 9110.
Comment préparer un test simple de reproduction ?
Exemple démonstratif de signalement : « À 14:32, j’ouvre la fiche produit en tant qu’invité. Le document a le statut 500. La page d’accueil fonctionne dans le même navigateur. À 14:35, ce même produit fonctionne depuis un autre réseau ». Une telle note ne diagnostique pas la cause, mais indique des requêtes concrètes à comparer.
À chaque répétition, modifiez une seule condition et notez le résultat. Si vous videz en même temps le cache, changez de PHP et désactivez plusieurs modules, il sera difficile de déterminer quelle modification a influencé le comportement de la boutique.
Quels logs transmettre à la personne chargée du diagnostic ?
Demandez la vérification d’un court intervalle de temps autour de l’événement : log de l’application, erreurs PHP et serveur WWW, et, en présence d’une couche intermédiaire, également ses événements. L’emplacement d’enregistrement des logs dépend de la version de la boutique et de la configuration de l’hébergement. Au lieu de supposer un chemin, donnez à l’administrateur l’heure exacte, l’adresse ainsi que la méthode de requête, si vous la connaissez.
Les extraits de logs peuvent contenir des adresses e-mail, des identifiants de session et des données de commande. Transmettez l’extrait nécessaire par un canal convenu et supprimez les secrets. Un fichier HAR complet peut également contenir de telles informations ; ne le publiez pas comme simple pièce jointe sur un forum.
Comment comparer les couches sans modifier la protection de toute la boutique ?
La comparaison des réponses via le CDN et directement depuis le serveur doit être préparée par un administrateur connaissant la configuration du domaine, du TLS et de l’accès à l’origine. La différence entre les réponses est un indice pour des tests complémentaires, et non une preuve automatique de la responsabilité du WAF ou de PrestaShop.
Utilisez le mode débogage sur une copie de travail ou dans un accès contrôlé. La désactivation globale de la protection ou l’affichage des exceptions détaillées à tous les visiteurs n’est pas nécessaire pour rédiger un signalement utile.
Modèle de signalement prêt à télécharger
Télécharger le formulaire de description de panne — TXT. Remplissez les champs, et indiquez « non vérifié » pour toute information manquante. Le formulaire ne demande ni mots de passe ni clés API.
Que vérifier après la correction ?
Répétez les étapes notées dans les mêmes conditions, vérifiez le résultat du fonctionnement et les nouvelles entrées dans les logs. En cas de problème sporadique, une seule ouverture correcte de la page ne confirme que cet essai. Définissez avec l’intervenant la période d’observation, le périmètre des tests ainsi que le signal de nouveau signalement.
Si le problème est apparu lors d’un changement de version, utilisez aussi la liste de préparation à la mise à jour de PrestaShop. Un guide séparé explique le rôle des en-têtes de sécurité HTTP.
commentaires (0)