Évaluer le parcours d’échec : Next.js, Remix et données d’autorisation obsolètes

Les comparaisons de frameworks mesurent généralement le scénario idéal : un navigateur vierge, des données préchargées et une page qui s’affiche en une seule fois. Les systèmes de production sont évalués ailleurs, c’est-à-dire dans les moments suivant une modification des données. Cette étude de cas suit une équipe qui a développé la même interface authentifiée avec Next.js et dans une architecture de type Remix, a constaté que Next.js remportait toutes les mesures de performance, puis a changé d’avis en raison d’une autorisation annulée qui refusait de disparaître. À la fin, vous disposerez d’une méthode pratique pour évaluer les frameworks de rendu en fonction des échecs que votre produit ne peut vraiment pas se permettre.

Un gagnant évident en termes de performance

La comparaison des performances n’était pas serrée. La version Next.js envoyait moins de JavaScript au navigateur, affichait la première vue utile plus rapidement, conservait les traitements de données coûteux sur le serveur et, grâce au cache, rendait les navigations répétées instantanées.

Un administrateur a alors été supprimé d’un compte client. La base de données ainsi que le journal des audits reflétaient cette suppression, et la recharge de la page affichait les bons droits d’accès. Cependant, lorsque l’utilisateur concerné est retourné à l’écran du compte via la navigation intégrée, les contrôles d’administration étaient de nouveau présents. Les boutons qui auraient dû disparaître étaient à nouveau visibles.

L’API backend a rejeté toutes les actions privilégiées, de sorte qu’aucune donnée n’a été modifiée et aucun incident de sécurité n’a eu lieu. C’est précisément à cause de cette vérification côté serveur que l’autorisation doit toujours être appliquée au niveau de l’API, et non déduite de ce que montre l’interface utilisateur. Mais cette mesure de sécurité n’a pas sauvé la décision architecturale prise initialement.

Dans la version de type Remix, les ingénieurs ont identifié en quelques minutes tous les endroits où des données obsolètes pouvaient subsister. Pour la version Next.js, il a fallu plusieurs personnes, deux traces contradictoires et un rechargement forcé accidentel pour déterminer quel niveau avait généré la réponse. Cette enquête a renversé le verdict.

L’écran construit deux fois

La page en question n’était pas un simple outil de démonstration. Elle servait de nombreux utilisateurs et permettait aux administrateurs de gérer les personnes, leurs rôles, les clés API, ceux qui pouvaient accéder aux informations de facturation, ainsi que les événements survenus au sein du compte. La lecture dominait le trafic, mais les interactions critiques étaient des écritures : annuler un rôle, renouveler une clé, supprimer un membre, modifier les personnes autorisées à voir les factures.

Trois exigences poussaient dans des directions différentes :

• Un rendu initial rapide, même pour les comptes ayant une longue historique d’activités.

JavaScript minimal dans le navigateur, car les utilisateurs travaillaient sur des ordinateurs professionnels lents.

Changements de permissions affichés de manière fiable, quel que soit le moyen par lequel l’utilisateur accède à la page.

Au sein de Next.js, les composants serveur affichaient la majeure partie de l’écran, seuls de petits composants client étant utilisés pour les widgets interactifs. Les données de compte, utilisées par plusieurs layouts imbriqués, étaient stockées dans un cache afin d’éviter de les récupérer à plusieurs reprises, et les écritures réussies déclenchaient une révalidation.

La version de style Remix s’appuyait sur des chargeurs par route pour les lectures et des actions pour les écritures, n’ajoutant des en-têtes de cache HTTP standard que lorsque la durée de vie sûre était connue. Une fois une action terminée, les chargeurs des routes concernées étaient exécutés à nouveau, selon une séquence suffisamment simple pour être esquissée sur un tableau blanc. (Au moment de la rédaction, ce modèle de chargeurs et d’actions persiste dans le mode framework de React Router, dans lequel Remix a été intégré ; consultez la documentation actuelle pour les noms utilisés.)

Les deux implémentations étaient solides, et aucune n’était conçue pour échouer. Dans des conditions idéales, Next.js l’emportait clairement, ce qui révélait la première faille du test : le trafic réel n’est pas limité à des conditions idéales.

Où les composants serveur compliquent la requête

Les composants serveur ont tenu leurs promesses. Les sections en lecture seule n’exigeaient aucun code client, la récupération des données se faisait directement auprès des composants qui les utilisaient, les panneaux lents s’affichaient sans bloquer l’interface, et les données d compte stables évitaient des requêtes répétées vers l’origine.

Le prix à payer était que une seule page visible était désormais assemblée à partir de plusieurs cycles de vie indépendants :

• Des tâches limitées à une seule génération côté serveur.
• Des données réutilisées grâce au cache côté serveur.
• L’état du routeur conservé dans le navigateur au cours des navigations client.
• Plusieurs instances serveur, chacune conservant sa propre copie des valeurs mémorisées.
• Une invalidation déclenchée par une écriture.
• Tous les proxies ou CDN situés en amont de l’application.

