La base de données WordPress : comprendre à quoi elle sert et comment elle fonctionne

Un site Word­Press, ce n’est pas seule­ment un ensemble de fichiers. Une bonne par­tie de ce qui fait vivre votre site (vos articles, vos réglages, vos comptes uti­li­sa­teurs) est sto­ckée ailleurs, dans une base de don­nées. Voyons ce qu’elle contient, com­ment elle est orga­ni­sée, et pour­quoi la com­prendre un mini­mum aide à mieux entre­te­nir votre site.

Pourquoi WordPress a besoin d’une base de données

Un site pure­ment sta­tique, fait de pages HTML écrites une fois pour toutes, n’a pas besoin de base de don­nées : chaque page existe déjà telle quelle sur le ser­veur. Word­Press fonc­tionne dif­fé­rem­ment. Ses fichiers PHP ne contiennent aucun conte­nu en tant que tel : ils décrivent com­ment affi­cher un conte­nu, pas le conte­nu lui-même. Quand un visi­teur charge une page, Word­Press va cher­cher dans la base de don­nées le texte de l’ar­ticle, les réglages du site, les infor­ma­tions sur l’au­teur, puis assemble le tout à la volée pour pro­duire la page finale.

Cette sépa­ra­tion a une consé­quence directe sur l’en­tre­tien de votre site : les fichiers (thème, exten­sions, cœur de Word­Press) et la base de don­nées (conte­nu, réglages, comptes) sont deux élé­ments dis­tincts, tout aus­si indis­pen­sables l’un que l’autre. Perdre l’un ou l’autre revient à perdre une par­tie du site, même si l’autre par­tie est intacte.

Comment WordPress organise ses données : les tables principales

À l’in­té­rieur de la base de don­nées, les infor­ma­tions sont répar­ties dans des tables, un peu comme des feuilles de cal­cul spé­cia­li­sées, cha­cune dédiée à un type de don­née. Par défaut, ces tables portent un pré­fixe (wp_ en stan­dard), per­son­na­li­sable à l’ins­tal­la­tion. Chan­ger ce pré­fixe ne rem­place évi­dem­ment pas les vraies mesures de sécu­ri­té, mais cela peut ajou­ter une petite couche de pro­tec­tion sup­plé­men­taire face à cer­tains scripts automatisés.

wp_posts : articles, pages et bien plus

Contrai­re­ment à ce que son nom laisse pen­ser, wp_posts ne contient pas seule­ment les articles. Elle stocke aus­si les pages, les entrées de la média­thèque, les révi­sions, et tout type de conte­nu per­son­na­li­sé créé par un thème ou une exten­sion. Atten­tion tou­te­fois : pour un média, la base conserve les infor­ma­tions asso­ciées au fichier, mais le fichier image, PDF ou vidéo reste sto­cké dans les fichiers du site, géné­ra­le­ment dans wp-content/uploads. C’est la colonne « type de conte­nu » qui dis­tingue un article d’une page ou d’un média au sein de cette même table.

À noter : cer­taines exten­sions volu­mi­neuses choi­sissent de sor­tir de ce fonc­tion­ne­ment com­mun. Woo­Com­merce, par exemple, uti­lise aujourd’­hui HPOS, pour High-Per­for­mance Order Sto­rage, sur les nou­velles ins­tal­la­tions : les com­mandes ne sont plus sto­ckées uni­que­ment dans wp_posts et wp_postmeta, mais dans des tables dédiées. Sur les bou­tiques plus anciennes, la situa­tion peut varier selon la confi­gu­ra­tion et l’é­tat de migra­tion. Cela illustre bien que l’or­ga­ni­sa­tion des tables n’est pas figée : elle dépend aus­si des exten­sions ins­tal­lées sur votre site.

À l’in­verse, du côté du cœur de Word­Press cette fois, l’é­di­teur de site (FSE) va dans l’autre sens : plu­tôt que de s’é­loi­gner de wp_posts, il y ajoute de nou­veaux types de conte­nu, comme les modèles de page (wp_template) ou les styles glo­baux (wp_global_styles). Avec un thème basé sur les blocs, une per­son­na­li­sa­tion faite depuis l’é­di­teur de site est donc enre­gis­trée en base. Avec un thème clas­sique, une par­tie de la struc­ture dépend davan­tage des fichiers du thème, même si de nom­breux réglages res­tent eux aus­si sto­ckés en base.

wp_postmeta : les informations complémentaires

Chaque conte­nu de wp_posts peut avoir des infor­ma­tions com­plé­men­taires asso­ciées : une image mise en avant, un champ per­son­na­li­sé ajou­té par une exten­sion, des réglages spé­ci­fiques à une page. Ces infor­ma­tions vivent dans wp_postmeta, sous forme de paires clé/valeur reliées à un conte­nu précis.

wp_options : les réglages globaux du site

Cette table cen­tra­lise les réglages qui s’ap­pliquent à l’en­semble du site : le titre, l’a­dresse, la ver­sion de Word­Press ins­tal­lée, mais aus­si une bonne par­tie des réglages de vos exten­sions et de votre thème. Une colonne par­ti­cu­lière de cette table, l’au­to­load, déter­mine si un réglage est char­gé auto­ma­ti­que­ment à chaque affi­chage de page : un volume exces­sif d’op­tions char­gées auto­ma­ti­que­ment peut ralen­tir votre site (nous détaillons ce point dans notre article sur l’au­to­load Word­Press).

wp_users et wp_usermeta : les comptes

wp_users contient les infor­ma­tions essen­tielles d’un compte (iden­ti­fiant, adresse e‑mail, mot de passe chif­fré), tan­dis que wp_usermeta stocke les infor­ma­tions com­plé­men­taires : rôle, pré­fé­rences d’af­fi­chage, ou toute don­née ajou­tée par une extension.

