Tu peux optimiser un mutualisé pendant des heures (htaccess, cache, compression Gzip, lazy loading) et c’est pertinent. Mais un jour, tu auras besoin de WebSockets pour du temps réel, ou de scaling automatique pour un pic de traffic. Ce ne sont pas des problèmes de configuration, ce sont des choix d’architecture. C’est là que le cloud entre en jeu.
Pourquoi ces services existent
L’hébergement mutualisé est une excellente solution. Avec une bonne configuration (cPanel, protection via htaccess, optimisation du cache, robots.txt, config.php) on peut aller très loin. Beaucoup de sites performants tournent sur mutualisé sans aucun problème.
Mais il existe des limites architecturales qu’aucune configuration ne peut dépasser :
| Fonctionnalité | Mutualisé optimisé | Cloud / VPS |
|---|---|---|
| CI/CD | ⚠️ Possible (GitHub Actions, Gitea) | ✅ Intégré nativement |
| Scaling | ❌ Plafond physique du serveur | ✅ Automatique selon la charge |
| CDN mondial | ❌ Un seul emplacement | ✅ 300+ nœuds edge |
| Realtime (WebSocket) | ❌ Architecture non conçue pour | ✅ Natif (Cloudflare, Supabase) |
| Serverless | ❌ Process Passenger limité | ✅ Zéro coût si pas de traffic |
| Multi-région | ❌ Un seul datacenter | ✅ Déploiement mondial |
PaaS = Cloud : dans cet article, “Cloud” et “PaaS” (Platform as a Service) désignent la même chose : des plateformes comme Vercel, Netlify ou Railway qui gèrent l’infrastructure pour toi. “BaaS” (Backend as a Service) = Supabase, Firebase.
Le Contexte
Le plafond invisible
Le mutualisé, c’est le covoiturage : tu partages la voiture avec d’autres, c’est pas cher, et ça va très bien pour les trajets quotidiens. Mais tu ne choisis ni l’itinéraire ni la vitesse, et si tu as besoin de transporter un piano, ça ne passe pas.
Le VPS, c’est ta propre voiture : tu contrôles tout, mais tu gères l’entretien.
Le cloud, c’est le taxi : tu payes à l’usage, quelqu’un d’autre conduit, et ça scale selon la demande.
Le Tableau Comparatif
Cloudflare et Supabase offrent un tier gratuit permanent
villes dans le monde : le code s'exécute plus près de l'utilisateur
o2switch, OVH, Infomaniak : hébergement partagé
Hetzner, OVH, Infomaniak : contrôle total
| Service | Type | Idéal pour | Prix HT/mois | Avantage clé | Limite |
|---|---|---|---|---|---|
| o2switch | Mutualisé traditionnel | PHP, WordPress, Symfony | 7€ | Simple, pas cher, support FR | CI/CD à configurer, pas de scaling |
| OVH / Infomaniak | Mutualisé | PHP, WordPress, Symfony | 3.50-8€ | Large choix, éco-responsable (Infomaniak) | Variables selon l'offre |
| Hetzner | VPS Cloud | Backends, multi-services | 7.19€ | Rapport qualité/prix imbattable | Datacenter Allemagne |
| OVH VPS | VPS | Backends, multi-services | 3.80-20€ | Large choix de gammes, datacenter France | Sysadmin requis |
| Infomaniak VPS | VPS Cloud | Backends, multi-services | 24.92€ | Éco-responsable, support FR | Plus cher que la concurrence |
| Vercel | Frontend + Serverless | Astro, Next.js (SSG/SSR) | Gratuit / ~18€ (Pro) | CDN mondial, preview PR | Limite au front, back limité |
| Netlify | Frontend + Serverless | Astro, sites statiques | Gratuit / ~8.28€ (Personal) | Form handling, fonctions serverless | Mêmes limites que Vercel |
| Cloudflare | Edge + Storage | Apps realtime, API légères | Gratuit | Workers edge, D1, KV, R2 | CPU limité (10ms free, 30s paid) |
| Railway | Conteneurs Docker | Backends, microservices | Gratuit / ~4.60€ (Hobby) | Polyvalent, bases managées | Pas de CDN, peut coûter cher |
| Supabase | BaaS (Firebase-like) | Apps avec auth + realtime | Gratuit / ~23€ (Pro) | PostgreSQL, realtime, auth | Pas un hébergeur web |
Comment Choisir : Les 5 Étapes
Identifier ton besoin réel
Blog vitrine ? API temps réel ? App avec auth ? Définis si tu as BESOIN du cloud ou si le mutualisé suffit.
Vérifier le budget
Mutualisé = 7€ HT fixe. VPS = 3.80-24.92€ HT fixe. Cloud = variable (peut monter). Définis ta tolérance.
Évaluer tes compétences
Pas de sysadmin ? Le cloud (Vercel, Railway) gère tout. Tu maîtrises Docker ? Le VPS est pertinent.
Tester le gratuit d'abord
Vercel, Netlify, Cloudflare et Supabase ont un tier gratuit. Teste avant de payer.
Scaler si besoin
Commence simple (mutualisé). Ajoute un service cloud quand le besoin se présente, pas avant.
Modèles de Prix : Fixe vs Consommation
La plupart des services cloud fonctionnent par abonnement fixe (VPS, mutualisé) ou à la consommation (serverless, BaaS). Voici la différence :
| Modèle | Fonctionnement | Avantages | Inconvénients | Exemples |
|---|---|---|---|---|
| Freemium | Gratuit avec limites, payant pour plus | Tester gratuitement, scaler si besoin | Lock-in si tu dépasses les limites | Vercel, Netlify, Supabase, Cloudflare |
| Fixe (abonnement) | Tu paies un montant fixe/mois | Prévisible, pas de surprise | Tu payes même si tu n'utilises pas tout | Hetzner, OVH, Infomaniak, o2switch |
| Consommation | Tu paies ce que tu utilises | Scalable, pas de gaspillage | Coût variable, peut exploser | Cloudflare Workers, Railway, Vercel Pro |
Comment éviter les mauvaises surprises ?
- Cloudflare : les Workers gratuits ont 100k requêtes/jour : suffisant pour 99% des petits projets
- Railway : limite ton budget mensuel dans les settings (max 5$ par défaut en Hobby)
- Vercel/Netlify : le tier gratuit (Hobby) est illimité en requêtes, mais limité en build time
- Supabase : le tier gratuit pause après 7 jours d’inactivité : pas grave pour du dev, problématique en prod
Par Type d’Application
Frontend
Frontend : Vercel, Netlify, Cloudflare Pages
- Vercel/Netlify : CI/CD intégré, preview PR, CDN mondial, serverless functions
- Cloudflare Pages : edge computing, WebSocket, DNS + CDN centralisé
- Gratuit pour les projets personnels
Site Astro/Next.js avec déploiement automatique, API légère sans base de données complexe, meilleur SEO possible (HTML pré-généré).
Backend
Backend : Railway, Hetzner, OVH, Infomaniak
- Railway : conteneurs Docker, bases managées, pricing à l’usage
- Hetzner : VPS cloud à coût fixe, datacenter Allemagne
- OVH/Infomaniak : VPS à coût fixe, datacenter France
Backend API Node.js/Python avec bases de données, projet multi-services (API + worker + DB), contrôle total sur l’infrastructure.
BaaS
BaaS : Supabase, Cloudflare Workers/D1
- Supabase : PostgreSQL managé, auth, realtime, stockage de fichiers
- Cloudflare Workers/D1 : edge computing, base SQLite distribuée
- Gratuit avec limites claires
Application avec données temps réel (chat, dashboard), authentification robuste sans la builder, PostgreSQL sans gérer un serveur.
Hébergement Cloud
Vous comprenez les solutions d'hébergement : mais comment choisir entre SSR, SSG et CSR selon votre projet ?
En cours de rédaction
Cet article est en cours de rédaction. Inscrivez-vous à la newsletter pour être averti de sa publication.
Newsletter
Un récap par mois de ce qui a vraiment compté. Pas de spam, promis.
Détail des Services
Vercel & Netlify
Ce que c’est
Vercel et Netlify sont quasi identiques dans leur fonctionnement. Ce sont des plateformes dédiées au frontend statique et aux serverless functions. Tu relies ton dépôt Git, et à chaque push, le site est automatiquement buildé et déployé.
Pourquoi c’est intéressant
- CI/CD intégré : tu push, c’est déployé : pas de FTP, pas de script
- Preview pour chaque PR : chaque branche a son propre URL de preview
- CDN mondial : le site est servi depuis le serveur le plus proche de l’utilisateur
- Serverless functions : des micro-APIs Node.js qui scalent à zéro (pas de coût fixe)
- Gratuit pour les projets personnels et petits projets
- Site Astro statique (blog, doc, vitrine) avec déploiement automatique
- API légère sans base de données complexe
- Meilleur SEO possible (HTML pré-généré, CDN rapide)
Limites
- Le backend est limité : pas de base de données managée
- Serverless functions ont des timeouts (10s sur le gratuit)
- Vendor lock-in : migrer vers un autre hébergeur demande du travail
Un concierge automatique qui accueille vos visiteurs au stand le plus proche d’eux dans le monde. Le contenu est déjà prêt (SSG), il n’y a rien à calculer : juste à servir. Rapide, efficace, mais il ne peut pas cuisiner sur commande (SSR limité).
Bonnes pratiques Vercel/Netlify
✅ Utilise SSG (Static Site Generation) par défaut : plus rapide que le SSR
✅ Configure les headers de cache pour réduire les builds inutiles
✅ Utilise les preview PR pour valider avant de merger
✅ Limite les serverless functions aux endpoints critiques (pas de gros traitement)
Pièges à éviter
❌ Ne pas stocker de données sensibles dans les serverless functions (pas de base de données intégrée)
❌ Ne pas dépasser les 10s de timeout sur le tier gratuit : sinon le build crash
❌ Ne pas oublier le vendor lock-in : migrer vers un autre hébergeur demande du travail
Cloudflare
Ce que c’est
Cloudflare va plus loin que Vercel/Netlify. C’est un écosystème complet :
- Cloudflare Pages : hébergement de sites statiques (comme Vercel)
- Cloudflare Workers : code qui s’exécute sur le réseau edge (300+ villes)
- D1 : base de données SQLite distribuée au edge
- KV : stockage clé-valeur distribué
- R2 : stockage d’objets (comme S3, mais sans frais de sortie)
Pourquoi c’est intéressant
- Edge Computing : le code s’exécute plus près de l’utilisateur que partout ailleurs
- WebSocket natif : Workers supportent les WebSockets (contrairement à Vercel)
- Gratuit très généreux : 100k requêtes/jour pour Workers
- DNS + CDN + Sécurité : tout est centralisé chez Cloudflare
- Application avec besoins temps réel (chat, notifications, dashboard live)
- Tu veux tout centraliser chez un seul provider (DNS + hosting + edge)
- API légère avec base de données simple (D1)
Limites
- Workers ont 128ms de CPU time par requête
- D1 est SQLite, pas PostgreSQL : moins flexible pour des requêtes complexes
- Debugging plus complexe qu’un serveur traditionnel
Un réseau d’ambassadeurs dans chaque ville du monde. Chaque ambassadeur parle la langue locale, connaît les règles, et peut prendre des décisions sans appeler le siège. Rapide, autonome, mais avec des instructions qui tiennent sur un post-it (128ms de CPU).
Bonnes pratiques Cloudflare
✅ Utilise Workers pour les APIs légères (redirections, proxy, auth) : pas pour du gros traitement
✅ Centralise DNS + CDN + Workers chez Cloudflare pour simplifier l’infra
✅ Utilise R2 pour le stockage de fichiers (pas de frais de sortie comme S3)
✅ Limite le budget mensuel dans les settings pour éviter les surprises
Pièges à éviter
❌ Ne pas utiliser D1 pour des requêtes PostgreSQL complexes : c’est SQLite
❌ Ne pas dépasser 128ms de CPU par requête : sinon le Worker timeout
❌ Ne pas stocker de données critiques sans backup : D1 est encore en bêta
❌ Ne pas confondre Pages (sites statiques) et Workers (edge computing)
Railway
Ce que c’est
Railway est une plateforme d’hébergement pour applications conteneurisées (Docker). Tu pushes ton code, Railway build un conteneur et le déploie. C’est compatible avec Node.js, Python, Go, Ruby, PHP (via Docker) : tout ce qui peut être conteneurisé.
Pourquoi c’est intéressant
- Simplicité : tu push, Railway build et déploie automatiquement
- Bases de données incluses : PostgreSQL, MySQL, Redis en quelques clics
- Pricing à l’usage : tu payes uniquement ce que tu consommes (RAM, CPU, réseau)
- Scaling automatique : Railway scale selon la charge
- Backend API Node.js/Python qui a besoin de bases de données
- Microservices avec conteneurs Docker
- Projet qui nécessite plusieurs services (API + worker + base de données)
- Tu veux un “petit AWS” sans la complexité d’AWS
Limites
- Pas de CDN mondial (un seul région)
- Plus cher que le mutualisé pour du PHP pur
- Pricing peut monter vite avec beaucoup de traffic
Un atelier modulaire où vous louez l’espace dont vous avez besoin. Besoin d’une cuisine (API) ? Vous en avez une. Besoin d’un cellier froid (base de données) ? Il est là. Le loyer dépend de ce que vous consommez : flexible, mais il faut surveiller la facture.
Bonnes pratiques Railway
✅ Utilise les bases de données managées (PostgreSQL, Redis) : pas besoin de les installer toi-même
✅ Configure un budget mensuel pour éviter les surprises (max 5$ par défaut en Hobby)
✅ Utilise les variables d’environnement pour séparer config et secrets
✅ Déploie avec Dockerfile pour un contrôle total sur l’environnement
Pièges à éviter
❌ Ne pas oublier le pricing à l’usage : un gros traffic peut coûter cher
❌ Ne pas utiliser Railway pour du frontend statique : Vercel/Netlify sont meilleurs
❌ Ne pas négliger la sécurité : Railway ne gère pas tout (mises à jour OS, firewall)
VPS (Hetzner/OVH/Infomaniak)
Ce que c’est
Un VPS (Virtual Private Server), c’est un serveur virtuel dédié. Tu loues une machine avec des ressources garanties (CPU, RAM, disque) et tu fais tout dessus : installer le système d’exploitation, configurer le serveur web, la base de données, la sécurité. C’est comme un hébergement mutualisé où tu es l’administrateur.
Les providers les plus connus : Hetzner (Allemagne, excellent rapport qualité/prix), OVH (France, large choix), Infomaniak (Suisse, éco-responsable).
Pourquoi c’est intéressant
- Coût fixe et prévisible : tu payes un forfait mensuel (3.80-20€ HT selon la gamme), pas de surprises
- Contrôle total : tu choisis l’OS (Ubuntu, Debian), les versions, la config exacte
- Ressources dédiées : pas de partage avec d’autres sites (contrairement au mutualisé)
- Multi-services : tu peux faire tourner API + base de données + Redis + nginx sur le même serveur
- Rapport qualité/prix : un VPS OVH à 3.80€/mois ou Hetzner à 7.19€/mois offrent bien plus qu’un mutualisé
- Backend API Node.js/Python qui nécessite plus de ressources qu’un mutualisé
- Projet avec plusieurs services (API + worker + base de données)
- Tu veux un contrôle total sur l’infrastructure
- Tu as des compétences sysadmin (ou veux les acquérir)
- Budget serré mais besoin de performance
Limites
- Sysadmin requis : tu gères les mises à jour de sécurité, les backups, la configuration
- Pas de CDN mondial : c’est un seul serveur, pas un réseau global
- Pas de CI/CD intégré : tu dois configurer GitLab CI, GitHub Actions ou Jenkins toi-même
- Pas de scaling automatique : si tu dépasses les ressources, tu changes de plan manuellement
Un terrain vague dans une résidence : vous avez votre espace, vous construisez ce que vous voulez, vous gérez l’électricité et l’eau. Plus de liberté qu’un appartement (mutualisé), mais il faut savoir bricoler. Pas de concierge (cloud managed), pas de gardien (support technique) : vous êtes le chef.
Bonnes pratiques VPS
✅ Utilise Docker pour isoler les services (API, DB, Redis) et simplifier les mises à jour
✅ Configure UFW (firewall) et fail2ban dès le premier jour
✅ Automatise les backups avec un script cron ou un service externe
✅ Utilise Hetzner pour le meilleur rapport qualité/prix en Europe
Pièges à éviter
❌ Ne pas négliger les mises à jour de sécurité : un VPS non maintenu est un risque
❌ Ne pas tout installer sur un seul VPS sans isolation (API + DB + Redis = Docker)
❌ Ne pas oublier les backups : il n’y a pas de restore automatique comme sur le cloud
❌ Ne pas choisir un VPS si tu n’as pas de compétences sysadmin : le cloud est plus simple
VPS vs Mutualisé vs Cloud
| Critère | Mutualisé (o2switch/OVH) | VPS (OVH/Hetzner) | Cloud (Railway) |
|---|---|---|---|
| Contrôle | Faible | Élevé | Variable |
| Complexité | Faible | Moyenne | Faible à moyenne |
| Coût | 7€ HT/mois fixe | 3.80-24.92€ HT/mois fixe | ~4.60€ HT/mois variable |
| Scaling | Manuel | Manuel | Automatique |
| CI/CD | Non | À configurer | Intégré |
| Support | Inclus | À vos risques | Limité |
Supabase
Ce que c’est
Supabase est une alternative open-source à Firebase. C’est une base de données PostgreSQL managée avec des fonctionnalités intégrées : authentification, stockage de fichiers, edge functions, et surtout du realtime (websocket).
Pourquoi c’est intéressant
- PostgreSQL : pas MySQL, plus puissant, plus flexible
- Realtime : les données changent et tous les clients connectés voient la mise à jour instantanément
- Auth intégrée : gestion des utilisateurs, rôles, permissions
- Gratuit jusqu’à 500 Mo de base de données
- Application avec données temps réel (chat, dashboard live, collaboration)
- Tu as besoin d’authentification robuste sans la builder toi-même
- Tu veux PostgreSQL sans gérer un serveur
Limites
- Pas un hébergeur web : tu ne peux pas y déployer un site Astro
- PostgreSQL est différent de MySQL : pas de migration directe
- Le tier gratuit a des limites (500 Mo, 50k requêtes/mois)
Un archiviste intelligent qui non seulement range vos dossiers, mais qui vous prévient instantanément quand quelqu’un en consulte un, et qui vérifie votre identité avant de vous laisser entrer. Idéal pour les équipes qui travaillent en temps réel.
Bonnes pratiques Supabase
✅ Utilise les RLS (Row Level Security) pour sécuriser chaque ligne de ta base
✅ Utilise les Edge Functions pour le traitement côté serveur (auth, webhooks)
✅ Configure les abonnements Realtime uniquement sur les tables nécessaires
✅ Utilise le stockage de fichiers pour les images et documents (pas de S3 externe)
Pièges à éviter
❌ Ne pas confondre Supabase et un hébergeur web : tu ne peux pas y déployer un site Astro
❌ Ne pas négliger les 500 Mo de DB en gratuit : ça passe vite avec des images
❌ Ne pas oublier la pause après 7 jours d’inactivité : problématique en production
❌ Ne pas utiliser PostgreSQL comme MySQL : les fonctionnalités sont différentes
Scénarios Pratiques
| Scénario | Solution recommandée | Pourquoi |
|---|---|---|
| Blog / vitrine | Mutualisé seul | Simple, pas cher, suffisant |
| Blog avec déploiement auto | Astro sur Vercel + mutualisé | Frontend rapide + CI/CD gratuit |
| App avec API Node.js légère | Railway | Conteneurs + bases managées |
| App avec API lourde + budget serré | VPS Hetzner + Docker | Contrôle total, coût fixe, ressources dédiées |
| Chat / live / realtime | Supabase + Cloudflare | PostgreSQL realtime + edge |
| Multi-sites avec CI/CD | Vercel ou Netlify | Pipeline intégré, preview PR |
| Tout centralisé | Cloudflare (Pages + Workers + D1) | DNS + hosting + edge + base |
| Backend multi-services | VPS Hetzner + Docker Compose | API + DB + Redis sur un même serveur |
La Recommandation Bao-Link
L’hébergement mutualisé reste votre hébergeur principal (PHP/Symfony/MySQL) : rien ne change.
Le cloud s’ajoute en complément selon votre besoin :
- Frontend Astro ultra-rapide avec CI/CD → Vercel ou Netlify
- API avec données temps réel → Cloudflare Workers + D1 ou Supabase
- Backend conteneurisé avec bases → Railway
- Backend lourd avec contrôle total → VPS Hetzner/OVH/Infomaniak (3.80-24.92€ HT/mois)
L’important : commencez simple. Le mutualisé suffit pour 80% des projets. Ajoutez le cloud ou un VPS quand le besoin se présente, pas avant.
blogs, vitrines, e-commerce, sites corporate : le mutualisé fait le job
apps temps réel, microservices, CI/CD avancé, scaling automatique
Situation actuelle
- Déploiement manuel via FTP
- Pas de preview avant mise en production
- Pas de scaling automatique
- Pas de CDN mondial
Avec le cloud
- CI/CD intégré (push = déployé)
- Preview pour chaque PR
- Scaling automatique selon la charge
- CDN mondial + edge computing
Valider avant de déployer
0/6Vos progrès sont sauvegardés localement sur votre appareil. Aucune donnée n'est collectée. La durée de conservation dépend de la durée de rétention des données de votre navigateur.
Des zones d'ombre ?
Quelle solution d'hébergement est la moins chère ?
Faut-il obligatoirement un VPS pour un backend Node.js ?
Cloudflare ou Vercel : lequel choisir ?
Peut-on combiner mutualisé et cloud ?
Hébergement Bases
Vous comprenez les solutions cloud : mais connaissez-vous les fondamentaux de l'hébergement web, le nom de domaine et le DNS ?
Découvrez l'article complet
en un clic
Le cloud n’est pas la solution à tous les problèmes : c’est un outil qui s’ajoute à votre hébergement traditionnel. Utilisez-le quand il résout un vrai besoin, pas parce que c’est trendy. Mutualisé + un bon choix cloud, c’est la combinaison gagnante.
Prêt à lancer votre projet ?
Je donne vie à vos idées en créant des sites web et applications intuitifs, esthétiques et fonctionnels.
Articles Connexes
0+4
Serveurs, SSR, SSG, CSR : Qui Fait Quoi ?
Comprenez la différence entre serveur d'application et serveur de base de donnéés, les modes de rendu (SSR, SSG, CSR), et comment Node.js, PHP et MySQL cohabitent sur un même projet.

