Un ingénieur chez Cloudflare a reconstruit Next.js en sept jours avec Claude et pour seulement 1 100 dollars de jetons. Le résultat, baptisé Vinext, est une réimplémentation complète du framework, fondée sur Vite plutôt que sur Turbopack, et déployable sur Cloudflare Workers en une commande. Les premiers benchmarks affichent des builds jusqu'à 4,4 fois plus rapides et des bundles clients réduits de 57 %.
LCloudflare avait investi des ressources significatives dans OpenNext, un projet communautaire visant à faire tourner les applications Next.js sur des infrastructures autres que Vercel. L'approche consistait à rétro-ingénierer le format de sortie produit par Turbopack — le compilateur propriétaire de Vercel — pour le rendre interprétable par d'autres environnements d'exécution. Le résultat était fonctionnel mais structurellement fragile : chaque mise à jour mineure de Next.js pouvait casser la compatibilité, sans préavis, parce que le format de sortie de Turbopack n'est ni documenté ni stabilisé contractuellement.
Face à ce mur, un ingénieur chez Cloudflare a décidé de changer de niveau : plutôt que d'adapter un format opaque, pourquoi ne pas réimplémenter directement la surface d'API de Next.js sur Vite, le compilateur standard de l'écosystème front-end. Le tout en s’appuyant sur l’aide de Claude, le modèle d’Anthropic. Le processus reposait sur une boucle courte et mécanique : définir une tâche précise, laisser Claude écrire l'implémentation et les tests associés, lancer la suite de tests, fusionner si elle passe, fournir l'output d'erreur à Claude dans le cas contraire et itérer. Des agents distincts étaient dédiés à la revue de code et à la correction des commentaires de revue, automatisant une partie du cycle de validation habituellement pris en charge par une équipe.
Au total, plus de 800 sessions ont été ouvertes dans OpenCode sur la semaine. Le premier soir, les deux routeurs de Next.js — Pages Router et App Router — avaient un rendu côté serveur fonctionnel, avec middleware, actions serveur et streaming. Le troisième jour, la commande vinext deploy expédiait des applications complètes sur Cloudflare Workers avec hydratation côté client.
Un séisme dans l'économie du développement logiciel
Pour les DSI et architectes qui déploient des applications React en environnement multicloud ou serverless, cet événement marque un changement structurel, un séisme, dans l'économie du développement logiciel et dans les rapports de force entre plateformes d'hébergement. Next.js est le framework React dominant : environ la moitié des développeurs React l'utilisent, selon le State of JS 2025. Il est maintenu par Vercel, qui a construit sur lui un modèle économique reposant sur un choix d'architecture extrême : utiliser un bundler propriétaire à sortie opaque plutôt qu'un standard ouvert comme Vite.
Le build output de Next.js utilise Turbopack, un outil propriétaire développé par Vercel en Rust, dont le format de sortie est non documenté et optimisé pour l'infrastructure Vercel. Tout hébergeur concurrent — Cloudflare, Netlify, AWS Lambda — doit donc s'appuyer sur ce format opaque pour faire tourner les applications Next.js sur ses propres serveurs, avec le risque à chaque mise à jour mineure. La solution de contournement qui s'était imposée dans l'écosystème, OpenNext, est une approche fragile, développée par ingénierie inversée.
Cloudflare avait déjà investi dans OpenNext. Plutôt que de continuer à s'escrimer sur un format propriétaire, un ingénieur de l'entreprise a posé en février 2026 une question différente : et si on réécrivait l'ensemble de la surface d'API de Next.js directement sur Vite, le bundler standard de l'écosystème front-end ? Vite est déjà la fondation de SvelteKit, Nuxt, Astro et Remix, tout l'écosystème React sauf Next.js. Construire sur Vite signifiait produire une sortie standard, déployable sur n’importe quelle plateforme sans adaptation. Ce qui paraissait irréaliste sans IA a été réalisé en sept jours.
Turbopack contre Vite un changement fondamental
Un bundler est l’outil qui prend le code source d’une application web — des centaines ou milliers de fichiers JavaScript, TypeScript, CSS — et les transforme en un ou plusieurs fichiers optimisés pour être servis par un navigateur ou exécutés côté serveur. Turbopack, développé par Vercel en Rust, est conçu pour les architectures propres à Vercel : son output binaire est propriétaire et non documenté. Vite, à l’inverse, produit un output standardisé basé sur ES Modules natifs, compréhensible et déployable par tout runtime JavaScript, qu’il s’agisse de Node.js, de Cloudflare Workers ou de Deno. La migration de Turbopack vers Vite dans vinext est donc un grand pas, elle supprime la dépendance à un format opaque et rend le build output portatif par construction.
Les benchmarks publiés par Cloudflare illustrent les gains de compilation sur une application de 33 routes App Router. Next.js 16.1.6 avec Turbopack compile en 7,38 secondes en moyenne. Vinext avec Vite 7 (Rollup) descend à 4,64 secondes, soit 1,6 fois plus rapide. Avec Vite 8, qui intègre Rolldown — un bundler Rust open source équivalent à esbuild — le temps tombe à 1,67 seconde, soit 4,4 fois plus rapide. Côté bundle client gzippé livré au navigateur, Next.js produit 168,9 Ko ; vinext avec Rollup en produit 74 Ko, soit 56 % de moins. Ces mesures excluent le type-checking TypeScript et le lint pour assurer la comparabilité, et ne portent que sur la compilation et le bundling, pas sur la performance de serving en production.
Pour les équipes qui exploitent de grandes applications Next.js — et souffrent de builds de 20 à 30 minutes dès que le nombre de routes statiques dépasse quelques milliers — ces ratios ont une traduction opérationnelle directe en temps de déploiement, en coût de CI/CD et en capacité d’itération. Les pipelines CI/CD dimensionnés autour de builds statiques massifs, l’impact potentiel sur les coûts d’infrastructure et les délais de mise en production est substantiel, à condition que la maturité du produit suive.
Guillermo Rauch, CEO de Vercel, a immédiatement contesté la qualification de « production-ready », pointant des failles de sécurité identifiées et le fait que « customers running it in production » renvoie, selon les termes mêmes du billet Cloudflare, à un site bêta de l’agence National Design Studio sur CIO.gov, sans trafic significatif à l’heure de l’annonce. La critique est légitime sur le fond : vinext est explicitement présenté comme expérimental par ses auteurs.
Portabilité, dépendance fournisseur et souveraineté
L’événement vinext dépasse la dimension technique pour poser une question de gouvernance des architectures applicatives. Le modèle économique de Vercel repose structurellement sur un verrouillage doux : Next.js est open source, mais son build output propriétaire rend le déploiement sur une autre plateforme soit impossible soit coûteux en maintenance. C’est une forme de vendor lock-in documentaire plutôt que contractuelle — légale, mais réelle pour toute organisation qui cherche à diversifier ses fournisseurs d’hébergement ou à négocier ses contrats cloud.
Vinext, en remplaçant Turbopack par Vite, produit un output standardisé qui rétablit la portabilité. Une application Next.js compilée via vinext peut être déployée sur Cloudflare Workers, mais aussi — Cloudflare l’a démontré — sur Vercel en moins de 30 minutes de travail d’adaptation. Ce n’est pas un argument de marketing : c’est un changement de nature dans la relation entre le framework et la plateforme d’hébergement. Pour un DSI dont la politique d’achat exige un second sourcing ou une sortie de contrat maîtrisée, la différence est concrète.
L’autre implication, plus large, concerne l’économie de la réplication logicielle. Un projet de ce type aurait nécessité plusieurs années-ingénieur avant l’émergence des modèles de génération de code actuels. La réduction du coût de réplication d’un logiciel open source commercial modifie l’équilibre concurrentiel entre éditeurs et hébergeurs : tout projet suffisamment documenté et doté d’une suite de tests publique devient réplicable à faible coût. Le cas vinext constitue un précédent opérationnel, pas une extrapolation prospective.
La question que les équipes architecture devront trancher dans les prochains mois est celle de la maturité : vinext couvre 94 % de la surface d’API de Next.js 16, mais les 6 % exclus et les cas limites de sécurité non encore audités peuvent suffire à bloquer une migration en production.
