Les 20 bugs WordPress les plus courants : diagnostic et solutions

Écran blanc, erreur 500, site qui rame, page de connexion en boucle… Quand votre site WordPress tombe en panne, chaque minute compte.

En 12 ans d’interventions sur des sites WordPress de toutes tailles, notre équipe a diagnostiqué et résolu des milliers de bugs — des plus classiques aux plus retors. Comme un bon médecin, on commence toujours par un diagnostic précis avant de prescrire le bon traitement.

Dans ce guide, nous passons en revue les 20 bugs WordPress les plus courants, classés en 6 grandes « pathologies ». Pour chaque bug : les symptômes, les causes probables, et la solution concrète testée en conditions réelles. Pas de théorie vague — du diagnostic actionnable.

Vous préférez qu’un expert s’en charge ? Notre équipe de dépannage WordPress intervient sous 24h.

• Identifier rapidement les 20 bugs WordPress les plus courants et leurs causes
• Appliquer les bons réflexes de diagnostic avant toute manipulation
• Résoudre soi-même les pannes simples grâce à des protocoles testés
• Savoir quand faire appel à un expert pour éviter d’aggraver la situation

1. Faites une sauvegarde avant toute manipulation

Avant de toucher à quoi que ce soit, sauvegardez. C’est la règle numéro un de tout dépannage WordPress — et en 12 ans, on a vu trop de situations empirer parce que cette étape a été sautée.

Si vous avez accès au tableau de bord, utilisez votre plugin de sauvegarde habituel (UpdraftPlus, BackWPup, etc.). Si le site est inaccessible, connectez-vous en FTP/SFTP et faites une copie du dossier wp-content/ ainsi qu’un export de la base de données via phpMyAdmin ou en ligne de commande :

# Export rapide de la base de données via WP-CLI
wp db export sauvegarde-avant-debug.sql

# Si WP-CLI n'est pas dispo, via mysqldump
mysqldump -u UTILISATEUR -p NOM_BASE > sauvegarde-avant-debug.sql

Une sauvegarde prend 5 minutes. Réparer un site sans sauvegarde après une mauvaise manipulation peut prendre des heures.

2. Activez WP_DEBUG pour des messages d’erreur explicites

Par défaut, WordPress masque les erreurs PHP pour ne pas les afficher aux visiteurs. C’est bien en production, mais ça rend le diagnostic aveugle. Activer le mode debug vous donne les messages d’erreur complets — souvent, ils pointent directement vers le plugin ou le fichier responsable.
Ajoutez ces lignes dans votre fichier wp-config.php, juste avant la ligne /* That's all, stop editing! */ :

// Activer le mode debug WordPress
define( 'WP_DEBUG', true );

// Écrire les erreurs dans un fichier log plutôt que les afficher aux visiteurs
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Les erreurs seront enregistrées dans wp-content/debug.log. Consultez ce fichier après avoir reproduit le bug — vous y trouverez le nom du fichier fautif, le numéro de ligne, et souvent le nom du plugin ou du thème en cause.

⚠️ Important : pensez à désactiver WP_DEBUG une fois le problème résolu. Laisser le debug actif en production peut exposer des informations sensibles et ralentir le site.

3. Éliminez les faux positifs côté navigateur

Avant de toucher au serveur ou au code, vérifiez que le problème ne vient pas de votre côté :

• Videz le cache de votre navigateur (Ctrl+Shift+Suppr) — un CSS ou JS en cache peut masquer une correction déjà en place, ou simuler un bug qui n’existe plus.
• Testez en navigation privée — ça élimine les extensions de navigateur, les cookies et le cache d’un coup.
• Testez sur un autre appareil ou un autre réseau — certains problèmes sont liés au DNS local, au proxy d’entreprise, ou à un blocage FAI.

Si le bug disparaît en navigation privée, le problème est côté navigateur ou cache, pas côté WordPress. Si vous utilisez un plugin de cache WordPress (WP Super Cache, W3 Total Cache, WP Rocket…), purgez-le aussi avant de creuser plus loin.

---

Erreur 403 Forbidden

L’erreur 403 indique que le serveur refuse l’accès à la ressource demandée. Sur WordPress, elle touche soit une page spécifique, soit l’ensemble du site — et les causes sont très différentes selon le cas.

Causes les plus fréquentes :

• Permissions de fichiers incorrectes. WordPress attend des permissions précises : 755 pour les dossiers, 644 pour les fichiers. Des permissions trop restrictives (comme 000 ou 600) provoquent un 403 immédiat.
• Fichier .htaccess corrompu. Un plugin qui réécrit les règles .htaccess peut injecter une directive qui bloque l’accès. C’est la cause n°1 des 403 soudains après une mise à jour de plugin.
• Plugin de sécurité trop agressif. Wordfence, iThemes Security ou Sucuri peuvent bloquer votre propre IP s’ils détectent un comportement suspect (trop de tentatives de connexion, par exemple).

Solutions :

# Vérifier et corriger les permissions via SSH
# 755 pour tous les dossiers
find /chemin/vers/wordpress/ -type d -exec chmod 755 {} ;
# 644 pour tous les fichiers
find /chemin/vers/wordpress/ -type f -exec chmod 644 {} ;

Si le problème vient du .htaccess, renommez-le temporairement pour tester :

# Renommer le .htaccess pour tester sans
mv .htaccess .htaccess.backup

Si le site revient, régénérez un .htaccess propre depuis Réglages > Permaliens dans l’administration WordPress (il suffit de cliquer sur « Enregistrer les modifications » sans rien changer).

Si un plugin de sécurité vous a bloqué, connectez-vous en FTP et renommez le dossier du plugin dans wp-content/plugins/ pour le désactiver.

Erreur 404 sur les permaliens WordPress

