VPS à New York : quels critères comptent vraiment ?

Ce qu’un VPS à New York vous apporte réellement

Un VPS à New York se trouve dans l’un des deux grands marchés d’interconnexion de la côte est des États-Unis. L’autre est Ashburn, en Virginie. Vous bénéficiez d’un aller-retour réseau court vers les utilisateurs situés entre Boston et Washington, ainsi que du chemin fibre le plus court entre l’Amérique du Nord et l’Europe. Si vos utilisateurs sont répartis uniformément sur le continent, un emplacement central les desservira généralement mieux. Distinguer ces deux cas nécessite des mesures, et non des suppositions.

Pourquoi l’hébergement VPS de New York se trouve principalement dans le New Jersey

Manhattan accueille les carrier hotels. Le plus connu est 60 Hudson Street : ce bâtiment Art déco de Tribeca, achevé en 1930, héberge plus de 300 opérateurs et fournisseurs cloud, ainsi que les points d’échange qui desservent la région, notamment DE-CIX New York et NYIIX. 32 Avenue of the Americas remplit la même fonction quelques pâtés de maisons plus loin. Dans le New Jersey, 165 Halsey Street à Newark joue un rôle équivalent.

C’est dans ces bâtiments que les réseaux s’interconnectent. Ils n’hébergent pas de grandes capacités de calcul, car l’électricité et l’espace au sol coûtent cher à Manhattan et sont difficiles à augmenter. Les grandes salles se trouvent de l’autre côté de l’Hudson, à Secaucus, Weehawken, Carteret, Piscataway et Newark. Un fournisseur qui vend un VPS « New York » désigne presque toujours un rack situé quelque part dans cette couronne, à environ 40 km de Midtown au maximum. La distance supplémentaire sur la fibre ajoute largement moins d’une milliseconde. Une application web ne la remarquera donc jamais. Demandez le bâtiment uniquement si vous avez besoin d’un cross-connect vers un réseau précis.

Ce qui a attiré la capacité dans cette métropole

Quatre facteurs se renforcent mutuellement.

• Les câbles transatlantiques arrivent juste à côté. Wall Township et Manasquan, sur la côte du New Jersey, forment le cluster le plus actif du pays. Havfrue, commercialisé sous le nom d’AEC-2, relie Wall à Blaabjerg, au Danemark, avec des branches vers l’Irlande et la Norvège. Seabras-1 part de la même station vers le Brésil, tandis que TGN Atlantic traverse l’Atlantique vers l’Europe. Apollo arrive à Manasquan depuis Bude, en Angleterre, et Lannion, en France. Le câble Grace Hopper de Google arrive à Bellport, sur Long Island, et transporte du trafic vers Bude depuis septembre 2022.
• Les places de marché ont quitté Wall Street. Le matching engine du NYSE se trouve à Mahwah, celui du Nasdaq à Carteret et celui de Cboe à Secaucus. Les traders appellent ces sites le triangle des actions. Les entreprises qui ont besoin de données de marché avec une latence de quelques microsecondes doivent louer de l’espace à proximité de l’un d’eux. Cette demande a financé la fibre que nous partageons désormais tous.
• Les médias et la publicité sont présents sur place. Une enchère en temps réel doit renvoyer une réponse avant la fin du chargement de la page. Les ad exchanges se sont donc installés à proximité des réseaux des agences auxquels ils vendent leurs services.
• Les réseaux s’installent là où d’autres réseaux sont déjà présents. Une fois que plusieurs centaines d’opérateurs partagent un même bâtiment, le suivant obtient un transit moins cher et un meilleur peering en les rejoignant plutôt qu’en construisant ailleurs.

Pour un acheteur de VPS, il ne s’agit pas de prestige. Cela signifie que le transit est concurrentiel, que le peering est dense et que le chemin vers l’Europe est court, puisqu’il commence là où arrivent les câbles.

Ce que coûte réellement un aller-retour

Dans une fibre optique, la lumière se déplace à environ 200,000 km par seconde, soit environ les deux tiers de sa vitesse dans le vide. Cela représente 1 ms d’aller-retour pour 100 km de fibre, avant même qu’un routeur ne traite le paquet. Les trajets réels sont plus longs que la distance à vol d’oiseau, car la fibre suit les emprises disponibles et les routes sous-marines au lieu de lignes droites.

Le coût ne correspond pas à un seul aller-retour. Il dépend du nombre d’allers-retours nécessaires au protocole. Une nouvelle connexion HTTPS consomme un aller-retour pour le handshake TCP (transmission control protocol), un autre pour le handshake TLS (transport layer security) 1.3, puis un autre pour envoyer la requête et recevoir les premiers octets. Cela représente trois allers-retours avant que le navigateur n’affiche le moindre HTML. TLS 1.2 en ajoute un quatrième.

