Quand utiliser Next.js pour un site professionnel

Next.js résout un petit nombre de problèmes réels remarquablement bien, et il paye cela par une complexité opérationnelle que tous les projets n’ont pas besoin d’assumer. La meilleure manière d’y penser est de séparer ce que le framework fait vraiment bien de ce qu’on espère parfois qu’il fasse à votre place.

Next.js est bon sur : le rendu serveur React avec une faible latence pour l’utilisateur ; le SEO sur du contenu qui dépend de données dynamiques ; le mélange de contenu statique (pages marketing, blog) et de fonctionnalités dynamiques (un tableau de bord connecté, une interface de recherche) dans un seul codebase ; l’optimisation d’images et de polices qui demanderait sinon un pipeline séparé ; et la régénération statique incrémentale pour du contenu qui change sur son propre rythme plutôt qu’à chaque requête.

Next.js n’est pas particulièrement bon pour : remplacer un CMS pour des éditeurs non techniques qui préféreraient ne pas toucher à un déploiement ; servir de version « moderne » de WordPress pour un site vitrine à faible trafic ; ou être le chemin le moins cher vers un petit site dont le contenu ne change presque jamais. Dans ces trois cas, le bon outil est généralement autre chose, et choisir Next.js malgré tout achète de la complexité sans acheter de capacité.

Cet article est la version pratique de cette décision. Il s’associe à l’article Next.js vs Laravel pour la conversation d’architecture full-stack ; ici, l’angle est plus étroit : à quel moment un site web professionnel est réellement un bon candidat pour Next.js.

Trois formes de projet font systématiquement de Next.js un choix justifié plutôt qu’un choix de mode.

La première, c’est le hub de contenu avec personnalisation ou filtrage dynamiques. Un site dont les pages doivent s’afficher rapidement pour le SEO, mais dont le contenu est filtré, trié ou partiellement personnalisé selon le visiteur (localisation, langue, segment, paramètres d’URL). C’est exactement ce pour quoi Next.js a été conçu : rendre la page côté serveur une fois avec le bon contexte, l’envoyer à l’utilisateur, et garder un bundle léger.

La deuxième, c’est le site marketing multilingue avec de vraies exigences SEO. Plusieurs locales, hreflang correctement posé, pages rendues côté serveur qui ressemblent à la même chose pour un utilisateur et pour un crawler, premier rendu rapide sur une connexion 3G. Un générateur de site statique peut faire la plupart de cela ; Next.js le fait avec moins de plomberie sur mesure dès qu’on dépasse quelques dizaines de pages ou que le contenu dépend de données.

La troisième, c’est le codebase site-et-application hybride. Un site marketing public, un blog, un espace client connecté, un outil d’administration, tous partageant des composants et un design system. Découper cela en un CMS plus une application React séparée plus un générateur statique est faisable, mais cela triple la surface de maintenance. Next.js permet à la même équipe de livrer les mêmes composants sur l’ensemble.

Dans les trois cas, le coût du modèle opérationnel Next.js (hébergement Node ou plateforme type Vercel, pipeline de build, processus de déploiement plus élaboré qu’un upload de fichiers) est justifié par ce que le projet a réellement besoin de faire.

À l’inverse, trois formes font systématiquement de Next.js le mauvais outil, même quand l’équipe préférerait l’utiliser.

Un site vitrine à faible trafic de moins de vingt pages avec un contenu qui change peu et aucune fonctionnalité dynamique. Un générateur de site statique (Astro, Eleventy, Hugo) déployé en fichiers plats derrière un CDN fait le travail pour une fraction du coût opérationnel, et reste maintenable trivialement pendant des années. Ici, Next.js achète surtout un déploiement plus complexe.

Un site éditorial dont les éditeurs sont non techniques et ont besoin d’un vrai CMS (WordPress, Webflow, Sanity studio avec un éditeur familier). La bonne réponse est le CMS, avec la couche de rendu que l’équipe peut tenir. Forcer un front Next.js par-dessus, quand l’équipe n’a pas d’ingénieur React en interne, crée une dépendance de maintenance qui survivra au développeur d’origine.

