WooCommerce site cassé : diagnostic rapide et remise en ligne d'urgence

WooCommerce site cassé : diagnostic rapide et remise en ligne d'urgence

Votre boutique WooCommerce est inaccessible. Avant de chercher la cause, deux décisions s'imposent dans les deux premières minutes : avez-vous une sauvegarde récente ? Quel est le coût commercial de chaque minute d'arrêt ? Ce guide suit une logique d'urgence — triage d'abord, diagnostic ensuite, prévention en dernier — précisément parce que la plupart des ressources disponibles font l'inverse.

Il s'adresse aux développeurs et aux agences qui interviennent sur une boutique cliente en erreur. Les étapes sont séquentielles : chacune filtre les causes possibles avant de passer à la suivante.

• Symptômes courants d'une boutique WooCommerce cassée
• Triage en moins de 10 minutes
• Diagnostic en 5 étapes
• Remédiation selon la cause identifiée
• Prévenir les prochaines pannes

Symptômes courants d'une boutique WooCommerce cassée

Chaque symptôme oriente vers une cause probable. Identifier le bon symptôme économise du temps de diagnostic et évite de modifier des fichiers au hasard.

• Erreur 500 (Internal Server Error) — le serveur a rencontré une erreur fatale non gérée. La page affiche un message générique ou reste blanche. C'est le symptôme le plus fréquent après une mise à jour PHP, un conflit entre plugins ou un dépassement de ressources serveur.
• Écran blanc de la mort (WSOD) — la page se charge mais reste entièrement vide. PHP échoue silencieusement : erreur de syntaxe dans un fichier de thème ou de plugin, dépassement de la limite mémoire, ou timeout d'exécution. L'absence de message d'erreur visible complique le diagnostic.
• Panier vide ou checkout bloqué — la boutique semble fonctionner, mais les commandes ne peuvent pas être finalisées. Les sessions PHP ou les cookies WooCommerce sont en cause, ou la passerelle de paiement retourne une erreur non affichée côté client.
• Administration inaccessible — /wp-admin redirige en boucle ou affiche une page blanche. Les mises à jour incomplètes du core WordPress et les conflits avec les plugins de cache ou de minification en sont souvent responsables.
• Pages produit ou catégorie en 404 — les URLs semblent valides mais WordPress ne les reconnaît plus. Une réinitialisation des règles de réécriture ou une corruption du fichier .htaccess est généralement en cause, parfois après une migration de serveur.

Les cinq symptômes les plus fréquents et leur orientation vers la cause probable.

Triage en moins de 10 minutes

Le triage a un seul objectif : décider entre deux chemins — restauration immédiate depuis une sauvegarde ou diagnostic à chaud pour ne pas perdre les commandes passées depuis la dernière sauvegarde.

Trois facteurs orientent la décision :

1. Ancienneté de la dernière sauvegarde valide. Si la sauvegarde date de moins de quelques heures, restaurer est le chemin le plus court pour reprendre le chiffre d'affaires. Si elle date de plus de 24 heures, des commandes risquent d'être perdues : le diagnostic à chaud devient préférable, quitte à documenter les erreurs rencontrées pour les traiter après remise en ligne.
2. Moment et intensité du trafic. Une panne à 3 h du matin sur un site à faible trafic tolère un diagnostic méthodique de 30 à 45 minutes. Une panne à 14 h un vendredi sur une boutique active justifie une restauration immédiate si la sauvegarde est récente.
3. Existence d'un staging. Si un environnement de préproduction existe avec les fichiers et la base de données synchronisés, vous pouvez y reproduire la panne et diagnostiquer sans toucher à la production.

Si une sauvegarde récente est disponible et que le trafic est élevé, passez directement à la section remédiation. Sinon, suivez le diagnostic pas à pas ci-dessous.

Diagnostic en 5 étapes

Étape 1 — Lire les logs PHP et WordPress

Les logs contiennent le message d'erreur exact, le fichier en cause et le numéro de ligne. Deux emplacements à vérifier en priorité : le fichier wp-content/debug.log (actif si WP_DEBUG_LOG est défini à true dans wp-config.php) et le journal d'erreurs PHP du serveur (emplacement variable selon l'hébergeur, souvent accessible depuis le panneau de contrôle).

Si le fichier debug.log est absent ou vide, activez temporairement le débogage en ajoutant ces lignes dans wp-config.php via SFTP :

define( 'WP_DEBUG', true );

define( 'WP_DEBUG_LOG', true );

define( 'WP_DEBUG_DISPLAY', false );

La constante WP_DEBUG_DISPLAY à false enregistre les erreurs dans le fichier log sans les exposer aux visiteurs. Consultez la documentation officielle WordPress sur le débogage pour la liste complète des constantes disponibles et les précautions à prendre en production.

Étape 2 — Identifier les modifications récentes

Un site qui fonctionnait hier et ne fonctionne plus aujourd'hui a subi une modification. Vérifiez dans l'ordre : l'historique des mises à jour dans Tableau de bord → Mises à jour, les dates de modification des fichiers via SFTP (triez par date décroissante dans wp-content/plugins/ et wp-content/themes/), puis les modifications côté serveur (changement de version PHP, rotation de certificat SSL, modification de la configuration Apache ou Nginx par l'hébergeur).

L'article Mises à jour WordPress sans risque : le process d'une agence explique comment mettre en place un suivi de chaque modification pour retrouver rapidement la cause d'une régression.

