React ou Next.js pour un site vitrine

La question arrive presque toujours déjà tranchée. Quelqu’un a lu que Next.js est meilleur pour le référencement, ou que React est plus simple, et cherche une confirmation. Ces deux formulations passent à côté de ce qui décide réellement : ce que contient le HTML avant qu’un seul script ne s’exécute.

Pour un site vitrine produit — une page d’accueil, quelques pages produit, des études de cas, un formulaire de contact — c’est toute la décision. Le reste relève de la préférence.

La différence, concrètement

React est une bibliothèque pour construire des interfaces. Elle ne décide pas de la façon dont vos pages sont livrées. Next.js est un framework bâti sur React qui, lui, le décide : rendu côté serveur, génération de pages statiques au build, routage depuis le système de fichiers, et du code serveur dans le même projet.

La comparaison n’oppose donc pas vraiment React à Next.js. Une application React seule est presque toujours une application monopage : le serveur envoie un fichier HTML quasi vide, le navigateur télécharge un bundle JavaScript, et ce bundle construit chaque page. La vraie comparaison se joue entre ce modèle et celui où chaque page existe déjà sous forme de HTML.

La question qui tranche

Demandez-vous ce qui doit être vrai de vos pages, dans cet ordre :

1. 01Le contenu change-t-il à chaque requête ? Tarifs personnalisés, état connecté, stock par région, tout ce qui vient d’une base de données au moment de l’affichage. Si oui, il vous faut du rendu serveur, et Next.js est le chemin le plus court.
2. 02Le contenu change-t-il souvent, depuis un CMS, sans redéploiement ? Si des rédacteurs publient à leur propre rythme, il vous faut un framework avec régénération incrémentale plutôt qu’une étape de build que quelqu’un doit déclencher.
3. 03Y a-t-il du travail côté serveur dans le même projet ? Authentification, webhooks, retours de paiement, une API qui n’a pas à vivre dans un service séparé. Next.js vous donne ces routes dans le même dépôt.
4. 04Le site est-il un ensemble fixe de pages qui changent quand vous déployez ? Alors les pages peuvent simplement être générées au build — et l’outil qui s’en charge importe bien moins que le fait que cela ait lieu.

Pour la plupart des sites vitrines, la réponse honnête est la quatrième. Douze pages, mises à jour quand l’équipe les met à jour, aucun contenu par visiteur. Cela ne demande pas un serveur qui rend à la demande. Cela demande que les pages existent.

L’option qu’on oublie

Une application React monopage peut produire du vrai HTML pour chaque route au moment du build, sans adopter de framework. On rend chaque route en chaîne de caractères pendant la compilation et on l’écrit dans un fichier. Le résultat : une page statique par URL, lisible par n’importe quel client, l’application reprenant la main dans le navigateur.

Ce site fonctionne ainsi. Il est en React et Vite, et chaque route est rendue en HTML au build. Si nous le mentionnons, c’est parce que c’est l’option absente du débat : on présente le choix comme « rester vide ou migrer », alors que générer les pages relève d’un changement d’étape de build, pas d’un changement d’architecture.

Ce que cela coûte mérite d’être dit clairement. Il n’y a pas de serveur, donc tout ce qui dépend de la requête est exclu. Ajouter une page suppose que le build en soit informé. Et comme l’application se rend à nouveau dans le navigateur au lieu de reprendre le rendu généré, ce HTML s’adresse aux clients qui ne peuvent pas exécuter l’application — il ne rend pas l’application elle-même plus rapide à démarrer.

Quand Next.js se justifie clairement

• Le site vitrine et le produit partagent le même dépôt. Partager composants, types et design system entre les deux vaut plus que n’importe quelle fonctionnalité de rendu prise isolément.
• Des personnes non techniques publient. Un CMS avec régénération signifie qu’un rédacteur appuie sur publier et la page se met à jour. Un build statique signifie un déploiement.
• Il y a du vrai travail serveur. Authentification, sessions, webhooks, tout ce qui détient un secret.
• Le nombre de pages est élevé, ou généré depuis des données. Des centaines de pages programmatiques sont un problème de routage, que le routage par fichiers et le rendu serveur résolvent directement.

Parmi les études de cas présentées ici, Lowkar est celle construite avec React et Next.js — une place de marché, où les annonces viennent de données et où l’ensemble des pages n’est pas quelque chose que l’on écrit à la main. C’est exactement la forme de problème pour laquelle ce framework existe.

Quand il ne se justifie pas

Si le site est un ensemble fixe de pages, adopter un framework pour résoudre un problème de HTML revient à endosser son modèle de rendu, ses règles de cache, ses conventions de récupération de données et son rythme de mises à jour. C’est un échange raisonnable quand vous avez besoin de ce qu’il apporte. C’en est un mauvais quand votre besoin était que les pages existent, ce qu’une étape de build suffit à faire.

Le cas d’échec qui mérite d’être nommé est la position intermédiaire : un site Next.js entièrement composé de composants côté client, qui embarque le framework et sert malgré tout un document vide. Cela arrive souvent, et c’est le pire des deux mondes — plus de machinerie, même problème.

Comment vérifier ce que votre site sert réellement

Avant toute décision, regardez ce que reçoit un client incapable d’exécuter du JavaScript. Récupérez votre propre page et lisez la réponse :

• Lancez curl -s https://votresite.com | wc -c pour voir la taille du document lui-même.
• Cherchez vos titres dans cette réponse. S’il n’y a pas de h1, rien de ce qui ignore le JavaScript ne peut savoir de quoi parle la page.
• Vérifiez la présence d’une balise canonique. Dans une application monopage, elle est souvent posée à l’exécution — donc absente précisément pour les clients qui en ont le plus besoin.
• Collez l’URL dans une messagerie. L’aperçu généré est un test en direct de ce que reçoivent les clients qui ne rendent rien.

Faites cela d’abord. Si le document contient déjà votre contenu, la question du framework est une question de préférence, et vous pouvez la trancher selon ce que votre équipe maîtrise. S’il revient vide, vous avez trouvé ce qu’il faut corriger — et cela n’exige peut-être aucun changement de framework.

Si vous voulez un deuxième avis sur ce dont votre site a besoin, écrivez-nous.