La latence arrive souvent tard dans les discussions sur l’infrastructure. Au début, on parle de prix, de capacité, de région cloud, de sécurité ou de services managés. Ce n’est qu’une fois la plateforme en production que surgissent les métriques qui dérangent : pages lentes à répondre, paniers abandonnés, APIs en attente, sessions mobiles peu converties. Et ce, alors que le serveur « fonctionne bien ».
Servir une application depuis une infrastructure distante n’est pas équivalent à un hébergement local. La différence peut sembler faible en millisecondes, mais elle se multiplie à chaque requête, à chaque négociation TCP/TLS, à chaque appel API et à chaque ressource dynamique qui ne peut pas être mise en cache. Cela s’illustre très concrètement dans des marchés comme l’Amérique latine, mais le principe s’applique à tout déploiement cloud international.
Le RTT : la distance transformée en expérience
Le RTT (round-trip time) mesure le temps nécessaire à un paquet pour aller d’un point à un autre et revenir. C’est une métrique simple mais très utile pour comprendre pourquoi la localisation physique de l’infrastructure continue d’importer. La fibre optique ne supprime pas la géographie. Elle la réduit, l’achemine et l’optimise, mais chaque saut, chaque route internationale et chaque point d’échange ajoute du délai.
Dans une application web moderne, 100 millisecondes de différence n’affectent pas qu’une seule requête. Elles se manifestent lors de la résolution DNS, de l’établissement de connexion, de la négociation TLS, du chargement initial du HTML, des appels backend, des ressources bloquantes, des endpoints de paiement et de la communication entre microservices répartis entre différentes régions.
Le tableau suivant utilise Buenos Aires comme point de référence (avec des valeurs issues de mesures publiques) pour illustrer l’ordre de grandeur. Ces chiffres varient selon l’opérateur, la route, le fournisseur de transit et l’heure de la journée. Mais les écarts relatifs restent indicatifs.
| Localisation | RTT approximatif depuis Buenos Aires | Différence | Lecture technique |
|---|---|---|---|
| Argentine locale | ~2-5 ms | Référence | Idéal pour les charges sensibles à la latence |
| Santiago du Chili | ~21-25 ms | +20 ms | Bonne option régionale |
| São Paulo | ~30-35 ms | +30 ms | Région cloud proche pour l’Amérique du Sud |
| Miami | ~110-135 ms | +110-130 ms | Éloigné pour une expérience locale |
| New York / Virginie | ~140-150 ms | +140-150 ms | Région souvent choisie par défaut, loin des utilisateurs argentins |
| Londres | ~220-225 ms | +220 ms | Puissante pour l’Europe, peu efficace pour l’Amérique du Sud |
| Madrid | ~230-235 ms | +230 ms | Bonne pour l’Espagne, pas pour une faible latence en Argentine |
| Francfort | ~235-245 ms | +235-240 ms | Région européenne mature, mais très distante pour le trafic argentin |
Madrid illustre bien une confusion fréquente. C’est une localisation excellente pour servir des utilisateurs en Espagne, au Portugal ou en Europe du Sud. Mais si l’utilisateur final est à Buenos Aires, chaque interaction traverse l’Atlantique, avec un RTT supérieur à 230 ms. La logique s’applique dans l’autre sens : un hébergement en Europe de l’Ouest convient aux utilisateurs européens, pas à des utilisateurs en Asie ou en Amérique du Sud.
Le coût réel de la latence pour l’e-commerce
L’impact économique de la latence est souvent résumé à deux références. Greg Linden, ancien ingénieur chez Amazon, avait noté que des retards de 100 ms introduits en tests internes entraînaient une chute significative du chiffre d’affaires. La formule simplifiée depuis lors : « 100 ms supplémentaires peuvent coûter 1 % de ventes ». C’est une référence historique, pas une loi universelle.
L’étude « Milliseconds Make Millions » de Deloitte pour Google montrait qu’une amélioration de 0,1 seconde sur des métriques de vitesse mobile se traduisait par une hausse de 8,4 % des conversions dans le retail et de 10,1 % dans le voyage. Le principe est clair : plus une application est interactive et transactionnelle, plus le coût d’éloigner le backend de l’utilisateur est élevé.
| Localisation | Augmentation de latence vs. local | Impact estimé sur 1 M€ de CA annuel* |
|---|---|---|
| Infrastructure locale | 0 ms | Référence |
| Région régionale proche | +20-30 ms | ~2 000-3 000 € |
| Région continentale | +100-130 ms | ~10 000-13 000 € |
| Région intercontinentale | +200-240 ms | ~20 000-24 000 € |
*Estimation indicative basée sur la règle historique d’Amazon (100 ms ≈ 1 % de ventes). Ne remplace pas une mesure réelle avec les métriques propres au site.
La variation dépend fortement du type d’application : ce n’est pas la même chose pour une boutique à fort trafic mobile, un portail corporate, une API financière, un SaaS B2B ou une plateforme de jeu. Mais le principe reste : les applications interactives et transactionnelles souffrent davantage de la distance.
CDN, edge, région cloud et infrastructure locale : ce que chaque couche résout
Un CDN améliore la livraison du contenu statique : images, CSS, JavaScript, vidéos, polices ou téléchargements. Il peut aussi réduire la charge sur l’origine. Mais tout ne se met pas en cache. Un login, une requête de stocks, une opération de paiement, une mise à jour de panier ou une recommandation personnalisée doivent toujours atteindre le backend.
C’est là que la localisation de l’infrastructure devient déterminante. Une architecture avec un frontend en cache à la périphérie mais un backend dynamique à 2 000 km peut assurer un premier chargement acceptable tout en pénalisant chaque action importante de l’utilisateur. Sur mobile, la situation s’aggrave avec la variabilité réseau, la perte de paquets, le changement de cellule et la moindre stabilité de certains liens.
| Couche | Ce qu’elle améliore | Ce qu’elle ne résout pas seule |
|---|---|---|
| CDN | Contenus statiques, cache, téléchargements, vidéos | Opérations dynamiques non cachables |
| Edge functions | Logique légère près de l’utilisateur | Bases de données complexes ou états transactionnels distants |
| Région cloud proche | RTT réduit par rapport à des régions éloignées | Dépendance aux services disponibles dans cette région |
| Infrastructure locale | Faible latence pour les utilisateurs nationaux | Nécessite une conception, une exploitation et une résilience soignées |
| Multi-région | Résilience et proximité par marché | Complexité accrue pour la cohérence et le coût |
La question n’est pas « cloud public ou infrastructure locale », mais plutôt quelle architecture hybride et adaptée convient à chaque charge. Certaines charges trouvent une bonne place dans des régions cloud mondiales : analytique, sauvegarde, reprise après sinistre, services managés, IA, environnements de développement. D’autres — celles très sensibles à la latence ou avec un utilisateur concentré dans un pays — bénéficient clairement d’une proximité physique. C’est d’ailleurs ce qui pousse les acteurs comme Meta à investir dans des data centers spécialisés avec des CPU dédiés comme le Qualcomm Dragonfly C1000, adaptés à des charges spécifiques plutôt que généralistes.
Comment mesurer avant de déplacer une charge
La latence ne doit pas simplement être estimée à partir d’un tableau. Avant de migrer, il faut mesurer depuis les points où se trouvent réellement les utilisateurs. Pour une boutique nationale, cela implique de tester depuis plusieurs villes. Pour un SaaS B2B, l’origine des connexions réseau des clients est aussi cruciale. Pour une API financière, il faut mesurer entre la plateforme, les PSP, banques, antifraude et fournisseurs externes.
Un test utile doit inclure au minimum le RTT, le jitter, la perte de paquets, le TTFB, les temps p95 et p99, le handshake TLS, le temps de requête vers la base de données et la performance sur mobile. La moyenne peut tromper : une application peut afficher une latence moyenne acceptable tout en subissant des files d’attente au 99e percentile lors des pics.
Il faut aussi distinguer la latence de traitement de celle du réseau. Un serveur lent à proximité peut être moins performant qu’un backend bien optimisé dans une région proche. Mais lorsque les deux environnements sont bien conçus, la géographie poids encore. Aucun réglage de CPU ne compense un RTT de 230 ms si le backend principal est à l’autre bout du monde par rapport aux utilisateurs — une réalité qui s’intensifie alors que les data centers IA consomment des puissances électriques de plus en plus importantes et que le choix de localisation devient aussi un choix d’approvisionnement énergétique.
La latence n’apparaît pas comme une ligne dans la facture du fournisseur, mais elle se retrouve dans les métriques. Elle influence la conversion, l’abandon, le TTFB, la vitesse des APIs, les processus de paiement et la qualité perçue. Pour beaucoup d’entreprises, choisir où héberger peut être aussi stratégique que de choisir la plateforme elle-même.
FAQ
Qu’est-ce que la latence réseau ?
C’est le temps qu’un paquet met pour voyager entre l’utilisateur et le serveur, généralement mesuré en RTT (round-trip time). Plus l’infrastructure est éloignée physiquement de l’utilisateur, plus ce temps est élevé.
Pourquoi la latence est-elle si importante en e-commerce ?
Chaque retard affecte le chargement des pages, les recherches, le panier, la connexion et le paiement. Sur mobile, de petits délais sont plus perceptibles à cause de la variabilité du réseau. La règle empirique d’Amazon (100 ms supplémentaires ≈ 1 % de ventes en moins) reste une référence utile, même si chaque site est différent.
Un CDN élimine-t-il le problème de latence ?
Pas entièrement. Un CDN améliore la livraison des contenus statiques et en cache, mais les opérations dynamiques (paiement, login, panier, recommandations) réclament toujours un accès au backend, aux bases de données ou aux APIs.
Quelle région cloud choisir pour des utilisateurs européens ?
Pour des utilisateurs en Europe de l’Ouest (France, Espagne, Allemagne), les régions cloud européennes (Paris, Francfort, Amsterdam, Madrid) offrent les RTT les plus faibles. Choisir une région américaine par défaut peut ajouter 100 à 150 ms supplémentaires sur chaque requête dynamique.
