Base de données WordPress : le guide complet en 2026

Si je vous demande ce qu’il y a dans la base de données de votre site WordPress, il y a de fortes chances que vous n’ayez jamais eu à vous poser la question.

Et c’est très bien ainsi, ce n’est pas votre métier.

Pourtant, cette base de données discrète, que vous ne voyez jamais, contient absolument tout ce qui fait vivre votre site, vos articles, vos pages, les informations de vos clients qui prennent rendez-vous en ligne, les réglages de chacune de vos extensions.

Dans cet article, je vous emmène sous le capot, avec des explications concrètes plutôt que du jargon, pour que vous compreniez enfin ce qui s’y passe réellement, comment y accéder si besoin, comment la protéger, et comment réagir si un jour quelque chose se dérègle.

L’essentiel à retenir

La base de données WordPress stocke tout le contenu de votre site, articles, pages, commentaires, réglages et comptes utilisateurs, répartis dans 12 tables natives identifiées par un préfixe, wp_ par défaut.
Les identifiants de connexion à votre base, nom, utilisateur, mot de passe et hôte, sont stockés dans le fichier wp-config.php, à la racine de votre installation.
Vous pouvez créer une base de données via l’installateur automatique de votre hébergeur comme Softaculous, manuellement depuis phpMyAdmin dans cPanel, ou en local avec un outil comme Local pour le développement.
L’accès quotidien à votre base se fait via phpMyAdmin, accessible depuis l’espace client de votre hébergeur, avec des parcours différents selon o2switch, Hostinger, OVHcloud ou IONOS ou un autre quelconque hébergeur.
Pour sauvegarder votre base, la fréquence doit être adaptée à l’activité réelle du site, avec un stockage hors du serveur d’hébergement, une exigence RGPD, via une extension comme UpdraftPlus ou BackWPup.
Pour importer une base de données, UpdraftPlus reste l’option gratuite la plus complète, avec une option de recherche et remplacement de domaine intégrée dès sa version gratuite.
Optimiser et nettoyer régulièrement sa base passe par la commande OPTIMIZE TABLE et la suppression des révisions d’articles, de loin le poste le plus lourd sur la grande majorité des sites.
Les meilleurs plugins pour gérer une base de données WordPress se répartissent en deux familles, la sauvegarde et la migration d’un côté, avec UpdraftPlus, BackWPup et Duplicator, le nettoyage et l’optimisation de l’autre, avec WP-Optimize, Advanced Database Cleaner, WP Rocket et FlyingPress.
L’erreur la plus fréquente, « Error establishing a database connection« , vient presque toujours d’un identifiant ou d’un mot de passe incorrects dans wp-config.php, à vérifier avant toute autre manipulation.

Testez votre niveau de sérénité face à votre base de données

Qu’est-ce qu’une base de données WordPress ?

Avant de parler de WordPress, revenons à la base, sans mauvais jeu de mots.

Une base de données, dans l’absolu, c’est simplement une façon organisée de stocker de l’information pour la retrouver rapidement, un peu comme un immense classeur numérique rangé par tiroirs plutôt qu’un tas de feuilles volantes.

Le dictionnaire Larousse parle d’« un ensemble structuré et organisé de données », rassemblées pour être consultées par des utilisateurs ou par des programmes.

On en retrouve dans la quasi-totalité des logiciels que vous utilisez au quotidien.

WordPress ne fait pas exception. Une base de données WordPress, c’est l’endroit où vit tout le contenu réel de votre site, pas les fichiers du thème, pas le code des extensions, mais la matière vivante et structurée qui fait tourner votre installation.

Ce que WordPress y stocke réellement

WordPress s’appuie pour cela sur un système appelé MySQL, un gestionnaire de bases de données, autrement dit un logiciel spécialisé dans le stockage et la recherche d’informations.

La documentation officielle de WordPress.org le confirme, le cœur du logiciel s’appuie sur MySQL pour stocker l’ensemble du contenu, et sur le langage PHP pour interroger cette base et construire les pages affichées à vos visiteurs.

Concrètement, votre base de données WordPress contient :

vos articles ;
vos pages ;
les révisions de vos contenus ;
les commentaires de vos visiteurs ;
les réglages de votre installation y compris ceux des extensions ;
les informations de vos utilisateurs ;
une multitude d’options qui définissent le comportement de votre site, l’adresse de votre page d’accueil, le nom de votre activité, ou encore l’adresse email de contact.

Les identifiants de connexion à cette base, le nom de la base, l’utilisateur autorisé, le mot de passe et l’adresse du serveur qui l’héberge, sont conservés dans un fichier à part appelé wp-config.php.

Ces informations sont sensibles, c’est aussi une question de sécurité, retenez ce nom de fichier, on y reviendra plus loin dans cet article, notamment quand on parlera des erreurs de connexion.

Vous l’aurez compris, si cette base de données venait à disparaître, à la suite d’un piratage ou d’un problème chez votre hébergeur par exemple, vous perdriez la totalité du contenu de votre site.

Pas seulement quelques réglages, mais vraiment tout. C’est justement pour cette raison que la sauvegarde régulière de cette base, dont on parlera en détail plus loin, n’est jamais une option facultative pour moi.

Pourquoi la manipuler avec prudence

Une base de données n’est pas un simple document que vous pouvez modifier et annuler d’un clic si quelque chose se passe mal.

C’est un ensemble de tables reliées entre elles, dont on détaillera la structure un peu plus loin dans cet article, où chaque information a sa place précise et où certaines dépendent directement d’autres.

Toucher à l’une peut avoir des répercussions sur les autres, sans que ce soit toujours immédiatement visible.

Une mauvaise manipulation du fichier wp-config.php ou d’une table de la base peut avoir deux conséquences bien différentes.

Premier cas de figure, votre site devient totalement inaccessible, plus rien ne s’affiche pour vos visiteurs.

Second cas de figure, souvent plus insidieux, le site reste en ligne mais affiche des dysfonctionnements par endroits, ce qui dégrade autant l’expérience de vos visiteurs que l’image renvoyée par votre activité.

Il me semble essentiel de souligner ce point avant d’aller plus loin, tout ce que je vais vous montrer dans cet article reste accessible, mais rien ne remplace la prudence, une sauvegarde avant chaque intervention, et l’accompagnement de quelqu’un qui connaît bien ce terrain si le doute persiste.

Pourquoi une erreur y est parfois difficile à repérer

D’expérience, manipuler une base de données directement demande une concentration de tous les instants.

Contrairement à une erreur visible sur le front end, c’est à dire la partie visible de votre site que voient vos visiteurs, une erreur commise dans la base de données ne saute pas toujours aux yeux immédiatement.

Si vous n’avez pas consciemment vu l’endroit exact où la manipulation a dérapé, il devient parfois très difficile de remonter jusqu’à la source du problème.

La structure de la base de données WordPress, les tables et leur rôle

Maintenant que vous savez ce que contient votre base de données, entrons un peu plus dans le détail de son organisation.

Une base de données WordPress n’est pas un grand fourre-tout, elle est rangée en tables, un peu comme un meuble de rangement composé de plusieurs tiroirs, chaque tiroir étant dédié à un type précis d’information.

Les tables natives de WordPress, une par une

Par défaut, à la sortie de son installation, une base de données WordPress compte douze tables. Voici d’abord une vue d’ensemble, puis le détail complet de chacune.

Table	Ce qu’elle contient
wp_posts En savoir plus	Vos articles, vos pages, et tous vos types de contenus personnalisés
wp_postmeta En savoir plus	Les métadonnées de ces publications, c’est à dire les informations complémentaires qui leur sont rattachées, comme les champs personnalisés
wp_comments En savoir plus	Les commentaires laissés par vos visiteurs
wp_commentmeta En savoir plus	Les métadonnées de ces commentaires, l’auteur, son email, l’heure de publication
wp_options En savoir plus	Les réglages globaux de votre site, l’adresse de votre page d’accueil, le nom de votre activité, et bien d’autres options
wp_users En savoir plus	Les comptes utilisateurs de votre site, avec leur identifiant et leur rôle
wp_usermeta En savoir plus	Les métadonnées liées à ces utilisateurs
wp_terms En savoir plus	Vos catégories, vos étiquettes, et toute autre taxonomie
wp_term_taxonomy En savoir plus	Le type de taxonomie associé à chaque terme
wp_term_relationships En savoir plus	Le lien entre vos publications et ces catégories ou étiquettes
wp_termmeta En savoir plus	Les métadonnées complémentaires de ces termes
wp_links En savoir plus	Une table héritée d’une ancienne fonctionnalité de liens, aujourd’hui quasiment inutilisée

Schéma entité-relation des douze tables natives de la base de données WordPress, organisées en cinq groupes fonctionnels, contenu autour de wp_posts, taxonomie, commentaires, utilisateurs et réglages du site, avec les relations entre chaque table. — *Vue d’ensemble des douze tables natives de WordPress et de leurs relations.*

Sachez aussi que ces douze tables ne sont pas figées. Certaines extensions volumineuses, comme WooCommerce si vous vendez en ligne, créent leurs propres tables en plus de celles-ci pour stocker leurs données spécifiques, les commandes ou les produits par exemple. C’est une des raisons pour lesquelles votre base de données grossit avec le nombre d’extensions installées.

Petite précision pour les cas particuliers, si votre site fonctionne en réseau multisite, c’est à dire une seule installation WordPress qui gère plusieurs sites à la fois, sachez que la plupart de ces tables sont dupliquées pour chaque site du réseau.

Passons maintenant en revue chacune de ces douze tables en détail, pour que vous compreniez précisément ce qu’elle contient et à quoi correspond chaque colonne que vous pourriez voir si vous alliez y jeter un œil vous même.

wp_posts : c’est la table centrale de votre base de données, celle dont dépendent presque toutes les autres.

Elle contient bien plus que vos articles de blog, elle héberge aussi vos pages, vos brouillons, vos révisions, les éléments de votre menu de navigation, vos fichiers médias téléversés dans la médiathèque, et tout type de contenu personnalisé que vos extensions pourraient créer, comme vos produits si vous vendez en ligne avec WooCommerce.

Ce qui différencie ces différents usages d’une même table, c’est la colonne « post_type », elle indique si la ligne concernée est un article, une page, une pièce jointe, un élément de menu, ou un autre type de contenu.

Capture d'écran de la table wp_posts dans phpMyAdmin, montrant plusieurs pages publiées d'un site WordPress, mentions légales, politique de confidentialité, contact et accueil, avec leur statut de publication et l'état de leurs commentaires. — *Aperçu de la table wp_posts dans phpMyAdmin, avec plusieurs pages du site affichées.*

Colonne	Ce qu’elle signifie concrètement
ID	Identifiant unique de la publication
post_author	Identifiant de l’auteur, en lien avec wp_users
post_date / post_date_gmt	Date de publication, en heure locale puis en heure universelle
post_content	Le contenu complet de la publication
post_title	Le titre
post_excerpt	Le résumé ou extrait, s’il existe
post_status	L’état, publié, brouillon, en attente, ou dans la corbeille
comment_status	Indique si les commentaires sont ouverts ou fermés sur cette publication
ping_status	Indique si les pings et rétroliens, des notifications automatiques entre sites, sont acceptés
post_password	Le mot de passe si la publication est protégée, laissé vide sinon
post_name	Le slug, c’est à dire la partie de l’URL propre à cette publication
to_ping / pinged	Les adresses que WordPress doit notifier ou a déjà notifiées, une fonctionnalité aujourd’hui peu utilisée
post_modified / post_modified_gmt	Date de la dernière modification, en heure locale puis universelle
post_content_filtered	Une colonne héritée, plus utilisée par le cœur de WordPress aujourd’hui
post_parent	Identifiant de la publication parente, utile pour une page enfant ou une pièce jointe
guid	Un identifiant global stable, pas un lien cliquable malgré son apparence d’URL. Ne l’utilisez jamais comme lien vers votre page, elle ne sert qu’à identifier la publication dans les flux
menu_order	L’ordre d’affichage, utilisé notamment pour les pages triables manuellement
post_type	Le type de contenu, article, page, pièce jointe, ou type personnalisé
post_mime_type	Le type de fichier pour les pièces jointes, une image ou un PDF par exemple
comment_count	Le nombre de commentaires approuvés

wp_postmeta : elle accompagne wp_posts pour stocker des informations complémentaires sur chaque publication, ce qu’on appelle des métadonnées.

C’est ici, par exemple, que sont stockés les champs personnalisés que vous ajoutez à un article, ou les informations techniques qu’une extension attache à une publication sans avoir besoin de créer sa propre table.

IMPORTANT : cette table suit une structure qu’on retrouve à l’identique dans trois autres tables de cet article, « wp_commentmeta », « wp_usermeta » et « wp_termmeta ».

Je vous l’explique donc une bonne fois pour toutes ici, plutôt que de la répéter à chaque fois.

Le principe est celui d’une fiche à quatre colonnes, un identifiant unique pour la ligne, l’identifiant de l’élément auquel se rattache cette information, une clé qui nomme l’information, et une valeur qui la contient.

Une même publication peut avoir autant de lignes de métadonnées que nécessaire, une ligne par information stockée.

Point important à connaître si vous ouvrez cette table vous même, « meta_value » contient parfois du PHP sérialisé, pas du JSON.

WordPress exécute la fonction serialize() sur tout tableau ou objet avant de l’écrire dans cette colonne.

