2026-09-15
Le lien de déconnexion que le préchargement suivait
Sur le tableau de bord de notre plateforme, chaque page connectée renvoyait à l'écran de connexion dès que la vue d'ensemble avait été affichée. Le défaut n'existait pas en développement, et la validation locale de bout en bout ne pouvait pas le voir : il tenait à une optimisation que Next.js n'applique qu'aux versions de production. Constat du 10 juillet 2026.
Un lien de déconnexion en GET
La vue d'ensemble portait un lien « Se déconnecter » vers une route qui détruisait la session à la réception d'une requête GET. En développement, cliquer sur le lien déconnectait, et rien d'autre ne sollicitait cette route. La validation locale, menée sur cette version, était verte.
Le préchargement de production
En production, Next.js précharge les liens présents dans la page pour accélérer la navigation, et il ne le fait jamais en développement. Le préchargement du lien de déconnexion envoyait donc la requête GET qui détruisait la session, sans aucun clic, à chaque affichage de la vue d'ensemble. Toute page connectée renvoyait ensuite à l'écran de connexion.
La correction
La route de déconnexion ne répond plus qu'au POST, et le lien est devenu un formulaire dont le bouton envoie ce POST ; un préchargement n'émet jamais de POST. Vérifié sur une version de production locale : un GET sur la route renvoie 405 et la session survit, l'envoi du formulaire déconnecte et efface le témoin, et la session survit au préchargement dans un navigateur automatisé, sans erreur de console.
La règle que nous en gardons
Une action qui change un état ne se déclenche jamais par un GET, quel que soit le cadre employé : c'est un principe du protocole, et le préchargement est l'une des façons dont il se rappelle à vous. Une validation de bout en bout se fait sur la version de production, parce que le développement n'exécute pas les mêmes optimisations.
Un préchargement n'émet jamais de POST, et une action qui change un état ne se déclenche jamais par un GET.