Votre page d’accueil fonctionne, mais toutes les autres pages renvoient une erreur 404 ? C’est un grand classique — et la solution est généralement simple.

Cause principale : les règles de réécriture d’URL sont cassées. WordPress utilise le fichier .htaccess (Apache) ou la configuration nginx pour transformer les URLs propres (/mon-article/) en requêtes PHP. Quand ces règles disparaissent ou sont corrompues, le serveur ne sait plus router les URLs et renvoie un 404.

Ça arrive souvent après :

• Une migration de serveur ou un changement d’hébergeur
• Une mise à jour de WordPress ou d’un plugin qui réécrit le .htaccess
• Un changement de structure de permaliens

Solution rapide :

Allez dans Réglages > Permaliens et cliquez sur « Enregistrer les modifications » sans rien modifier. WordPress régénère automatiquement les règles de réécriture.

Si ça ne suffit pas, vérifiez que le module mod_rewrite est activé sur votre serveur Apache :

# Vérifier si mod_rewrite est actif
apache2ctl -M | grep rewrite

# Si absent, l'activer (Debian/Ubuntu)
sudo a2enmod rewrite
sudo systemctl restart apache2

Sur nginx (ce qui est le cas de beaucoup d’hébergeurs modernes, y compris certaines configurations O2Switch), les permaliens nécessitent un bloc try_files dans la configuration du vhost :

location / {
    try_files $uri $uri/ /index.php?$args;
}

Si vous n’avez pas accès à la config serveur, contactez votre hébergeur — c’est une modification de 2 minutes pour eux.

Erreur Mixed Content (HTTP/HTTPS)

Après une migration vers HTTPS, votre navigateur affiche un cadenas cassé ou barré, certaines images ne se chargent plus, ou des scripts ne fonctionnent pas ? Vous avez un problème de Mixed Content : le site est en HTTPS mais certaines ressources (images, CSS, JavaScript) sont encore appelées en HTTP.

Comment diagnostiquer :

Ouvrez la console de votre navigateur (F12 > Console). Les erreurs Mixed Content apparaissent en jaune (warning) ou en rouge (bloqué) avec l’URL exacte de la ressource fautive.

Causes courantes :

• URLs en dur dans le contenu (articles, pages) qui pointent encore vers http://
• Thème ou plugin qui injecte des ressources en HTTP
• URL du site mal configurée dans Réglages > Général

Solution — remplacement en base de données :

La méthode la plus fiable est un search-replace en base de données avec WP-CLI :

# Remplacer toutes les occurrences http par https
# --dry-run d'abord pour vérifier ce qui sera modifié
wp search-replace 'http://www.wpclinique.com' 'https://www.wpclinique.com' --dry-run

# Si le résultat est cohérent, exécuter pour de vrai
wp search-replace 'http://www.wpclinique.com' 'https://www.wpclinique.com'

⚠️ Important : adaptez le domaine à votre propre site. Vérifiez aussi les variantes sans www si applicable. Et comme toujours — sauvegardez la base avant de lancer un search-replace.

Si des ressources externes (polices Google Fonts, CDN tiers) sont appelées en HTTP, mettez à jour les URLs directement dans le code du thème ou du plugin concerné. La plupart des services externes supportent HTTPS depuis des années — il suffit souvent de changer http:// en https:// ou d’utiliser // (protocol-relative URL).

---

La lenteur d’un site WordPress est comparable à une maladie chronique qui s’installe insidieusement. Au début, les symptômes semblent bénins : quelques secondes de chargement supplémentaires, une légère latence dans l’administration. Mais les conséquences sont bien réelles : les visiteurs impatients quittent votre site, Google rétrograde votre positionnement, et vos conversions chutent — un cercle vicieux qui s’aggrave si on n’identifie pas la cause.

Derrière un site lent, il y a toujours une cause précise. Voici les trois que nous rencontrons le plus souvent en intervention.

Erreur « Allowed Memory Size Exhausted »

Fatal error: Allowed memory size of 67108864 bytes exhausted

Ce message signifie que PHP a atteint la limite de mémoire autorisée pour exécuter un script. Sur WordPress, ça arrive fréquemment avec des plugins gourmands (builders type Elementor ou Divi, WooCommerce avec beaucoup de produits) ou lors d’imports de contenu volumineux.

Le chiffre dans le message vous donne l’indice : 67108864 bytes = 64 Mo, 134217728 = 128 Mo. Si vous voyez 64 Mo, c’est souvent la valeur par défaut du serveur, bien trop basse pour un WordPress moderne.

Solution — augmenter la limite mémoire PHP :

// Dans wp-config.php, avant la ligne "That's all, stop editing!"
define( 'WP_MEMORY_LIMIT', '256M' );

// Pour l'administration (qui consomme souvent plus)
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Si ça ne suffit pas, la limite est peut-être verrouillée côté serveur. Vous pouvez tenter via le php.ini ou .user.ini à la racine du site :

; Dans .user.ini (hébergement mutualisé type O2Switch)
memory_limit = 256M

⚠️ Attention : augmenter la mémoire n’est pas un vrai correctif, c’est un pansement. Si un plugin consomme 256 Mo de RAM pour afficher une page, c’est le plugin le problème. Activez WP_DEBUG_LOG (cf. section réflexes essentiels) pour identifier quel plugin ou quelle fonction explose la mémoire, et envisagez de le remplacer par une alternative plus légère.

Erreur « Maximum Execution Time Exceeded »

PHP impose un temps maximum d’exécution par script (30 secondes par défaut). Quand un script WordPress dépasse cette limite, PHP le tue. C’est courant pendant les mises à jour de plugins, les imports WooCommerce, ou les régénérations de miniatures d’images.

À ne pas confondre avec un site lent au quotidien — cette erreur apparaît sur des opérations ponctuelles lourdes, pas sur le chargement normal des pages.

