Réparation site WordPress : restaurer après corruption de base de données

Quand un site WordPress tombe en panne, la première émotion est souvent la même, puis les minutes passent et la réalité s’installe. Le fichier PHP n’a pas forcément “cassé”. Très souvent, le problème vient d’une base de données corrompue, d’une table qui répond mal, d’une requête qui finit en erreur, ou d’une mise à jour WordPress ratée qui a laissé WordPress dans un état incohérent. On voit aussi des cas où le site WordPress a été piraté, et la corruption de base arrive en cascade, avec des tentatives d’accès en arrière-plan et des options modifiées.

Dans cet article, je vais vous expliquer comment raisonner, quoi vérifier, et comment restaurer proprement après une corruption de base de données. Je vais parler aussi des erreurs que vous rencontrerez presque toujours sur un site WordPress en panne, notamment l’erreur critique WordPress, l’erreur 500 WordPress, la page blanche, et les symptômes qui ressemblent à une attaque, alors que c’est parfois “juste” la DB.

Les symptômes qui pointent vers une base corrompue

Une corruption de base de données ne se manifeste pas toujours par un message clair. Parfois, c’est immédiat, parfois ça arrive “après” un événement.

Les déclencheurs typiques que j’ai vus sur des environnements réels :

une migration (hébergement changé, base importée manuellement, encodage ou collation différents)
une mise à jour WordPress ratée, surtout si le PHP a expiré pendant l’exécution
une intervention manuelle sur les tables, ou une sauvegarde restaurée incomplète
des erreurs d’espace disque sur le serveur de base, qui interrompent une requête
une intrusion qui a modifié des options ou créé des entrées anormales

Côté symptômes, on retombe très souvent sur :

Un site WordPress en panne avec page blanche (parfois seulement certaines pages), une erreur 500 WordPress qui apparaît dès que vous ouvrez une page d’administration, ou une erreur critique WordPress quand WordPress charge les tables nécessaires au chargement du thème, des options et de la configuration.

Et il y a un détail qui trompe pas mal de monde : vous pouvez avoir un site “qui affiche quelque chose” mais qui est déjà cassé. Par exemple, le front affiche le thème et des images, mais l’administration renvoie des erreurs parce que wp options ou wpposts répond mal, ou parce que les requêtes de sauvegarde expirent. On croit alors à un souci de plugin, alors que la racine est la base.

Première urgence : isoler sans aggraver

Avant de “réparer”, il faut éviter de faire pire. Sur une DB corrompue, chaque tentative de mise à jour, de purge de cache, ou de sauvegarde automatique peut ajouter des lignes incohérentes ou déclencher des erreurs en boucle.

Le réflexe que j’applique toujours en urgence WordPress :

1) Mettre le site à l’arrêt, ou au moins en maintenance, pour stopper le trafic et les déclenchements (cron, plugins, indexation). 2) Bloquer l’accès à wp-admin si nécessaire, le temps d’analyser. 3) Vérifier que vous avez une sauvegarde fiable de la base, et pas juste un dump incomplet.

WordPress a une fonction de maintenance, soit via l’admin, soit via la création d’un fichier de maintenance quand WordPress redémarre après incident. En pratique, sur un site WordPress en panne où l’administration est inutilisable, on passe souvent par un mode maintenance côté serveur. Le but est simple : réduire le nombre de requêtes pendant que vous travaillez.

Si vous êtes dans une situation de dépannage WordPress chez un client, j’ajoute toujours un point humain : quelqu’un doit savoir qui fait quoi. Quand plusieurs personnes tentent des restaurations en même temps, on finit avec deux bases dans deux états, et la “meilleure version” devient introuvable.

Comprendre la nature de la corruption : erreurs SQL, tables, encodage

La corruption n’est pas toujours “la base est illisible”. Elle prend plusieurs formes.

Dans les cas les plus fréquents, vous aurez des erreurs du type requêtes échouées, syntaxe SQL invalide (parfois à cause de contenus corrompus), ou erreurs de connexion à la base.