Quelle Stack pour Quel Projet ?
Comparez Astro + Symfony, Next.js + Symfony, WP + WooCommerce headless, Strapi et Ghost pour choisir la stack adaptée à votre projet web.

Déploiement complet sur o2switch avec Passenger
Procédure pas à pas pour déployer un site Astro SSR + proxy Express sur un hébergement o2switch, avec Passenger, le fichier app.js et le .htaccess.

CI/CD et Déploiement Automatisé : Introduction
Automatisez vos tests et déploiements avec Git, GitHub Actions et des pipelines fiables. De la validation de code à la mise en production, sans intervention manuelle.
Inspiration
Découvrez d'autres projets
Bao-Link Documentation : De WordPress à un Écosystème Centré Utilisateur
Le projet Bao-Link raconte l'évolution du site et de ses outils: la création d'un premier site WordPress vitrine, puis le passage à Astro avec un site 100% sur mesure, sans template, centré sur le SEO et l'expérience utilisateur ainsi que les projets liés : diag-application et personas.
ACM : Refonte E-commerce avec Astro, Express & WordPress
Étude de cas complète : migration d'un site e-commerce WordPress/WooCommerce vers une architecture Astro SSR + proxy Express, avec déploiement et optimisation SEO.
Soair : La Transition Numérique Complète
Étude de cas complète : création d'un site WordPress professionnel puis migration vers Hugo pour des performances optimales et un SEO décuplé.