Structurer les biens d’une agence immobilière sans surcharger les métadonnées

Douze champs personnalisés pour décrire un bien immobilier : c’est le point de départ typique d’une petite agence qui structure son catalogue sans réfléchir à la nature de chaque attribut. Type de bien, ville, quartier, nombre de pièces, surface, présence d’un balcon, année de construction – tout finit en métadonnée, faute d’une distinction claire entre ce qui doit filtrer une recherche et ce qui décrit simplement le bien.

Cette approche fonctionne un temps, jusqu’à ce que le site propose un moteur de recherche par critères : filtrer par ville et par type de bien simultanément avec des meta_query imbriquées devient lent dès que le catalogue dépasse quelques centaines d’annonces, la table wp_postmeta n’étant pas conçue pour ce type de filtrage combiné.

Distinguer ce qui filtre de ce qui décrit

La règle qui simplifie la décision : si une valeur sert à filtrer, trier ou regrouper des biens entre eux, et qu’elle appartient à un ensemble fini de valeurs réutilisées, elle relève d’une taxonomie. Si elle décrit une caractéristique propre à un bien précis, souvent numérique ou en texte libre, elle reste une métadonnée.

function wpm_enregistrer_taxonomies_bien() {
    register_taxonomy( 'type_bien', 'bien', array(
        'label'        => 'Type de bien',
        'hierarchical' => false,
        'show_in_rest' => true,
    ) );

    register_taxonomy( 'ville', 'bien', array(
        'label'        => 'Ville',
        'hierarchical' => true,
        'show_in_rest' => true,
    ) );
}
add_action( 'init', 'wpm_enregistrer_taxonomies_bien' );

Ce qui reste en métadonnée

• bien_surface : un nombre en mètres carrés, propre à chaque annonce
• bien_nb_pieces : un entier, filtrable mais généralement par plage plutôt que par valeur exacte
• bien_annee_construction : une donnée descriptive sans intérêt à regrouper en taxonomie
• bien_reference : l’identifiant interne de l’agence pour ce bien

Pourquoi tax_query surpasse meta_query en performance

Une taxonomie s’appuie sur les tables wp_term_relationships et wp_term_taxonomy, indexées et pensées pour ce type de jointure. Une meta_query avec plusieurs conditions génère au contraire une jointure sur wp_postmeta par condition, une table qui grossit vite et dont l’index ne cible que la clé, pas la combinaison de plusieurs clés à la fois.

// Recherche combinée, rapide grâce aux taxonomies
$requete = new WP_Query( array(
    'post_type' => 'bien',
    'tax_query' => array(
        'relation' => 'AND',
        array( 'taxonomy' => 'type_bien', 'field' => 'slug', 'terms' => 'appartement' ),
        array( 'taxonomy' => 'ville', 'field' => 'slug', 'terms' => 'lyon' ),
    ),
) );

Le cas particulier du nombre de pièces

Le nombre de pièces illustre bien la limite de la règle simple : c’est une valeur souvent filtrée (« 3 pièces et plus »), ce qui pourrait plaider pour une taxonomie. Mais comme les filtres portent généralement sur une plage plutôt qu’une valeur exacte, une métadonnée numérique avec une meta_query de type NUMERIC et un opérateur >= reste plus adaptée qu’une taxonomie avec une entrée par nombre de pièces possible.

Un compromis : combiner les deux mécanismes

Rien n’empêche de combiner une tax_query pour les critères discrets (ville, type de bien) et une meta_query réduite à un seul critère numérique (surface minimale, nombre de pièces minimal). Cette combinaison reste largement plus performante qu’une recherche entièrement construite sur des métadonnées.

Attribut	Mécanisme	Justification
Type de bien	Taxonomie	Ensemble fini, filtré fréquemment
Ville / quartier	Taxonomie hiérarchique	Regroupement naturel, réutilisé
Surface	Métadonnée numérique	Valeur propre à chaque bien, filtrée par plage
Référence interne	Métadonnée texte	Non filtrable côté visiteur

Sur un catalogue de biens, la première question avant de créer un champ n’est pas « comment vais-je l’afficher » mais « comment vais-je le filtrer dans six mois, quand le catalogue aura triplé ».

En résumé

Un catalogue immobilier bien pensé repose sur un partage clair entre taxonomies pour les critères de filtrage combinés et métadonnées pour les valeurs propres à chaque bien. Cette distinction, posée dès la conception, évite une migration douloureuse le jour où le nombre d’annonces dépasse ce qu’une recherche à base de métadonnées peut encaisser sans ralentir la page de résultats.