L'interface est traduite. Les faits fournisseurs et le texte des évaluations sont actuellement en anglais ; la page reste non indexée jusqu'à une traduction de qualité.
Ce guide est entièrement traduit. La version anglaise reste la référence pour les faits et prix des fournisseurs ; la traduction est en attente de relecture éditoriale, cette page reste donc pour l'instant hors index.
Un catalogue de régions n'est pas un ping
La page de régions d'un fournisseur indique où il propose son service. Elle ne donne pas le temps aller-retour depuis vos utilisateurs, la perte de paquets sur une route particulière, ni la disponibilité en stock de l'offre exacte que vous souhaitez. VPSTab enregistre le catalogue de sites du fournisseur et, lorsqu'il est disponible, le prix propre au centre de données ; il ne transforme ni l'un ni l'autre en affirmation sur la latence.
Cette distinction compte, car deux offres dans la même ville peuvent emprunter des chemins réseau différents, et la région la moins chère d'un fournisseur peut se trouver à des milliers de kilomètres des utilisateurs que vous cherchez à servir. Traitez l'emplacement comme une contrainte à vérifier, et non comme un score de performance.
Alignez l'emplacement sur les utilisateurs et les obligations
Partez des personnes et des systèmes qui vont se connecter. Un service destiné à des utilisateurs singapouriens profite d'une région à Singapour ; une équipe qui travaille à Osaka peut préférer Osaka ou Tokyo ; un examen de résidence des données en Allemagne peut exiger une région allemande, quel que soit le prix. Ce sont des exigences strictes, et non des préférences, lorsque la charge de travail en dépend.
Examinez ensuite les obligations opérationnelles. Le fournisseur publie-t-il une page de statut et un SLA ? La région est-elle couverte par les conditions de support dont vous avez besoin ? Pouvez-vous déplacer le service ultérieurement ? Une région bon marché mais isolée sur le plan opérationnel peut être un mauvais choix, même si le prix est attractif.
Le prix et le trafic varient selon l'emplacement
Hetzner en est un exemple clair. CPX02 coûte 6,49 euros ou 8,09 dollars par mois en Allemagne et en Finlande avec 20 TB de trafic UE, mais 7,99 euros ou 9,59 dollars à Singapour avec seulement 500 GB. Le serveur est de la même classe ; l'emplacement change à la fois le prix et le trafic. Un budget construit sur le prix UE peut échouer à Singapour.
AWS Lightsail en est un autre. Sa page de tarifs présente un prix de forfait général et avertit que certaines régions ne reçoivent que la moitié du quota de trafic indiqué. Un forfait qui semble généreux dans l'Oregon peut être bien plus serré dans une autre région. Vérifiez toujours la note régionale, et pas seulement l'intitulé du tableau.
Exemples à Singapour et au Japon
Pour Singapour, le jeu de données collecté comprend Hetzner SIN1, DigitalOcean SGP1, Linode ap-south, Vultr sgp, UpCloud SG-SIN1 et Netcup SIN. Ils diffèrent par le prix, le trafic, les conditions de sauvegarde et la qualité des preuves. Aucun d'eux ne dispose d'un résultat de latence mesuré dans ce jeu de données ; un classement ne peut donc refléter que l'adéquation à vos contraintes déclarées et aux faits énoncés par le fournisseur.
Pour le Japon, Linode propose Osaka et Tokyo, tandis que Vultr liste des sites Osaka et Tokyo dans l'API des offres. Le profil de développement Japon de ce jeu de données exige délibérément Osaka et au moins 2 GB de RAM, ce qui réduit la présélection à Linode 2 GB et à plusieurs offres Vultr. Il s'agit d'un résultat de ressources et d'emplacement, et non d'une affirmation sur la rapidité de l'un ou de l'autre.
L'Allemagne et les clés de région normalisées
L'Allemagne est un cas utile pour comprendre les régions normalisées. Hetzner vend à Falkenstein et Nuremberg, DigitalOcean et Linode listent Francfort, UpCloud liste Francfort et IONOS publie une disponibilité au niveau du pays. Un filtre sur la région normalisée « Frankfurt » n'inclura pas automatiquement Falkenstein, bien que les deux se situent en Allemagne. La page de l'offre affiche le centre de données exact du fournisseur, de sorte que la différence reste visible.
Si votre exigence porte réellement sur « l'Allemagne », vérifiez chaque site allemand plutôt que de supposer qu'une ville représente le pays. Si votre exigence porte sur une ville ou un centre de données précis, utilisez l'emplacement exact du fournisseur. Aucun des deux choix n'est universellement juste ; l'erreur consiste à masquer la distinction.
Architecture, disponibilité et réversibilité
Le choix d'une région est aussi un choix d'architecture. Si le service doit survivre à une panne de centre de données, un seul serveur dans une seule région constitue un point de défaillance unique, quelle que soit sa proximité avec les utilisateurs. Les conceptions multirégions ajoutent des coûts de réplication, de basculement et de cohérence des données qui sortent du cadre d'une comparaison de VPS uniques. Décidez explicitement si vous achetez un hôte unique ou un service résilient.
Prévoyez la sortie avant d'en avoir besoin. Vérifiez si le fournisseur prend en charge les images standard, les instantanés ou les exports ; si vous pouvez déplacer une adresse IP ; et combien de temps la migration risque de prendre. Un fournisseur bon marché aujourd'hui mais qui rend la migration coûteuse présente un coût de verrouillage caché. Ce coût fait partie de la comparaison, même s'il ne peut pas être réduit à un montant mensuel.
Pour les services sensibles à la latence, envisagez un CDN ou une couche de routage basée sur le DNS devant le VPS lorsque les utilisateurs sont répartis dans le monde. Cela transforme le problème : au lieu de « choisir la région parfaite », il s'agit de « choisir une région d'origine et une couche de diffusion ». VPSTab ne mesure pas les performances des CDN ; il s'agit donc d'une option architecturale, et non d'une recommandation fondée sur des mesures.
Comment vérifier un emplacement
Ouvrez la page officielle des régions ou des tarifs du fournisseur et confirmez que l'offre souhaitée est proposée dans l'emplacement dont vous avez besoin. Recherchez un code de centre de données et, lorsqu'il est disponible, un prix propre à l'emplacement. Consignez la date d'observation. Une entrée de catalogue de régions peut changer, et un catalogue ne garantit pas le stock.
Si la latence est une exigence déterminante, mesurez-la depuis des réseaux représentatifs une fois que vous avez un candidat, ou demandez un point de test au fournisseur. Ne considérez pas la géographie, une carte marketing ou le benchmark d'un autre client comme une preuve pour votre route.
Ce que nous ne mesurons pas
Le jeu de données actuel de VPSTab contient des preuves issues des catalogues de fournisseurs, et non des mesures réseau. Il ne publie ni temps aller-retour, ni gigue, ni perte de paquets, ni débit, ni qualité de route pour ces offres. Une présélection classée selon l'adéquation d'emplacement n'est donc pas un benchmark de latence et ne doit pas être présentée comme tel.
Cette limite ne rend pas les données d'emplacement inutiles. Elle change la décision : utilisez le catalogue pour éliminer les emplacements incapables de servir la charge de travail, puis mesurez les candidats restants si la latence compte. La séparation entre preuves de catalogue et mesures fait la différence entre une recommandation honnête et une supposition avancée avec assurance.
Checklist de vérification
- Listez les régions qui satisfont les utilisateurs, la latence et les exigences légales.
- Distinguez une entrée de catalogue de régions d'un stock confirmé pour une offre donnée.
- Vérifiez si le prix et le quota de trafic varient selon l'emplacement.
- Consignez le code exact du centre de données du fournisseur, et pas seulement le pays.
- Vérifiez qu'un filtre de région normalisée n'a pas masqué un emplacement éligible à proximité.
- Ne mesurez la latence qu'avec une méthode correspondant à vos utilisateurs et routes réels.
- Examinez le support, le SLA et les options de sortie pour la région choisie.
- Conservez la date d'observation avec chaque affirmation d'emplacement.
Sources
- Hetzner price API — CLOUD_136 + CLOUD_21 (CPX02 with IPv4)https://website-price-api.hetzner.com/api/v1/products/CLOUD_136%2BCLOUD_21
- Vultr API — List planshttps://api.vultr.com/v2/plans
- Vultr API — List regionshttps://api.vultr.com/v2/regions
- UpCloud data centershttps://upcloud.com/data-centers/
- Amazon Lightsail pricing — Linux/Unix general-purpose bundleshttps://aws.amazon.com/lightsail/pricing/
- Linode API — List regionshttps://api.linode.com/v4/regions