Le fait de savoir quel niveau de traitement contenait la valeur obsolète n’avait aucune importance pour l’utilisateur, mais était crucial pour celui qui était de garde. Une trace montrait que la base de données renvoyait le rôle mis à jour ; une autre indiquait que l’interface des permissions affichait encore la version précédente. Aucune des deux n’était erronée : chacune capturait une demande différente suivant un parcours distinct au sein du système.

Le développement local n’a jamais reproduit ce problème. Un seul processus gérait tout le cache, les ingénieurs mettaient à jour les données après chaque modification, et les comptes de test ne suivaient jamais la séquence d’un client réel qui aurait gardé l’application ouverte avant que les permissions ne changent. En éliminant le travail redondant, la conception avait également supprimé toute façon simple de déterminer quel niveau de traitement fournissait une valeur donnée.

Le comportement exact de chaque couche de cache de Next.js, comme la durée pendant laquelle le routeur client conserve les segments préchargés, a changé entre les versions majeures. Cela fait partie de la leçon : si votre logique dépend de ces paramètres par défaut, notez cette dépendance et vérifiez-la à chaque mise à jour.

Pourquoi le rechargement forcé était la véritable piste

Les équipes de support ont constaté qu’un rechargement forcé résolvait le problème. Cela semble indiquer un problème lié au cache du navigateur, mais celui-ci n’expliquait qu’une partie du phénomène. Un rechargement envoie une demande complètement nouvelle au serveur, et cette demande a tendance à atteindre une instance ne contenant pas la version obsolète. La navigation client, quant à elle, réutilise un chemin avec des données différentes et un historique d’invalidation différent. Comme la page semblait correcte après chaque rechargement, le bug disparaissait systématiquement dès que quelqu’un la consultait.

Le suivi synthétique a révélé le même point aveugle. Chaque vérification débutait par une session nouvelle et confirmait qu’un utilisateur ayant le nouveau rôle affichait la bonne page. Aucun n’a testé la transition du vieux droit d’accès vers le nouveau au sein d’une session existante. L’équipe surveillait les états, tandis que le bug se trouvait entre ces états.

Avec cette compréhension, la reproduction du problème est devenue fiable :

1. Ouvrir l’écran de compte afin qu’il soit géré par une instance d’application.
2. Changer le rôle de l’utilisateur depuis une autre session.
3. Retourner à l’écran via la navigation client, sans rechargement.
4. Vérifier si la version du droit d’accès affichée dans l’interface correspond à celle que le service a enregistrée.

Rien dans les composants n’était défectueux. L’entrée mémorisée se comportait exactement comme configuré ; la durée de vie définie était simplement inadaptée aux données d’autorisation. qualifier cela de « bug de cache obsolète » suggère une ligne de code défectueuse. La véritable faille résidait dans une garantie architecturale non énoncée : dans quel délai un droit révoqué doit disparaître de tout ce que l’utilisateur peut voir ?

La première correction a presque transféré le problème à la base de données

La solution la plus rapide a été d’activer l’arrêt du cache dans toute la section du compte. L’autorisation obsolète a disparu, et la charge de la base de données a augmenté immédiatement.

Les layouts et panneaux imbriqués demandaient des données de compte superposées. Le cache faisait en sorte que ces lectures dupliquées semblent gratuites ; son suppression a transformé un incident lié aux autorisations en des temps d’attente croissants dans le pool de connexions PostgreSQL, mettant en péril les autres pages de compte.

Les débats sur les frameworks ont tendance à passer complètement à côté de ce point. Un cache peut représenter un risque pour la correction des données, mais il peut également servir de support de charge. L’activer à nouveau restaure la fraîcheur des données tout en éliminant une hypothèse qui permettait au système de base de données de rester en bon état.

La récupération s’est faite par des étapes plus petites et plus sûres :

• Les données de permission ont été invalidées pour chaque compte et pour chaque version de permission, plutôt que de manière globale.
• Les lectures d’autorisation ont été effectuées au niveau de chaque requête, de sorte qu’elles ne duraient jamais plus longtemps qu’une seule requête.
• Les lectures redondantes ont été supprimées avant d’élargir le champ des chemins non mémorisés.
• Une petite partie du trafic a d’abord été traitée selon le nouveau comportement, tout en surveillant le temps d’attente dans la file d’attente.
• Chaque réponse a commencé à contenir un petit marqueur indiquant comment elle avait été générée, quelle instance l’avait servie, la version des données et si une réponse provenant du cache avait été utilisée.

Ce marqueur a modifié les investigations ultérieures. Il permettait de déterminer l’origine d’une réponse sans exposer les données de permission elles-mêmes, et les ingénieurs n’avaient plus besoin de deviner le chemin d’exécution en se basant sur le fait qu’un renouvellement avait eu lieu. Il s’agit d’une solution peu coûteuse pour tout système disposant de plusieurs couches de mise en cache.

Pourquoi l’architecture plus lente a triomphé pour ce produit

La méthode de construction de type Remix n’était pas à l’abri des problèmes liés à l’état distribué. Des caches existent dans les navigateurs et les CDN, les bases de données gèrent des répliques, et toute application sérieuse finit par faire face à des données obsolètes, des échecs partiels et des tentatives de réessai.