Mais il y a aussi des corruptions partielles. Certaines tables fonctionnent, d’autres non. Par exemple, wp options peut répondre mais wpposts renvoie une erreur, ou l’inverse. On peut aussi avoir un problème d’encodage, où des caractères “cassent” une requête. Ça arrive après certaines migrations ou restaurations depuis un dump généré dans un contexte différent.

Un autre signal important : si vous voyez des erreurs uniquement après un accès admin, souvent c’est lié à une table contenant des options ou des métadonnées manipulées par des plugins. Le diagnostic devient alors plus “chirurgical” plutôt que “tout restaurer”.

Vérifier les logs : c’est eux qui tranchent

Quand j’entends “ça affiche page blanche”, je ne me précipite pas sur les fichiers. Je commence par regarder les logs, parce qu’ils disent ce que WordPress fait réellement.

Deux sources sont particulièrement utiles :

logs PHP et logs serveur (Nginx/Apache), où une erreur 500 WordPress se traduit souvent par un message concret
logs MySQL ou MariaDB, où une corruption de table ou un incident de transaction apparaît

Si WordPress affiche une erreur, activez l’affichage des erreurs uniquement le temps de diagnostic, puis désactivez. Sur certains serveurs, les erreurs sont déjà remontées dans les logs mais pas à l’écran. L’objectif, c’est d’identifier la requête ou la table qui pose problème.

Dans un contexte de réparation site WordPress, ce point est souvent le plus rentable. Sans logs, on tente des réparations “au hasard” : désactivation de plugins, changement de thème, régénération de permalinks. Ça peut aider dans des cas de conflit, mais si la DB est en cause, vous perdez du temps.

Réparer au niveau WordPress : wp-config.php, paramètres et réparation de base

Avant d’entrer dans MySQL, il faut vérifier ce que WordPress a dans wp-config.php. En dépannage WordPress, on voit parfois :

des identifiants incorrects après migration
un préfixe de table ($table_prefix) qui ne correspond pas à la base restaurée
des paramètres de connexion qui pointent vers la mauvaise base
un mauvais caractère de collation lors de restauration (plus rare, mais ça arrive)

Ensuite, la “réparation” au sens WordPress correspond à des outils assez limités pour la DB. WordPress peut proposer certaines opérations, comme la réparation de tables, mais aujourd’hui, on est souvent plus efficace en allant directement côté SGBD.

Cela dit, il y a une étape logique : confirmer que WordPress arrive à se connecter et à exécuter des requêtes simples. Si WordPress échoue dès qu’il tente de lire des options, on saura que le problème est plus bas que le applicatif.

Restaurer proprement la base : le choix entre réparation et rollback

Quand on parle de réparation site WordPress, la question centrale est toujours la même : est-ce qu’on répare la DB existante, ou est-ce qu’on restaure une sauvegarde plus saine ?

En atelier, je vois deux scénarios.

Cas A : la DB est partiellement lisible

Le site affiche une partie des pages, l’administration échoue, mais les logs montrent des erreurs sur certaines tables. Là, on peut parfois :

identifier la table fautive
réparer cette table (selon le moteur, InnoDB, MyISAM)
nettoyer des données incohérentes (par plugin ou par intrusion)

Le risque est de corriger une “symptôme” plutôt que la cause, surtout si la base a été modifiée par un processus malveillant.

Cas B : la DB est globalement instable

Si l’erreur 500 WordPress survient dès le chargement, si plusieurs tables échouent, si MySQL signale des erreurs de corruption plus large, ou si vous voyez des timeouts sur des requêtes simples, alors la restauration est souvent le choix le plus sûr.

Le point clé est la qualité de la sauvegarde. Une sauvegarde “ancienne” mais cohérente peut être préférable à une sauvegarde récente et incomplète. Sur un site WordPress piraté, c’est encore plus important : une sauvegarde de la période d’infection peut réintroduire les portes dérobées, même si les tables semblent “revenues à la normale”.

Une méthode de restauration qui évite les mauvaises surprises

Je vais décrire une méthode pragmatique, celle que j’utilise quand il faut agir vite sans se tromper de base.