Si vous ouvrez une ligne qui contient une valeur complexe, vous verrez un bloc de texte impossible à interpréter avec un simple lecteur JSON, il faut le désérialiser avec PHP pour le comprendre.

Capture d'écran de la table wp_postmeta dans phpMyAdmin, montrant des lignes de métadonnées techniques comme _edit_lock, _edit_last et _kt_rc_carousel_columns, rattachées à différentes publications par leur post_id. — *Aperçu de la table wp_postmeta dans phpMyAdmin, avec plusieurs métadonnées techniques rattachées à des publications.*

Colonne	Ce qu’elle signifie concrètement
meta_id	Identifiant unique de la ligne de métadonnée
post_id	Identifiant de la publication concernée, en lien avec wp_posts
meta_key	Le nom de l’information stockée
meta_value	La valeur de cette information, parfois sous forme de donnée sérialisée comme expliqué plus haut

wp_comments : elle contient tous les commentaires laissés sur votre site, qu’ils proviennent de vos articles ou de vos pages si vous y avez autorisé les commentaires.

Chaque ligne représente un commentaire unique, avec son auteur, son contenu, et son état de modération.

Capture d'écran de la table wp_comments dans phpMyAdmin, montrant plusieurs commentaires laissés sur un article de test, avec les colonnes comment_author, comment_author_email, comment_author_url et comment_author_IP volontairement masquées pour protéger les données personnelles. — *Aperçu de la table wp_comments dans phpMyAdmin, avec les données personnelles des auteurs masquées.*

Colonne	Ce qu’elle signifie concrètement
comment_ID	Identifiant unique du commentaire
comment_post_ID	Identifiant de la publication commentée, en lien avec wp_posts
comment_author	Le nom saisi par la personne qui commente
comment_author_email	L’adresse email saisie
comment_author_url	Le site web saisi par la personne, s’il y en a un
comment_author_IP	L’adresse IP utilisée au moment du commentaire
comment_date / comment_date_gmt	La date du commentaire, en heure locale puis universelle
comment_content	Le texte du commentaire
comment_karma	Une colonne héritée d’un ancien système de notation, non utilisée par le cœur de WordPress aujourd’hui
comment_approved	L’état de modération, approuvé, en attente, ou marqué comme indésirable
comment_agent	Le navigateur utilisé pour poster le commentaire
comment_type	Le type, un commentaire classique, ou une notification automatique comme un rétrolien
comment_parent	Identifiant du commentaire auquel celui-ci répond, s’il s’agit d’une réponse
user_id	Identifiant de l’utilisateur connecté qui a commenté, si la personne était identifiée, sinon la valeur reste à zéro

wp_commentmeta : elle suit exactement le même principe que wp_postmeta, expliqué plus haut, un identifiant, un rattachement au commentaire concerné, une clé et une valeur.

Je ne reviens pas sur le fonctionnement général, mais un mot sur ce qu’on y trouve concrètement, des informations complémentaires que des extensions de modération ou anti-spam viennent y ajouter, en plus de ce que contient déjà wp_comments.

Capture d'écran de la table wp_commentmeta dans phpMyAdmin, montrant des métadonnées ajoutées par une extension d'avis clients, une note et un statut de vérification, rattachées à plusieurs commentaires par leur comment_id. — *Aperçu de la table wp_commentmeta dans phpMyAdmin, avec des métadonnées ajoutées par une extension d’avis.*

Colonne	Ce qu’elle signifie concrètement
meta_id	Identifiant unique de la ligne de métadonnée
comment_id	Identifiant du commentaire concerné, en lien avec wp_comments
meta_key	Le nom de l’information stockée
meta_value	La valeur de cette information

wp_users : elle contient la liste de tous les comptes utilisateurs de votre site, que ce soit vous en tant qu’administrateur, un membre de votre équipe, ou un client qui a créé un compte pour prendre rendez-vous en ligne ou passer une commande sur votre boutique. Chaque ligne représente une personne.

Capture d'écran de la table wp_users dans phpMyAdmin, avec les colonnes user_login, user_pass, user_nicename et user_email annotées par des flèches expliquant leur fonction, ces données étant volontairement masquées pour protéger les informations de connexion. — *Aperçu de la table wp_users dans phpMyAdmin, avec les colonnes sensibles masquées et expliquées.*

À SAVOIR : une chose surprend souvent quand on découvre cette table pour la première fois, le rôle de l’utilisateur, administrateur, éditeur, abonné, n’y figure pas.

Vous ne trouverez aucune colonne « role » ici.

Cette information est stockée ailleurs, dans wp_usermeta, la table suivante, ce qui explique pourquoi les deux fonctionnent toujours en binôme.

Colonne	Ce qu’elle signifie concrètement
ID	Identifiant unique de l’utilisateur
user_login	Le nom utilisé pour se connecter
user_pass	Le mot de passe, jamais stocké en clair mais sous forme chiffrée
user_nicename	Une version simplifiée du nom, utilisée notamment dans certaines URL
user_email	L’adresse email associée au compte
user_url	Le site web renseigné dans le profil, s’il y en a un
user_registered	La date de création du compte
user_activation_key	Une clé technique temporaire, utilisée par exemple lors d’une réinitialisation de mot de passe
user_status	Une colonne héritée, non utilisée par le cœur de WordPress aujourd’hui
display_name	Le nom affiché publiquement, par exemple comme auteur d’un article

wp_usermeta : elle reprend elle aussi la structure des tables meta déjà expliquée, avec une petite particularité que je vous ai déjà signalée plus haut dans cet article, sa colonne d’identifiant s’appelle umeta_id, et non meta_id comme dans les trois autres tables du même type.

C’est justement ici que se cache le rôle de chaque utilisateur qu’on ne trouvait pas dans wp_users.

Il est stocké sous la clé wp_capabilities, sous la forme d’une donnée sérialisée, ce format PHP dont je vous ai parlé au sujet de wp_postmeta.

La liste complète de ce que chaque rôle a le droit de faire, elle, ne se trouve pas ici mais dans wp_options, sous la forme d’une option nommée wp_user_roles, valable pour tout le site.

Capture d'écran de la table wp_usermeta dans phpMyAdmin, montrant les métadonnées d'un compte administrateur, surnom, prénom, nom, et plusieurs préférences d'affichage de l'interface d'administration. — *Aperçu de la table wp_usermeta dans phpMyAdmin, avec les métadonnées d’un compte utilisateur.*

Colonne	Ce qu’elle signifie concrètement
umeta_id	Identifiant unique de la ligne de métadonnée
user_id	Identifiant de l’utilisateur concerné, en lien avec wp_users
meta_key	Le nom de l’information stockée, par exemple wp_capabilities pour le rôle
meta_value	La valeur de cette information

wp_terms : elle contient les termes que vous utilisez pour classer votre contenu, vos catégories, vos étiquettes, ou toute taxonomie personnalisée qu’une extension aurait pu créer.

Chaque ligne représente un terme unique, indépendamment de l’endroit où il est utilisé.

À SAVOIR : cette table ne dit à elle seule ni à quoi sert le terme, catégorie ou étiquette par exemple, ni à quelles publications il est rattaché.

Ces deux informations vivent dans les deux tables suivantes, ce qui explique pourquoi ces trois tables fonctionnent toujours ensemble.

Capture d'écran de la table wp_terms dans phpMyAdmin, montrant plusieurs termes utilisés sur un site WordPress, une catégorie par défaut, le nom du thème actif, des emplacements de menu, et des types de produits WooCommerce. — *Aperçu de la table wp_terms dans phpMyAdmin, avec plusieurs termes utilisés sur le site.*

Colonne	Ce qu’elle signifie concrètement
term_id	Identifiant unique du terme
name	Le nom affiché du terme, par exemple « Coloration » si c’est une catégorie
slug	La version simplifiée du nom, utilisée dans l’URL
term_group	Une colonne héritée, rarement utilisée aujourd’hui

wp_term_taxonomy : elle précise à quel type de classement appartient chaque terme de la table précédente.

Un même mot pourrait en théorie exister à la fois comme catégorie et comme étiquette, c’est cette table qui lève l’ambiguïté et qui donne son sens réel au terme.

Capture d'écran de la table wp_term_taxonomy dans phpMyAdmin, montrant à quelle taxonomie appartient chaque terme, catégorie, thème, emplacement de menu ou type de produit, ainsi que le nombre de publications rattachées à chacun. — *Aperçu de la table wp_term_taxonomy dans phpMyAdmin, avec le type de taxonomie de chaque terme.*

Colonne	Ce qu’elle signifie concrètement
term_taxonomy_id	Identifiant unique de cette association terme et taxonomie
term_id	Le terme concerné, en lien avec wp_terms
taxonomy	Le type de classement, catégorie, étiquette, ou une taxonomie personnalisée
description	Une description facultative du terme dans ce contexte précis
parent	Le terme parent, si vos catégories sont organisées en sous-catégories
count	Le nombre de publications actuellement rattachées à ce terme

wp_term_relationships: elle fait le lien concret entre vos publications et les termes qui leur sont attribués. C’est cette table qui répond à la question, quelles catégories ou étiquettes sont cochées sur tel article précis.

Capture d'écran de la table wp_term_relationships dans phpMyAdmin, montrant les liens entre plusieurs publications et les termes de taxonomie qui leur sont associés. — *Aperçu de la table wp_term_relationships dans phpMyAdmin, avec les liens entre publications et termes.*

Colonne	Ce qu’elle signifie concrètement
object_id	Identifiant de la publication concernée, en lien avec wp_posts
term_taxonomy_id	L’association terme et taxonomie concernée, en lien avec wp_term_taxonomy
term_order	L’ordre d’affichage, rarement utilisé en dehors de certains cas particuliers

wp_termmeta: elle suit la même structure que les autres tables meta déjà vues, avec cette fois des informations complémentaires rattachées à un terme plutôt qu’à une publication, un commentaire, ou un utilisateur.

C’est ici, par exemple, qu’une extension pourrait stocker une image de mise en avant propre à une catégorie.

Capture d'écran de la table wp_termmeta dans phpMyAdmin, montrant des métadonnées techniques rattachées à plusieurs termes, comme une image associée à une catégorie ou un nombre de produits. — *Aperçu de la table wp_termmeta dans phpMyAdmin, avec des métadonnées techniques rattachées à des termes.*

Colonne	Ce qu’elle signifie concrètement
meta_id	Identifiant unique de la ligne de métadonnée
term_id	Le terme concerné, en lien avec wp_terms
meta_key	Le nom de l’information stockée
meta_value	La valeur de cette information

wp_options : c’est en quelque sorte le tableau de bord central de votre site, celui où WordPress range tous les réglages qui s’appliquent à l’ensemble de votre installation, pas à une publication ou un utilisateur en particulier.

L’adresse de votre site, son titre, l’email de l’administrateur, la liste des extensions actives, les réglages de votre thème, tout ça y passe.

Vous vous souvenez peut-être de wp_user_roles, évoquée plus haut au sujet des rôles utilisateurs, c’est justement une option parmi tant d’autres stockée ici, valable pour tout le site.

À SAVOIR : un détail technique mérite d’être connu, la colonne autoload.

Certaines options sont chargées automatiquement en mémoire à chaque fois qu’une page de votre site est consultée, pour que WordPress y accède instantanément sans avoir à les rechercher à chaque fois.

C’est utile pour les réglages essentiels, mais avec le temps, des extensions désinstallées laissent parfois derrière elles des options devenues inutiles, encore marquées pour ce chargement automatique.

J’y reviens avec des pistes concrètes un peu plus loin dans cet article, dans la partie sur les autres facteurs qui influencent la performance de votre site.

Capture d'écran de la table wp_options dans phpMyAdmin, montrant plusieurs réglages généraux d'un site WordPress, le nom et la description du site, les préférences de commentaires et de flux RSS, avec les colonnes siteurl, home et admin_email volontairement masquées pour protéger les données sensibles. — *Aperçu de la table wp_options dans phpMyAdmin, avec les données sensibles masquées.*

Colonne	Ce qu’elle signifie concrètement
option_id	Identifiant unique de l’option
option_name	Le nom de l’option, par exemple siteurl ou blogname
option_value	La valeur de cette option, parfois sous forme de donnée sérialisée comme pour les tables meta déjà vues
autoload	Indique si cette option doit être chargée automatiquement à chaque page, ou seulement à la demande

wp_links : c’est un peu la table fantôme de cette liste.

Elle stockait autrefois les liens d’une fonctionnalité appelée « blogroll », une liste de sites recommandés qui s’affichait dans la barre latérale des blogs à l’époque où WordPress ressemblait davantage à un journal personnel qu’à un site professionnel.

À SAVOIR : cette fonctionnalité a été retirée de l’interface depuis WordPress 3.5, mais la table, elle, continue d’être créée par défaut sur chaque nouvelle installation, par souci de compatibilité, au cas où une extension viendrait la réactiver.

Dans l’immense majorité des cas, cette table reste vide et n’a aucune utilité.

Je la mentionne uniquement par souci d’exhaustivité, pour que vous ne soyez pas surpris de la voir apparaître si vous ouvrez votre base de données un jour.

