Les trois questions des deux premières minutes

1. Qu’est-ce qui est tombé exactement ? La boutique seule, le back-office seul, ou les deux ? Toutes les pages ou seulement certaines ? Un back-office qui fonctionne pendant que la vitrine est blanche réduit déjà le champ de recherche de moitié : le cœur démarre, le problème est côté façade — thème, module greffé sur une page publique, surcharge d’un contrôleur.

2. Qu’est-ce qui a changé juste avant ? Mise à jour de PrestaShop ou d’un module, installation d’un thème, édition d’un fichier, intervention de l’hébergeur, expiration d’un certificat, changement de version de PHP, disque plein. Dans mon expérience, la réponse à cette question donne la cause dans la grande majorité des cas. Et quand on me répond « rien n’a changé », c’est presque toujours que le changement est venu du serveur, pas de la boutique.

3. Est-ce que des commandes sont en cours ? Si oui, aucune restauration de sauvegarde ne doit être envisagée avant d’avoir exporté les commandes récentes. Une restauration efface tout ce qui s’est passé depuis la sauvegarde — y compris les paiements encaissés.

Identifier le type de panne

Erreur 500

Le serveur annonce explicitement l’échec. Causes habituelles : erreur PHP fatale, fichier .htaccess invalide, version de PHP incompatible, limite mémoire atteinte. La marche à suivre détaillée est dans l’article erreur 500 sur PrestaShop.

Page blanche

Le serveur répond « tout va bien » et n’envoie rien. C’est une erreur fatale dont l’affichage est désactivé. Il faut forcer PrestaShop à parler : voir page blanche PrestaShop.

Erreur de connexion à la base

Message explicite au chargement. Soit les identifiants dans app/config/parameters.php ont changé, soit le serveur de base de données est saturé ou arrêté. C’est souvent un problème d’hébergement, pas de boutique : commencez par le support de votre hébergeur.

Boutique extrêmement lente, puis délai dépassé

Ce n’est pas une panne franche mais une saturation : requêtes trop lourdes, tâche planifiée partie en boucle, robot qui aspire le site, cache désactivé. Voir PrestaShop lent.

Le paiement échoue

La boutique fonctionne, mais le tunnel casse à la dernière étape. Causes fréquentes : clés d’API expirées ou régénérées, URL de retour injoignable, certificat, conflit JavaScript, pare-feu qui bloque la notification du prestataire. C’est la panne la plus coûteuse, parce qu’elle est invisible depuis la page d’accueil.

Back-office inaccessible seul

Souvent un module d’administration, un cache corrompu, ou un jeton de session invalide. Videz var/cache/ par FTP : dans la majorité des cas, cela suffit.

Trouver le message d’erreur réel

Tant que vous n’avez pas lu le message, vous devinez. Et deviner sur une boutique en production coûte cher.

Trois endroits, dans cet ordre :

  1. var/logs/ : les journaux applicatifs de PrestaShop. Regardez les fichiers les plus récents et la dernière ligne horodatée au moment de la panne.
  2. Le journal d’erreurs PHP de l’hébergeur, accessible depuis votre panneau d’hébergement. C’est là qu’atterrissent les erreurs fatales — y compris celles qui empêchent PrestaShop de démarrer, donc celles que var/logs/ ne verra jamais.
  3. La console du navigateur (touche F12, onglet « Console » puis « Réseau »). Indispensable quand la page s’affiche mais qu’un bouton ne répond plus : les conflits JavaScript ne laissent aucune trace côté serveur.

Notez le message exact, avec le fichier et le numéro de ligne. C’est l’information qui transforme une panne mystérieuse en correction de dix minutes — et c’est la première chose que vous demandera n’importe quel prestataire sérieux.

Les gestes sûrs, par ordre de rentabilité

  1. Sauvegarder dans l’état. Fichiers et base, avant toute manipulation. Oui, même si la boutique est cassée : c’est cette copie qui permettra de comprendre ce qui s’est passé, et de revenir en arrière si une tentative aggrave les choses.
  2. Vider var/cache/. Supprimez le contenu du dossier par FTP, PrestaShop le reconstruit seul. C’est sans danger, et c’est le geste qui règle le plus grand nombre de pannes — en particulier après une mise à jour interrompue.
  3. Vérifier l’espace disque. Un disque plein provoque des pannes d’apparence très variée : sessions impossibles à écrire, cache corrompu, base en lecture seule. Cela se vérifie en dix secondes depuis le panneau d’hébergement.
  4. Vérifier la version de PHP active. Si elle a changé récemment, revenez temporairement à la précédente pour confirmer le diagnostic — puis planifiez une montée de version plutôt que de rester sur une version de PHP abandonnée.
  5. Désactiver le dernier élément installé ou mis à jour. Un seul, puis test. Si vous en désactivez cinq d’un coup et que la boutique revient, vous ne savez toujours rien.
  6. Remettre un fichier .htaccess propre, régénéré depuis le back-office si vous y avez accès.

