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

> Type de bien, ville, nombre de pièces : certains attributs relèvent d'une taxonomie, d'autres d'un champ personnalisé. Le mauvais choix ralentit les requêtes.

- Auteur : WordPress Développement
- Publié le : 2021-01-19
- Mis à jour le : 2021-01-19
- Catégorie : Extensions
- URL : https://www.wpmoderne.fr/extensions/structurer-biens-agence-immobiliere-sans-surcharge-metadonnees/

## L’essentiel

- Les valeurs filtrables et réutilisées vont en taxonomie
- Les valeurs uniques et numériques restent en métadonnée
- tax_query bat toujours meta_query en performance

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.

> L'essentiel à retenir : Les valeurs filtrables et réutilisées vont en taxonomie ; Les valeurs uniques et numériques restent en métadonnée ; tax_query bat toujours meta_query en performance

```
// 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.