Avant les Server Actions, écrire un formulaire vers WordPress depuis Next.js imposait un détour systématique : une route app/api/.../route.js qui recevait la requête du client, validait, puis appelait WordPress. Un fichier de plus à maintenir pour chaque formulaire, souvent copié-collé d’un projet à l’autre avec de légères variations qui finissaient par diverger.
Les Server Actions suppriment cet intermédiaire : une fonction marquée 'use server' peut être appelée directement depuis le formulaire du composant, tout en s’exécutant exclusivement côté serveur.
Déclarer une action serveur
La fonction vit dans un fichier séparé, avec la directive en première ligne, ce qui garantit qu’aucun de ses secrets ne sera inclus dans le bundle envoyé au navigateur :
// app/actions/inscription.js
'use server';
export async function inscrireNewsletter(etatPrecedent, formData) {
const email = formData.get('email');
if (!email || !email.includes('@')) {
return { erreur: 'Adresse e-mail invalide' };
}
const reponse = await fetch(`${process.env.WP_URL}/wp-json/newsletter/v1/inscrire`, {
method: 'POST',
headers: {
'Content-Type': 'application/json',
Authorization: `Basic ${process.env.WP_APP_PASSWORD_B64}`,
},
body: JSON.stringify({ email }),
});
if (!reponse.ok) {
return { erreur: 'Inscription impossible pour le moment' };
}
return { succes: true };
}
Le mot de passe d’application encodé reste une variable d’environnement serveur : à aucun moment il ne transite vers le client, contrairement à ce qui arriverait avec un appel fetch exécuté directement dans un composant client.
Brancher l’action sur le formulaire
Le composant utilise le hook useActionState pour relier le formulaire à l’action et récupérer son résultat sans écrire le moindre gestionnaire onSubmit manuel :
'use client';
import { useActionState } from 'react';
import { inscrireNewsletter } from '../actions/inscription';
export default function FormulaireNewsletter() {
const [etat, action] = useActionState(inscrireNewsletter, {});
return (
<form action={action}>
<input type="email" name="email" required />
<button type="submit">S'inscrire</button>
{etat.erreur && <p>{etat.erreur}</p>}
</form>
);
}
Le formulaire fonctionne même avant l’hydratation complète du JavaScript côté client, puisque les Server Actions s’appuient sur la soumission native des formulaires HTML.
Valider avant d’écrire dans WordPress
- Toute validation de format doit se faire dans l’action elle-même, jamais côté client seul : un client malveillant peut toujours contourner le formulaire.
- Les erreurs renvoyées par l’API REST de WordPress (code HTTP, message) doivent être traduites en messages compréhensibles, pas transmises brutes à l’utilisateur.
- Un mot de passe d’application scoppé à une seule route personnalisée limite les dégâts en cas de fuite, plutôt qu’un compte administrateur complet.
Limiter les abus sur une action publique
Une action serveur accessible sans authentification, comme une inscription à une newsletter, reste exposée à un usage abusif : un script qui soumet le formulaire des centaines de fois par minute. Ajouter une limitation de fréquence simple, par exemple en comptant les tentatives récentes par adresse IP dans un espace de stockage temporaire côté serveur, évite de transformer un formulaire public en porte ouverte au spam d’inscriptions.
Un piège avec le cache de Next.js
Après une écriture réussie, la page qui affiche la liste des inscrits ou un compteur ne se met pas à jour automatiquement : il faut appeler explicitement revalidatePath ou revalidateTag à la fin de l’action pour indiquer à Next.js que le contenu concerné vient de changer. Oublier cet appel donne l’impression que l’écriture a échoué, alors qu’elle a parfaitement réussi côté WordPress.
Une action serveur qui écrit sans jamais revalider la page correspondante finit toujours par générer un ticket de support « ça n’a pas marché » alors que tout a fonctionné.
En résumé
Les Server Actions suppriment une couche entière de code de liaison entre un formulaire Next.js et l’API REST de WordPress, tout en gardant les secrets d’authentification strictement côté serveur. Le seul réflexe à ne pas oublier : revalider explicitement ce qui doit changer après une écriture réussie, faute de quoi le front continue d’afficher une donnée périmée.
