Un VPS, oui, mais pas pour n'importe quoi

Un VPS (Virtual Private Server) est un serveur Linux loué chez un hébergeur (DigitalOcean, Hetzner, OVH, Scaleway...) dont tu administres tout toi-même : mise à jour du système, serveur web, certificats HTTPS, pare-feu, sauvegardes. C'est le réflexe qui ressort dès qu'un projet devient « un peu sérieux » : portfolio ? VPS. Petite API ? VPS. Site vitrine ? VPS. Appli utilisée par douze personnes ? Tu vois le tableau. Le problème n'est pas le VPS : c'est de croire qu'une seule réponse convient à toutes les situations.

D'abord : qu'est-ce que tu déploies, au juste ?

Le mot « site web » cache des architectures très différentes. Un site statique contient des fichiers déjà prêts (HTML, CSS, JavaScript) que le navigateur reçoit tels quels. Une application dynamique exécute du code à chaque visite : elle lit et écrit des données, gère des comptes, traite des paiements, envoie des emails. Statique ou dynamique, serveur permanent ou non, base de données ou non : ce sont les vraies questions avant d'ouvrir un catalogue d'hébergeurs.

1. Le contenu est-il le même pour tous les visiteurs ? Si tout le monde reçoit les mêmes pages et que le site ne change que quand tu le publies, il est statique.
2. Un programme doit-il tourner en continu ? Une API, un bot, un traitement de fichiers ont besoin d'un serveur qui ne dort jamais.
3. Stockes-tu des données ? Un formulaire, des comptes utilisateurs, un panier cachent presque toujours une base de données.
4. Faut-il contrôler la machine au niveau système ? Version précise d'un logiciel, accès réseau particuliers, services internes : c'est ici que le VPS trouve sa raison d'être.

Niveau 1 : l'hébergement statique, gratuit et sans entretien

Un site statique n'a besoin d'aucun serveur applicatif : il suffit de ranger les fichiers quelque part et de les envoyer au navigateur. En général, ton fournisseur les copie sur un CDN (un réseau de serveurs répartis dans le monde) pour que la page se charge vite partout.

Les options de départ sont gratuites : GitHub Pages publie directement le contenu d'un dépôt, Netlify et Vercel servent aussi du statique avec de généreuses limites pour un projet qui démarre. C'est parfait pour un portfolio, une documentation, une landing page ou un blog généré à l'avance.

Si tu n'as jamais déployé, fais-le au moins une fois à la main : crée un dépôt GitHub, pousse le code, connecte le dépôt sur Netlify ou Vercel, choisis la branche, c'est en ligne. La plateforme s'occupe du certificat HTTPS et de la mise en cache sur le CDN. Tu auras vu tout le pipeline (code, build, publication) et tu reconnaîtras ces mêmes étapes sur n'importe quelle autre solution.

Niveau 2 : les plateformes managées (PaaS), git push = déployé

Vercel, Netlify et leurs cousins sont des PaaS : des plateformes sur lesquelles tu déploies ton propre code sans administrer de machine. Tu connectes un dépôt Git, la plateforme détecte ton framework (Next.js, React, Vue...), lance le build (la fabrication des fichiers finaux), publie la version, et crée une URL d'aperçu pour chaque branche.

git push origin main

Un git push, et une nouvelle version est en ligne. C'est le meilleur rapport valeur-effort pour quelqu'un dont le métier n'est pas l'administration système. L'idée n'est pas d'avoir moins de puissance : c'est de ne pas gérer soi-même ce qui n'apporte rien à ton projet. Les offres gratuites couvrent de l'ordre de 100 Go de bande passante par mois (Vercel, Netlify), largement de quoi avancer.

Et Supabase, le BaaS, dans tout ça ?

Autre confusion fréquente : Supabase n'est pas un hébergeur pour ton frontend. C'est un BaaS (back-end as a service, autrement dit « back-end en location ») : une plateforme qui fournit une base PostgreSQL gérée, de l'authentification, du stockage de fichiers, du temps réel et des fonctions serveur. C'est le « Firebase open source », si ça t'aide à le situer.

Frontend → Vercel ou Cloudflare (le site)
Données → Supabase (base, comptes, fichiers)

