Quand la page dépend de qui la regarde

Le problème qu’il résout

Une interface React classique construit ses pages dans le navigateur. C’est confortable à écrire, et cela a deux défauts : la première page est lente à apparaître, et le référencement est très complexe, souvent impossible — une application de ce type convient à ce qui n’a pas besoin d’être indexé.

Next.js lève cette limite en construisant la page avant qu’elle arrive : soit à l’avance, soit sur le serveur au moment de la demande. Le visiteur reçoit une page complète, les moteurs aussi. On garde la richesse de React sans payer son principal inconvénient.

Trois modes, et il faut choisir

C’est la décision structurante du projet, et elle se prend page par page :

• Généré à l’avance — le contenu est connu au moment de la construction. Rien à calculer à la visite ; c’est le mode le plus rapide et le moins cher à héberger.
• Rendu à la demande — la page dépend de l’utilisateur connecté, d’un panier, d’une recherche. Elle est fabriquée par le serveur à chaque appel.
• Régénéré périodiquement — un intermédiaire : la page est statique, mais rafraîchie après un délai. Utile pour un contenu qui bouge sans être personnel.

Beaucoup de projets basculent tout en rendu à la demande par défaut, alors que l’essentiel de leurs pages serait identique pour tout le monde. Nous posons la question page par page — elle décide de la facture d’hébergement autant que de l’architecture.

Quand React s’impose vraiment

Trois situations, et il vaut mieux qu’au moins une soit vraie : une équipe qui connaît déjà React, une part applicative importante — formulaires complexes, états à tenir entre écrans, interactions nombreuses — ou un existant en React, bibliothèque de composants ou design system.

En dehors de ces cas, un site de contenu n’a pas besoin d’embarquer un framework applicatif complet. Sur une vitrine ou un site éditorial, Astro fait le même travail en envoyant beaucoup moins de code, et c’est ce que nous employons le plus souvent. Nous le disons y compris à ceux qui viennent chercher du Next.js.

La question de la plateforme

Next.js est développé par une société qui vend aussi son hébergement, et une partie de son confort vient de cette plateforme. C’est un point à connaître au moment de choisir : nous concevons les applications pour qu’elles tournent sur notre propre infrastructure, en France, ce qui suppose de remplacer explicitement quelques mécanismes — le cache des images, la régénération, le cache partagé entre instances.

Ce n’est pas un obstacle, c’est un travail à faire consciemment. Le bénéfice est double : vos données restent sous droit français et européen, et la facture dépend d’une machine plutôt que du nombre de visites.