Solution :

// Dans wp-config.php
set_time_limit( 300 ); // 300 secondes = 5 minutes

Ou via .user.ini :

; Dans .user.ini
max_execution_time = 300

Cas spécifique des mises à jour qui timeout : si une mise à jour de plugin ou de WordPress échoue à cause du timeout, ne relancez pas la mise à jour immédiatement. Vérifiez d’abord que le site n’est pas resté bloqué en mode maintenance (voir la section « Conflits d’extensions » plus bas). Augmentez le timeout, puis relancez la mise à jour.

Solution pérenne : pour les opérations lourdes récurrentes (imports, exports, régénération d’images), privilégiez WP-CLI qui n’a pas de limite de temps d’exécution par défaut :

# Régénérer toutes les miniatures via WP-CLI (sans limite de temps)
wp media regenerate --yes

# Mettre à jour tous les plugins via WP-CLI
wp plugin update --all

Site WordPress anormalement lent — diagnostic en 5 points

Un site lent n’est pas un bug unique, c’est un symptôme avec des dizaines de causes possibles. Plutôt que de deviner, voici une méthode de diagnostic structurée qui permet d’isoler le coupable en quelques minutes.

Point 1 — Mesurez d’abord, optimisez ensuite. Testez votre site sur PageSpeed Insights et GTmetrix. Notez le TTFB (Time To First Byte) : s’il est supérieur à 800 ms, le problème est côté serveur. S’il est correct mais que la page met du temps à s’afficher, le problème est côté front-end (CSS, JS, images).

Point 2 — Testez sans plugins. Désactivez tous les plugins et vérifiez si la vitesse s’améliore. Si oui, réactivez-les un par un pour identifier le coupable. Via WP-CLI c’est rapide :

# Désactiver tous les plugins d'un coup
wp plugin deactivate --all

# Les réactiver un par un pour tester
wp plugin activate mon-plugin

Point 3 — Vérifiez le thème. Basculez temporairement sur un thème par défaut (Twenty Twenty-Five) pour voir si le problème vient du thème :

wp theme activate twentytwentyfive

Point 4 — Examinez la base de données. Une base surchargée ralentit tout. Les tables wp_options (avec des autoload inutiles) et les tables de révisions sont souvent en cause :

# Vérifier la taille de la table wp_options
wp db query "SELECT COUNT(*) as total, SUM(LENGTH(option_value)) as taille_totale FROM wp_options WHERE autoload = 'yes';"

# Supprimer les révisions anciennes (garde les 5 dernières par article)
wp post delete $(wp post list --post_type='revision' --format=ids) --force

# Optimiser les tables
wp db optimize

Point 5 — Vérifiez l’hébergement. Si le TTFB est élevé même sur une page simple avec tous les plugins désactivés et un thème par défaut, le serveur est le goulot. Sur un mutualisé O2Switch, les performances varient selon la charge du serveur partagé. Envisagez de passer en VPS ou hébergement WordPress managé si le site génère un trafic significatif.

En résumé : TTFB élevé → problème serveur/BDD. TTFB ok mais chargement lent → problème front-end (images non optimisées, trop de JS/CSS, pas de cache). Cette distinction vous fait gagner des heures de diagnostic.

---

Se retrouver bloqué à la porte de son propre site WordPress est particulièrement frustrant — comme découvrir que la serrure de votre maison a été changée pendant la nuit. Les causes vont du simple cookie corrompu au problème de base de données, mais dans tous les cas, la priorité est de récupérer l’accès sans aggraver la situation. Voici les trois blocages que nous rencontrons le plus en intervention.

Boucle de redirection sur wp-login.php

Vous tentez d’accéder à /wp-admin/ ou /wp-login.php et le navigateur affiche « Cette page est redirigée trop de fois » (ERR_TOO_MANY_REDIRECTS) ? Vous êtes piégé dans une boucle de redirection — le serveur vous renvoie indéfiniment entre deux URLs sans jamais charger la page.

Causes les plus fréquentes :

• URLs mal configurées en base de données. Les options siteurl et home dans wp_options ne correspondent pas (ex : l’une en www, l’autre sans, ou un mélange HTTP/HTTPS).
• Plugin de cache ou de sécurité qui force une redirection en conflit avec une autre règle.
• .htaccess avec des règles de redirection contradictoires (typique après une migration ou un changement de certificat SSL).

Solution — vérifier les URLs en base :

# Vérifier les URLs configurées
wp option get siteurl
wp option get home

# Si elles ne correspondent pas, les corriger
wp option update siteurl 'https://www.votresite.com'
wp option update home 'https://www.votresite.com'

Si vous n’avez pas accès à WP-CLI (puisque le back-office est inaccessible), vous pouvez forcer les URLs dans wp-config.php :

// Forcer les URLs dans wp-config.php (solution temporaire de déblocage)
define( 'WP_SITEURL', 'https://www.votresite.com' );
define( 'WP_HOME', 'https://www.votresite.com' );

Si ça persiste : videz les cookies de votre navigateur pour le domaine concerné, purgez le cache WordPress (via FTP en supprimant le contenu du dossier cache si nécessaire), et renommez le .htaccess pour tester sans règles de réécriture.

Erreur « Cookies are blocked or not supported »

Ce message apparaît sur la page de connexion WordPress : vous entrez vos identifiants, la page se recharge, et vous retombez sur le formulaire avec ce message. Vos identifiants sont corrects — c’est la gestion des cookies qui bloque.

Causes principales :

• Constante COOKIE_DOMAIN mal configurée dans wp-config.php, souvent suite à une migration de domaine ou un passage de www à non-www.
• Plugin de cache qui sert une version en cache de la page de connexion (le cookie de session n’est jamais posé).
• Conflit avec un CDN ou un reverse proxy (Cloudflare, Varnish) qui strip les cookies sur certaines URLs.

