# Relire une pull request sensible à la performance : ce que cherche un relecteur

> Trois signaux reviennent systématiquement dans une relecture attentive : une requête en boucle, un cache oublié, un appel bloquant glissé sans prévenir.

- Auteur : WordPress Développement
- Publié le : 2023-12-10
- Mis à jour le : 2023-12-10
- Catégorie : Performance
- URL : https://www.wpmoderne.fr/performance/relire-pull-request-performance/

## L’essentiel

- Une requête dans une boucle est le signal le plus fréquent à repérer
- Un cache manquant se voit souvent à un nouvel appel systématique
- Un appel réseau doit toujours être justifié dans la description

Une pull request qui touche au cœur métier d'un site à fort trafic mérite une relecture différente d'un simple correctif d'affichage. Au-delà de la correction fonctionnelle, un relecteur expérimenté cherche systématiquement trois signaux d'alerte, souvent invisibles à la première lecture rapide du code.

Voici ce que vérifie, dans l'ordre, une relecture attentive d'une évolution touchant à une logique exécutée fréquemment, avant de donner son approbation.

## Premier réflexe : chercher une requête dans une boucle

Le signal le plus fréquent, et le plus facile à repérer une fois qu'on sait le chercher, est un appel à une fonction de requête (`get_posts()`, `WP_Query`, `get_post_meta()` répété avec des identifiants variables) placé à l'intérieur d'une boucle `foreach` ou `while`. Ce motif, souvent appelé N+1, transforme ce qui pourrait être une seule requête en autant de requêtes qu'il y a d'éléments à traiter.

```
// Signal d'alerte : une requête par produit dans la boucle
foreach ( $produits as $produit_id ) {
    $avis = get_posts( array(
        'post_type'   => 'avis',
        'meta_key'    => 'produit_id',
        'meta_value'  => $produit_id,
    ) );
    // ...
}
```

Un relecteur attentif propose systématiquement de reformuler ce genre de motif avec une seule requête regroupée en amont, utilisant `'meta_value__in'` ou une jointure adaptée, puis un tri en mémoire PHP du résultat déjà chargé.

## Deuxième réflexe : vérifier la présence d'un cache

Toute nouvelle fonction qui effectue un calcul coûteux ou une requête répétée mérite de passer par `wp_cache_get()` et `wp_cache_set()`, ou par un transient si la persistance au-delà d'une seule requête est utile. Un relecteur vérifie systématiquement si l'auteur de la pull request a pensé à cette couche, et si la clé de cache choisie est correctement construite pour éviter les collisions entre contextes différents.

> L'essentiel à retenir : Une requête dans une boucle est le signal le plus fréquent à repérer ; Un cache manquant se voit souvent à un nouvel appel systématique ; Un appel réseau doit toujours être justifié dans la description

## Troisième réflexe : traquer l'appel bloquant

Tout appel à `wp_remote_get()`, `wp_remote_post()` ou une fonction équivalente mérite une attention particulière dans un hook exécuté à chaque requête (comme `init`, `template_redirect` ou `save_post`). Un relecteur demande systématiquement : cet appel est-il vraiment nécessaire de façon synchrone, ou peut-il être différé, mis en cache, ou déclenché uniquement dans un contexte d'administration plutôt que sur le front public ?

> Une règle simple qui sert de garde-fou en relecture : aucun appel réseau sortant ne devrait s'exécuter sur une page vue par un visiteur anonyme sans qu'un cache ou un mécanisme de report ne l'entoure.

## Ce que la description de la pull request doit expliquer

Au-delà du code lui-même, un relecteur attend que la description de la pull request justifie explicitement les choix de performance : pourquoi telle requête n'a pas pu être regroupée, pourquoi tel appel reste synchrone malgré le risque, quelle volumétrie de données est attendue en production. Une description silencieuse sur ces points oblige le relecteur à deviner les intentions, ce qui ralentit la revue et augmente le risque de laisser passer un problème.

## Une check-list de relecture rapide

- Y a-t-il une requête de base de données à l'intérieur d'une boucle qui pourrait grandir avec le volume de données ?
- Le nouveau code appelle-t-il un service externe, et si oui, cet appel est-il mis en cache ou différé ?
- Une nouvelle option ou métadonnée ajoutée est-elle correctement indexée si elle sera utilisée dans des requêtes de filtrage ?
- Le code a-t-il été testé avec un volume de données réaliste, pas seulement avec le jeu de données de développement local ?

## En résumé

Une relecture sensible à la performance ne remplace pas les tests automatisés, mais elle attrape ce qu'aucun test unitaire classique ne détecte : un motif de requête qui se dégradera avec le volume de production. Chercher systématiquement ces trois signaux, requête en boucle, cache oublié, appel bloquant, transforme une revue de code en véritable filet de sécurité contre les régressions de performance silencieuses.