La latence apparaît souvent tard dans les discussions sur l’infrastructure. Au début, on parle de prix, de capacité, de région cloud, d’évolutivité, de sécurité ou de services managés. Ce n’est qu’une fois la plateforme en production que surgissent les métriques : pages qui mettent plus de temps à répondre, paniers abandonnés, APIs avec des attentes accumulées, sessions mobiles peu converties et utilisateurs percevant le service comme lent, même si le serveur « fonctionne bien ».

Dans des marchés comme l’Argentine, cette discussion a une lecture très concrète. Servir une application depuis une infrastructure locale n’est pas pareil que depuis São Paulo, Miami, Virginie, Madrid ou Francfort. 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 simplement être mise en cache.

Le RTT n’est pas un détail : c’est la distance transformée en expérience

Lorsqu’on parle de latence réseau, on utilise souvent le RTT, ou round-trip time, qui mesure le temps nécessaire à un paquet pour aller d’un point à un autre puis 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, une différence de 100 millisecondes n’affecte pas qu’une seule requête. Elle peut se manifester lors de la résolution DNS, de l’établissement de la connexion, de la négociation TLS, du chargement initial du HTML, des appels backend, des ressources bloquantes, des endpoints de paiement, de la connexion ou de la communication entre microservices si une partie du système est répartie entre différentes régions.

Le tableau suivant utilise Buenos Aires comme point de référence et recense des valeurs indicatives de RTT, publiées par des mesures publiques entre villes. Ces chiffres ne garantissent pas un rendement précis ; chaque opérateur, route, fournisseur de transit ou heure de la journée peut faire varier ces résultats. Ils servent simplement à visualiser l’ordre de grandeur.

Madrid constitue un bon exemple pour clarifier une confusion fréquente. En tant que région européenne, elle peut être une localisation excellente pour servir des utilisateurs en Espagne, au Portugal, en Europe du Sud ou dans certains scénarios d’interconnexion transatlantique. Mais si l’utilisateur final est à Buenos Aires, Córdoba, Rosario ou Mendoza, Madrid n’est pas « proche ». Chaque interaction traverse l’Atlantique, et cela se ressent dans le RTT.

Le coût technique d’héberger le serveur loin

L’impact économique de la latence est souvent évoqué avec deux références connues. Greg Linden, ancien ingénieur chez Amazon, expliquait qu’en tests internes, des retards de 100 millisecondes étaient introduits et que même de petites augmentations entraînaient une chute significative du chiffre d’affaires. La formule résumée depuis longtemps est : « 100 ms supplémentaires peuvent coûter 1 % de ventes ». Il faut la considérer comme une référence historique, pas une règle universelle.

L’autre référence provient de l’étude « Milliseconds Make Millions », réalisée par Deloitte pour Google. Elle montrait qu’une amélioration de 0,1 seconde dans plusieurs métriques de vitesse mobile s’accompagnait d’une augmentation de 8,4 % des conversions dans le retail et de 10,1 % dans le secteur du voyage. Cela ne signifie pas que chaque site obtiendra ces chiffres, mais cela confirme une réalité constatée depuis des années : quand l’expérience mobile s’améliore, la conversion tend à augmenter.

Pour une boutique en ligne générant un chiffre d’affaires annuel de 1 million de dollars, en utilisant la règle empirique d’Amazon, l’impact serait approximativement :

*Estimation indicative basée sur la règle historique de 100 ms ≈ 1 % de vente en moins. Ne remplace pas une mesure réelle avec ses propres métriques.

La variation peut être très importante. Ce n’est pas la même chose pour une boutique avec beaucoup de trafic mobile, un portail corporate, une API financière, un SaaS B2B ou une plateforme de gaming. Mais le principe est clair : plus une application est interactive et transactionnelle, plus le coût d’éloigner le backend de l’utilisateur est élevé.

Local, edge, CDN et cloud régional n’apportent pas la même solution