Solution — vérifier la configuration cookies :

Cherchez dans wp-config.php si une constante COOKIE_DOMAIN est définie :

// Si cette ligne existe et que le domaine est incorrect, corrigez-la
define( 'COOKIE_DOMAIN', 'www.votresite.com' );

// Ou supprimez-la pour laisser WordPress gérer automatiquement
// define( 'COOKIE_DOMAIN', '' );

Si le problème vient du cache : ajoutez /wp-login.php et /wp-admin/ aux exclusions de votre plugin de cache. Sur WP Super Cache ou W3 Total Cache, c’est dans les réglages avancés. Sur un CDN type Cloudflare, créez une règle de page (Page Rule) qui désactive le cache sur /wp-admin/* et /wp-login.php.

Test rapide : essayez de vous connecter en navigation privée. Si ça fonctionne, le problème vient des cookies ou du cache de votre navigateur, pas de WordPress.

Perte du rôle administrateur

Vous pouvez vous connecter à WordPress, mais l’interface est vide : plus de menus, plus d’accès aux réglages, comme si votre compte avait été rétrogradé en simple abonné. Votre rôle administrateur a été modifié en base de données — volontairement (piratage) ou accidentellement (plugin de gestion de rôles mal configuré, import de base de données partiel).

Diagnostic — vérifier votre rôle actuel :

# Lister les utilisateurs et leurs rôles
wp user list --fields=ID,user_login,roles

Si votre compte apparaît avec un rôle autre que administrator, c’est confirmé.

Solution — restaurer le rôle via WP-CLI :

# Restaurer le rôle administrateur (remplacez votre_login)
wp user set-role votre_login administrator

Si WP-CLI n’est pas disponible, passez par phpMyAdmin. La manipulation est un peu plus technique — le rôle est stocké dans la table wp_usermeta, clé wp_capabilities :

-- Trouver votre user_id d'abord
SELECT ID, user_login FROM wp_users WHERE user_login = 'votre_login';

-- Mettre à jour le rôle (remplacez 123 par votre ID)
UPDATE wp_usermeta
SET meta_value = 'a:1:{s:13:"administrator";b:1;}'
WHERE user_id = 123 AND meta_key = 'wp_capabilities';

⚠️ Si le préfixe de vos tables n’est pas wp_ (ce qui est recommandé pour la sécurité), adaptez le nom de la table et de la meta_key. Le préfixe est visible dans wp-config.php à la ligne $table_prefix.

Si vous n’avez ni WP-CLI ni phpMyAdmin, vous pouvez ajouter un script PHP temporaire via FTP. Mais on recommande plutôt de contacter notre équipe de dépannage — une perte de rôle admin peut être le signe d’un piratage, et il faut auditer le site avant de simplement restaurer l’accès.

---

Les plugins WordPress sont comme les médicaments : individuellement bénéfiques, mais leurs interactions ne sont pas toujours heureuses. Un site WordPress moderne utilise en moyenne une dizaine de plugins, chacun ajoutant ses propres scripts, styles et règles. Quand deux plugins tentent de modifier la même chose au même moment, c’est le conflit — et les symptômes vont du simple dysfonctionnement visuel au crash complet du site.

Site bloqué en mode maintenance après une mise à jour

Vous lancez une mise à jour de plugin ou de WordPress, et le site affiche indéfiniment « Briefly unavailable for scheduled maintenance. Check back in a minute. » — sauf que ça fait bien plus d’une minute. Le site est figé en mode maintenance.

Ce qui s’est passé : quand WordPress lance une mise à jour, il crée un fichier .maintenance à la racine du site pour afficher le message d’attente. Si la mise à jour échoue en cours de route (timeout, erreur PHP, perte de connexion), ce fichier n’est jamais supprimé — et le site reste bloqué.

Solution — supprimer le fichier .maintenance :

# Via SSH — vérifier que le fichier existe
ls -la /chemin/vers/wordpress/.maintenance

# Le supprimer
rm /chemin/vers/wordpress/.maintenance

Si vous n’avez pas accès en SSH, connectez-vous en FTP/SFTP et supprimez le fichier .maintenance à la racine du site (au même niveau que wp-config.php).

⚠️ Attention : le site va revenir en ligne, mais la mise à jour qui a échoué n’est probablement pas terminée. Vérifiez immédiatement dans le back-office que le plugin ou WordPress n’est pas dans un état intermédiaire. Si le plugin problématique est cassé, désactivez-le via WP-CLI avant de retenter :

# Désactiver le plugin qui a planté pendant la MAJ
wp plugin deactivate nom-du-plugin

# Vérifier l'état de tous les plugins
wp plugin status

# Retenter la mise à jour proprement
wp plugin update nom-du-plugin

Prévention : c’est exactement pour ce type de scénario qu’on recommande de toujours faire les mises à jour via WP-CLI plutôt que via le back-office. WP-CLI ne dépend pas du timeout PHP, affiche les erreurs en temps réel, et permet de reprendre proprement en cas d’échec.

Erreur critique — « Il y a eu une erreur critique sur ce site »

Disponible depuis WordPress 5.2 et maintenu dans toutes les versions jusqu’à WordPress 6.8, ce mécanisme affiche un message générique côté visiteur et envoie un email à l’administrateur avec un lien de « mode de récupération ». C’est un progrès par rapport à l’écran blanc, mais le message est volontairement vague — il faut creuser pour trouver la cause réelle.

Première chose à faire — vérifier vos emails. WordPress envoie un email à l’adresse admin du site avec le détail de l’erreur et un lien de récupération. Ce lien vous donne un accès temporaire au back-office avec tous les plugins actifs, ce qui vous permet de désactiver le coupable.

Si vous n’avez pas reçu l’email (spam, mauvaise adresse admin, envoi d’emails cassé sur le serveur), activez WP_DEBUG_LOG comme expliqué dans la section « Réflexes essentiels » et consultez wp-content/debug.log. L’erreur fatale y sera enregistrée avec le nom du fichier responsable.

Solution rapide — identifier et désactiver le plugin fautif :

# Consulter les dernières erreurs dans le log
tail -50 wp-content/debug.log

# L'erreur mentionne un fichier dans wp-content/plugins/nom-du-plugin/ ?
# Désactiver ce plugin
wp plugin deactivate nom-du-plugin

Causes les plus fréquentes :

• Plugin ou thème incompatible avec la version PHP du serveur (ex : plugin pas encore compatible PHP 8.x)
• Mise à jour d’un plugin qui introduit un bug
• Conflit entre deux plugins qui surchargent la même fonction

Après avoir désactivé le coupable : vérifiez s’il existe une version plus récente du plugin, consultez le changelog, et testez la mise à jour sur un environnement de staging si possible. Si c’est un conflit entre deux plugins, il faut souvent choisir lequel garder — ou contacter les développeurs respectifs.

Conflit jQuery / scripts JavaScript

Des boutons qui ne réagissent plus, des sliders figés, des menus déroulants qui ne s’ouvrent pas, un formulaire qui refuse de s’envoyer — quand des éléments interactifs cessent de fonctionner sans raison apparente, c’est souvent un conflit JavaScript.

Diagnostic — la console du navigateur est votre meilleur outil :

Ouvrez les outils de développement (F12) et allez dans l’onglet Console. Les erreurs JavaScript apparaissent en rouge. Les plus révélatrices :

• $ is not defined ou jQuery is not defined — jQuery n’est pas chargé ou est chargé trop tard. Un plugin a probablement déregistré jQuery ou l’a déplacé dans le footer alors qu’un autre script en a besoin dans le header.
• Cannot read property of undefined — un script essaie d’accéder à un élément qui n’existe pas encore dans le DOM, souvent à cause d’un ordre de chargement incorrect.
• Uncaught TypeError — deux plugins définissent une fonction avec le même nom, ou utilisent des versions différentes d’une même bibliothèque.

Solutions par ordre de priorité :

1. Identifier le script fautif. L’erreur dans la console indique le fichier source (cliquez sur le lien à droite du message d’erreur). Si c’est un fichier dans wp-content/plugins/nom-du-plugin/, vous avez votre coupable.

2. Tester en désactivant les plugins un par un. C’est la méthode la plus fiable pour isoler un conflit JS :

# Désactiver tous les plugins
wp plugin deactivate --all

# Réactiver un par un et tester après chaque activation
wp plugin activate plugin-critique-1
# Tester... OK ? Continuer
wp plugin activate plugin-critique-2
# Tester... Bug revenu ? C'est celui-là (ou le conflit entre les deux)

3. Vérifier la version de jQuery. WordPress embarque sa propre version de jQuery. Certains thèmes ou plugins chargent une version différente en parallèle, ce qui crée des conflits. Vérifiez dans la console :

// Taper dans la console du navigateur
jQuery.fn.jquery
// Doit retourner la version incluse dans WordPress (ex: "3.7.1")

Si vous voyez deux scripts jQuery dans l’onglet Sources, un plugin ou le thème charge une version en double — c’est la source du conflit.

---

La base de données est la mémoire de votre site WordPress. Elle stocke vos contenus, vos réglages, vos utilisateurs et toutes les relations entre ces éléments. Quand cette mémoire montre des signes de faiblesse, les symptômes peuvent aller du simple message d’erreur à la perte totale d’accès au site. Voici les trois pannes de base de données que nous traitons le plus souvent.

Error Establishing a Database Connection

C’est l’une des erreurs WordPress les plus stressantes : au lieu de votre site, une page blanche affiche simplement « Error establishing a database connection ». Le site est totalement hors ligne — front-office et back-office.

Ce que ça signifie : WordPress n’arrive pas à se connecter au serveur MySQL/MariaDB. Pas de connexion à la base = pas de contenu à afficher = page blanche.

Les 4 causes à vérifier dans l’ordre :

1. Identifiants incorrects dans wp-config.php. C’est la cause n°1, surtout après une migration ou un changement d’hébergeur. Vérifiez ces 4 lignes :

// Dans wp-config.php — vérifiez chaque valeur
define( 'DB_NAME', 'nom_de_la_base' );
define( 'DB_USER', 'utilisateur_bdd' );
define( 'DB_PASSWORD', 'mot_de_passe' );
define( 'DB_HOST', 'localhost' ); // Parfois 127.0.0.1 ou un socket selon l'hébergeur

Pour vérifier que ces identifiants fonctionnent, testez la connexion directement en ligne de commande :

# Tester la connexion MySQL avec les identifiants de wp-config.php
mysql -u utilisateur_bdd -p -h localhost nom_de_la_base
# Si "Access denied" → identifiants incorrects
# Si "Can't connect" → le serveur MySQL est arrêté ou DB_HOST est faux

2. Le serveur MySQL est arrêté. Sur un hébergement mutualisé (type O2Switch), c’est rare mais ça arrive lors des maintenances. Vérifiez le statut du service :

# Vérifier si MySQL tourne
systemctl status mysql
# ou selon l'hébergeur
systemctl status mariadb

Si MySQL est arrêté et que vous êtes sur un mutualisé, c’est côté hébergeur — contactez leur support. Si vous avez un VPS, redémarrez le service.

3. La base de données est corrompue. Si les identifiants sont bons et MySQL tourne, la base elle-même est peut-être corrompue. WordPress a un outil de réparation intégré :

// Ajouter temporairement dans wp-config.php
define( 'WP_ALLOW_REPAIR', true );

Puis accédez à https://votresite.com/wp-admin/maint/repair.php. Cette page propose deux options : « Réparer la base de données » et « Réparer et optimiser ». Lancez la réparation, puis supprimez immédiatement la ligne de wp-config.php — cette page est accessible sans authentification.

4. L’utilisateur MySQL a perdu ses privilèges. Après une restauration de backup ou une manipulation dans cPanel/phpMyAdmin, l’utilisateur MySQL peut se retrouver dissocié de la base. Vérifiez dans le panneau de gestion de votre hébergeur que l’utilisateur est bien assigné à la base avec tous les privilèges nécessaires.

Table wp_options corrompue ou surdimensionnée

Votre site fonctionne, mais il est lent — particulièrement l’administration. Ou bien certains réglages de plugins semblent se réinitialiser tout seuls. Le coupable est souvent la table wp_options, la table la plus sollicitée de WordPress et celle qui grossit le plus au fil du temps.

Pourquoi wp_options est critique : à chaque chargement de page, WordPress exécute une requête qui charge en mémoire toutes les lignes de wp_options où autoload = 'yes'. Sur un site propre, ça représente quelques centaines de lignes. Sur un site avec beaucoup de plugins installés/désinstallés au fil des années, ça peut atteindre des milliers de lignes et plusieurs mégaoctets — chargés à chaque page.

Diagnostic :

# Nombre total de lignes dans wp_options
wp db query "SELECT COUNT(*) as total FROM wp_options;"

# Nombre et taille des options en autoload (c'est ça qui impacte les performances)
wp db query "SELECT COUNT(*) as nb_autoload, ROUND(SUM(LENGTH(option_value))/1024/1024, 2) as taille_mo FROM wp_options WHERE autoload = 'yes';"

# Les 20 plus grosses options autoload (pour trouver les coupables)
wp db query "SELECT option_name, LENGTH(option_value) as taille, autoload FROM wp_options WHERE autoload = 'yes' ORDER BY LENGTH(option_value) DESC LIMIT 20;"

Ce qu’il faut regarder :

• Si la taille autoload dépasse 1 Mo, c’est trop — objectif : rester sous 500 Ko.
• Les options les plus grosses sont souvent des transients expirés, des logs de plugins de sécurité, ou des données de plugins désinstallés qui n’ont pas nettoyé derrière eux.

Nettoyage :

# Supprimer les transients expirés (sans risque)
wp transient delete --expired

# Supprimer TOUS les transients (régénérés automatiquement au besoin)
wp transient delete --all

# Désactiver l'autoload sur une option spécifique non critique
wp db query "UPDATE wp_options SET autoload = 'no' WHERE option_name = 'nom_option_volumineuse';"

# Optimiser la table après le nettoyage
wp db optimize

⚠️ Prudence : ne supprimez pas des options au hasard — certaines sont vitales pour WordPress ou vos plugins actifs. Concentrez-vous sur les transients expirés et les options de plugins que vous avez désinstallés. En cas de doute, passez l’option en autoload = 'no' plutôt que de la supprimer — ça résout le problème de performance sans risque de casse.

Erreur lors de l’import/export de base de données

Vous tentez de migrer votre site ou de restaurer un backup, et l’import de la base échoue à mi-chemin. Le message d’erreur varie selon l’outil utilisé, mais les causes sont presque toujours les mêmes.

Symptômes courants :

• phpMyAdmin qui affiche « Script timeout passed » ou « No data received »
• Import WP-CLI qui plante avec une erreur MySQL
• Plugin de migration (Duplicator, All-in-One WP Migration) qui reste bloqué à un pourcentage

Cause n°1 — Fichier SQL trop volumineux pour phpMyAdmin. phpMyAdmin a une limite d’upload (souvent 50 Mo ou 128 Mo sur les mutualisés). Si votre dump dépasse cette limite, l’import échoue silencieusement ou timeout.

Solution : importez via la ligne de commande, qui n’a pas de limite de taille :

# Import via WP-CLI (méthode recommandée)
wp db import sauvegarde.sql

# Import via mysql directement (si WP-CLI non dispo)
mysql -u utilisateur -p nom_base < sauvegarde.sql

Cause n°2 — Jeu de caractères incompatible. L’export a été fait en utf8 mais la base cible attend du utf8mb4, ou inversement. Symptôme : l’import réussit mais des caractères spéciaux (accents, émojis) apparaissent corrompus.

# Vérifier le charset du fichier SQL
head -20 sauvegarde.sql | grep -i charset

# Si nécessaire, convertir avant l'import
sed -i 's/utf8mb4/utf8/g' sauvegarde.sql
# ou inversement selon le cas

Cause n°3 — Contraintes de clés étrangères ou tables manquantes. Si le dump SQL contient des instructions dans un ordre qui crée des dépendances circulaires, l’import peut échouer. Solution :

# Désactiver temporairement les vérifications de clés étrangères pendant l'import
wp db query "SET FOREIGN_KEY_CHECKS = 0;"
wp db import sauvegarde.sql
wp db query "SET FOREIGN_KEY_CHECKS = 1;"

Bonne pratique pour les exports : utilisez toujours WP-CLI pour exporter, c’est le format le plus fiable pour un import WordPress :

# Export propre et complet
wp db export sauvegarde-$(date +%Y%m%d).sql

C’est plus fiable que phpMyAdmin (pas de timeout, pas de limite de taille) et le fichier résultant est optimisé pour un réimport WordPress.

---

Dans le monde numérique, les menaces de sécurité évoluent constamment, cherchant de nouvelles failles à exploiter. WordPress propulse plus de 40 % du web — cette popularité en fait une cible privilégiée des pirates, non pas parce que le CMS est fragile, mais parce que l’impact d’une faille est démultiplié par le nombre de sites concernés. Voici les trois signes d’infection que nous rencontrons le plus en intervention d’urgence.

Redirections malveillantes vers des sites tiers

Vos visiteurs cliquent sur un lien de votre site et se retrouvent sur un site de pharma douteuse, de casino en ligne ou de faux support technique. Ou pire : Google affiche un avertissement « Ce site a peut-être été piraté » dans les résultats de recherche. Ce sont les symptômes typiques d’une injection de redirections malveillantes.

Particularité vicieuse : ces redirections sont souvent invisibles pour l’administrateur. Le code malveillant détecte les visites depuis Google (via le referer HTTP) et ne redirige que ces visiteurs-là — quand vous accédez directement au site, tout semble normal. C’est pour ça que le piratage peut passer inaperçu pendant des semaines.

Diagnostic — chercher le code injecté :

# Chercher les redirections dans .htaccess (premier endroit à vérifier)
cat .htaccess
# Chercher des lignes suspectes : RewriteRule vers des domaines externes,
# blocs encodés en base64, ou des conditions sur HTTP_REFERER

# Chercher des injections base64 dans les fichiers PHP
grep -r "base64_decode" wp-content/ --include="*.php" -l
grep -r "eval(" wp-content/ --include="*.php" -l

# Chercher des fichiers PHP suspects dans wp-includes (il ne devrait y avoir
# que des fichiers WordPress core — tout fichier inconnu est suspect)
find wp-includes/ -name "*.php" -newer wp-includes/version.php

Vérifier l’intégrité du core WordPress :

# WP-CLI compare vos fichiers avec les originaux de WordPress.org
wp core verify-checksums
# Tout fichier modifié ou ajouté sera listé

Nettoyage :

1. Remplacez le .htaccess par un fichier propre (Réglages > Permaliens > Enregistrer)
2. Réinstallez le core WordPress propre : wp core download --force --skip-content
3. Vérifiez la base de données — les redirections peuvent aussi être injectées dans wp_options :

# Chercher des URLs suspectes dans wp_options
wp db query "SELECT option_name, option_value FROM wp_options WHERE option_value LIKE '%<script%' OR option_value LIKE '%eval(%' OR option_value LIKE '%base64_decode%';"

⚠️ Important : un simple nettoyage ne suffit pas si vous ne colmatez pas la faille d’entrée. Changez tous les mots de passe (admin WordPress, FTP, base de données, cPanel), mettez à jour WordPress, les plugins et le thème, et identifiez le point d’entrée (plugin vulnérable, mot de passe faible, version PHP obsolète). Sans ça, le site sera réinfecté sous quelques jours.

Fichiers infectés dans wp-includes ou wp-content

Votre site se comporte bizarrement — pages lentes, pop-ups qui apparaissent, contenu spam injecté dans vos articles — mais il n’y a pas de redirection. Le pirate a déposé des fichiers malveillants directement dans l’arborescence WordPress, souvent dans des endroits que personne ne vérifie.

Emplacements favoris des pirates :

• wp-includes/ — des fichiers PHP ajoutés qui imitent des noms légitimes (wp-info.php, class-wp-cache.php)
• wp-content/uploads/ — des fichiers PHP cachés parmi les images (un .php dans un dossier 2024/03/ passe facilement inaperçu)
• wp-content/plugins/ — un faux plugin avec un nom anodin (starter-toolkit/, security-helper/)

Diagnostic complet :

# 1. Vérifier l'intégrité du core
wp core verify-checksums

# 2. Vérifier l'intégrité de chaque plugin installé depuis WordPress.org
wp plugin verify-checksums --all

# 3. Chercher des fichiers PHP dans le dossier uploads (il ne devrait y en avoir aucun)
find wp-content/uploads/ -name "*.php" -type f

# 4. Chercher les fichiers modifiés récemment (dernières 48h)
find . -name "*.php" -mtime -2 -type f

# 5. Chercher des patterns malveillants classiques
grep -r "eval(base64_decode" wp-content/ --include="*.php" -l
grep -r "file_put_contents" wp-content/ --include="*.php" -l
grep -r "$_REQUEST[" wp-content/ --include="*.php" -l
grep -r "preg_replace.*/e" wp-content/ --include="*.php" -l

