Actions serveur dans Next.js : mutations sans maintenir une API juste pour ça

Il existe un type de code que chaque équipe finit par écrire sans se poser de questions : la couche de colle entre le formulaire et la base de données. Un endpoint qui reçoit le POST, valide le corps, appelle le service, renvoie un JSON. De l'autre côté, un fetch sur le client qui assemble ce corps, gère l'erreur, met à jour l'état. Multipliez cela par chaque action d'écriture de produit et vous obtenez des centaines de lignes qui existent uniquement pour déplacer les données d'un côté à l'autre.

Les actions du serveur, dans Next.js, attaquent exactement cette colle. La proposition est simple : effectuer des mutations (écriture, mise à jour, suppression) à partir d'une fonction qui s'exécute sur le serveur, appelée directement depuis le composant, sans avoir besoin de concevoir, versionner et maintenir une API REST dédiée pour cela. Le point de terminaison existe toujours, mais le framework le génère et le connecte pour vous.

Quels changements dans la pratique

Une action serveur est une fonction asynchrone marquée pour s'exécuter sur le serveur. Vous l'associez à un formulaire ou un événement, et Next.js s'occupe du transport : sérialise les arguments, fait l'appel réseau, renvoie le résultat. Du point de vue de celui qui écrit l'écran, il semble que vous appeliez simplement une fonction locale.

La différence par rapport au modèle précédent est moins de code et moins de points de synchronisation. Il n'y a plus de contrat API à maintenir aligné entre les deux parties, ni de schéma de requête qui doit correspondre à ce que le client envoie. La fonction qui enregistre la demande et l'écran qui déclenche cet enregistrement sont proches l'un de l'autre, et le type de retour est le même aux deux extrémités.

C'est important car la plupart des frictions au sein des équipes produit ne viennent pas de la logique métier, mais de la colle. Chaque mutation qui nécessitait auparavant un fichier de route, un gestionnaire, un client de récupération et un type partagé s'intègre désormais dans une fonction. Moins de surface propice aux erreurs, moins de fichiers à ouvrir en cas de panne.

Le gain de productivité est réel, mais ce n'est pas le point central

Il est tentant de vendre les actions serveur comme un raccourci de productivité, et c'est le cas. Mais réduire le discours à « moins de passe-partout » revient à sous-estimer ce qui se passe. Le gain le plus important est architectural : la logique sensible ne passe plus par le client.

Lorsque la mutation s'exécute sur le serveur, la clé API, les identifiants bancaires, la règle de prix, le calcul de la commission, rien de tout cela n'a besoin d'être envoyé au navigateur. Le client déclenche l'intention (« créer cette demande ») et le serveur décide de ce que cela signifie. Le code qui compte ne quitte jamais l’environnement que vous contrôlez.

Cela résout toute une classe de fuites que le modèle SPA traditionnel a rendue courante. Les équipes ont diffusé la logique métier sur le front-end parce que c'était là que c'était le plus pratique, puis ont découvert que des règles de remise ou des validations de limites étaient exposées dans l'offre groupée. Avec la mutation sur le serveur par défaut, la tentation disparaît : il n'y a nulle part où mettre cette logique sur le client, car le client ne connaît que l'appel.

Pour comprendre pourquoi le serveur est devenu le lieu naturel de cette logique, il convient de revisiter l'idée plus large de l'architecture serveur d'abord sur le web4, dont les Actions Serveur sont une pièce.

La mise en garde que personne ne peut ignorer : traiter l'entrée comme hostile

Voici la partie qui sépare ceux qui utilisent bien les actions serveur de ceux qui créent une faille de sécurité soignée. Une action serveur est un point de terminaison public. Le fait que vous l’appeliez uniquement à partir d’un joli formulaire dans votre propre application n’y change rien.

Lorsque Next.js génère l'action, il expose une route qui accepte les appels. Toute personne disposant du bon outil peut formuler une demande, avec les arguments de son choix et dans l’ordre de son choix. L'interface que vous avez conçue n'est pas une barrière : c'est juste une des manières d'appeler cette fonction. Penser « mais mon front n’enverrait jamais cette valeur » est l’erreur classique, car l’attaquant n’utilise pas son front.

