# Ma boutique a un problème : par où commencer

> Votre boutique ne se comporte plus comme hier et vous ne savez pas encore pourquoi. Cette rubrique regroupe trente pannes classées par ce que vous constatez à l’écran, pas par cause technique : vous partez du symptôme, la page vous mène vers l’origine probable.

- Source canonique : [https://allaux.fr/problemes](https://allaux.fr/problemes)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## À qui s’adresse cette rubrique

Vous arrivez ici parce que quelque chose ne va pas et que le message d’erreur, quand il y en a un, ne vous dit rien. Le tunnel de commande n’aboutit plus, l’administration refuse de s’ouvrir, une page reste blanche, ou le site répond en dix secondes alors qu’il répondait en une. À ce moment précis, la question n’est pas de choisir un prestataire : elle est de savoir d’où vient la panne.

Les pages qui suivent sont donc écrites pour quelqu’un qui n’a pas encore de diagnostic. Elles partent de ce qui se voit — un écran, un comportement, un courriel d’alerte de l’hébergeur — et remontent vers les causes possibles, de la plus fréquente à la plus rare. Aucune ne suppose que vous sachiez lire du code.

## Comment la rubrique est organisée

Les trente pages se répartissent en quatre familles. Les pannes d’affichage : page blanche, images absentes, thème cassé après modification, mise en page mobile dégradée. Les pannes fonctionnelles : paiement impossible, tunnel bloqué, courriels non reçus, imports et exports qui échouent, synchronisation interrompue. Les pannes d’infrastructure : erreur 500, erreur 504, connexion à la base de données refusée, nom de domaine qui ne pointe plus, certificat expiré. Et les situations de gestion : site laissé sans maintenance, prestataire injoignable, panne apparue juste après une mise à jour ou un changement d’hébergeur.

Si votre symptôme figure dans la liste ci-dessous, allez directement sur la page correspondante. Si vous hésitez entre plusieurs, commencez par celle qui sépare une panne du site d’une panne d’hébergement : c’est le premier embranchement du diagnostic, et il évite de chercher longtemps du mauvais côté.

## Affichage ou serveur : la distinction qui fait gagner du temps

Une panne d’affichage laisse le serveur répondre : une page revient bien, elle est seulement vide, fausse ou mal habillée. Une panne serveur empêche la réponse d’exister : le navigateur reçoit un code 500, 502 ou 504, ou attend jusqu’à expiration. Dans le premier cas, la cause est presque toujours dans le thème, un module, le cache ou un chemin de fichiers. Dans le second, elle est du côté de PHP, de la base de données ou de la configuration de l’hébergement.

Dans les deux cas le réflexe est le même : ouvrir le journal d’erreurs avant de toucher quoi que ce soit. Sur PrestaShop, l’information utile est dans var/logs/ et dans le journal de l’hébergeur ; sur WordPress, la constante WP_DEBUG_LOG écrit dans wp-content/debug.log. Une seule ligne y nomme souvent le fichier fautif. Modifier le site avant de l’avoir lue revient à effacer la trace qui contenait la réponse.

## Avant toute manipulation

> Sauvegardez les fichiers et la base de données avant d’essayer une correction, même une correction qui paraît anodine. Une restauration possible transforme une panne en incident ; une restauration impossible la transforme en refonte.

## Les quatre pages les plus utiles au départ

- **Site ou hébergement : d’où vient la panne** — Le premier tri à faire. Il oriente vers le code ou vers le serveur, et évite de chercher pendant des heures du mauvais côté. ([/problemes/site-ou-hebergement-d-ou-vient-la-panne](/problemes/site-ou-hebergement-d-ou-vient-la-panne))
- **Erreur 500 ou page blanche** — Le message le plus courant et le moins bavard, et sa variante muette. Ce qu’ils recouvrent réellement et comment obtenir l’erreur PHP qui se cache derrière. ([/problemes/erreur-500-d-ou-vient-elle](/problemes/erreur-500-d-ou-vient-elle))
- **Mon site ne répond plus du tout** — Le navigateur tourne dans le vide et n’affiche même pas le site. Les quatre vérifications qui séparent une panne d’hébergement d’une panne applicative. ([/problemes/site-ne-repond-plus](/problemes/site-ne-repond-plus))
- **Lire les journaux d’erreurs PrestaShop** — La procédure pas à pas pour trouver et interpréter les journaux, avant d’ouvrir le moindre fichier du thème. ([/guides/lire-logs-erreurs-prestashop](/guides/lire-logs-erreurs-prestashop))

## FAQ

### Je ne sais pas nommer mon symptôme, par où commencer ?

Par la page qui distingue une panne du site d’une panne d’hébergement. Elle ne demande aucune compétence technique : elle vous fait vérifier trois choses observables depuis un navigateur, et le résultat vous envoie vers la bonne famille de pages.

### Faut-il un accès FTP ou SSH pour suivre ces pages ?

Pas pour la partie diagnostic. La plupart des vérifications se font depuis l’administration de la boutique ou depuis le panneau de l’hébergeur. L’accès aux fichiers devient nécessaire au moment de corriger, et c’est signalé quand c’est le cas.

### Ces pages valent-elles pour PrestaShop comme pour WooCommerce ?

Oui : les symptômes décrits ici sont communs aux deux plateformes, et Shopify partage une partie d’entre eux. Quand la manipulation diffère selon la plateforme, la page donne les deux chemins plutôt qu’un seul.

### Ma boutique est arrêtée maintenant, dois-je vraiment lire avant d’agir ?

Lisez au moins le paragraphe qui identifie la cause : c’est cinq minutes, et cela évite les manipulations qui aggravent la situation, comme réinstaller un module ou vider un cache avant d’avoir relevé le message d’erreur. Si vous préférez déléguer immédiatement, la page urgence explique comment me transmettre les éléments utiles.

### Le site fonctionne de nouveau tout seul, faut-il quand même chercher ?

Oui. Une panne qui disparaît d’elle-même est presque toujours une saturation passagère : mémoire PHP, tâche planifiée trop lourde, pic de trafic, disque plein. Elle revient, et généralement au pire moment. Le journal d’erreurs de la période concernée contient encore la trace.