Chapitre 1.2 — PaaS, VPS, cloud : le paysage

⏱️ TL;DR — Quatre grandes familles d’hébergement, du plus « géré » au plus « à toi de tout faire » : l’hébergement mutualisé (vieux monde PHP), le PaaS (Vercel, Netlify, Render — tu pousses du code, ils gèrent le serveur), le VPS (une machine Linux à toi, tu gères tout — l’objet de ce cours), et le cloud / dédié (VPS sous stéroïdes, à l’échelle). Le compromis est toujours le même : plus c’est géré, moins tu contrôles et plus ça coûte au passage à l’échelle ; plus c’est brut, plus tu es libre et responsable. Ce chapitre te donne la grille pour choisir — et pourquoi ce cours parie sur le VPS.

🎯 Objectifs

Distinguer mutualisé, PaaS, VPS, serveur dédié et cloud.
Comprendre le compromis central : contrôle vs commodité vs coût.
Savoir quand un PaaS est le bon choix, et quand un VPS gagne.
Situer où se placent Vercel, un VPS Hetzner/OVH, et AWS dans ce paysage.

Le curseur unique : contrôle ↔ commodité

Tout l’hébergement se lit sur un seul axe. À une extrémité, on te mâche tout (tu pousses du code, le reste est invisible) mais tu es enfermé dans les choix du fournisseur. À l’autre, tu as une machine nue : liberté totale, mais tout est ta responsabilité (sécurité, mises à jour, sauvegardes).

Il n’y a pas de « meilleur » dans l’absolu : il y a le bon choix pour un projet donné. Passons-les en revue.

Les quatre familles

L’hébergement mutualisé

Le plus ancien. Une grosse machine partagée entre des centaines de clients, un panneau de contrôle (cPanel/Plesk), du FTP, une base MySQL, et surtout PHP. C’est ce qui a hébergé le web des années 2000 et une bonne partie de WordPress. Bon marché, zéro compétence système, mais très limité : pas de Node.js longue durée, pas de contrôle, voisins bruyants (un autre site sur la machine peut la ralentir). Pour un dev Next.js/Node moderne, c’est rarement adapté. On le cite pour la culture, on n’y reste pas.

Le PaaS (Platform as a Service)

Vercel, Netlify, Render, Fly.io, Railway. Le modèle qui a séduit les devs front : tu connectes ton dépôt git, tu pushes, et la plateforme build et déploie automatiquement. Elle gère le serveur, la mise à l’échelle, le HTTPS, le CDN — tu ne vois jamais de Linux. C’est génial pour démarrer vite, surtout du front/JAMstack.

Les contreparties :

Enfermement (vendor lock-in) : ton déploiement dépend de leurs conventions ; migrer ailleurs demande du travail.
Limites techniques : durée d’exécution des fonctions bornée, difficile d’avoir un service qui tourne en continu, un cron lourd, une base sur la même machine, des WebSockets persistants, des binaires système.
Coût au passage à l’échelle : très abordable (souvent gratuit) au début, la facture peut s’envoler avec le trafic, les fonctions serverless, la bande passante.
Boîte noire : quand ça casse, tu débogues sans accès à la machine.

Le VPS (Virtual Private Server) — le sujet de ce cours

Une machine virtuelle dédiée, à toi. Un vrai Linux avec sa propre IP, sur lequel tu as les pleins pouvoirs (root). Tu installes ce que tu veux, tu fais tourner ce que tu veux, aussi longtemps que tu veux. C’est ton serveur, pour quelques euros par mois.

Le prix de la liberté : tout est à toi. Sécuriser, mettre à jour, configurer Nginx, obtenir le HTTPS, faire tourner l’app en service, sauvegarder, surveiller. C’est précisément ce que ce cours t’apprend. En échange : contrôle total, coût prévisible et bas, aucune limite artificielle, et une compétence qui te suit partout.

Le serveur dédié & le cloud

Le dédié : une machine physique entière rien que pour toi (plus de puissance, plus cher). Le cloud (AWS, Google Cloud, Azure) : un VPS poussé à l’extrême — des dizaines de services à la carte (calcul, stockage, bases managées, files, IA…), facturés à l’usage, pilotables par API et par infrastructure-as-code. Puissant et élastique, mais complexe et facilement ruineux si mal maîtrisé. Un VPS bien opéré couvre l’immense majorité des besoins d’un projet ou d’une PME avant d’avoir besoin de ça.

Le tableau de décision

Critère	Mutualisé	PaaS (Vercel…)	VPS	Cloud (AWS…)
Compétence système requise	Aucune	Faible	Moyenne (ce cours)	Élevée
Contrôle	Très faible	Faible	Total	Total
Services longue durée / cron / DB locale	Non	Difficile	Oui	Oui
HTTPS, scaling « automagiques »	Partiel	Oui	À faire soi-même	À configurer
Coût au démarrage	Bas	Très bas / gratuit	Bas (quelques €/mois)	Variable
Coût à l’échelle	—	Peut exploser	Prévisible / bas	Selon maîtrise
Enfermement	Moyen	Fort	Faible	Fort
Idéal pour	Vieux PHP	Front/JAMstack, MVP rapides	Full-stack, contrôle, coût	Grande échelle, équipes ops

Alors, PaaS ou VPS ?

Pas de guerre de religion. Une règle simple :

