Les Server Actions sont des fonctions qui s'exécutent côté serveur, mais que l'on peut appeler directement depuis un composant ou un formulaire dans le navigateur. C'est l'une des fonctionnalités les plus disruptives apportées par Next.js 14.
Avant les Server Actions, pour modifier une donnée (créer un commentaire, ajouter au panier, supprimer un post), il fallait créer une route API REST, écrire le code de la requête fetch côté client, gérer les états de chargement, l'erreur, le rafraîchissement de la page. Beaucoup de code répétitif.
Avec les Server Actions, tout ce code disparaît. On écrit une fonction serveur, on la passe à un formulaire, et tout fonctionne — y compris si JavaScript est désactivé.
Pour transformer une fonction normale en Server Action, on ajoute une directive textuelle en première ligne du fichier ou de la fonction. Cette directive indique au compilateur Next.js que la fonction doit être exécutée uniquement côté serveur.
Deux placements possibles :
⚠️ Attention sécurité : ne jamais utiliser de variables d'environnement secrètes dans des Client Components, et toujours valider les inputs côté serveur dans les Server Actions.
React 19 introduit deux hooks dédiés aux formulaires connectés à des Server Actions :
Combinés, ces deux hooks permettent de gérer formulaires, validations et feedbacks utilisateur sans aucune ligne de useState ou useEffect.
Après une mutation (création, modification, suppression), il faut invalider le cache pour que les données fraîches s'affichent. Next.js fournit deux fonctions :
Exemple de scénario : un utilisateur poste un commentaire. La Server Action insère le commentaire en base, puis appelle revalidatePath sur la page de l'article. La prochaine visite affiche le nouveau commentaire sans rebuild complet.
Pour une UX premium, on peut afficher immédiatement le résultat attendu avant même que le serveur réponde. C'est le pattern optimistic update, géré par le hook useOptimistic de React 19.
Cas d'usage typiques : like Twitter, ajout au panier, validation d'une todo. Le visuel se met à jour instantanément, et si la Server Action échoue, on rollback automatiquement.
| Critère | API Routes | Server Actions |
|---|---|---|
| Format | REST endpoints (GET, POST, etc.) | Fonctions JavaScript |
| Cas d'usage | API publique, webhooks, mobile app | Mutations internes au site |
| Type-safety | Manuelle (Zod, OpenAPI) | Native TypeScript |
| Sans JS | Non fonctionnel | Fonctionne (forms HTML natifs) |
| Boilerplate | Élevé | Quasi nul |
Next.js permet de choisir l'environnement d'exécution de chaque route ou Server Action.
| Aspect | Edge Runtime | Node Runtime |
|---|---|---|
| Localisation | CDN mondial, proche utilisateur | Région unique du serveur |
| Démarrage | Quasi-instantané (cold start négligeable) | 100-500 ms cold start |
| APIs disponibles | Web standard (fetch, Request) | Toutes APIs Node.js (fs, crypto) |
| Limite mémoire | Faible (~128 MB) | Élevée (jusqu'à plusieurs GB) |
| Use case | Auth, géolocalisation, streaming IA | Traitement lourd, accès DB direct |
Le fichier middleware à la racine du projet s'exécute avant chaque requête. Il tourne sur l'Edge Runtime et permet d'intercepter, modifier ou rediriger les requêtes.
✅ À retenir : les Server Actions remplacent 90 % des cas où on créait une API REST en interne. Garde les API Routes pour les cas publics ou mobiles.