Nettoyage méthodique :

1. Core WordPress : réinstallez proprement avec wp core download --force --skip-content
2. Plugins : supprimez et réinstallez chaque plugin depuis WordPress.org (wp plugin install nom-plugin --force)
3. Thème : si c’est un thème du répertoire officiel, même traitement. Si c’est un thème custom, auditez chaque fichier manuellement
4. Uploads : supprimez tout fichier .php trouvé dans wp-content/uploads/
5. Plugins inconnus : supprimez tout dossier de plugin que vous n’avez pas installé vous-même

Après le nettoyage : changez les clés de sécurité dans wp-config.php (ça invalide toutes les sessions actives, y compris celles du pirate) :

# Régénérer les clés de sécurité (déconnecte tous les utilisateurs)
wp config shuffle-salts

Compte administrateur inconnu ajouté

En consultant la liste des utilisateurs WordPress, vous découvrez un compte administrateur que personne dans votre équipe n’a créé. C’est le signe clair d’un accès non autorisé — le pirate s’est créé une porte d’entrée permanente pour revenir même si vous changez votre propre mot de passe.

Diagnostic — lister tous les administrateurs :

# Lister tous les comptes avec le rôle administrateur
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Examinez chaque compte attentivement. Les signaux d’alerte :

• Un nom d’utilisateur générique que personne ne reconnaît (admin2, support, wp_update)
• Une adresse email sur un domaine gratuit sans rapport avec votre entreprise
• Une date d’inscription récente que personne ne peut expliquer