Un prototype ou une expérimentation qui ne survivra peut-être pas à son premier trimestre. Next.js récompense l’investissement dans une architecture propre, une bonne stratégie de cache, un routage réfléchi. Un prototype jetable justifie rarement ce travail ; un outil no-code ou une page PHP en un seul fichier fait souvent le même travail en un après-midi.

Le motif est le même dans les trois cas : la forme du projet ne justifie pas le poids opérationnel de Next.js. Le choisir quand même est la manière dont l’équipe finit par maintenir un pipeline de build pour un site qui n’en avait pas besoin.

Quand la réponse n’est pas évidente d’après la forme du projet, quatre questions tranchent généralement.

La première : que faut-il que la page sache au moment du rendu, et d’où vient cette information. Si la plupart des pages peuvent être construites une fois au déploiement et mises en cache, un générateur statique suffit. Si les pages ont besoin de données fraîches par requête (état connecté, contenu personnalisé, résultats de recherche), le modèle de rendu serveur que donne Next.js commence à gagner sa place.

La deuxième : quelle est l’importance du SEO sur du contenu dynamique. Le SEO sur des pages statiques est résolu par tout ce qui produit du HTML propre. Le SEO sur des pages dont le contenu dépend de données (catalogues filtrables, contenu multilingue, pages localisées) est réellement plus difficile, et Next.js le rend abordable d’une manière qu’un React purement client ne fait pas.

La troisième : que va maintenir l’équipe dans deux ans. Une équipe qui fait déjà tourner du Node et du React en production absorbera Next.js facilement. Une équipe dont la seule expérience web est WordPress et HTML ne le fera probablement pas, peu importe à quel point le framework a l’air d’être la bonne réponse sur le papier. Les décisions d’architecture qui ignorent qui les maintient vieillissent mal.

La quatrième : quelle est l’histoire de déploiement. Next.js veut un runtime Node ou une plateforme serverless avec un pipeline d’images et de polices sensé. Si l’équipe ops de l’organisation ne supporte que de l’hébergement statique sur un CDN, cette contrainte exclut Next.js ou pousse le projet vers une plateforme managée que l’équipe ops n’a pas signé pour supporter. Les deux ont un vrai coût ; faire comme si ce n’était pas le cas est la manière dont les surprises arrivent au lancement.

Choisir Next.js, c’est choisir un modèle opérationnel précis. Le pipeline de build est plus élaboré que pour un site statique. L’hébergement est soit une plateforme managée (Vercel et équivalents), soit une infrastructure Node que l’équipe doit opérer. Le framework évolue vite, avec des changements cassants entre versions majeures que l’équipe doit suivre. Les pipelines d’images, de polices et d’assets sont configurables et puissants, ce qui veut aussi dire qu’ils ne sont pas triviaux à régler.

Aucun de ces points n’est rédhibitoire. Ce sont les coûts de la capacité. L’erreur, c’est de les ignorer au moment de la décision et de les découvrir au moment de la maintenance, surtout dans les organisations où l’équipe qui construit le site n’est pas celle qui le fera tourner pendant les cinq prochaines années.

Un test utile avant de s’engager : nommez la personne ou l’équipe qui sera d’astreinte sur le site en production, sur le pipeline de build et sur la plateforme d’hébergement dans deux ans. Si la réponse est « on verra », Next.js n’est probablement pas encore le bon choix.

Next.js est le bon outil pour les sites professionnels qui combinent du vrai contenu, un vrai SEO, et soit de la vraie interactivité, soit de la vraie personnalisation. C’est le mauvais outil, même quand il est à la mode, pour les vitrines à faible trafic, les sites éditoriaux purement CMS, et les expérimentations à courte durée de vie. La décision n’est presque jamais sur Next.js lui-même ; elle porte sur la capacité de la forme du projet et de l’équipe à porter le modèle opérationnel qui vient avec.

Le contexte plus large, dont la comparaison transverse avec d’autres choix d’architecture, est rassemblé dans le cluster architecture web et plateformes. Et lorsque la question passe de « Next.js est-il le bon outil » à « oui il l’est, et il nous faut maintenant quelqu’un pour le livrer correctement, avec le bon déploiement, le bon SEO et un codebase maintenable », c’est exactement ce sur quoi mon accompagnement développement d’applications web est centré.