[
  {
    "label": "Same metro",
    "rtt_ms": 5,
    "https_first_byte_ms": 15,
    "six_call_chain_ms": 30
  },
  {
    "label": "New York to Dallas",
    "rtt_ms": 38,
    "https_first_byte_ms": 114,
    "six_call_chain_ms": 228
  },
  {
    "label": "New York to London",
    "rtt_ms": 78,
    "https_first_byte_ms": 234,
    "six_call_chain_ms": 468
  },
  {
    "label": "New York to Singapore",
    "rtt_ms": 230,
    "https_first_byte_ms": 690,
    "six_call_chain_ms": 1380
  }
]

Ces colonnes résultent de calculs et non de mesures : first byte correspond à trois allers-retours, tandis que la colonne chain représente une page qui lance six appels API dépendants les uns des autres. Dans le réseau métropolitain, avec 5 ms, l’établissement de la connexion est imperceptible. De l’autre côté de l’Atlantique, avec 78 ms, la même page attend 234 ms avant de recevoir le premier octet de HTML, et la chaîne de six appels passe 468 ms à attendre sans rien faire d’autre. Entre New York et Singapour, avec 230 ms, cette chaîne coûte 1380 ms.

Consultez la colonne chain avant de déplacer un serveur. La réutilisation des connexions et la reprise de session TLS suppriment les allers-retours que vous payiez à répétition. Transformer six appels dépendants en deux appels parallèles fait gagner plus de temps que de rapprocher le serveur d’un continent. Déplacez le serveur lorsque les allers-retours sont incompressibles : pour une connexion, ou pour une écriture en base de données que votre client ne peut pas regrouper.

Temps aller-retour typiques depuis un VPS de la région de New York

[
  {
    "label": "Within the NY and NJ metro",
    "rtt_ms": 2
  },
  {
    "label": "Ashburn, Virginia",
    "rtt_ms": 8
  },
  {
    "label": "Toronto",
    "rtt_ms": 14
  },
  {
    "label": "Chicago",
    "rtt_ms": 22
  },
  {
    "label": "Dallas",
    "rtt_ms": 38
  },
  {
    "label": "Miami",
    "rtt_ms": 40
  },
  {
    "label": "Los Angeles",
    "rtt_ms": 70
  },
  {
    "label": "London",
    "rtt_ms": 78
  },
  {
    "label": "Frankfurt",
    "rtt_ms": 88
  },
  {
    "label": "Sao Paulo",
    "rtt_ms": 120
  }
]

Considérez ces valeurs comme des chiffres typiques publiés, et non comme des mesures effectuées depuis une machine donnée. Il s’agit de la plage généralement citée pour des hôtes bien connectés utilisant un transit standard. Votre propre chemin réseau peut produire des valeurs inférieures ou supérieures. Ashburn est à environ 8 ms, suffisamment proche pour qu’un VPS de New York puisse appeler les services du cluster de Virginie sans pénalité notable. Toronto est à environ 14 ms. Londres se situe autour de 78 ms et Francfort autour de 88 ms. C’est pourquoi un serveur situé sur la côte Est peut servir correctement des utilisateurs européens, contrairement à un serveur situé sur la côte Ouest.

Quand choisir un datacenter sur la côte Est

• La plupart de vos utilisateurs se trouvent dans le corridor entre Boston et Washington. Cette zone représente une part importante de la demande Internet aux États-Unis, et l’ensemble de cette région se trouve à quelques millisecondes de la métropole.
• Vous desservez l’est des États-Unis et l’Europe depuis une seule machine. New York est le meilleur compromis économique, car la liaison transatlantique commence ici.
• Vous dépendez d’un service déjà présent dans la métropole : un flux de données de marché, une ad exchange ou une API partenaire à Secaucus ou Ashburn.
• Vous voulez un chemin court vers le Canada sans y héberger vos services. Toronto est à environ 14 ms. Si la résidence des données au Canada est une exigence stricte, la décision est différente ; les critères réellement importants pour choisir un hébergement VPS au Canada les détaille.

Quand un emplacement central aux États-Unis est préférable à la côte Est

Concevez votre infrastructure pour le pire cas, pas pour la moyenne. Un utilisateur situé sur la côte opposée ressent la latence. Un utilisateur dans l’État voisin ne la remarque pas.

