Votre application tiendra-t-elle à dix fois plus de clients ?

Le défaut qui grandit avec le succès

Les applications générées rapidement ont souvent la même habitude : pour afficher les commandes d'un client, elles demandent à la base toutes les commandes de tous les clients, puis l'écran ne garde que les siennes. Avec cent commandes en base, personne ne remarque rien. Avec dix mille, chaque affichage télécharge plusieurs mégaoctets sur le téléphone du client.

Sur Supabase, il y a pire : l'API de Supabase plafonne par défaut chaque réponse à 1 000 lignes. Au-delà, elle renvoie les 1 000 premières (dans l'ordre de la requête), sans erreur. Une cliente fidèle ne voit plus ses anciennes commandes, et le code qui vérifie « a-t-elle déjà réservé ce créneau ? » se trompe, en silence.

Nous l'avons mesuré sur Studio Kerelune, notre application témoin : 131 ko par affichage à 100 réservations et 1,3 Mo à 1 000, contre 1 ko et 9 ko pour la même requête filtrée sur la cliente.

Vérification 1 : la requête demande-t-elle tout ?

Ouvrez votre application, les outils de développement (F12), onglet Réseau (ou Network), puis affichez une page du type « Mes commandes » ou « Mes réservations ». Cliquez sur la requête qui part vers votre base (sur Supabase, son adresse contient /rest/v1/) et regardez :

• l'adresse : si elle contient seulement select=* sans filtre comme user_id=eq.…, la requête demande toute la table (si les règles d'accès sont correctes, la base ne renverra que les lignes du client, mais la requête reste plus lente qu'une requête filtrée) ;
• la taille de la réponse : comparez-la au nombre de lignes réellement affichées à l'écran. Une réponse de plusieurs centaines de ko pour trois lignes affichées signe le problème ;
• l'onglet Réponse : si vous y voyez les commandes d'autres clients, vous avez en plus un problème de règles d'accès (voir notre guide Supabase : vérifier vos règles d'accès).

Dans le code, le même défaut se lit ainsi : une requête sans filtre, suivie d'un .filter(...) en JavaScript.

Vérification 2 : la limite silencieuse des 1 000 lignes

Sur Supabase, la limite se règle dans les paramètres du projet (rubrique Data API, anciennement API, réglage Max rows). Ne la montez pas pour « réparer » : vous déplaceriez le problème et alourdiriez chaque réponse. Demandez-vous plutôt, pour chaque table : combien de lignes aura-t-elle dans un an ? Si la réponse dépasse 1 000 et qu'une page lit cette table sans filtre ni pagination, cette page cassera ce jour-là.

Vérification 3 : les requêtes en boucle

Toujours dans l'onglet Réseau, rechargez une page de liste et comptez les requêtes vers la base. Une liste de vingt éléments qui déclenche vingt et une requêtes (une pour la liste, puis une par élément) a un défaut classique : chaque requête ajoute son aller-retour, et la page devient lente dès que la liste s'allonge. Une seule requête avec les jointures nécessaires fait le même travail.

Vérification 4 : les index

Une recherche sur une colonne sans index oblige la base à lire toute la table. Dans le SQL Editor de Supabase, vous pouvez demander à la base comment elle exécute une requête :

explain analyze
select * from commandes where client_id = 'un-identifiant';

Remplacez un-identifiant par un vrai identifiant copié depuis la table, sinon la base renverra une erreur. Si la réponse contient Seq Scan sur une grande table, la base lit toutes les lignes ; un index sur client_id réglerait la question. Sur une petite table, c'est normal : le problème n'apparaît qu'avec le volume. Plus simple encore : le menu Advisors, puis Performance Advisor, signale notamment les clés étrangères sans index, et le rapport Query Performance suggère des index pour les requêtes les plus lentes.

Le test qui tranche : simuler dix fois plus

Dans une copie de votre base (jamais en production), générez des données fictives à la hauteur de vos ambitions, dix ou cent fois le volume actuel, puis rouvrez vos pages principales en surveillant l'onglet Réseau. Ce qui était instantané et devient lent, ou ce qui ne renvoie plus tout, vous montre où ça lâchera. C'est exactement ce que nous avons fait pour le constat J de Studio Kerelune, de 100 à 50 000 réservations.

Si vous avez trouvé un problème

Les corrections sont rarement longues : filtrer dans la requête plutôt que dans l'écran, paginer les historiques, regrouper les requêtes en boucle, ajouter les index sur les colonnes recherchées. Ce qui prend du temps, c'est de trouver tous les endroits concernés, puis de vérifier qu'on n'a rien cassé : d'où l'intérêt de tests sur les parcours principaux.

Ce que cette vérification ne couvre pas

Le temps de chargement de l'interface elle-même (poids du code, images, polices : un autre guide), les fonctions serveur lentes, les appels à des services externes sans délai maximal, et le coût de l'hébergement quand le volume monte. C'est ce que couvre l'axe « qualité et performance » de notre diagnostic.