Avant de toucher à quoi que ce soit, je note les états : nom de la base, utilisateur MySQL, version MySQL/MariaDB si elle est visible, et surtout la taille des dumps si vous en avez. Une différence de taille trop grande entre deux dumps “à la même heure” est souvent un indice de restauration incomplète.

Ensuite, je travaille dans cet ordre.

Préparer l’environnement

Je mets en maintenance, et je m’assure que personne ne déclenche de synchronisation ou de purge. Je coupe le cron si possible, ou je limite les processus. Si le site utilise WooCommerce, je suspends les tâches critiques pour éviter des paniers ou des commandes incohérentes. Oui, on parle ici d’une DB WordPress, mais sur beaucoup de sites, WooCommerce est le cœur des données. Un WooCommerce en panne peut résulter du même problème de base, ou bien d’une cohérence de données brisée.

Restaurer la base depuis une sauvegarde saine

Je restaure dans une base dédiée ou je remplace proprement la base actuelle. En fonction de l’infrastructure, créer une base “de travail” est une option solide : vous pouvez tester WordPress sans risque de perdre l’état actuel.

Vérifier l’intégrité

Après restauration, je vérifie que WordPress charge une page simple, puis l’admin, puis le front avec un thème réel. Si tout répond, c’est déjà un gros point. Si certaines fonctionnalités échouent, je passe par la détection des tables en cause.

Retrouver la cause

Enfin, je cherche pourquoi la corruption s’est produite. C’est là que les “réparations” deviennent durables. Si c’était une mise à jour WordPress ratée, je corrige le pipeline de mise à jour. Si c’était une contrainte disque, j’augmente la marge et je surveille. Si c’était une intrusion, je nettoie aussi les fichiers et je change les accès.

Voici un mini repère de diagnostic, très court, mais utile quand on est en urgence WordPress :

si wp-config.php pointe sur la mauvaise base, c’est d’abord là qu’on corrige
si les erreurs SQL mentionnent une ou deux tables précises, on tente une réparation ciblée
si plusieurs tables cassent, restauration depuis sauvegarde cohérente
si l’accès admin est le seul qui échoue, suspicion de données d’options ou de métadonnées manipulées
si des logs montrent des tentatives de scripts, il faut vérifier aussi côté fichiers pour un site WordPress piraté

Quand l’intrusion ressemble à une corruption : cas “site WordPress piraté”

Un site Jetez un coup d’œil sur ce site Web WordPress piraté peut provoquer une “corruption” qui n’en est pas exactement une, au sens où les structures ne sont pas forcément endommagées. En revanche, les données peuvent être polluées : options modifiées, utilisateurs ajoutés, plugins réinstallés, cron détourné, contenus injectés.

Dans ce contexte, une restauration de base uniquement ne suffit pas. Vous pouvez restaurer wp posts et wpoptions, mais si un fichier modifié charge un contenu malveillant au runtime, vous réinfectez au prochain chargement.

C’est la raison pour laquelle, même si votre objectif principal est la réparation site WordPress après corruption de base, je recommande toujours de vérifier rapidement l’état des fichiers WordPress et des plugins. Un scan de fichiers et une comparaison avec un état connu peuvent éviter de “réussir la restauration” tout en laissant une porte ouverte.

Signaux typiques :

utilisateurs admin supplémentaires apparus sans raison
changements répétés de wp_options
chargement de fichiers inhabituels dans le thème ou dans wp-includes
cron WordPress qui se déclenche en boucle

Si vous êtes en présence d’un site WordPress piraté, l’ordre d’action doit intégrer sécurité d’abord, DB ensuite. On peut restaurer, mais on doit aussi éliminer la source.

Et si la panne ressemble à autre chose : maintenance, mise à jour ratée, plugins

Parfois, une corruption de base de données est accompagnée de symptômes qui ressemblent à :

maintenance WordPress qui se déclenche mais ne se retire pas
mise à jour WordPress ratée, avec base partiellement migrée
conflit plugin après un update, qui provoque des erreurs d’admin
cache mal géré (notamment sur Nginx ou via un plugin)