wp_terms, wp_term_taxonomy, wp_term_relationships : catégories et étiquettes

Ces trois tables tra­vaillent ensemble pour gérer les caté­go­ries, les éti­quettes et les taxo­no­mies per­son­na­li­sées : la pre­mière liste les termes exis­tants, la deuxième pré­cise à quelle taxo­no­mie chaque terme appar­tient, la troi­sième relie ces termes aux conte­nus de wp_posts.

Comment WordPress se connecte à sa base

wp-config.php fait par­tie des tout pre­miers fichiers que Word­Press charge à chaque affi­chage de page. C’est là que sont défi­nies les constantes DB_NAME, DB_USER, DB_PASSWORD et DB_HOST, qui donnent res­pec­ti­ve­ment le nom de la base, l’i­den­ti­fiant, le mot de passe et l’a­dresse du ser­veur néces­saires à la connexion. C’est ce fichier qui fait le lien entre votre code Word­Press et votre base MySQL.

Où et comment accéder vous-même à la base de données

Les outils natifs de l’hébergement

Les héber­geurs mettent géné­ra­le­ment à dis­po­si­tion un client SQL, un outil pour consul­ter et modi­fier direc­te­ment le conte­nu de la base. Le plus répan­du est php­MyAd­min, c’est notam­ment celui qu’o2switch pro­pose via le cPa­nel, mais d’autres solu­tions existent selon l’hé­ber­geur. Nous détaillons l’ou­til php­MyAd­min du cPa­nel o2switch dans notre article sur la ges­tion des bases de don­nées avec le cPa­nel d’o2switch.

Adminer, une alternative à installer soi-même

L’in­té­rêt d’Ad­mi­ner est sur­tout de don­ner un accès auto­nome à la base de don­nées, sans pas­ser par le cPa­nel de l’hé­ber­ge­ment. Il peut s’a­gir d’une exten­sion Word­Press qui l’in­tègre au tableau de bord (menu Outils) : utile si vous n’a­vez que l’ac­cès à l’ad­mi­nis­tra­tion Word­Press et pas à l’es­pace de ges­tion de votre héber­geur. Il existe aus­si une ver­sion en fichier PHP unique à dépo­ser soi-même sur le ser­veur : si vous avez un accès FTP, elle est plus légère et plus simple à déployer. Vous pou­vez en sécu­ri­ser l’ac­cès, puis la sup­pri­mer pro­pre­ment après usage, sans sur­char­ger votre WordPress.

Dans les deux cas, Admi­ner per­met une admi­nis­tra­tion com­plète de la base (consul­ta­tion, modi­fi­ca­tion, requêtes) : pra­tique en dépan­nage ponc­tuel, mais à reti­rer aus­si­tôt après usage, le lais­ser acces­sible en per­ma­nence expose la base de don­nées à un risque de sécu­ri­té impor­tant. Plus de détails dans notre article Admi­ner, une alter­na­tive à php­MyAd­min.

Les précautions à prendre en cas d’intervention directe sur la base

Inter­ve­nir direc­te­ment sur une base de don­nées Word­Press (en SQL, via php­MyAd­min, Admi­ner, ou même WP-CLI) demande de vraies com­pé­tences tech­niques : com­prendre le voca­bu­laire des tables, savoir écrire une requête, maî­tri­ser au mini­mum un outil en ligne de com­mande. Ce n’est pas une inter­ven­tion à impro­vi­ser pour dépan­ner ponc­tuel­le­ment un site : mieux vaut la confier à un déve­lop­peur ou à votre pres­ta­taire de maintenance.

Si vous ou la per­sonne qui s’en charge devez inter­ve­nir, quelques pré­cau­tions s’imposent :

• Tou­jours faire une sau­ve­garde de la base avant toute modi­fi­ca­tion. Une erreur dans une table comme wp_options ou wp_postmeta peut rendre le site inaccessible.
• Réser­ver les inter­ven­tions directes en base (php­MyAd­min, Admi­ner) au strict néces­saire, en dépan­nage ponctuel.
• Pour cer­tains chan­ge­ments régu­liers sur le conte­nu de la base, comme cor­ri­ger une URL en masse, WP-CLI est sou­vent pré­fé­rable à une requête SQL directe. Sa com­mande wp search-replace, par exemple, sait gérer les don­nées séria­li­sées, là où un rem­pla­ce­ment SQL brut risque de les cor­rompre. Notre article WP-CLI et la ligne de com­mande pour Word­Press détaille son fonctionnement.

Le seul geste réel­le­ment à la por­tée de tous, sans com­pé­tence tech­nique par­ti­cu­lière : véri­fier que votre stra­té­gie de sau­ve­garde couvre bien la base de don­nées, au même titre que vos fichiers. C’est aus­si le plus impor­tant, il vous per­met de reve­nir en arrière quelle que soit l’in­ter­ven­tion effec­tuée sur la base.

À retenir

La base de don­nées est l’autre moi­tié de votre site Word­Press, celle qui contient vos articles, vos réglages et vos comptes uti­li­sa­teurs. Elle est orga­ni­sée en tables spé­cia­li­sées (wp_posts, wp_postmeta, wp_options, wp_users…) reliées entre elles, et acces­sible via des outils comme php­MyAd­min dans le cPa­nel de votre héber­ge­ment. Vous n’a­vez pas besoin de la mani­pu­ler direc­te­ment au quo­ti­dien, mais la com­prendre aide à mieux éva­luer l’im­por­tance d’une sau­ve­garde régu­lière et à évi­ter les inter­ven­tions hasar­deuses en cas de problème.