Pourquoi votre appli créée avec l'IA paraît lente (et quoi y faire)

Votre appli créée avec l’IA fonctionne. Les boutons vont là où il faut, les écrans s’alignent, les données s’enregistrent. Mais quelque chose cloche. Les pages mettent un peu trop de temps à charger. Une liste de cinquante éléments se fige une seconde. Cliquer sur « enregistrer » vous fait attendre, puis attendre encore un peu, puis vous demander si vous devriez recliquer. Rien n’est cassé — c’est juste qu’elle paraît lente.

Si vous êtes un fondateur non technique qui lance avec un créateur d’applis avec IA, c’est l’un des moments « je ne sais pas ce qui cloche » les plus fréquents. La bonne nouvelle, c’est que 80 % des applis créées avec l’IA qui sont lentes le sont pour la même poignée de raisons. Aucune ne vous oblige à apprendre comment marchent les bases de données. Toutes ont des solutions que vous pouvez demander à votre créateur avec IA en langage clair.

Cet article est l’antisèche.

Pourquoi « lent » se résume généralement à quatre choses

Quand les utilisateurs disent qu’une appli paraît lente, ils ne veulent presque jamais dire « le serveur est sous-dimensionné ». Ils veulent dire l’une de ces quatre choses :

1. Le premier affichage est lent — ils cliquent sur un lien et fixent un écran blanc pendant deux secondes avant que quoi que ce soit n’apparaisse.
2. Une longue liste est poussive — faire défiler, filtrer, ou charger « tous mes projets » prend plus de temps que de faire défiler Instagram.
3. Une action prend trop de temps sans leur dire ce qui se passe — ils cliquent sur « enregistrer » ou « envoyer » et rien ne réagit visiblement.
4. On pose trop de questions à la base de données — les pages qui affichent des données venant de plusieurs endroits récupèrent chaque morceau séparément et empilent les temps d’attente.

C’est tout. Presque toutes les applis lentes créées avec l’IA que j’ai examinées le sont pour l’une de ces quatre raisons. Voici comment repérer chacune et quoi demander à votre créateur d’y faire.

Raison de lenteur n° 1 : le premier affichage

À quoi ça ressemble : vous cliquez sur un lien vers votre appli, la barre d’URL finit de charger, mais la page reste blanche une seconde ou deux avant que quoi que ce soit n’apparaisse.

Ce qui le cause généralement : l’appli charge tous les morceaux de JavaScript dont elle pourrait avoir besoin avant de vous montrer quoi que ce soit. Les créateurs d’applis avec IA ont tendance à regrouper généreusement — mieux vaut inclure quelque chose que de l’oublier — et ce paquet grossit à mesure que vous ajoutez des fonctionnalités.

Quoi demander à votre créateur avec IA : « Le premier chargement de page paraît lent. Tu peux découper les paquets JavaScript par route pour que la page d’accueil n’ait pas à télécharger toute la section d’administration ? » Ou, plus simplement : « Ajoute le chargement différé pour les routes qui ne sont pas la page d’accueil. » La plupart des frameworks modernes le gèrent en une ou deux lignes de configuration. L’IA sait comment faire — il suffit de demander.

Tant que vous y êtes : « Y a-t-il de grosses images sur la page d’atterrissage qu’on pourrait optimiser ? » Une photo de bannière de 4 Mo plombe la vitesse ressentie plus que n’importe quel problème de code.

Raison de lenteur n° 2 : la longue liste

À quoi ça ressemble : vous avez une liste — projets, contacts, publications, n’importe quoi — et une fois qu’elle dépasse quarante ou cinquante éléments, le défilement saccade ou le filtrage prend un temps perceptible.

Ce qui le cause généralement : l’appli affiche chaque élément sur la page d’un coup, même ceux que vous ne pouvez pas voir. Avec dix éléments, c’est très bien. Avec cinq cents, le navigateur s’étrangle.

Quoi demander à votre créateur avec IA : « La liste des projets est lente quand il y a beaucoup d’éléments. On peut ajouter la pagination, ou virtualiser la liste pour que seules les lignes visibles soient affichées ? » La pagination (« afficher 20 par page, avec des boutons suivant/précédent ») est la solution la plus facile. La virtualisation (« n’afficher que ce qui est à l’écran à mesure que l’utilisateur défile ») paraît plus fluide mais demande un peu plus de travail. L’une ou l’autre fait l’affaire.

Si la liste a aussi une recherche ou un filtrage : « Est-ce que le filtre de recherche peut se faire côté serveur plutôt que dans le navigateur ? » Le filtrage côté serveur signifie que le navigateur ne détient jamais que les lignes correspondantes, pas tout le jeu de données.

Raison de lenteur n° 3 : l’attente silencieuse

À quoi ça ressemble : vous cliquez sur « enregistrer », « envoyer » ou « générer ». Rien ne se passe visiblement. Deux secondes plus tard, l’écran se met à jour et vous réalisez que ça travaillait tout du long.

Ce qui le cause généralement : l’appli fait un vrai travail — enregistrer dans une base de données, appeler une API — mais le créateur avec IA n’a pas ajouté d’état de chargement. Donc de votre point de vue, le clic n’a rien fait.