Cela se traduit par deux obligations non négociables. La première est la validation. Chaque argument qui arrive doit être vérifié sur le serveur, avec un schéma explicite, avant de toucher à une règle métier. Type, format, plage de valeurs, présence de champs. La saisie de TypeScript est utile pendant le développement, mais elle disparaît au moment de l'exécution ; cela ne valide rien de ceux qui appellent l'itinéraire de l'extérieur.

La seconde est l’autorisation, et elle est distincte de la validation. Validate répond « ces données ont-elles un sens ? ». Autoriser répond « cette personne peut-elle faire cela ? ». Chaque action du serveur qui change d'état doit, en elle-même, vérifier qui est l'utilisateur et s'il a l'autorisation pour cette opération sur cette ressource. Ne comptez pas sur le fait d'avoir masqué le bouton dans l'interface. Le bouton caché ne protège pas la fonction ; il suffit de vérifier à l'intérieur, il protège.

Pourquoi ces contrôles doivent-ils vivre à l'intérieur de l'action

Il est tentant de centraliser l’autorisation dans le middleware et de considérer le problème comme résolu. Le middleware est utile, mais il fonctionne souvent au niveau de la route et non au niveau des ressources. Il peut indiquer « cet utilisateur est connecté », et rarement « cet utilisateur possède précisément cette commande qu'il essaie d'annuler ».

C’est dans cette différence que résident les échecs les plus coûteux. Un utilisateur authentifié et légitime peut tenter d'agir sur une ressource qui ne lui appartient pas simplement en modifiant un identifiant dans l'argument de l'appel. authentification réussie ; l'autorisation sur l'objet spécifique a échoué. C'est pourquoi la vérification des autorisations appartient au corps de l'action, proche de la règle métier, où vous disposez du contexte complet de ce qui est modifié et pour qui.

Le principe est ancien et mérite d'être lu plus largement sur les fondamentaux de la sécurité dans les applications Web : toute frontière entre ce que demande l'utilisateur et ce que fait le système est un point de contrôle. Les Actions Serveur ne créent pas cette bordure, elles la rendent plus discrète, et le discret est justement ce qu'on oublie de protéger.

Comment penser l'adoption sans devenir un gâchis

Les actions du serveur n'éliminent pas le besoin d'une couche de service. Si vous incorporez toute la logique métier dans les actions, vous recréerez le problème du gros contrôleur, juste avec un nom différent. L'action doit être fine : il reçoit l'appel, le valide, l'autorise et le délègue à une fonction de domaine qui ne connaît rien à HTTP ou à Next.js.

Cette séparation maintient la logique testable et réutilisable. La même règle d'ordre de création peut être appelée par une action, un travail de file d'attente et un script d'importation, à condition qu'elle se trouve en dehors de l'action. Traitez l'action du serveur comme une porte d'entrée, et non comme la pièce entière.

Il vaut également la peine d'être honnête quant au moment où une API traditionnelle a encore du sens. Si vous avez des clients externes, une application mobile native ou des intégrations tierces, une API versionnée et documentée reste la bonne réponse. Les actions du serveur brillent dans le couplage entre votre avant et votre arrière ; ils n'ont pas été conçus pour être le marché public qu'un partenaire va consommer. La façon dont cela s'intègre dans le reste du cadre est plus claire dans le guide Next.js App Router.

Que faut-il prendre en compte dans la décision

Les actions du serveur réduisent l'encombrement du code et transmettent la logique sensible au serveur par défaut, ce qui constitue à la fois un gain de productivité et de sécurité. C’est l’argument en faveur, et il est fort pour la plupart des applications qui, en fin de compte, sont votre face qui parle à votre dos.

Le prix est la discipline. Chaque action est un port public et doit être traitée comme telle : validation explicite, autorisation au niveau de la ressource, logique de domaine en dehors de celle-ci. Ceux qui traitent cela comme un détail échangent un passe-partout visible contre un risque invisible, et le risque invisible est le type qui apparaît dans la production au pire moment.

Si vous concevez l'architecture d'une nouvelle application Next.js], il vaut la peine de modéliser dès le début où se situent les limites de confiance avant de distribuer les actions dans tout le code. Si vous souhaitez échanger des idées sur ce dessin, appelez-moi dans les commentaires ou sur les réseaux.