Server Actions ou route API pour le formulaire d'une landing page Next.js ?

Un formulaire de landing page a un seul travail : faire arriver un lead quelque part, sans jamais planter au visage du visiteur qui vient de cliquer sur « Envoyer ». Historiquement, sur Next.js, ce travail passait presque toujours par la même mécanique : un composant client qui intercepte le submit, appelle fetch() vers une route API, attend une réponse JSON, puis met à jour l'interface à la main. Depuis Next.js 13 et l'App Router, une autre option existe : la Server Action, une fonction qui s'exécute côté serveur mais que le formulaire peut appeler directement via son attribut action, sans écrire de route intermédiaire. Les deux approches restent valables sur les templates LanderKit — la question n'est pas laquelle est « meilleure » dans l'absolu, mais laquelle correspond au niveau de robustesse, de sécurité et de simplicité que réclame concrètement votre page.

Server Action : ce que ça change concrètement

Une Server Action est une fonction annotée "use server", définie dans un fichier serveur ou en tête de fonction, que Next.js expose automatiquement comme point d'entrée réseau sécurisé. Le formulaire lui-même n'a plus besoin de JavaScript pour fonctionner : son attribut action pointe directement vers la fonction, le navigateur poste les données de façon native, et React ne fait qu'améliorer l'expérience par-dessus — état de chargement via useFormStatus, affichage d'erreur via useFormState, sans jamais rendre le formulaire dépendant du script pour simplement s'envoyer. C'est la même logique que le guide complet du formulaire de landing page recommande depuis toujours pour la robustesse — sauf qu'avant les Server Actions, l'obtenir sur Next.js demandait d'écrire soi-même la route de secours <form method="POST"> à côté du flux JavaScript.

Ce que la route API fait encore mieux

Une route API classique (app/api/lead/route.ts) reste un point d'entrée HTTP ordinaire, documentable, testable avec n'importe quel client REST, et appelable depuis un autre domaine — un CRM externe qui veut réutiliser le même endpoint, un test end-to-end qui poste directement sans passer par le rendu de la page, ou un futur besoin d'exposer le même traitement à une application mobile. Une Server Action, elle, est pensée pour être appelée depuis le rendu React qui la déclare : elle n'a pas d'URL stable documentée, ne s'invoque pas proprement depuis un outil externe, et complique la réutilisation si un jour le même traitement de lead doit servir à deux formulaires très différents dans le code. Pour une intégration qui doit rester interrogeable de l'extérieur — c'est le cas typique d'un webhook relayé vers un CRM ou Zapier — la route API garde l'avantage de la lisibilité et de la portabilité.

Sécurité : la différence n'est pas où on la croit

Un argument revient souvent en faveur des Server Actions : la protection CSRF (falsification de requête intersite) serait automatique, alors qu'une route API classique demanderait de la coder à la main. C'est vrai pour l'implémentation de Next.js, qui vérifie automatiquement l'origine de la requête avant d'exécuter une Server Action — un gain réel de simplicité. Mais ça ne veut pas dire qu'une route API est intrinsèquement vulnérable : Adam Barth, Collin Jackson et John C. Mitchell, dans « Robust Defenses for Cross-Site Request Forgery », publié en 2008 dans les actes de la 15^e conférence ACM sur la sécurité informatique (CCS 2008) (voir sur Google Scholar), montrent que les défenses CSRF fiables reposent sur la vérification de l'origine ou du referer de la requête — exactement le mécanisme qu'une route API peut implémenter elle-même, avec un peu plus de code. La vraie différence n'est donc pas « sécurisé » contre « pas sécurisé », mais « protégé par défaut sans y penser » contre « protégé si on prend soin de l'implémenter ». Sur un formulaire de capture de leads sans authentification préalable, le risque CSRF reste de toute façon limité — l'enjeu réel se situe plutôt du côté de la validation des données reçues et de la protection anti-spam, comme détaillé dans notre article sur le CAPTCHA.

Latence et hébergement : ce qui compte vraiment

