Next.js ou React pur avec Vite ? Choisir le framework adapté à votre projet.

Dans de nombreuses équipes utilisant React, Next.js est la solution avant même que la question ne soit posée. Les documents sont excellents, l’écosystème est vaste, le déploiement se fait sans problème, et l’on pense généralement qu’il rend les sites plus rapides et plus faciles à faire indexer, ce qui fait que commencer chaque projet avec lui semble être le choix le plus sûr. Cependant, un framework reste un outil ayant une fonction spécifique, et Next.js peut ajouter autant de friction à un projet inadapté qu’il en économise dans un projet adapté. Ce qui suit est une méthode pratique pour se décider : ce que Next.js résout réellement (SSR, SEO, rendu mixte), les cas où il est clairement avantageux, les situations courantes où React pur avec Vite convient mieux, ainsi que la façon de présenter ce choix à son équipe comme une exigence plutôt qu’une préférence.

Qu’ajoute réellement Next.js à React

En mettant de côté le marketing, Next.js concerne principalement la manière et le lieu où votre code React est rendu. Concrètement, il offre :

• Le rendu serveur (SSR), la génération statique en temps de compilation (SSG) ainsi que des combinaisons des deux, intégrés à React.
• Un routage basé sur des fichiers, où la structure des dossiers définit les URLs au lieu d’une table de routage manuscrite.
• Une couche backend légère incluse avec le frontend : des gestionnaires de routes API, du middleware et des fonctions edge, permettant à une même base de code de gérer une application full-stack.
• Une intégration étroite avec les plateformes d’hébergement modernes, en particulier Vercel, pour le cache, la livraison edge et le déploiement.

Cette liste se résume en une phrase à retenir pour le reste de la discussion : Next.js se distingue lorsque les performances de chargement initial, le SEO, ainsi que la capacité à regrouper les aspects frontend et backend sous un même framework sont vraiment importants pour le projet. Chacun des scénarios suivants constitue en réalité une validation de cette phrase.

Projets où Next.js est clairement avantageux

La visibilité dans les résultats de recherche et la première charge sont des exigences commerciales

Certains produits dépendent entièrement du trafic organique et des premières impressions :

• les sites de marketing et les pages de destination des produits
• les blogs riches en contenu et les portails de documentation
• les boutiques en ligne qui reposent sur les recherches

Pour ces cas, le rendu côté serveur et la génération statique ne sont pas des luxes. Le navigateur reçoit un HTML complet avant que tout JavaScript ne s’exécute, permettant ainsi aux utilisateurs de voir le contenu plus rapidement et aux outils de crawlage d’indexer du texte réel plutôt qu’un élément racine vide. Next.js vous permet également de pré-renderiser les pages avec leurs données, de gérer proprement les métatags par route, et d’utiliser la régénération statique incrémentale (ISR) pour mettre à jour le contenu sans devoir reconstruire l’ensemble du site chaque fois qu’il y a un changement. Il est possible de rassembler ces mêmes fonctionnalités autour d’une simple application single-page, mais cela est rarement aussi efficace.

Vous souhaitez un framework pour l’ensemble de la stack

Considérez des projets tels que :

• un produit SaaS de petite ou moyenne taille
• un tableau de bord alimenté par quelques points d’entrée authentifiés
• une application web typique où la même équipe gère le frontend et le backend

Next.js permet au code API et aux composants React de coexister dans le même projet. Vous pouvez écrire des gestionnaires de points d’entrée dans app/api (ou pages/api si vous utilisez l’ancien Pages Router), utiliser des middleware pour les vérifications d’authentification, la localisation et les redirections, puis déployer l’ensemble sur n’importe quelle plateforme prenant en charge Next.js, y compris Vercel mais pas uniquement.