Suppression du compte frauduleux :

# Supprimer le compte suspect (remplacez ID par l'ID du compte)
# --reassign=1 attribue le contenu éventuel à l'admin principal (ID 1)
wp user delete ID_SUSPECT --reassign=1

⚠️ Ne vous arrêtez pas là. Un compte admin ajouté signifie que le pirate a déjà un accès au site — supprimer le compte ne ferme pas la faille qui lui a permis d’entrer. Procédez dans cet ordre :

Étape 1: Supprimez le compte frauduleux (commande ci-dessus)

Étape 2: Changez le mot de passe de tous les comptes admin légitimes :

wp user update votre_login --user_pass='NouveauMotDePasseComplexe'

Étape 3: Régénérez les clés de sécurité pour invalider toutes les sessions :

wp config shuffle-salts

Étape 4: Vérifiez qu’il n’y a pas de backdoor qui recrée le compte automatiquement — cherchez des hooks WordPress malveillants :

# Chercher du code qui crée des utilisateurs
grep -r "wp_create_user|wp_insert_user" wp-content/ --include="*.php" -l

Étape 5: Auditez le site complet avec les commandes de la section « Fichiers infectés » ci-dessus

Si vous n’êtes pas sûr de pouvoir tout nettoyer vous-même, c’est le type d’intervention où faire appel à un professionnel est fortement recommandé. Un nettoyage incomplet laisse des portes ouvertes, et le pirate reviendra.

