Site WooCommerce cassé : identifiez la cause avant de restaurer

Lorsqu’une boutique ne charge plus, qu’un écran blanc apparaît ou que le bouton de paiement ne répond plus, commencez par préserver les commandes et par identifier ce qui a changé. Ne réinstallez pas WooCommerce et ne restaurez pas une sauvegarde sans diagnostic : la panne peut venir d’une extension, du thème, du cache, de PHP ou d’une mise à jour interrompue. En isolant les causes successivement, vous pouvez souvent remettre la vente en ligne sans effacer les données récentes.

Commencer par situer la panne et protéger les ventes

Un site WooCommerce cassé n’est pas forcément totalement inaccessible. La boutique peut afficher les produits tout en perdant le panier, bloquer uniquement le checkout ou cesser d’envoyer les emails de confirmation. Cette distinction évite une restauration complète pour un problème limité à une seule fonction.

Geler les manipulations avant qu’elles se multiplient

Notez l’heure du problème, les mises à jour effectuées, le message d’erreur exact et les actions réalisées juste avant la panne. Vérifiez aussi si des commandes ont été passées entre-temps dans le compte du prestataire de paiement. Cette précaution compte avant une restauration : revenir à l’état des fichiers et de la base de données enregistré dans une sauvegarde peut faire disparaître des commandes créées depuis cette date.

Imaginez la boutique comme un flux continu : les visiteurs et les commandes continuent d’arriver pendant que vous cherchez la cause. Une correction ciblée préserve ce flux. Une restauration globale peut créer un décalage entre les paiements encaissés, les stocks et les commandes enregistrées. Avant tout rollback, comparez la date de sauvegarde avec les transactions récentes et prévoyez de réconcilier les écarts.

Lire les indices techniques avant de désactiver quoi que ce soit

Une mise à jour n’est pas forcément la cause directe de la panne. Elle peut révéler une incompatibilité ancienne entre WordPress, WooCommerce, le thème et une extension. Les plugins de paiement, de cache, de sécurité, de livraison et de taxes demandent une attention particulière, car ils interviennent dans le tunnel d’achat.

Activer temporairement le debug WordPress

Si vous avez accès aux fichiers, ouvrez wp-config.php et activez WP_DEBUG ainsi que WP_DEBUG_LOG. L’objectif est d’écrire les erreurs dans wp-content/debug.log sans les afficher aux clients. WP_DEBUG_DISPLAY doit donc rester désactivé en production. Recherchez le nom d’un plugin, d’un fichier de thème ou une erreur PHP fatale : cet indice aide souvent à isoler le conflit.

Dans l’administration WordPress, consultez aussi WooCommerce > État > Journaux. Sélectionnez les journaux correspondant au moment de la panne, en particulier ceux du moyen de paiement concerné. Une erreur de webhook, de signature API ou de connexion au prestataire ne se corrige pas en réinstallant WooCommerce. Il faut vérifier les réglages et les clés du module de paiement.

Distinguer cache, thème et incompatibilité PHP

Un panier qui se vide pointe souvent vers le cache, les cookies ou les sessions. Videz les caches de WordPress, de l’hébergeur et du CDN, puis assurez-vous que les pages panier, checkout et mon compte sont exclues du cache. Si le checkout s’affiche mais ne réagit pas, ouvrez la console JavaScript du navigateur. Une erreur provenant du thème, d’un optimiseur de scripts ou d’un bloc de paiement peut bloquer le bouton de commande.

Vérifiez aussi la version PHP dans le panneau d’hébergement et la compatibilité annoncée par les extensions installées. PHP 7.4 peut empêcher certaines évolutions, tandis qu’un passage vers PHP 8 ou plus peut casser un plugin ancien. Ne changez pas de version PHP au hasard sur une boutique active : sauvegardez les fichiers et la base, puis testez la version visée sur un environnement de staging lorsque cela est possible.

Isoler le conflit sans accès au back-office

