Commencer

Prêt à commencer ?

Rejoignez des milliers d'utilisateurs qui créent des choses incroyables avec notre plateforme.

Pas de carte de crédit requise

Restez informé de nos derniers articles et actualités du développement web.

Pas de spam, désabonnement à tout moment

Introduction à Next.js 16

Ce qui change concrètement quand on développe avec Next.js 16 et React 19 : params asynchrones, Server Components, Server Actions et Turbopack.

#nextjs#react#frontend

Mike Codeur

03 août 20265 min

Next.js 16 tourne avec React 19, et l'App Router n'est plus une nouveauté à apprivoiser : c'est la manière normale d'écrire une application. Plutôt qu'une liste de changelog, voici ce qui change quand vous écrivez du code au quotidien, avec des exemples tirés d'une application réelle en production.

Les exemples de cet article viennent d'un projet tournant sous Next.js 16.2 et React 19.2, en TypeScript strict.

Les Server Components sont le défaut

Un composant est un Server Component tant que vous n'écrivez pas 'use client'. Il s'exécute sur le serveur, n'est jamais envoyé au navigateur, et peut faire de l'asynchrone directement :

export default async function CoursesPage() {
  const courses = await getCoursesDal()

  return (
    <ul>
      {courses.map((course) => (
        <li key={course.id}>{course.title}</li>
      ))}
    </ul>
  )
}

Pas de useEffect, pas de useState, pas d'état de chargement à gérer à la main : les données sont là au moment du rendu.

La bonne discipline : garder 'use client' pour les feuilles de l'arbre — un formulaire, un menu, un bouton interactif. Tout ce qui n'a pas besoin d'interactivité reste sur le serveur, et ne pèse rien dans le bundle.

`params` et `searchParams` sont asynchrones

C'est le changement qui surprend le plus à la migration, et celui qu'on rencontre dès la première page dynamique. Les paramètres de route ne sont plus un objet, mais une promesse :

interface PageProps {
  params: Promise<{slug: string}>
}

export default async function Page({params}: PageProps) {
  const {slug} = await params
  return <article>{slug}</article>
}

La règle s'applique partout où ces props apparaissent : page.tsx, layout.tsx, generateMetadata, generateStaticParams.

En TypeScript strict, l'oubli du await se voit tout de suite. En JavaScript, vous obtiendrez un undefined silencieux — typez vos props, c'est le meilleur filet de sécurité de cette migration.

Les Server Actions remplacent la plupart des routes d'API

Pour une mutation, plus besoin d'écrire une route d'API, de sérialiser un fetch et de gérer le JSON des deux côtés. Une fonction serveur suffit :

'use server'

import {revalidatePath} from 'next/cache'

export async function updateProfileAction(formData: FormData) {
  const user = await requireActionAuth()

  const parsed = profileSchema.safeParse({
    name: formData.get('name'),
    email: formData.get('email'),
  })

  if (!parsed.success) {
    return {success: false, message: 'Données invalides'}
  }

  await updateUserService({id: user.id, ...parsed.data})
  revalidatePath('/account')

  return {success: true, message: 'Profil mis à jour'}
}

Elle s'appelle directement depuis un formulaire, sans couche réseau à écrire :

'use client'

export function ProfileForm() {
  return (
    <form action={updateProfileAction}>
      <input name="name" />
      <button type="submit">Enregistrer</button>
    </form>
  )
}

Une Server Action est un point d'entrée public, exactement comme une route d'API. Elle doit vérifier l'authentification et valider ses entrées à chaque appel. Le fait qu'elle soit appelée depuis un formulaire de votre application ne prouve rien sur l'appelant réel.

Turbopack en développement

Le serveur de dev tourne sous Turbopack. Concrètement, le démarrage se compte en centaines de millisecondes et le rafraîchissement suit la frappe :

pnpm dev

▲ Next.js 16.2.10 (Turbopack)
- Local:  http://localhost:3000
✓ Ready in 233ms

Sur un projet qui grossit, c'est le genre de détail qui change la façon de travailler : on relance sans y penser.

Où mettre quoi

La question la plus fréquente en démarrant sur l'App Router n'est pas technique, c'est une question de placement. Un repère simple :

Besoin	Où l'écrire
Lire des données pour l'affichage	Server Component, en `await` direct
Modifier des données	Server Action (`'use server'`)
État local, événements, animations	Client Component (`'use client'`)
Réponse machine (webhook, API tierce)	Route Handler (`route.ts`)
Protéger une page	Au niveau du layout et de la page

