Des Server Actions vers un BFF

Quelle alerte a été émise en décembre

En décembre, j’ai signalé que l’usage prévu des Server Actions dans la vitrine Next.js poserait problème. L’argument venait de l’expérience : j’en avais fait les frais sur des projets personnels.

L’alerte n’a pas été retenue, et le développement a continué sur la trajectoire prévue. C’est le point de départ de cette étude de cas, et ce n’est pas la partie intéressante.

Ce qui s’est passé six mois plus tard

Après la mise en production, la bascule de la production sur une version canary de Next.js a fait apparaître des défaillances sur les Server Actions. Il a fallu les remplacer en urgence par des appels vers un BFF, exposé en vraies routes API Next.

L’urgence a rendu l’opération inconfortable, mais la cible était la bonne. Les Server Actions étaient de toute façon mal employées dans le code : passer par un BFF avec des routes API explicites était plus sain sur le fond, indépendamment de l’incident qui a déclenché le chantier. On y gagne une frontière lisible entre le front et le back, des points d’entrée nommés, et un comportement qui ne dépend pas d’un mécanisme implicite du framework.

Pourquoi ce n’est pas une histoire de raison technique

La lecture facile de cet enchaînement serait : l’alerte était juste, elle a été ignorée, l’incident est arrivé. Cette lecture ne sert à rien, et elle est fausse sur le fond.

Ce que je retiens est l’inverse. Mon alerte n’était pas défendable en l’état. Elle reposait sur une intuition tirée de projets personnels, elle n’était adossée à rien de démontrable dans le contexte du projet, et elle n’était pas chiffrée. Une équipe qui doit arbitrer entre des chantiers n’a aucune raison de réorienter une partie de son architecture sur cette base. Le problème n’était pas l’écoute de l’équipe : c’était la qualité de l’argument.

Comment je porterais la même alerte aujourd’hui

Un argument technique se défend avec des éléments qui portent, pas avec une conviction :

• une reproduction du problème dans le contexte du projet, pas dans un projet personnel ;
• le coût du changement au moment de l’alerte, comparé au coût du même changement fait plus tard, sous contrainte ;
• une proposition de cible concrète, ici le BFF, plutôt qu’un signalement de risque sans issue de sortie ;
• et un point de réévaluation daté, pour que le sujet revienne à l’ordre du jour au lieu de dépendre du fait que quelqu’un s’en souvienne.

Avoir raison ne suffit pas. Un développeur qui a raison et qui n’arrive pas à le rendre démontrable produit exactement le même résultat qu’un développeur qui a tort : rien ne change, et l’équipe encaisse le coût plus tard, au pire moment. La compétence à acquérir n’est pas technique, elle est dans la façon de construire et de présenter le dossier.