Cas pratiques Next.js

Contexte : Une application Next.js contient un menu de navigation vers plusieurs pages internes. Le Problème : La navigation provoque un rechargement complet de la page au lieu d'un routage côté client. Contraintes : Vous devez utiliser le composant Link de Next.js correctement sans ajouter de librairie. Code actuel : export default function Home() { return ( <a href="/about">About</a> ); } Livrable attendu : Modifier le code pour utiliser le système de navigation interne de Next.js sans rechargement complet.

Contexte : Vous reprenez une page Next.js utilisée pour afficher une liste d'articles récupérés côté serveur pour un blog interne. Le Problème : Les données sont bien récupérées dans getServerSideProps mais la page affiche une erreur indiquant que props.articles est undefined. Contraintes : Vous devez corriger uniquement la transmission des props. Aucune librairie externe autorisée. Le rendu doit rester côté serveur. Code actuel : export async function getServerSideProps() { const res = await fetch("https://api.example.com/articles"); const articles = await res.json(); return { articles: articles }; } export default function Blog({ articles }) { return ( <ul> {articles.map(a => ( <li key={a.id}>{a.title}</li> ))} </ul> ); } Livrable attendu : Corriger la structure de retour de getServerSideProps pour que les données soient correctement injectées dans le composant.

Contexte : Une page affiche des images produits importées directement via balise img. Le Problème : Les performances Lighthouse sont mauvaises à cause d'images non optimisées. Contraintes : Utiliser le composant Image de Next.js. Aucune librairie externe. Livrable attendu : Remplacer la balise img par le composant optimisé Image avec width et height appropriés.

Contexte : Une page tente d'utiliser une variable d'environnement pour afficher une clé publique. Le Problème : La variable process.env.API_KEY retourne undefined côté client. Contraintes : Vous devez respecter les conventions Next.js concernant les variables publiques. Livrable attendu : Corriger la configuration pour que la variable soit accessible côté client.

Contexte : Plusieurs pages partagent le même header et footer dans votre application Next.js. Le Problème : Le code est dupliqué dans chaque page. Contraintes : Mettre en place un layout global simple sans librairie externe. Livrable attendu : Créer un composant Layout et l'intégrer dans _app.js pour encapsuler toutes les pages.

Contexte : L'application affiche la page 404 par défaut de Next.js. Le Problème : L'équipe souhaite une page 404 personnalisée respectant la charte graphique. Contraintes : Respecter la convention Next.js pour la page 404. Livrable attendu : Créer un fichier 404.js personnalisé affichant un message clair et un lien de retour à l'accueil.

Contexte : Votre équipe souhaite optimiser les performances d'une page marketing affichant des contenus peu fréquents. Le Problème : La page est actuellement rendue côté client, ce qui ralentit le chargement initial. Contraintes : Utiliser getStaticProps. Aucune librairie externe. Livrable attendu : Implémenter une page Next.js utilisant getStaticProps pour récupérer des données statiques à la build et les afficher correctement.

Contexte : Vous devez rediriger automatiquement les utilisateurs non authentifiés vers la page login. Le Problème : Aucune logique de redirection globale n'est en place. Contraintes : Utiliser le middleware Next.js natif. Livrable attendu : Implémenter un middleware simple qui vérifie une condition et redirige vers /login si nécessaire.

Contexte : Votre application Next.js doit exposer une petite API interne pour retourner un message JSON. Le Problème : Aucun endpoint backend n'existe actuellement dans le projet. Contraintes : Utiliser le dossier pages/api. Retourner une réponse JSON valide. Livrable attendu : Créer une API Route Next.js retournant un objet JSON simple avec un statut 200.

Contexte : Une application Next.js doit afficher le détail d'un produit via une route dynamique basée sur son id. Le Problème : La page affiche toujours undefined pour l'id récupéré dans le composant. Contraintes : Vous devez conserver l'utilisation du router Next.js. Aucune modification de structure globale. Code actuel : import { useRouter } from "next/router"; export default function Product() { const router = useRouter(); const { id } = router.query; return <p>Produit {router.id}</p>; } Livrable attendu : Corriger l'accès au paramètre dynamique afin d'afficher correctement l'id du produit.

Contexte : Vous migrez une application Next.js vers l'App Router (Next 13+). Le Problème : L'architecture actuelle basée sur pages/ devient difficile à maintenir. Contraintes : Structurer proprement les layouts, routes et composants serveur. Livrable attendu : Proposer une structure App Router modulaire avec layouts imbriqués et séparation claire des responsabilités.