Étape 3 — Tester un conflit de plugin

Si les logs pointent vers un plugin spécifique, désactivez-le en renommant son dossier via SFTP. Si aucun plugin n'est clairement incriminé, renommez le dossier wp-content/plugins/ en wp-content/plugins_bak/ : WordPress désactive tous les plugins d'un coup. Si la boutique répond à nouveau, réactivez-les un par un pour isoler le coupable. Ne désactivez WooCommerce lui-même que si les logs pointent explicitement vers ses fichiers — cela supprime temporairement toutes les routes de la boutique.

Étape 4 — Tester un conflit de thème

Basculez vers un thème par défaut (Twenty Twenty-Four) via l'administration. Si l'administration est inaccessible, modifiez directement la base de données :

UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name IN ('template', 'stylesheet');

Si la boutique revient après ce changement, le thème actif est en cause — souvent un gabarit personnalisé dans le dossier woocommerce/ du thème enfant, incompatible avec la version WooCommerce installée.

Étape 5 — Vérifier la base de données et le .htaccess

Une base de données corrompue se manifeste par des erreurs du type Table './db/wp_options' is marked as crashed. Exécutez REPAIR TABLE via phpMyAdmin ou en ligne de commande MySQL. Si des pages produit sont en 404 après une modification, régénérez le .htaccess depuis Réglages → Permaliens : cliquez sur « Enregistrer les modifications » sans rien changer — WordPress recrée le fichier automatiquement.

Remédiation selon la cause identifiée

Plugin coupable — désactivation d'urgence

Une fois le plugin isolé, désactivez-le et vérifiez que la boutique répond. Notez la version installée et ouvrez un ticket auprès du développeur du plugin en joignant le message d'erreur extrait des logs. Ne réactivez le plugin qu'après une mise à jour corrective ou une confirmation de compatibilité avec la version de WooCommerce en production.

Thème en conflit — rollback du gabarit

Si le thème enfant contient des gabarits WooCommerce personnalisés (woocommerce/checkout/, woocommerce/cart/), supprimez-les temporairement et laissez WooCommerce utiliser ses propres gabarits. Une mise à jour WooCommerce change régulièrement la structure interne de ces fichiers — toujours vérifier le fichier de suivi des modifications (changelog) avant de surcharger un gabarit. L'article Mise à jour WooCommerce qui casse le checkout : ce qui se passe, étape par étape détaille cette séquence avec précision.

Restauration depuis une sauvegarde

La restauration est le chemin le plus sûr quand la cause reste non identifiée après 20 minutes d'investigation et que la boutique génère du chiffre d'affaires. Avant de restaurer, exportez les commandes récentes (depuis la table wp_wc_orders si HPOS est activé, ou wp_posts en stockage classique) pour ne pas perdre les données de la fenêtre non couverte par la sauvegarde.

Si vos sauvegardes sont gérées par Sentinelo, la restauration est déclenchée sur demande à partir de n'importe quelle archive dans la fenêtre de rétention (7 quotidiennes, 4 hebdomadaires, 12 mensuelles sur 24 mois). Pour comprendre ce qu'il faut avoir en place avant la panne, lisez notre guide sur la sauvegarde WooCommerce avant une mise à jour.

Prévenir les prochaines pannes WooCommerce

Un incident WooCommerce se prévient à trois niveaux. Aucun ne remplace les deux autres.

Sauvegardes quotidiennes chiffrées et vérifiées

Une sauvegarde n'a de valeur que si elle est testée régulièrement et disponible au moment exact de la panne. Les sauvegardes Sentinelo sont nocturnes, chiffrées avant transfert avec une clé propre à chaque site, et vérifiées post-stockage par empreinte SHA-256. Cela garantit qu'une archive corrompue est détectée immédiatement — pas au moment où vous en avez besoin pour une restauration d'urgence.

Supervision HTTP avec double confirmation de panne

Sentinelo sonde chaque site toutes les 5 minutes par défaut, configurable entre 1 et 60 minutes selon la criticité du site. Deux sondes consécutives en échec sont nécessaires avant de déclencher une alerte, ce qui élimine les faux positifs liés aux micro-coupures réseau. L'alerte part sur e-mail, Slack, Teams, Discord ou webhook — avant que le client ne constate lui-même la panne. L'article Alertes panne site client : détecter avant que le client appelle explique comment structurer ces alertes dans un parc multi-sites.

Tests en staging avant chaque mise à jour majeure

Appliquer une mise à jour WooCommerce directement en production sans staging, c'est découvrir les incompatibilités avec les clients en session d'achat. Un environnement de préproduction avec une copie récente de la base de données permet de tester les gabarits personnalisés, les passerelles de paiement et les interactions entre plugins dans leurs conditions réelles. Sentinelo intègre un rollback automatique du composant si le site cesse de répondre après une mise à jour automatisée, mais cela ne remplace pas un test fonctionnel complet du tunnel de commande. Le guide scanner un site web : guide complet sécurité et performance couvre les audits de santé à planifier régulièrement avant d'intervenir.

Pour les agences qui maintiennent un parc de boutiques WooCommerce, ces trois niveaux de protection — sauvegarde vérifiable, supervision proactive et processus de mise à jour contrôlé — constituent le filet de sécurité entre une panne technique et un incident commercial. Sentinelo couvre ces trois dimensions dans une interface unique, avec la même tarification par site quelle que soit la technologie de la boutique.