[
  {
    "label": "New York metro",
    "to_new_york_ms": 2,
    "to_los_angeles_ms": 70
  },
  {
    "label": "Dallas",
    "to_new_york_ms": 38,
    "to_los_angeles_ms": 35
  },
  {
    "label": "Chicago",
    "to_new_york_ms": 22,
    "to_los_angeles_ms": 50
  },
  {
    "label": "Los Angeles",
    "to_new_york_ms": 70,
    "to_los_angeles_ms": 2
  }
]

Un serveur à New York se trouve à 70 ms de Los Angeles. Un serveur à Dallas est à 38 ms de New York et à 35 ms de Los Angeles. Dans le pire cas à l’échelle du pays, sa latence est donc environ deux fois plus faible que celle de New York. Lorsque votre trafic est réellement réparti à l’échelle nationale, Dallas constitue le meilleur choix. Pourquoi placer un VPS à Dallas présente ce marché en détail. Chicago est l’autre emplacement central cohérent, avec une orientation davantage tournée vers l’est.

Deux autres situations plaident contre New York. Si vos utilisateurs sont principalement concentrés en Ontario ou au Québec, un VPS à Toronto les dessert directement au lieu d’ajouter le saut de 14 ms depuis New York. Si la quasi-totalité de votre trafic circule entre vos propres serveurs, regroupez-les dans une seule région et ne tenez pas compte de la géographie : un saut interrégional annulera largement le gain obtenu en vous rapprochant des utilisateurs.

Mesurez, ne vous fiez pas à la carte de couverture

Une carte de couverture indique où se trouve un bâtiment. Elle ne vous indique pas comment les paquets atteignent ce bâtiment. Ce chemin dépend des contrats de transit et des accords de peering, pas de la distance. Mesurez donc depuis l’endroit où se trouvent vos utilisateurs. Un ordinateur portable connecté à Internet depuis un domicile constitue une meilleure sonde que le VPS lui-même, qui se trouve du bon côté du réseau.

sudo apt update
sudo apt install -y mtr-tiny traceroute iperf3

Commencez par un aller-retour simple et envoyez vingt sondes plutôt que quatre. Remplacez le nom d’hôte par celui de votre serveur.

ping -c 20 your-server.example.com

La dernière ligne indique rtt min/avg/max/mdev. La moyenne est la valeur la moins utile ici. mdev correspond à la gigue. Une gigue élevée perturbe la voix et les sessions interactives, même lorsque la moyenne semble correcte. Sur une liaison filaire, toute perte de paquets supérieure à zéro indique un problème, pas du bruit.

Trouvez ensuite où le temps est consommé.

mtr -rwzbc 100 your-server.example.com

mtr envoie 100 sondes à chaque saut et affiche la perte et la latence pour chacun. -z ajoute le numéro d’AS (système autonome), afin d’indiquer quel réseau possède chaque saut. Une perte signalée sur un saut intermédiaire, puis absente sur les sauts suivants, n’est pas réelle : ce routeur limite le débit des réponses ICMP qu’il doit générer lui-même, ce qui ne coûte rien à votre trafic. Une perte qui commence sur un saut et se poursuit sur tous les sauts suivants est réelle.

ICMP est également un mauvais protocole pour évaluer un service web, car de nombreux réseaux lui accordent une faible priorité. Mesurez le service que vous fournissez réellement.

curl -o /dev/null -s -w 'dns %{time_namelookup}\ntcp %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://example.com/

Chaque valeur correspond au nombre de secondes écoulées depuis le début. Vous devez donc calculer les différences. time_connect moins time_namelookup correspond à un aller-retour. time_appconnect moins time_connect correspond à la négociation TLS. time_starttransfer moins time_appconnect correspond à un aller-retour supplémentaire, auquel s’ajoute le temps nécessaire à votre application pour répondre. Cette dernière différence permet d’établir le diagnostic. Si elle est proche d’un aller-retour, le réseau constitue la limite et un serveur plus proche sera utile. Si elle représente plusieurs fois le temps d’un aller-retour, votre application est lente et son déplacement ne changera rien.

for i in $(seq 1 20); do
  curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/
done | sort -n | awk 'NR==10 || NR==11'

Exécutez le même test sur une instance d’essai dans chaque emplacement candidat avant de vous engager. La méthode complète pour évaluer un VPS couvre ensuite le disque et le processeur en plus du réseau. Vous ne choisissez donc pas uniquement en fonction de la latence.

Ce qui change aussi avec une adresse à New York