Contexte : L'application fonctionne en local mais échoue en production à cause d'une variable d'environnement manquante. Le Problème : Certaines variables ne sont pas accessibles selon le contexte serveur ou client. Contraintes : Respecter les conventions NEXT_PUBLIC et différencier serveur/client. Livrable attendu : Corriger la configuration pour assurer un accès cohérent aux variables d'environnement selon le contexte d'exécution.

Contexte : Une API Route Next.js expose un endpoint POST pour créer un utilisateur. Le Problème : En cas d'erreur, l'API retourne toujours un statut 200, ce qui complique la gestion côté client. Contraintes : Vous devez implémenter une gestion correcte des statuts HTTP. Code actuel : export default function handler(req, res) { if (req.method === "POST") { try { const { name } = req.body; res.status(200).json({ success: true }); } catch (e) { res.json({ error: "Something went wrong" }); } } } Livrable attendu : Corriger la gestion des erreurs pour retourner des statuts HTTP appropriés.

Contexte : Une page affiche une longue liste d'articles récupérés via SSR. Le Problème : Tous les articles sont chargés en une seule fois, ce qui ralentit le rendu. Contraintes : Implémenter une pagination via query params avec getServerSideProps. Livrable attendu : Mettre en place une pagination côté serveur permettant de limiter le nombre d'éléments chargés par page.

Contexte : Une page d'actualités doit être rapide tout en se mettant à jour régulièrement. Le Problème : Le SSR pur est coûteux et le SSG pur ne reflète pas les mises à jour fréquentes. Contraintes : Utiliser Incremental Static Regeneration. Livrable attendu : Implémenter getStaticProps avec revalidate pour permettre une mise à jour périodique automatique.

Contexte : Votre application Next.js doit protéger certaines pages accessibles uniquement aux utilisateurs authentifiés. Le Problème : Actuellement, toutes les routes sont accessibles librement. Contraintes : Aucun framework externe d'authentification. Utiliser middleware ou logique côté serveur. Livrable attendu : Implémenter un mécanisme de protection de route redirigeant les utilisateurs non authentifiés vers /login tout en conservant une bonne expérience utilisateur.

Contexte : Certaines pages de l'application nécessitent un layout différent (dashboard vs site marketing). Le Problème : Le layout global actuel ne permet pas cette flexibilité. Contraintes : Implémenter une solution propre compatible avec _app.js. Livrable attendu : Permettre aux pages de définir dynamiquement leur propre layout sans dupliquer la logique.

Contexte : L'analyse du build montre un bundle JavaScript principal trop lourd. Le Problème : Certaines librairies sont chargées alors qu'elles ne sont utilisées que sur des pages spécifiques. Contraintes : Utiliser le dynamic import natif de Next.js. Livrable attendu : Implémenter un chargement dynamique de composants afin de réduire la taille du bundle initial.

Contexte : Une page produit récupère actuellement ses données côté client via useEffect, provoquant un délai d'affichage initial. Le Problème : Les performances SEO sont impactées et le contenu met du temps à apparaître. Contraintes : Migrer vers getStaticProps avec revalidation ISR. Livrable attendu : Transformer la page pour utiliser SSG avec revalidation automatique afin d'améliorer les performances et le SEO.

Contexte : Vous reprenez une application Next.js utilisant le rendu côté serveur pour afficher un dashboard personnalisé. Le Problème : En production, l'application affiche une erreur d'hydratation indiquant que le contenu rendu côté serveur ne correspond pas au rendu côté client. Contraintes : Vous devez conserver le SSR avec getServerSideProps. Aucune librairie externe autorisée. La correction doit éviter toute divergence entre rendu serveur et client. Code actuel : export async function getServerSideProps() { return { props: { date: new Date().toLocaleString() } }; } export default function Page({ date }) { return <div>{date}</div>; } Livrable attendu : Corriger la logique afin d'éviter les erreurs d'hydratation tout en conservant un rendu cohérent.

Contexte : Vous devez implémenter une authentification robuste dans une application Next.js utilisant SSR pour les pages sensibles. Le Problème : Le token JWT expire et provoque des déconnexions brutales lors des rendus serveur. Contraintes : Aucun framework externe d'authentification. Gestion sécurisée via cookies HTTPOnly. Compatibilité SSR obligatoire. Livrable attendu : Concevoir une architecture complète intégrant login, stockage sécurisé des tokens, refresh automatique côté serveur et protection des routes sensibles.

