Fin 2023, j'ai migré la vitrine e-commerce d'un client depuis Vercel après qu'une facture d'un mois arrive à 340 $. SaaS à trafic moyen. Rien d'extraordinaire. Le fondateur m'a appelé vendredi après-midi ayant l'air véritablement alarmé, et honnêtement, je n'avais pas de bonne défense. Je m'étais par défaut orienté vers Vercel parce que c'était ce que je connaissais, ce qui semblait rapide à mettre en place, et ce que la doc Next.js supposait essentiellement que vous utiliseriez. Cette migration vers Cloudflare Pages m'a pris un après-midi et a réduit le coût mensuel à environ 22 $. J'y accorde beaucoup plus d'attention depuis.
Voici donc où j'en suis réellement en 2026 après avoir utilisé les deux plateformes sur du travail client chez Seahawk : Cloudflare Pages a énormément mûri, Vercel n'a pas non plus resté immobile, et la réponse à « laquelle dois-je utiliser » porte moins sur la loyauté envers une marque et plus sur ce que vous construisez réellement.
La Réalité du Pricing (Et Où Vercel Fait Encore Mal)
Le tier gratuit de Vercel est véritablement bon pour les projets personnels. Plan Hobby, déploiements illimités, URLs de preview, des minutes de build décentes. Dès que vous passez à Pro (20 $/mois par siège), vous êtes correct en tant que développeur solo. Mais les agences ? Le modèle par siège accumule les frais rapidement. Six développeurs dans une équipe, c'est 120 $/mois avant d'avoir servi une seule requête. Ensuite vous ajoutez la bande passante, les invocations Edge Function et l'Image Optimisation, et la facture commence à ressembler à un contrat de téléphone mobile de 2009 où vous ne compreniez jamais vraiment ce que vous payiez.
Cloudflare Pages repose sur un modèle économique fondamentalement différent. Le tier gratuit inclut des sites illimités, des requêtes illimitées, et 500 builds par mois. Le plan Pro est 20 $/mois fixe, pas par siège. Pour Seahawk, cette distinction est significative parce que nous gérons les builds de plusieurs clients depuis un seul compte. J'ai fait les calculs pour un mois typique début 2025 : 14 projets actifs, environ 2,1 millions de requêtes edge combinées. Sur Cloudflare, nous avons payé 20 $. Sur le tier d'utilisation équivalent de Vercel, l'estimation sortait à environ 180-220 $ selon lesquels add-ons étaient actifs.
Cela dit, la tarification de Vercel vous paie quelque chose de réel. On revient là-dessus dans un instant.
Le piège de la bande passante et de la sortie
C'est la chose que personne ne vous signale jusqu'à ce qu'il soit trop tard. Vercel facture la bande passante sur le plan Pro au-delà de 1TB. Ça semble correct. La plupart des projets n'y arrivent jamais. Mais les Edge Functions qui retournent de grandes réponses, ou les projets qui font du traitement d'images côté serveur, peuvent consommer la bande passante de façons qui semblent disproportionnées.
L'ensemble du réseau de Cloudflare fonctionne avec une sortie non mesurée au sein de leur plateforme. La page de tarification de Cloudflare le rend explicite. Les requêtes Workers et Pages Functions sont facturées à 0,30 $ par million après les 100k requêtes quotidiennes gratuites. C'est transparent. Prévisible. Je peux dormir.Cloudflare's pricing page makes this explicit. Workers and Pages Functions requests are priced at $0.30 per million after the free 100k daily requests. That's transparent. Predictable. I can sleep.
Couverture du réseau Edge : Cloudflare gagne, mais pas par magie
Cloudflare a plus de 300 centres de données mondialement en 2026. Vercel fonctionne sur un ensemble plus restreint de régions, soutenu largement par l'infrastructure AWS. Pour la plupart des projets au Royaume-Uni et en Europe, la différence de latence au démarrage froid à la périphérie est réelle mais modeste. Pour un produit SaaS servant des utilisateurs à Lagos, Mumbai ou São Paulo simultanément ? L'écart de couverture de Cloudflare se réduit à presque rien.
J'ai travaillé sur un projet SaaS multilingue en 2024, servant des utilisateurs à travers l'Asie du Sud-Est. On avait initialement lancé sur Vercel et la latence p99 depuis Singapour tournait autour de 380ms. Pas terrible. On a déplacé le middleware API vers Cloudflare Workers et on l'a réduite à 95ms. Essentiellement le même code. Densité de nœuds edge différente.
Workers vs Edge Functions : la divergence du runtime
C'est là que les choses deviennent véritablement techniques et véritablement importantes. Vercel Edge Functions s'exécutent sur le modèle d'isolate V8 (même philosophie que Cloudflare Workers) mais elles sont liées plus étroitement à l'infrastructure propre de Vercel et au système middleware de Next.js. Cloudflare Workers font cela depuis plus longtemps. Le runtime Workers supporte Web Crypto, Streams, KV, R2, Durable Objects, et une suite de bindings qui n'ont pas d'équivalent direct sur Vercel.Workers runtime supports Web Crypto, Streams, KV, R2, Durable Objects, and a suite of bindings that have no direct equivalent on Vercel.
Si vous construisez quelque chose qui a besoin d'état persistant à la périphérie (pensez : indicateurs de présence, rate limiting avec état partagé, fonctionnalités collaboratives en temps réel), Cloudflare Durable Objects sont véritablement utiles et il n'y a rien sur Vercel qui les égale aujourd'hui.
Cela dit, si vous déployez une app Next.js 14+ avec App Router et que vous voulez une ISR sans configuration, du streaming Edge et des middlewares qui « fonctionnent juste » avec votre setup RSC, Vercel reste le chemin le plus fluide. Ce n'est pas une opinion. C'est juste ce que j'observe à chaque fois que j'essaie de répliquer l'intégration Next.js de Vercel sur Cloudflare Pages en utilisant l'adaptateur @cloudflare/next-on-pages. Ça fonctionne. C'est juste pas frictionless.@cloudflare/next-on-pages adapter. It works. It's just not frictionless.
Expérience développeur : la version honnête
Je veux être prudent ici parce que la DX est subjective et c'est aussi où vivent les prises les plus tribales. Donc laissez-moi juste décrire ce que j'observe réellement.
Le tableau de bord de Vercel est magnifique. Les déploiements de prévisualisation sont instantanés. L'intégration GitHub est la meilleure que j'aie utilisée partout. Quand vous pushez une branche, l'URL de prévisualisation est live en moins de 45 secondes sur un cache chaud, et le commentaire de déploiement sur votre PR vous montre les Core Web Vitals, la durée du build, et un lien direct. Cette boucle de feedback est rapide et ça se ressent bien. Ça compte, surtout quand vous embarquez un client non-technique qui veut cliquer sur un lien et voir ses changements.feels good. That matters, especially when you're onboarding a non-technical client who wants to click a link and see their changes.
Cloudflare Pages a considérablement amélioré son tableau de bord depuis l'époque 2022 où il ressemblait à un élément subsidiaire boulonné sur Workers. Le système de build est plus rapide maintenant, les déploiements de prévisualisation fonctionnent bien, et l'intégration Pages + Workers (via wrangler.toml) est véritablement agréable. Mais le modèle mental de la surface produit de Cloudflare est plus large et donc plus difficile. Vous avez Workers, Pages, R2, KV, D1, Durable Objects, Pages Functions, et ils ont tous des surfaces de configuration légèrement différentes. La documentation sur developers.cloudflare.com est complète mais très étendue.wrangler.toml) is genuinely nice. But the mental model of Cloudflare's product surface is broader and therefore harder. You've got Workers, Pages, R2, KV, D1, Durable Objects, Pages Functions, and they all have slightly different configuration surfaces. The documentation at developers.cloudflare.com is thorough but sprawling.
Honnêtement, j'ai vu des développeurs juniors chez Seahawk prendre Vercel en un jour. Cloudflare Pages prend environ une semaine avant que quelqu'un arrête de douter si sa fonction est un Worker ou une Pages Function et quel fichier de config gouverne quoi.
Développement local et Wrangler
Le CLI wrangler dev de Cloudflare est bon. Il exécute une simulation du runtime Workers et supporte la plupart des bindings. Mais « simulation » est le mot clé. J'ai déployé du code qui fonctionnait localement et se comportait différemment sur le vrai réseau edge à cause de différences subtiles dans le comportement de KV en aperçu par rapport à la production. Petit bug en 2025, attrapé en staging, mais ça m'a coûté une demi-journée.wrangler dev CLI is good. It runs a local simulation of the Workers runtime and supports most bindings. But "simulation" is the operative word. I've shipped code that worked locally and behaved differently on the actual edge network because of subtle differences in how KV behaves in preview versus production. Small bug in 2025, caught in staging, but it cost me half a day.
La commande vercel dev de Vercel est plus limitée dans certains cas extrêmes mais c'est presque toujours une réplique fidèle de la production pour les projets Next.js standard. Cette prévisibilité compte.vercel dev command is more limited in some edge cases but it's almost always a faithful replica of production for standard Next.js projects. That predictability matters.
Support de framework au-delà de Next.js
C'est une conversation sous-estimée. Vercel est, fonctionnellement, une entreprise d'hébergement Next.js qui supporte aussi d'autres choses. SvelteKit, Nuxt, Astro, Remix, SolidStart fonctionnent tous, et ils fonctionnent bien. Mais Next.js reçoit les fonctionnalités en premier, obtient de meilleures valeurs par défaut, et est clairement le cas d'usage principal.
Cloudflare Pages n'a aucune allégeance envers un framework. Astro sur Pages est un plaisir. L'adaptateur SvelteKit pour Cloudflare est maintenu et stable. J'exécute une poignée de projets Astro sur Pages depuis mi-2024 et les temps de build sont plus rapides que les déploiements Vercel équivalents pour les mêmes sites (environ 30-40% plus rapides en moyenne, d'après mes propres logs de build).
Si votre équipe s'éloigne de Next.js ou construit avec plusieurs frameworks sur différents projets, Cloudflare Pages est plus agnostique et cet agnosticisme paie sur la durée.
Où je choisirais chacun en 2026
Soyons directs. Voici la logique de décision que j'utilise réellement :
Choisir Vercel si :
- Votre projet est Next.js-first et vous utilisez App Router profondément (RSC, streaming, ISR, tout ça)
- Vos clients ont besoin de voir les déploiements preview et commenter dessus sans aucune friction technique
- Votre équipe est petite (1-3 développeurs) et le coût par siège est négligeable
- Vous construisez quelque chose où le support Next.js de première classe vaut le prix premium
Choisissez Cloudflare Pages si :
- Vous êtes une agence ou un opérateur indépendant gérant plus de quatre ou cinq projets en production
- La prévisibilité des coûts compte plus que la meilleure expérience développeur Next.js
- Vous avez besoin de liaisons Workers (KV, R2, Durable Objects, D1) dans votre architecture
- Votre base d'utilisateurs est mondialement distribuée et la latence edge dans les régions non-US compte
- Vous n'êtes pas lié à Next.js et voulez la flexibilité des frameworks
Pour le travail client de Seahawk spécifiquement, nous avons opté pour une séparation : Cloudflare Pages pour les sites marketing, les builds riches en contenu, et tout ce qui est basé sur Astro. Vercel pour les produits SaaS Next.js complexes où l'équipe de développement du client est déjà dans cet écosystème.
Le truc que personne ne mentionne : le support
Vercel Pro vous donne le support par email. Enterprise en propose davantage. C'est réactif et l'équipe connaît Next.js en profondeur. Si quelque chose casse dans votre pipeline de déploiement à 2h du matin un jeudi avant un lancement client, avoir quelqu'un qui répond et qui comprend vraiment ce que la révalidation ISR fait sous le capot, ça a de la valeur.
Le modèle de support de Cloudflare pour Pages spécifiquement a historiquement été... inégal. Leur communauté Discord est active et l'équipe Workers est accessible, mais les tickets de support spécifiques à Pages peuvent prendre plus de temps à être résolus que vous ne le souhaiteriez. C'est amélioré en 2025 mais je donnerais quand même l'avantage à Vercel ici (jeu de mots, désolé).
---
FAQ
Cloudflare Pages est-il vraiment prêt pour la production en 2026 ?
Oui, sans équivoque. La perception que « Cloudflare Pages est encore en bêta » est dépassée. Il exécute des charges de travail de production sérieuses. Le statut de la plateforme Pages a été constamment solide. Les principales réserves concernent l'adaptateur Next.js (qui est maintenu par la communauté, pas en propriété) et la courbe d'apprentissage autour de la surface produit plus large de Cloudflare.Pages platform status has been consistently strong. The main caveats are around the Next.js adapter (which is community-maintained, not first-party) and the learning curve around Cloudflare's broader product surface.
Puis-je utiliser Cloudflare Pages avec Next.js App Router ?
Vous pouvez, via l'adaptateur @cloudflare/next-on-pages. Il supporte un sous-ensemble significatif des fonctionnalités d'App Router, y compris les Server Components, les routes dynamiques et les middlewares. Mais certaines fonctionnalités qui reposent sur une infrastructure spécifique à Vercel (comme l'ISR avancé avec revalidation à la demande via l'API Vercel) ne fonctionnent pas ou nécessitent des contournements. Si vous construisez une application Next.js complexe, testez vos besoins en fonctionnalités spécifiques avant de vous engager.@cloudflare/next-on-pages adapter. It supports a significant subset of App Router features including Server Components, dynamic routes, and middleware. But some features that rely on Vercel-specific infrastructure (like advanced ISR with on-demand revalidation via the Vercel API) either don't work or require workarounds. If you're building a complex Next.js app, test your specific feature requirements before committing.
Le forfait gratuit de Vercel fonctionne-t-il pour les sites client ?
Techniquement oui, mais les Conditions de service de Vercel pour le plan Hobby restreignent l'utilisation commerciale. Si vous construisez pour un client payant, vous devriez être sur Pro. Ce n'est pas une zone grise qu'ils ignorent indéfiniment. Utilisez Pro pour le travail client.
Quelle plateforme est meilleure pour la performance SEO ?
Aucune plateforme ne vous offre le SEO par défaut. Mais la livraison en edge et les Core Web Vitals sont liés, et les deux plateformes peuvent produire d'excellents scores de LCP et CLS avec une bonne implémentation. L'API Image Optimisation de Vercel (via next/image) est plus mature et plus facile à configurer. La fonctionnalité Image Resizing de Cloudflare (disponible sur les plans Pro) nécessite plus de configuration manuelle mais est moins chère à grande échelle.next/image) is more mature and easier to configure. Cloudflare's Image Resizing feature (available on Pro plans) requires more manual setup but is less expensive at scale.
Et Netlify ? Est-ce que c'est toujours pertinent ?
Netlify existe toujours et est toujours utilisé, particulièrement par les équipes JAMstack ayant des workflows spécifiques à Netlify. Mais en termes de notoriété, d'adoption et d'investissement dans la plateforme en 2026, ça s'essouffle noticeusement par rapport à Cloudflare et Vercel. Je n'ai pas recommandé Netlify pour un nouveau projet depuis environ 2023.
---
Le choix de plateforme en 2026 est vraiment moins dramatique que ce que les threads Twitter laissent entendre. Les deux fonctionnent. Les deux sont fiables. La vraie décision concerne l'alignement du modèle de coûts avec votre business et l'alignement du framework avec votre équipe. Prenez cette décision délibérément plutôt que de suivre par défaut ce que le bouton « deploy » des docs du framework affiche.