Colonne	Ce qu’elle signifie concrètement
link_id	Identifiant unique du lien
link_url	L’adresse du site recommandé
link_name	Le nom affiché du lien
link_image	Une image associée, si elle existait
link_target	La façon dont le lien s’ouvrait, dans le même onglet ou dans un nouveau
link_description	Une description facultative
link_visible	Indique si le lien était visible ou masqué
link_owner	L’utilisateur ayant créé le lien, en lien avec wp_users
link_rating	Une note attribuée au lien, fonctionnalité aujourd’hui obsolète
link_updated	La date de dernière modification
link_rel	Un attribut technique pour les moteurs de recherche
link_notes	Des notes internes facultatives
link_rss	L’adresse d’un flux RSS associé, si elle existait

Le préfixe des tables, un point de sécurité à connaître

Vous l’avez sans doute remarqué en parcourant les douze tables précédentes, elles commencent toutes par le même préfixe, wp_.

C’est le préfixe par défaut de toute installation WordPress, et c’est justement ce qui pose un problème.

Ce même préfixe, identique sur des millions de sites, facilite la tâche des attaques automatisées qui tentent des injections SQL, une méthode d’attaque qui vise justement les tables portant ce nom par défaut.

Je vous en dis davantage un peu plus loin dans cet article, au sujet du fichier wp-config.php qui le définit, et je détaille la marche à suivre pour le changer cet article dédié à ce sujet.

Les fichiers et dossiers essentiels qui pilotent votre base de données WordPress

Avant de passer aux manipulations concrètes, un dernier détour s’impose.

Un fichier et un dossier, quelque part dans les entrailles de votre hébergement, jouent un rôle central dans le dialogue entre WordPress et votre base de données.

Les connaître ne vous rendra pas spécialiste du sujet, mais ça vous aidera à comprendre pourquoi certaines erreurs surviennent, et surtout où aller chercher si un jour vous en avez besoin.

wp-config.php, le fichier qui établit la connexion

wp-config.php est un fichier PHP situé à la racine de votre installation WordPress, celui qui contient les informations dont votre site a besoin pour se connecter à sa base de données à chaque chargement de page.

Concrètement, il définit des constantes, des valeurs fixes que WordPress va lire au démarrage, le nom de la base de données, l’utilisateur autorisé à y accéder, son mot de passe, et l’adresse du serveur qui l’héberge.

C’est aussi dans ce fichier qu’est défini le préfixe de vos tables, dont je vous ai parlé plus haut, et sur lequel je reviens en détail dans un article dédié.

Vous pouvez consulter ce fichier en vous connectant à votre hébergement, via le gestionnaire de fichiers de votre cPanel ou par FTP, il se trouve à la racine, au même niveau que les dossiers wp-admin, wp-includes et wp-content.

Attention cependant, ce fichier n’a rien à voir avec phpMyAdmin, dont on reparlera plus loin pour accéder au contenu de votre base, wp-config.php ne sert qu’à stocker les identifiants de connexion, pas à consulter vos données.

Il me semble essentiel de souligner un point de sécurité ici, ce fichier ne doit jamais être partagé ni affiché publiquement, une capture d’écran de son contenu réel équivaut à distribuer les clés de votre base de données à qui saurait les lire.

Capture d'écran du coeur de WordPress, aussi appelé "core" en anglais, dans lequel on aperçoit les fichiers essentiels au fonctionnement de WordPress dont le fichier wp-config.php. — *Le coeur de WordPress (Core), et le fichier wp-config.php*

Capture d'écran annotée du fichier wp-config.php de WordPress montrant les paramètres de connexion à la base de données : DB_NAME, DB_USER, DB_PASSWORD, DB_HOST, DB_CHARSET et DB_COLLATE. — Les principales constantes du fichier wp-config.php permettant à WordPress de se connecter à la base de données MySQL : nom de la base, identifiant, mot de passe, serveur, jeu de caractères et règles de tri des caractères.

wp-includes, le pont technique entre WordPress et MySQL

WordPress ne dialogue généralement pas directement avec MySQL. Il passe par une classe de code PHP appelée « wpdb », qui fournit un ensemble de méthodes permettant à WordPress d’envoyer des requêtes SQL à la base de données et d’en récupérer les résultats.

Ce code vit dans wp-includes, qui n’est pas un fichier mais un dossier, et un gros dossier qui plus est, plus d’une centaine de fichiers rien qu’à sa racine, plus d’un millier une fois tous ses sous dossiers comptés.

C’est littéralement là que réside la majorité du code source de WordPress lui même.

Vue du contenu du dossier wp-includes de WordPress affichant ses nombreux sous-dossiers et fichiers internes. — *Le dossier wp-includes contient une grande partie du code source de WordPress.*

Attention : contrairement à wp-config.php, que vous pouvez légitimement consulter en cas de souci de connexion, wp-includes ne doit jamais être modifié.

C’est le cœur technique de WordPress, réservé aux spécialistes qui interviennent directement sur le code source du logiciel, pas un endroit où un propriétaire de site a quoi que ce soit à faire.

Retenez simplement son existence et son ampleur, ça vous aidera à comprendre pourquoi une mise à jour de WordPress touche justement ce dossier, et pourquoi on ne le modifie jamais à la main.

Créer une base de données WordPress, les différentes méthodes

Maintenant que vous savez ce que contient une base de données et comment elle est organisée, voyons comment on en crée une.

Il existe plusieurs façons de procéder, selon votre situation, et bonne nouvelle, la plus courante ne demande aucune manipulation technique de votre part.

Avec l’installateur en un clic de votre hébergeur (Softaculous ou équivalent)

C’est la méthode que vous utiliserez presque toujours, sans même vous en rendre compte.

La plupart des hébergeurs proposent un installateur en un clic pour WordPress, Softaculous étant le plus répandu, accessible depuis votre cPanel.

La marche à suivre :

Repérez l’icône WordPress parmi la liste des scripts disponibles

Liste des scripts disponibles dans Softaculous sur cPanel, avec l'icône WordPress mise en évidence par une flèche parmi Joomla, phpBB, WHMCS et les autres applications proposées. — *L’icône WordPress dans la liste des scripts Softaculous, accessible depuis votre cPanel.*

Renseignez l’URL d’installation, choisissez la version souhaitée, puis cliquez sur « Installer »

Écran de configuration de l'installateur WordPress dans Softaculous, avec les champs pour choisir l'URL d'installation, la version à installer, et le bouton Installation rapide. — *L’écran de configuration de Softaculous avant de lancer l’installation de WordPress.*

L’installateur se charge de tout le reste en coulisses, y compris la création de la base de données, avec un nom, un utilisateur et un mot de passe générés automatiquement.

Vous n’avez jamais besoin de créer la base vous même dans ce cas de figure.

C’est d’ailleurs pour cette raison que beaucoup de propriétaires de site n’ont jamais eu l’occasion de se demander ce qu’était une base de données avant de lire cet article.

Manuellement via phpMyAdmin depuis cPanel

Il existe des situations où créer la base à la main devient nécessaire, avant une migration, pour préparer un espace de travail avant l’installation de WordPress, ou si votre hébergeur ne propose pas d’installateur en un clic.

Dans votre cPanel, la section « Bases de données » rassemble tous les outils dont vous aurez besoin :

Section Bases de données du cPanel, avec les icônes phpMyAdmin, Bases de données MySQL, Assistant de base de données MySQL, MySQL distant, et leurs équivalents PostgreSQL. — *La section Bases de données de cPanel, point de départ pour créer une base manuellement.*

Première étape, créer la base elle même. Depuis l’outil Bases de données MySQL, il vous suffit de lui donner un nom et de cliquer sur Créer une base de données. Rien d’autre n’est demandé à ce stade.

Formulaire de création d'une base de données MySQL dans cPanel, avec le champ pour saisir le nom de la nouvelle base et le bouton Créer une base de données. — *Le formulaire de création d’une base de données MySQL sur cPanel.*

Une fois cette étape terminée, votre base est créée mais vide, sans aucune table à l’intérieur :

Interface phpMyAdmin affichant une base de données nouvellement créée, sans aucune table, avec le message "Aucune table n'a été trouvée dans cette base de données" et le formulaire pour créer une nouvelle table. — *Une base de données fraîchement créée, encore vide, dans phpMyAdmin.*

Seconde étape, uniquement si une application doit se connecter à cette base.

Consulter votre base depuis phpMyAdmin ne demande jamais cette étape, votre session cPanel suffit.

Elle devient en revanche indispensable quand vous voulez connecter WordPress ou toute autre application à cette base, car celle-ci a besoin de ses propres identifiants, indépendants de votre connexion cPanel.

Une base de données ne s’ouvre jamais sans identifiants pour une application extérieure, il faut donc :

Créer un utilisateur, avec son propre mot de passe, dans la section Utilisateurs MySQL
Relier cet utilisateur à votre base, via la section Ajouter un utilisateur à la base de données, en sélectionnant les deux dans les menus déroulants

Formulaire de création d'un utilisateur MySQL dans cPanel, avec les champs nom d'utilisateur et mot de passe, un indicateur de niveau de sécurité, et la section pour rattacher cet utilisateur à une base de données. — *Création d’un utilisateur MySQL et rattachement à la base de données.*

Petit aparté en passant devant cette capture, l’indicateur de niveau de sécurité du mot de passe est un bon rappel visuel de ce qu’on évoque dans la section suivante sur l’accès à votre base, un mot de passe robuste n’est jamais optionnel, même pour un compte technique que vous ne saisissez presque jamais à la main.

Une fois ces deux éléments reliés, un dernier écran s’ouvre automatiquement pour vous demander d’accorder les privilèges, autrement dit le droit pour cet utilisateur de lire et d’écrire des données dans la base. Pour un usage WordPress classique, cochez simplement Tous les privilèges, puis validez.

Votre base et son utilisateur sont maintenant prêts. Il faudra ensuite soit y importer un fichier de sauvegarde existant, on y reviendra plus loin dans cet article, soit renseigner ces mêmes identifiants dans le fichier wp-config.php, dont on a parlé plus haut, au moment d’installer WordPress manuellement dessus.

En local, pour du développement ou du test

Dernier cas de figure, vous voulez travailler sur un site sans le publier en ligne, pour tester une extension, préparer une refonte en toute tranquillité, ou comme je le fais moi même pour préparer les captures d’écran de cet article.

On appelle ça travailler en local, c’est à dire directement sur votre ordinateur plutôt que sur un serveur d’hébergement.

L’outil le plus simple pour ça s’appelle Local, anciennement connu sous le nom de Local by Flywheel. Il installe pour vous un environnement complet, serveur, PHP et base de données MySQL compris, en quelques clics, sans aucune ligne de commande à taper.

Interface du logiciel Local pour WordPress, montrant un site de test avec ses informations, domaine local, certificat SSL, serveur web, version PHP, et base de données MySQL déjà configurée automatiquement. — *L’interface de Local, avec la base de données MySQL configurée automatiquement pour un site de test.*

Comme vous pouvez le voir sur cette interface, la base de données apparaît déjà renseignée, MySQL 8.0.35 dans cet exemple, sans qu’aucune manipulation n’ait été nécessaire de mon côté. La création est entièrement automatisée.

Je consacre un article complet à l’utilisation de Local pour créer un site WordPress en local, où je détaille son installation pas à pas.

Il existe aussi des solutions plus techniques comme MAMP ou WAMP, qui demandent ensuite de créer la base manuellement via phpMyAdmin, sur le même principe que la méthode cPanel vue juste au-dessus.

Je vous les mentionne pour être complet, mais pour la grande majorité des cas d’usage, Local reste largement suffisant et bien plus simple à prendre en main.

Accéder à votre base de données et la modifier au quotidien

Une fois votre base de données créée, reste à savoir comment y accéder concrètement quand le besoin se présente, pour une vérification ponctuelle ou une intervention plus poussée.

La bonne nouvelle, c’est que vous n’avez besoin d’aucun logiciel à installer, tout se passe depuis l’interface de votre hébergeur, via phpMyAdmin, l’outil qu’on a déjà croisé un peu plus haut dans cet article.

Depuis l’interface de votre hébergeur, l’exemple de cPanel chez o2switch

cPanel est l’un des panneaux d’administration les plus répandus chez les hébergeurs, o2switch en fait partie. Pour accéder à votre base de données :

Connectez-vous à votre cPanel
Rendez-vous dans la section Bases de données
Cliquez sur l’icône phpMyAdmin

Section Bases de données du cPanel o2switch avec l'icône phpMyAdmin mise en évidence pour accéder à la base de données WordPress. — *Depuis la section Bases de données de votre cPanel, l’icône phpMyAdmin vous donne un accès direct à votre base de données WordPress.*

Une fois sur l’interface de phpMyAdmin, un menu arborescent affiche la liste des tables de votre base sur la gauche.

En cliquant sur l’onglet « Structure », vous retrouvez le détail complet de chacune d’elles, exactement les douze tables natives qu’on a détaillées un peu plus haut dans cet article.

Interface phpMyAdmin affichant les douze tables natives d'une base de données WordPress fraîchement installée. — *Une fois dans phpMyAdmin, vous retrouvez les douze tables natives de WordPress, celles qu’on a détaillées plus haut dans cet article.*

L’exemple de Hostinger

Chez Hostinger, l’interface change complètement de nom et d’apparence, on parle de hPanel plutôt que de cPanel, mais le résultat final reste identique.

Le chemin à suivre est le suivant :

Cliquez sur l’onglet Sites web dans le menu de gauche
Sélectionnez le site concerné
Vous arrivez sur le tableau de bord de ce site, avec l’ensemble des onglets de gestion dans le menu de gauche, dont Bases de données