Un layout ne se re-rend pas à chaque navigation côté client. Protéger uniquement le layout laisse une faille : doublez la vérification au niveau de la page.

Une structure qui tient dans le temps

L'App Router n'impose pas d'architecture, ce qui est autant une liberté qu'un piège : rien ne vous empêche d'appeler la base de données depuis un composant. Sur un projet qui dure, il vaut mieux poser un sens de circulation unique :

Présentation

Pages et composants. Ils affichent, ils ne savent pas d'où viennent les données.

Accès aux données

Une couche dédiée, mise en cache, qui vérifie les droits et renvoie des objets prêts à afficher — jamais des lignes de base brutes.

Métier

Validation, règles, autorisations. C'est ici que vivent les décisions, pas dans le composant.

Persistance

Les requêtes. Elles ne connaissent ni React ni le HTTP.

La règle qui fait tenir l'ensemble : on ne saute jamais une couche. Une page qui importe directement une requête SQL est un raccourci qui coûte cher six mois plus tard.

À retenir

Next.js 16 ne demande pas de réapprendre React : il déplace le curseur par défaut vers le serveur. Les trois réflexes qui font la différence :

Écrire serveur d'abord, et ne passer client que pour ce qui a vraiment besoin d'interactivité
await sur params et searchParams, partout
Traiter chaque Server Action comme un point d'entrée public : authentification et validation systématiques

Pour la liste exhaustive des changements d'une version à l'autre, le guide de migration officiel de Next.js reste la référence à garder ouverte pendant la mise à jour.

Écrit par

Mike Codeur

Auteur

Prêt à commencer ?

Rejoignez des milliers d'utilisateurs qui créent des choses incroyables avec notre plateforme.

Commencer gratuitement

Pas de carte de crédit requise

Restez informé de nos derniers articles et actualités du développement web.

Pas de spam, désabonnement à tout moment

Retour aux articlesDevelopment

Introduction à Next.js 16

Ce qui change concrètement quand on développe avec Next.js 16 et React 19 : params asynchrones, Server Components, Server Actions et Turbopack.

#nextjs#react#frontend

Mike Codeur

03 août 20265 min

Les exemples de cet article viennent d'un projet tournant sous Next.js 16.2 et React 19.2, en TypeScript strict.

Les Server Components sont le défaut

Un composant est un Server Component tant que vous n'écrivez pas 'use client'. Il s'exécute sur le serveur, n'est jamais envoyé au navigateur, et peut faire de l'asynchrone directement :

export default async function CoursesPage() {
  const courses = await getCoursesDal()

  return (
    <ul>
      {courses.map((course) => (
        <li key={course.id}>{course.title}</li>
      ))}
    </ul>
  )
}

Pas de useEffect, pas de useState, pas d'état de chargement à gérer à la main : les données sont là au moment du rendu.

`params` et `searchParams` sont asynchrones

C'est le changement qui surprend le plus à la migration, et celui qu'on rencontre dès la première page dynamique. Les paramètres de route ne sont plus un objet, mais une promesse :

interface PageProps {
  params: Promise<{slug: string}>
}

export default async function Page({params}: PageProps) {
  const {slug} = await params
  return <article>{slug}</article>
}

La règle s'applique partout où ces props apparaissent : page.tsx, layout.tsx, generateMetadata, generateStaticParams.

En TypeScript strict, l'oubli du await se voit tout de suite. En JavaScript, vous obtiendrez un undefined silencieux — typez vos props, c'est le meilleur filet de sécurité de cette migration.

Les Server Actions remplacent la plupart des routes d'API

Pour une mutation, plus besoin d'écrire une route d'API, de sérialiser un fetch et de gérer le JSON des deux côtés. Une fonction serveur suffit :

'use server'

import {revalidatePath} from 'next/cache'

export async function updateProfileAction(formData: FormData) {
  const user = await requireActionAuth()

  const parsed = profileSchema.safeParse({
    name: formData.get('name'),
    email: formData.get('email'),
  })

  if (!parsed.success) {
    return {success: false, message: 'Données invalides'}
  }

  await updateUserService({id: user.id, ...parsed.data})
  revalidatePath('/account')

  return {success: true, message: 'Profil mis à jour'}
}