La méthode la plus sûre consiste à ne modifier qu’une variable à la fois. Si l’accès au tableau de bord fonctionne, désactivez d’abord les extensions non indispensables, puis testez une page produit, le panier et le checkout. Réactivez-les une par une jusqu’au retour de la panne. La dernière extension activée est alors probablement impliquée, sans que cela dispense de vérifier les journaux.

Utiliser FTP ou le gestionnaire de fichiers

En cas d’écran blanc ou de back-office inaccessible, connectez-vous en FTP, dans cPanel, Plesk ou le gestionnaire de fichiers de l’hébergeur. Dans wp-content/plugins, renommez le dossier de l’extension récemment mise à jour, par exemple en ajoutant -off. WordPress la désactivera automatiquement. Si vous ignorez laquelle est responsable, renommez temporairement le dossier plugins, puis remettez-le en place et désactivez les extensions individuellement.

Ne supprimez pas un plugin avant d’avoir relevé ses réglages et ses données éventuelles. Une désactivation reste réversible. Une suppression peut compliquer la remise en service, notamment pour un plugin de paiement ou de livraison. Conservez aussi une copie des fichiers avant toute modification effectuée depuis le gestionnaire de fichiers.

Écarter le thème du diagnostic

Si les extensions ne sont pas en cause, basculez provisoirement vers un thème WordPress par défaut tel que Twenty Twenty-Four ou Twenty Twenty-Five. Si le tunnel d’achat redevient fonctionnel, vérifiez les surcharges WooCommerce du thème enfant, les templates personnalisés et les scripts ajoutés au checkout. Un thème peut afficher correctement les fiches produit tout en utilisant un code obsolète sur le panier ou les blocs de commande.

Choisir entre correction ciblée, réinstallation et restauration

La correction ciblée est préférable lorsqu’un plugin, un réglage PHP ou le cache a été identifié. Mettez alors à jour l’extension compatible, remplacez-la si elle n’est plus maintenue ou revenez temporairement à sa version précédente. Après chaque action, testez le parcours réel d’un client au lieu de vous fier au seul affichage de la page.

Réinstaller WooCommerce peut être pertinent si ses fichiers sont incomplets après une mise à jour interrompue ou si le plugin a disparu de la liste des extensions. Les produits et les commandes sont normalement conservés dans la base de données : ils ne dépendent pas uniquement du dossier du plugin. Toutefois, une réinstallation ne supprimera pas le conflit d’un thème, d’une extension de paiement ou d’une configuration serveur. Sauvegardez les fichiers et la base de données avant toute intervention.

La restauration complète depuis une sauvegarde de l’hébergeur, d’UpdraftPlus, BackWPup ou Jetpack devient pertinente si plusieurs composants ont été modifiés, si des fichiers sont corrompus ou si le site reste indisponible après l’isolement des extensions. Restaurez ensemble les fichiers et la base correspondant au même point de sauvegarde. Contrôlez ensuite les commandes, les paiements, les stocks et les comptes créés après cette date.

Valider la remise en ligne et éviter la prochaine panne

Une boutique n’est pas réparée parce que la page d’accueil s’ouvre. Vérifiez au minimum les pages produit, l’ajout au panier, la conservation du panier après actualisation, le calcul de la livraison et des taxes, le checkout, le paiement en mode test, l’email de confirmation, le décrément du stock et le statut de commande. Contrôlez aussi les journaux après le test : une erreur silencieuse peut réapparaître au prochain achat.

• Conservez une sauvegarde testée des fichiers et de la base de données.
• Effectuez les mises à jour sur un staging avant la production.
• Mettez à jour WordPress, WooCommerce, le thème et les extensions séparément.
• Attendez et testez le tunnel d’achat avant de passer au composant suivant.
• Évitez les modifications directes dans les fichiers d’un plugin ou du thème parent.

Faites appel à un spécialiste WooCommerce lorsque des paiements ont été encaissés sans commandes, que la base de données doit être manipulée, que l’erreur PHP reste obscure ou qu’une panne bloque les ventes pendant une période commerciale sensible. Une intervention experte doit préserver les données, identifier la cause racine et vérifier le tunnel d’achat, plutôt que se limiter à faire réapparaître le site.