Pourquoi votre application ralentit quand elle se remplit
Au début, tout va vite. L’application s’ouvre en un instant, les listes défilent, rien ne bronche. Six mois plus tard, les mêmes écrans mettent deux secondes à s’afficher et vos utilisateurs signalent des choses qui « ne s’affichent pas toujours ».
Personne n’a ralenti le code entre temps. Ce qui a changé, c’est la quantité de données qu’il traverse. Et la vraie question n’est pas « combien d’utilisateurs supporte l’application », mais qu’est-ce qui, dans cette application, coûte plus cher à chaque élément ajouté.
Le 16 septembre 2026, nous avons ouvert le code de BeeDone, une de nos propres applications, pour répondre exactement à cette question sur un seul écran : la liste des tâches du jour. Cet article reprend ce que cet audit a trouvé, parce que les trois mécanismes en cause sont les plus courants du marché, et qu’aucun ne demande de savoir coder pour être détecté.
Le bug « aléatoire » n’est presque jamais aléatoire
Le symptôme signalé était celui-ci : on accepte une tâche partagée, la photo de la personne n’apparaît pas. On coche une autre tâche sans rapport, et la photo apparaît. Le genre de comportement qu’on classe en « bug d’affichage aléatoire » et qu’on ne reproduit jamais devant le développeur.
Il n’avait rien d’aléatoire. Une ligne de code écrite deux ans plus tôt comparait chaque nouvelle version d’une tâche à la précédente et décidait si l’écran valait la peine d’être rafraîchi. Cette comparaison portait sur 6 informations sur les 21 que contient une tâche. Toute mise à jour qui ne touchait que les 15 autres était écartée. Pas retardée : écartée. Elle ne revenait qu’au changement suivant, en auto-stop.
Ce filtre avait été écrit pour rendre l’application plus rapide. C’est aujourd’hui le seul endroit de cette application capable de perdre une donnée sans que rien ne le signale.
C’est le premier enseignement, et il est désagréable : une optimisation posée au mauvais endroit ne se contente pas d’être inutile, elle devient une source de bugs que personne ne cherche là. Elle est invisible en recette, parce qu’en recette on teste une tâche, pas cinquante, et on teste ce qui change, pas ce qui ne change pas.
Les trois choses qui grandissent avec vos données
Une application est lente quand elle fait un travail proportionnel à ce qu’elle contient. L’audit n’a trouvé que trois familles de coûts sur cet écran. Il y en a rarement plus, et elles se retrouvent presque partout.
| Le mécanisme | Ce qui se passe | Ce que l’utilisateur ressent |
|---|---|---|
| Une connexion par élément | Chaque ligne de la liste ouvre sa propre connexion à la base de données, et ne la referme pas en quittant l’écran | L’application chauffe, consomme de la batterie, et devient lente après plusieurs allers-retours |
| Tout dessiné, même hors écran | La liste construit ses 200 lignes alors que l’écran n’en montre que douze, images comprises | L’ouverture de l’écran met de plus en plus de temps, proportionnellement au contenu |
| Un changement redessine tout | Un détail change sur le profil de l’utilisateur, et les 50 lignes se redessinent | Des à-coups au défilement, des animations qui sautent |
Le point commun des trois : ils sont indolores au lancement. Avec cinq tâches dans la base, cinq connexions et cinq lignes dessinées ne se voient pas. Le coût existe dès le premier jour, il n’est simplement pas encore visible.
Ce que l’audit a compté
Voici les comptes relevés sur cet écran, dans l’hypothèse d’un compte bien rempli : 50 tâches en attente et 20 habitudes.
| Ce qu’on compte | Constaté | Visé | Ce qui change |
|---|---|---|---|
| Connexions ouvertes à la base | 24 | 5 | Une connexion partagée au lieu d’une par élément |
| Connexions refermées en quittant l’écran | 0 | 0 | Assumé des deux côtés, mais borné dans la cible |
| Lignes construites à l’ouverture | 50 | ~12 | Seul ce qui est à l’écran est construit |
| Lignes redessinées quand le profil change | 50 | 0 | Comparaison par contenu, pas par identité |
| Lignes redessinées quand une tâche est modifiée | 50 | 1 | Chaque ligne ne regarde que sa propre tâche |
| Informations de la tâche qui atteignent l’écran | 6 sur 21 | 21 sur 21 | Suppression du filtre décrit plus haut |
| Connexions abandonnées après 20 allers-retours d’écran | 20 | 0 | Fermeture à la sortie de l’écran |
Une précision qui compte plus que les chiffres eux-mêmes. Ces comptes viennent de la lecture du code, pas d’une mesure sur téléphone. Ce sont des comptes structurels, et ils doivent être confirmés par des compteurs automatiques avant d’être revendiqués comme des résultats. Dans notre propre suivi, ils restent écrits « à confirmer » tant que ces compteurs n’ont pas tourné.
C’est une distinction que vous pouvez exiger de n’importe quel prestataire : un chiffre déduit du code et un chiffre mesuré sur un appareil ne se présentent pas de la même façon. Quand on vous annonce « trois fois plus rapide » sans dire lequel des deux c’est, la réponse vous apprend plus que le chiffre.
Pourquoi la solution n’est pas « optimiser davantage »
Le réflexe, devant ces chiffres, est d’ajouter des protections. C’est exactement ce qui a produit le bug du début.
La correction va dans l’autre sens : on retire le filtre, et on obtient la même économie plus bas et plus finement. Chaque ligne ne regarde plus que sa propre tâche. Une modification sur une tâche redessine une ligne, pas cinquante. Une modification sur rien ne redessine rien, parce que deux versions identiques sont reconnues comme identiques.
La différence est structurelle. Un filtre placé en haut décide pour tout le monde et se trompe pour tout le monde. Une règle placée au niveau de chaque ligne ne peut se tromper que sur cette ligne.
C’est la même logique que celle décrite dans comment savoir si votre application est maintenable : ce qui rend une correction sûre, ce n’est pas la quantité de précautions, c’est le fait qu’une modification reste locale.
Comment on prouve qu’un écran est réactif
« C’est réactif » n’est pas une phrase vérifiable. Elle se transforme en tests qui échouent avant la correction et qui passent après. Sur cet écran, ils ont été écrits avant de toucher au code :
| Le test | Ce qu’il vérifie | État au départ |
|---|---|---|
| 21 informations, 21 cas | Chaque information modifiée fait bouger la ligne | 15 en échec |
| Compteur de connexions | Combien de connexions sont ouvertes, et refermées | 1 par élément |
| Compteur de redessins | Combien de lignes bougent quand le profil change | Les 50 |
| Charge de 200 tâches | Combien de lignes sont réellement construites | Les 200 |
| 20 allers-retours d’écran | Combien de connexions restent abandonnées | 20 |
| Captures d’écran comparées | 3 largeurs d’écran, mode clair et sombre, taille de texte doublée | Nouveau |
La dernière ligne mérite un mot. Les trois derniers défauts visuels de cette application ont tous été attrapés par une capture d’écran regardée à l’œil, jamais par un test automatique : un élément qui dépassait de 43 pixels, un texte coupé à 200 % de taille, un dessin affiché deux fois. Un test automatique vérifie ce qu’on a pensé à lui demander. Une capture montre ce à quoi on ne pensait pas.
Et une limite honnête : aucun de ces tests ne mesure la fluidité réelle. Ça demande un relevé sur un vrai appareil, en conditions de production, avant et après. Tant que ce relevé n’existe pas, l’amélioration de fluidité reste une hypothèse.
Ce que cette correction ne règle pas
L’audit a identifié un problème qu’il ne corrige pas : l’application charge toujours l’intégralité d’une liste d’un coup. Un écran plafonne à 50 éléments sans moyen d’en voir plus, un autre n’a aucune limite. Réparer ça touche la façon dont l’application parle à sa base de données, donc c’est un chantier séparé, chiffré séparément.
Le risque, à ce moment précis, n’est pas technique. Il est dans le vocabulaire. Le jour de la livraison, il serait facile d’annoncer que « la performance des listes est réglée ». Elle ne le sera pas. Ce qui sera réglé, c’est le travail que fait l’écran. Pas la quantité de données qu’il va chercher.
Un prestataire qui nomme lui-même ce qui reste à faire vous coûte moins cher qu’un prestataire qui vous laisse le découvrir. C’est l’un des rares signaux fiables avant signature, et il ne demande aucune compétence technique : il suffit de remarquer si la phrase « voilà ce que ça ne couvre pas » est prononcée sans que vous ayez à la demander.
Les quatre questions à poser
Elles se posent à une agence, à un développeur interne, ou en recette avant d’accepter une livraison.
- « Qu’est-ce qui, dans cet écran, coûte plus cher à chaque élément ajouté ? » Une réponse correcte cite deux ou trois mécanismes précis. Une réponse vague veut dire que personne n’a compté.
- « Ce chiffre, il est lu dans le code ou mesuré sur un téléphone ? » Les deux sont utiles. Les confondre ne l’est pas.
- « Comment vous savez que cet écran affiche bien toutes les mises à jour ? » S’il existe un test par information affichée, c’est vérifié. Sinon c’est espéré.
- « Qu’est-ce que cette correction ne règle pas ? » Si la réponse est « rien », la question n’a pas été travaillée.
Ces quatre questions ne coûtent rien à poser et se répondent en quelques minutes. Le questionnaire de cadrage les reprend, et le périmètre d’une application livrée est détaillé sur la page application mobile.
En résumé
- Une application ne ralentit pas à cause du nombre d’utilisateurs, mais parce qu’une partie de son travail est proportionnelle à ce qu’elle contient.
- Trois mécanismes suffisent à l’expliquer presque partout : une connexion par élément, tout dessiné même hors écran, un changement qui redessine tout.
- Un bug d’affichage « aléatoire » est presque toujours déterministe. Sur l’audit de BeeDone du 16 septembre 2026, un filtre d’optimisation laissait passer 6 informations sur les 21 que porte une tâche.
- Une optimisation posée trop haut décide pour tout le monde et se trompe pour tout le monde. La bonne correction consistait à retirer ce filtre, pas à en ajouter un.
- Comptés sur ce seul écran : 24 connexions ouvertes, 50 lignes construites pour un écran qui en montre douze, 20 connexions abandonnées après vingt allers-retours. Comptes lus dans le code, à confirmer par compteurs automatiques.
- « C’est réactif » se prouve par des tests qui échouent avant et passent après, plus des captures d’écran regardées à l’œil : les trois derniers défauts visuels ont tous été attrapés comme ça.
- Aucun test automatique ne mesure la fluidité réelle. Ça demande un relevé sur un vrai appareil, avant et après.
- Quatre questions suffisent en recette : qu’est-ce qui coûte par élément, chiffre lu ou mesuré, comment on sait que tout s’affiche, et ce que la correction ne règle pas.