L'architecture moderne fréquente : le frontend est un site servi par Vercel ou Cloudflare, les données et l'authentification viennent de Supabase. Tu n'es plus obligé de caser toute ton application sur une seule machine. Et comme Supabase est open source, tu pourras même l'auto-héberger un jour si tu veux tout garder chez toi.

Niveau 3 : le VPS, quand ça se justifie vraiment

Sur un VPS, c'est toi le propriétaire : tu installes Nginx, Docker, Node.js, PostgreSQL, Redis, tu choisis comment tout communique, tu règles ton réseau. Deux entrées de gamme fréquentes : un Droplet chez DigitalOcean (de l'ordre de 6 $/mois) ou une machine chez Hetzner (à partir d'environ 4 €/mois, facturée à l'heure). Puissant, mais chaque avantage a un prix.

• tu dois faire tourner des processus en permanence (files d'attente, bots, traitements) ;
• tu veux faire cohabiter plusieurs services Docker sur une seule machine ;
• ton application exige une configuration système précise ;
• tu héberges plusieurs applications dans le même environnement ;
• tu as besoin d'un contrôle fin du réseau (pare-feu, ports, domaines) ;
• tu acceptes d'entretenir : mises à jour, certificats, sauvegardes, surveillance, redémarrages.

Pose donc la question à l'envers : prends un VPS quand le contrôle de l'infrastructure est un besoin réel, pas une envie de développeur.

Et si la réponse est oui, garde cette liste de contrôle sous la main, avant même de pointer ton nom de domaine :

• accès uniquement par clé SSH, mot de passe désactivé ;
• pare-feu ouvert sur les seuls ports utiles (SSH, 80, 443) ;
• mises à jour de sécurité automatiques ;
• sauvegardes en dehors de la machine, chez un autre fournisseur ;
• HTTPS automatique dès le premier jour (Caddy ou Let's Encrypt) ;
• une alerte simple dès que le serveur cesse de répondre.

Et Docker dans tout ça ?

Docker n'est pas un hébergeur : c'est une façon d'empaqueter une application et toutes ses dépendances dans un conteneur qui s'exécute à l'identique sur n'importe quelle machine. Image, conteneur, compose (documentation officielle) : pense « recette » pour l'image, « plat servi » pour le conteneur, et « menu complet » pour l'ensemble décrit dans un fichier compose.yml.

docker compose up -d

Avec docker compose, une seule commande démarre plusieurs services définis dans ton architecture (API, base, cache, tâches...). Docker se combine avec tout : VPS + Docker (le classique), cloud de conteneurs, ou CI/CD pour que tes tests tournent dans le même environnement que la production. Il devient indispensable dès que ton application a plusieurs composants ou que tu veux un résultat identique d'une machine à l'autre.

services:
  api:
    build: .
    environment:
      DATABASE_URL: postgres://user:pass@db:5432/mabase   # secrets stockés à part
    ports:
      - "3000:3000"
    depends_on:
      - db
  db:
    image: postgres:16
    volumes:
      - pgdata:/var/lib/postgresql/data
volumes:
  pgdata:

Niveau 4 : serverless et Edge

Le serverless (littéralement « sans serveur ») délègue encore plus : tu ne fais pas tourner un serveur en permanence, tu déploies des fonctions qui ne s'exécutent qu'à l'appel, avec une facturation à l'usage et une infrastructure qui s'adapte toute seule. Vercel et Netlify embarquent du serverless par défaut via leurs fonctions.

Cloudflare pousse l'idée sur son réseau Edge : le code s'exécute dans les centres de données les plus proches du visiteur plutôt que sur une machine centrale. Ses Workers peuvent aujourd'hui servir aussi des fichiers statiques, ce qui permet d'héberger une application complète en un seul déploiement. À noter : les offres serverless ont des limites (temps d'exécution court, pas d'état persistant), et il faut souvent leur adosser une base de données externe.

Attention à un piège du serverless : le cold start. Une fonction qui n'a pas été appelée depuis un moment met de l'ordre d'une à plusieurs centaines de millisecondes à se réchauffer avant de répondre. Indolore pour une API de taille moyenne, il se fait sentir sur les chemins critiques : premier écran d'une page, déclenchement d'un paiement, réponse attendue en dessous de 300 ms.

Et si tu veux partir, un jour ?

C'est la question que personne ne pose quand tout va bien : par où vais-je sortir ? Chaque plateforme a ses pièges d'adhérence (le terme consacré est vendor lock-in) : fonctions serverless propriétaires, base de données pénible à exporter, processus de déploiement indissociable de l'outil. Règle simple : garde exportable ce qui t'appartient (code, données, configuration), et ne colle pas ton projet à une fonction exclusive tant que tu hésites. C'est ce qui rend une migration possible le jour où la facture ou les limites te poussent dehors.

Concrètement, je pars sur quoi ?

1. Portfolio ou landing page : hébergement statique gratuit (GitHub Pages, Netlify, Vercel).
2. Blog : générateur statique déployé sur Netlify ou Vercel, ou plateforme dédiée si tu ne veux rien coder.
3. Appli avec comptes et données : frontend chez Vercel ou Cloudflare + Supabase en BaaS. Simple, gratuit au démarrage, évolutif.
4. API ou petits services : un PaaS type Render ou Railway pour commencer, un VPS ensuite si les besoins débordent.
5. Plusieurs services Docker : VPS ou cloud de conteneurs (pas d'orchestration au début).
6. Contrôle système total : un VPS simple chez Hetzner ou DigitalOcean.
7. Très fort trafic, grandes contraintes : il n'y a plus de réponse simple ; il faut penser cache, CDN, bases dédiées et métriques, pas seulement « quel hébergeur ».

Exemple réaliste pour un petit SaaS : un frontend sur Vercel et une base Supabase coûtent 0 € au début. Le jour où un traitement lourd (import de fichiers, envoi d'emails) dépasse ce que font les fonctions, tu déplaces uniquement ce service sur un petit VPS Hetzner à quelques euros par mois, en le branchant au reste. Pas d'architecture à tout réécrire : une brique a bougé, c'est tout.

Preuve par l'exemple : le site où tu lis cet article tourne lui-même sur cette architecture. Le frontend est généré à l'avance et déployé chez Vercel, les données (articles, commentaires, comptes) vivent dans une base Supabase. Aucun VPS, aucun serveur à maintenir, zéro facture d'hébergement au lancement, et chaque brique est remplaçable sans tout réécrire.

Le mot de la fin

Le déploiement moderne n'est pas un concours de serveurs. Un développeur confirmé ne choisit pas la solution la plus puissante : il choisit celle qui répond au besoin avec le moins de complexité inutile. Un portfolio n'a pas besoin de Kubernetes, une petite API n'a pas besoin de trois VPS, un SaaS n'est pas obligé d'administrer lui-même son PostgreSQL. Et quand les contraintes le réclament, le VPS reste parfaitement légitime.

La bonne infrastructure n'est pas celle qui offre le plus de contrôle. C'est celle qui offre le contrôle dont ton projet a réellement besoin.

Petit glossaire pour la route

• VPS : serveur Linux loué que tu administres toi-même (système, applications, sécurité).
• PaaS : plateforme où tu déploies ton propre code sans gérer la machine (Vercel, Netlify, Railway, Render).
• BaaS : services back-end prêts à l'emploi (base, comptes, fichiers) reliés à ton code (Supabase, Firebase).
• CDN : réseau de serveurs qui copie ton site près des visiteurs pour accélérer le chargement.
• Build : l'étape qui fabrique les fichiers finaux d'une application (compilation, minification, génération).
• Serverless : fonctions exécutées à la demande, sans serveur permanent ni facturation à l'inactivité.
• Edge : exécution du code au plus près de l'internaute (les Workers de Cloudflare, par exemple).
• Conteneur : application et dépendances empaquetées, exécutées à l'identique sur n'importe quelle machine (Docker).

Sources et pour aller plus loin

• Vercel : déploiement de sites et d'applications frontend
• Netlify : hébergement statique, fonctions et aperçus
• Supabase : plateforme back-end open source
• Supabase Docs : guide d'auto-hébergement
• Cloudflare : documentation Workers et réseau Edge
• Docker : documentation officielle, compose et démarrage
• Hetzner Cloud : VPS économiques
• DigitalOcean : Droplets
• Render : PaaS pour démarrer une API