Tableau de bord d'un site WordPress dans le hPanel Hostinger avec l'onglet Bases de données dans le menu de gestion. — *Une fois votre site sélectionné dans l’onglet « Sites web » du hPanel, vous accédez à son tableau de bord complet, avec la gestion de la base de données dans le menu de gauche.*

Cliquez sur Bases de données, puis sur phpMyAdmin dans le sous-menu
Cliquez sur le bouton Accéder à phpMyAdmin en face de votre base

Page phpMyAdmin du hPanel Hostinger avec le bouton Accéder à phpMyAdmin pour la base de données du site. — *Le bouton Accéder à phpMyAdmin, dans la section Bases de données du hPanel, ouvre directement l’interface de gestion de votre base de données.*

L’un utilise cPanel, l’autre hPanel, mais l’outil final que vous manipulez une fois arrivé est très exactement le même.

phpMyAdmin reste le client le plus répandu pour gérer sa base de données depuis un navigateur, quel que soit l’hébergeur choisi.

Sur les autres hébergements

Le chemin change d’un hébergeur à l’autre, mais la logique reste la même.

Chez OVHcloud, l’accès dépend du format choisi. Sur l’offre d’hébergement web mutualisé, phpMyAdmin est accessible directement depuis l’espace client, en face de chaque base de données. Sur l’offre de bases de données managées Web Cloud Databases, l’accès à phpMyAdmin doit d’abord être activé manuellement depuis ce même espace client.

Chez IONOS, l’outil est préinstallé d’office sur toutes les offres d’hébergement incluant une base de données, accessible depuis l’encadré Bases de données de votre compte.

Et oui, doutez-vous bien que ce constat se vérifie chez la quasi-totalité des hébergeurs.

La présentation de l’interface change, le nombre de clics aussi, mais l’outil qui gère concrètement votre base de données WordPress au quotidien reste très exactement le même.

Une fois que vous maîtrisez la logique chez un hébergeur, vous savez la retrouver partout ailleurs.

Si l’hébergement en lui même reste flou pour vous au delà de cet accès à phpMyAdmin, j’explique tout le sujet plus en détail dans mon article sur comment héberger un site web.

Sécuriser l’accès à votre base de données

Avant de refermer ce sujet, quelques réflexes de sécurité méritent d’être posés :

Un mot de passe robuste et unique pour votre utilisateur de base de données, jamais réutilisé d’un site à l’autre
Une restriction d’accès par adresse IP, utile seulement si vous connectez un outil externe à votre base, un logiciel de bureau ou un serveur distant.

Si vous vous contentez de phpMyAdmin depuis votre hébergeur, votre connexion est déjà protégée par votre session, vous n’avez rien à activer ici.

Cette option porte le nom Remote MySQL ou MySQL à distance selon l’hébergeur, et se trouve dans la même section Bases de données.

Vous la retrouvez d’ailleurs sur votre capture du cPanel un peu plus haut, l’icône MySQL distant juste à côté de phpMyAdmin, le principe est identique chez Hostinger
Un vrai cloisonnement sur un hébergement mutualisé, si votre compte accueille plusieurs sites, comme le font les lunes chez o2switch par exemple

Il me semble essentiel de souligner ce dernier point. Sans cloisonnement, un site compromis peut exposer les bases de données de tous les autres sites hébergés au même endroit, ce qui n’est vraiment pas ce que vous souhaitez.

Sauvegarder votre base de données WordPress

On l’a vu plus haut, une erreur dans votre base de données peut rendre votre site inaccessible en quelques secondes.

La sauvegarde est le seul filet de sécurité qui transforme cette frayeur en simple contretemps.

À quelle fréquence sauvegarder selon votre type de site

La bonne question n’est pas combien de sauvegardes garder, mais à quel rythme vos tables changent réellement, même s’il est impératif de stocker suffisamment de sauvegardes en cas de problème.

Profil de site	Fréquence	Pourquoi ?
Vitrine statique sans blog ni formulaire	Hebdomadaire	La table wp_posts, celle de vos pages, ne bouge quasiment jamais
Vitrine vivant blog, pages, demandes mail	Quotidienne	Chaque article ajouté modifie wp_posts, chaque message reçu remplit une table de formulaire
Réservation en ligne rendez vous, créneaux	Horaire	Les tables de réservation de votre extension se remplissent toute la journée
Espace membre comptes clients	Horaire	wp_users et wp_usermeta évoluent à chaque inscription
Boutique e-commerce commandes, paiements	Horaire	Les tables de commandes et paiements de WooCommerce changent à chaque achat

À retenir : plus vos tables encaissent de la valeur chaque jour, plus l’écart entre deux sauvegardes doit être court.

Le stockage hors du serveur d’hébergement, une exigence RGPD

Une sauvegarde stockée au même endroit que le site protège de peu de choses, une panne ou un piratage du serveur emporte alors le site et sa copie de sécurité en même temps.

Votre base de données contient des données personnelles, les adresses email de vos clients, leurs mots de passe hachés, le détail de leurs commandes le cas échéant.

Beaucoup d’extensions de sauvegarde envoient cette copie vers des services américains comme Google Drive, Dropbox ou Amazon S3.

IMPORTANT : pour que ce transfert reste légalement encadré, le prestataire doit relever d’un cadre d’adéquation reconnu entre l’Union européenne et les États-Unis, un cadre qui a déjà été remplacé plusieurs fois par le passé et le sera probablement encore.

Si je devais vous donner un conseil, je vous dirais qu’un stockage souverain en Europe évite cette question dès le départ, puisque vos données ne quittent jamais le territoire européen.

L’automatisation avec un outil de supervision comme WP Umbrella

Automatiser la sauvegarde avec un outil de supervision comme WP Umbrella, autrement dit une plateforme qui pilote plusieurs sites depuis un tableau de bord unique, retire l’essentiel de la charge manuelle.

Les sauvegardes s’exécutent seules, en tâche de fond, avec une conservation de plusieurs semaines sur une infrastructure européenne.

Tableau de bord des sauvegardes WP Umbrella affichant un taux de succès à 100 pour cent et la fréquence de sauvegarde programmée pour plusieurs sites WordPress. — *Le tableau de bord des sauvegardes de WP Umbrella affiche en un coup d’œil le taux de succès et la fréquence programmée pour chaque site.*

Ce que l’automatisation prend en charge :

Les sauvegardes s’exécutent seules, en tâche de fond, avec une conservation de plusieurs semaines sur une infrastructure européenne
Un contrôle d’intégrité automatique quotidien sur la base de données et les dossiers sauvegardés, contrairement à une extension de sauvegarde classique
Vous n’avez donc plus besoin de tester vous même une restauration, l’outil le vérifie à votre place

Ce qu’elle ne retire pas

Une sauvegarde intègre ne veut pas dire une sauvegarde propre. Un piratage discret installé depuis plusieurs semaines peut très bien s’être glissé dans vos dernières sauvegardes sans que rien ne le signale
Identifier un point de restauration réellement sain, pas seulement techniquement valide, demande un vrai bagage technique
Si un problème survient malgré tout, il vous faut soit les compétences pour diagnostiquer et intervenir dans l’urgence, soit un prestataire de confiance déjà disponible pour le faire

Or c’est justement là que ça coince. La personne qui choisit de tout gérer elle même a rarement, par définition, construit ce réseau de prestataires en amont. Le jour où elle en a besoin, elle part donc de zéro, dans l’urgence, ce qui est le pire moment pour chercher.

D’ailleurs, WP Umbrella se positionne lui-même comme un outil pensé pour les agences et les indépendants qui gèrent la maintenance de sites clients au quotidien, pas comme une solution grand public en libre-service.

C’est révélateur, même l’éditeur de l’outil reconnaît que le piloter correctement relève d’un métier.

L’option autonome, une extension couplée à un stockage européen

Si vous préférez garder la main vous-même sur cette sauvegarde, je vous propose deux extensions précises, parce que toutes les deux permettent une connexion à un stockage compatible S3 dès leur version gratuite respective, sans passer par une licence payante.

UpdraftPlus, l’extension de sauvegarde la plus installée du répertoire officiel WordPress avec plus de 3 millions de sites actifs, propose une option nommée S3-Compatible (Generic) directement accessible en version gratuite.

Écran de sélection du stockage distant dans UpdraftPlus, avec l'option S3-Compatible (Generic) mise en évidence, disponible dès la version gratuite du plugin. — *UpdraftPlus propose le stockage S3 compatible générique dès sa version gratuite, ce qui permet de le relier directement à un espace de stockage souverain comme Scaleway.*

BackWPup, une alternative solide et largement éprouvée du même répertoire, gère elle aussi cette connexion S3 sans limitation dans sa version gratuite, sous l’intitulé Amazon S3 dans son écran de configuration.

Écran de configuration Amazon S3 dans BackWPup, avec Scaleway PAR sélectionné directement dans la liste des services, disponible dès la version gratuite du plugin. — *BackWPup propose lui aussi Scaleway PAR directement dans sa liste de services S3, dès sa version gratuite, sans configuration technique supplémentaire.*

Fait notable, l’extension BackWPup propose Scaleway directement dans leur liste déroulante de services, région « PAR » pour Paris, sans que vous ayez besoin de saisir la moindre adresse de point de terminaison.

Il vous suffit d’indiquer la clé d’accès et la clé secrète fournies par votre espace de stockage souverain.

La présentation change d’un plugin à l’autre, comme on l’a vu plus haut pour les panneaux d’hébergement, mais le principe reste identique.

Reste à choisir la bonne classe de stockage sur Scaleway au moment de créer votre bucket.

La classe « Standard » convient à une sauvegarde qu’on doit pouvoir restaurer rapidement, contrairement aux classes d’archivage pensées pour des données rarement consultées.

Cette combinaison, une extension autonome reliée à un stockage souverain, est robuste et respectueuse du RGPD, à condition de la configurer correctement, ce qui demande un peu de technique.

La méthode manuelle, l’export direct depuis phpMyAdmin

Il est aussi possible d’exporter votre base de données directement depuis phpMyAdmin, sans passer par une extension.

Depuis l’onglet « Structure », cochez « Tout cocher » en bas de la liste des tables, puis choisissez « Exporter » dans le menu qui s’affiche.

Interface phpMyAdmin, sélection de toutes les tables de la base de données WordPress avant export via le menu Avec la sélection — *Depuis l’onglet « Structure », cochez « Tout cocher » puis choisissez « Exporter » pour récupérer l’ensemble de votre base de données.*

Sur l’écran suivant, deux méthodes s’offrent à vous :

La méthode Rapide, celle que je recommande, ne pose qu’une seule question, le format d’export.

Choisissez toujours SQL, le seul format qui rassemble à la fois la structure de vos tables et leur contenu dans un même fichier, celui que phpMyAdmin sait réimporter directement pour reconstruire une base fonctionnelle.

Les autres formats proposés, CSV, JSON, XML, PDF, Word, n’extraient que des données brutes, utiles pour les consulter ailleurs, mais inexploitables pour restaurer un site.

Écran d'export phpMyAdmin avec la méthode Rapide sélectionnée et le format SQL, recommandés pour sauvegarder une base de données WordPress. — *La méthode Rapide au format SQL est le choix le plus simple et le plus fiable pour exporter votre base de données.*

La méthode Personnalisée, elle, déroule un nombre impressionnant de réglages, la sélection fine de la structure et des données table par table, le nom du fichier de sortie, le jeu de caractères, la compression, et bien d’autres options techniques encore plus loin sur la page.

Écran d'export phpMyAdmin en méthode Personnalisée, avec la sélection table par table et les options de sortie avancées. — *La méthode Personnalisée déroule de nombreuses options techniques, à réserver à un utilisateur averti.*

ATTENTION : ne vous aventurez jamais dans cette méthode sans un vrai bagage technique. Une case décochée par erreur, et c’est la structure d’une table entière qui manque à l’appel au moment de restaurer.

Une fois sur « Exporter », phpMyAdmin télécharge directement le fichier SQL sur votre ordinateur.

Ce fichier est très léger. Par exemple, la base fraîchement installée qu’on a vue plus haut, avec ses douze tables natives, pesait à peine 1,3 Mio.

Vous pouvez donc garder plusieurs sauvegardes sur votre ordinateur sans jamais manquer de place.

La seule contrainte, c’est de penser à le faire vous-même à chaque fois, rien n’est automatique.

En cas de problème, voici comment ce fichier vous permet de restaurer votre site :

Vous videz d’abord les tables de la base actuelle
Vous importez ensuite votre fichier SQL depuis l’onglet Importer de phpMyAdmin

Cette étape de vider la base avant d’importer est indispensable. Sans elle, phpMyAdmin refuse de recréer des tables qui existent déjà, et renvoie une erreur.

Et c’est là que ça devient intéressant, car des outils comme UpdraftPlus, BackWPup ou WP Umbrella font exactement ces deux étapes quand vous cliquez sur « Restaurer » dans leurs options respectives.

Vous ne les voyez jamais, mais le mécanisme est le même que celui qu’on vient de détailler, et c’est justement ce mécanisme que je décortique pas à pas dans mon guide pour sauvegarder un site WordPress.

Importer une base de données dans WordPress

Sauvegarder sa base de données ne sert à rien si on ne sait pas la faire revivre ailleurs.

Que ce soit pour rapatrier un site développé en local, changer d’hébergeur, ou restaurer après un incident, l’import pose une difficulté que l’export n’a pas, l’adresse de votre site est écrite en dur dans la base de données.