---

La maintenance préventive d’un site WordPress, c’est exactement comme un bilan de santé régulier : personne n’a envie de s’y coller, mais ceux qui le font évitent les hospitalisations d’urgence. La majorité des bugs décrits dans ce guide — conflits de plugins, piratages, erreurs de base de données — auraient pu être évités avec un protocole de maintenance structuré.

Voici le programme que nous appliquons chez nos clients sous contrat de maintenance WordPress :

Vérifications quotidiennes

Surveillance de disponibilité (uptime monitoring). Votre site est-il accessible 24h/24 ? Un outil de monitoring (UptimeRobot, Better Uptime, Freshping) vous alerte par SMS ou email en moins de 5 minutes si le site tombe. Sans ça, c’est un client ou Google qui vous l’apprend.

Scan de sécurité automatisé. Fichiers modifiés, tentatives de connexion suspectes, logiciels malveillants — un scan quotidien détecte une intrusion dans les heures qui suivent l’infection, avant qu’elle ne se propage.

Vérifications hebdomadaires

Mises à jour WordPress, plugins et thème. Chaque semaine, de nouvelles vulnérabilités sont publiées. La mise à jour est le correctif. Testez-la sur un environnement de staging, puis déployez. Via WP-CLI, ça prend 2 minutes :

wp core update
wp plugin update --all
wp theme update --all