Je le dis simplement : dans ces cas, la DB corrompue peut être soit la cause, soit la conséquence. Si la base a été écrite de façon interrompue pendant la mise à jour, vous aurez un mélange de “conflit” et de corruption. D’où l’importance des logs.

Un exemple concret que j’ai déjà rencontré : après une mise à jour, le site affichait une erreur critique WordPress sur l’admin, tandis que le front fonctionnait pour certains URLs. Le plugin de cache pensait que tout allait bien, parce que les pages servies étaient en cache. En creusant côté logs, on voyait une requête échouée sur wp_options liée à une migration incomplète. Une fois la base restaurée depuis une sauvegarde juste avant la mise à jour, la page blanche disparaissait, et l’admin revenait.

Réparation WordPress étape par étape, sans se perdre

Je vais vous proposer une démarche complète, sans listes techniques interminables, mais avec un enchaînement clair. C’est aussi la méthode que j’utilise quand je fais du dépannage WordPress pour restaurer après corruption de base.

1) Stopper le bruit, mettre en maintenance

Le temps que vous diagnostiquiez, vous ne voulez pas que WordPress continue à écrire, ni que les bots “tapent” les pages d’erreur. Une maintenance bien posée réduit la charge et évite des effets de bord.

2) Valider la connexion

Vérifier wp-config.php, préfixes de table, identifiants, hôte de base. Un détail comme un préfixe $table_prefix mal aligné après restauration peut donner une impression de “DB corrompue”, alors que c’est juste un mismatch.

3) Identifier les requêtes cassées

Avec les logs, repérez les messages : erreur SQL, table mentionnée, trace PHP autour de wp-admin ou autour de certains écrans.

4) Choisir réparation ciblée ou restauration complète

Si vous avez une table identifiée, réparation ciblée possible. Si vous avez une cascade, restauration depuis une sauvegarde cohérente.

5) Vérifier et tester progressivement

Je teste toujours dans cet ordre : chargement d’une page simple, chargement des pages qui utilisent les options, puis l’admin. Si WooCommerce est actif, je valide aussi l’interface des produits et le panier. Quand WooCommerce en panne vient du même problème, le back-office est souvent le premier à montrer l’odeur.

Pour garder un cap, voici la seule mini-checklist que je recommande vraiment en urgence, parce qu’elle évite les erreurs humaines :

activer la maintenance et limiter les accès pendant le diagnostic
récupérer les logs PHP et SGBD avant de modifier quoi que ce soit
sauvegarder l’état actuel de la base avant toute restauration
restaurer depuis la sauvegarde la plus cohérente, pas forcément la plus récente
valider front, admin, et si présent WooCommerce, avant de remettre en ligne

Cas particuliers : erreurs 500, page blanche, admin inaccessible

L’erreur 500 WordPress

Le “500” est une ombre portée. Il peut venir de PHP, d’un plugin, d’un timeout, ou d’une erreur DB. Le diagnostic se fait par les logs. Si les logs mentionnent des erreurs SQL, on revient au problème de base. Si les logs mentionnent un fatal error PHP, on ne doit pas conclure trop vite.

Dans les cas DB, vous pouvez avoir un message “Erreur de base de données” côté WordPress, ou un fatal silencieux si display_errors est masqué. Là encore, les logs sont votre boussole.

La page blanche

Page blanche sur le front ou sur wp-admin. Sur une DB corrompue, page blanche peut arriver quand WordPress ne parvient pas à charger les options essentielles, ou quand une classe essaye de lire des données qui déclenchent une exception. Sur un environnement mal configuré, vous aurez peu d’informations. J’insiste, logs.

Admin inaccessible

Si seul wp-admin ne répond pas, il y a deux hypothèses fréquentes : données incohérentes dans les options et échec de certaines requêtes plus coûteuses. Les plugins d’administration et de sécurité modifient souvent wp_options. Et sur un site WordPress piraté, les modifications d’options peuvent être la source du blocage.

Après la restauration : nettoyer, sécuriser, et éviter la récidive

Restaurer la base, c’est une étape. Empêcher la panne de revenir, c’est le travail de fond.