Contexte : Vous développez une plateforme SaaS multi-tenant où chaque client possède son sous-domaine. Le Problème : L'application doit détecter dynamiquement le tenant et charger les données correspondantes. Contraintes : Utiliser middleware et SSR. Aucune duplication de code par tenant. Livrable attendu : Concevoir une architecture capable d'identifier le tenant via le hostname, charger ses données et sécuriser l'isolation des informations.

Contexte : Une API Route Next.js permet de rechercher des utilisateurs via un paramètre transmis en requête. Le Problème : L'endpoint accepte directement les paramètres sans validation, exposant potentiellement l'application à des injections ou abus. Contraintes : Aucun framework externe de validation. Mise en place d'une validation robuste et gestion des erreurs HTTP. Code actuel : export default function handler(req, res) { const query = req.query.q; const result = database.search(query); res.status(200).json(result); } Livrable attendu : Sécuriser l'API Route avec validation stricte des entrées et gestion appropriée des erreurs.

Contexte : Une application SaaS utilise un middleware Next.js pour vérifier un token à chaque requête. Le Problème : En production, le serveur Edge montre une consommation mémoire croissante et des latences importantes. Contraintes : Vous devez conserver le middleware natif. Aucun framework externe. Le code doit être compatible avec l'environnement Edge Runtime. Code actuel : export function middleware(req) { const token = req.cookies.get("token"); if (!token) { return Response.redirect(new URL("/login", req.url)); } const decoded = JSON.parse(atob(token)); return Response.next(); } Livrable attendu : Identifier et corriger les mauvaises pratiques dans le middleware pour éviter toute surcharge ou traitement inutile.

Contexte : Une application B2B consomme une API coûteuse en temps de réponse pour afficher des tableaux analytiques. Le Problème : Les appels répétés dégradent fortement les performances et augmentent les coûts backend. Contraintes : Utiliser les mécanismes de cache natifs de Next.js (fetch cache, revalidate, headers). Aucun outil externe. Livrable attendu : Mettre en place une stratégie de cache côté serveur avec invalidation conditionnelle garantissant performance et fraîcheur des données.

Contexte : Une API publique intégrée à votre application Next.js reçoit un nombre croissant de requêtes. Le Problème : Aucun mécanisme ne limite les abus ou les attaques par flood. Contraintes : Implémentation maison sans librairie externe. Compatible avec déploiement serverless. Livrable attendu : Concevoir un système simple de rate limiting basé sur IP ou token avec gestion des erreurs HTTP 429.

Contexte : Vous migrez une application volumineuse vers l'App Router de Next.js 13+ en utilisant des Server Components. Le Problème : Certains composants utilisent encore des hooks client, provoquant des erreurs de compilation et une mauvaise séparation serveur/client. Contraintes : Respecter strictement la séparation Server Components / Client Components. Aucune librairie externe. Livrable attendu : Refactoriser l'architecture pour exploiter pleinement les Server Components, réduire le bundle client et structurer correctement les boundaries "use client".

Contexte : Une application analytique affiche plusieurs widgets dépendant de sources de données distinctes. Le Problème : Le rendu SSR bloque tant que toutes les données ne sont pas chargées. Contraintes : Utiliser le streaming SSR avec Suspense dans l'App Router. Aucun outil externe. Livrable attendu : Mettre en place un rendu progressif permettant d'afficher certaines parties de la page pendant que d'autres chargent encore.

Contexte : Une application historique Next.js repose entièrement sur le dossier pages/ avec une logique mêlant rendu serveur et client. Le Problème : L'architecture devient difficilement maintenable et empêche l'exploitation des nouvelles optimisations de Next.js. Contraintes : Migration progressive vers App Router sans interruption de service. Séparation claire server/client. Livrable attendu : Proposer une stratégie de migration structurée vers App Router avec layouts imbriqués, server components et optimisation du bundle.

Contexte : Vous intervenez sur une plateforme e-commerce développée avec Next.js utilisant Incremental Static Regeneration pour afficher des fiches produits. Le Problème : Après certaines mises à jour côté backend, les utilisateurs voient encore d'anciennes données pendant plusieurs minutes. Le mécanisme de revalidation semble mal configuré et provoque des incohérences. Contraintes : Vous devez conserver getStaticProps avec revalidate. Aucune librairie externe autorisée. La solution doit garantir une cohérence forte après mise à jour critique. Livrable attendu : Corriger et améliorer la stratégie ISR afin d'assurer une revalidation fiable, potentiellement en combinant revalidate et revalidation à la demande via API Route sécurisée.