Le prix est le premier élément. L’électricité et l’espace au sol coûtent plus cher dans la région métropolitaine de New York qu’au Texas ou dans le Midwest. Certains fournisseurs répercutent cette différence sous la forme d’un supplément par site. D’autres la répartissent sur l’ensemble de leur parc. En août 2026, il n’existe pas de règle unique. Comparez donc le prix d’une même configuration dans deux emplacements sur la page de commande du fournisseur avant de supposer qu’un supplément s’applique. La section Quel est le coût réel d’un VPS par mois détaille le reste de la facture.

La loi ne suit pas le serveur. Le SHIELD Act de l’État de New York impose des obligations de notification des violations de données et de mise en place de mesures de protection raisonnables à toute personne qui détient des informations privées concernant un résident de New York, quel que soit l’emplacement de ces données. Déplacer votre serveur à Dallas ne supprime pas cette obligation. Le déplacer à Manhattan ne la crée pas non plus. Il en va de même pour le GDPR (règlement général sur la protection des données) et vos utilisateurs européens. L’emplacement devient important lorsqu’un contrat ou une réglementation sectorielle désigne un pays, ce qui est fréquent dans le secteur de la santé et dans certains services financiers.

Les risques liés à l’alimentation électrique et aux inondations méritent un paragraphe. Lorsque l’ouragan Sandy a frappé en octobre 2012, plusieurs bâtiments de fournisseurs télécoms du Lower Manhattan ont perdu leur service, car les pompes à carburant des sous-sols ont été inondées et les générateurs situés aux étages supérieurs sont tombés à court de carburant. Un site unique dans n’importe quelle région métropolitaine constitue un point de défaillance unique. Conservez vos sauvegardes sur un réseau électrique différent et effectuez au moins une restauration ailleurs afin de vérifier qu’elle fonctionne.

FAQ

Un VPS à New York est-il plus rapide pour les utilisateurs européens qu’un VPS situé dans le centre des États-Unis ?

Oui, avec un écart prévisible. Londres se trouve à environ 78 ms de la métropole new-yorkaise, car les câbles transatlantiques aboutissent sur la côte du New Jersey et à Long Island. Un serveur situé à Dallas rejoint d’abord la côte est, puis Londres. Il ajoute donc environ les 38 ms du trajet entre Dallas et New York. Si une machine doit servir à la fois l’est des États-Unis et l’Europe, New York est le compromis le moins coûteux.

Pourquoi mon VPS « New York » est-il en réalité situé dans le New Jersey ?

Parce que c’est là que se trouvent les espaces en datacenter et l’alimentation électrique. Les immeubles de Manhattan, comme le 60 Hudson Street, sont des hubs d’interconnexion plutôt que de grandes salles informatiques. Les racks se trouvent donc à Secaucus, Weehawken, Carteret, Piscataway ou Newark. La fibre supplémentaire ajoute bien moins d’une milliseconde, ce qu’aucune charge web ne remarquera. Demandez le site exact uniquement si vous avez besoin d’un cross-connect vers un réseau particulier dans un immeuble donné.

Comment savoir si la latence est réellement mon problème ?

Exécutez la décomposition des temps curl et faites la soustraction. L’écart entre time_appconnect et time_starttransfer correspond à un aller-retour réseau, auquel s’ajoute le temps de traitement de votre serveur. Si cet écart est nettement supérieur à l’aller-retour mesuré avec ping, le délai vient de votre application. Un datacenter plus proche ne le corrigera pas. Si l’écart est proche d’un aller-retour et que la page reste lente, comptez le nombre de requêtes que la page effectue séquentiellement, car chacune paie de nouveau l’aller-retour.

L’hébergement à New York change-t-il les lois sur la confidentialité qui s’appliquent à mon activité ?

En général, non. Des textes comme le SHIELD Act de l’État de New York et le RGPD s’appliquent selon les personnes dont vous détenez les données, et non selon l’emplacement du disque. L’emplacement du serveur devient déterminant lorsqu’un contrat ou une réglementation sectorielle impose un pays précis. C’est fréquent dans le secteur de la santé et dans certains services financiers. Lisez l’exigence applicable avant de choisir un emplacement pour y répondre.

Un CDN peut-il remplacer un VPS correctement positionné ?

Pour les fichiers statiques, oui. Un CDN (content delivery network) met en cache les images et les scripts près de vos utilisateurs et supprime l’essentiel de la distance pour ces requêtes. Il ne peut pas mettre en cache un tableau de bord associé à une session ou une écriture dans votre base de données. Ces opérations doivent donc toujours atteindre votre serveur d’origine et subir l’aller-retour complet. Placez le serveur d’origine près des utilisateurs qui écrivent des données et laissez le CDN gérer le reste.