Pourquoi votre application créée par IA semble lente (même si ce n'est pas le cas) : l'illusion du temps d'attente
Une application semble lente quand l'utilisateur ne reçoit aucun retour pendant l'attente, pas parce que le chargement lui-même est long. Corrigez cela avec un retour sous 100 ms, des squelettes de chargement à la place des écrans vides, et des indicateurs de progression pour les attentes de plus de trois secondes.
Votre application récupère des données en 1,2 seconde. Un être humain peut percevoir 100 millisecondes. Vous êtes 12 fois plus rapide que la perception humaine, et pourtant ça semble lent. Pourquoi ?
La latence perçue — à quel point une application paraît lente pour la personne qui l’utilise — n’a que peu à voir avec le temps de chargement réel. Ce qui compte, c’est que l’utilisateur comprenne ce qui se passe pendant qu’il attend. Lent et rapide sont des mensonges ; le retour d’information, lui, est réel.
Pourquoi mon application semble-t-elle lente même quand elle est rapide ?
Une application semble lente à cause de ce qui se passe pendant l’attente, pas à cause de sa durée réelle. Trois lacunes précises en sont responsables : aucun retour pendant le chargement, un écran vide à la place d’une mise en page visible, et aucune sensation de progression sur les opérations longues.
1. Aucun retour pendant l’attente.
Un formulaire est envoyé. Le bouton devient inactif (pratique standard, ça évite les doubles clics). Rien d’autre ne se passe. Une seconde passe. Deux secondes. L’utilisateur ne sait pas si ça traite, si c’est bloqué, s’il a perdu sa connexion, ou si ça a planté. Après deux secondes de silence, le cerveau humain envisage de fermer l’onglet.
C’est pour ça que ça semble lent même si 1,2 seconde est un temps raisonnable pour un vrai calcul. L’anxiété de l’utilisateur remplit le silence.
2. Les écrans vides.
Une page se charge. Le titre s’affiche. Puis plus rien pendant 800 ms le temps que l’application récupère la liste en dessous. La page a l’air cassée — mise en page incomplète, aucun espace réservé, juste… du chargement. Une attente de 800 ms devient une pause perçue de 5 secondes, parce que l’œil de l’utilisateur interprète l’incomplétude comme un échec.
3. Aucune sensation de progression.
Une opération longue démarre. « Chargement… » s’affiche. Et ensuite ? Est-on à 10 % ou à 90 % ? L’utilisateur a-t-il le temps de se faire un café, ou est-ce que ce sera fini dans trois secondes ? L’absence de progression crée de l’anxiété. Rapide + mystérieux paraît plus lent que lent + transparent.
Comment corriger une application qui semble lente ?
Trois corrections répondent aux trois causes ci-dessus : afficher un retour à l’instant même où l’utilisateur agit, remplir l’espace vide avec un espace réservé pendant le chargement des données, et afficher une progression réelle pour tout ce qui prend plus de quelques secondes.
Correction 1 — Afficher quelque chose immédiatement
Placez un état de chargement avant de lancer la récupération des données. Un écran squelette, un indicateur de chargement, un message « en cours… ». N’importe quoi qui dise « j’ai reçu ton tap, je m’en occupe ».
Exemple : Un formulaire de réservation est envoyé. Immédiatement, le texte du bouton change pour « Vérification des disponibilités… » et affiche un petit indicateur de chargement. C’est seulement ensuite que la requête démarre. L’utilisateur voit une réponse à son action instantanément, même si le travail réel prend 1,2 seconde. Ce retour instantané fait paraître l’attente courte.
À demander au builder : Après le clic de l’utilisateur sur le bouton principal, changez le texte du bouton et ajoutez un état de chargement avant d’envoyer la requête. C’est une seule instruction.
Test : Sur votre téléphone, déclenchez l’action. Le retour doit apparaître en moins de 100 ms. Si vous voyez 500 ms de silence avant l’état de chargement, l’utilisateur en tiendra l’application pour responsable.
Correction 2 — Remplir l’espace vide
Au lieu d’un écran blanc avec « Chargement… » dans le coin, montrez la forme de ce qui arrive.
Histoire vraie : L’application de réservation d’une organisatrice de mariages récupérait la liste des dates disponibles. Au lieu d’une page vide, elle affiche des lignes en attente — cinq rectangles gris à l’emplacement des futures dates. Quand les vraies dates se chargent, elles remplacent les rectangles. Le cerveau de l’utilisateur perçoit cela comme « instantané », parce que la page n’a jamais paru incomplète.
À demander au builder : Ajoutez une version espace réservé (squelette) de la liste ou du tableau avant de récupérer les vraies données. Quand les données arrivent, remplacez le squelette par le contenu réel. Oui, c’est un élément de plus à construire. Ça en vaut la peine, car ça réduit de moitié le temps d’attente perçu.
Test : Chargez la page sur une connexion lente (mobile, bridée en 4G). Voyez-vous une page vide ou une forme ? La forme gagne.
Correction 3 — Afficher la progression
Pour les opérations de plus de trois secondes, montrez où vous en êtes.
Histoire vraie : Un formulaire exporte 500 lignes de données vers un tableur. Cela prend 4 secondes. Sans progression : « Exportation… » (donne l’impression de 15 secondes, l’utilisateur annule). Avec progression : « Exportation de la ligne 127 sur 500 » (mise à jour toutes les 200 ms, donne l’impression de 2 secondes alors que le travail réel n’a pas changé).
Le piège de l’honnêteté : Si vous ne savez vraiment pas combien de temps ça va prendre, ne falsifiez pas la barre de progression. Une fausse barre qui se bloque à 67 % trahit la confiance bien plus qu’un honnête retour « en cours ». Une progression réelle (si vous pouvez la calculer) l’emporte toujours sur une progression factice.
À demander au builder : Pour toute opération de plus de 2 secondes, émettez des mises à jour de progression. Pour un envoi de fichier, montrez combien de Mo ont été envoyés. Pour une récupération de liste, montrez « 50 éléments chargés, récupération en cours… ». Même si vous ne connaissez pas le total, savoir qu’il se passe quelque chose change la perception.
Test : Ralentissez votre réseau en 3G et observez. Est-ce que ça semble bloqué, ou est-ce que ça semble progresser ?
Comment tester si votre application semble lente ?
Faites le test de l’inconnu : chargez votre application sur le téléphone de quelqu’un d’autre, laissez-le taper sur l’action principale sans votre aide, et demandez-lui si ça lui a semblé rapide ou lent.
S’il dit que c’est lent, vérifiez trois choses :
- A-t-il vu un retour dans les 100 ms ? (changement de texte, indicateur de chargement, changement d’état)
- A-t-il vu la forme de la page pendant l’attente ? (squelette, espace réservé, quelque chose)
- Savait-il où ça en était ? (pour les attentes de plus de 3 s)
Si l’une de ces réponses est « non », corrigez d’abord ce point-là.
La vitesse n’est pas un chiffre. Un appel API de 1,2 seconde sans aucun retour semble plus lent qu’une opération de 3 secondes où l’on voit la progression toutes les demi-secondes. La différence ne vient pas de l’application — elle vient du dialogue entre l’application et la personne qui l’utilise.
Corrigez le retour d’information. Les gens arrêtent d’accuser la lenteur quand ils comprennent ce qui se passe.