Prenons un exemple concret. Sur un écran qui affiche 50 commandes avec leur client, une boucle naïve peut lancer 51 requêtes au lieu de 2. La page paraît correcte en local, puis devient lente en production dès que la base grossit. Le coût réseau et le temps d’attente s’additionnent sans que le code semble fautif. Le symptôme arrive souvent après quelques semaines, quand les données de test ne représentent plus la réalité.

La correction commence par charger les relations utiles en une requête, puis par vérifier les requêtes réellement exécutées. Un outil de profilage ou des journaux bien réglés suffisent souvent à repérer les appels répétés. J’ajoute aussi un test sur le nombre de requêtes pour éviter une régression silencieuse. Ce test reste simple : il compare le total attendu et alerte dès qu’un nouvel appel apparaît.

Cette discipline évite des optimisations tardives et rend le code plus prévisible. Une requête lente isolée se corrige plus facilement qu’une centaine d’appels dispersés. Mieux vaut traiter le N+1 au moment où la fonctionnalité est écrite, quand le contexte est encore frais.