Ses capacités étaient plus limitées. Le trio chargeur, action et révalidation fournissait à l’équipe un modèle mental compact de ce qui se passe après une écriture. Lorsqu’une action modifiait un rôle, les ingénieurs pouvaient identifier les chemins dont les données devaient être mises à jour et savaient où les valider. Les limites des requêtes coïncidaient avec celles utilisées par les opérateurs de suivi. Il récupérait certaines données deux fois et nécessitait du code supplémentaire dans le navigateur pour certains widgets, mais ses dysfonctionnements pouvaient être rapidement identifiés.

Cela convient donc à ce produit en particulier, sans pour autant en faire une solution universelle. Sur un site où le contenu ne change que rarement et où les tâches liées aux navigateurs prennent le pas, l’architecture Next.js reste la meilleure option ; ses capacités de rendu et de mise en cache permettent d’obtenir une expérience nettement supérieure. Pour un outil opérationnel nécessitant une authentification, le fait qu’une autorisation annulée reste visible coûte plus que l’écart de performance mesuré. Les écritures traçables et une fraîcheur prévisible étaient plus importantes.

Le benchmark n’était pas erroné. Il avait simplement répondu à une question incomplète.

Reconstruire l’évaluation autour des échecs

La deuxième évaluation n’a pas commencé avec un navigateur propre et des données mises à jour. Elle a pris pour point de départ les situations que le premier benchmark avait ignorées :

• Une autorisation change tandis que l’écran reste ouvert. Tous les moyens d’accéder à la page affichent-ils ce changement dans le délai convenu, et un ingénieur peut-il savoir quelle version est affichée ?
• Une instance d’application disparaît en cours d’utilisation. L’utilisateur peut-il réessayer en toute sécurité, et un travail partiel ne crée-t-il pas un état du client confus ?
• Le cache est désactivé en période de trafic maximal. La base de données peut-elle résister à la solution d’urgence la plus tentante ?
• Deux versions d’une application gèrent le trafic pendant un déploiement. Les deux peuvent-elles interpréter à la fois les données en cache et les réponses aux modifications ?
• Le service client reconstitue un parcours d’utilisateur. Peuvent-ils déterminer comment la page a été affichée, quel cache et quelle instance ont répondu, ainsi quelle version des données a été utilisée, sans devoir déboguer les serveurs en direct ?

Next.js est resté plus rapide sur plusieurs chemins importants. Le modèle de type Remix a facilité la compréhension par l’équipe lorsque ces chemins ont cessé de fonctionner normalement. À ce stade, l’équipe comparait des systèmes plutôt que des captures d’écran.

Décider en fonction des erreurs potentielles de la page

Réduire le choix à « Next.js est rapide, Remix est simple » ne tiendra pas face aux conditions réelles en production. Avant de mesurer les performances, répondez à ces questions :

• Quels données le produit est-il autorisé à servir de manière obsolète, et pendant combien de temps ?
• Les mutations affectent-elles l’argent, les droits d’accès, les stocks, ou seulement l’affichage ?
• Combien de limites de mise en cache et d’affichage l’équipe peut-elle identifier à partir d’un seul rapport client ?
• La base de données peut-elle fonctionner si la mémoire cache est supprimée ?
• Comment deux versions déployées se comportent-elles côte à côte ?

Puis mesurez le chemin optimal.

L’équipe a abouti à une décision partagée. Next.js a été conservé pour les pages où les composants serveur réduisaient réellement le travail côté client et où chaque donnée disposait d’une durée de vie clairement définie et sécurisée. Les données de permissions, souvent modifiées fréquemment, étaient intentionnellement conçues de manière simple : limitées au cadre d’une requête et jamais mémorisées en cache. Quant à l’écran des opérations, où il était plus important de bien gérer les modifications que d’assurer une livraison statique rapide, l’approche Remix a été choisie. Si vous continuez d’utiliser Next.js pour de tels écrans, l’invalidation basée sur des balises, abordée dans la directive use cache et la révalidation basée sur des balises, vous offre un contrôle plus fin, tandis que les vérifications d’autorisation à l’intérieur de chaque action serveur restent une solution de secours, quel que soit l’affichage de l’interface.

Points clés

• Un benchmark qui démarre depuis une session vierge ne peut pas détecter les bugs présents entre différents états ; testez les transitions au sein de sessions à longue durée de vie.
• Traitez les données d’autorisation comme une classe à part entière : limitées au cadre de la requête, versionnées et invalidées explicitement.
• Un cache peut représenter une charge réelle ; planifiez comment le supprimer avant qu’un incident ne vous y force.
• Rendez visible l’origine de chaque réponse à l’aide d’un marqueur léger indiquant le mode de rendu, l’instance, la version et l’état du cache.
• Choisissez le framework dont les modes de défaillance peuvent être rapidement expliqués par votre équipe. Une option peut vous offrir plus d’outils pour accélérer le travail ; l’autre peut faciliter le diagnostic des pages incorrectes. Pour certains produits, c’est cette deuxième caractéristique qui est vraiment essentielle.

Lectures complémentaires