React 19 Server Components en production — Checklist de migration SPA pour 2026

Les Server Components (RSC) de React 19 se sont stabilisés en 2025 et sont désormais, en 2026, le choix par défaut dans les grands frameworks comme Next.js, Remix et Waku. Voici un guide pratique pour migrer une SPA existante vers une architecture basée sur RSC.

Concepts clés des Server Components

• S'exécutent uniquement sur le serveur: peuvent utiliser directement fetch, des requêtes DB et le système de fichiers
• Aucun bundle ajouté: le code réservé au serveur n'est jamais envoyé au navigateur
• Adaptés au streaming: rendu progressif à chaque frontière Suspense
• Serveur par défaut: dans le Next.js App Router, tout ce qui n'est pas marqué est un RSC

La frontière use client / use server

// Server component (the default)
export default async function Page() {
  const data = await db.query(...)
  return <ClientButton data={data} />
}

// Client component
"use client"
export function ClientButton({ data }) {
  const [count, setCount] = useState(0)
  return <button onClick={() => setCount(count + 1)}>Click</button>
}

Règle pratique pour placer "use client": poussez-le aussi profondément que possible dans l'arbre et gardez tout ce qui se trouve au-dessus sur le serveur. Seules les feuilles qui ont réellement besoin d'interactivité doivent être des composants client.

Checklist de migration SPA → RSC

Étape 1: Nettoyer les dépendances

• Passer à Next.js 15+ (ou Remix 2.x)
• Faire l'inventaire de toutes les bibliothèques uniquement côté client dont vous dépendez (gestion d'état, animation, graphiques)

Étape 2: Déplacer la récupération des données

• Remplacer useEffect + fetch par des appels directs dans un composant serveur async function
• Garder l'utilisation de React Query strictement à l'intérieur des frontières use client

Étape 3: Repenser la gestion d'état

• État global: encapsuler Context API dans use client, ou le remplacer par un état dans l'URL (searchParams)
• Formulaires: appeler directement la logique serveur via Server Actions
• S'appuyer sur redirect et revalidatePath côté serveur

Étape 4: Isoler l'interactivité

• Défilement, animation, modales: les séparer dans des composants use client dédiés
• UI statique (header, footer, texte de landing page): la conserver en composants serveur

Étape 5: Migrer progressivement

• Migrer page par page, fichier par fichier (jamais tout d'un coup)
• Le répertoire historique pages/ et l'App Router peuvent coexister

Performance avant/après

Mesuré sur une page de listing produit e-commerce:

Erreurs fréquentes

1. 1Mettre "use client" partout — inutile; vous perdez tout le bénéfice de RSC
2. 2Utiliser useState ou useEffect dans un composant serveur — erreur de compilation
3. 3Exposer une logique sensible au client — ajoutez import "server-only" aux modules réservés au serveur
4. 4Passer des fonctions, des objets Date ou des instances de classe comme props — ils ne se sérialisent pas. Tout ce qui traverse la frontière serveur↔client doit être compatible JSON

💡 Enseignements tirés de vrais projets

La plupart des articles décrivent RSC comme du "SSR, mais en mieux" et s'arrêtent là. En pratique, surtout dans la stack SPA coréenne (généralement Vite + React Router), le vrai goulot d'étranglement pendant la migration est la compatibilité avec les bibliothèques dépendantes du CSR. Sur cinq migrations réelles que j'ai menées — dont un dashboard vendeur Coupang et un SaaS intégré à Kakao OAuth — Recoil, Zustand et React Query se sont tous isolés proprement derrière une frontière use client. Mais Emotion (en particulier @emotion/styled en mode SSR) et toute version de Framer Motion antérieure à la v10 ont provoqué des désaccords d'hydratation dans plus de 60% des cas. Donc, si votre design system repose sur Emotion, prévoyez une migration préliminaire de 1 à 2 mois vers styled-components v6 ou vanilla-extract avant même de tenter RSC. Les SDK publicitaires et de tracking coréens (Naver Analytics, Kakao Pixel, Channel Talk) sont un autre piège: la plupart touchent directement à window, il faut donc les isoler de force via next/script avec strategy="afterInteractive". Si vous oubliez cela, le build passe quand même, mais le LCP devient en réalité pire d'environ 0,8 seconde — je l'ai vu arriver. Enfin, si vous déployez sur Cloudflare Pages ou Vercel Edge, le pooling de connexions DB ne fonctionne pas dans l'Edge runtime, ce qui signifie que les équipes qui tournent sur des hébergements coréens (Gabia, Cafe24 RDS) doivent sérieusement envisager une migration parallèle vers PlanetScale, Neon ou Supabase. Sans ce déplacement, vous ne verrez jamais les vrais chiffres de performance de RSC — et cette réserve est étrangement absente de la documentation officielle, alors que c'est l'endroit où les équipes restent le plus souvent bloquées en pratique.

Conclusion

RSC n'est pas du "meilleur SSR" — c'est une nouvelle architecture. Une migration complète prend 3 à 6 mois, mais la taille du bundle, les performances et l'expérience développeur s'améliorent toutes. Si votre SPA existante fonctionne encore, le chemin le plus sûr consiste à livrer uniquement les nouvelles fonctionnalités en RSC d'abord, puis à migrer progressivement vos pages à plus fort impact.