Elle s'appelle directement depuis un formulaire, sans couche réseau à écrire :

'use client'

export function ProfileForm() {
  return (
    <form action={updateProfileAction}>
      <input name="name" />
      <button type="submit">Enregistrer</button>
    </form>
  )
}

Turbopack en développement

Le serveur de dev tourne sous Turbopack. Concrètement, le démarrage se compte en centaines de millisecondes et le rafraîchissement suit la frappe :

pnpm dev

▲ Next.js 16.2.10 (Turbopack)
- Local:  http://localhost:3000
✓ Ready in 233ms

Sur un projet qui grossit, c'est le genre de détail qui change la façon de travailler : on relance sans y penser.

Où mettre quoi

La question la plus fréquente en démarrant sur l'App Router n'est pas technique, c'est une question de placement. Un repère simple :

Besoin	Où l'écrire
Lire des données pour l'affichage	Server Component, en `await` direct
Modifier des données	Server Action (`'use server'`)
État local, événements, animations	Client Component (`'use client'`)
Réponse machine (webhook, API tierce)	Route Handler (`route.ts`)
Protéger une page	Au niveau du layout et de la page

Un layout ne se re-rend pas à chaque navigation côté client. Protéger uniquement le layout laisse une faille : doublez la vérification au niveau de la page.

Une structure qui tient dans le temps

Présentation

Pages et composants. Ils affichent, ils ne savent pas d'où viennent les données.

Accès aux données

Une couche dédiée, mise en cache, qui vérifie les droits et renvoie des objets prêts à afficher — jamais des lignes de base brutes.

Métier

Validation, règles, autorisations. C'est ici que vivent les décisions, pas dans le composant.

Persistance

Les requêtes. Elles ne connaissent ni React ni le HTTP.

La règle qui fait tenir l'ensemble : on ne saute jamais une couche. Une page qui importe directement une requête SQL est un raccourci qui coûte cher six mois plus tard.

À retenir

Next.js 16 ne demande pas de réapprendre React : il déplace le curseur par défaut vers le serveur. Les trois réflexes qui font la différence :

Écrire serveur d'abord, et ne passer client que pour ce qui a vraiment besoin d'interactivité
await sur params et searchParams, partout
Traiter chaque Server Action comme un point d'entrée public : authentification et validation systématiques

Pour la liste exhaustive des changements d'une version à l'autre, le guide de migration officiel de Next.js reste la référence à garder ouverte pendant la mise à jour.

Écrit par

Mike Codeur

Auteur

Prêt à commencer ?

Newsletter

Introduction à Next.js 16

Les Server Components sont le défaut

`params` et `searchParams` sont asynchrones

Les Server Actions remplacent la plupart des routes d'API

Turbopack en développement

Où mettre quoi

Une structure qui tient dans le temps

Présentation

Accès aux données

Métier

Persistance

À retenir

Articles connexes

Tailwind CSS v4 : la configuration passe dans le CSS

Le Proxy Component en React

Prêt à commencer ?

Newsletter

Introduction à Next.js 16

Les Server Components sont le défaut

`params` et `searchParams` sont asynchrones

Les Server Actions remplacent la plupart des routes d'API

Turbopack en développement

Où mettre quoi

Une structure qui tient dans le temps

Présentation

Accès aux données

Métier

Persistance

À retenir

Articles connexes

Tailwind CSS v4 : la configuration passe dans le CSS

Le Proxy Component en React

Prêt à commencer ?

Newsletter

Les Server Components sont le défaut

params et searchParams sont asynchrones

Les Server Actions remplacent la plupart des routes d'API

Turbopack en développement

Où mettre quoi

Une structure qui tient dans le temps

Présentation

Accès aux données

Métier

Persistance

À retenir

Articles connexes

Tailwind CSS v4 : la configuration passe dans le CSS

Le Proxy Component en React

Prêt à commencer ?

Newsletter

Les Server Components sont le défaut

params et searchParams sont asynchrones

Les Server Actions remplacent la plupart des routes d'API

Turbopack en développement

Où mettre quoi

Une structure qui tient dans le temps

Présentation

Accès aux données

Métier

Persistance

À retenir

Articles connexes

Tailwind CSS v4 : la configuration passe dans le CSS

Le Proxy Component en React

`params` et `searchParams` sont asynchrones

`params` et `searchParams` sont asynchrones