Au début, tout s’affichait instantanément. Aujourd’hui, la liste principale met huit secondes à apparaître, vos utilisateurs cliquent deux fois parce qu’ils croient que rien ne s’est passé, et quelqu’un a commencé à dire que « l’appli rame ».

Rien n’a changé dans le code. C’est le volume de données qui a changé, et il révèle des choix qui étaient invisibles quand la base était vide.

Le seuil au delà duquel un affichage est perçu comme lent est documenté : 2,5 secondes pour que le plus gros élément de la page apparaisse, mesuré sur les trois quarts des consultations. Au delà, l’utilisateur considère que quelque chose ne va pas.

La cause numéro un : une requête par ligne affichée

C’est le défaut le plus fréquent sur les applications générées, et il porte un nom chez les développeurs, le problème des requêtes en cascade.

Concrètement : votre écran affiche une liste de commandes. Pour chaque commande, il veut aussi montrer le nom du client. Le code demande donc la liste des commandes, puis, pour chacune, il repart chercher le client correspondant. Trente commandes déclenchent trente et une interrogations de la base au lieu d’une seule.

Avec trente lignes, personne ne remarque rien. Avec trois mille, l’écran attend trois mille allers-retours, chacun coûtant quelques millisecondes qui s’additionnent.

Ce défaut ne se voit jamais en développement, parce qu’on développe sur une base presque vide. Il se corrige en demandant les données en une seule fois, ce qui prend généralement quelques heures par écran concerné.

La cause numéro deux : tout charger puis trier dans le navigateur

Une application générée affiche souvent une liste en récupérant l’intégralité de la table, puis en filtrant et en triant côté navigateur. Le résultat est correct et la programmation est simple.

Le jour où la table contient quarante mille lignes, le navigateur télécharge quarante mille lignes pour en afficher vingt. Sur un ordinateur de bureau connecté en fibre, cela reste supportable. Sur un téléphone en 4G dans un couloir, l’écran ne s’affiche plus du tout.

La correction consiste à ne demander que ce qui est affiché, page par page, et à laisser la base faire le tri et la recherche. Comptez une demi-journée par écran, davantage si les filtres sont nombreux.

La cause numéro trois : les images

Une photo prise par un téléphone récent pèse plusieurs mégaoctets. Affichée dans une vignette de trois centimètres, elle est téléchargée en pleine résolution puis réduite par le navigateur.

Une galerie de vingt photos fait alors passer soixante mégaoctets sur le réseau pour afficher l’équivalent d’un timbre-poste. Le coût est double : le temps d’affichage et la facture de transfert.

La correction est mécanique et rapide. On génère des versions réduites au moment du dépôt, et l’écran affiche la taille dont il a besoin.

La cause numéro quatre : les connexions non libérées

Chaque échange avec la base occupe une place dans un nombre limité de connexions simultanées. Un code qui ouvre une connexion sans la refermer proprement épuise progressivement ce stock.

Le symptôme est déroutant : l’application fonctionne parfaitement pendant les essais, puis refuse tout le monde en milieu de journée, avant de se remettre à fonctionner après un redémarrage. Beaucoup d’équipes concluent à un problème d’hébergement et paient une formule supérieure, ce qui repousse simplement le seuil.

La cause numéro cinq : les traitements longs au mauvais endroit

Un export de tous les clients, un rapport mensuel, un envoi de courriels en masse. Quand ces traitements s’exécutent au même endroit que les écrans, ils monopolisent les ressources et l’application ralentit pour tout le monde pendant leur durée.

Le déclenchement à onze heures du matin par un utilisateur qui veut son export produit exactement l’effet observé : « c’est lent, mais seulement parfois ».

Le défaut de fond : le code se répète

Ces cinq causes se corrigent une par une. Une sixième les rend plus probables et plus coûteuses à traiter : la duplication.

L’étude de GitClear portant sur plus de 200 millions de lignes modifiées entre 2020 et 2024 montre que la part de lignes copiées-collées est passée de 8,3 % à 12,3 %, pendant que les lignes déplacées, marque d’un remaniement, tombaient de 24,1 % à 9,5 %.

Sur une application générée, cela veut dire que la même interrogation de la base est écrite dans six écrans différents. Corriger la lenteur suppose alors de retrouver les six, et une correction partielle laisse le problème en place là où on n’a pas regardé.

Comment savoir d’où vient votre lenteur

Deviner coûte cher. La mesure est rapide.

On remplit une copie de votre base avec un volume réaliste, celui que vous atteindrez dans six mois. On ouvre ensuite les écrans les plus utilisés en observant, avec les outils de développement du navigateur, ce qui est demandé et combien de temps chaque appel prend.

Le résultat est presque toujours le même : deux ou trois écrans concentrent l’essentiel du problème, et le reste de l’application se comporte correctement. C’est une bonne nouvelle, parce qu’une intervention ciblée suffit dans la plupart des cas.

Ce qu’il ne faut pas faire

Augmenter la puissance du serveur en premier. Cela masque le symptôme pendant quelques mois, coûte tous les mois, et le problème revient avec un volume plus important et une facture plus élevée.

Réécrire l’application entière. La lenteur vient rarement de l’architecture générale, elle vient de quelques endroits précis.

Ce que la lenteur coûte réellement

Le coût direct est visible sur la facture d’hébergement. Le coût indirect pèse davantage et se voit moins.

Vos utilisateurs internes contournent. Ils exportent vers un tableur, travaillent à côté, et réimportent quand ils y pensent. L’application perd son rôle de référence, et les écarts s’installent.

Vos utilisateurs externes partent. Sur un formulaire de commande, chaque seconde d’attente supplémentaire fait abandonner une partie des visiteurs. Le seuil de 2,5 secondes n’est pas une recommandation de confort, c’est le point à partir duquel le comportement change.

Vos équipes cessent de signaler. Après trois mois de lenteur, plus personne ne remonte le problème, et une vraie panne se noie dans le bruit de fond.

Enfin, la lenteur masque les autres défauts. Un écran qui met huit secondes à répondre rend impossible de distinguer un traitement lourd d’un traitement bloqué. Le jour où une tâche échoue vraiment, personne ne le voit.

Ce que nous faisons

Nous mesurons sur un volume réaliste et nous vous remettons la liste de ce qui ralentit votre application, écran par écran, avec le gain attendu et le coût de chaque correction, en français.

Vous choisissez ce que vous traitez. Chaque lot est chiffré à prix fixe, et nous mesurons de nouveau après correction pour que le gain soit constaté plutôt qu’annoncé.