Un développeur me dit que son code est propre et qu'il n'y a donc pas de N+1. Que répondre ?

Qu'il a raison sur la propreté et que c'est justement le piège. Un N+1 naît rarement d'un mauvais code ; il naît d'un ORM qui rend l'accès à une relation aussi anodin qu'un accès à un attribut. La boucle qui le déclenche est souvent dans un template, parfois à trois niveaux de profondeur dans un composant réutilisé. La relecture ne suffit pas à le voir, seul le compteur de requêtes tranche.

Faut-il une base de production pour reproduire le problème en local ?

Pas la base, mais du volume. Sur un jeu de test à cinq lignes, un N+1 reste invisible : six requêtes au lieu de deux, personne ne le sent passer. Je peuple donc une base locale avec quelques centaines d'enregistrements via les factories du framework avant de mesurer. Sans ce volume, le diagnostic ne dit rien.

Au lieu du chargement anticipé, puis-je simplement mettre un cache devant la page ?

Le cache masque le symptôme sans toucher à la cause, et il se retourne contre vous au premier contenu personnalisé ou au premier panier qui change à chaque visite. Vous payez alors le plein tarif des requêtes à chaque miss, plus la complexité d'invalidation. Je corrige la requête d'abord ; le cache vient après, sur une base déjà saine, jamais pour camoufler une dette.

Le GraphQL ou les API à champs imbriqués sont-ils plus exposés ?

Nettement. Une requête GraphQL qui descend client puis commandes puis lignes peut générer une cascade de N+1 emboîtés, un par niveau de résolveur. La parade habituelle est un dataloader qui regroupe les accès d'un même niveau en un seul appel. Le principe reste celui du chargement anticipé, mais il se règle dans la couche résolveur, pas dans le contrôleur.

Le problème N+1 : le détecter et le corriger

Une page de listing à 3,5 secondes, chez un client e-commerce. L’équipe la trouvait « un peu lente » depuis des mois, sans jamais mettre le doigt sur la cause. Le code de la page était lisible. Rien ne sautait aux yeux. En comptant les requêtes, le verdict est tombé en deux minutes : un N+1 sur les images produit. Un with() ajouté au bon endroit, la page est repassée sous 400 ms. Vingt minutes de travail, café compris.

Ce scénario, je le rejoue à l’identique plusieurs fois par an. C’est de loin la lenteur que je rencontre le plus souvent, et elle se planque toujours derrière le confort d’un ORM.

Le N+1, c’est quand une appli tire une requête par ligne au lieu d’une seule pour afficher une liste : on le démasque en comptant les requêtes par page, et le chargement anticipé ramène souvent la page sous le demi-seconde.

Ce qui se passe vraiment sous le capot

Vous affichez 100 commandes, et pour chacune le nom du client. Le code paraît anodin : on récupère les commandes, et dans la boucle on lit le client de chaque ligne. Mais l’ORM, lui, tire 1 requête pour les commandes, puis 1 requête par commande pour aller chercher le client. Résultat : 101 requêtes là où 2 auraient suffi.

D’où le nom : 1 requête de départ, plus N requêtes derrière, une par élément. Sur une page de démo, ça passe inaperçu. Sous trafic réel, c’est une base qui sature sans qu’on comprenne d’où vient la pression.

Le mettre en évidence

Le symptôme se devine à l’œil : plus la liste s’allonge, plus la page traîne. Reste à le prouver, et ça, ça se compte.

La plupart des stacks offrent de quoi le faire sans rien installer de lourd. Django Debug Toolbar, le query log de Laravel, le profiler de Symfony : peu importe l’outil, le geste est le même. Vous ouvrez la page, vous lisez le compteur de requêtes. 150 requêtes pour une simple liste ? Le diagnostic est posé.

Le correctif : le chargement anticipé

On dit à l’ORM de charger les relations en amont, en une requête groupée, au lieu de les réclamer une par une dans la boucle. C’est ce qu’on appelle le chargement anticipé, ou eager loading. Vos 101 requêtes redeviennent 2, et l’effet sur le temps de réponse est souvent spectaculaire.

Concrètement, c’est with() côté Laravel, select_related et prefetch_related côté Django, le fetch join côté Doctrine. Des syntaxes différentes, une seule idée. Vous prévenez l’ORM des relations dont vous aurez besoin, pour qu’il aille les chercher d’un bloc.

Là où il faut rester mesuré

Ce n’est pas un interrupteur qu’on laisse sur ON partout. Charger toutes les relations « au cas où » ramène des données que personne n’affiche et déplace simplement le coût ailleurs. Je m’en tiens aux relations réellement utilisées par la page, pas à l’arbre complet du modèle.

Une réserve, pour finir

Compter les requêtes vous dit qu’il y a un N+1 et où regarder. Ça ne vous dit pas toujours quoi charger. Sur une page qui agrège une dizaine de relations imbriquées, le bon réglage tient parfois plus de l’ajustement que de la règle : on charge, on remesure, on retire ce qui ne sert pas. La méthode démasque le problème de façon fiable. La correction fine, elle, demande de connaître ce que la page affiche vraiment, et aucun compteur ne le sait à votre place.