Pour un développeur solo ou une petite équipe, cette consolidation est précieuse. Il n’y a pas de serveur Node ou Express séparé à configurer, ni de deuxième pipeline de déploiement à entretenir. La logique serveur se trouve à côté des composants qui l’utilisent, et le framework coordonne le routage et l’affichage entre eux.

Les zones publiques et privées nécessitent un affichage différent

De nombreuses applications se divisent naturellement en deux parties : des pages publiques largement statiques telles que la page d’accueil, les informations sur les prix et la documentation, ainsi que des zones dynamiques réservées aux utilisateurs connectés comme un tableau de bord ou une console d’administration. Next.js gère bien cette combinaison. Vous pouvez générer statiquement du contenu qui change rarement, afficher des pages personnalisées par utilisateur sur le serveur, et conserver des widgets très interactifs uniquement du côté client là où le rendu serveur apporte peu d’avantages. Le véritable avantage réside dans la possibilité de choisir la stratégie de rendu pour chaque route, ce qui vous permet d’optimiser les performances de chaque partie du produit sans devoir changer de framework ou gérer deux bases de code distinctes.

Projets où React pur est généralement plus adapté

Ces cas sont fréquents, et c’est précisément dans ces situations que les équipes ont tendance à recourir à Next.js par habitude.

Applications côté client que personne ne trouve via une recherche

Pensez aux opérations internes ou aux tableaux de bord analytiques, aux panneaux d’administration accessibles après connexion, ainsi qu’aux outils où chaque utilisateur accède directement à l’application plutôt qu’à travers un moteur de recherche. Dans ces produits, toutes les données sont chargées après le chargement de l’application ; un document HTML initial vide est donc sans importance, car les robots de recherche ne font pas partie de votre public cible. Les problèmes de performance importants sont ceux du côté client : gestion de l’état, chargement des données et efficacité de l’affichage.

Next.js intègre des fonctionnalités serveur que vous n’utiliserez pas, un environnement d’exécution serveur dont vous n’avez pas besoin, ainsi que des concepts supplémentaires liés au routage et au chargement des données. Une application React développée avec Vite, Parcel ou même une configuration simple de webpack est souvent plus rapide à mettre à jour et plus facile à comprendre pour tout le monde. Si vous souhaitez vous rafraîchir la mémoire sur ce que comporte une telle configuration, consultez notre guide pas à pas pour créer votre première application React avec Vite.

Une règle pratique : lorsque chaque écran important nécessite une authentification et que les utilisateurs y accèdent via une URL connue ou un shell d’application, Next.js est optionnel plutôt que nécessaire.

Widgets, bibliothèques de composants et outils embeddables

Parfois, le produit final n’est même pas un site web. Il peut s’agir d’un widget embeddable publié sur npm, d’un système de design partagé, ou d’une application à écran unique qui sera intégrée dans l’application d’un tiers. Ce que vous livrez, c’est une interface utilisateur réutilisable, et non des pages ; par conséquent, le routage, le SSR, le SSG ainsi qu’un organisation des dossiers prédéfinie résolvent des problèmes qui n’existent pas.

Une compilation légère avec React est ici le meilleur choix pour trois raisons. Vous pouvez le compiler et le publier sans devoir contourner les conventions du framework. Ceux qui utilisent votre package décident comment et où il s’affiche. De plus, vous évitez d’intégrer des hypothèses spécifiques à Next.js dans du code qui devrait fonctionner n’importe où. Si votre projet ne comporte pas de véritables pages, un framework organisé autour des pages est le mauvais point de départ.

Routage qui ne correspond pas à des dossiers

Le routage basé sur les fichiers est pratique pour de nombreuses applications, mais il reste une contrainte. La structure des URL est liée à la structure des dossiers, certains schémas avancés nécessitent des solutions de contournement, et un routage fortement axé sur les données peut paraître artificiel. Si votre application dispose de routes profondément imbriquées et hautement dynamiques, d’un modèle de navigation qui ne ressemble pas à un arbre de fichiers, ou de schémas URL inhabituels dictés par des règles métier, React associé à un routage programmatisé comme React Router pourrait être plus adapté. Définir les routes dans le code vous donne un contrôle total, au lieu de devoir adapter votre conception au schéma attendu du framework.

