L’étude State of JS parue en 2025 montre une trajectoire claire : Next.js domine aujourd’hui largement le paysage des frameworks React. En 2018, le marché était encore partagé, notamment entre Gatsby et Next.js. En quelques années, l’écart s’est creusé. 56 % des répondants utilisent désormais Next.js tandis que le reste du marché se répartit entre plusieurs alternatives, comme Nuxt.js, et des challengers en progression tels qu’Astro ou SvelteKit.
Next.js est surtout devenu une architecture par défaut pour les projets React. L’enquête Stack Overflow Developer Survey 2025 montre ainsi que 21 % des développeurs professionnels déclarent utiliser Next.js dans leur travail. Là où l’on opposait auparavant React comme une librairie et Angular comme un framework, Next.js a pris la place de framework de référence dans l’écosystème React.
Cette adoption massive ne va toutefois pas sans contrepartie. Les mêmes enquêtes mettent en évidence un recul de l’admiration et du désir pour Next.js. Cela montre que les équipes choisissent souvent Next.js par défaut ou par contrainte.
Plusieurs événements en 2025 ont entaché la réputation du framework. De nombreux développeurs avaient alerté sur le risque lié à l’exécution de code côté serveur. La faille React2Shell a ainsi obtenu la note maximale de 10.0 sur l’échelle CVSS, un niveau rarement atteint.
Dans cet article, nous avons croisé le code et les chiffres pour répondre à une question simple, mais structurante : pourquoi Next.js est-il devenu le choix par défaut aujourd’hui ?
Next.JS en 2025 : les chiffres d’une adoption massive.
On l’a mentionnée en introduction, l’étude State of JS représente 14 015 répondants. Elle est organisée par deux Français : Sacha Greif et Eric Burel, et de nombreux contributeurs open-source.
State of JS classe Next.js parmi les meta-frameworks, aux côtés de Nuxt, Gatsby et Astro.
Pour voir apparaître Angular il faut voir le tableau avec React et Vue. Les chiffres montrent qu’Angular perd du terrain. Svelte et VueJS lui prenne du territoire chaque année.
Stack Overflow montre que React n’embarque pas systématiquement Next.js
React y est mentionné par 44,7% des développeurs alors que Next.js grimpe de 17 à 20,8%. En pratique il y a plus de nouveaux développeurs React que de nouveaux développeurs Next.js. Il est très certains que les nouveaux utilisateurs de Next.js sont aussi les nouveaux utilisateurs de React.
C’est dans le monde professionnel que Next.js vient par défaut. Quand on recoupe les chiffres de State of JS on constate également que Next est l’outil par défaut pour les projets professionnels.
Certaines bases de données B2B comptent plus de 18K entreprises utilisatrices de Next.js et les études de salaires montrent qu’un développeur ou une développeuse est mieux rémunéré s’il maîtrise Next en plus de React.
Bref, Next.js est devenu le choix par défaut pour les applications web en entreprise. Et on comprends pourquoi. Le framework apporte un code uniformisé, des performances fiables, peu importe l’échelle. Et la flexibilité pour profiter autant d’un framework backend que d’un framework frontend. On en reparlera plus tard.
Pourquoi migrer de React vers Next.js : Performance et SEO.
WeLoveDevs.com va plus vite avec Next.js
Le site de WeLoveDevs est le résultat de choix technologiques faits dans un autre contexte.
Au départ, ce n’était qu’une CVthèque. Avec Vincent, on venait tous les deux du développement mobile. React nous paraissait alors un choix naturel. J’avais déjà beaucoup travaillé avec React Native, et l’approche par composants nous convenait bien.
Avec le temps, le produit a changé.
- WeLoveDevs est devenu un site d’annonces, avec des pages entreprises.
- La majorité du trafic non payant venait désormais du SEO.
- En parallèle, l’application a grossi. Le bundle JavaScript est devenu difficile à découper, notamment à cause du store Redux central.
Avant que Next.js ne soit une option, nous avons dû passer au rendu côté serveur. On a bricolé. Le serveur était un Express qui faisait un rendu React, puis livrait une SPA complète. L’hydratation correspondait au moment où le bundle client prenait le relais du rendu serveur.
Quand Next.js a été suffisamment mature, nous avons déployé un second serveur. Nous avons commencé par y migrer les fonctionnalités en bout de parcours, comme les pages d’annonces.
Deux ans plus tard, nous avons ensuite migré la home. Aujourd’hui, certaines fonctionnalités internes, notamment le backoffice, sont encore servies par l’ancienne application React.
Et ça se voit sur les performances web.
Pouvez-vous trouver le moment où la home page a été migrée sur Next ? Le Speed Index variait entre 1400 et 1600ms. Et après migration, il est stabilisé à 1000ms.
Et aujourd’hui cet indicateur est descendu encore à 500ms.
Pourquoi ce gain en performance et pourquoi en deux temps ?
Avant la migration, WeLoveDevs utilisait du rendu côté serveur avec React et Express. En pratique, ce modèle était fragile. La moindre divergence entre le HTML généré côté serveur et le rendu attendu par le bundle client provoquait une hydratation ratée. Suivie d’un re-render complet côté client qui explose l’indicateur Largest Content Paint.
Pour éviter ces cas, certains composants trop complexes étaient volontairement remplacés par des placeholders côté serveur, et chargés uniquement une fois le bundle JavaScript évalué et le store initialisé. Cette approche permettait de stabiliser l’application, mais annulait en grande partie les bénéfices du SSR en termes de performance perçue.
Nous gagnons encore 500 ms en réduisant ce que le navigateur doit exécuter. En cassant le store Redux historique et en affinant le chunking, la quantité de JavaScript à exécuter diminue nettement. Les React Server Components permettent en outre de rendre certains composants uniquement côté serveur, sans jamais les envoyer au client. Le navigateur affiche du HTML, et n’exécute du JavaScript que là où c’est nécessaire.
Next.js sur un nouveau projet c’est quand même une expérience développeur largement supérieure !
Récemment, j’ai développé mon site personnel avec Fastify et Handlebars. Tout est rendu côté serveur. C’est simple, efficace et rapide. Pour un site de contenu classique, cette approche fonctionne très bien.
Sur un projet de voyage à vélo, le contexte était différent. J’avais besoin d’un CMS. J’ai donc déployé Strapi, un CMS headless. Côté front, certaines fonctionnalités devaient vivre côté client, comme un outil pour créer un carnet de voyage personnalisé. Dans ce contexte, Next.js me paraissait plus adapté que Fastify.
Le résultat m’a surpris. Je pensais que Next.js serait plus lourd. Pourtant, l’instance s’exécute sans difficulté avec 512 Mio de RAM. Elle n’est pas connectée à PostgreSQL ni à un stockage de type S3. Dans cette configuration, elle consomme moins de CPU que mon instance Fastify. À l’inverse, Strapi s’est révélé trop lourd pour ce type d’instance.
Turbopack m’a décoiffé.
La vraie différence se fait sur l’expérience développeur. Turbopack est le successeur de Webpack, écrit en Rust. Il n’a pas encore remplacé Webpack partout, mais il change clairement le quotidien. Le serveur de développement démarre en quelques centaines de millisecondes. Sur ce projet, le build de production prend moins de dix secondes.
À titre de comparaison, WeLoveDevs était dans une autre situation. Démarrer Webpack en développement prenait plusieurs minutes. En production, un build pouvait dépasser trente minutes. Le volume de pages et la génération des sitemaps y contribuaient fortement. Je me rappelle qu’un développeur avait reçu une machine neuve et se vantait de pouvoir faire le build dev en moins de 4 minutes.
Turbopack n’est pas encore généralisé dans l’écosystème. Il remplace déjà le serveur de développement dans la majorité des cas, mais il ne couvre pas encore toutes les fonctionnalités de Webpack. Il ne prend pas non plus en charge le Pages Router, le système historique que l’App Router remplace aujourd’hui.
Pourquoi Next.js ne provoque plus autant d’enthousiasme ?
State of JS comme StackOverflow indiquent une baisse de l’enthousiasme. Sur le premier on lit qu’entre 2022 et 2024, elle a chuté de 77 à 58% SvelteKit et Astro provoquant plus d’enthousiasme.
Alors qu’est-ce qui peut provoquer cette baisse d’enthousiasme ? La réponse n’est pas simple. C’est multi-factoriel. Mais le principal est sûrement le plus simple.
Next.js est un choix par défaut, pas un choix porté par la hype.
State of JS 2024 montre un décrochage sur l’Appreciation de Next.js : on passe d’environ 77% (2022) à 58% (2024), pendant qu’Astro et SvelteKit conservent des utilisateurs plus ‘heureux’. À lire avec une nuance : le format de l’enquête 2024 introduit davantage de réponses neutres, ce qui tend à faire baisser mécaniquement les scores.
Il y a un autre facteur assez simple qui peut expliquer cela. Vu que la majorité des projets sont aujourd’hui basés sur Next.JS, les développeurs qui travaillent avec n’ont pas porté le choix. Alors que quand il était encore un challenger, il fallait que les devs montrent beaucoup d’enthousiasme pour qu’il soit retenu.
Est-ce que ça veut dire qu’Astro et SvelteKit vont remplacer Next d’ici quelques années dans le cœur des entreprises ?
Astro est déjà très attractif pour les sites de contenu ou catalogue. Et c’est un territoire où l’adoption des agences webs est clé. Aujourd’hui on constate que Next.js est poussé par ces acteurs chez leurs clients.
On a vu quelques entreprises adopter Svelte. Le principal défaut de ce choix est qu’il y a beaucoup moins d’opportunités de recrutement. Il est plus efficace de convertir des devs Next à Svelte pour les assimiler à l’équipe.
Les failles de sécurité ça abîme la réputation des frameworks aussi
On explique souvent que le principal impact d’une faille de sécurité est sur la perception d’une marque, sur sa réputation.
Et ça vaut pour les frameworks. Encore maintenant quand, j’écris cet article, on trouve sur la page d’accueil du framework on voit le bandeau “React2Shell & two new vulnerabilities”
Et React2Shell n’est pas le premier cas. Les fonctionnalités de middleware avaient donné deux failles de sécurité permettant un bypass d’authentification (CVSS 9.1). La première en 2024, la deuxième en 2025.
Le système d’optimisation des images avait également permis un DoS, une fois en 2024 et une deuxième en 2025 (CVSS 7,5).
Donc quand les React Server Component donnent une faille en 2025, on a peur d’une deuxième faille en 2026. C’est un sujet structurel et pas accidentel.
Et le sujet structurel c’est principalement que React Server Component, et Next permettent d’exécuter du code côté serveur. Alors que ce code métier était déjà exécuté côté client. Cela crée une surface d’attaque que beaucoup des développeurs avaient dénoncé dès l’annonce de la fonctionnalité. Et Vercel reste une Startup : “Move fast and break things”
La vague de boycott concernant Vercel en 2025 n’a pas encore d’impact visible sur Next.js
Une vague d’appels à boycotter Vercel a saisi la communauté cette année. Les appels étaient très bruyants et certaines agences web ont même déclaré migrer leurs clients hors Vercel. Le plus souvent pour atterrir sur Netlify ou Cloudflare.
Ça n’a aucun impact visible sur le chiffre d’affaires de la société qui a atteint les 200 millions de revenus récurrents annuels en 2025. Soit 67% de croissance, c’est une belle performance pour une entreprise qui est censée être boycottée.
La réalité c’est que Vercel héberge beaucoup de projets gratuitement avec une fonctionnalité de scale-to-zero. Le serveur est coupé quand il n’y a pas de visiteurs. Le premier visiteur le réveille en quelques secondes.
Et c’est facile de quitter un service gratuit pour un autre.
Bref, le Vercel-drama ne suffit pas à expliquer la baisse de désirabilité de Next. C’est une accumulation qui commence par la fatigue et le choix par défaut. Ils font le lot de celui qui domine le marché. Ajoutez une perte de confiance suite à des failles de sécurité. Et du drama comme déclencheur pour faire tomber le roi.
Apprendre Next.js en 2026 reste incontournable pour les développeurs Web
La majorité des entreprises adoptent Next.js parce qu’il est adopté par la majorité des développeurs. C’est une boucle vertueuse qu’on désigne souvent par le mot “mainstream”.
Donc oui, si vous faites du web, que ce soit du PHP ou du Vue.js, apprendre Next.js vous donne accès à beaucoup plus d’opportunités professionnelles. Prenez le temps de passer le QCM Next.js contribué par la communauté WeLoveDevs.
React sans Next.js reste indispensable dans beaucoup de cas. Par exemple, si vous avez un backend en Symfony ou Django dans ce cas, vous utiliserez React pour dynamiser une page qui est déjà rendue côté serveur.
Même pour une Single Page Application où on pourrait dire que React suffit, Next devient un bon réflexe. C’est vraiment le framework qui vous permettra d’ajouter la génération ou le rendu côté serveur simplement si le besoin métier change. Il facilite le déploiement. Et surtout c’est le framework qui uniformise le code quand l’équipe grandit.
On peut avoir l’impression que Next est trop lourd pour un POC ou un side-project, mais mon expérience indique le contraire. Il est vraiment léger et se met en production en quelques heures.
