Problème plugin WordPress : l’étude de cas d’un back-office devenu presque inutilisable

⏱ Temps de lecture estimé 09 min. 

Introduction

Pendant plusieurs mois, Laure a cru que son site WordPress était simplement… capricieux.

Une page qui met longtemps à s’ouvrir. Une sauvegarde qui tourne dans le vide. Une modification qui fonctionne une fois sur deux. Puis des erreurs serveur qui apparaissent sans prévenir.

Au début, ce n’était qu’un contretemps.

Puis c’est devenu son quotidien.

Le plus frustrant ? Son site avait été créé par une professionnelle plusieurs années auparavant, mais celle-ci avait arrêté son activité. Depuis, Laure faisait vivre son site seule. Elle n’était pas débutante, connaissait déjà le vocabulaire de WordPress et, plus récemment, s’aidait même de l’intelligence artificielle pour résoudre ses problèmes.

Malgré tout, les lenteurs continuaient de s’accumuler.

Jusqu’au jour où une restauration complète du site est devenue nécessaire.

À quelques semaines de la réouverture de sa boutique en ligne prévue en septembre, l’inquiétude était bien réelle. Son site public fonctionnait encore, mais le back-office devenait presque impossible à utiliser. Modifier une fiche produit ou une page pouvait prendre plusieurs minutes… quand cela fonctionnait.

C’est à ce moment-là que Laure m’a contactée.

Et ce que nous avons découvert montre une réalité que je rencontre souvent : lorsqu’un site WordPress devient très lent, il n’existe presque jamais une seule cause.

Sommaire

1. Le contexte de la mission
2. Pourquoi le problème était difficile à identifier
3. Le diagnostic : plusieurs causes qui se cumulaient
4. Les corrections réalisées
5. Les optimisations réalisées en complément
6. Les résultats obtenus
7. Ce que cette intervention nous apprend
8. En résumé

1. Le contexte de la mission

Laure est la fondatrice de 7Flammes, une jeune marque de beauté émotionnelle inspirée du monde des abeilles.

Depuis une miellerie bretonne, elle développe une gamme de soins formulés autour des trésors de la ruche, avec une approche très personnelle de la beauté.

Son site WordPress constitue le cœur de cette activité : présentation de la marque, boutique WooCommerce, gestion des produits, des commandes et de toute la partie administrative.

Lorsque Laure me contacte, la boutique est temporairement fermée.

Cette fermeture est finalement une chance.

Les clientes ne rencontrent aucune difficulté puisque le site public reste accessible, mais le back-office, lui, devient de plus en plus difficile à utiliser. Et avec une réouverture prévue quelques semaines plus tard, impossible de préparer sereinement les nouveaux produits dans ces conditions.

2. Pourquoi le problème était difficile à identifier

Ce type de mission est souvent plus complexe qu’il n’y paraît.

Contrairement à un site qui affiche une erreur critique du jour au lendemain, ici le problème s’est installé progressivement.

Pendant plusieurs mois :

• certaines pages mettaient de plus en plus de temps à charger ;
• Avada Builder restait parfois bloqué lors des sauvegardes ;
• des erreurs serveur apparaissaient de façon aléatoire ;
• certaines modifications demandaient plusieurs tentatives avant d’être enregistrées.

Rien ne semblait totalement cassé.

Mais tout devenait lent.

C’est justement ce qui rend ce genre de panne particulièrement difficile à diagnostiquer.

Lorsqu’un site ralentit progressivement, il est rare qu’un seul plugin soit responsable. Plusieurs petits dysfonctionnements peuvent s’accumuler sans être visibles individuellement, jusqu’au moment où le back-office devient presque inutilisable. Ce scénario correspondait parfaitement à ce que vivait Laure.

3. Le diagnostic : plusieurs causes qui se cumulaient

La première étape n’a pas consisté à modifier le site.

Elle a consisté à comprendre.

J’ai commencé par reproduire les dysfonctionnements directement dans Avada Builder afin d’observer précisément ce qui se passait lors des sauvegardes. L’environnement technique a ensuite été vérifié : versions de WordPress, d’Avada, des extensions, mémoire serveur disponible et paramètres principaux.

L’analyse des journaux Wordfence a rapidement mis en évidence un premier problème : certaines requêtes parfaitement légitimes envoyées par Avada Builder étaient bloquées par le pare-feu.

Autrement dit, Wordfence interprétait des actions normales comme potentiellement dangereuses.

À chaque sauvegarde, Avada attendait une réponse qui n’arrivait jamais.

