# fields => ids dans WP_Query pour réduire l’exposition d’une recherche

> Une recherche interne qui renvoie des objets WP_Post complets expose souvent bien plus de métadonnées que ce que l'affichage final n'utilise réellement.

- Auteur : Clément Hadrot
- Publié le : 2026-05-10
- Mis à jour le : 2026-05-10
- Catégorie : Sécurité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/securite/fields-ids-wp-query-reduire-exposition-recherche/

## L’essentiel

- Le paramètre fields en ids réduit la charge et la surface exposée
- Les métadonnées sensibles ne doivent jamais transiter par une recherche générique
- Un second appel ciblé récupère uniquement les champs à afficher

`'fields' => 'ids'` — ce simple argument, ajouté à un tableau de paramètres `WP_Query`, change profondément ce qui transite dans la mémoire du serveur lors d'une recherche interne. Par défaut, une requête de recherche standard construit un objet `WP_Post` complet pour chaque résultat, avec l'ensemble de son contenu, ses métadonnées chargées à la demande et parfois des champs personnalisés sensibles jamais destinés à quitter le contexte d'administration. Cette recette ne traite pas de l'indexation par un moteur de recherche externe, mais de la construction de la recherche interne elle-même.

## Le problème observé

Une fonction de recherche interne, construite pour alimenter une barre de recherche en autocomplétion, interrogeait `WP_Query` sans restriction de champs et transmettait ensuite l'ensemble des objets trouvés à une fonction de formatage côté client via une réponse JSON. Un examen de la réponse réseau, dans les outils de développement du navigateur, révélait des champs personnalisés jamais affichés à l'écran, dont un identifiant interne de fournisseur et un statut de marge commerciale associés à certains produits.

## Le snippet corrigé

> L'essentiel à retenir : Le paramètre fields en ids réduit la charge et la surface exposée ; Les métadonnées sensibles ne doivent jamais transiter par une recherche générique ; Un second appel ciblé récupère uniquement les champs à afficher

```
function domaine_rechercher_produits($terme) {
  $requete = new WP_Query(array(
    's'           => sanitize_text_field($terme),
    'post_type'   => 'produit',
    'post_status' => 'publish',
    'fields'      => 'ids',
    'posts_per_page' => 15,
  ));

  return array_map('domaine_formater_resultat_public', $requete->posts);
}

function domaine_formater_resultat_public($id_produit) {
  return array(
    'titre' => get_the_title($id_produit),
    'lien'  => get_permalink($id_produit),
    'image' => get_the_post_thumbnail_url($id_produit, 'thumbnail'),
  );
}
```

Avec `'fields' => 'ids'`, la requête ne renvoie plus qu'un tableau d'identifiants numériques. La fonction de formatage récupère ensuite explicitement, un par un, les seuls champs destinés à l'affichage public, sans jamais charger ni transmettre l'objet complet du produit avec ses métadonnées internes.

## Les variantes utiles de fields

| Valeur de fields | Ce qui est renvoyé | Cas d'usage typique |
| --- | --- | --- |
| `'ids'` | Tableau d'identifiants numériques | Recherche, filtrage, comptage |
| `'id=>parent'` | Identifiants associés à leur parent | Construction d'arborescences |
| Valeur par défaut (absente) | Objets `WP_Post` complets | Affichage détaillé d'un article ou d'une page unique |

## Le gain de performance, un bénéfice secondaire mais réel

Au-delà de la réduction de l'exposition de données, cette approche allège sensiblement la charge mémoire et le temps de réponse d'une recherche portant sur un grand nombre de résultats, puisque WordPress n'a plus à hydrater chaque objet complet avant que le code applicatif ne les filtre. Sur un catalogue de plusieurs milliers de produits, la différence se mesure directement dans le temps de réponse de l'autocomplétion.

## Vérifier ce qui part réellement au client

Réduire les champs renvoyés par `WP_Query` ne suffit pas si la fonction de formatage qui suit continue, par erreur, à ressortir des métadonnées via `get_post_meta()` sans filtrage. Chaque fonction de formatage destinée à une réponse publique doit lister explicitement les champs autorisés, plutôt que de renvoyer un tableau construit par copie partielle d'une structure plus large.

## Un réflexe à généraliser à d'autres recherches

Cette même logique s'applique à toute fonctionnalité de recherche ou de filtrage exposée publiquement : recherche de contacts dans un annuaire, filtrage de rendez-vous disponibles, suggestion de contenus liés. Dès qu'une requête `WP_Query` alimente une réponse destinée à un visiteur non authentifié, la question du périmètre de champs renvoyés mérite d'être posée avant celle de la performance.

## En résumé

Le paramètre `fields` de `WP_Query` n'est pas qu'une optimisation technique : c'est un outil de réduction de surface d'exposition. Limiter une recherche interne à des identifiants, puis reconstruire manuellement une réponse restreinte aux seuls champs destinés à l'affichage, referme une fuite de métadonnées souvent invisible tant qu'on ne va pas inspecter la réponse réseau réelle.