Pourquoi une application fait 100 requêtes au lieu d'une (le problème N+1)

Une page lente cache souvent un défaut discret : au lieu de demander tout ce dont elle a besoin d'un coup, l'application pose la même question à la base de données une fois par ligne. On appelle ça le problème N+1 : une requête pour la liste, puis N requêtes pour les détails de chacun de ses N éléments.

L'analogie : les courses

Vous avez une liste de vingt articles à acheter. Première méthode : vous allez au magasin, prenez un article, rentrez chez vous, puis ressortez pour le suivant. Deuxième méthode : un seul trajet, un seul panier. Le contenu est le même, mais le premier trajet est vingt fois plus long.

L'application qui fait du N+1 prend la première méthode. Chaque aller-retour vers la base est court, mais il se paie : un temps d'attente, un peu de travail pour la base, et tout cela se multiplie.

Un exemple

Prenons une boutique de 200 produits (exemple illustratif). La page d'accueil affiche chaque produit avec le nom de sa catégorie.

1. L'application demande la liste des produits : 1 requête.
2. Puis, pour chaque produit, elle demande sa catégorie : 200 requêtes.

Soit 201 requêtes pour afficher une page, alors qu'une ou deux auraient suffi. Avec 10 produits, personne ne remarque rien. Avec 200, la page ralentit. Le défaut grandit en même temps que vos données, c'est pourquoi une application peut sembler rapide au lancement, puis lente quelques mois plus tard.

Pourquoi c'est si fréquent

Le code qui l'engendre a l'air tout à fait propre : une boucle sur les produits, et dans la boucle, « donne-moi sa catégorie ». Beaucoup d'outils d'accès à la base masquent la requête derrière une simple écriture, donc on ne la voit pas. Du code généré par une IA peut le produire aussi, car il fonctionne parfaitement sur un jeu de test minuscule.

Comment le repérer

• Une page qui ralentit à mesure que la liste s'allonge.
• Des outils de suivi ou des journaux qui montrent la même requête répétée des dizaines de fois pour une seule page.
• Un temps de réponse qui reste long alors que le serveur est peu chargé.

Comment le corriger

On demande tout en une fois :

• charger les éléments liés en même temps que la liste (de nombreux outils proposent un « chargement anticipé ») ;
• ou demander toutes les catégories d'un coup pour l'ensemble des produits, puis les rattacher en mémoire ;
• ou fusionner les deux demandes en une seule avec une jointure.

Quand la bonne requête est lente à son tour, un index aide la base à la trouver vite, et un cache évite de la refaire à chaque visite. Pour le panorama des autres causes, voyez pourquoi une application est lente.

À retenir

Le problème N+1 transforme une page en une rafale de petites requêtes : la solution est de tout demander en une fois. Si une page ralentit quand les données grossissent, c'est le premier suspect.

Et pour votre produit ?

Ce genre de défaut ne se voit pas en lisant l'écran, il se voit dans le code et dans les requêtes réellement envoyées. Un audit de votre application permet de repérer les pages concernées et de dire lesquelles méritent d'être corrigées en premier. Si vous le souhaitez, nous en parlons lors d'un échange de 30 minutes.