Créer une table personnalisée avec dbDelta() pour stocker des réservations, des candidatures ou des avis clients prend, au mieux, une heure de travail bien fait. Créer un type de contenu personnalisé pour la même donnée prend dix minutes. Cet écart, à lui seul, explique une bonne partie du succès des types de contenu personnalisés (CPT) face aux tables maison — bien plus que la performance brute, souvent invoquée après coup.
Quand on compare les deux approches uniquement sur le plan des requêtes SQL générées, une table personnalisée bien indexée gagne presque toujours. Le CPT s’appuie sur wp_posts et wp_postmeta, une structure généraliste pensée pour stocker n’importe quel type de contenu avec n’importe quel champ, ce qui implique des jointures et un stockage en lignes clé-valeur plutôt qu’en colonnes typées. Pourtant, les CPT dominent largement les extensions et thèmes publiés. La raison tient à ce que l’API apporte gratuitement.
Ce que l’API de contenu personnalisé offre sans rien coder
Un CPT enregistré avec register_post_type() hérite immédiatement d’un écran de liste dans l’administration, d’un formulaire de saisie, d’une gestion des révisions, d’une intégration à l’API REST si show_in_rest est activé, d’un système de permissions basé sur les capacités, et d’une compatibilité native avec des dizaines d’extensions tierces qui savent déjà manipuler des articles. Une table personnalisée ne bénéficie d’aucun de ces éléments par défaut : chaque écran, chaque contrôle de droits, chaque route d’API doit être écrit à la main.
C’est cet investissement caché qui explique le choix par défaut vers les CPT, même dans des cas où une table dédiée serait objectivement plus rapide à l’exécution.
Le prix réel de wp_postmeta
La table wp_postmeta stocke chaque champ personnalisé comme une ligne distincte, avec une clé, une valeur et une référence à l’article. Cette flexibilité a un coût direct : récupérer plusieurs champs d’un même article suppose plusieurs lignes à joindre ou plusieurs appels à get_post_meta(), et filtrer une liste d’articles sur un champ personnalisé numérique impose une comparaison sur une colonne de type texte, rarement indexée efficacement pour ce genre de tri.
// Filtrer sur un champ personnalisé : correct, mais coûteux à grande échelle
$requete = new WP_Query( array(
'post_type' => 'reservation',
'meta_key' => 'montant',
'meta_type' => 'DECIMAL(10,2)',
'orderby' => 'meta_value_num',
'order' => 'DESC',
) );Cette requête fonctionne parfaitement jusqu’à quelques milliers de lignes. Passé un certain volume, le plan d’exécution MySQL montre clairement la limite : la comparaison typée sur une colonne texte empêche un usage optimal des index, et le tri s’appuie sur une jointure supplémentaire vers wp_postmeta.
Quand la table maison redevient le bon choix
Trois signaux indiquent qu’une table personnalisée mérite d’être envisagée plutôt qu’un CPT classique :
- Un volume de lignes qui dépasse largement la centaine de milliers, avec des filtres fréquents sur des champs numériques ou des dates.
- Une donnée qui n’a jamais besoin d’écran d’édition dans l’administration native (un journal d’événements, par exemple).
- Des relations complexes entre plusieurs entités, plus naturelles à exprimer en colonnes et jointures SQL qu’en métadonnées.
Un compromis intermédiaire trop souvent ignoré
Entre les deux extrêmes, une option reste sous-utilisée : garder un CPT pour bénéficier de l’écran d’administration et de l’API REST, tout en stockant les champs les plus sollicités en filtrage dans une table personnalisée dédiée aux recherches, synchronisée à chaque enregistrement via le hook save_post. Cette approche cumule les avantages des deux mondes au prix d’une synchronisation à maintenir — un compromis pertinent quand le volume grossit progressivement, sans justifier d’emblée une refonte complète.
Le choix d’un CPT n’est presque jamais un choix de performance : c’est un choix de vitesse de développement, assumé ou non.
En résumé
Les types de contenu personnalisés ont gagné contre les tables SQL maison parce qu’ils offrent un écran d’administration, une API REST et un système de permissions sans une ligne de code supplémentaire — pas parce qu’ils exécutent des requêtes plus rapides. Comprendre ce compromis permet de faire un choix éclairé plutôt qu’un choix par défaut, et de basculer vers une table dédiée le jour où le volume ou les besoins de filtrage le justifient réellement.
