nextjs.org

Next.js est un framework React destiné à la création d’applications web full-stack. React fournit le modèle de composants pour les interfaces utilisateur ; Next.js ajoute le routage, le rendu, des conventions d’accès aux données, des capacités serveur, la compilation, la création de bundles, la mise en cache et des outils orientés production.

Le sujet principal est le framework, et non son domaine. nextjs.org est le site officiel où les visiteurs peuvent trouver une documentation maintenue, des guides, des liens vers la communauté et des informations sur le projet.

Next.js est particulièrement pertinent lorsqu’une équipe souhaite développer avec React tout en prenant en charge davantage qu’une interface limitée au navigateur. Un même projet peut contenir des pages pré-rendues, des réponses générées au moment des requêtes, un accès aux données côté serveur, des points de terminaison de type API et des composants interactifs exécutés dans le navigateur.

Ce que Next.js ajoute à React

React aide les développeurs à décrire les interfaces sous forme de composants, mais ne prescrit pas une architecture d’application complète. Next.js fournit des conventions pour associer les fichiers aux routes, décider où le code s’exécute, charger les données, produire les réponses et préparer une application au déploiement.

Sa valeur dépasse donc le rendu côté serveur. Une application Next.js peut utiliser plusieurs méthodes de rendu et de diffusion, parfois au sein du même projet. Le framework coordonne ces méthodes autour de React au lieu d’imposer un modèle unique à toutes les routes.

Voici un résumé utile de cette répartition :

• React définit les composants, l’état, les props et la composition de l’interface.
• Next.js définit les routes, les mises en page, les choix de rendu, les points d’entrée serveur et le comportement de la compilation.
• L’application définit ses règles de données, ses frontières client, sa politique de cache et ses exigences de déploiement.
• L’environnement d’hébergement détermine les fonctionnalités d’exécution disponibles et leur fonctionnement.

Cette séparation est importante lorsque l’on compare Next.js à une application cliente React, à un générateur de sites statiques ou à un autre framework web. Le framework propose un large éventail de capacités, mais un projet ne bénéficie que de celles qu’il utilise correctement.

Composants serveur et client

Dans l’App Router, les mises en page et les pages sont des Server Components par défaut. Les Server Components s’exécutent dans un environnement serveur et peuvent effectuer des opérations sur les données côté serveur sans envoyer leur implémentation au navigateur.

Les Client Components sont utilisés lorsqu’une partie de l’interface nécessite un état dans le navigateur, des gestionnaires d’événements, des effets ou des API disponibles uniquement dans le navigateur. Les développeurs définissent une frontière client à l’aide de la directive use client, et les composants situés sous cette frontière intègrent le graphe de modules côté client.

Question	Server Component	Client Component
Où sa logique de composant s’exécute-t-elle ?	Dans l’environnement de rendu serveur	Dans le navigateur après son inclusion dans le bundle client
Peut-il utiliser un état du navigateur ou des gestionnaires de clics ?	Non	Oui
Peut-il utiliser directement des API réservées au navigateur ?	Non	Oui
Son code de composant est-il envoyé au navigateur ?	Pas en tant que code de composant client	Oui
Rôle habituel	Contenu alimenté par des données, mises en page et composition côté serveur	Formulaires, menus, éditeurs, filtres et autres commandes interactives

Une route n’est pas obligée de choisir exclusivement un type. Un Server Component peut afficher du contenu et intégrer certains Client Components pour les parties interactives de la page. Cela permet aux équipes de placer du JavaScript destiné au navigateur autour de besoins précis au lieu de traiter toute la route comme une application cliente.

Cette frontière exige néanmoins de la prudence. Placer un vaste sous-arbre de composants derrière use client peut envoyer davantage de JavaScript au navigateur, tandis que diviser chaque petite commande en une frontière distincte peut rendre le code plus difficile à comprendre. Il convient de mesurer des pages représentatives plutôt que de les juger uniquement d’après l’étiquette du framework.