Chaque article, chaque image, chaque lien interne pointe vers l’ancienne adresse. Si le nom de domaine change, il faut donc rechercher et remplacer cette adresse partout dans la base, sans quoi le site importé reste boiteux même si l’opération a techniquement réussi.

Voici les méthodes les plus intéressantes pour importer une base de données existante dans WordPress, il en existe d’autres, mais celles-ci couvrent l’essentiel des besoins :

UpdraftPlus, l’option la plus généreuse en version gratuite, recherche et remplacement de domaine compris
BackWPup, une alternative gratuite tout aussi solide, avec un fonctionnement légèrement différent
Duplicator, qui embarque l’intégralité du site, fichiers et base de données, mais plutôt pensée pour une migration complète que pour un import ciblé
La méthode manuelle, directement depuis phpMyAdmin

Importer une sauvegarde avec UpdraftPlus

Contrairement à ce qu’on lit parfois, la version gratuite d’UpdraftPlus permet bien de restaurer une sauvegarde vers un nom de domaine différent, la documentation officielle du plugin le confirme noir sur blanc.

Deux situations sont possibles :

UpdraftPlus est déjà relié à un stockage distant, la sauvegarde apparaît automatiquement dans la liste des sauvegardes existantes
Vous disposez d’un fichier de sauvegarde généré par UpdraftPlus, à téléverser manuellement

Attention, un point à ne pas négliger : le fichier téléversé doit impérativement provenir d’une sauvegarde UpdraftPlus. N’essayez jamais de déposer directement un fichier .sql exporté depuis phpMyAdmin, même compressé en .zip ou en .gz, l’opération ne fonctionnera pas. UpdraftPlus attend son propre format de fichier.

Générer une sauvegarde manuelle, pour l’exemple

Le mieux reste d’automatiser vos copies de sécurité directement dans les réglages de l’extension, comme on l’a vu dans la section précédente sur la sauvegarde de la base de données.

Pour illustrer la suite :

Cliquez sur « Sauvegarder », depuis l’onglet Sauvegarder/restaurer

Bouton "Sauvegarder" dans UpdraftPlus pour lancer manuellement une nouvelle sauvegarde de la base de données WordPress. — *Le bouton « Sauvegarder » lance une nouvelle sauvegarde manuelle depuis l’onglet Sauvegarder/restaurer d’UpdraftPlus.*

Une fenêtre s’ouvre pour choisir ce que la sauvegarde doit inclure.

Un point mérite une précision au passage, la case « Tout autre répertoire trouvé dans wp-content » inclut dans la sauvegarde tout dossier supplémentaire présent dans ce répertoire, au-delà des extensions, thèmes et téléversements classiques.

C’est utile si une extension stocke des données ailleurs que dans les emplacements standards, mais ça alourdit aussi le fichier final, à décocher si vous savez que ce n’est pas nécessaire chez vous

Fenêtre de sélection des éléments à inclure dans une sauvegarde UpdraftPlus, base de données, extensions, thèmes et téléversements. — *Cette fenêtre permet de choisir précisément ce que la sauvegarde doit inclure avant de la lancer.*

En bas de cette même fenêtre, un dernier réglage mérite une explication.

La case « Autoriser uniquement cette sauvegarde à être supprimée manuellement » protège cette sauvegarde précise d’une suppression automatique.

Si vous programmez des sauvegardes régulières avec un nombre limité de copies conservées, les plus anciennes sont supprimées automatiquement dès que ce quota est dépassé.

Cocher cette case exempte la sauvegarde en cours de cette règle, elle reste en place quoi qu’il arrive.

C’est particulièrement utile pour une sauvegarde manuelle que vous voulez garder comme point de repère, par exemple juste avant une modification importante

Case "Autoriser uniquement cette sauvegarde à être supprimée manuellement" dans UpdraftPlus, pour protéger une sauvegarde des quotas de rétention. — *Cocher cette case protège la sauvegarde d’une suppression automatique liée aux quotas de rétention.*

Une fois l’opération terminée, la sauvegarde apparaît dans la liste, fichiers et base de données réunis, avec le bouton « Restaurer » en face

Ligne d'une sauvegarde terminée dans UpdraftPlus avec le bouton "Restaurer" en évidence — *Une fois la sauvegarde terminée, le bouton « Restaurer » apparaît en face de la ligne correspondante.*

Récupérer le fichier de base de données, la voie manuelle

Si vous n’avez pas de stockage distant relié, ce qui ne devrait normalement pas être le cas sur un site bien configuré :

Cliquez sur « Base de données », puis sur « Télécharger sur votre ordinateur »

Bouton "Télécharger sur votre ordinateur" pour récupérer le fichier de base de données d'une sauvegarde UpdraftPlus. — *Le bouton « Télécharger » sur votre ordinateur récupère le fichier de base de données de la sauvegarde sélectionnée.*

Le fichier récupéré se présente sous la forme d’une archive compressée en .gz

Fichier de base de données WordPress au format .gz généré par UpdraftPlus, visible sur l'ordinateur. — *Le fichier téléchargé se présente sous la forme d’une archive compressée au format .gz.*

Déposez ce fichier par glisser-déposer sur la zone prévue à cet effet

Zone de dépôt pour téléverser manuellement un fichier de sauvegarde dans UpdraftPlus. — *Le fichier .gz se dépose directement sur cette zone pour être pris en compte par UpdraftPlus.*

Une fois téléversé, le fichier apparaît comme n’importe quelle autre sauvegarde, prêt à être restauré

Fichier de base de données téléversé manuellement dans UpdraftPlus, prêt à être restauré avec le bouton "Restaurer". — *Le fichier téléversé rejoint la liste des sauvegardes, prêt à être restauré.*

Lancer la restauration

Cliquez sur « Restaurer », puis choisissez le composant à reprendre, ici uniquement la base de données

Première étape de la restauration UpdraftPlus avec la case "Base de données" cochée. — *La première étape de la restauration consiste à choisir le composant à reprendre, ici uniquement la base de données.*

Cliquez sur « Suivant ». Deux cas de figure se présentent selon que le domaine de la sauvegarde correspond ou non à celui du site actuel :

Si le domaine diffère, UpdraftPlus affiche une alerte de migration et propose la case « Rechercher et remplacer l’emplacement du site dans la base de données (migrer) ». Cochez-la impérativement.

Alerte de migration UpdraftPlus avec la case "Rechercher et remplacer l'emplacement du site" cochée — *Quand le domaine de la sauvegarde diffère du site actuel, UpdraftPlus propose de rechercher et remplacer automatiquement l’adresse dans la base.*

Si le domaine est identique, cette alerte n’apparaît pas

Étape de restauration UpdraftPlus sans alerte de migration, domaine identique à la sauvegarde. — *Quand le domaine reste identique, aucune alerte de migration ni case de recherche-remplacement ne s’affiche.*

Un lien discret permet de replier ou déplier la liste des tables pour n’en reprendre que certaines si besoin. Cliquez enfin sur « Restaurer » pour valider

Écran de confirmation "Restore successful" avec le journal d'activité d'UpdraftPlus. — *Le journal d’activité confirme la réussite de la restauration et détaille chaque étape effectuée en coulisses.*

Un détail révélé par le journal, à connaître

En restaurant uniquement la base de données sur un site qui n’a pas les fichiers correspondants, le journal d’activité montre quelque chose d’instructif, WordPress signale que le thème et certaines extensions référencés dans la base sont introuvables, désactive ces extensions automatiquement, et revient au thème par défaut pour éviter que le site ne plante.

C’est la preuve concrète que la base de données seule ne fait pas tout, elle contient la liste de ce qui doit tourner, pas les fichiers qui le font tourner.

Après une telle opération, pensez à réinstaller ou réactiver le thème et les extensions concernés.

Importer une sauvegarde avec BackWPup

Nous avons déjà croisé BackWPup plus haut, aux côtés de WP Umbrella (outil payant) et UpdraftPlus, comme option gratuite pour automatiser vos sauvegardes vers un stockage souverain comme Scaleway.

Voyons maintenant comment cette extension se comporte à l’import, autrement dit pour restaurer une base de données existante.

Générer une sauvegarde manuelle pour l’exemple

Contrairement à UpdraftPlus, BackWPup vous impose de passer par un assistant de configuration en trois étapes avant de pouvoir déclencher votre toute première sauvegarde manuelle.

Quoi ? : vous choisissez ce que vous souhaitez inclure, vos fichiers, votre base de données, ou les deux.

L’extension permet même de descendre jusqu’à la sélection table par table si vous ne voulez sauvegarder qu’une partie précise de votre base

Interface BackWPup, étape 1 de la configuration, sélecteur de contenu avec les options "Fichiers" et "Base de données" activées. — *La première étape de la configuration vous demande ce que vous souhaitez sauvegarder, vos fichiers, votre base de données, ou les deux.*

Panneau de sélection des tables de la base de données à inclure dans la sauvegarde BackWPup. — *Vous pouvez descendre jusqu’à la sélection table par table si vous ne souhaitez sauvegarder qu’une partie précise de votre base.*

Quand ? : vous fixez la fréquence des sauvegardes automatiques, séparément pour les fichiers et pour la base.

Si je devais vous donner un conseil, la fréquence horaire disponible gratuitement sur la base de données est un vrai argument face à des extensions concurrentes qui réservent ce niveau de fraîcheur à leur version payante.

Réglages de fréquence de sauvegarde planifiée pour les fichiers et la base de données dans BackWPup. — *L’étape 2 fixe la fréquence de vos sauvegardes automatiques, séparément pour les fichiers et pour la base de données.*

Où ? : vous choisissez le lieu de stockage. Le serveur du site reste disponible par défaut, et parmi les stockages cloud gratuits figure Amazon S3, compatible avec un stockage souverain comme Scaleway PAR déjà évoqué pour UpdraftPlus.

Choix du lieu de stockage de la sauvegarde BackWPup, serveur du site ou stockage cloud. — *La dernière étape choisit où stocker la sauvegarde, avec Amazon S3 disponible gratuitement pour un stockage souverain compatible Scaleway.*

Une fois cette configuration enregistrée, chaque sauvegarde programmée apparaît comme une tâche indépendante dans votre tableau de bord, avec son propre historique.

Tableau de bord BackWPup listant les prochaines sauvegardes planifiées et l'historique des sauvegardes réalisées. — *Une fois configurée, chaque sauvegarde apparaît comme une tâche indépendante, ici une sauvegarde complète mensuelle et une sauvegarde de base de données chaque heure.*

Pour l’exemple qui nous intéresse ici, plutôt que d’attendre l’échéance programmée, cliquez sur « Sauvegarder maintenant ». BackWPup génère alors une sauvegarde complète immédiate, stockée sur le serveur de votre site et téléchargeable sur votre ordinateur.

Fenêtre de confirmation du bouton Sauvegarder maintenant dans BackWPup, précisant le stockage sur le serveur du site. — *Le bouton « Sauvegarder maintenant » déclenche une sauvegarde complète immédiate, stockée sur le serveur et téléchargeable ensuite.*

Restaurer la base de données depuis BackWPup

La restauration existe bel et bien dans la version gratuite de BackWPup, confirmé sur la documentation officielle de l’extension.

Deux situations sont possibles :

La sauvegarde est stockée sur un service distant déjà connecté, la restauration directe en un clic depuis l’historique est possible, mais réservée à la version payante
Vous disposez du fichier de sauvegarde généré par BackWPup, à téléverser manuellement, c’est le seul chemin disponible en version gratuite, quel que soit l’endroit où la sauvegarde est stockée

Attention, un point à ne pas négliger : le fichier téléversé doit impérativement provenir d’une sauvegarde BackWPup. N’essayez pas de déposer un fichier .sql exporté depuis phpMyAdmin ou une sauvegarde générée par une autre extension, l’opération ne fonctionnera pas. BackWPup l’indique d’ailleurs lui même sur son écran de téléversement, chaque extension attend son propre format.

Depuis l’historique de vos sauvegardes, ouvrez le menu d’actions de la sauvegarde concernée. Vous y trouvez deux options, « Télécharger » ou directement « Restaurer la sauvegarde »

Menu d'actions d'une sauvegarde dans l'historique BackWPup avec les options "voir le journal", "télécharger", "restaurer" et "supprimer". — *Depuis l’historique, chaque sauvegarde propose un menu d’actions rapides.*

Téléchargez le fichier, il se présente sous la forme d’une archive au format .tar

Fichier d'archive au format tar généré par BackWPup, téléchargé sur l'ordinateur — *Le fichier de sauvegarde téléchargé se présente sous la forme d’une archive tar.*

Que vous cliquiez sur « Restaurer la sauvegarde » depuis ce menu ou que vous vous rendiez directement sur la page BackWPup > Restore, les deux chemins vous ramènent à la même zone de téléversement manuel. La version gratuite ne propose aucun raccourci qui vous en dispenserait, je l’ai vérifié en testant les deux voies

Page de restauration BackWPup avec zone de téléversement manuel du fichier et mise en avant de la restauration directe réservée à la version Pro. — *En version gratuite, la restauration directe en un clic est verrouillée, il faut téléverser manuellement le fichier de sauvegarde.*

Téléversez le fichier .tar que vous venez de télécharger
Une fois l’extraction réussie, choisissez votre stratégie de restauration parmi Restauration complète, Base de données uniquement ou Fichiers uniquement. Pour un import ciblé sur la base, sélectionnez « Base de données uniquement »

