Ce qu’il faut absolument savoir avant de choisir Next.js

• Un article qui traite des problèmes d’ouverture et de gouvernance de Next.js : absence d’adaptateurs, manque de prise en charge serverless officielle, chemins de code réservés à Vercel, ainsi que l’attitude de Vercel dans sa réponse à un incident de sécurité
• Le choix d’une stack technique est une décision importante, avec des effets de long terme sur la vitesse de développement, la qualité du projet et la composition de l’équipe
• Les logiciels open source donnent aux utilisateurs la liberté d’étendre et de modifier le code, avec l’avantage d’éviter l’enfermement propriétaire
• Next.js est proposé en open source, mais reste étroitement imbriqué avec l’infrastructure de Vercel qui l’a créé
• Il n’y a rien de problématique à ce qu’une entreprise tire des revenus d’un logiciel open source qu’elle a créé, mais pour qu’un tel modèle soit durable, la frontière entre l’open source et l’entreprise doit être claire

Contexte et intérêts de l’auteur

• L’auteur travaille chez Netlify depuis plus de quatre ans, et Netlify est en concurrence avec Vercel
• En construisant directement chez Netlify l’infrastructure et l’outillage nécessaires pour prendre en charge toutes les fonctionnalités de Next.js, il a acquis une compréhension approfondie de son architecture interne
• Il a longtemps hésité à soulever publiquement ces problèmes, mais a décidé d’écrire cet article après avoir estimé que la manière dont Vercel a géré un récent problème de sécurité nuisait à la communauté

# Problèmes d’ouverture et de gouvernance de Next.js

Fait n°1 : absence d’adaptateurs

• La plupart des frameworks modernes peuvent être configurés de manière flexible selon la cible de déploiement via des adaptateurs
• Next.js ne prend pas officiellement en charge les adaptateurs, et son format de sortie repose sur une structure propriétaire et non publique utilisée uniquement par Vercel
• Vercel a créé la Build Output API, mais Next.js ne la prend toujours pas en charge
• En conséquence, les fournisseurs autres que Vercel doivent construire leurs solutions sur des API non documentées, ce qui les rend vulnérables aux changements imprévus
• Cloudflare et Netlify collaborent au développement d’adaptateurs Next.js via OpenNext, et Vercel a aussi commencé à y participer, mais aucun calendrier concret n’a encore été annoncé

Fait n°2 : manque de prise en charge serverless officielle

• La méthode officielle d’auto-hébergement de Next.js repose sur des serveurs à exécution longue, ce qui rend difficile l’obtention d’une mise à l’échelle souple et d’une réduction des coûts en conditions réelles d’exploitation
• Il existait autrefois un mode serverless, mais il a été supprimé en octobre 2022 sans véritable explication
• La documentation officielle de React mentionne qu’un déploiement serverless est possible, mais il n’existe en pratique aucune documentation officielle expliquant comment le mettre en œuvre
• Les fournisseurs d’hébergement qui veulent un environnement serverless doivent faire de la rétro-ingénierie sur Next.js et en réaliser leur propre implémentation

Fait n°3 : existence de chemins de code réservés à Vercel

• Next.js contient des chemins de code non publics qui ne fonctionnent que lors d’un déploiement sur Vercel (par exemple : minimal mode)
• Grâce à ce mode, Vercel peut optimiser les performances, notamment en exécutant le middleware à l’edge
• Le middleware permet d’exécuter rapidement de la logique avant le passage par le cache, mais cette fonctionnalité n’est accessible qu’à Vercel
• Netlify a mis en place une équipe d’ingénieurs dédiée et développé sa propre implémentation pour prendre en charge cette fonctionnalité, mais cela exige un niveau de ressources inaccessible aux petits fournisseurs
• Le fait que Vercel soit en pratique la seule plateforme à proposer officiellement l’ensemble des fonctionnalités de Next.js va à l’encontre de la philosophie open source du framework

Incident de sécurité et réponse de Vercel

• Le 21 mars 2025, une faille de sécurité critique dans Next.js permettant de contourner l’authentification (CVE notée 9,1) a été rendue publique
• Cette vulnérabilité permettait, en incluant un en-tête spécifique dans la requête, de neutraliser le middleware et d’accéder à des ressources protégées
• La faille a été signalée le 27 février, mais Vercel n’a commencé à l’examiner que le 14 mars
• Une fois le problème identifié, un correctif a été déployé rapidement, mais il a fallu huit jours pour en informer d’autres fournisseurs comme Netlify
• Le billet de blog initial laissait entendre que le pare-feu de Vercel avait protégé ses clients, alors qu’en réalité ce n’était pas le cas
• Cela a conduit plusieurs fournisseurs et développeurs à réagir sur la base d’informations erronées ou à se retrouver dans la confusion, et il est possible que de nombreux sites soient encore vulnérables

La propriété de Next.js par Vercel et les responsabilités de l’open source