La question à se poser est de savoir si le routage basé sur les fichiers simplifie votre modèle mental ou s’il crée plutôt des difficultés. S’il crée des difficultés, React pur est probablement le choix le plus approprié.

Contenu principalement statique avec peu d’interactivité

Next.js peut générer des sites statiques, mais le résultat inclut néanmoins le runtime React ainsi que les coûts liés à l’hydratation. Pour des pages de marketing simples, des documents à faible niveau d’interactivité, des portfolios ou de petits sites de contenu, cela peut signifier l’envoi d’une quantité bien supérieure de JavaScript à celle nécessaire. Les outils de création de sites statiques tels qu’Astro, Eleventy ou Hugo, ou même du HTML et CSS écrits manuellement avec un peu de JavaScript lorsque c’est nécessaire, produisent généralement des fichiers plus légers et des déploiements plus simples.

En bref, si une page se comporte comme un document plutôt que comme une application, un meta-framework React représente plus de complexité que nécessaire.

Hébergement incapable d’exécuter du code serveur

Next.js est à son meilleur lorsque vous pouvez le déployer sur une plateforme qui exécute des fonctions Node ou serverless et que vous utilisez réellement SSR, des fonctions edge ou des routes API. Votre situation peut être différente : un hébergement uniquement statique comme GitHub Pages, Netlify en mode purement statique ou S3 derrière CloudFront ; une politique interdisant les processus Node à long terme ; ou un budget ne permettant pas de payer par invocation serverless.

Dans ce cas, une compilation React statique à l’aide d’un outil comme Vite est plus simple : générer les ressources, les télécharger, c’est tout. Next.js propose bien un mode d’exportation statique pour cette situation, mais il renonce alors aux fonctionnalités dépendantes d’un serveur telles que ISR, les middleware et les gestionnaires de routes qui nécessitent un serveur au moment de la demande ; vérifiez donc la documentation actuelle pour connaître précisément ce qui est pris en charge. Si vous utilisez Next.js sans jamais toucher à SSR, aux routes API ou aux middleware, vous l’utilisez principalement comme un bundler avancé.

L’expérience de l’équipe fait partie de la décision

La compatibilité technique n’est qu’une partie du tableau ; la maîtrise de l’équipe est également importante. Supposons que l’équipe soit à l’aise avec React côté client et les modèles à page unique, qu’elle ait peu d’expérience avec SSR, le streaming ou la récupération de données dans les composants serveur, et qu’elle doive livrer des fonctionnalités de produit plutôt que d’investir dans l’ingénierie de plateforme. Adopter Next.js signifie alors devoir s’adapter à :

• de nouveaux modèles de pensée, y compris les composants serveur, le chargement des données côté serveur et les conventions de routage
• une complexité opérationnelle liée aux cibles de déploiement, aux couches de mise en cache et au comportement aux extrémités du réseau
• plus d’éléments à vérifier en cas de problème de rendu ou d’hydratation

Cet investissement peut certainement en valoir la peine, mais c’est un coût réel. Pour un petit produit ou un outil interne, il est souvent préférable de rester avec une technologie que l’équipe maîtrise parfaitement plutôt que d’adopter quelque chose simplement parce qu’il semble plus moderne. Si vous envisagez les nouvelles fonctionnalités du framework, notre carte des fonctionnalités modernes de Next.js et de ce qu’elles remplacent est un bon moyen d’évaluer l’ampleur du travail à effectuer.

Checklist de décision pour de nouveaux projets

Résolvez ces questions au début de tout projet axé sur React :