Une CDN permet d’améliorer clairement la livraison du contenu statique : images, CSS, JavaScript, vidéos, polices ou téléchargements. Elle peut également réduire la charge sur l’origine et améliorer les temps de réponse pour les ressources en cache. Mais tout ne peut pas être mis en cache. Un login, une requête de stocks, une opération de paiement, une mise à jour de panier, une recommandation personnalisée ou un appel à une base de données doivent toujours atteindre le backend.

C’est là que la localisation de l’infrastructure devient centrale. Un design avec un frontend en cache à la périphérie, mais un backend dynamique en Virginie peut assurer un premier chargement acceptable tout en pénalisant chaque action importante de l’utilisateur. Sur mobile, la situation s’aggrave à cause de la variabilité réseau, de la perte de paquets, du changement de cellule et de la moindre stabilité de certains liens.

En Argentine, une particularité supplémentaire apparaît : les grands hyperscalaires ne montrent pas une région publique complète dans le pays sur leurs cartes officielles. AWS liste une Local Zone à Buenos Aires, associée à la région principale US East (Virginie). Cela permet d’approcher certains ressources des utilisateurs finaux, mais une Local Zone ne constitue pas une région complète avec tout le catalogue de services. Azure, Google Cloud et Oracle publient leurs cartes mondiales avec une couverture régionale organisée autour d’autres pays et localisations.

Ce qui invite à voir la question non pas comme « cloud public ou infrastructure locale », mais comme une architecture hybride et adaptée. Certaines charges trouvent une bonne place dans des régions cloud mondiales : analytique, sauvegarde, reprise après sinistre, services gérés, intelligence artificielle, environnements de développement ou applications avec utilisateurs dispersés. D’autres charges, surtout celles très sensibles à la latence ou avec un utilisateur concentré dans un pays, peuvent bénéficier très clairement d’une localisation physique.

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 est conseillé de mesurer depuis les points où se trouvent réellement les utilisateurs. Pour une boutique en Argentine, cela implique de tester depuis Buenos Aires, Córdoba, Rosario, Mendoza, Tucumán et d’autres zones pertinentes. Pour un SaaS B2B, l’origine des connexions réseau des clients est également 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, RTT, jitter, perte de paquets, TTFB, temps p95 et p99, handshake TLS, temps de requête vers la base de données et performance sur mobile. La moyenne peut être trompeuse. Une application peut afficher une latence moyenne acceptable tout en subissant des files d’attente au 99e percentile, ruineant l’expérience lors des pics.

Il est aussi essentiel de distinguer la latence de traitement de celle du réseau. Un serveur lent en Argentine peut être pire qu’un backend très optimisé à São Paulo. Mais lorsque les deux environnements sont bien conçus, la géographie pèse encore. Aucun réglage de CPU ne compense un RTT de 230 ms si l’utilisateur est à Buenos Aires et que le backend principal est à Madrid.

En résumé, 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 API, les processus de paiement et la qualité perçue. Pour beaucoup d’entreprises, choisir où héberger une application peut être aussi crucial que de choisir la plateforme elle-même.

Questions fréquentes

Qu’est-ce que la latence réseau ?
C’est le temps qu’un data met pour voyager entre l’utilisateur et le serveur. On le mesure généralement en RTT, c’est-à-dire le temps aller-retour d’un paquet.

Pourquoi est-ce si important en ecommerce ?
Car chaque retard peut impacter 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.

Une CDN élimine-t-elle le problème de latence ?
Pas complètement. Elle améliore surtout la livraison des contenus statiques et en cache, mais les opérations dynamiques réclament toujours l’accès au backend, aux bases de données ou aux APIs.

Madrid est-elle une localisation adaptée pour servir des utilisateurs en Argentine ?
Madrid peut être idéale pour l’Espagne et l’Europe, mais du point de vue de l’Argentine, elle génère un RTT supérieur à 230 ms. Pour des applications sensibles à la latence, une localisation locale ou régionale proche est généralement plus adaptée.