Alternatives à Netlify qui ne vous réservent pas de surprise sur la facture

Pourquoi on cherche des alternatives à Netlify

Netlify mérite le respect. Ce sont eux qui ont essentiellement inventé le workflow de déploiement JAMstack moderne : on connecte un repo Git, on configure une commande de build, on push sur main, et le site est live avec HTTPS, CDN et deploy previews. Avant Netlify, déployer un site statique voulait dire du FTP ou se battre avec des policies de buckets S3. Ils ont rendu ça simple.

Et pour beaucoup de projets, Netlify fait encore très bien le job. Un blog perso, un site de doc, une petite landing page — le tier gratuit gère ça sans problème. Les ennuis commencent quand votre projet arrête d'être petit.

Les dépassements de bande passante, c'est le gros morceau. Le tier gratuit de Netlify inclut 100 Go de bande passante par mois. Ca semble large jusqu'à ce qu'on fasse le calcul. Un site marketing avec une hero video, quelques photos produit en haute résolution et un PDF à télécharger peut peser 5-10 Mo par chargement de page. A 10 000 visiteurs par mois — du trafic modeste pour un site produit — on est déjà à 50-100 Go. Un seul article qui buzze, un lancement Product Hunt, une mention Hacker News, et on explose les 100 Go en une journée. Le dépassement coûte 55 $ par 100 Go supplémentaires. C'est pas une coquille. Votre hébergement gratuit peut devenir une surprise à 55 $ du jour au lendemain.

Les minutes de build fondent vite. Le tier gratuit donne 300 minutes de build par mois. Un site Next.js ou Astro avec un build lourd en contenu peut prendre 3-5 minutes par deploy. Si on déploie deux fois par jour, on est à 180-300 minutes dans le mois. Ajoutez les deploy previews pour les pull requests et vous dépassez la limite avant la fin du mois. Le dépassement coûte 7 $ par tranche de 500 minutes supplémentaires.

La tarification par membre sur Pro. Le plan Pro à 19 $/mois par membre monte la bande passante à 1 To et les minutes de build à 25 000. Mais ce "par membre" compte. Un fondateur solo paie 19 $. Un co-fondateur rejoint l'aventure, et d'un coup c'est 38 $. Ajoutez un freelance pour un mois et on passe à 57 $. Pour un fondateur bootstrapé qui surveille son burn rate, la tarification par siège sur l'hébergement, ça fait bizarre — les coûts serveur ne devraient pas scaler avec la taille de l'équipe.

Le vendor lock-in est bien réel. Netlify Forms, Netlify Identity, Netlify Edge Functions, Netlify Blobs — ce sont des fonctionnalités pratiques qui ne marchent que sur Netlify. Chaque fonctionnalité adoptée rend la migration plus difficile. Ce n'est pas propre à Netlify (Vercel fait pareil), mais ça vaut le coup d'en prendre conscience tôt.

Rien de tout ça ne rend Netlify mauvais. Ca rend Netlify cher et collant d'une manière qui n'est pas évidente quand on s'inscrit.

Comment on a évalué ces alternatives

Chaque plateforme a été testée sur ce qui compte pour les builders solos et les petites équipes qui déploient des sites et des apps web :

• Workflow de déploiement : A quel point c'est proche du "git push et c'est fait" de Netlify ?
• Prévisibilité des coûts : On peut estimer sa facture avant qu'elle arrive, ou c'est du doigt mouillé ?
• Economie de bande passante : Que se passe-t-il quand le trafic fait x10 ? On reçoit une facture ou un haussement d'épaules ?
• Support de frameworks : Ca gère Astro, Next.js, SvelteKit, Remix, Hugo et du HTML brut ?
• Parité fonctionnelle : Deploy previews, domaines custom, HTTPS, fonctions serverless, formulaires ?

On n'a pas testé les fonctionnalités enterprise. Les audit logs, le SSO et la gestion d'équipe comptent pour les grosses structures mais sont hors sujet quand on déploie le site marketing de son SaaS.

Analyse détaillée : ce que chaque alternative fait de mieux

Vercel — le roi de la DX avec les mêmes pièges tarifaires

