React vs Next.js, quoi choisir et quand ?

La question revient sur la table dès qu'un projet web sort des cartons. Dans les discussions sur Discord, pendant les réunions de cadrage ou autour de la machine à café, le sujet fait toujours débat : « On part sur du React pur ou on met du Next.js tout de suite ? »

Le problème, c'est que l'opposition est bancale dès le départ. On compare une bibliothèque UI dédiée uniquement à l'affichage d'un côté, et un framework applicatif complet qui embarque tout le reste de l'autre.

Pourtant, ce choix de départ a des répercussions directes sur l'architecture du projet, les coûts d'hébergement, la vitesse d'affichage et l'effort d'infogérance au quotidien.

La liberté de React face au cadre de Next.js

Quand on initialise un projet avec React (souvent couplé à Vite aujourd'hui), la promesse est simple : de la modularité absolue. On récupère un moteur de rendu par composants et un Virtual DOM efficace. Pour le reste, c'est quartier libre.

C'est une excellente chose quand on veut garder la main sur chaque brique de son application. Mais cela signifie aussi qu'il faut assumer des choix d'architecture au quotidien : le routage est confié à une dépendance externe comme React Router ou TanStack Router, la récupération de données demande une gestion manuelle ou l'ajout d'outils type TanStack Query, et l'assemblage repose sur sa propre configuration de bundler.

Concrètement, la mise en place d'une simple navigation dans une application React pure ressemble à ça :

import { BrowserRouter, Routes, Route } from 'react-router-dom';
import Home from './pages/Home';
import Product from './pages/Product';

export default function App() {
  return (
    <BrowserRouter>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/produit/:id" element={<Product />} />
      </Routes>
    </BrowserRouter>
  );
}

À l'inverse, Next.js part du principe qu'un projet web de production retombe souvent sur les mêmes besoins. Le framework construit par Vercel impose donc une structure stricte mais ultra-complète : un système de fichier pour gérer les routes (App Router), une optimisation automatique des images ou des polices, et une gestion native des variables d'environnement.

Avec l'App Router de Next.js, plus besoin de déclarer un routeur central. L'arborescence des dossiers fait foi :

app/
├── layout.tsx         # Frame commune à toute l'application
├── page.tsx           # Route d'accueil /
└── produit/
    └── [id]/
        └── page.tsx   # Route dynamique /produit/123

React vous donne les pièces et la notice pour construire ce que vous voulez. Next.js vous livre la structure déjà assemblée, pré-câblée pour le serveur.

Le rendu : Single Page Application contre approche hybride

La vraie ligne de fracture entre les deux outils se situe sur le mode d'exécution du code et la façon dont les données sont récupérées.

Par défaut, une application React s'exécute côté client (Client-Side Rendering). Le serveur envoie un document HTML très léger, accompagné d'un fichier JavaScript plus ou moins volumineux. C'est le navigateur de l'utilisateur qui télécharge ce script, l'exécute et construit l'interface sous ses yeux.

Sur une page produit en React pure, la récupération de données se fait généralement dans un hook useEffect après le premier rendu :

import { useEffect, useState } from 'react';

export default function Product({ id }: { id: string }) {
  const [data, setData] = useState<any>(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch(`/api/products/${id}`)
      .then((res) => res.json())
      .then((data) => {
        setData(data);
        setLoading(false);
      });
  }, [id]);

  if (loading) return <p>Chargement du produit...</p>;
  return <h1>{data.name}</h1>;
}

Cette mécanique offre une navigation fluide une fois la page chargée, mais elle présente un défaut majeur : le navigateur doit effectuer un premier affichage vide, puis exécuter le script, puis faire la requête API, ce qui rallonge le First Contentful Paint.

Next.js casse ce schéma grâce aux React Server Components (RSC). Le composant s'exécute directement sur le serveur Node.js et peut interroger la base de données ou une API distante avant d'envoyer le HTML prêt à être affiché :

// app/produit/[id]/page.tsx - Next.js Server Component
async function getProduct(id: string) {
  const res = await fetch(`https://api.domaine.com/products/${id}`);
  return res.json();
}

export default async function ProductPage({ params }: { params: { id: string } }) {
  const product = await getProduct(params.id);

  return (
    <main>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
    </main>
  );
}

Les différentes stratégies de rendu dans Next.js

• Server-Side Rendering (SSR) : la page HTML est construite sur le serveur à chaque requête utilisateur. Idéal pour du contenu dynamique ou personnalisé.

• Static Site Generation (SSG) : les pages sont générées une fois pour toutes lors du build. Le résultat est distribué via un CDN pour des temps d'accès très bas.

• Incremental Static Regeneration (ISR) : vous mettez à jour des pages statiques en arrière-plan à intervalles réguliers sans ré-exécuter un build complet.

• React Server Components (RSC) : les composants s'exécutent uniquement sur le serveur, ce qui permet de réduire drastiquement la taille du JavaScript envoyé au navigateur.

Bilan comparatif : React vs Next.js

Référencement naturel et métriques de performance

Pour les robots d'indexation comme Googlebot, la différence de rendu a un impact direct sur le SEO.

Même si les crawlers savent exécuter du JavaScript, l'indexation d'une Single Page Application en React pur demande plus de ressources et subit parfois des retards. À l'inverse, en recevant un HTML déjà complet depuis un serveur Next.js, les moteurs de recherche lisent directement le contenu, les balises de structure et les métadonnées sans ambiguïté.

Au-delà de l'indexation, l'impact se mesure sur les Core Web Vitals. Next.js embarque des composants sur-mesure pour bloquer les dérives de performance courantes :

next/image gère le redimensionnement à la volée, le lazy loading et la conversion vers des formats modernes (WebP, AVIF) pour éviter le décalage de mise en page (CLS).

next/font télécharge et auto-héberge les polices au moment du build pour supprimer les requêtes réseau externes qui ralentissent le rendu.

Faire le bon choix pour son projet

Pour faire un choix logique, il faut regarder le type de produit qu'on développe plutôt que de céder à la tendance. Si le site nécessite du SEO public ou un premier chargement rapide, alors NextJS est tout désigné. Sinon, on aura tendence à préférer React.

Quand choisir React seul ?

React associé à Vite reste un excellent choix quand le référencement naturel n'a aucune importance. C'est le cas typique des outils internes, des tableaux de bord d'administration, des applications SaaS accessibles uniquement après connexion ou des prototypes rapides.

Dans ces contextes, conserver une architecture 100 % client évite d'avoir à gérer un serveur Node.js en production, simplifie le déploiement sur un hébergement statique simple (S3, Cloudflare Pages) et offre une isolation parfaite de la logique front-end.

Quand basculer sur Next.js ?

Dès que le projet s'adresse au grand public ou qu'il doit générer du trafic organique, Next.js s'impose naturellement. C'est la solution adaptée pour les sites vitrines, les plateformes e-commerce, les blogs, les médias ou les marketplaces.

Le gain de temps sur l'outillage (routage, SEO, optimisation d'assets) compensera largement la courbe d'apprentissage liée à la séparation entre Server Components et Client Components.