Ce qui aggrave la situation

Restaurer une sauvegarde sans avoir compris. Si la cause est extérieure à la boutique — version de PHP, quota, limite serveur, attaque en cours —, la panne revient aussitôt, et vous avez perdu les commandes passées entre-temps. La restauration est une solution de dernier recours, pas un premier réflexe.

Modifier des fichiers directement sur le serveur, sans copie. C’est ainsi que se glissent les espaces avant <?php et les encodages invalides qui provoquent justement les pages blanches.

Augmenter la mémoire PHP indéfiniment. Cela masque le symptôme. Si une page de catalogue réclame un gigaoctet, c’est qu’un module charge sans limite — et il le fera encore demain, en pire.

Tout désactiver d’un coup. Vous perdez l’information la plus précieuse : lequel était responsable.

Passer la boutique en mode développement et l’y laisser. Les messages d’erreur exposent vos chemins serveur et parfois des informations de configuration à tous les visiteurs — robots compris. On l’active le temps du diagnostic, on le désactive aussitôt.

Attendre que « ça revienne tout seul ». Une panne qui disparaît sans intervention n’est pas résolue : elle reviendra, probablement un jour de forte affluence.

Quand appeler quelqu’un

Trois signaux doivent vous faire arrêter les manipulations :

  • Vous ne trouvez pas le message d’erreur. Continuer sans lui, c’est tirer au hasard sur une boutique qui ne vend plus.
  • La panne touche le paiement ou les données clients. Le risque n’est plus seulement commercial.
  • Vous soupçonnez une intrusion : fichiers apparus récemment, redirections étranges, envois de spam depuis le serveur. Dans ce cas, le nettoyage et la restauration doivent être menés dans un ordre précis, sinon la boutique est réinfectée en quelques heures.

Quand vous écrivez à quelqu’un, donnez d’emblée : l’adresse de la boutique, la version de PrestaShop et de PHP, ce qui a changé juste avant, le message d’erreur exact, et si des commandes sont en cours. Avec ces cinq éléments, un diagnostic commence tout de suite. Sans eux, la première heure se passe à les reconstituer.

C’est l’objet du dépannage e-commerce. Et pour une boutique qui tient encore debout mais donne des signes de fatigue, le diagnostic identifie les fragilités avant qu’elles ne deviennent des pannes.

Checklist

  • Noter l’heure de la panne et ce qui a changé juste avant
  • Déterminer ce qui est touché : boutique, back-office, ou les deux
  • Sauvegarder fichiers et base dans l’état, avant toute manipulation
  • Lire var/logs/, le journal PHP de l’hébergeur, la console du navigateur
  • Vider var/cache/
  • Vérifier l’espace disque et la version de PHP active
  • Isoler un seul élément à la fois, avec un test entre chaque
  • Ne jamais restaurer une sauvegarde avant d’avoir compris
  • Tester le parcours d’achat complet avant de déclarer la panne résolue

Questions fréquentes

La boutique est revenue après avoir vidé le cache. C’est réglé ?

Le symptôme a disparu, pas la cause. Un cache corrompu est toujours corrompu par quelque chose : mise à jour interrompue, déploiement partiel, disque plein, deux processus qui écrivent en même temps. Tant que vous ne savez pas quoi, la panne reviendra.

Comment savoir si c’est la boutique ou l’hébergeur ?

Trois indices pointent vers l’hébergeur : d’autres sites du même compte sont touchés, la panne coïncide avec une maintenance annoncée, ou le message concerne la base de données ou un dépassement de ressources. Dans le doute, ouvrez un ticket en parallèle de votre diagnostic — cela ne coûte rien et vous fait gagner du temps.

Puis-je afficher une page « maintenance » pendant la panne ?

Oui, et c’est recommandé si la panne dure. Le mode maintenance de PrestaShop renvoie un code approprié aux moteurs de recherche, ce qui évite qu’ils interprètent la panne comme une disparition des pages. Pensez à y mettre un moyen de vous contacter.

Je n’ai aucune sauvegarde. Que faire ?

Commencez par en faire une, maintenant, même de la boutique cassée : copie des fichiers et export de la base. Puis traitez la panne. Et une fois tout rentré dans l’ordre, mettez en place des sauvegardes automatiques stockées ailleurs que sur le serveur — et testez une restauration. Une sauvegarde jamais restaurée n’est pas une sauvegarde, c’est une hypothèse.

Combien de temps pour rétablir une boutique ?

Quand le message d’erreur est identifié, la correction prend souvent moins d’une heure. Ce qui prend du temps, c’est de trouver ce message, et de défaire les manipulations faites en panique avant l’appel. D’où l’intérêt de consigner chaque action.