Si on quitte Netlify à cause du prix, Vercel ne va probablement pas résoudre le problème. Le tier gratuit, c'est 100 Go de bande passante — comme Netlify. Le plan Pro, c'est 20 $/mois par membre d'équipe — 1 $ de plus que Netlify, même modèle par siège. Dépassements de bande passante, limites d'invocations de fonctions et frais d'optimisation d'images s'appliquent aussi.

Alors pourquoi regarder Vercel ? Parce que la DX est objectivement meilleure, surtout pour Next.js. Vercel développe Next.js. Des fonctionnalités comme l'Incremental Static Regeneration (ISR), les React Server Components, le middleware et l'optimisation d'images fonctionnent parfaitement sur Vercel parce qu'ils sont conçus ensemble. Sur Netlify, ces fonctionnalités passent par des adaptateurs qui accusent parfois un retard sur la dernière version de Next.js.

Les deploy previews sont plus rapides et mieux finies. Le dashboard est plus propre. Le pipeline de build est plus fiable. Vercel propose aussi des edge functions qui tournent mondialement avec des cold starts minimaux, et leur produit d'analytics est étroitement intégré.

Là où Vercel est en retrait par rapport à Netlify, c'est la neutralité framework. Netlify traite chaque framework en citoyen de première classe. Vercel optimise pour Next.js d'abord et tout le reste ensuite. Si on construit avec Astro, Hugo ou SvelteKit, Netlify offre souvent une expérience plus fluide.

La vraie raison de passer de Netlify à Vercel, c'est la compatibilité framework, pas les économies. Si on build avec Next.js et qu'on bute sur les limitations des adaptateurs Netlify, Vercel supprime cette friction. Si on cherche à dépenser moins, continuez la lecture.

Quand choisir Vercel : On développe avec Next.js, on veut une intégration framework parfaite, et on accepte le modèle tarifaire de Vercel pour le gain en DX.

Cloudflare Pages — celui qui règle le problème de facturation

C'est l'alternative qui change l'équation économique. Le tier gratuit de Cloudflare Pages inclut une bande passante illimitée. Pas 100 Go. Pas 1 To. Illimitée. Pas de frais de dépassement. Votre site se retrouve en une de Hacker News et sert un million de pages vues ? La facture reste à 0 $.

Pour un fondateur bootstrapé, la bande passante illimitée n'est pas qu'une économie — c'est la tranquillité d'esprit. On n'a plus jamais besoin de se demander si une campagne marketing ou un moment viral va produire une facture d'hébergement inattendue. Cette charge mentale en moins vaut plus que le montant en dollars.

Côté performance, le discours est tout aussi convaincant. Netlify sert les sites depuis son CDN, qui est solide. Cloudflare sert depuis plus de 300 points de présence dans le monde, adossé à l'un des plus gros réseaux internet de la planète. Le Time to First Byte (TTFB) est régulièrement sous les 50 ms à l'échelle mondiale. Pour les landing pages sensibles au taux de conversion, cette différence de vitesse compte.

