Réponse courte. Une application est lente pour cinq raisons qui se règlent dans le code et une seule qui se règle dans l'hébergement. Les cinq : des écrans qui chargent tout le code et des images originales de 4 Mo ; des listes sans pagination ; une requête par ligne au lieu d'un appel agrégé ; des recherches sans index ; et tout rechargé à chaque ouverture faute de cache. Ce qu'on construit : un budget par écran écrit avant le code, cinq cents kilo-octets, trois requêtes, contenu principal affiché en 2,5 secondes sur un Android de 2019 en 3G simulée ; des images réduites et converties à l'envoi ; un appel d'API par écran, paginé, compressé, mis en cache ; des index sur ce qui est cherché et trié ; et la mesure au 75e percentile chez les vrais utilisateurs, par écran et par réseau, vérifiée par la chaîne de livraison. Six semaines, dont la première sans une ligne de code.
Ce guide s'adresse au gérant dont les vendeurs attendent devant l'écran, au fondateur installé en France qui ne voit l'application que depuis la fibre, et au responsable qui doit comparer un devis « optimisation » avec un autre. Il ne redit pas où placer les serveurs, décrit dans le guide sur l'hébergement, ni comment une application travaille sans réseau, décrit dans le guide sur la synchronisation ; il décrit ce qui se construit pour qu'elle soit rapide quand il y a du réseau, même mauvais, et il prolonge notre page sur l'ingénierie logicielle.
Ce que les chiffres disent
Les seuils de vitesse ont une définition publique, et elle est exigeante. Les indicateurs que Google utilise pour juger une page, les Core Web Vitals, fixent trois seuils « bons » : le contenu principal affiché « dans les 2,5 secondes » suivant le début du chargement, une réaction aux gestes de « 200 millisecondes ou moins », et un décalage visuel de « 0,1 ou moins » ; et ils demandent de mesurer « le 75e percentile des chargements, séparément sur mobile et sur ordinateur ». Ce que cela impose : on ne mesure pas une moyenne, qui cache le quart des utilisateurs les plus mal servis, mais le point au-dessous duquel trois clients sur quatre se trouvent ; et on le mesure sur mobile, séparément.
Les images sont le premier poste, et le gain est documenté. Google indique qu'une image WebP avec pertes est « 25 à 34 % plus petite qu'une image JPEG comparable » à qualité égale, et qu'en sans perte elle est « 26 % plus petite » qu'un PNG ; mais le gain qui compte vraiment vient avant le format : une photo prise au téléphone pèse plusieurs méga-octets et s'affiche dans un carré de 300 pixels, et la réduire à cette taille divise son poids par dix ou plus avant toute conversion. Ce que cela impose : les images sont redimensionnées et converties à l'envoi, côté serveur, en plusieurs tailles, et l'écran demande la taille qu'il affiche.
Le réseau de vos clients n'est pas celui du développeur, et les chiffres publics ne vous diront pas lequel c'est. Les médianes de débit mobile publiées pour l'Algérie varient fortement selon la source et la période, de l'ordre de quarante à soixante-dix mégabits par seconde dans les rapports de 2025 et 2026 qui s'appuient sur les mesures de Speedtest ; nous ne retenons aucun de ces chiffres, parce qu'une médiane nationale ne dit rien du vendeur dans l'arrière-boutique en 3G ni du client dans un sous-sol. Ce que cela impose : on relève les temps réels chez vos utilisateurs, par type de réseau et par wilaya, et on construit pour le 75e percentile de ce qu'on a mesuré, pas pour la moyenne nationale. Ce que nous n'avons pas trouvé : une étude publique des téléphones réellement utilisés en Algérie par année de fabrication ; ce que nous voyons dans les journaux de nos projets, c'est encore des téléphones de 2019, et nous le disons comme une observation.
Le même écran, sur un réseau faible, avant et après
La vitesse ne se comprend pas sur un principe mais sur un écran réel, chargé deux fois sur le même réseau.
Avant. La page HTML pèse 180 Ko et met plus d'une seconde. Trois scripts de 1,4 Mo au total, tout le code de l'application alors que l'écran n'en utilise qu'une fraction, en prennent trois et demie de plus. Douze images arrivent telles que le téléphone qui les a prises les a envoyées, 3,2 Mo, et occupent le réseau pendant sept secondes. Puis l'API : un premier appel renvoie toutes les commandes de l'année, 640 Ko, et cinq autres appels suivent l'un après l'autre pour les clients, les produits et les statuts, parce que le code en fait un par type d'information. L'écran est utilisable à 9,8 secondes, et le vendeur a déjà rappuyé deux fois.
Après. La même liste, le même réseau. La page HTML pèse 40 Ko. Un seul script, celui de cet écran, 220 Ko, et le reste de l'application se charge plus tard, quand on en a besoin. Quatre images, celles qui sont visibles, réduites à la taille affichée et converties, 280 Ko ; les suivantes viennent au défilement. Un seul appel d'API, agrégé, paginé à cinquante lignes, compressé, 38 Ko, qui renvoie la page avec ses clients et ses produits. L'écran est utilisable à 1,9 seconde, et à la deuxième ouverture, le cache sert la page sans réseau. Les chiffres sont un exemple construit à partir de cas réels ; l'ordre de grandeur, cinq fois plus rapide sans changer de serveur, est celui que nous mesurons.
«Cinq fois plus rapide sans changer de serveur : c'est l'ordre de grandeur que nous mesurons quand l'écran passe de vingt appels à un.»
Six lenteurs que nous trouvons presque toujours
Six lenteurs reviennent sur presque toutes les applications que nous reprenons, et chacune a une construction qui la règle.
L'écran de 5 Mo : tout le code chargé d'un coup et des images originales ; budget par écran, code découpé, images réduites et converties à l'envoi. La liste de 2 000 lignes : toutes les commandes de l'année dans un appel, puis l'écran qui bloque en les dessinant ; pagination côté serveur à cinquante lignes, tri et filtre dans la requête, défilement qui charge la suite. Une requête par ligne : pour chaque commande un appel pour le client et un pour le produit, deux cents appels pour une page ; un appel agrégé, et côté base une jointure plutôt qu'une boucle ; c'est la lenteur la plus fréquente et la plus invisible sur le wifi du développeur.
La recherche sans index : chercher un client par téléphone parcourt toute la table, quatre secondes à cent mille lignes et pire chaque mois ; index sur les colonnes cherchées et triées, plan d'exécution lu avant la mise en production, seuil de 300 ms au 75e percentile ; la recherche dans un catalogue a ses propres règles, décrites dans le guide sur la recherche. Tout rechargé à chaque ouverture : catalogue, images et réglages repartent de zéro ; cache HTTP avec validation, cache local des données stables, réseau seulement pour ce qui a changé. Le serveur loin et lent : c'est la seule lenteur qui se règle dans l'hébergement, et seulement après les cinq autres, parce qu'un écran qui fait vingt appels est lent même sur le meilleur serveur.
La vitesse d'une application, en cinq couches
Derrière ces six lenteurs, cinq couches, et celle où l'on gagne le plus n'est pas celle qu'on croit.
Le téléphone et le réseau : un Android de 2019, une 3G ou un wifi partagé, une batterie en mode économie ; vous ne les changez pas, vous construisez pour eux et vous testez dessus. L'écran : le code de cet écran seulement, des images à la taille affichée, un rendu qui montre quelque chose avant d'avoir tout reçu ; chaque écran a son budget. L'API : un appel agrégé par écran, pagination, compression, en-têtes de cache, temps de réponse mesuré au 75e percentile ; c'est la couche où l'on gagne le plus, en supprimant des appels plutôt qu'en les accélérant.
La base de données : index sur ce qui est cherché et trié, jointures au lieu de boucles, plan d'exécution lu, requêtes lentes journalisées ; une table qui grossit chaque mois fait apparaître ce qui n'était pas visible au lancement, et c'est pour cela que la mesure continue après la mise en production. La mesure : temps réels relevés chez les utilisateurs, par écran, par type de réseau, par wilaya, au 75e percentile, et budget vérifié à chaque livraison, sur un écran bâti comme le tableau de bord du gérant ; sans elle, « ça rame » et « ça marche » sont deux opinions, et la discussion avec le prestataire ne finit jamais.
Le budget de performance, écrit avant le code
Le budget est la pièce qui change tout : six chiffres par écran, écrits avant la première ligne et vérifiés à chaque livraison.
Six mesures pour l'écran « liste des commandes », sur un Android de 2019 en 3G simulée : le poids du premier écran, HTML, scripts et images visibles compressés, 500 Ko ; les images visibles, 200 Ko ; les scripts avant affichage, 250 Ko ; les requêtes avant affichage, trois ; le temps de réponse de l'API au 75e percentile, 300 ms ; et le contenu principal affiché, 2,5 secondes, le seuil public. Sur le dessin, une barre dépasse : les images pèsent 280 Ko parce qu'une photo de produit arrive encore à sa taille d'origine ; la livraison est refusée, et la démonstration suivante montre la correction.
Trois règles tiennent le budget. Il est écrit par écran, pas pour l'application, parce que la caisse se joue en centaines de millisecondes par geste et la carte en secondes. Il est mesuré sur le téléphone et le réseau de vos clients, pas sur ceux du développeur. Et il vit dans le dépôt de code, vérifié par la chaîne de livraison à chaque version, pas dans un document relu une fois : c'est ce qui empêche la vitesse de repartir à la version suivante, comme le guide sur la livraison le décrit pour les tests. Les valeurs du dessin sont un exemple ; les seuils de 2,5 secondes et de 300 ms sont ceux que nous écrivons par défaut.
«Sans mesure chez les vrais utilisateurs, « ça rame » et « ça marche » sont deux opinions, et la discussion ne finit jamais.»
Six écrans, et le budget que nous écrivons pour chacun
Un budget par écran, parce que six écrans n'ont pas la même vitesse à tenir.
La liste des commandes : cinquante lignes avec client, montant et statut ; 500 Ko, trois requêtes, 2,5 secondes, API à 300 ms. La fiche produit avec photos : 600 Ko dont 300 Ko d'images visibles, les suivantes au défilement ; c'est l'écran du portail B2B que les détaillants ouvrent le plus. La recherche dans le catalogue : résultats pendant la frappe sur dix mille références, 200 ms par frappe au 75e percentile, index de recherche et jamais de parcours de table. Le tableau de bord du gérant : six chiffres par agence en une requête sur des agrégats précalculés, 1,5 seconde, rafraîchi toutes les soixante secondes et pas à chaque geste.
La caisse en magasin : 100 ms par geste, catalogue en cache local, et elle fonctionne sans réseau, comme le guide sur la caisse l'exige. La carte des livraisons : deux cents points regroupés, fond de carte en cache, deux secondes, mise à jour par événements et non par rechargement, selon le guide sur la plateforme de livraison. Chaque ligne est écrite au cahier des charges et mesurée à chaque démonstration ; un écran qui n'a pas de budget est un écran dont personne ne saura dire s'il est lent.
Vu ailleurs : les seuils publics, et ce qui se transpose
Deux sources disent l'essentiel. Les Core Web Vitals disent qu'une page est bonne quand le contenu principal s'affiche en 2,5 secondes, qu'elle réagit en 200 ms et ne bouge pas, mesurés au 75e percentile sur mobile ; ce qui se transpose, c'est le percentile et la séparation mobile, pas seulement les seuils, parce qu'une moyenne cache le quart de vos clients. La documentation de Google sur WebP dit 25 à 34 % de gain sur le JPEG ; ce qui se transpose, c'est que le format vient après la taille, et que les deux se font à l'envoi, côté serveur, une fois pour toutes.
Ce que ces sources ne disent pas : quels téléphones et quels réseaux ont vos clients, et quel écran est vraiment lent ; la première semaine du projet y répond, sans une ligne de code, en relevant les temps réels chez vos utilisateurs.
Les règles d'une application rapide chez vos clients
Six règles, écrites la première semaine. Un budget par écran, écrit avant le code. Mesuré sur le téléphone et le réseau de vos clients, pas du développeur, au 75e percentile. Les images sont réduites et converties à l'envoi, et l'écran demande la taille qu'il affiche. Un appel d'API par écran, agrégé, paginé, compressé, mis en cache. Des index sur ce qui est cherché et trié, et les requêtes lentes journalisées. Le budget vit dans la chaîne de livraison, et une version qui le dépasse ne part pas.
Une septième règle porte sur le devis : « optimisation des performances » n'est pas une exigence, c'est une phrase ; l'exigence s'écrit « budget par écran avec poids, requêtes, contenu principal en 2,5 s et API en 300 ms au 75e percentile ; mesure chez les vrais utilisateurs par écran, réseau et wilaya ; images redimensionnées et converties à l'envoi en plusieurs tailles ; code découpé par écran ; pagination côté serveur ; un appel agrégé par écran, pas de requête par ligne ; index et plan d'exécution ; cache HTTP et local ; tests sur Android de 2019 en 3G simulée ; budget vérifié par la chaîne de livraison », et elle se vérifie comme le guide sur le cahier des charges le recommande. Un devis qui propose « un serveur plus puissant » en première ligne a proposé la sixième lenteur avant les cinq autres.
Six applications, et l'écran qui les ralentissait
Six applications que nous avons reprises ou construites, et pour chacune l'écran qui était lent et ce qui l'a réglé.
- L'application des commerciaux terrain, décrite dans le guide dédié. La fiche client chargeait l'historique complet des commandes ; pagination et agrégats, et la tournée du matin ne commence plus par une attente.
- Le portail de commande B2B, décrit dans le guide dédié. Le catalogue envoyait les photos originales des fournisseurs ; réduites à l'envoi, le catalogue passe de 11 Mo à 600 Ko.
- La caisse, décrite dans le guide dédié. Chaque article ajouté faisait un appel au serveur ; catalogue en cache local, 100 ms par geste, et la file au comptoir a disparu.
- Le tableau de bord, décrit dans le guide dédié. Six chiffres recalculés sur toute la table à chaque ouverture ; agrégats précalculés, une requête, 1,5 seconde.
- L'application reprise d'un prestataire disparu, décrite dans le guide dédié. Deux cents requêtes par page sans que personne ne le sache ; la première semaine de mesure l'a montré, la troisième l'a réglé.
- Le commerce piloté depuis la France, décrit dans le guide dédié. Le fondateur voyait une application rapide depuis la fibre ; le tableau au 75e percentile par wilaya lui a montré ce que voyaient ses vendeurs.
Le calendrier 2027
Le calendrier est celui d'une application rendue rapide en six semaines, dont la première sans une ligne de code.
La semaine 0 à 1 mesure chez les vrais utilisateurs : temps réels par écran, réseau et wilaya, téléphones réellement présents dans les journaux, et budget écrit par écran ; l'écran lent n'est presque jamais celui qu'on croyait. La semaine 1 à 2 traite les écrans : code découpé, images réduites et converties à l'envoi, chargement de ce qui est visible d'abord ; c'est là que les gains sont les plus grands. La semaine 2 à 3 traite l'API : un appel agrégé par écran, pagination, compression, en-têtes de cache, appels superflus supprimés. La semaine 3 à 4 traite la base : index, jointures, requêtes lentes journalisées et corrigées.
La semaine 4 à 5 mesure chaque écran sur un Android de 2019 en 3G simulée et charge l'API comme un jour de pointe. La semaine 5 à 6 fait entrer le budget dans la chaîne de livraison et installe le tableau au 75e percentile lu chaque semaine. Chaque lot est démontré comme le guide sur la livraison le décrit ; et quand l'application est mobile, la même discipline s'applique à chaque version, selon le guide sur les mises à jour. Si après tout cela le serveur reste le goulot, le guide sur l'hébergement dit où le mettre ; c'est la sixième étape, pas la première.
Ce qui fait échouer une application rapide
Les applications lentes que nous reprenons le sont presque toujours pour l'une de ces raisons.
- Testée sur le téléphone du développeur. Récent, en wifi, à Alger ; les clients ont des Android de 2019, en 3G, à Sétif.
- Pas de budget. Personne ne peut dire si l'écran est lent, donc personne ne le corrige.
- Les photos originales. Quatre méga-octets pour un carré de 300 pixels, multipliés par douze.
- Une requête par ligne. Invisible sur le wifi, dévastatrice en 3G.
- La liste sans pagination. Rapide au lancement, lente au sixième mois, bloquée au douzième.
- Un serveur plus gros à la place du code. La facture monte, l'écran fait toujours vingt appels.
- Mesuré une fois. La version suivante reperd tout, et personne ne le voit avant les clients.
Questions fréquentes
Les questions que nous recevons de gérants, de fondateurs et de responsables informatiques.
- Pourquoi l’application est-elle rapide chez nous et lente chez les clients ?
- Parce qu'elle a été testée sur un téléphone récent en wifi et qu'elle est utilisée sur des téléphones plus anciens en 3G ou sur un wifi partagé. Un écran qui fait vingt appels et charge cinq méga-octets passe inaperçu sur la fibre et prend dix secondes en 3G. On construit et on mesure pour le téléphone et le réseau de vos clients, au 75e percentile, pas pour ceux du développeur.
- Faut-il un serveur plus puissant ?
- Presque jamais en premier. Cinq des six lenteurs se règlent dans le code : poids des écrans, images, pagination, requête par ligne, index, cache. Un écran qui fait un appel au lieu de vingt est rapide même sur un serveur moyen. Le serveur vient en sixième, après la mesure, et le guide sur l'hébergement dit alors où le placer.
- Qu’est-ce qu’un budget de performance ?
- Six chiffres par écran, écrits avant le code et vérifiés à chaque livraison : poids du premier écran, images visibles, scripts avant affichage, nombre de requêtes, temps de réponse de l'API au 75e percentile, et affichage du contenu principal en 2,5 secondes sur un Android de 2019 en 3G simulée. Une version qui dépasse une de ces valeurs n'est pas livrée tant qu'elle n'est pas corrigée.
- Pourquoi le 75e percentile et pas la moyenne ?
- Parce que la moyenne cache le quart des utilisateurs les plus mal servis. Le 75e percentile est le temps au-dessous duquel trois clients sur quatre se trouvent ; c'est le point que les seuils publics de Google demandent de mesurer, séparément sur mobile, et c'est celui que nous écrivons au contrat.
- Combien gagne-t-on sur les images ?
- Le gain documenté par Google pour le format WebP est de 25 à 34 % par rapport au JPEG à qualité égale ; mais le gain qui compte vient avant : une photo de téléphone pèse plusieurs méga-octets et s'affiche dans un carré de 300 pixels, et la réduire à cette taille divise son poids par dix ou plus. Les deux se font à l'envoi, côté serveur, en plusieurs tailles, une fois pour toutes.
- Combien de temps pour rendre une application rapide ?
- Six semaines : une pour mesurer chez les vrais utilisateurs et écrire les budgets, une pour les écrans, une pour l'API, une pour la base, une pour mesurer sur un téléphone ancien en 3G simulée et charger l'API, une pour faire entrer le budget dans la chaîne de livraison. La première semaine est sans code, et elle décide de l'ordre des cinq autres.