Si le problème venait d’une mise à jour WordPress ratée, vous devez regarder le process : espace disque, limite mémoire PHP, temps d’exécution. Une mise à jour échouée en plein milieu peut laisser des migrations “en cours”. La réparation après corruption de base se transforme alors en remise à plat de votre stratégie de mise à jour.

Si le problème venait d’un espace disque, la suite est simple, augmenter la capacité, mettre une alerte, et surveiller les logs DB.

Si le problème vient d’une intrusion, là, il faut faire plus que restaurer. On revient sur l’hygiène sécurité : mots de passe, clés API, suppression de comptes ajoutés, nettoyage de fichiers modifiés, réinstallation des plugins suspects, durcissement.

Et si votre activité est hybride, par exemple une plateforme qui héberge aussi une boutique, vous avez peut-être croisé la logique de dépannage PrestaShop. Je le dis parce qu’on voit parfois des environnements où un même prestataire gère WordPress et PrestaShop sur la même infrastructure. Les erreurs critiques côté PrestaShop (boutique PrestaShop inaccessible, page blanche PrestaShop) ne sont pas identiques à WordPress, mais la philosophie de diagnostic est la même : logs d’abord, sauvegarde cohérente, restauration contrôlée.

Et si votre client a aussi une boutique PrestaShop ou une boutique WooCommerce ?

Je sais, le titre parle de WordPress. Mais dans les missions réelles, c’est rarement isolé.

Si vous gérez une boutique WooCommerce, la même base WordPress peut entraîner un WooCommerce en panne. Le dépannage WooCommerce commence alors souvent par la DB et les tables d’options. Une fois WordPress restauré, on valide le fonctionnement du module de paiement, la disponibilité des produits, et l’intégrité des commandes.
Si vous gérez une boutique PrestaShop sur un autre serveur, le diagnostic “base corrompue” se traite à la même logique, même si les tables et les outils changent. Un site PrestaShop en panne ou une maintenance PrestaShop qui reste bloquée peut être une conséquence d’une base instable, ou d’un processus interrompu pendant une mise à jour PrestaShop ratée.

Ces recoupements comptent parce qu’ils influencent la façon dont on planifie l’intervention. En pratique, si vous êtes en contexte de dépannage site internet global, vous devez éviter de toucher aux bases de production au même moment.

Les erreurs à éviter absolument

Je termine avec les erreurs “classiques” qui reviennent, parce qu’elles coûtent cher en temps et en sérénité.

D’abord, ne pas se contenter d’un “plugin en cause” quand les logs pointent MySQL. Désactiver des plugins pendant que la base est instable peut provoquer une nouvelle couche d’incohérence. Ensuite, ne pas restaurer une sauvegarde récente si vous suspectez une intrusion au même moment. Enfin, ne pas remettre en ligne sans vérifier les zones sensibles, surtout l’administration et les fonctionnalités e-commerce.

Une dernière erreur fréquente : oublier de documenter ce que vous faites. Dans un dépannage WordPress, chaque modification doit être tracée, même rapidement. Quand vous avez plusieurs tentatives, vous saurez quoi revenir en arrière, et vous éviterez de perdre la meilleure fenêtre de récupération.

Ce que j’attends d’un dépannage WordPress bien fait

Si vous faites intervenir quelqu’un, ou si vous gérez vous même le chantier, attendez au minimum ces points de méthode.

Je ne parle pas de jargon, je parle de décisions. Est-ce qu’on a identifié la cause probable dans les logs ? Est-ce qu’on a comparé la qualité des sauvegardes ? Est-ce qu’on a prévu une validation front et admin ? Est-ce qu’on a sécurisé après restauration pour éviter un retour de la panne ? Quand ces éléments sont réunis, la réparation site WordPress après corruption de base devient un retour à la normale, plutôt qu’une succession d’essais.

Si vous voulez, décrivez-moi les symptômes exacts (page blanche ou erreur 500 WordPress, ce qui se passe sur wp-admin, un extrait des logs SQL ou PHP si vous pouvez). Avec ces informations, je peux vous proposer un plan de diagnostic plus précis pour votre cas, en distinguant réparation ciblée et restauration complète.