Vérification des sauvegardes. Avoir une sauvegarde c’est bien. Avoir une sauvegarde qui fonctionne, c’est mieux. Testez un fichier de sauvegarde au hasard chaque semaine — une sauvegarde corrompue non détectée, c’est une fausse sécurité.

Contrôle des liens cassés et erreurs 404. Un lien interne qui renvoie vers une page inexistante, c’est une mauvaise expérience utilisateur et un signal négatif pour Google. Screaming Frog en mode planifié ou un plugin dédié (Broken Link Checker en mode scheduled, pas en temps réel) suffit à les identifier.

Bilan mensuel

Optimisation de la base de données. Supprimez les révisions d’articles accumulées, les transients expirés et les données orphelines laissées par les plugins désinstallés (cf. section wp_options plus haut). Une base nettoyée mensuellement ne grossit pas de façon incontrôlée :

wp transient delete --expired
wp post delete $(wp post list --post_type='revision' --format=ids --posts-per-page=200) --force
wp db optimize

Audit des comptes utilisateurs. Listez les administrateurs actifs, vérifiez qu’aucun compte inconnu n’a été ajouté, et révoquez les accès obsolètes (anciens prestataires, stagiaires partis). Deux minutes de vérification mensuelle, une faille de sécurité potentielle en moins.

Bilan des performances. Comparez le TTFB et le score PageSpeed avec le mois précédent. Une dégradation progressive est souvent le signe d’une table wp_options qui grossit, d’une image non optimisée ajoutée récemment, ou d’un plugin devenu lourd après mise à jour.

Récapitulatif du protocole

Fréquence	Action	Outil
Quotidienne	Surveillance uptime	UptimeRobot / Better Uptime
Quotidienne	Scan sécurité	Wordfence / Sucuri
Hebdomadaire	Mises à jour (core, plugins, thème)	WP-CLI / back-office
Hebdomadaire	Vérification sauvegardes	UpdraftPlus / BackWPup
Hebdomadaire	Contrôle liens cassés	Screaming Frog / plugin
Mensuelle	Nettoyage base de données	WP-CLI
Mensuelle	Audit comptes utilisateurs	WP-CLI / back-office
Mensuelle	Bilan performances	PageSpeed Insights / GTmetrix

Vous préférez déléguer tout ça ? C’est exactement ce que couvre notre contrat de maintenance WordPress — mises à jour, sauvegardes vérifiées, monitoring, et intervention prioritaire en cas de problème.

---

Que ce soit un simple bug d’affichage ou un piratage complexe nécessitant une réparation approfondie, chaque problème WordPress a sa solution.

Maintenir un site WordPress en bonne santé demande de la vigilance et des soins réguliers. Comme pour votre santé, la prévention reste le meilleur remède. Si votre site présente l’un des symptômes décrits dans cet article, n’attendez pas qu’il s’aggrave : agissez rapidement ou consultez un expert.

Notre service de dépannage WordPress professionnel est disponible 7j/7 pour établir un diagnostic précis et appliquer le traitement approprié à votre site. Avec une maintenance régulière et des soins appropriés, votre site WordPress peut rester performant et sécurisé pendant de nombreuses années.

---