Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

Écrire un message contact@allaux.fr
FR EN TR
allaux.
Urgence Parler de mon projet

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.

Décrire mon problème Écrire un message

Un écran de boutique en alerte d’où partent des chemins de diagnostic vers plusieurs causes possibles, l’un éclairé en ambre.

À 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.

Les quatre pages les plus utiles au départ

Dans cette rubrique

Questions fréquentes

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.

Décrivez votre besoin en 1 minute

Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.

Où en est votre boutique en ce moment ?
Sur quelle plateforme tourne le site ?
Que s’est-il passé juste avant la panne ?

C’est souvent l’information qui fait gagner le plus de temps au diagnostic.

De quels accès disposez-vous ? (facultatif)

Sans accès, la première étape sera de les récupérer — cela change le délai.

Quelle est l’adresse du site concerné ? (facultatif)

Un premier coup d’œil avant même la réponse permet souvent de dégrossir le diagnostic.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Pages liées