Confirmation d'extraction réussie dans BackWPup avec choix de la stratégie de restauration, base de données uniquement, fichiers uniquement ou restauration complète. — *Une fois le fichier téléversé et extrait, vous choisissez ce que vous souhaitez restaurer, ici uniquement la base de données.*

Renseignez les identifiants de connexion à la base de données de destination, le serveur, le nom de la base, l’identifiant et le mot de passe. Vous les trouverez dans le fichier wp-config.php de l’installation concernée. Cliquez sur « Tester la connexion » avant de continuer

Formulaire de connexion à la base de données de destination dans BackWPup avec serveur, nom, identifiant et mot de passe. — *Renseignez les identifiants de connexion à votre base, disponibles dans le fichier wp-config.php, puis testez la connexion.*

Une fois la connexion confirmée, cliquez sur « Démarrer » pour lancer la restauration

Dernière étape de la restauration BackWPup avec le bouton "Démarrer" pour lancer la restauration de la base de données. — *Une fois la connexion validée, il ne reste qu’à cliquer sur « Démarrer » pour lancer la restauration.*

Un message de succès confirme que l’opération s’est bien déroulée

Message de confirmation de réussite de la restauration de la base de données avec BackWPup. — *Le message de succès confirme que la restauration s’est déroulée correctement.*

ATTENTION : Contrairement à UpdraftPlus et sa case recherche et remplacement intégrée, BackWPup ne gère pas le changement de nom de domaine lors de la restauration.

Si je devais vous mettre en garde sur un point précis, c’est que l’extension ne vous prévient d’aucune façon, j’ai testé une restauration vers un nom de domaine différent et la procédure s’est déroulée sans le moindre avertissement, comme si de rien n’était.

C’est donc à vous d’y penser, en passant par une extension dédiée comme Better Search Replace, vue plus haut, si vous importez sur une adresse différente de l’originale.

Duplicator, une solution pensée pour un autre usage

Duplicator revient dans presque tous les comparatifs sur les extensions de migration WordPress, et ce n’est pas volé.

Elle empaquette l’intégralité de votre site, fichiers et base de données comprises, dans une archive redéployable ailleurs, y compris sur un serveur totalement vierge sans installation WordPress préalable.

Pour un simple import de base de données comme celui qui nous occupe ici, la version gratuite complique plutôt les choses :

Aucune restauration ne se fait depuis l’interface de l’extension, ni en un clic depuis l’historique, ni en glisser déposer dans l’admin, cette dernière option est réservée à la version payante
Le seul chemin disponible passe par le FTP, le protocole de transfert de fichiers qui vous permet de déposer des fichiers directement sur votre serveur d’hébergement
Une fois le paquet généré, vous téléchargez séparément l’archive et le fichier installer.php

Liste des sauvegardes Duplicator avec les boutons de téléchargement séparés pour le fichier installer.php et l'archive de sauvegarde. — *Une fois le paquet généré, téléchargez séparément l’archive et le fichier installer.php, les deux sont nécessaires pour lancer l’installation.*

Vous transférez ensuite les deux fichiers par FTP à la racine du site de destination, puis vous exécutez installer.php depuis votre navigateur pour relancer l’installation

Si je devais vous donner un conseil, je vous dirais que Duplicator reste une excellente extension, mais pas pour tout le monde.

Un accès FTP suppose déjà une certaine aisance technique, et au delà de l’accès lui même, il faut comprendre ce qui se joue derrière l’extension, la façon dont l’archive est structurée, ce que fait réellement l’installeur, pour éviter de se retrouver bloqué au premier imprévu.

C’est un outil que je recommande davantage pour une migration complète de site que pour un import ciblé de base de données, où UpdraftPlus et BackWPup, vus juste avant, restent plus directs, puisque tout se pilote depuis votre tableau de bord WordPress sans sortir de l’admin.

La méthode manuelle, importer depuis phpMyAdmin

Pour un import sans extension, direction l’onglet « Importer » de phpMyAdmin, l’interface qui vous donne un accès direct à votre base de données.

ATTENTION : comme on l’a vu dans la section précédente sur les sauvegardes, il faut d’abord vider les tables existantes de la base de destination, sans quoi phpMyAdmin refuse de recréer des tables déjà présentes.

Ici, en revanche, personne ne fait le travail de recherche-remplacement à votre place.

Si le domaine change, il vous faudra soit passer une requête SQL directement sur les lignes siteurl et home de la table wp_options, soit vous appuyer ensuite sur Better Search Replace pour couvrir l’ensemble de la base, y compris le contenu sérialisé qu’une requête SQL classique ne sait pas traiter correctement.

Depuis l’onglet « Structure », cochez « Tout cocher » pour sélectionner l’ensemble des tables, puis choisissez « Supprimer » dans le menu déroulant « Avec la sélection »

Onglet "Structure" de phpMyAdmin avec toutes les tables cochées et le menu déroulant "Avec la sélection" ouvert sur l'option "Supprimer". — *Cochez « Tout cocher » pour sélectionner l’ensemble des tables, puis choisissez « Supprimer » dans le menu Avec la sélection.*

phpMyAdmin vous demande alors de confirmer, avec le détail de la requête DROP TABLE qui sera exécutée sur l’ensemble des tables sélectionnées

Fenêtre de confirmation phpMyAdmin avant l'exécution d'une requête DROP TABLE pour supprimer les tables existantes d'une base de données WordPress. — *phpMyAdmin demande toujours confirmation avant d’exécuter une commande de suppression de table.*

Une fois la requête exécutée, un message confirme que les tables ont bien été supprimées

Message de succès dans phpMyAdmin confirmant l'exécution réussie de la requête de suppression des tables. — *La requête exécutée avec succès, les anciennes tables ont bien été supprimées.*

Un passage par l’onglet « Structure » confirme que la base est désormais vide, prête à recevoir le nouveau contenu

Onglet "Structure" de phpMyAdmin affichant qu'aucune table n'a été trouvée dans la base de données. — *Un passage par l’onglet « Structure » confirme que la base est désormais vide.*

Vous pouvez maintenant importer votre fichier SQL exporté précédemment.

Fichier SQL exporté depuis phpMyAdmin, enregistré sur l'ordinateur — *Le fichier de sauvegarde exporté précédemment, prêt à être importé.*

Rendez vous sur l’onglet « Importer », puis cliquez sur « Choisir un fichier »

Onglet "Importer" de phpMyAdmin avec le champ de sélection de fichier, encore vide. — Depuis l’onglet « Importer », cliquez sur « Choisir un fichier » pour sélectionner votre export SQL.

Sélectionnez votre fichier SQL

Onglet "Importer" de phpMyAdmin avec le fichier SQL sélectionné, prêt à être importé. — *Le fichier SQL est sélectionné, il ne reste plus qu’à lancer l’import.*

Laissez le format sur SQL, gardez les options par défaut, puis cliquez sur « Importer » en bas de page

LES RÉGLAGES POUR L’IMPORT :

Jeu de caractères du fichier : indique à phpMyAdmin comment interpréter les octets du fichier importé. Réglé sur utf-8 par défaut, ce qui correspond à l’encodage standard des exports WordPress. Un mauvais réglage ici, par exemple si le fichier a été exporté dans un autre encodage, se traduit par des caractères accentués corrompus une fois importés, é, à, ç transformés en symboles bizarres. Dans la grande majorité des cas, la valeur par défaut proposée correspond à l’encodage réel du fichier, aucune raison d’y toucher.
Format : SQL, cohérent avec le fichier que vous venez d’exporter. Rien à changer ici.
Mode de compatibilité SQL : réglé sur NONE par défaut. Ce paramètre adapte la syntaxe SQL acceptée pour se rapprocher du comportement d’un autre système de base de données. Sur un export WordPress classique réimporté sur MySQL ou MariaDB, il n’y a aucune raison de le modifier.
Activer la vérification des clés étrangères : les tables natives de WordPress n’ont pas de clé étrangère entre elles, ce réglage n’a donc quasiment aucun effet sur un import standard. Il ne devient pertinent que si une extension comme WooCommerce en a défini.
Ne pas utiliser AUTO_INCREMENT pour la valeur zéro : coché par défaut, ce réglage conserve exactement les identifiants présents dans le fichier exporté plutôt que d’en générer de nouveaux.

Dans l’immense majorité des cas, les réglages par défaut proposés par phpMyAdmin conviennent parfaitement, inutile d’y toucher.

Le seul cas où ça vaut la peine d’y revenir, c’est si votre import échoue avec une erreur du type valeur par défaut invalide sur une colonne de date, un dump ancien peut se heurter à un mode SQL plus strict que celui utilisé à l’origine. Le mode de compatibilité est alors le premier réglage à ajuster.

Bas de la page "Importer" de phpMyAdmin avec le format SQL et le bouton "Importer". — *Conservez les options par défaut, puis cliquez sur Importer pour lancer l’opération.*

ATTENTION : contrairement à UpdraftPlus, personne ne fait le travail de recherche et remplacement à votre place ici. Si vous importez sur un nom de domaine différent de l’original, l’ancienne adresse reste présente partout dans la base tant que vous n’intervenez pas vous même.

Un réflexe universel après l’import, réactualiser les permaliens

Quelle que soit la méthode utilisée pour importer votre base de données, un réflexe simple évite bien des soucis d’affichage après coup, réenregistrer vos permaliens.

Rendez vous dans Réglages > Permaliens, et cliquez sur « Enregistrer les modifications« , sans rien changer à la structure choisie.

Cette action force WordPress à régénérer ses règles de réécriture d’URL, ce qui résout la plupart des erreurs 404 qui peuvent apparaître juste après un import.

Page "Réglages Permaliens" de WordPress avec le bouton "Enregistrer les modifications". — *Réenregistrer vos permaliens sans rien changer à la structure suffit à régénérer les règles de réécriture d’URL.*

Le réflexe à avoir si votre site utilise Elementor

Si votre site utilise Elementor, l’import d’une base de données appelle une vigilance supplémentaire.

Elementor stocke certains réglages sous forme sérialisée et met en cache ses fichiers CSS avec l’adresse du site figée en dur, ce qui peut laisser des traces de l’ancien nom de domaine même après une recherche et remplacement classique.

Rendez vous dans Elementor > Outils, onglet « Remplacement d’URL« . Renseignez l’ancienne et la nouvelle adresse de votre site, puis cliquez sur « Remplacement d’URL«

Onglet "Remplacement d'URL" dans Elementor avec les champs ancienne et nouvelle adresse du site. — *Renseignez l’ancienne et la nouvelle adresse de votre site pour mettre à jour les données Elementor.*

Depuis le même menu, onglet Général, cliquez sur « Effacer les fichiers et les données » pour vider le cache d’Elementor. Cette étape force la régénération des fichiers CSS avec la nouvelle adresse à la prochaine visite d’une page du site

Onglet "Général" d'Elementor avec le bouton "Effacer les fichiers et les données" du cache. — *Vider le cache Elementor force la régénération des fichiers CSS avec la nouvelle adresse.*

Pour vérifier qu’aucune ancienne adresse n’a survécu quelque part dans la base, l’extension gratuite Better Search Replace, développée par WP Engine, fait un excellent filet de sécurité.

Fiche d'installation de l'extension gratuite Better Search Replace par WP Engine dans le répertoire WordPress. — *Better Search Replace, une extension gratuite développée par WP Engine, plus d’un million d’installations actives.*

Elle gère correctement les données sérialisées et propose un mode d’essai qui prévisualise les changements avant de les appliquer réellement.

Renseignez l’ancienne et la nouvelle adresse, sélectionnez les tables concernées

Formulaire Better Search Replace rempli avec l'ancienne et la nouvelle adresse du site, et les tables sélectionnées. — *Renseignez l’ancienne et la nouvelle adresse, puis sélectionnez les tables concernées.*

Cochez « Faire un essai » avant de lancer l’opération pour de vrai, cette case affiche un aperçu des changements sans toucher à la base

Réglages supplémentaires de Better Search Replace avec la case Faire un essai cochée avant l'exécution. — *Cocher Faire un essai affiche un aperçu des changements sans toucher à la base de données.*

C’est une étape à connaître avant de migrer un site construit avec Elementor, peu importe la méthode d’import retenue plus haut.

Optimiser et nettoyer votre base de données WordPress

Une base de données WordPress fonctionne encore techniquement même chargée de révisions inutiles, de brouillons oubliés et de tables orphelines.

Mais chaque requête devient plus lente à exécuter, et chaque sauvegarde plus lourde à générer.

Optimiser et nettoyer régulièrement votre base, c’est garder un site rapide sans attendre qu’il montre des signes de ralentissement.

La commande d’optimisation dans phpMyAdmin

Quand WordPress supprime ou modifie beaucoup de lignes dans une table, par exemple après avoir purgé des milliers de révisions, l’espace libéré n’est pas automatiquement rendu au système.

Ces zones inoccupées, appelées overhead, restent réservées à l’intérieur de la table, qui garde donc un poids supérieur à son contenu réel. La commande OPTIMIZE TABLE reconstruit la table pour récupérer cet espace perdu.

Si je dois être honnête sur ce point, sur le moteur InnoDB, celui qu’utilise WordPress par défaut depuis longtemps, l’effet reste réel mais plus modeste que ce qu’on lit parfois.

