Choisir un cloud ne consiste pas à comparer la longueur des catalogues, mais à vérifier si les régions, le routage, la facturation et la conformité correspondent au besoin. Il faut aussi savoir quand une VM cloud est adaptée ou non.
Lorsqu'une entreprise se développe à l'international, l'achat d'un premier serveur à l'étranger devient souvent nécessaire. L'erreur classique consiste à aligner les fiches techniques, comparer les cœurs CPU et la mémoire, puis découvrir que l'offre la plus chère n'est pas plus agréable à utiliser.
Le bon point de départ est de définir l'usage, puis de choisir ce qui lui correspond. Les éléments ci-dessous sont ceux qui influencent réellement l'expérience quotidienne et la facture.
Aligner d'abord la région sur le marché cible
La région choisie détermine l'origine de la sortie réseau du serveur. Le principe est simple : placez le serveur aussi près que possible des utilisateurs.
La couverture régionale varie fortement d'un fournisseur à l'autre. En Europe, en Amérique du Nord et en Asie du Sud-Est, presque tous proposent des régions, ce qui laisse beaucoup de choix. Dans des marchés moins courants, seuls un ou deux fournisseurs peuvent être présents, voire aucun, obligeant à se rabattre sur une région voisine. Un même fournisseur peut aussi offrir des performances très différentes selon les régions. Une bonne réputation dans un pays ne garantit pas la même stabilité juste à côté. Avant d'acheter, les tests de routage et retours d'expérience du marché visé sont souvent plus utiles que les promesses du site officiel.
Il faut aussi se demander si une couverture mondiale est réellement utile. Si l'activité ne cible qu'un seul marché, payer davantage pour un fournisseur présent partout signifie souvent financer des régions qui ne serviront jamais.
La qualité réseau dépend surtout du trajet retour
C'est l'un des critères les plus difficiles à lire sur une fiche technique, mais aussi l'un de ceux qui influencent le plus l'accès.
Deux fournisseurs utilisant le même emplacement de centre de données peuvent avoir des trajets retour très différents. Le trajet retour correspond au chemin emprunté par les paquets du serveur vers l'utilisateur. S'il fait un détour important, la latence et la perte de paquets augmentent. Pour des accès depuis la Chine continentale vers des régions étrangères, ce trajet peut compter davantage que la distance physique au centre de données. Certaines offres paraissent proches et bon marché, tout en donnant en pratique une latence élevée et beaucoup de pertes : le routage est souvent en cause.
Une seule méthode est fiable : tester. Faites un ping depuis l'emplacement cible et mesurez latence et perte de paquets. Si possible, utilisez une instance d'essai ou un outil de mesure avant l'achat, en évaluant séparément TCP et UDP. Les noms de lignes affichés sur les pages commerciales peuvent donner une indication, mais ne remplacent pas des mesures réelles.
Facturation et coûts cachés
Trois modèles de facturation sont courants, chacun adapté à des usages différents.
| Mode de facturation | Caractéristiques | Adapté à |
|---|---|---|
| Mensuel ou annuel | Coût fixe, budget prévisible | Charges stables à long terme |
| À l'usage | Paiement selon la consommation | Besoins courts ou variables |
| Forfait fixe | Ressources regroupées, coût clair | Scénarios simples et ciblés |
Le trafic est souvent le vrai piège. De nombreuses offres semblent peu chères au mois, mais incluent peu de bande passante ou de transfert, puis facturent les dépassements à un tarif élevé. Pour une activité très consommatrice, le trafic peut coûter plus cher que le serveur lui-même. Avant d'acheter, calculez trois éléments : volume inclus, prix des dépassements et bande passante dédiée ou partagée. Vérifiez aussi si les ressources peuvent être augmentées ou réduites à tout moment et quelle est la politique de remboursement. Quand la taille de l'activité évolue, ces clauses deviennent directement des coûts.
Conformité et lieu de stockage des données
Une activité transfrontalière ne peut pas ignorer ce sujet. Il s'agit souvent d'une contrainte stricte plutôt que d'une préférence à arbitrer.
Commencez par confirmer dans quels pays ou régions les données peuvent être stockées. Certains marchés imposent clairement un lieu de stockage, surtout pour les données personnelles. Vérifiez ensuite les obligations que les règles locales de protection des données imposent au fournisseur, ainsi que ses certifications et documents de conformité. Il faut aussi savoir où sont stockées les sauvegardes et si les transferts internationaux exigent des démarches supplémentaires.
Les réponses peuvent éliminer immédiatement certains choix. Un fournisseur vague sur sa documentation de conformité peut ne pas être suffisamment préparé pour le marché cible, ce qui augmente le risque de problèmes par la suite.
Évaluer le support technique sur deux axes
Le premier est la gestion des incidents. En cas de problème, combien de temps faut-il pour obtenir une réponse, s'agit-il d'un modèle générique ou d'une solution concrète, et le support peut-il réellement faire avancer le dossier jusqu'à résolution ? C'est difficile à juger quand tout va bien. Avant l'achat, une question envoyée au support permet déjà d'observer la rapidité et le niveau technique.
Le second est la stabilité historique. Regardez si la région cible a connu de nombreuses pannes et si le fournisseur publie une page d'état. Le coût caché d'incidents répétés dépasse généralement la différence de prix entre plusieurs offres.
La disponibilité du support compte également : existe-t-il une documentation en chinois et les équipes travaillent-elles sur votre fuseau horaire ? En cas de panne, attendre une équipe située sur un autre fuseau rallonge le temps de rétablissement.
Les IP publiques des VM cloud appartiennent à des plages de centres de données
Ce point est souvent négligé, mais il peut rendre certains usages peu réalistes. L'IP publique d'une VM cloud appartient à une plage d'adresses de centre de données. Les plateformes dotées de contrôles de risque stricts peuvent souvent l'identifier et voir une adresse d'hébergement plutôt qu'une connexion résidentielle.
Pour l'hébergement de sites, les services API ou les tâches d'automatisation classiques, ce n'est pas un problème. En revanche, si l'activité implique plusieurs comptes ou doit reproduire l'environnement réseau d'un utilisateur réel, des proxys résidentiels peuvent être plus adaptés. Dans ce cas, l'environnement du navigateur et l'IP de sortie doivent rester associés de manière stable et ne pas changer lors d'un changement de réseau ou d'appareil. Des outils comme PurpleMark gèrent précisément cette partie en liant durablement les paramètres d'environnement et l'IP.
Quand utiliser le cloud, et quand l'éviter
Les VM cloud conviennent à trois types de besoins : héberger des sites et services destinés à l'étranger, exécuter des automatisations qui doivent rester en ligne longtemps et monter en charge si nécessaire, et disposer d'une sortie fixe pour des accès programmatiques.
Certaines situations s'y prêtent moins. Si l'activité est très petite et qu'il suffit de garder une page accessible, un forfait léger ou un service géré peut être plus simple. Si la gestion de comptes exige un environnement réseau de type résidentiel, l'IP de centre de données d'une VM cloud est naturellement inadaptée. Enfin, avec un budget très serré et sans équipe technique, l'auto-hébergement n'est pas forcément moins cher qu'un service géré une fois les coûts d'exploitation inclus.
L'ordre de décision peut donc être inversé : commencez par écrire ce que le serveur doit faire, pendant combien de temps et avec quelles exigences de conformité, puis comparez les caractéristiques techniques. Quand le besoin n'est pas clair, la plupart des avantages d'une fiche technique restent théoriques.