1. Avez-vous besoin de SSR ou de SSG pour le SEO ou les performances au premier chargement ? Si oui, Next.js est un excellent choix ; sinon, React pur suffit amplement.
2. S’agit-il d’un site composé de pages réelles, ou principalement d’une coquille d’application ? De nombreuses pages de contenu renvoient vers Next.js ; une interface à coquille unique indique plutôt une application single-page React.
3. Souhaitez-vous un petit backend fonctionnant à côté du frontend ? Si les routes API et le middleware dans le même répertoire vous intéressent, Next.js convient. S’il existe déjà un backend dédié, que ce soit en NestJS, Spring Boot, Laravel ou un autre outil, l’ajout de Next.js est moins pertinent.
4. Où sera-t-il hébergé, et avec quel budget ? La capacité et la volonté de payer pour les processus serveur ou les appels de fonctions maintiennent Next.js comme option envisageable. Si seul l’hébergement statique est disponible, une version React légère est généralement plus adaptée.
5. Quelles sont les compétences actuelles de l’équipe ? Si tout le monde maîtrise bien React mais que seules quelques personnes comprennent SSR et les composants serveur, demandez si les exigences du projet justifient réellement cette courbe d’apprentissage.

Rien de tout cela ne force à adopter une position binaire. Vous n’êtes pas obligé d’utiliser exclusivement Next.js pour tout ou de l’exclure complètement. L’approche saine consiste à le considérer comme une option parmi les outils disponibles pour React, choisie délibérément lorsque ses avantages correspondent à vos besoins.

Présenter le choix à votre équipe

Si c’est vous qui prenez ou influencez cette décision, évitez de la formuler comme « Next.js est un excès », ce qui donne l’impression que c’est une question de goût. Préférez plutôt en souligner les compromis que l’équipe peut évaluer :

• « Ce tableau de bord interne tire peu parti du SSR ou du SEO, donc Next.js ajouterait des coûts supplémentaires sans avantage clair. »
• « La bibliothèque de composants ne contient ni pages ni routes, donc une configuration de build basique avec React convient mieux. »
• « Notre hébergement ne sert que des fichiers statiques, donc la plupart des fonctionnalités fortes de Next.js resteraient inutilisées. »
• « Nous utiliserons Next.js pour les produits publics à forte teneur en contenu où la performance et les recherches sont cruciales, et nous conserverons React pur pour les outils internes. »

De telles déclarations maintiennent la discussion axée sur les exigences plutôt que sur les tendances, et elles facilitent un réexamen de la décision en cas de changement de ces exigences.

Laissez les exigences choisir le framework

Le choix entre Next.js et React pur ne concerne pas savoir lequel est le plus moderne ; il s’agit plutôt de déterminer quelles sont les problématiques réelles de votre projet. Le rendu serveur, l’SEO, les stratégies de rendu par route et un backend situé au même endroit constituent de réels avantages lorsque vous en avez besoin, mais représentent un surcoût important en l’absence de ces besoins. Partez des exigences listées ci-dessus, tenez compte des contraintes d’hébergement et de l’expérience de votre équipe, et laissez le framework découler de ces réponses plutôt que l’inverse.

Lectures complémentaires

• Actions du serveur ou gestionnaires de route ? Un guide de décision pour Next.js 16 : Découvrez quand une mutation dans Next.js 16 doit être placée dans une action du serveur et quand elle nécessite un gestionnaire de route, avec des exemples corrigés pour les formulaires, les erreurs, l’optimisme et les webhooks.
• Séparer les couches domaine, données et UI dans un codebase Next.js App Router : Une étude de cas Pokédex montrant comment diviser une application Next.js App Router en couches domaine, données et présentation à l’aide de Prisma, Zod, d’authentification par cookies et de mise en cache.

L’état URL, l’état serveur et un BFF : une pile Vite pour les applications React internes : Pourquoi une plateforme React interne authentifiée peut être mieux servie par Vite, TanStack Router, TanStack Query et un BFF distinct que par Next.js, et quand cela cesse d’être vrai.