Le chargement restait bloqué.

Mais ce conflit n’expliquait pas à lui seul toutes les lenteurs observées.

En poursuivant le diagnostic, plusieurs autres facteurs sont apparus :

• une base de données devenue très lourde ;
• deux plugins de sécurité remplissant le même rôle ;
• un système de cache qui faisait doublon ;
• des sauvegardes automatiques inexistantes ;
• plusieurs éléments de configuration qui, pris séparément, semblaient anodins mais qui, ensemble, dégradaient progressivement les performances.

C’est précisément pour cette raison que j’aime parler de diagnostic plutôt que de dépannage.

Corriger uniquement le conflit Wordfence aurait résolu une partie du problème, mais pas l’ensemble.

4. Les corrections réalisées

Une fois les différentes causes identifiées, chaque intervention a été réalisée méthodiquement.

La priorité était évidemment de rendre Avada Builder pleinement fonctionnel.

Pour cela, le pare-feu Wordfence a été placé temporairement en mode apprentissage afin qu’il reconnaisse les requêtes légitimes envoyées par Avada Builder, avant d’être remis en mode protection. Les tests ont confirmé que les sauvegardes fonctionnaient de nouveau normalement.

Cette première correction a ensuite été complétée par plusieurs interventions :

• configuration de sauvegardes automatiques avec UpdraftPlus ;
• suppression du doublon entre Really Simple Security et Wordfence ;
• suppression de Query Monitor une fois le diagnostic terminé ;
• suppression de W3 Total Cache qui faisait doublon avec le cache intégré d’Avada ;
• optimisation générale de la configuration de sécurité ;
• vérification complète des scans Wordfence, sans détection de fichier malveillant.

L’objectif n’était pas simplement de résoudre le problème du jour.

Il était aussi d’éviter qu’il revienne quelques semaines plus tard.

5. Les optimisations réalisées en complément

Une fois le site stabilisé, plusieurs optimisations supplémentaires ont été réalisées.

La plus importante concernait la base de données.

Les données chargées automatiquement à chaque ouverture de page sont passées d’environ 8 Mo à seulement 280 Ko, soit une réduction de 96 % de la charge automatique.

D’autres points ont également été corrigés lors du suivi :

• réactivation de WP Mail SMTP ;
• reconnexion du compte Gmail ;
• vérification de Stripe et PayPal ;
• rétablissement de la connexion Sendcloud ;
• recommandations concernant l’utilisation de Google Chrome plutôt que Microsoft Edge pour l’administration du site.

Enfin, quelques recommandations ont été laissées pour continuer d’améliorer les performances après la réouverture de la boutique, notamment le nettoyage des anciennes tâches WooCommerce et une future mise à jour d’Avada.

6. Les résultats obtenus

À la fin de l’intervention :

✅ les sauvegardes Avada fonctionnaient de nouveau ;

✅ le chargement infini avait disparu ;

✅ les sauvegardes automatiques étaient configurées ;

✅ Wordfence protégeait toujours le site ;

✅ les principales sources de ralentissement avaient été supprimées.

Le plus important reste pourtant ailleurs.

Laure peut désormais préparer sereinement la réouverture de sa boutique sans avoir l’impression de lutter contre son propre outil de travail.

7. Ce que cette intervention m’a confirmé

Cette mission illustre parfaitement une idée reçue que j’entends souvent :

« Mon site est lent, c’est sûrement un plugin. »

Parfois, oui.

Mais bien souvent, le plugin n’est que la partie visible de l’iceberg.

Les vraies causes se cachent dans l’accumulation de petites configurations imparfaites qui, au fil des années, finissent par ralentir tout l’écosystème WordPress.

C’est aussi pour cette raison qu’un diagnostic vaut presque toujours mieux qu’une succession d’essais au hasard.

8. En résumé

Le problème de Laure n’était pas un simple plugin défectueux.

C’était l’accumulation de plusieurs facteurs techniques qui rendaient progressivement son back-office presque inutilisable.

Grâce à un diagnostic complet, il a été possible de :

• identifier le conflit principal entre Wordfence et Avada ;
• supprimer plusieurs sources de ralentissement ;
• optimiser la base de données ;
• sécuriser les sauvegardes ;
• remettre en état les services essentiels comme les emails, Stripe, PayPal et Sendcloud.

Parce qu’un site WordPress ne se résume pas à ses plugins.

C’est un écosystème complet. Et parfois, ce sont les petits détails invisibles qui font toute la différence entre un site qui fonctionne… et un site qui devient un frein au développement de ton activité.