Il y a trois ans, j'ai mis une vitrine Next.js d'un client chez un fournisseur cloud « bon marché » que je ne nommerai pas, parce qu'il avait déjà payé un an d'avance et je ne voulais pas discuter. Premier événement de vente flash, le site s'est effondré en quatorze minutes. Quatorze. Le client a perdu environ 28 000 £ en commandes selon son estimation. Je n'ai jamais refait cette erreur, et cet après-midi-là est la raison pour laquelle je suis plutôt direct quand on me demande où héberger son frontend en 2026.
Il n'y a évidemment pas une seule bonne réponse. Mais il y a beaucoup de mauvaises réponses, et ce post parle surtout de celles-là.
Je suis Gautam. Je dirige Seahawk Media depuis Londres. Nous avons construit plus de 12 000 sites dans tous les secteurs imaginables. J'ai eu assez de catastrophes directes et de victoires discrètes avec chaque grande plateforme pour avoir un vrai avis, pas juste un tableau de comparaison que j'aurais repiqué à quelqu'un d'autre.Seahawk Media out of London. We've built north of 12,000 sites across every vertical you can imagine. I've had enough firsthand disasters and quiet wins with every major platform to have a real opinion, not just a comparison table I nicked from someone else.
Voici la liste.
Ce que « l'hébergement frontend » signifie vraiment en 2026
Il faut être précis ici, parce que la catégorie a dévié.
En 2020, l'hébergement frontend signifiait : déployer vos fichiers statiques, obtenir un CDN, et c'est fini. Très simple. Maintenant, un « hébergeur frontend » pourrait exécuter vos processus Node SSR, gérer vos fonctions edge, gérer vos environnements de prévisualisation, et synchroniser les variables d'environnement sur 40 branches. Ce n'est pas un CDN. C'est essentiellement une plateforme en tant que service qui parle Git.
Les hébergeurs qui valent la peine d'en parler en 2026 fonctionnent tous dans ce territoire plus large. Si vous pensez toujours « où je mets mes fichiers HTML », vous pouvez arrêter de lire et simplement choisir Cloudflare Pages sur un plan gratuit. Voilà. Mais si vous exécutez Next.js, Nuxt, SvelteKit, Remix, Astro, ou quelque chose avec des composants serveur ou du rendu edge, la décision compte vraiment.Cloudflare Pages on a free plan. Done. But if you're running Next.js, Nuxt, SvelteKit, Remix, Astro, or anything with server components or edge rendering, the decision genuinely matters.
Les trois choses qui séparent le bon du mauvais
- La latence de démarrage à froid sur les fonctions serverless (cela nuira à votre TTFB plus que n'importe quoi d'autre)
- La qualité de la compréhension du système de build de la plateforme pour votre framework (tous ne parlent pas encore couramment le Next.js App Router)
- La falaise tarifaire : où la couche gratuite s'arrête-t-elle et la couche payante a-t-elle du sens pour un client agence à £3 000/mois
Vercel : Toujours le Défaut, Toujours Cher
Je vais être honnête : Vercel est la réponse facile et celle qui m'a aussi causé le plus de disputes de facturation avec les clients en 2024.
Le produit est excellent. Il n'y a pas de vrai débat là-dessus. Leur intégration Next.js est évidemment inégalée parce qu'ils ont construit Next.js. Les fonctions edge démarrent à froid en moins de 50 ms de façon cohérente. Les déploiements de prévisualisation fonctionnent exactement comme annoncé. L'expérience développeur est probablement la meilleure de la catégorie, point barre.Next.js integration is obviously unmatched because they built Next.js. Edge functions cold start in under 50ms consistently. Preview deployments work exactly as advertised. The DX (developer experience) is probably the best in the category, full stop.
Mais voilà le truc : les tarifs au-dessus du tier Hobby sont vraiment pénalisants pour le travail d'agence. Pro coûte $20/mois par membre, ce qui semble correct jusqu'au moment où vous avez une équipe de huit personnes et trois comptes clients distincts. Et les dépassements de bande passante sur les builds pour un client e-commerce à fort trafic vont vous ruiner votre marge si vous ne faites pas attention.
Fin 2023, Seahawk avait un client SaaS qui faisait tourner une appli Remix assez lourde sur Vercel Pro. Sa facture est passée de $180/mois à $610/mois en six mois uniquement à cause du nombre d'invocations de fonctions sur ses routes de dashboard. Personne ne l'a remarqué jusqu'à ce que le comptable du client le signale. Techniquement, Vercel ne fait rien de mal. Mais c'est le genre de chose que vous devez modéliser avant de vous engager.
Pour qui c'est vraiment adapté : les startups financées avec des budgets appropriés, les projets Next.js App Router où vous voulez un support natif du framework, les équipes qui considèrent l'expérience développeur comme un véritable investissement commercial. Funded startups with proper budgets, Next.js App Router projects where you want framework-native support, teams that treat DX as a genuine business investment.
Pour qui il faudrait probablement regarder ailleurs : les freelancers sensibles aux coûts, les agences qui gèrent beaucoup de petits et moyens sites clients, quiconque utilise SvelteKit ou Astro sans avoir besoin des fonctionnalités spécifiques à Vercel. Cost-sensitive freelancers, agencies managing lots of small-to-mid client sites, anyone on SvelteKit or Astro who doesn't need the Vercel-specific features.
Netlify : Celui Qui A Perdu Un Peu La Boussole
Je dis ça avec une certaine affection parce que Netlify a fondamentalement inventé cette catégorie. Ils faisaient des déploiements atomiques et des aperçus de déploiement avant que quiconque ne le prenne vraiment au sérieux.
Le problème c'est que Netlify en 2026 ressemble à un produit où chaque décision après 2022 a été prise par un comité. Des fonctionnalités ont été ajoutées, l'interface est devenue plus chargée, les tiers tarifaires se sont compliqués, et le produit core est devenu plus lent. Leurs temps de build ont régressé. J'ai fait des comparaisons informelles sur la même appli Next.js 14 fin 2024 : Netlify faisait des builds en moyenne de 4m 20s contre 2m 45s chez Vercel. Pas catastrophique. Mais notable.
Où Netlify brille toujours : les formulaires (leur gestion des formulaires intégrée est vraiment pratique pour les sites marketing), leurs intégrations CMS, et le fait que leur tier gratuit est plus généreux que celui de Vercel pour les sites purement statiques. Si vous lancez un site Gatsby ou Eleventy pour un client commercial local, Netlify gratuit c'est tout à fait solide.
Une chose que j'aime bien : leurs Edge Functions sont sous-estimées. Basées sur Deno, avec de faibles cold starts, et la simulation du développement local avec netlify dev est en réalité meilleure que celle de Vercel pour certains workflows. Je l'ai beaucoup utilisée sur un projet Shopify headless pour une marque de mode à Birmingham. Ça a marché proprement.Edge Functions are underrated. Deno-based, low cold starts, and the local dev simulation with netlify dev is actually better than Vercel's for certain workflows. I used it heavily on a headless Shopify project for a fashion brand in Birmingham. Worked cleanly.
Pour qui c'est adapté : les sites marketing, les agences qui se sont verrouillées tôt et ont des workflows existants, quiconque s'appuie sur les fonctionnalités CMS ou formulaires de Netlify. Marketing sites, agencies who got locked in early and have existing workflows, anyone leaning on Netlify's CMS or form features.
Devraient chercher ailleurs : Toute personne qui privilégie la vitesse de build, les équipes exécutant des applications SSR-intensives, quiconque trouve la structure tarifaire actuelle difficile à justifier (c'est le cas). Anyone prioritising build speed, teams running SSR-heavy apps, anyone who finds the current pricing structure hard to reason about (it is).
Cloudflare Pages : L'Outsider Qui Est Discrètement Très Bon
Pour être complètement honnête, Cloudflare Pages est devenu ma recommandation par défaut pour un nombre surprenant de projets ces 18 derniers mois.
L'offre gratuite est ridiculement bonne. Sites illimités, requêtes illimitées, bande passante illimitée. Oui, il y a des limites (500 builds par mois sur l'offre gratuite, par exemple), mais pour le type de sites qui ont besoin d'une offre gratuite, ces limites conviennent.
L'intégration Workers, c'est là que ça devient intéressant. Le réseau edge de Cloudflare est le plus grand au monde en nombre de PoP, ce n'est pas du battage marketing, ça affecte réellement la latence pour les audiences distribuées mondialement. Si vous avez un client avec 40% de son trafic provenant d'Asie du Sud-Est, Cloudflare Pages le servira plus rapidement que Vercel d'une manière significative.the largest in the world by PoP count, which is not marketing fluff, it genuinely affects latency for globally distributed audiences. If you've got a client with 40% of their traffic coming from Southeast Asia, Cloudflare Pages will serve them faster than Vercel by a meaningful margin.
Le compromis : la prise en charge des frameworks rattrape encore son retard. Next.js App Router, spécifiquement React Server Components, a eu une histoire mouvementée sur Pages. C'est mieux qu'il y a un an, mais il y a des cas limites, particulièrement autour du streaming et de certains comportements de cache, qui vous causeront des problèmes si vous n'êtes pas prudent. Je ne déploierais pas une application Next.js 15 complexe avec une utilisation RSC importante sur Pages sans test approfondi d'abord. Astro, SvelteKit et les sites purement statiques cependant ? Complètement bon.
Pour qui c'est adapté : Les agences soucieuses des coûts, les audiences mondiales, les projets Astro/SvelteKit/Qwik, quiconque est déjà dans l'écosystème Cloudflare. Cost-conscious agencies, global audiences, Astro/SvelteKit/Qwik projects, anyone already in the Cloudflare ecosystem.
Devraient chercher ailleurs : Les équipes ayant des configurations Next.js RSC complexes, quiconque a besoin de SLA d'entreprise dès le départ. Teams with complex Next.js RSC setups, anyone who needs enterprise SLAs out of the box.
Render : Le Juste Milieu Sensé Dont Personne Ne Parle Assez
Render n'obtient pas la couverture qu'il mérite, probablement parce qu'il n'a pas de budget marketing de capital-risque.
Ce que Render réussit bien : il pense comme une plateforme full-stack tout en restant véritablement utilisable pour du travail frontend uniquement. Vous pouvez exécuter votre app Next.js en tant que service Node, configurer une base de données Postgres, ajouter un worker en arrière-plan et tout gérer depuis un seul tableau de bord avec une tarification sensée. C'est un modèle mental différent de Vercel ou Netlify, mais pour certains types de projets c'est exactement ce qu'il faut.
L'offre gratuite pour les sites statiques est compétitive. Les plans payants commencent à 7 $/mois par service, ce qui est bien plus facile à expliquer à un petit client entreprise que le modèle par siège de Vercel.
J'ai utilisé Render correctement pour la première fois sur un projet de tableau de bord fintech au début de 2024. Frontend Next.js, backend FastAPI, Redis pour les sessions. Avoir tout au même endroit avec gestion des variables d'environnement partagée était véritablement agréable. Pas de compte Railway séparé pour le backend, pas de stitching de facturation provenant de trois fournisseurs.
Les démarrages à froid sur l'offre gratuite de Render sont la plainte principale que vous entendrez, et elle est justifiée. Le démarrage à partir de l'inactivité peut prendre 30 à 60 secondes. Sur un plan payant c'est acceptable. Donc ne l'utilisez simplement pas pour du contenu orienté utilisateur.
Pour qui c'est adapté : Projets full-stack, équipes voulant une plateforme unifiée pour le frontend et le backend, développeurs solo gérant les coûts attentivement. Full-stack projects, teams wanting a unified platform across frontend and backend, solo developers managing costs carefully.
Qui devrait chercher ailleurs : Sites purement statiques (Cloudflare est mieux et gratuit), quiconque a besoin de la meilleure DX la plus soignée disponible (Vercel est mieux). Pure static sites (Cloudflare is better and free), anyone who needs the most polished DX available (Vercel is better).
Fly.io : Quand Vous Avez Vraiment Besoin de Contrôle
Fly.io n'est pas un hébergeur frontend typique. Mais je l'inclus ici parce qu'il y a une catégorie de projet, généralement tout ce qui implique des connexions persistantes, des WebSockets ou un état serveur lourd, où Fly.io est simplement la bonne réponse et aucun des autres ne l'est.
Fly exécute des conteneurs. De vrais conteneurs, près du métal, dans plus de 35 régions. Ce n'est pas un pipeline de déploiement CDN géré. Vous écrivez un Dockerfile et Fly l'exécute. Cela signifie que vous pouvez exécuter une app Remix avec SQLite (en utilisant LiteFS), ou une app SvelteKit avec un serveur de socket persistant, de manières qui ne sont tout simplement pas possibles sur le modèle de fonction edge.
La courbe d'apprentissage est plus raide. La CLI demande de s'y habituer. Et leur documentation, bien qu'en amélioration, peut donner l'impression qu'elle suppose que vous savez déjà ce que vous faites. Mais si vous savez ce que vous faites, Fly est remarquablement puissant.
C'est fait pour : les apps lourdes en WebSocket, tout ce qui nécessite un état serveur persistant, les développeurs à l'aise avec les conteneurs qui veulent une distribution mondiale sans les contraintes des plateformes gérées. WebSocket-heavy apps, anything needing persistent server state, developers comfortable with containers who want global distribution without the managed-platform constraints.
Cherchez ailleurs : les débutants, ceux qui veulent des déploiements point-and-click, les sites purement statiques. Beginners, anyone wanting point-and-click deploys, pure static sites.
Comment vraiment choisir (un processus décisionnel simple)
- C'est un site purement statique (pas de SSR, pas de edge functions, juste HTML/CSS/JS) ? Utilisez Cloudflare Pages, offre gratuite, c'est réglé.
- C'est du Next.js avec App Router et RSC comme fonctionnalité centrale ? Utilisez Vercel. Payez, ça vaut le coup pour cette stack spécifique.
- C'est du SvelteKit, Astro, Nuxt, ou Remix avec un petit budget ? Essayez d'abord Cloudflare Pages. Si vous heurtez des cas limites du framework, passez à Render.
- Votre projet inclut des services backend et vous voulez un seul tableau de bord ? Utilisez Render.
- Vous avez des connexions persistantes, des WebSockets, ou vous avez besoin d'un vrai contrôle des conteneurs ? Utilisez Fly.io.
- Vous êtes freelance et gérez 20+ petits sites clients et le coût est la variable principale ? Cloudflare Pages pour les statics, Render pour tout ce qui a un composant serveur, Vercel uniquement quand le client en a besoin précisément.
Le contrôle réaliste des tarifs
Personne n'en parle honnêtement. Voici ce que je dépense réellement en ce moment sur les projets actifs de Seahawk :
- Vercel Pro : réservé à deux clients avec des builds Next.js App Router où le support du framework n'est pas négociable. Nous répercutons le coût directement.
- Cloudflare Pages : onze sites en gratuit, trois sur le plan Pro à 20 $/mois pour des raisons de limite de build.
- Render : quatre projets, tous sur le niveau de service individuel à 7 $/mois. Total : environ 28 $/mois pour ces quatre.
- Fly.io : deux projets avec des requirements WebSocket, approximativement 18 $/mois combinés.
Total des dépenses d'hébergement pour le portefeuille géré par l'agence : moins de 120 $/mois pour plus de 20 sites actifs. Les factures Vercel sont payées directement par les clients.
Si vous payez significativement plus que ça pour un nombre comparable de projets, je vous recommande vraiment d'auditer votre setup.
FAQ
Est-ce que Vercel vaut le prix en 2026 ?
Pour les projets Next.js App Router spécifiquement, oui, probablement. Les performances au démarrage froid, les temps de build et les features natives du framework justifient le coût si Next.js est une partie centrale de votre stack. Pour n'importe quoi d'autre, vous payez une prime qui ne se traduit pas en améliorations visibles pour l'utilisateur.
Cloudflare Pages peut-elle gérer un site à fort trafic ?
Oui, sans problème. Le réseau de Cloudflare gère des milliards de requêtes par jour. La promesse de « bande passante illimitée » de l'offre gratuite est réelle pour les ressources statiques. La seule contrainte sérieuse est les 500 builds/mois en gratuit et les avertissements de compatibilité des frameworks que j'ai mentionnés pour les configurations Next.js complexes.
Qu'en est-il d'AWS Amplify ou Firebase Hosting ?
Je ne les ai pas inclus parce que, franchement, ni l'un ni l'autre n'est une recommandation solide pour le travail frontend moderne en 2026. L'expérience développeur d'Amplify a toujours été en retrait par rapport aux plateformes dédiées, et Firebase Hosting convient mieux aux projets déjà profondément ancrés dans l'écosystème Firebase. Si vous y êtes déjà, utilisez-le. Sinon, commencez par l'une des cinq que j'ai listées.
Netlify est-elle en déclin ?
Non, mais elle ne croît pas comme elle le devrait. Le produit fonctionne toujours. L'entreprise a levé un tour significatif et continue de livrer des fonctionnalités. Mais elle a perdu le statut « clairement la meilleure » qu'elle avait en 2019-2021, et pour la plupart des nouveaux projets, je choisirais quelque chose d'autre en premier.
Quelle est la meilleure option pour un freelance qui démarre ?
Cloudflare Pages pour les sites statiques, Render pour tout ce qui a de la logique serveur. Les deux ont des offres gratuites véritablement utilisables, pas juste de l'appât d'essai. Commencez là, passez à Vercel seulement quand un projet spécifique l'exige.
---
La conversation sur l'hébergement, je l'ai au moins deux fois par semaine avec des clients, des pairs d'agence, et des développeurs dans notre Discord communautaire. Personne ne fait parfaitement juste à chaque fois (moi certainement pas). Mais si vous utilisez le processus de décision ci-dessus au lieu de vous en tenir à ce que vous avez utilisé l'année dernière, vous gaspillerez beaucoup moins d'argent et vous aurez beaucoup moins de conversations comme celle que j'ai eue avec ce client après quatorze minutes d'arrêt.
Choisissez le bon outil. Puis construisez quelque chose qui mérite d'être hébergé.