OPTIMIZE TABLE ne va pas transformer un site lent en site rapide à lui seul, il récupère surtout de l’espace disque après un gros nettoyage, plutôt que d’accélérer spectaculairement les requêtes.

Pour la lancer manuellement depuis phpMyAdmin :

Cochez « Tout cocher » pour sélectionner l’ensemble des tables, ou uniquement celles concernées par un nettoyage récent
Choisissez « Optimiser la table » dans le menu déroulant « Avec la sélection »

Menu déroulant "Avec la sélection" dans phpMyAdmin avec l'option "Optimiser la table" mise en évidence, toutes les tables cochées — *Cochez « Tout cocher » pour sélectionner l’ensemble des tables, puis choisissez « Optimiser la table » dans le menu « Avec la sélection ».*

Un message confirme que la requête OPTIMIZE TABLE s’est exécutée avec succès sur l’ensemble des tables sélectionnées

Message de succès dans phpMyAdmin confirmant l'exécution de la requête OPTIMIZE TABLE sur l'ensemble des tables de la base. — *La requête OPTIMIZE TABLE s’exécute sur toutes les tables sélectionnées en une seule opération.*

Si je devais vous donner un conseil, sachez que si vous utilisez déjà un outil de performance comme WP Rocket, cette manipulation manuelle devient rare. C’est justement l’intérêt de ce type d’extension, l’optimisation se fait automatiquement, sans avoir à ouvrir phpMyAdmin.

Ce qui alourdit vraiment une base, et comment le nettoyer

Toutes les données ne pèsent pas le même poids dans une base WordPress. Voici ce qui s’accumule le plus, et comment y remédier.

Les révisions d’articles, de loin le poste le plus lourd dans la grande majorité des bases WordPress que je croise.

Chaque enregistrement d’un article en cours de rédaction crée une nouvelle révision, sans limite par défaut. Un article modifié cinquante fois traîne cinquante versions dans la table wp_posts.

Vous pouvez limiter ce comportement en ajoutant cette ligne dans votre fichier wp-config.php :

wp-config.php


1define('WP_POST_REVISIONS', 5);

Cette constante fixe le nombre de révisions conservées par article, ici cinq. Pour les désactiver entièrement, remplacez la valeur par false.

Les brouillons automatiques, créés par WordPress dès que vous cliquez sur « Ajouter », avant même d’avoir écrit quoi que ce soit.

C’est aussi sur cet enregistrement que reposent les sauvegardes automatiques de votre saisie en cours toutes les 60 secondes.

IMPORTANT : si un nettoyage supprime ces entrées pendant que vous êtes en train de rédiger, vous risquez de perdre ce qui n’a pas encore été enregistré comme brouillon à proprement parler. WordPress dispose d’ailleurs de son propre mécanisme natif, mais qui ne supprime que les brouillons automatiques de plus de 7 jours, largement le temps de finir sa rédaction.

Les transients expirés, ces données temporaires que WordPress et vos extensions stockent dans la table wp_options pour éviter de recalculer certaines informations à chaque chargement. Une fois expirés, ils devraient normalement disparaître seuls, mais ce n’est pas toujours le cas en pratique, et ils s’accumulent silencieusement.

Les commentaires indésirables et Akismet, si vous utilisez cette extension anti-spam, très répandue sur WordPress, elle laisse des métadonnées associées aux commentaires qu’elle traite, en plus des commentaires eux-mêmes mis en attente ou marqués comme spam.

Les tables orphelines, laissées par des extensions désinstallées sans avoir nettoyé leurs propres tables. On y reviendra en détail juste après, avec un comparatif d’extensions dédiées.

Avant tout nettoyage programmé, un impératif : des sauvegardes récentes et de qualité. Si quelque chose tourne mal après une opération de nettoyage, c’est votre sauvegarde qui vous permet de revenir en arrière. Plus la fréquence de vos sauvegardes est calibrée aux besoins réels du site, moins vous risquez de perdre du contenu entre la dernière copie et l’incident.

Automatiser ce nettoyage

Dans ma pratique, je programme ce nettoyage plutôt que de le faire manuellement, avec WP Rocket, l’extension de performance que j’utilise pour mes clients en maintenance, combinée à Imagify pour les images.

Interface de nettoyage de base de données WP Rocket avec les options révisions, brouillons auto, corbeille et commentaires indésirables. — *WP Rocket regroupe le nettoyage des contenus et des commentaires dans un seul écran, avec le nombre d’éléments concernés affiché en direct.*

Je programme une optimisation hebdomadaire de la base, avec les réglages ci dessus. Un point sur lequel je suis intransigeant, je ne programme jamais la suppression automatique des brouillons, pour la raison évoquée plus haut, un article en cours de rédaction ne doit jamais être menacé par une tâche planifiée.

Réglages de nettoyage automatique WP Rocket avec optimisation des tables et planification hebdomadaire activée. — *Le nettoyage automatique peut être planifié, ici sur une fréquence hebdomadaire, avec un rappel de sauvegarder la base avant toute opération.*

Si vous cherchez une alternative gratuite, deux extensions se distinguent.

WP-Optimize combine nettoyage, optimisation des tables et détection des tables orphelines, avec en prime des fonctionnalités de cache. Argument de confiance à noter, elle est développée par TeamUpdraft, l’éditeur d’UpdraftPlus, ce qui peut rassurer si vous utilisez déjà cette extension pour vos sauvegardes.

Onglet "Tables" de WP-Optimize listant les tables de la base de données avec détection des tables orphelines liées à des extensions désinstallées. — *WP-Optimize identifie les tables laissées par des extensions inactives ou désinstallées, ici backwpup et fluentform, avec un bouton « Retirer ».*

Onglet "Optimisations" de WP-Optimize listant les tâches disponibles, optimisation des tables, révisions, brouillons automatiques, corbeille et commentaires. — *Chaque tâche de nettoyage peut être lancée individuellement ou groupée depuis cet écran.*

Sa version gratuite permet aussi de programmer le nettoyage automatique.

Réglages de nettoyage planifié de WP-Optimize avec fréquence hebdomadaire et sélection des tâches à automatiser. — *La version gratuite de WP-Optimize permet de programmer le nettoyage automatique, avec un réglage fin des tâches incluses.*

Advanced Database Cleaner prend une approche plus ciblée, entièrement dédiée au nettoyage et à l’optimisation de la base, sans les fonctionnalités de cache. Sa version gratuite autorise jusqu’à cinq tâches automatisées.

Panneau Automatisation d'Advanced Database Cleaner avec une tâche d'optimisation et de nettoyage planifiée sur une fréquence hebdomadaire. — *La version gratuite d’Advanced Database Cleaner autorise jusqu’à cinq tâches automatisées.*

Panneau Nettoyage général d'Advanced Database Cleaner listant les révisions, brouillons auto et articles à la corbeille avec leur nombre. — *Chaque catégorie affiche le nombre d’éléments concernés avant de lancer le nettoyage.*

Les deux extensions se valent largement, le choix dépend surtout de si vous voulez un outil de cache en plus, ou une solution concentrée uniquement sur le nettoyage. On y reviendra plus en détail dans le comparatif des meilleures extensions, un peu plus bas.

Les autres facteurs qui influencent les performances de votre site

La rapidité d’un site WordPress ne dépend pas uniquement de sa base de données. Plusieurs autres éléments jouent un rôle direct sur la vitesse de chargement :

Le poids des images et leur conversion au format webp, plus léger que le jpeg ou le png classique
La structure des pages, un nombre raisonnable d’éléments plutôt qu’une accumulation de blocs et de widgets
Le choix d’un thème léger et bien codé
Le choix d’extensions de qualité, plutôt que d’en accumuler sans discernement
Les outils de performance dédiés à l’optimisation de la base de données et à la compression des images, comme ceux vus juste au dessus

Du côté strictement base de données, un facteur mérite une attention particulière, souvent négligé, les options autochargées de la table wp_options.

Comprendre les options autochargées

WordPress charge en mémoire l’ensemble des options marquées autoload à chaque chargement de page, aussi bien côté admin que côté public.

Cela concerne notamment :

Les réglages laissés par des thèmes et extensions désinstallés, jamais nettoyés au moment de la suppression
Les réglages que certaines extensions marquent en autoload par facilité, même quand ils ne sont pas nécessaires à chaque page

Passé un certain poids, WordPress affiche d’ailleurs un avertissement dans Outils > Santé du site, « Les options autochargées pourraient affecter les performances ».

Contrairement à une table qui grossit visiblement, ce problème reste invisible tant qu’on ne va pas le chercher, alors qu’il pèse sur absolument chaque page vue de votre site.

Ce qui reste prioritaire

Dans la grande majorité des cas que je croise, ce sont bien les révisions qui représentent le premier poste à surveiller, largement devant les options autochargées.

C’est pour cette raison que je recommande vraiment de nettoyer sa base régulièrement, plutôt que d’attendre que le site montre des signes de ralentissement.

Quels plugins choisir pour gérer votre base de données WordPress ?

Deux familles d’extensions se distinguent, sauvegarder et migrer votre base d’un côté, la nettoyer et l’optimiser de l’autre, avec les solutions de performance qui intègrent un nettoyage de base directement intégrées à cette seconde famille.

Voici un récapitulatif pour vous orienter rapidement, le détail pratique de chaque extension reste disponible plus haut dans l’article.

Sauvegarder et migrer sa base de données

Extension	Gratuit / Payant	Installations actives	Points forts	Limites
UpdraftPlus	Freemium	3 millions+	Recherche et remplacement de domaine intégré dès la version gratuite, stockage compatible S3 souverain comme Scaleway inclus	Sans stockage distant connecté, la restauration passe par un téléversement manuel
BackWPup	Freemium	500 000+	Fréquence horaire disponible gratuitement sur la base de données, développée par WP Media, l’éditeur de WP Rocket et Imagify	Restauration toujours manuelle en version gratuite, aucune recherche et remplacement de domaine intégrée
Duplicator	Freemium	1 million+	Embarque fichiers et base dans une seule archive, fonctionne même sur un serveur vierge sans WordPress préinstallé	Import via FTP uniquement en version gratuite, aucune restauration possible depuis l’administration

Nettoyer et optimiser sa base de données

Extension	Gratuit / Payant	Repère de confiance	Points forts	Limites
WP-Optimize	Freemium	1 million+	Combine nettoyage, cache et compression d’images, programmation automatique gratuite, développée par TeamUpdraft, l’éditeur d’UpdraftPlus	Version gratuite sans contrôle table par table, tout ou rien
Advanced Database Cleaner	Freemium	100 000+	Détection des tables au préfixe invalide, automatisation jusqu’à 5 tâches en version gratuite	Aucune fonctionnalité de cache, uniquement centrée sur la base. L’identification de l’extension responsable d’une table reste payante
WP Rocket	Payant uniquement	Éditeur actif depuis 2013	Nettoyage couvrant les mêmes catégories qu’un outil dédié, intégré à la performance globale du site, plus de dix ans de recul	Aucune détection des tables orphelines, aucune version gratuite
FlyingPress	Payant uniquement	Éditeur actif depuis 2020	Mêmes catégories de nettoyage que WP Rocket, approche allégée orientée Core Web Vitals, bien noté par ses utilisateurs	Aucune détection des tables orphelines, aucune version gratuite, éditeur plus jeune

Si je devais vous donner un conseil sur WP Rocket et FlyingPress, sur le nettoyage de base précisément, elles se valent, aucune des deux ne surclasse l’autre à cet endroit.

Leurs vraies différences se jouent ailleurs, l’intégration Cloudflare, la gestion du CSS, l’ancienneté et la taille de la communauté, pas sur ce module particulier.

Un cas particulier, réinitialiser sa base de données

Dans certains cas, plutôt que de nettoyer, mieux vaut repartir de zéro. C’est utile sur un site de développement ou de test, pour effacer un contenu de démonstration avant la mise en ligne, ou pour repartir sur une base saine après une longue série d’essais.

WP Reset, plus de 300 000 installations actives et 4,8 étoiles, remet votre base de données à son état d’installation par défaut en un clic, sans toucher à vos fichiers. Un système d’instantanés intégré permet de revenir en arrière si besoin, avant de valider la réinitialisation.

ATTENTION : cette opération reste radicale et irréversible une fois confirmée. Sur un site en production, ce n’est pas un outil de nettoyage courant, mais une solution à réserver aux cas où repartir de zéro est réellement l’objectif.

Résoudre les erreurs courantes de la base de données WordPress

Même avec une base bien entretenue, certaines erreurs finissent par se glisser. Voici comment reconnaître les plus fréquentes et les résoudre avec de vraies solutions, pas juste un diagnostic.

L’erreur d’établissement de connexion à la base de données

Le symptôme est sans appel, votre site entier disparaît derrière un message froid, sans mise en forme, sans menu, rien.

Message d'erreur WordPress "Error establishing a database connection" affiché à la place du site — *C’est souvent la première chose que voit un visiteur quand WordPress ne parvient plus à joindre sa base de données.*

Ce message signifie une seule chose, WordPress ne parvient pas à joindre sa base de données. Les causes possibles, par ordre de fréquence :

Des identifiants incorrects dans le fichier wp-config.php, la cause la plus courante, notamment après un changement d’hébergeur ou une migration
Un serveur MySQL indisponible ou surchargé chez votre hébergeur
Des tables corrompues
Des fichiers WordPress corrompus
Une limite de mémoire PHP dépassée
Un piratage du site ou de la base