• On ne peut pas nier que Vercel possède Next.js, et sa monétisation est légitime
• Mais puisqu’il est distribué en open source, les autres fournisseurs devraient aussi pouvoir l’utiliser à égalité, et sur ce point Vercel est en deçà des attentes
• Redis, Grafana, WordPress et d’autres exploitent eux aussi à la fois des services commerciaux et des projets open source, tout en préservant l’ouverture et l’interopérabilité

Conclusion

• Quel que soit le framework choisi, cela relève de la décision de chacun, et si Next.js est le meilleur choix pour résoudre votre problème, il reste tout à fait possible de l’utiliser
• Mais il est important de choisir en connaissant les problèmes structurels et les limites actuelles de Next.js

[GN⁺]

Commentaires Hacker News

• J’ai utilisé next.js puis abandonné le projet quand je suis passé du page router à l’app router. L’expérience avec l’app router était tellement mauvaise que je n’ai plus jamais eu envie de réutiliser next.js depuis
  • Vercel fait semblant d’être open source, mais construit des barrières pour enfermer les utilisateurs sur sa plateforme d’hébergement
• J’ai toujours été un peu mal à l’aise vis-à-vis de Vercel. Quand j’ai essayé d’auto-héberger Next.js sur un VPS, je suis tombé dans les petits pièges qu’ils avaient mis en place
  • Leur manière de gérer cette vulnérabilité m’a rendu encore plus méfiant
  • Leur explication initiale affirmant que le pare-feu de Vercel avait « protégé activement » les clients a laissé une mauvaise impression
  • Il y a eu un retard pour informer les autres plateformes, ce qui montre que Vercel a moins d’incitation à empêcher l’introduction de vulnérabilités dans Next.js
• J’avertis tout le monde d’éviter next.js. V0 risque d’augmenter fortement son adoption
  • Beaucoup de nouveaux développeurs ne veulent pas avoir à réfléchir au déploiement ni à l’administration système
  • Si on connaît seulement React, l’avantage est de pouvoir en tirer quelque chose sans apprendre le SSR
• J’ai abandonné next.js parce que, sur de petits projets, il fallait 6 à 7 secondes pour que les changements apparaissent dans le navigateur
  • J’utilise maintenant React SPA et Vite
• Nous avons migré de Next.js vers Vike l’année dernière. L’expérience développeur s’est nettement améliorée
  • Pour l’essentiel, nos besoins sont couverts par le pré-rendu des pages
• J’ai des sentiments mitigés à propos de Next.js. D’un côté, c’est une entreprise qui construit un framework avec des investisseurs
  • Comme c’est sous licence MIT, Netlify ou une autre entreprise pourrait le forker et proposer une meilleure alternative
  • Si j’étais investisseur chez Vercel, je n’aurais aucune raison d’augmenter le risque de l’investissement en aidant la concurrence
  • Vercel soutient l’open source tout en essayant de maintenir suffisamment de friction pour faire de sa plateforme d’hébergement le meilleur choix
• Je suis en train de choisir la stack React de l’entreprise où je travaille. Je n’arrive pas à imaginer une raison de choisir Next.js plutôt qu’une alternative
  • Remix, React Router v7 ou TanStack sont des choix plus raisonnables si l’on veut du SSR
• Je ne suis pas convaincu que l’approche serverless soit un bon choix par défaut. Elle ajoute une complexité inutile
  • Je n’aime pas utiliser JavaScript côté back-end
  • Cette focalisation sur les server components et sur Next.js m’a donné une impression de vision en tunnel
  • Il est très probable que l’approche serverless soit à l’origine de la communication privilégiée via des en-têtes HTTP
• Les temps de build en développement sont catastrophiques, et il y a eu beaucoup de plaintes pendant des années sans que rien ne soit réglé
• Vercel et NextJS ne devraient pas exister
  • La seule fois où j’ai essayé Next, j’ai rencontré beaucoup d’erreurs d’hydratation en production
  • Le framework complique tout pour de potentiels gains liés au rendu côté serveur
  • Tout le framework donne l’impression d’avoir été conçu comme une belle vitrine pour vendre leurs services cloud hors de prix

[ahwjdekf]

L’auteur travaille chez Netlify et dit lui-même être un concurrent direct de Vercel. Cela me semble manquer un peu d’objectivité.

[preserde]

Le contenu de l’article reprend, dans les grandes lignes comme dans les détails, des points que tout le monde connaît déjà s’il a récemment comparé des frameworks concurrents comme TanStack ou Remix. Pour l’instant, la part de marché de Next.js reste tellement importante et Vercel n’a pas encore adopté une posture assez ouvertement agressive pour que cela apparaisse clairement à la surface.

[alpharoom]

Prétendre que les informations qu’un article cherche à transmettre manquent d’objectivité au seul motif que son auteur travaille chez un concurrent, c’est une attaque ad hominem. Même si l’on fait abstraction du parcours de l’auteur et de ses intérêts, est-ce vraiment un mauvais article ? Je pense que ce sont des informations utiles.