Sur le plan de la performance pure, Server Action et route API s'exécutent toutes deux comme des fonctions serverless ou edge selon la configuration du déploiement, avec un coût de démarrage à froid comparable dans les deux cas — la différence entre les deux n'a rien à voir avec la latence. Liang Wang, Mengyuan Li, Yinqian Zhang, Thomas Ristenpart et Michael M. Swift, dans « Peeking Behind the Curtains of Serverless Platforms », publié en 2018 dans les actes de la conférence USENIX ATC (voir sur Google Scholar), ont mesuré plus de 50 000 invocations de fonctions sur AWS Lambda, Azure Functions et Google Cloud Functions et montrent que le délai de démarrage à froid — parfois plusieurs centaines de millisecondes — dépend surtout du runtime, de la taille du paquet de code et de la fréquence d'appel, pas du mécanisme d'invocation utilisé pour y accéder. Concrètement pour une landing page hébergée sur Vercel : garder la fonction de traitement du lead légère (pas de dépendance lourde importée juste pour un envoi d'e-mail) pèse davantage sur le temps de réponse que le choix entre Server Action et route API.

Le vrai avantage des Server Actions : la robustesse sans effort

Là où les Server Actions gagnent nettement, c'est sur la robustesse par défaut. Un formulaire branché sur une Server Action fonctionne même si le JavaScript n'a pas fini de se charger, échoue au chargement sur une connexion instable, ou tourne dans un contexte où le script est bloqué — le navigateur poste le formulaire nativement, la fonction serveur s'exécute, la page se recharge avec le résultat. Avec une route API appelée en fetch() depuis un gestionnaire onSubmit, ce filet de sécurité n'existe que si on prend la peine de l'écrire — un <form action="/api/lead" method="POST"> en secours, que peu d'équipes ajoutent une fois le flux JavaScript en place et testé. Le service public britannique (Government Digital Service) a documenté que sur ses propres sites à fort trafic, le JavaScript n'atteint pas correctement le navigateur dans environ 1,1 % des visites — pas parce que l'utilisateur l'a désactivé (environ 0,2 % des cas seulement), mais parce qu'un script tombe, une connexion coupe avant la fin du téléchargement, ou un navigateur mobile le désactive lui-même pour économiser de la bande passante. Sur une landing page où chaque conversion compte, une Server Action ferme ce trou de perte sans une ligne de code supplémentaire.

Comparatif : Server Action ou route API

Comment choisir pour votre landing page

1. Un formulaire de capture simple (nom, e-mail, un ou deux champs), qui n'a besoin d'être appelé que depuis cette page : la Server Action est le choix le plus direct, avec la robustesse sans JavaScript en prime.
2. Un formulaire dont le traitement doit être réutilisé ailleurs — plusieurs templates partageant le même endpoint, un test end-to-end qui poste directement en HTTP, ou un futur besoin d'exposer le même traitement à une autre application : la route API garde l'avantage.
3. Un formulaire multi-étapes avec validation en temps réel et logique conditionnelle complexe côté client : les deux approches cohabitent bien, une Server Action pouvant très bien ne servir qu'à la soumission finale.
4. Une intégration déjà pensée comme un webhook vers un outil tiers (CRM, Airtable, plateforme d'e-mailing) : garder une route API dédiée, documentée et testable indépendamment du rendu de la page, simplifie la maintenance à plusieurs mains.
5. Dans le doute, sur un template livré en production : la Server Action couvre la majorité des cas de capture de leads simples et réduit la surface de code à maintenir, tout en restant compatible avec un passage ultérieur vers une route API si le besoin évolue.

Aucun des deux choix n'est un mauvais calcul technique : les deux traitent la demande côté serveur, à l'abri du navigateur, et les deux peuvent être aussi robustes l'un que l'autre si on prend soin d'écrire le fallback qui manque par défaut à la route API. La différence se joue sur l'effort à fournir pour obtenir cette robustesse — nul avec une Server Action, à coder soi-même avec une route API — et sur la portabilité du traitement en dehors du rendu React. Chaque template LanderKit livre son formulaire déjà connecté et pensé pour cette robustesse, que ce soit sur le template Formation CPF (démo) ou sur le template SaaS & Liste d'attente (démo), à 89 € l'unité ou 229 € pour le pack complet des dix templates. Le choix technique entre Server Action et route API reste alors une question d'architecture à trancher au moment d'y brancher son propre CRM ou sa propre logique métier, pas un frein au lancement.