Chapitre 1.4 — Choisir & dimensionner
⏱️ TL;DR — Trois décisions avant de créer ton VPS : le fournisseur (Hetzner, OVHcloud, DigitalOcean, Scaleway… — arbitrage prix / localisation / interface), la distribution (dans ce cours : Ubuntu Server LTS ou Debian stable — stables, immenses communautés,
apt+systemd), et la taille (vCPU / RAM / disque). Règle d’or du dimensionnement : commence petit et raisonnable, mais choisis un fournisseur chez qui grossir est facile. Un VPS se redimensionne ; se tromper de plateforme se paie en migration. Ce chapitre te donne des repères concrets pour choisir sans y passer une semaine.
🎯 Objectifs
- Choisir un fournisseur de VPS selon des critères clairs (prix, localisation, sauvegardes, interface).
- Choisir une distribution et comprendre pourquoi LTS compte.
- Dimensionner un premier serveur (ordres de grandeur, pas de sur-ingénierie).
- Éviter les erreurs classiques (sous-dimensionner la RAM, sur-payer « au cas où », mauvaise région).
Décision 1 — Le fournisseur
Le marché du VPS est concurrentiel, ce qui est une bonne nouvelle : les prix sont bas. Les noms qui reviennent : Hetzner (réputé pour le rapport perf/prix, Allemagne/Finlande), OVHcloud (français, large gamme), DigitalOcean (interface soignée, doc excellente), Scaleway (français), Vultr, Linode/Akamai. Tous font très bien le travail pour ce cours.
Les critères qui comptent vraiment :
| Critère | Pourquoi ça compte |
|---|---|
| Prix / ressources | Le rapport vCPU-RAM-disque par euro varie ; à besoin égal, l’écart de prix est réel. |
| Localisation du datacenter | Proximité = latence plus faible pour tes utilisateurs ; juridiction = enjeu RGPD (données en UE). |
| Sauvegardes & snapshots | Un bouton « snapshot » et des backups automatiques (souvent en option payante) simplifient la vie. |
| Interface & API | Un bon panneau de contrôle et une API (pour automatiser plus tard) font gagner du temps. |
| Réputation réseau & support | Qualité du réseau, anti-DDoS de base, réactivité du support. |
💡 Réflexe — Privilégie un fournisseur chez qui redimensionner (passer à une offre supérieure) et prendre un snapshot se font en un clic. Tu vas presque certainement vouloir grossir ou cloner ta machine un jour ; que ce soit trivial change tout. La localisation UE est un bon défaut pour un public francophone (latence + RGPD).
Décision 2 — La distribution
Question fréquente : « quelle distribution Linux ? » Pour un serveur de production, on ne cherche pas l’exotisme : on veut stable, bien documenté, largement supporté. Deux choix évidents :
- Ubuntu Server LTS — le défaut le plus sûr. Communauté immense, doc et tutoriels partout, paquets récents. Les versions LTS (Long Term Support, ex. 24.04) sont supportées 5 ans : c’est ce qu’on veut en prod.
- Debian stable — la référence de la stabilité (ex. Debian 12 « Bookworm »). Paquets un peu plus conservateurs, très fiable, base d’Ubuntu.
Les deux utilisent APT (apt install), dpkg et systemd : tout ce cours s’applique aux deux à l’identique. Choisis l’une, tu ne te trompes pas.
⚠️ Piège — Choisir une version non-LTS ou trop récente « pour avoir le dernier truc ». En prod, tu veux le contraire de la nouveauté : de la stabilité et un support long. Une version non-LTS cesse d’être maintenue vite, te forçant à migrer (avec ses risques) bien plus tôt. En prod, LTS par défaut.
🔒 Sécurité — Le choix LTS est un choix de sécurité : une version supportée reçoit des correctifs de sécurité pendant des années. Une version en fin de vie n’en reçoit plus — tes failles connues restent ouvertes. On automatisera d’ailleurs l’installation des correctifs de sécurité (
unattended-upgrades, Partie 5).
Décision 3 — La taille (dimensionner)
Combien de vCPU, de RAM, de disque ? Le réflexe du débutant est de sur-payer « au cas où » ou de sous-dimensionner pour économiser. La bonne approche : estimer par la charge, partir raisonnable, et grossir si besoin (un VPS se redimensionne).
Quelques ordres de grandeur (indicatifs — les offres évoluent, vérifie les specs du jour) :
| Usage | vCPU | RAM | Disque | Commentaire |
|---|---|---|---|---|
| Petit site statique, side-project, apprentissage | 1 | 1–2 Go | 20–40 Go | Suffit pour apprendre et pour du petit trafic. |
| App Next.js + petite base, trafic modéré | 2 | 2–4 Go | 40–80 Go | Le point de départ confortable de ce cours. |
| Front + API + base sur la même machine, prod sérieuse | 2–4 | 4–8 Go | 80–160 Go | Plusieurs services qui cohabitent, marge de RAM. |
| Charge lourde, Docker + plusieurs services | 4+ | 8–16 Go+ | 160 Go+ | On envisage aussi de séparer les services (Partie 15). |
Le facteur le plus souvent sous-estimé est la RAM : Node (surtout au build), Postgres et Nginx en consomment simultanément. Mieux vaut un peu trop de RAM qu’un OOM killer qui tue ton app en pleine journée.
💡 Réflexe — Dimensionne pour la charge réelle, pas pour le fantasme. Un side-project n’a pas besoin de 8 vCPU. Pars sur une taille « app + petite base » (2 vCPU / 2–4 Go), mesure en prod (Partie 14), et monte si les métriques le disent. Payer pour des ressources inutilisées, c’est brûler du budget ; sous-dimensionner, c’est des pannes. Le juste milieu se mesure, il ne se devine pas.
📚 La doc — Les grilles (tailles, prix, régions, options de backup) changent souvent. Compare toujours sur les pages officielles au moment de commander, et regarde si le fournisseur propose un redimensionnement à chaud et des snapshots. Ne te fie pas à un tableau figé (celui ci-dessus compris) pour les chiffres exacts.
Une méthode en cinq questions
Avant de cliquer « créer », réponds à ceci :
- Où sont mes utilisateurs ? → choisis une région proche (latence) et conforme (RGPD).
- Qu’est-ce qui va tourner ? (front seul ? + API ? + base ? Docker ?) → en déduire RAM/CPU.
- Combien de données ? (base, uploads, logs, sauvegardes locales) → dimensionner le disque avec de la marge.
- Puis-je grossir facilement chez ce fournisseur ? → vérifier redimensionnement + snapshots.
- Quelle distribution ? → Ubuntu LTS ou Debian stable, sans hésiter.
✏️ Exercices
Exercice 1 — Dimensionne. Un dev veut héberger un blog Next.js (SSG, peu de SSR) avec une petite base Postgres, pour un public français, budget serré. Propose une région, une distribution et une taille de départ, en justifiant.
✅ Solution
Région : un datacenter en France ou en UE (latence pour le public FR + conformité RGPD des données). Distribution : Ubuntu Server LTS (ou Debian stable) — support long, doc abondante. Taille : ~2 vCPU / 2–4 Go RAM / 40 Go disque — confortable pour Next.js + une petite base, avec de la marge de RAM pour le build ; on pourra grossir si le trafic monte. On vérifie que le fournisseur permet un redimensionnement facile.
Exercice 2 — Repère l’erreur. Un collègue commande « le plus petit VPS à 1 Go de RAM » pour faire tourner Next.js en SSR + Postgres + un build sur la machine, sur une version Ubuntu non-LTS récente, dans un datacenter à l’autre bout du monde parce que c’était 1 € moins cher. Liste trois problèmes.
✅ Solution
(1) RAM insuffisante : SSR Node + Postgres + build sur 1 Go → risque quasi certain d’OOM killer qui tue l’app ; il faut plus de RAM (et/ou builder ailleurs, et/ou du swap). (2) Version non-LTS : support court, migration forcée bientôt, moins de correctifs long terme — en prod on veut du LTS. (3) Datacenter lointain : latence élevée pour des utilisateurs qui ne sont pas là-bas, et potentiel souci de juridiction/RGPD ; l’économie d’1 € ne vaut pas la dégradation d’expérience. On corrige : taille RAM adaptée, distribution LTS, région proche du public.
🧠 Quiz de révision
1. Pourquoi choisir une version LTS de la distribution en production ?
Parce qu’elle est supportée longtemps (ex. 5 ans pour une Ubuntu LTS) : stabilité et surtout correctifs de sécurité pendant des années. Une version non-LTS ou en fin de vie cesse d’être maintenue et te force à migrer tôt, en laissant des failles ouvertes entre-temps.
2. Quelle ressource est la plus souvent sous-dimensionnée, et avec quelle conséquence ?
La RAM. Node (au build surtout), Postgres et Nginx en consomment ensemble ; trop peu de RAM déclenche l’OOM killer qui tue un processus (souvent ton app). Mieux vaut une marge de RAM (+ un peu de swap).
3. Pourquoi la localisation du datacenter compte-t-elle ?
Pour la latence (un datacenter proche des utilisateurs = site plus réactif) et pour la juridiction/RGPD (données personnelles hébergées en UE, par exemple). Choisir une région proche et conforme au public.
4. Quelle est la bonne stratégie de dimensionnement de départ ?
Partir raisonnable (dimensionner pour la charge réelle estimée, pas « au cas où »), mesurer en prod, puis grossir si les métriques le justifient — en s’assurant que le fournisseur permet un redimensionnement facile.
5. Ubuntu LTS et Debian stable : ce cours s’applique-t-il aux deux ?
Oui, à l’identique : les deux utilisent APT (apt), dpkg et systemd. Les commandes et concepts du cours valent pour l’une comme pour l’autre.
Chapitre suivant : Le cycle de vie d’une requête — ce qui se passe, étape par étape, entre le clic du visiteur et l’affichage de ta page.