Cloudflare Pages ne se limite plus aux sites statiques. L'intégration Workers permet d'exécuter du code côté serveur en edge — SSR, routes API, middleware, logique d'authentification. Les adaptateurs de frameworks pour Next.js, Astro, SvelteKit, Nuxt et Remix sont matures. L'écosystème Cloudflare au sens large apporte R2 pour le stockage objet (sans frais d'egress — un contraste frappant avec AWS S3), D1 pour du SQLite en edge, KV pour le stockage clé-valeur, et Queues pour le traitement asynchrone.

Les compromis méritent d'être compris. Le runtime Workers est basé sur V8, pas Node.js. La plupart du code JavaScript et TypeScript fonctionne bien, mais les packages npm qui dépendent d'API spécifiques à Node.js (fs, path, net, child_process) ne tourneront pas. Ca s'améliore — Cloudflare ajoute progressivement la compatibilité Node.js — mais vérifiez vos dépendances avant de vous engager.

Le système de build est plus simple que celui de Netlify. Netlify a un écosystème riche de plugins et de nombreuses options de configuration de build. Cloudflare Pages vous donne une commande de build et un répertoire de sortie. Pour la plupart des projets c'est suffisant, mais si vous comptez sur les build plugins Netlify, il faudra les remplacer par des scripts de build ou des GitHub Actions.

Quand choisir Cloudflare Pages : La bande passante ou la performance mondiale est la priorité. Particulièrement adapté aux sites marketing, blogs, docs et apps JAMstack.

Railway — quand le site a aussi besoin d'un backend

Netlify est une plateforme d'hébergement frontend. Ca gère les fichiers statiques et les fonctions serverless, mais ça ne fait pas tourner de base de données, de worker en arrière-plan ou de serveur API persistant. Si votre produit a un site marketing sur Netlify ET un backend sur Heroku ou Render ET une base sur Supabase, vous gérez trois plateformes, trois factures et trois dashboards.

Railway consolide tout ça. Frontend, backend, base de données, cache Redis, workers en arrière-plan, cron jobs — tout dans un seul projet, connecté via un réseau interne. On déploie tout avec un git push. On voit tous les services dans un seul dashboard. On reçoit une seule facture.

Le modèle tarifaire est à l'usage et transparent. Le plan Hobby coûte 5 $/mois et inclut 5 $ de crédit d'usage. On paie le CPU, la mémoire et le réseau réellement consommés. Un site marketing plus une petite API plus Postgres coûte typiquement 8-15 $/mois au total. Comparez ça à Netlify Pro (19 $/mois) plus un service de base de données (7-25 $/mois) plus un hébergement backend (7-20 $/mois).

Le provisioning de bases de données en un clic, c'est un vrai gain de productivité. On clique sur un bouton, on obtient une instance Postgres avec une connection string injectée dans les variables d'environnement. Pareil pour MySQL, Redis et MongoDB. Pas de service externe à configurer, pas d'identifiants à copier entre dashboards.

Là où Railway est en retrait par rapport à Netlify, c'est le polish côté frontend. Pas de CDN intégré pour le cache des assets statiques. Pas de deploy previews natives par pull request (même si on peut les configurer). Pas d'edge functions ni de réseau edge mondial. Pour un site marketing purement statique, Railway n'est pas le bon outil. Mais combinez un frontend Cloudflare Pages avec un backend Railway et vous avez un setup full-stack puissant et économique.

Quand choisir Railway : On construit un produit full-stack et on veut frontend et infrastructure backend sur une seule plateforme à des prix prévisibles.

Render — la plateforme tout-en-un avec un vrai tier gratuit

Render occupe un territoire similaire à Railway mais avec une philosophie de tarification différente. L'hébergement de sites statiques est vraiment gratuit — 100 Go de bande passante, HTTPS automatique, domaines custom et déploiement continu depuis Git. Pas de limite de temps, pas de mise en pause des projets, pas de piège.

Pour quelqu'un qui est sur le tier gratuit de Netlify juste pour de l'hébergement statique, le tier gratuit de Render est fonctionnellement équivalent. Le pipeline de build marche de la même façon : on connecte un repo, on définit une commande de build, on push pour déployer. Les deploy previews sont moins intégrées que celles de Netlify mais fonctionnelles.

Là où Render devient intéressant, c'est la plateforme complète. Les services web démarrent à 7 $/mois. Le Postgres managé démarre à 7 $/mois. Cron jobs, workers en arrière-plan et réseau privé entre services sont disponibles. Comme Railway, Render permet de consolider frontend et backend sur une seule plateforme.

Le problème du cold start sur les services web gratuits est toujours le même. Les instances gratuites se mettent en veille après 15 minutes d'inactivité. La première requête après la veille prend 30-60 secondes. Pour une démo ou un environnement de staging, c'est acceptable. Pour tout ce qui est face aux utilisateurs, il faut le tier payant.

La vitesse de build, c'est le point faible de Render. Les builds sont régulièrement plus lents que sur Netlify, Vercel ou Railway. Un projet qui build en 45 secondes sur Netlify peut prendre 3-4 minutes sur Render. Si on déploie souvent, ces minutes d'attente en plus se cumulent en temps développeur perdu.

Quand choisir Render : On veut un hébergement statique gratuit plus la possibilité d'ajouter des services backend et des bases de données sur la même plateforme sans changer de fournisseur.

Coolify — auto-hébergez et arrêtez de payer par site

Quand on fait tourner plus que quelques sites, la tarification par site ou par siège des plateformes managées commence à devenir absurde. Trois sites marketing, un site de doc et une app SaaS sur Netlify Pro ? C'est 19 $/mois minimum, et la bande passante de tous les projets compte sur le même pool.

Coolify change complètement l'équation. Installez-le sur un VPS Hetzner — un CAX11 à environ 4 $/mois ou un CPX21 à 10 $/mois — et vous pouvez héberger dix, vingt, cinquante sites. Pas de tarification par site. Pas de frais de dépassement de bande passante. Pas de limites de minutes de build. Le seul coût, c'est le VPS.

L'expérience de déploiement est plus proche de Netlify qu'on ne le penserait. On connecte ses repos GitHub. Coolify détecte le framework, build avec Nixpacks ou Docker, provisionne le SSL via Let's Encrypt et configure le reverse proxy. Les deploy previews pour les pull requests sont supportées. Les rollbacks marchent. Le dashboard web donne accès aux logs, métriques et configuration de tous les sites en un seul endroit.

On peut aussi faire tourner des bases de données (Postgres, MySQL, Redis, MongoDB), des outils de monitoring (Plausible, Umami) et n'importe quel conteneur Docker à côté des sites. Un serveur, une facture, tout ce qu'il faut.

Les compromis sont les compromis de l'auto-hébergement. On est l'équipe ops. Les mises à jour serveur, le monitoring de l'espace disque, la stratégie de sauvegarde et le monitoring d'uptime sont notre responsabilité. Il n'y a pas de CDN mondial intégré — mettez Cloudflare (tier gratuit) devant votre serveur Coolify pour le cache et la protection DDoS. Si le serveur tombe à 3 h du matin, personne ne vous prévient sauf votre propre monitoring.

Pour un fondateur technique, le calcul est clair. Un VPS Hetzner à 10 $/mois avec Coolify et Cloudflare en façade gère une charge de travail qui coûterait 100-200 $/mois entre Netlify, un fournisseur de base de données et un hébergement backend. Sur un an, c'est plus de 1 000 $ d'économies — de l'argent réel pour un projet pré-revenu.

Quand choisir Coolify : On est technique, à l'aise avec Linux, et on veut éliminer les coûts d'hébergement comme variable du burn rate.

GitHub Pages — gratuit, simple, limité

GitHub Pages n'essaie pas de concurrencer Netlify sur les fonctionnalités. C'est de l'hébergement statique gratuit depuis un repo GitHub. On push du HTML, du Markdown ou un site Jekyll sur la branche gh-pages (ou on configure une source custom), et le site est live à username.github.io ou sur un domaine custom.

Pour les sites de documentation, les blogs persos, les pages de projets open source et les landing pages simples, GitHub Pages est l'option zéro coût, zéro prise de tête. Pas de pipeline de build à configurer (sauf si on veut via GitHub Actions), pas de dashboard à gérer, pas de compte à créer au-delà du compte GitHub qu'on a déjà.

La limite de bande passante est de 100 Go par mois — comme le tier gratuit de Netlify. Le stockage est limité à 1 Go par repo. Pas de fonctions serverless, pas de formulaires, pas d'edge functions, pas d'analytics, pas de deploy previews. Ce sont des fichiers statiques servis depuis un CDN, rien de plus.

GitHub Actions comble certains manques. On peut configurer un workflow pour builder n'importe quel générateur de sites statiques (Astro, Hugo, Eleventy, export statique Next.js) et déployer sur GitHub Pages. On peut même mettre en place des déploiements de preview pour les PR avec des actions tierces. Mais ça demande plus de configuration que le setup one-click de Netlify.

Quand choisir GitHub Pages : On a besoin d'hébergement statique gratuit pour de la doc, un site perso ou une page projet, sans besoin de fonctions serverless ni de fonctionnalités de déploiement avancées.

Comparaison des coûts : site marketing + app SaaS

Voici ce que la stack typique d'un indie founder coûte réellement — un site marketing/blog (statique, trafic modéré à environ 50 000 visites/mois) plus une application SaaS (Next.js avec routes API) :

• Netlify : Le tier gratuit couvre le site statique (de justesse — 100 Go de bande passante c'est serré à 50K visites). L'app SaaS sur Pro pour les fonctions serverless : 19 $/mois. Risque de dépassement de bande passante : 55 $ par 100 Go. Mensuel réaliste : 19-74 $/mois
• Vercel : Même histoire. Site marketing en gratuit. App sur Pro : 20 $/mois. Dépassements de bande passante et fonctions possibles. Mensuel réaliste : 20-70 $/mois
• Cloudflare Pages : Les deux sites en gratuit. Bande passante illimitée. Ajoutez Workers Paid (5 $/mois) si vous avez besoin de plus de 100K requêtes de fonctions/jour. Mensuel réaliste : 0-5 $/mois
• Railway : Les deux sites comme services. A l'usage. Mensuel réaliste : 8-15 $/mois
• Render : Site statique gratuit. App sur plan à 7 $/mois. Mensuel réaliste : 7-14 $/mois
• Coolify sur Hetzner : Les deux sites plus CDN Cloudflare. Mensuel réaliste : 5-10 $/mois (fixe)
• GitHub Pages + hébergement app séparé : Site marketing gratuit. App sur une autre plateforme. Mensuel réaliste : 0 $ + coût de l'hébergement app

L'écart est significatif. La même charge de travail coûte 0-5 $/mois sur Cloudflare Pages et 19-74 $/mois sur Netlify. Sur un an, c'est une différence de 228-828 $. Pour un fondateur qui essaie d'atteindre la ramen profitability, les économies d'infrastructure à ce niveau-là comptent.

Quand rester sur Netlify

Netlify reste le bon choix si :

• On dépend fortement de fonctionnalités spécifiques Netlify comme les formulaires, Identity ou le Split Testing qui demanderaient de construire ou acheter des remplacements ailleurs
• Le projet tient confortablement dans le tier gratuit et les pics de trafic ne nous inquiètent pas
• On valorise l'écosystème de build plugins Netlify pour des tâches comme l'optimisation d'images, la génération de sitemap ou l'invalidation de cache
• L'équipe utilise les workflows de déploiement par branche de Netlify pour le staging et les environnements de preview, et les fonctionnalités de collaboration justifient le coût par siège
• L'effort de migration dépasse les économies — si le projet est profondément intégré aux fonctionnalités Netlify, le temps d'ingénierie pour migrer peut coûter plus qu'un an d'hébergement

Le workflow de déploiement de Netlify reste excellent. La plateforme est mature, stable et bien documentée. Si la facture est à 19 $/mois et que le projet génère du revenu, le confort des fonctionnalités intégrées de Netlify peut valoir plus que les économies d'un changement de plateforme.

Conseils pratiques pour la migration

Quitter Netlify est généralement moins douloureux qu'on ne le croit, à quelques exceptions près :

1. Inventoriez vos fonctionnalités Netlify. Avant de migrer, listez tout ce que vous utilisez : build plugins, formulaires, identity, edge functions, redirects, headers, split testing. Chaque élément a besoin d'un remplacement sur la nouvelle plateforme ou d'un service tiers.

2. Les redirects et headers se portent facilement. Les fichiers _redirects et _headers de Netlify ont des équivalents sur la plupart des plateformes. Cloudflare Pages utilise _redirects nativement. Vercel utilise vercel.json. Pour les autres, la configuration de votre framework gère ça.

3. Remplacez Netlify Forms en premier. C'est le point de friction le plus courant en migration. Formspree, Getform ou un simple endpoint API remplace Netlify Forms avec un minimum de changements de code — en général il suffit de retirer l'attribut netlify du formulaire et d'ajouter une URL d'action.

4. Testez le build sur la nouvelle plateforme. Les commandes de build et les variables d'environnement se transfèrent généralement directement, mais les images de build diffèrent entre les plateformes. La version de Node.js, le package manager et les dépendances système peuvent nécessiter des ajustements. Faites un deploy de test avant de toucher au DNS.

5. Basculez via le DNS. Pointez votre domaine vers la nouvelle plateforme via DNS. Gardez Netlify actif en parallèle pendant 48-72 heures au cas où il faudrait faire un rollback. Réglez le TTL DNS à 300 secondes avant le basculement pour un failover rapide.

6. Surveillez la bande passante après migration. Si vous migrez vers Cloudflare Pages, la bande passante n'est plus un souci. Si vous migrez vers n'importe quelle autre plateforme, configurez du monitoring et des alertes de bande passante. La dernière chose qu'on veut, c'est migrer d'une facture de dépassement pour en retrouver une autre.