Choisir son premier plan VPS (sans payer trop cher)

Partez de la charge de travail, pas des specs

Avant de comparer les vCPU et les gigaoctets, notez ce que le serveur va réellement exécuter. Un site personnel et un reverse proxy ? Une API Node ou Python ? Un bot Telegram ? Quelques tâches cron ? Chacun de ces usages a une empreinte très différente, et c'est cette liste — pas la page de tarifs — qui doit guider votre choix.

Soyez honnête aussi sur la concurrence. Un blog lu par quelques centaines de personnes par jour et une API interrogée chaque seconde par une application mobile sont deux choses très différentes, même si les deux ressemblent à de 'petits projets'. Une fois la charge de travail claire, le bon plan se choisit souvent tout seul.

La RAM est généralement la vraie contrainte

Sur les petits serveurs, la RAM s'épuise presque toujours bien avant le CPU. Les charges web passent l'essentiel de leur vie à attendre le réseau, mais chaque processus que vous lancez garde sa mémoire en permanence. Quand la RAM manque, le noyau se met à tuer des processus — et c'est ainsi qu'un ₹ économisé sur un plan devient une panne à 2 heures du matin.

Pas besoin de chiffres précis, juste d'estimations honnêtes. Ces ordres de grandeur couvrent la plupart des premiers serveurs :

• Un site statique ou un reverse proxy se contente de ~512MB–1GB
• Une API Node ou Python demande en général 1–2GB
• Une petite base de données sur la même machine ajoute au moins 1GB
• Docker a son propre surcoût — prévoyez de la RAM par conteneur, pas seulement par application

CPU et comportement en rafale

Les vCPU partagés font plus peur qu'ils ne le devraient. La plupart des charges web fonctionnent en rafales : une requête arrive, le CPU grimpe quelques millisecondes, puis retombe au repos. Les cœurs partagés sont conçus exactement pour ce schéma, et pour l'immense majorité des sites, API et bots, ils sont indiscernables de cœurs dédiés — pour une fraction du prix.

Ce qu'il faut surveiller, c'est la charge soutenue. Si votre travail monopolise un cœur pendant des minutes entières — encodage vidéo, gros builds, génération de rapports volumineux — un vCPU partagé semblera bridé. Regardez vos graphiques CPU après le lancement : des pics occasionnels, c'est normal ; une ligne plate proche de 100 % signifie qu'il est temps de passer à plus de cœurs.

Disque, bande passante et tout ce qu'on oublie

Le disque se remplit d'une manière que personne ne planifie. Les logs applicatifs grossissent en silence pendant des mois, les sauvegardes s'empilent à côté des données qu'elles protègent, et les images envoyées par les utilisateurs ne cessent d'augmenter. Un disque de 25GB qui paraissait généreux le premier jour peut être plein au sixième mois — configurez donc la rotation des logs tôt et sachez où se trouvent vos gros répertoires.

La meilleure solution est de sortir complètement les fichiers volumineux et statiques du VPS. Déplacez images, uploads et sauvegardes vers un stockage objet comme Nest Storage : les buckets grandissent sans rien repartitionner, votre disque reste léger, et la bande passante des médias ne concurrence plus votre application. Votre VPS doit héberger le code et les données chaudes — pas votre médiathèque.

Commencez petit, redimensionnez plus tard

Voici la partie qui vous fait économiser : sur Anested Cloud, un VPS se redimensionne sur place, donc mettre à niveau plus tard vaut mieux que surdimensionner maintenant. Prendre un grand plan 'au cas où', c'est payer chaque mois pour de la RAM qui reste vide. Commencer petit, c'est payer ce qu'on utilise et monter en gamme le jour où les graphiques le demandent.

Commencez donc sur le niveau gratuit ou le plus petit plan, déployez votre vraie charge de travail et mesurez pendant une semaine ou deux. Si la mémoire reste confortablement sous la limite et que le CPU ne fait que des pics, c'est réglé — vous avez trouvé votre plan. Sinon, redimensionnez en deux clics et retournez construire. C'est tout le cadre : la charge d'abord, la RAM honnêtement, mesurer, redimensionner.