Un ingénieur. Une semaine. Mille dollars.
C'est ce qu'il a coûté à Cloudflare pour reconstruire Next.js de zéro.
Pas le patcher. Pas l'encapsuler. Pas faire de la rétro-ingénierie sur sa sortie de build comme tout le monde essayait de faire. Une réimplémentation complète de la surface API de Next.js — Vite au lieu de Webpack, Cloudflare Workers au lieu de Node.js, et un modèle de déploiement qui fonctionne en edge par conception plutôt que comme une réflexion après coup.
Le résultat s'appelle V-Next. Et quand j'ai lu l'annonce pour la première fois, ma réaction initiale était un mélange de "c'est impressionnant" et "attendez, est-ce que c'est vraiment assez stable pour y réfléchir sérieusement ?" Ces deux sentiments ont coexisté pendant environ une journée, jusqu'à ce que je commence à creuser les détails techniques et les données de production.
Voici ce qui a fait évoluer ma réflexion : le chiffre de 1 000 $ n'est pas la partie intéressante. Le coût est juste le titre accrocheur. Ce qui mérite vraiment d'être examiné, c'est la méthodologie — comment une boucle de rétroaction assistée par IA, ancrée sur la propre suite de tests open-source de Next.js, a transformé ce qui aurait dû être un projet de plusieurs mois pour une équipe en sept jours de travail par un seul ingénieur. Cette méthodologie est plus significative que le framework lui-même, car elle décrit quelque chose sur la façon dont les logiciels complexes seront construits à l'avenir.
Il y a aussi une décision technique enfouie dans V-Next que la plupart des analyses survolent — celle qui explique pourquoi la réduction de la taille du bundle est de 57 % et non de 15 %. J'y viendrai, mais d'abord il faut comprendre pourquoi Cloudflare était motivé à faire cela, car l'historique donne du sens aux choix architecturaux.
Le Problème de Verrouillage Vercel Dont Personne ne Parle Honnêtement
Next.js est un logiciel véritablement excellent. Vercel a construit quelque chose qui résolvait de vrais problèmes — rendu compatible SEO, génération statique, rendu côté serveur, ISR, server actions — et l'a emballé dans une expérience de déploiement qui rendait tout cela facile. Le framework et la plateforme ont grandi ensemble, et cette co-évolution fait partie de ce qui a rendu Next.js dominant.
C'est aussi exactement ce qui a créé la tension.
Vercel tourne sur Node.js complet. Cela donne accès à toute la surface API de Node.js — modules natifs, système de fichiers, crypto, streams, tout. Les fonctionnalités de Next.js ont évolué en supposant que cette compatibilité complète était disponible. Certaines de ces fonctionnalités — en particulier les configurations ISR avancées et les patterns de server actions — fonctionnent sur Vercel et deviennent des cauchemars de maintenance partout ailleurs.
Cloudflare Workers est un runtime différent. Ce n'est pas Node.js. C'est un environnement d'exécution personnalisé basé sur V8 avec un sous-ensemble d'APIs web standards et une couche de compatibilité Node.js limitée. Le compromis est significatif : Workers tourne en edge, dans des centres de données répartis dans plus de 300 villes, avec des temps de démarrage à froid mesurés en millisecondes plutôt qu'en secondes. Le profil de performance est réellement différent. Mais cette performance provient d'un runtime contraint, et Next.js n'a jamais été conçu avec cette contrainte en tête.
La tentative de la communauté pour combler ce fossé s'appelait OpenNext — un projet open-source qui essayait de faire fonctionner Next.js sur Cloudflare Workers en adaptant la sortie de build. Le problème était architectural. OpenNext devait faire de la rétro-ingénierie sur ce que le processus de build de Next.js produisait, puis le transformer pour fonctionner dans un runtime différent. Chaque fois que Vercel mettait à jour les mécanismes internes de Next.js (ce qui arrive constamment), quelque chose dans OpenNext cassait. Les mainteneurs étaient toujours en train de courir après le framework au lieu de construire.
Cloudflare a observé ce cycle suffisamment longtemps, a évalué l'effort nécessaire pour maintenir OpenNext, et a pris une décision différente : arrêter d'adapter la sortie de Next.js et plutôt reconstruire ce qui la produit.
C'est V-Next. Une implémentation propre de la surface API de Next.js — le même répertoire app/, les mêmes conventions de routage, les mêmes patterns de composants que les développeurs connaissent déjà — mais écrite de zéro pour cibler Cloudflare Workers.
Comment l'IA a Construit un Framework en Sept Jours
La méthodologie est la partie de cette histoire qui continue de capter mon attention.
La suite de tests de Next.js est publique. Elle est exhaustive — couvrant le comportement du routage, les modes de rendu, les patterns de récupération de données, les error boundaries, et quelques centaines d'autres cas qui définissent exactement à quoi ressemble le comportement correct de Next.js. C'est le type de couverture de tests que vous voudriez pour un framework dont dépendent des millions d'applications.
L'ingénieur de Cloudflare a utilisé ces tests comme spécification. Pas la documentation. Pas le code source de Next.js. Les tests — parce que les tests définissent le comportement de manière non ambiguë d'une façon que la documentation en prose n'atteint jamais tout à fait.
Le processus s'est déroulé en boucle de rétroaction : l'IA génère du code, les tests s'exécutent, les échecs sont renvoyés à l'IA, l'IA révise, les tests s'exécutent à nouveau. Répéter. La suite de tests open-source a fourni la vérité fondamentale vers laquelle la génération de l'IA devait converger. Sans cette ancre, le code généré par l'IA dériverait — produisant quelque chose qui ressemblerait au comportement de Next.js mais divergerait dans les cas limites d'une manière qui ne se manifeste qu'en production.
Le rôle de l'ingénieur humain était la supervision et la correction de trajectoire. Quand l'IA interprétait mal une exigence, quand deux tests tiraient dans des directions incompatibles, quand une solution générée passait techniquement les tests mais implémentait quelque chose de sémantiquement incorrect — c'étaient les moments nécessitant un jugement humain. Pas la majorité du travail. Mais les 10 % critiques qui déterminaient si le résultat était réellement correct.
Le chiffre de coût — 1 000 $ — reflète les dépenses de calcul IA. Une semaine d'exécutions intensives d'agents, d'itérations de tests et de cycles de révision. Ce chiffre ne fera que baisser à mesure que les modèles deviennent plus efficaces.
Ce que cette approche exige, c'est une suite de tests exhaustive qui spécifie réellement le comportement que vous essayez de reproduire. La plupart des projets n'ont pas cela. Next.js l'a parce que c'est un projet open-source mature, intensément maintenu, avec des milliers de contributeurs qui se soucient de la correction comportementale. La méthodologie qui a fonctionné ici fonctionne précisément parce que la spécification était déjà encodée dans les tests. C'est une contrainte réelle, et elle mérite d'être reconnue.
Ce que je trouve le plus intéressant dans la méthodologie, c'est où l'ingénieur humain a passé son temps. Pas à écrire du code d'implémentation — l'IA s'en est chargée. Pas à exécuter des tests — CI s'en charge. Le travail humain était en grande partie sémantique : évaluer si une solution générée qui passait les tests implémentait réellement la bonne chose. Les tests vérifient le comportement pour des entrées définies. Ils ne vérifient pas que vous avez choisi la bonne architecture pour les trois prochaines versions du framework.
Cette distinction est importante. Il existe une catégorie de décision — "l'état du routage doit-il vivre en mémoire ou être reconstruit à partir de l'URL à chaque requête ?" — où les tests ne donnent pas de réponse claire, mais les conséquences architecturales s'accumulent au fil du temps. Ce sont les décisions où l'expertise humaine est non négociable. L'IA peut générer les deux approches. Il faut quelqu'un qui a maintenu des applications Next.js en production pour savoir laquelle cause des problèmes six mois plus tard.
L'implication pour les équipes qui envisagent d'appliquer cette méthodologie à leurs propres projets : vous avez besoin d'une suite de tests dense et d'un expert du domaine capable d'auditer le résultat. L'IA compresse le temps d'implémentation. Elle ne supprime pas le besoin de jugement d'ingénierie. Ces deux choses sont différentes, et les confondre est la façon dont vous vous retrouvez avec une base de code qui passe tous ses tests tout en ayant des problèmes architecturaux fondamentaux.
La Décision Technique Qui Explique la Réduction de 57 % du Bundle
Voici ce que la plupart des analyses sur V-Next survolent.
Passer de Webpack à Vite n'est pas simplement un échange d'outils de build. Les deux outils ont des philosophies fondamentalement différentes concernant l'empaquetage.
Webpack a été conçu à l'ère du HTTP/1 où regrouper tout dans moins de fichiers plus volumineux était le bon choix — moins d'allers-retours signifiait de meilleures performances. Vite a été conçu après que les ES modules sont devenus universels, ce qui a entièrement changé les calculs d'optimisation. Vite utilise les ES modules natifs en développement et Rollup en interne pour les builds de production. Les deux sont orientés vers la production d'une sortie plus petite et plus ciblée que Webpack.
Par-dessus tout, Cloudflare Workers tourne en edge — ce qui signifie que la latence géographique est déjà résolue par l'architecture du runtime. Vous ne luttez pas contre des allers-retours de 200 ms vers un serveur distant. L'emplacement en edge s'en charge. Ce que vous optimisez passe de "moins de requêtes HTTP" à "charge totale plus petite." La philosophie de sortie de Vite s'aligne mieux avec cette contrainte.
La réduction de 57 % de la taille du bundle n'est pas magique. C'est l'effet composé d'un outil de build qui produit une sortie plus légère combiné à une cible de déploiement qui n'a pas besoin des optimisations de l'ère Webpack qui alourdissaient les bundles.
Les temps de build 4 fois plus rapides suivent un raisonnement similaire. L'expérience de développement de Vite a toujours été plus rapide que celle de Webpack — remplacement de modules à chaud quasi instantané, démarrages à froid plus rapides, traitement parallèle que l'architecture de plugins de Webpack rendait difficile. Cet avantage de vitesse se traduit aussi dans les builds de production.
Ce Que V-Next Fait Avec ISR
ISR est l'une des fonctionnalités les plus puissantes de Next.js et aussi la plus difficile à porter vers un runtime différent. L'implémentation originale d'ISR dans Next.js utilise le système de fichiers — elle écrit les pages régénérées sur le disque du serveur, les sert, et revalide en arrière-plan.
Cloudflare Workers n'a pas de système de fichiers. Il a Cloudflare KV — un magasin de clé-valeur distribué mondialement avec des vitesses de lecture au niveau de l'edge.
L'implémentation ISR de V-Next utilise KV comme couche de stockage. Les pages sont écrites dans des magasins KV, servies depuis là, et revalidées à l'intervalle configuré. Le comportement du point de vue du développeur est le même. L'implémentation sous-jacente est adaptée aux contraintes du runtime Workers.
C'est en fait un bon choix. Les lectures KV en edge sont rapides. La nature globalement distribuée de KV signifie que les pages ISR sont disponibles à proximité des utilisateurs dans les plus de 300 emplacements de centres de données de Cloudflare sans configuration supplémentaire. Sur Vercel, ISR nécessite un comportement de cache edge spécifique que vous configurez par route. Sur V-Next avec Cloudflare, la distribution est une propriété de la couche de stockage elle-même.
Ce Que V-Next Signifie Si Vous Construisez Quelque Chose Aujourd'hui
Avant de commencer à migrer quoi que ce soit : V-Next est expérimental. Cloudflare a été clair à ce sujet, et c'est le bon cadrage. Plusieurs applications réelles tournent en production — y compris CIO.gov, ce qui est un soutien significatif — mais les cas limites sont réels.
Voici ce qui ne fonctionne pas encore complètement :
Les analytics Open Graph en edge runtime ne se portent pas proprement. Si vous en dépendez pour les aperçus de partage social dans des configurations spécifiques, testez avant de vous engager.
Les bindings de blobs KV et les bindings Postgres ont des limitations. V-Next utilise les primitives de stockage de Cloudflare, et les patterns complexes d'intégration de base de données qui fonctionnent dans un environnement Node.js se heurtent aux contraintes du runtime Workers. Prisma avec des connexions directes à Postgres, par exemple, nécessite Hyperdrive (le service de proxy de base de données de Cloudflare) pour fonctionner correctement.
Turbopack n'est pas intégré. Si vous avez adopté Turbopack pour la vitesse de développement local, dans V-Next vous utilisez Vite — qui est rapide, mais c'est un outil différent et certaines configurations spécifiques à Turbopack ne se transposeront pas.
Le scaffolding Create Next App n'a pas encore d'équivalent V-Next. Vous configurez les projets manuellement ou adaptez des configurations existantes.
Certaines APIs spécifiques à Vercel dont Next.js dépend silencieusement n'existent pas dans V-Next. Si vous utilisez @vercel/og, @vercel/analytics, ou des packages similaires fournis par Vercel qui s'intègrent aux mécanismes internes de Next.js, ceux-ci nécessitent des alternatives.
Projets pour lesquels V-Next a du sens dès maintenant :
Si vous démarrez un nouveau projet et prévoyez de déployer sur Cloudflare Workers de toute façon, V-Next mérite une considération sérieuse. Vous obtenez la surface API de Next.js que vous connaissez déjà, des builds plus rapides, des bundles plus petits, et vous n'héritez pas des contraintes de Webpack.
Si vous êtes sur Vercel et que les coûts sont un point de pression, cela vaut le coup de faire des benchmarks. Le modèle tarifaire de Cloudflare (la bande passante est moins chère, le calcul en edge est moins cher pour certains patterns d'utilisation) peut rendre l'économie significativement différente à grande échelle.
Si vous exploitez un site de contenu à fort trafic avec une utilisation intensive d'ISR, l'approche basée sur KV présente de vrais avantages pour la performance de lecture globale.
Projets pour lesquels il vaut mieux attendre pour l'instant :
Les applications Next.js complexes qui utilisent de nombreuses fonctionnalités spécifiques à Vercel ou qui dépendent de patterns avancés de l'API Node.js vont se heurter à des murs de compatibilité. La surface de migration est trop importante pour un logiciel expérimental.
Les applications avec des exigences strictes de stabilité. Les systèmes critiques de production n'ont pas leur place sur des frameworks expérimentaux, sauf si vous disposez d'une capacité d'ingénierie sérieuse pour gérer l'imprévu.
Les Aspects de Tout Cela Qui Devraient Vous Mettre Mal à l'Aise
Réaction honnête : V-Next m'a impressionné. L'approche technique est solide, les chiffres de performance sont réels, et la méthodologie de développement assisté par IA représente quelque chose de véritablement nouveau dans la façon dont les frameworks peuvent être construits.
Et : je ne suis pas certain que Cloudflare soit le héros de cette histoire.
Vercel a construit Next.js. Ils l'ont publié en open-source, l'ont maintenu, ont financé son développement pendant des années. Cloudflare a utilisé cette surface open-source — spécifiquement la suite de tests que l'équipe de Vercel a consacré un effort énorme à construire — pour créer un produit concurrent. C'est légalement correct. C'est ce que l'open-source permet. Mais cela mérite d'être nommé : Cloudflare a directement bénéficié de l'investissement de Vercel pour concurrencer la plateforme de Vercel.
Le problème du verrouillage fournisseur ne disparaît pas non plus. Il se déplace. V-Next est conçu pour Cloudflare Workers. ISR tourne sur Cloudflare KV. Les assets sont servis depuis Cloudflare R2. Si vous adoptez V-Next, vous n'êtes pas verrouillé chez Vercel — vous êtes verrouillé chez Cloudflare. La dépendance a simplement changé de mains.
Mon opinion impopulaire : c'est peut-être le bon compromis pour de nombreuses équipes. Cloudflare possède son infrastructure de bout en bout — centres de données, calcul, bande passante, stockage. Cette intégration verticale est un avantage réel pour la prévisibilité des prix et l'optimisation des performances. Vercel construit par-dessus AWS, ce qui ajoute une couche à la structure de coûts. Mais les développeurs devraient entrer les yeux ouverts sur ce que "s'échapper du verrouillage fournisseur" signifie réellement ici.
Il y a aussi un tableau stratégique plus large qui mérite d'être gardé en tête. Cloudflare a acquis Astro — un autre framework frontend populaire — plus tôt dans cette chronologie. V-Next fait partie d'un schéma : Cloudflare ne se contente plus de vendre de l'infrastructure. Ils construisent une plateforme de développement full-stack opinionée qui concurrence Vercel sur plusieurs frameworks simultanément. L'état final vers lequel ils travaillent est un où tout l'écosystème de déploiement frontend — framework, outils de build, CDN, stockage, calcul — vit à l'intérieur de la surface produit de Cloudflare.
Ce n'est pas intrinsèquement mauvais pour les développeurs. La concurrence entre Vercel et Cloudflare sur l'expérience développeur va pousser les deux plateformes à s'améliorer. Mais il vaut la peine de reconnaître la structure d'incitations derrière V-Next. C'est une stratégie d'acquisition de clients, pas une contribution philanthropique à l'écosystème des frameworks. Cloudflare veut le trafic, la rétention et le calcul facturable qui accompagnent l'exécution de vos applications de production. V-Next est le moyen technique vers cette fin commerciale.
Comprendre cela ne rend pas V-Next moins bon. Cela clarifie simplement le prisme à travers lequel Cloudflare prendra des décisions sur son développement futur. Les fonctionnalités qui vous gardent sur l'infrastructure Cloudflare seront prioritaires. Les fonctionnalités de portabilité qui facilitent le départ ne le seront pas.
L'histoire du développement assisté par IA nécessite aussi un cadrage attentif. Un ingénieur + IA + une semaine est remarquable. C'est aussi un ingénieur qui comprenait Next.js en profondeur, comprenait Cloudflare Workers en profondeur, et pouvait évaluer la sortie générée par l'IA avec précision. L'IA a compressé le calendrier d'implémentation. L'expertise humaine a déterminé si la sortie compressée était correcte. Les deux parties de cette équation comptent.
Ce Que les Chiffres Montrent Réellement
Permettez-moi d'être concret sur ce qui est prouvé et ce qui est encore en cours d'établissement.
Temps de build 4 fois plus rapides : mesurés sur des projets réels, pas des applications jouets. Si votre pipeline CI passe 8 à 12 minutes sur les builds Next.js, vous envisagez des builds de moins de 3 minutes avec V-Next. Cela se cumule dans une équipe — moins de changements de contexte en attendant les builds, un feedback CI plus rapide, plus d'itérations par jour.
Bundles 57 % plus petits : c'est significatif pour le Time to Interactive, surtout sur mobile. Une réduction de 57 % de la taille du bundle se traduit directement par des chargements de page plus rapides sur des connexions limitées. Pour les sites de contenu, cela affecte à la fois l'expérience utilisateur et les scores Core Web Vitals.
CIO.gov fonctionnant avec V-Next en production : un site du gouvernement américain avec du vrai trafic et de vraies exigences de conformité faisant tourner un logiciel expérimental est un signal significatif. Les équipes informatiques gouvernementales ne prennent pas de risques à la légère. Le fait qu'ils aient migré est une donnée en soi.
Ce qui n'est pas encore établi : la stabilité à long terme sous des patterns de charge complexes, la surface de compatibilité complète à travers la diversité réelle de l'utilisation de Next.js dans les bases de code en production, et la trajectoire de maintenance une fois que V-Next aura rattrapé les versions actuelles de Next.js.
Suivez ces métriques si vous pilotez V-Next : temps de build (les logs CI vous le donnent immédiatement), taille du bundle (les rapports de sortie de build de Cloudflare l'indiquent), et Time to Interactive (Lighthouse ou WebPageTest contre la production). Ces trois chiffres vous disent si les avantages théoriques se manifestent dans votre application spécifique.
Une note pratique : mettez d'abord en place un déploiement parallèle. Faites tourner V-Next en parallèle avec votre déploiement Vercel existant sur des routes non critiques avant de basculer. Cela vous donne des benchmarks avec du vrai trafic sans risque en production. Les lacunes de compatibilité qui comptent pour votre projet spécifique se manifesteront rapidement sous des conditions réelles — bien plus fiablement que ce que n'importe quel test interne peut révéler. Deux semaines de trafic parallèle sur vos vrais patterns d'utilisation valent plus que n'importe quelle comparaison de benchmarks provenant du projet de quelqu'un d'autre.
La Partie Qui Mérite Qu'on s'y Attarde
Un ingénieur et un modèle d'IA ont reconstruit un framework frontend majeur en sept jours, et le résultat tourne en production sur de vrais sites, y compris un domaine gouvernemental.
Ce n'est pas un benchmark. C'est une preuve de concept sur la façon dont les logiciels complexes peuvent être construits.
La suite de tests de Next.js a joué le rôle de spécification. L'IA a joué le rôle de moteur d'implémentation. L'expertise humaine a joué le rôle de porte de qualité. Cette division du travail va apparaître dans davantage de projets logiciels au cours des 18 prochains mois — pas seulement des reconstructions de frameworks, mais des migrations complexes, des portages de bibliothèques, et des réimplémentations d'API où le comportement correct est déjà défini mais le travail d'implémentation est prohibitif.
La question intéressante n'est pas de savoir si Cloudflare peut terminer V-Next. Ils ont la capacité d'ingénierie et la motivation d'infrastructure. La question intéressante est de savoir ce qui sera reconstruit ensuite, par qui, et ce que cela fait à l'hypothèse que les logiciels complexes nécessitent des équipes de personnes sur de longues périodes.
Si un framework peut être reconstruit en une semaine, quoi d'autre le peut ?
C'est la question que V-Next pose réellement. La réponse va remodeler notre façon de penser le coût et le rythme du travail d'ingénierie ambitieux — et en tant que quelqu'un qui construit professionnellement avec des agents IA, cette question est considérablement plus excitante pour moi que n'importe quel chiffre de benchmark.
🤝 Travaillons Ensemble
Vous cherchez à construire des systèmes d'IA, automatiser des workflows ou faire évoluer votre infrastructure technologique ? Je serais ravi de vous aider.
- 🔗 Fiverr (développements et intégrations sur mesure) : fiverr.com/s/EgxYmWD
- 🌐 Portfolio : mejba.me
- 🏢 Ramlit Limited (solutions entreprise) : ramlit.com
- 🎨 ColorPark (design et branding) : colorpark.io
- 🛡 xCyberSecurity (services de sécurité) : xcybersecurity.io