Les Server Components se distinguent également de la stratégie de diffusion d’une route. Un Server Component peut contribuer à une sortie pré-rendue ou participer à un rendu dynamique. Qualifier un composant de côté serveur n’indique pas à lui seul si la route est générée pendant la compilation, actualisée ultérieurement ou produite pour chaque requête.

App Router et Pages Router

Next.js documente actuellement deux systèmes de routage. L’App Router est le système le plus récent et intègre des fonctionnalités React telles que les Server Components. Le Pages Router est l’ancien système et reste pris en charge.

Domaine	App Router	Pages Router
Structure principale des routes	Le répertoire app	Le répertoire pages
Modèle de composants par défaut	Les mises en page et les pages sont des Server Components	Utilise l’ancien modèle de pages de Next.js
Interface partagée	Les mises en page imbriquées constituent une convention centrale	Généralement composée à l’aide de modèles d’application et de page
Meilleur point de départ	Nouveaux projets adoptant l’architecture actuelle	Applications existantes ou dépendances construites autour des API du Pages Router

Une migration ne consiste pas simplement à renommer des dossiers. Le code de l’App Router introduit un modèle de composants privilégiant le serveur et des modèles différents pour les mises en page, l’accès aux données, les états de chargement et le comportement des routes. Les équipes devraient identifier ces changements conceptuels avant de convertir une application mature.

Les nouveaux projets devraient généralement commencer par étudier la documentation de l’App Router, car elle explique le modèle actuel du framework. Les applications existantes utilisant le Pages Router devraient évaluer une migration en fonction des avantages réels, des dépendances, de l’effort de test et du coût de maintenance, plutôt que de considérer la poursuite de sa prise en charge comme un défaut.

La documentation et les exemples peuvent ne cibler qu’un seul routeur. Avant de copier une implémentation, les développeurs devraient vérifier quel routeur elle utilise et si les API citées s’appliquent à leur projet.

Rendu, mise en cache et revalidation

Next.js ne rend pas toutes les pages de la même manière. Une route peut être préparée avant l’arrivée d’un visiteur, générée à l’aide d’informations propres à la requête, mise en cache ou actualisée conformément à une politique de revalidation.

Besoin de la route	Approche de diffusion probable	Question à vérifier
Les entrées sont connues à l’avance	Sortie pré-rendue	Quel événement devrait entraîner la modification de la sortie ?
La sortie dépend de cookies, d’en-têtes ou de données de requête	Rendu dynamique	Une partie du traitement peut-elle tout de même être mise en cache en toute sécurité ?
Le contenu change selon un calendrier contrôlé	Sortie mise en cache avec revalidation	Jusqu’à quel point la réponse peut-elle être obsolète ?
Aucune fonctionnalité réservée au serveur n’est requise	L’exportation statique peut convenir	Toutes les routes et ressources sont-elles compatibles avec les limites de l’exportation ?

La mise en cache n’est pas un simple interrupteur qui peut être compris indépendamment de l’accès aux données. Les équipes doivent savoir quelles opérations sont mises en cache, quelles routes deviennent dynamiques et comment se produisent l’invalidation ou la revalidation. Ces règles devraient être testées avec des modifications de contenu réalistes.

Cela est particulièrement important pour les pages authentifiées, les prix, les stocks, les tableaux de bord et les autres informations soumises à des exigences explicites d’actualisation. Fournir une sortie mise en cache peut être utile, mais uniquement lorsque les règles d’exactitude de l’application le permettent.

Les performances et la visibilité dans les moteurs de recherche ne devraient pas être déduites de la seule étiquette du rendu. Le pré-rendu peut réduire le travail au moment de la requête, et le rendu serveur peut fournir un HTML initial significatif, mais les résultats réels dépendent de la structure de la page, des ressources, de la latence des données, du JavaScript exécuté dans le navigateur, de la mise en cache et du comportement du déploiement.

Exportation statique et exigences d’exécution

