Server Actions
Définition
Fonctions Next.js exécutées côté serveur appelées directement depuis un composant React. Évitent d'écrire une route API séparée pour les mutations simples (formulaires, paiements).
Comment ça marche
Une Server Action est une fonction asynchrone marquée "use server" qu'on appelle directement depuis un composant React, sans monter manuellement une route API. Next.js gère la sérialisation des arguments, le transport HTTP (POST sécurisé avec protection CSRF), l'exécution côté serveur, et la revalidation des caches concernés. Côté code, on écrit une fonction async classique qui prend des arguments et retourne un résultat. Le framework se charge du reste. Le développeur a l'impression d'appeler une fonction locale, alors qu'il déclenche en réalité un round-trip réseau.
À quoi ça sert
Les Server Actions évitent d'écrire une route API séparée pour chaque mutation simple : soumission de formulaire, création d'enregistrement, déclenchement d'un workflow, mise à jour d'un statut. Le code reste co-localisé avec la page qui l'utilise, ce qui simplifie la maintenance et la lecture. On supprime un client API, des types partagés, du boilerplate de fetch et de gestion d'erreur. Pour les apps Next.js qui consomment elles-mêmes leur backend, c'est devenu le réflexe par défaut, en particulier sur les formulaires et les actions ponctuelles déclenchées depuis l'UI.
Forms et progressive enhancement
Les Server Actions s'intègrent nativement aux formulaires HTML via l'attribut action : <form action={createPost}>. L'avantage clé : la soumission fonctionne même si JavaScript est désactivé ou en cours de chargement. C'est ce qu'on appelle progressive enhancement. Une fois JS chargé, React intercepte la soumission et exécute la Server Action sans recharger la page. On bénéficie aussi des hooks useFormState et useFormStatus pour gérer les états de chargement et les erreurs côté client, sans réinventer la roue.
Revalidation automatique
Après une Server Action, on appelle généralement revalidatePath ou revalidateTag pour invalider les pages ou les caches concernés. La prochaine requête sur ces routes déclenchera une régénération avec les données fraîches. C'est ce mécanisme qui permet de mettre à jour l'UI sans gestion d'état manuelle : on mute, on revalide, le framework récupère et rerend. Pour les actions optimistes (afficher le résultat avant la confirmation serveur), on combine avec useOptimistic. L'écosystème est plus fluide qu'avec React Query côté state management.
Sécurité et validation
Une Server Action est un endpoint HTTP exposé publiquement. Tout client malveillant peut l'appeler avec n'importe quels arguments. Donc on valide systématiquement les entrées avec Zod, on vérifie l'authentification de l'utilisateur dès la première ligne, et on contrôle les autorisations métier avant toute écriture. La protection CSRF est gérée par Next.js, mais les contrôles d'accès et la validation métier restent votre responsabilité. Un anti-pattern fréquent : croire qu'une Server Action est plus sécurisée parce qu'elle ressemble à une fonction locale. Elle ne l'est pas.
Quand ne pas l'utiliser
Pour des appels lourds, partagés entre plusieurs clients (app mobile, intégrations partenaires, automatisations), ou consommés en dehors de votre app Next.js, on garde une route API REST classique. Les Server Actions sont conçues pour le couple Next.js + frontend de la même app, pas pour exposer un backend public. De même, pour des opérations longues (au-delà de quelques secondes), on préfère déclencher un job en arrière-plan (queue, cron, edge function) plutôt que de bloquer une Server Action. Et pour les opérations qui doivent retourner du streaming (chat IA, génération longue), une route API avec ReadableStream reste plus adaptée.