Ce n’est pas vraiment un problème de performance. C’est un problème de performance ressentie, et ceux-là sont souvent plus pénibles que les vrais. Une action de 200 millisecondes sans retour paraît plus lente qu’une action de 2 secondes avec un indicateur d’activité, parce que le cerveau de l’utilisateur est dans le noir.

Quoi demander à votre créateur avec IA : « Ajoute un état de chargement à chaque bouton qui déclenche une action. Affiche un indicateur d’activité ou le texte “Enregistrement…” pendant que ça travaille, et désactive le bouton pour que les utilisateurs ne puissent pas double-cliquer. » C’est la correction de performance au meilleur rapport effort/résultat de toute appli et elle ne coûte presque rien.

Tant que vous y êtes : « Pour les actions dont on connaît le résultat à l’avance, peut-on mettre à jour l’interface de façon optimiste — afficher le changement immédiatement et revenir en arrière si le serveur le rejette ? » Les mises à jour optimistes sont la raison pour laquelle le bouton « j’aime » des applis sociales paraît instantané même quand votre téléphone a une réception catastrophique.

Raison de lenteur n° 4 : la base de données bavarde

À quoi ça ressemble : une page qui affiche une liste d’éléments, chacun avec une info supplémentaire — comme une liste de projets avec le nombre de tâches dans chacun — met bien plus de temps à charger qu’une simple liste.

Ce qui le cause généralement : la page charge les projets en une requête, puis charge le nombre de tâches de chaque projet dans une requête séparée. Dix projets ? Onze requêtes. Cent projets ? Cent une. Ça s’appelle une « requête N+1 », et c’est le bug de performance de base de données le plus fréquent dans les applis créées avec l’IA, parce que l’IA optimise pour un code qui se lit clairement, pas pour un code qui s’exécute efficacement.

Quoi demander à votre créateur avec IA : « Cette page fait une requête par élément. On peut récupérer toutes les données liées en une seule requête — une jointure ou un agrégat ? » Vous n’avez besoin de savoir ce que ces deux mots veulent dire. L’IA le sait. Lui montrer la page lente et dire « je pense que ça a un problème de N+1 » suffit généralement.

Vous pouvez repérer les problèmes de N+1 sans aucun outil : ouvrez la page, comptez le temps que ça prend, puis ajoutez dix fois plus d’éléments à la liste sous-jacente. Si la page est maintenant dix fois plus lente, vous avez un N+1. Si elle n’est qu’un poil plus lente, vous n’en avez pas.

Un mot sur l’optimisation prématurée

Un piège dans lequel tombent les nouveaux créateurs : essayer de rendre chaque page rapide avant que quiconque n’utilise l’appli. Ne le faites pas.

Le travail de performance a un coût réel. Ajouter de la pagination à une liste qui n’aura jamais plus de vingt lignes est un effort gâché. Optimiser une page qui se charge deux fois par jour est un effort gâché. Découper les paquets pour un outil interne à trois utilisateurs est un effort gâché. Le bon moment pour réparer une page lente, c’est quand vous pouvez nommer la page, l’action et une personne que ça a agacée.

Alors construisez-la normalement d’abord. Lancez-la. Observez comment elle est utilisée. Quand quelque chose paraît lent à une vraie personne — y compris vous — associez le symptôme à l’une des quatre catégories ci-dessus et demandez cette correction précise. Vous obtiendrez une appli plus rapide sans passer une semaine sur une infrastructure que vos utilisateurs ne remarqueront jamais.

Comment parler de vitesse à votre créateur avec IA

Un schéma qui marche : décrivez le symptôme, pas la solution. L’IA est bien meilleure pour choisir la bonne correction que vous ne le penseriez, tant qu’elle sait ce qui cloche réellement.

De bonnes demandes à copier :

• « Quand j’ouvre la page des réglages, il y a une seconde de délai avant que quoi que ce soit n’apparaisse. On peut chercher ce qui bloque le premier affichage ? »
• « Le tableau de bord met plus de temps à charger que la page d’accueil alors qu’il affiche moins de données. On peut regarder comment il récupère ses données ? »
• « Quand je clique sur “enregistrer les modifications” sur la page de profil, rien ne se passe pendant deux secondes. Ajoute un état de chargement et assure-toi que le bouton ne peut pas être double-cliqué. »
• « Teste cette liste avec 500 faux éléments et dis-moi où sont les ralentissements. »

La dernière est sous-estimée. Demander à l’IA de générer des données de test et d’essayer la page elle-même est l’une des choses les plus utiles que vous puissiez faire. Elle trouvera souvent les points lents avant vos utilisateurs — et proposera la correction dans la même réponse.

La vitesse dans les applis créées avec l’IA n’est pas une affaire de magie. Il s’agit de savoir dans lequel des quatre paniers tombe votre problème, et de demander la bonne correction en mots clairs. Faites ça, et « paraît lente » devient « paraît bien » avec une poignée de petits changements ciblés — pas une réécriture.