Next.js peut générer une exportation statique lorsque le projet ne dépend pas de fonctionnalités du framework réservées au serveur. Les fichiers HTML, CSS, JavaScript et les ressources qui en résultent peuvent être servis par une infrastructure prenant en charge des fichiers statiques ordinaires.

La sortie statique peut tout de même inclure des Client Components. La diffusion statique décrit la manière dont le résultat compilé est hébergé ; elle ne signifie pas que toutes les interfaces doivent être non interactives. Le code côté navigateur peut toujours fournir un état, des événements et d’autres comportements clients.

Avant de choisir l’exportation statique, vérifiez que le projet ne nécessite pas :

• Des réponses générées à partir de données serveur propres à chaque requête.
• Un comportement des routes dépendant d’un environnement d’exécution Next.js actif.
• Des fonctionnalités non prises en charge concernant les images, le routage ou le serveur.
• Des règles d’actualisation qui ne peuvent pas être respectées par une nouvelle compilation ou un autre processus de mise à jour pris en charge.
• Des points de terminaison serveur devant s’exécuter aux côtés de l’application.

Lorsque ces capacités sont requises, l’application a besoin d’un environnement d’exécution compatible. Cela n’impose pas un déploiement sur Vercel : le guide de déploiement officiel documente l’auto-hébergement et les adaptateurs de plateformes. La prise en charge varie selon les plateformes ; la compatibilité devrait donc être vérifiée en fonction des fonctionnalités particulières utilisées.

Route Handlers et points de terminaison côté serveur

Dans l’App Router, les Route Handlers permettent à une application de définir des gestionnaires de requêtes HTTP à l’aide des concepts standard de requête et de réponse. Ils sont utiles pour les points de terminaison qui doivent accompagner l’application, notamment le traitement des formulaires, les webhooks, les réponses de données ou les rappels d’intégration.

Un Route Handler n’est pas automatiquement l’emplacement approprié pour tous les systèmes backend. Les équipes doivent toujours décider de la manière dont sont gérés l’authentification, l’autorisation, la validation, la limitation du débit, les tâches durables et le traitement des erreurs. Il peut être préférable de séparer de l’application web les services de longue durée ou mis à l’échelle indépendamment.

Une évaluation pratique pose les questions suivantes :

1. Le point de terminaison doit-il accéder au code de l’application ou à des types partagés ?
2. Nécessite-t-il des secrets disponibles au moment de la requête ou des dépendances réservées au serveur ?
3. Le déploiement cible peut-il exécuter le gestionnaire comme indiqué dans la documentation ?
4. Quel comportement de mise en cache convient à chaque méthode HTTP et à chaque réponse ?
5. Un service distinct offrirait-il une propriété ou une mise à l’échelle plus claires ?

Les Route Handlers facilitent la composition full-stack, mais cette commodité ne supprime pas les responsabilités habituelles en matière de conception et de sécurité des API.

Les cas où Next.js constitue un choix pratique

Next.js est un candidat solide pour les équipes déjà à l’aise avec React qui ont besoin de capacités de routage d’application et de serveur dans la même base de code. Il peut également convenir aux produits dont les différentes routes présentent des besoins de diffusion sensiblement différents.

Les cas courants comprennent :

• Les espaces de compte et tableaux de bord combinant données serveur et commandes interactives.
• Les expériences commerciales ou les catalogues mêlant contenu stable et informations dépendant des requêtes.
• Les sites de documentation ou de marketing qui contiennent également des parcours applicatifs.
• Les produits qui ont besoin de réunir des réponses HTML, des interactions client et des points de terminaison serveur.
• Les applications React dont les routes bénéficient de politiques distinctes de mise en cache et de rendu.

Le framework peut représenter plus de mécanismes que n’en exige un simple site de contenu. Une équipe publiant principalement des articles statiques devrait comparer ses besoins avec des outils centrés sur la diffusion de contenu, surtout si seule une petite partie du site nécessite une interaction React.

Next.js peut également être un mauvais choix lorsque l’équipe ne peut pas répondre à ses exigences d’exécution, ne souhaite pas adopter des concepts de rendu propres au framework ou aurait du mal à maintenir des frontières claires entre serveur et client. La flexibilité n’a de valeur que si l’architecture reste compréhensible.

