Jay Did C'est une conversation que nous avons plusieurs fois par mois. Un client nous appelle : son site est hébergé chez un grand fournisseur européen, l'offre est correcte, le serveur est puissant — et pourtant ses clients à Lomé, Cotonou ou Abidjan se plaignent de la lenteur. Sur l'ordinateur du dirigeant, en revanche, tout va bien.
Le coupable n'est presque jamais le serveur. C'est la distance.
Ce que coûte un aller-retour
Chaque fois qu'un navigateur demande quelque chose à un serveur, la requête doit physiquement traverser le réseau et revenir. Depuis Lomé vers un centre de données à Paris, comptez 120 à 180 millisecondes par aller-retour dans de bonnes conditions. Vers Francfort ou Amsterdam, souvent davantage.
Cent cinquante millisecondes, ce n'est rien. Le problème, c'est qu'une page web n'effectue jamais un seul aller-retour. Elle en enchaîne des dizaines : résolution DNS, poignée de main TLS, document HTML, feuilles de style, scripts, polices, images, appels à l'API. Avec une trentaine de requêtes séquentielles, ces 150 ms deviennent plusieurs secondes d'attente — sur lesquelles la puissance du serveur n'a aucune prise.
Pourquoi le problème s'aggrave sur mobile
En Afrique de l'Ouest, la majorité du trafic web est mobile. Or une connexion mobile ajoute sa propre latence à celle du réseau longue distance : le temps d'établissement de la liaison radio, les variations de qualité selon la couverture, et les pertes de paquets qui déclenchent des retransmissions.
Résultat : un site qui s'affiche en 1,2 seconde sur une fibre parisienne peut demander 6 à 8 secondes sur un téléphone à Kara. La même page, le même serveur.
Quatre leviers, par ordre d'efficacité
1. Rapprocher les fichiers statiques. Images, feuilles de style, scripts et polices représentent l'essentiel du poids d'une page. Les servir depuis un réseau de distribution disposant de points de présence en Afrique — ou au minimum en Europe du Sud — supprime la majorité des allers-retours longue distance.
2. Réduire le nombre de requêtes. Chaque fichier supprimé est un aller-retour économisé. Regrouper les scripts, supprimer les polices inutilisées et les bibliothèques chargées « au cas où » produit souvent plus de gain qu'un serveur deux fois plus puissant.
3. Servir des images au bon format et à la bonne taille. Une photo de 2000 pixels de large envoyée à un téléphone de 390 pixels, c'est 90 % de données gaspillées. Les formats modernes comme AVIF et WebP divisent encore le poids par trois à cinq à qualité équivalente.
4. Envisager un hébergement régional. Pour une application où chaque interaction déclenche un appel serveur — un logiciel de gestion, une caisse, un back-office — rapprocher le serveur de ses utilisateurs devient le seul levier réellement décisif.
Mesurer avant de décider
Avant d'engager des travaux, mesurez depuis l'endroit où se trouvent vos utilisateurs, pas depuis votre bureau. Un test de vitesse lancé depuis un navigateur connecté en fibre à Lomé ne dit rien de l'expérience d'un client sur son téléphone à Sokodé.
Les outils de mesure permettent de choisir le lieu du test : utilisez-le. Et comparez toujours deux chiffres — le temps d'affichage du premier contenu utile, et le temps avant que la page devienne réellement utilisable. C'est le second qui détermine si un visiteur reste ou s'en va.
Ce que nous constatons en pratique
Sur les migrations que nous accompagnons, la combinaison « réseau de distribution + optimisation des images + réduction du nombre de requêtes » divise généralement par trois le temps d'affichage perçu, sans changer une ligne de code applicatif ni augmenter la facture d'hébergement.
Le changement de serveur, lui, arrive en dernier — quand il arrive. C'est le levier le plus coûteux, et rarement le plus efficace.