# Tables de la base de données indisponibles : réparer WordPress

> « Une ou plusieurs tables de votre base de données sont indisponibles » : réparez WordPress avec WP_ALLOW_REPAIR, WP-CLI ou phpMyAdmin, en toute sécurité.

- Auteur : WordPress Développement
- Publié le : 2026-10-02
- Mis à jour le : 2026-10-02
- URL : https://www.wpmoderne.fr/erreurs-wordpress/tables-endommagees/

> Une table WordPress (souvent wp_options) est corrompue ou illisible. Sauvegardez, ajoutez define( ’WP_ALLOW_REPAIR’, true ); dans wp-config.php, ouvrez /wp-admin/maint/repair.php, lancez la réparation, puis retirez la ligne.

Votre site affiche soudain un message disant qu’une ou plusieurs tables de la base de données sont indisponibles et qu’il faudrait la réparer. Selon l’endroit, vous verrez ce texte complet (dans l’administration, ou lors de l’installation) ou le message plus bref [« Erreur lors de la connexion à la base de données »](https://www.wpmoderne.fr/erreurs-wordpress/erreur-connexion-base-de-donnees/) sur les pages publiques. Dans les deux cas, WordPress réussit à joindre le serveur MySQL ou MariaDB, mais ne parvient pas à lire une de ses propres tables.

C’est une situation sérieuse mais rarement fatale : dans la majorité des cas, une table abîmée après une coupure ou un disque plein se répare en quelques secondes. Le plus important est de sauvegarder avant d’agir.

## Ce que signifie cette erreur

Au démarrage, WordPress appelle `is_blog_installed()` (`wp-includes/functions.php`) pour savoir si le site est installé. La fonction cherche l’option `siteurl` dans la table des options. Si elle ne peut pas la lire, elle exécute `DESCRIBE` sur chacune des tables du cœur. Aucune table n’existe : le site est considéré comme vierge et WordPress redirige vers l’installateur (`wp_not_installed()`, `wp-includes/load.php`). Au moins une table existe : le site a été installé, mais une table est illisible. WordPress prépare alors le message ci-dessus, avec un lien vers `maint/repair.php`, puis appelle `dead_db()`.

Cette dernière fonction affiche le texte détaillé uniquement dans l’administration ou pendant l’installation ; ailleurs, elle se contente de « Erreur lors de la connexion à la base de données » (titre « Erreur de la base de données »). Si le dossier `wp-content/` contient un fichier `db-error.php`, c’est lui qui est affiché à la place.

Le script de réparation se trouve dans `wp-admin/maint/repair.php`. Il est volontairement inactif tant que la constante `WP_ALLOW_REPAIR` n’est pas définie à `true` dans `wp-config.php`. Une fois la constante activée, il exécute `CHECK TABLE` sur chaque table, puis `REPAIR TABLE` sur celles qui sont en défaut, et propose en option de les optimiser. Important : cette page **ne demande aucune connexion** ; il faut donc retirer la constante dès que vous avez terminé.

## Diagnostic rapide

| Symptôme / constat | Cause probable | À vérifier |
| --- | --- | --- |
| Le message apparaît après une coupure de courant, un redémarrage forcé ou un plantage du serveur | Table corrompue (surtout en MyISAM) | Journal d’erreurs de MySQL : « marked as crashed » |
| L’erreur survient pendant qu’un import ou une sauvegarde est en cours | Interruption, disque saturé | Espace disque (`df -h`), taille du dossier de la base |
| Le site redirige vers `wp-admin/install.php` | Aucune table trouvée : mauvais préfixe ou base vide | `$table_prefix` dans `wp-config.php`, liste des tables |
| Seuls certains écrans échouent, avec « Erreur de la base de données WordPress » et un nom de table | Table précise endommagée | Nom de la table dans le message ou `debug.log` |
| La page de réparation dit « The storage engine for the table doesn’t support repair » | Table InnoDB : `REPAIR TABLE` inapplicable | Moteur de la table (`SHOW TABLE STATUS`) |
| Le message revient après chaque réparation | Problème matériel, disque défaillant ou base trop grosse pour le serveur | Hébergeur, journal système, S.M.A.R.T. |

## Les causes les plus fréquentes

1. **Un arrêt brutal du serveur** (coupure électrique, redémarrage forcé, processus tué) qui interrompt une écriture ; les tables MyISAM sont les plus exposées.
2. **Un disque ou un quota saturé** : MySQL ne peut plus écrire et laisse des tables dans un état incohérent.
3. **Un plantage de MySQL ou de MariaDB**, souvent causé par un manque de mémoire.
4. **Un import ou une migration interrompus**, qui laissent une base à moitié restaurée.
5. **Un défaut du disque ou du système de fichiers**, plus rare mais à ne pas écarter si l’erreur se répète.
6. **Un mauvais préfixe de tables** après un déplacement : WordPress cherche des tables qui n’existent pas sous ce nom.

## Solutions pas à pas

**Sauvegardez d’abord.** Une réparation peut supprimer des lignes irrécupérables. Du moins invasif au plus technique :

### 1. Sauvegarder la base et vérifier les ressources

Exportez la base, depuis phpMyAdmin ou en ligne de commande. Même une base endommagée s’exporte souvent en grande partie :

```
mysqldump -u UTILISATEUR -p NOM_DE_LA_BASE > sauvegarde-avant-reparation.sql
df -h
```

La commande `df -h` vérifie qu’il reste de la place. Si l’export échoue sur une table précise, notez son nom. Si le serveur MySQL est inaccessible, voir la fiche [connexion à la base de données](https://www.wpmoderne.fr/erreurs-wordpress/erreur-connexion-base-de-donnees/). Sur un mutualisé, demandez à l’hébergeur une copie de la base si l’export échoue.

### 2. Réparer avec l’outil de WordPress

C’est la solution prévue par le cœur, utilisable sans WP-CLI ni phpMyAdmin. Ajoutez cette ligne à `wp-config.php`, au-dessus de « That’s all, stop editing! » :

```
define( 'WP_ALLOW_REPAIR', true );
```

Ouvrez ensuite `https://www.exemple.fr/wp-admin/maint/repair.php`. Cliquez sur « Réparer la base de données » (ou « Réparer et optimiser la base de données »). L’écran liste chaque table : « La table wp_options est correcte. » ou, en cas de problème, la tentative de réparation. En cas d’échec, il affiche « Impossible de réparer la table … » avec le message de MySQL. À la fin, WordPress vous demande de retirer la ligne de `wp-config.php` : **faites-le immédiatement**, car la page est accessible à tous tant que la constante existe.

### 3. Réparer avec WP-CLI

Si vous avez un accès SSH, les commandes suivantes fonctionnent même quand le site affiche l’erreur :

```
wp db check
wp db repair
wp db optimize
```

`wp db check` teste toutes les tables, `wp db repair` lance la réparation et `wp db optimize` les optimise. Relancez `wp db check` pour confirmer que tout est « OK ».

### 4. Réparer avec phpMyAdmin ou en SQL

Dans phpMyAdmin, ouvrez la base, cochez les tables en défaut (ou toutes), puis choisissez « Réparer la table » dans le menu « Avec la sélection ». En SQL, pour la table des options :

```
CHECK TABLE wp_options;
REPAIR TABLE wp_options;
```

En ligne de commande, `mysqlcheck -u UTILISATEUR -p --auto-repair --check NOM_DE_LA_BASE` traite toutes les tables d’un coup. Le détail d’un cas réel (table `wp_posts` marquée comme corrompue après une coupure) se trouve dans l’article [Table WordPress corrompue après une coupure serveur](https://www.wpmoderne.fr/hebergement/table-wordpress-corrompue-coupure-serveur-reparer/).

### 5. Cas des tables InnoDB

`REPAIR TABLE` ne s’applique pas aux tables InnoDB, le moteur par défaut des installations récentes. InnoDB sait se rétablir seul après un arrêt non propre ; si une table reste illisible, reconstruisez-la ou restaurez-la :

```
ALTER TABLE wp_options ENGINE=InnoDB;
```

Si le serveur refuse même de démarrer ou de lire la table, il faut passer par une restauration complète depuis une sauvegarde. Les administrateurs expérimentés peuvent aussi démarrer MySQL avec `innodb_force_recovery` (valeur 1 à 6 dans la section `[mysqld]` de `my.cnf`) pour exporter les données, puis recréer la base ; sur un hébergement partagé, confiez cette étape au support. Si vous utilisez encore MyISAM, envisagez la conversion décrite dans [Migrer une base WordPress de MyISAM vers InnoDB](https://www.wpmoderne.fr/hebergement/migrer-base-wordpress-myisam-innodb/).

### 6. Restaurer une sauvegarde

Si la réparation échoue ou si des données manquent, restaurez la dernière sauvegarde saine :

```
mysql -u UTILISATEUR -p NOM_DE_LA_BASE < sauvegarde-saine.sql
```

Importer écrase les tables existantes portant le même nom ; assurez-vous donc d’avoir mis de côté l’état actuel (étape 1). Un bon plan de reprise est décrit dans l’article sur les [sauvegardes et le plan de reprise](https://www.wpmoderne.fr/securite/sauvegardes-plan-de-reprise-wordpress/).

### Sans accès à l’administration

Les solutions 2, 3 et 4 n’exigent aucune connexion à WordPress : modification de `wp-config.php` par SFTP, SSH avec WP-CLI, ou phpMyAdmin depuis le panneau de l’hébergeur.

## Prévenir l’erreur

- **Automatisez les sauvegardes** de la base et testez régulièrement leur restauration.
- **Passez vos tables en InnoDB** : le moteur est transactionnel et supporte les arrêts brutaux.
- **Surveillez l’espace disque et la mémoire** du serveur, qui provoquent la plupart des corruptions.
- **Ne laissez pas `WP_ALLOW_REPAIR` activé** en dehors d’une réparation.
- **Évitez de couper un import** en cours, et travaillez sur une copie quand vous restaurez une grosse base.

## Questions fréquentes