Comparaison de Next.js avec Astro et d’autres options

Next.js et Astro sont souvent évalués pour des projets qui combinent contenu et éléments interactifs, mais leurs comportements par défaut et leurs modèles mentaux diffèrent. Le choix approprié dépend des routes réelles, et non d’une affirmation générale selon laquelle un framework serait plus rapide ou meilleur.

Pour effectuer une comparaison utile, créez la même page représentative avec chaque candidat et consignez :

• La quantité de JavaScript qui parvient au navigateur avant et après l’interaction.
• La manière dont les données sont chargées et dont leur actualisation est contrôlée.
• La nécessité éventuelle de fonctionnalités d’exécution serveur.
• La manière dont le routage, les mises en page, les formulaires et les états d’erreur sont implémentés.
• La prise en charge par l’hébergeur cible de toutes les fonctionnalités requises.
• La facilité avec laquelle l’équipe peut tester et expliquer l’architecture obtenue.

Astro mérite une attention particulière pour les sites axés sur le contenu, où la majorité de la sortie peut rester statique et les îlots interactifs sont limités. Next.js devient plus convaincant lorsque React constitue le modèle central de l’application et que les fonctionnalités serveur et client doivent être combinées dans l’ensemble du produit.

Aucune de ces comparaisons ne prédit un score de performance. Les images, les polices, les scripts tiers, les choix de composants, la latence des données et les frontières client peuvent peser davantage que les comportements par défaut du framework.

Origines, gouvernance et communauté

La page officielle consacrée à la gouvernance indique que l’équipe de Vercel a créé Next.js en 2016. Elle précise également que l’équipe principale de Vercel dirige la recherche et le développement du projet. Il s’agit d’une déclaration concernant l’origine et la gouvernance au niveau de l’équipe ; elle ne devrait pas être remplacée par une affirmation non étayée au sujet d’un fondateur individuel.

D’après les pages de gouvernance et de documentation disponibles le 27 août 2026, les moyens publics de participer au projet comprennent :

• Le dépôt GitHub officiel pour le code source, les problèmes et l’activité du projet.
• GitHub Discussions pour les questions et les discussions communautaires sur les RFC.
• Le Discord de Next.js pour bénéficier gratuitement de l’aide de la communauté.
• Une documentation maintenue pour l’App Router et le Pages Router.

Ces canaux fournissent différents types d’aide. La documentation devrait être la première référence concernant le comportement du framework, Discussions peut faire émerger des propositions et des questions communes, et Discord peut favoriser les échanges communautaires. Aucun d’eux ne remplace les tests propres au projet ni le processus d’assistance en production d’une équipe.

Liste de contrôle pour la décision

Avant d’adopter Next.js, les équipes devraient répondre à ces questions à l’aide d’un prototype fonctionnel :

• Quelles routes sont statiques, dynamiques, mises en cache ou revalidées ?
• Quels composants nécessitent réellement un état, des effets, des événements ou des API du navigateur ?
• Quelle quantité de JavaScript client chaque route représentative transmet-elle ?
• Quels points de terminaison doivent se trouver dans des Route Handlers, et lesquels doivent être placés ailleurs ?
• La plateforme cible peut-elle exécuter toutes les fonctionnalités Next.js requises ?
• Comment l’actualisation du cache, les défaillances, les journaux et les déploiements seront-ils gérés ?
• L’équipe comprend-elle les différences entre le routeur qu’elle a choisi et les exemples écrits pour l’autre routeur ?

Next.js permet d’appliquer React à une application web complète tout en choisissant délibérément où le travail s’effectue et comment chaque route est diffusée. La flexibilité décrite dans sa documentation est considérable, mais elle ne garantit ni les performances, ni les résultats dans les moteurs de recherche, ni de faibles coûts d’exploitation, ni la simplicité architecturale. Ces résultats doivent être établis par l’implémentation et la mesure.