Les React Server Components ont mis du temps à convaincre. En 2026, après un an de Next.js 15 stable et de patterns consolidés, je peux enfin dire : oui, ça marche, et oui, ça vaut le coup. Avec des nuances.

Ce qui change vraiment

Un Server Component s'exécute côté serveur, envoie du HTML + un payload RSC au client, et n'inclut aucun JS lui-même côté navigateur. Conséquences :

  • Bundle JS radicalement plus petit (parfois 50-70 % de réduction).
  • Accès direct à la DB ou aux APIs internes sans ping-pong réseau.
  • Pas besoin de fetch en useEffect, pas de skeleton loading sur l'initial render.

Ce que les devs adorent

Composer directement avec l'ORM ou la DB :

// app/posts/page.tsx (Server Component)
export default async function PostsPage() {
  const posts = await db.post.findMany({ where: { published: true } });
  return (
    <main>
      {posts.map(p => <PostCard key={p.id} post={p} />)}
    </main>
  );
}

Pas d'API à créer, pas de cache de fetch, pas de serialisation manuelle. Juste du JSX qui tourne sur le serveur.

Ce qui coince encore

  • Frontière client/serveur mentale : il faut apprendre où mettre 'use client' et pourquoi. Source #1 de bugs chez les débutants.
  • Bibliothèques non compatibles : beaucoup d'anciennes libs supposent du client, cassent en RSC. Check avant d'adopter.
  • Passage de callbacks serveur → client : subtil, nécessite Server Actions.
  • Débogage : les erreurs côté serveur remontent moins bien que les erreurs client. Toujours un stack trace à déchiffrer.

Server Actions : la vraie killer feature

Pouvoir définir une fonction serveur et l'appeler directement depuis un composant client supprime 80 % du boilerplate d'API routes :

'use server';
export async function createPost(formData: FormData) {
  const title = formData.get('title');
  await db.post.create({ data: { title } });
  revalidatePath('/posts');
}

// Dans un composant client :
<form action={createPost}>
  <input name="title" />
  <button>Créer</button>
</form>

Progressive enhancement gratuit : le formulaire marche même sans JS. Impossible en SPA classique.

Les frameworks qui supportent RSC en 2026

Quand NE PAS utiliser RSC

  • App extrêmement interactive (éditeur collaboratif, dashboard temps-réel).
  • App mobile (React Native n'a pas RSC).
  • Équipe pas prête à comprendre la dichotomie serveur/client.
  • Projet existant avec énormément de client-only logic.

Pour un site e-commerce, un blog, un dashboard à chargement lourd : foncez. Pour un éditeur type Figma : restez sur du CSR classique.

Besoin de moderniser une app React vers RSC ?

Tags #javascript #react #rsc #nextjs