💡 Réflexe — PaaS pour aller vite sur du front ou un MVP, quand tu ne veux pas penser au serveur et que le trafic/les besoins restent dans les clous. VPS dès que tu veux du contrôle, un coût maîtrisé, des services que le PaaS interdit (base locale, cron, longue durée, WebSockets), ou simplement apprendre à opérer ta prod. Beaucoup d’équipes matures utilisent les deux : un PaaS pour la vitrine statique, un VPS pour l’API et la base.

⚠️ Piège — Choisir un PaaS uniquement parce que « c’est plus simple », sans regarder la facture à l’échelle ni les limites techniques. Beaucoup de projets démarrent gratuits sur du serverless, puis découvrent des factures à trois chiffres et des impasses techniques (« impossible de faire tourner ce worker »). Choisis en fonction de là où tu vas, pas seulement de là où tu démarres.

🔒 Sécurité — Attention à l’illusion : sur un PaaS, la sécurité de la machine est gérée pour toi — mais pas celle de ton application (injections, secrets, dépendances, auth). Sur un VPS, tu gères les deux. Ce cours t’apprend la sécurité de la machine et garde un œil sur celle de l’app ; les deux comptent, où que tu héberges.

🧭 Sur FormaCampus — FormaCampus avait le front Next.js sur Vercel et une base managée chez un tiers. Trois déclencheurs poussent au VPS : (1) un worker d’export de données (rapports PDF nocturnes) impossible à faire tourner proprement en serverless ; (2) la facture de bande passante qui grimpe avec les vidéos de cours ; (3) l’envie de garder les données sur une machine en France, mieux maîtrisée côté RGPD. Décision : un VPS Ubuntu LTS qui héberge front, API Symfony et Postgres. Ils gardent un CDN devant pour les assets — le pragmatisme, pas le dogme.

📚 La doc — Les offres, tarifs et limites évoluent vite. Compare toujours sur les sites officiels des fournisseurs (Hetzner, OVHcloud, DigitalOcean, Scaleway pour les VPS ; Vercel, Netlify, Render pour les PaaS) au moment de choisir, plutôt que de te fier à un comparatif figé.

✏️ Exercices

Exercice 1 — Le bon outil. Pour chacun de ces projets, PaaS ou VPS (et pourquoi) ? (a) Un portfolio statique à publier ce soir. (b) Une API Node avec WebSockets temps réel, un cron d’agrégation nocturne et une base Postgres, budget serré. (c) Un blog WordPress d’entreprise.

✅ Solution

(a) PaaS (Vercel/Netlify) : statique, rapide, gratuit, HTTPS et CDN inclus — aucun intérêt à gérer un serveur. (b) VPS : WebSockets persistants, cron et base locale sont exactement ce que le PaaS rend difficile ou coûteux ; un VPS à quelques euros fait tout ça, budget maîtrisé. (c) VPS (ou mutualisé haut de gamme) : WordPress a besoin de PHP-FPM, MySQL et d’un stockage de fichiers persistant ; un VPS donne le contrôle et de bonnes perfs. On accepte un hébergement WordPress managé si l’équipe ne veut aucune ops.

Exercice 2 — Démonte l’argument. Un collègue affirme : « Le VPS c’est dépassé, tout le monde est sur le serverless. » Donne-lui deux cas concrets où le VPS reste clairement supérieur.

✅ Solution

Par exemple : (1) un service longue durée (worker, WebSocket, file d’attente, cron lourd) — mal adapté au serverless qui borne la durée d’exécution ; (2) un besoin de coût prévisible et bas à l’échelle ou de contrôle des données (héberger sa propre base dans une juridiction choisie, sans dépendre d’un tiers). On accepte aussi : éviter l’enfermement, faire tourner des binaires système, ou simplement maîtriser de bout en bout son infra.

🧠 Quiz de révision

1. Quel est le compromis central qui structure tout le paysage de l’hébergement ?

Contrôle vs commodité (et coût au passage à l’échelle). Plus l’hébergement est « géré » (mutualisé, PaaS), moins tu contrôles et plus tu risques l’enfermement et des coûts qui grimpent ; plus il est « brut » (VPS, dédié), plus tu es libre mais responsable de tout.

2. Qu’est-ce qu’un PaaS et quelle est sa principale limite pour un projet full-stack ?

Une plateforme qui build et déploie ton code depuis git en gérant le serveur pour toi (Vercel, Netlify, Render). Limite : difficile d’y faire tourner des services longue durée, cron, bases locales, WebSockets persistants ; enfermement et coûts qui peuvent exploser à l’échelle.

3. Qu’est-ce qu’un VPS ?

Une machine virtuelle privée (un vrai Linux avec sa propre IP) sur laquelle tu as les pleins pouvoirs. Liberté et contrôle total, coût bas et prévisible, en échange de toute la responsabilité d’administration (sécurité, MàJ, config, sauvegardes).

4. Cite un cas où le PaaS est clairement le meilleur choix.

Un site statique ou un MVP front à publier vite, sans envie de gérer un serveur, avec HTTPS et CDN inclus et un trafic qui reste dans les offres gratuites/abordables.

5. Pourquoi le cloud (AWS…) n’est-il pas le choix par défaut d’un petit projet ?

Parce qu’il est complexe et facilement coûteux si mal maîtrisé. Un VPS bien opéré couvre l’immense majorité des besoins d’un projet ou d’une PME avant d’avoir besoin de l’élasticité et des services managés du cloud.

Chapitre suivant : Anatomie d’un VPS — CPU, RAM, disque, IP : de quoi une machine est vraiment faite.