Première chose à vérifier, les identifiants dans wp-config.php.

Ouvrez ce fichier, déjà croisé plusieurs fois dans cet article, et comparez les quatre valeurs DB_NAME, DB_USER, DB_PASSWORD et DB_HOST avec celles fournies par votre hébergeur.

Une erreur de copier coller ou un identifiant qui a changé lors d’une migration suffit à provoquer ce message.

Si les identifiants sont bons, contactez votre hébergeur pour vérifier qu’il n’y a pas de panne du côté du serveur de base de données.

IMPORTANT : WP_ALLOW_REPAIR ne répare rien tant que la connexion elle même n’est pas rétablie. Cette option ne s’active qu’une fois que WordPress parvient à joindre la base, si le problème vient ensuite d’une table corrompue plutôt que d’identifiants erronés.

Si vous voyez encore le message générique d’erreur de connexion, inutile d’aller plus loin, retournez d’abord vérifier vos identifiants.

Une fois la connexion rétablie, si vous voyez plutôt un message du type « Une ou plusieurs tables de la base de données ne sont pas disponibles », WordPress dispose d’un mode de réparation intégré.

Ajoutez la ligne define('WP_ALLOW_REPAIR', true); dans votre fichier wp-config.php, juste avant la ligne « That’s all, stop editing ! ». Vous pouvez la récupérer facilement avec le bloc à copier ci-dessous.

wp-config.php


1define('WP_ALLOW_REPAIR', true);

Rendez vous ensuite sur votresite.com/wp-admin/maint/repair.php, vous obtenez deux boutons, « Réparer la base de données » ou « Réparer et optimiser la base de données ».

Une fois l’opération terminée, retirez impérativement cette ligne de votre wp-config.php, cette page reste accessible à n’importe qui tant qu’elle y figure, sans avoir besoin d’être connecté.

Vous pouvez aussi réparer directement depuis phpMyAdmin, avec l’option « Réparer la table », située juste à côté d’Optimiser la table dans le même menu déroulant « Avec la sélection » qu’on a déjà vu plus haut dans cet article.

Si rien de tout cela ne fonctionne, la dernière piste reste des fichiers WordPress corrompus.

Il faut alors remplacer les dossiers wp-admin et wp-includes par une copie fraîche téléchargée sur WordPress.org, sans toucher à wp-content ni à wp-config.php.

Un cas moins connu, des publications qui disparaissent du front-end après une modification en base

Un symptôme qui déroute souvent, des publications qui existent toujours dans l’administration, ou disparaissent même de la liste, mais qui ne s’affichent plus du tout sur le site.

La cause la plus fréquente, un type de publication personnalisé renommé.

Chaque publication stocke son type dans la colonne post_type de la table wp_posts, un point déjà vu plus haut dans l’article, dans la partie sur la structure de la base.

Si le type de publication personnalisé est renommé, dans le code d’une extension ou d’un thème, sans que les publications existantes soient migrées vers ce nouveau nom, WordPress ne reconnaît plus ces lignes comme appartenant à un type valide.

Elles restent physiquement présentes dans la base, mais deviennent invisibles pour WordPress.

Pour corriger la situation, trois options :

Revenir à l’ancien nom du type de publication dans le code, si c’est possible, la solution la plus simple
Mettre à jour la colonne post_type directement en base via une requête SQL, pour faire correspondre les publications existantes au nouveau nom
Utiliser une extension dédiée à ce type de correction, plutôt qu’une manipulation SQL manuelle si vous n’êtes pas à l’aise avec les requêtes

Dans tous les cas, réenregistrez vos permaliens une fois la correction faite, comme vu plus haut dans l’article, pour que WordPress régénère ses règles de réécriture d’URL en tenant compte des publications retrouvées.

D’autres pannes fréquentes, en bref

Des widgets, réglages de thème ou mises en page qui se vident après une restauration.

C’est un symptôme classique de données sérialisées corrompues.

WordPress stocke certains réglages complexes sous une forme qui indique, au début de chaque donnée, sa longueur exacte en caractères.

Une recherche et remplacement brute sur un export SQL, qui ne prend pas en compte cette longueur, casse cette lecture, et WordPress abandonne la donnée plutôt que de l’afficher à moitié.

C’est exactement la raison pour laquelle je recommande un outil comme Better Search Replace, vu plus haut dans l’article, plutôt qu’une modification directe du texte dans un export.

Le fichier .maintenance qui reste bloqué. Le message « Brièvement indisponible pour cause de maintenance planifiée » persiste sur toutes les pages du site.

Ce n’est pas à proprement parler un problème de base de données, mais il est souvent confondu avec, car il rend le site tout aussi inaccessible.

WordPress crée ce fichier à la racine du site pendant une mise à jour, puis le supprime normalement une fois l’opération terminée.

Si la mise à jour est interrompue, le fichier reste en place, et il suffit de le supprimer manuellement par FTP pour que le site revienne aussitôt.

Questions fréquentes sur la base de données de WordPress

Oui, changer le préfixe wp_ ajoute une couche de protection supplémentaire contre certaines attaques automatisées, notamment les injections SQL qui ciblent les noms de tables par défaut.

Ce n’est pas une protection absolue à elle seule, mais c’est un réflexe simple à adopter, que ce soit à l’installation ou sur un site déjà en ligne.

Je détaille la marche à suivre complète dans mon guide pour changer le préfixe de votre base de données.

Le fichier wp-config.php se trouve à la racine de votre installation WordPress, au même niveau que les dossiers wp-admin, wp-content et wp-includes.

Vous y accédez par FTP ou depuis le gestionnaire de fichiers de votre hébergeur.

Non, la plupart des opérations courantes, sauvegarder, importer, nettoyer, optimiser, se font sans écrire la moindre ligne de SQL, grâce à des extensions ou à des interfaces comme phpMyAdmin.

Le SQL reste utile pour des cas précis, mais il n’est jamais indispensable au quotidien.

Oui, une mauvaise manipulation peut effectivement supprimer ou corrompre des données.

C’est la raison pour laquelle une sauvegarde récente avant toute intervention n’est jamais une option facultative, c’est la seule vraie protection contre une erreur.

WordPress nécessite officiellement MySQL ou MariaDB pour fonctionner, comme le confirme la page officielle des prérequis de WordPress.org.

C’est un prérequis technique fixé au niveau du cœur du logiciel, aucun site WordPress ne peut aujourd’hui s’en passer.

Pour votre usage, aucune différence pratique.

MariaDB est un fork de MySQL, pensé dès le départ comme un remplacement compatible, et WordPress fonctionne indifféremment avec l’un ou l’autre, les deux figurant d’ailleurs à égalité sur cette même page officielle des prérequis.

C’est pour cette raison que beaucoup d’hébergeurs utilisent MariaDB sans le préciser, sans que ça change quoi que ce soit pour vous.

Sources :

Learn WordPress – Architecture MySQL et PHP de WordPress

Larousse – Définition de base de données

WordPress Developer Resources – Classe wpdb et rôle des tables natives

WordPress Developer Resources – Constantes et structure du fichier wp-config.php

Softaculous – Installation de WordPress en un clic

o2switch – Création manuelle d’une base de données MySQL sous cPanel

Local – Environnement de développement local pour WordPress

o2switch – Accès à phpMyAdmin depuis cPanel

Hostinger – Accès à phpMyAdmin depuis hPanel

Hostinger – Configuration de l’accès MySQL à distance

IONOS – Ouvrir phpMyAdmin depuis l’espace client

WP Umbrella – Fonctionnalités de sauvegarde et restauration

UpdraftPlus – Fiche officielle sur le répertoire WordPress.org

BackWPup – Fiche officielle sur le répertoire WordPress.org

Scaleway – Classes de stockage Object Storage

TeamUpdraft – Documentation officielle sur la migration avec UpdraftPlus

Elementor – Centre d’aide officiel sur la migration de site

Better Search Replace – Fiche officielle sur le répertoire WordPress.org

Google Search Central – Migration de site avec changement d’URL

MySQL – Documentation officielle de la commande OPTIMIZE TABLE

WordPress Developer Resources – Suppression native des brouillons automatiques

WordPress Developer Resources – Options autochargées et performance

Duplicator – Fiche officielle sur le répertoire WordPress.org

WP-Optimize – Fiche officielle sur le répertoire WordPress.org

Advanced Database Cleaner – Fiche officielle sur le répertoire WordPress.org

TeamUpdraft – Historique du rachat de WP-Optimize

WP Rocket – Page officielle sur l’historique de l’extension

FlyingPress – Interview du fondateur sur l’origine du projet

WP Reset – Fiche officielle sur le répertoire WordPress.org

WordPress Developer Resources – Documentation officielle de la commande WP-CLI search-replace

WordPress.org – Page officielle des prérequis techniques

Conclusion sur la base de données de WordPress

La base de données de votre site WordPress n’a plus grand chose d’un mystère, à présent. Vous savez ce qu’elle contient, où la trouver, comment la sauvegarder, l’importer, la nettoyer, et surtout, comment réagir le jour où quelque chose se passe mal.

Et si je devais résumer ce que je retiens de tout ce qu’on vient de couvrir, c’est que la base de données est justement l’endroit où se joue une bonne partie de cette propriété réelle sur votre site.

Un thème, on peut le changer. Une extension, on peut la remplacer. Mais le contenu, les réglages, l’historique de tout ce que vous avez construit, tout ça vit dans cette base.

La comprendre un minimum, savoir la sauvegarder correctement, c’est ce qui vous évite de dépendre entièrement d’un tiers, agence ou hébergeur, le jour où un problème survient.

Vous n’avez pas besoin de devenir spécialiste en bases de données pour autant.

Un bon réflexe de sauvegarde, une extension fiable pour l’entretien courant, et les bons repères pour diagnostiquer une erreur suffisent largement à garder la main sur votre site, sereinement.

Et si vous préférez ne pas porter ce suivi seul, un accompagnement en maintenance permet de confier la sécurité, les performances, les sauvegardes, les mises à jour et la surveillance à quelqu’un d’autre.

Base de données WordPress : le guide complet pour la comprendre et la gérer

Testez votre niveau de sérénité face à votre base de données

Qu’est-ce qu’une base de données WordPress ?

Ce que WordPress y stocke réellement

Pourquoi la manipuler avec prudence

Pourquoi une erreur y est parfois difficile à repérer

La structure de la base de données WordPress, les tables et leur rôle

Les tables natives de WordPress, une par une

Le préfixe des tables, un point de sécurité à connaître

Les fichiers et dossiers essentiels qui pilotent votre base de données WordPress

wp-config.php, le fichier qui établit la connexion

wp-includes, le pont technique entre WordPress et MySQL

Créer une base de données WordPress, les différentes méthodes

Avec l’installateur en un clic de votre hébergeur (Softaculous ou équivalent)

Manuellement via phpMyAdmin depuis cPanel

En local, pour du développement ou du test

Accéder à votre base de données et la modifier au quotidien

Depuis l’interface de votre hébergeur, l’exemple de cPanel chez o2switch

L’exemple de Hostinger

Sur les autres hébergements

Sécuriser l’accès à votre base de données

Sauvegarder votre base de données WordPress

À quelle fréquence sauvegarder selon votre type de site

Le stockage hors du serveur d’hébergement, une exigence RGPD

L’automatisation avec un outil de supervision comme WP Umbrella

L’option autonome, une extension couplée à un stockage européen

La méthode manuelle, l’export direct depuis phpMyAdmin

Importer une base de données dans WordPress

Importer une sauvegarde avec UpdraftPlus

Générer une sauvegarde manuelle, pour l’exemple

Récupérer le fichier de base de données, la voie manuelle

Lancer la restauration

Un détail révélé par le journal, à connaître

Importer une sauvegarde avec BackWPup

Générer une sauvegarde manuelle pour l’exemple

Restaurer la base de données depuis BackWPup

Duplicator, une solution pensée pour un autre usage

La méthode manuelle, importer depuis phpMyAdmin

Un réflexe universel après l’import, réactualiser les permaliens

Le réflexe à avoir si votre site utilise Elementor

Optimiser et nettoyer votre base de données WordPress

La commande d’optimisation dans phpMyAdmin

Ce qui alourdit vraiment une base, et comment le nettoyer

Automatiser ce nettoyage

Les autres facteurs qui influencent les performances de votre site

Comprendre les options autochargées

Ce qui reste prioritaire

Quels plugins choisir pour gérer votre base de données WordPress ?

Sauvegarder et migrer sa base de données

Nettoyer et optimiser sa base de données

Un cas particulier, réinitialiser sa base de données

Résoudre les erreurs courantes de la base de données WordPress

L’erreur d’établissement de connexion à la base de données

Un cas moins connu, des publications qui disparaissent du front-end après une modification en base

D’autres pannes fréquentes, en bref

Questions fréquentes sur la base de données de WordPress

Faut-il changer le préfixe de la base de données WordPress pour la sécuriser ?

Où se trouve le fichier wp-config.php ?

Faut-il savoir coder en SQL pour gérer sa base de données WordPress ?

Peut-on perdre son contenu en modifiant sa base de données ?

WordPress peut-il fonctionner sans MySQL ?

Quelle est la différence entre MySQL et MariaDB pour WordPress ?

0 commentaires

Laisser un commentaire Annuler la réponse

Les articles qui pourraient vous intéresser.

Besoin d’être accompagné ?