Cette page ne liste pas des fonctionnalités du framework. Elle décrit les décisions concrètes que nous prenons sur un projet Next.js, les défauts que nous retrouvons le plus souvent dans du code existant, et les situations où nous vous disons franchement qu'un autre outil ferait mieux l'affaire. Tout se traite par écrit, depuis Dijon, avec une réponse sous 24 heures ouvrées.
Le mode de rendu se décide route par route, pas une fois pour tout le site
Il n'existe pas de réglage unique à cocher au début du projet. Sur un même site, une page éditoriale se prégénère au build via generateStaticParams et se rafraîchit par revalidation incrémentale, une fiche produit dont le stock bouge vit mieux avec une revalidation courte ou une invalidation par étiquette, et un espace derrière authentification n'a aucune raison d'être mis en cache. C'est le type d'arbitrage que pose une boutique comme Chouchou Ribeyre (Next.js, Supabase, Stripe), où catalogue, pages de contenu et parcours de commande n'ont pas les mêmes exigences.
Le piège le plus fréquent tient en une ligne. Une invocation de cookies() ou headers() glissée dans un layout partagé, souvent pour une bannière ou un test d'affichage, fait basculer tout un segment de l'arbre en rendu dynamique. Le site continue de fonctionner, personne ne le remarque, et des pages qui auraient dû partir du cache repassent par le serveur à chaque visite. Nous lisons donc la sortie du build, qui indique pour chaque route si elle est statique, dynamique ou revalidée, et nous traitons toute bascule non voulue comme un défaut à corriger avant la mise en ligne, pas comme un détail à regarder plus tard.
La frontière serveur/client, là où la plupart des projets dérapent
La directive use client ne rend pas un composant interactif, elle marque une frontière. Tout ce qui est importé en dessous part dans le paquet envoyé au navigateur. Placée trop haut, par exemple sur un layout parce qu'un menu déroulant en avait besoin, elle entraîne des pages entières côté client et annule l'intérêt des composants serveur. Le symptôme est reconnaissable : un JavaScript qui gonfle au fil des semaines, une interactivité qui tarde, des données qui transitent inutilement dans la charge utile de la page.
La méthode est ennuyeuse mais elle tient. On descend la frontière le plus bas possible, on isole les îlots interactifs (formulaire, carrousel, filtre, carte, lecteur vidéo) et on laisse le reste en composants serveur. Les données sont chargées côté serveur puis passées en propriétés sérialisables, ce qui évite d'exposer des clés d'API et supprime une partie des requêtes réseau depuis le navigateur. Les bibliothèques lourdes, éditeurs de texte ou graphiques, sont chargées à la demande. Sur un projet repris à une autre équipe, la première chose que nous cartographions est justement l'ensemble des composants client : cette carte raconte l'histoire technique du site mieux que n'importe quelle documentation.
Cache, revalidation, chargement des données : trois sujets à ne pas confondre
Le cache de Next.js n'est pas une couche unique mais plusieurs mécanismes superposés : cache des données côté serveur, cache de rendu des routes, cache du routeur côté navigateur. Savoir lequel est en cause quand un contenu publié n'apparaît pas, c'est la différence entre une correction en dix minutes et une journée de tâtonnements. La règle que nous appliquons : chaque source de données a un propriétaire et un mode d'invalidation explicite. Une publication dans le CMS déclenche une revalidation ciblée sur les étiquettes concernées (la liste, la page, le plan du site) plutôt qu'un délai fixe qui laisse du contenu périmé en ligne ou qui fait travailler l'origine pour rien.
Le chargement des données mérite la même rigueur. Des attentes empilées en séquence dans un composant serveur créent une cascade : chaque requête attend la précédente et le temps de réponse devient la somme des latences. Les requêtes indépendantes partent en parallèle, les fragments lents sont isolés derrière Suspense pour que l'essentiel de la page soit envoyé tout de suite. Nous mesurons ensuite en conditions réelles, pas seulement en local : un rendu rapide sur une machine de développement peut se dégrader dès que la base de données se retrouve loin du serveur qui rend les pages.
Métadonnées, images, polices, redirections : le travail invisible qui décide du référencement
generateMetadata s'exécute côté serveur et peut interroger la même source que la page, à condition que la requête soit dédupliquée, sinon la même donnée est chargée deux fois. On y traite le titre, la description, l'URL canonique, les alternates hreflang quand le site est multilingue, et les balises de partage. Notre propre site est publié en huit langues : nous savons ce que coûte un hreflang incohérent, et pourquoi ces balises doivent être générées à partir de la configuration des locales, jamais écrites à la main page par page. Même principe pour les données structurées, dérivées des objets qui servent à l'affichage, sinon le balisage finit par décrire une page qui a changé depuis.
Le composant image ne fait pas tout à votre place. Sans attribut sizes correct, le navigateur télécharge une image trop grande sur mobile. Sans priorité sur le visuel de premier écran, le plus grand élément visible s'affiche en retard. Les polices servies depuis votre domaine, avec réservation d'espace, suppriment une source classique de décalage visuel. Enfin, une refonte se prépare par un inventaire des adresses existantes, correspondance une par une vers les nouvelles URL, redirections permanentes sans chaîne ni boucle, vérification après mise en ligne. C'est la partie la moins spectaculaire d'un projet et celle dont l'oubli coûte le plus cher.
Hébergement, réversibilité, et les cas où Next.js n'est pas la bonne réponse
Vercel est l'environnement pour lequel Next.js est conçu et, pour beaucoup de projets, c'est le chemin le plus direct. Il n'a pas à devenir un point de non retour. Certaines briques dépendent de la plateforme : optimisation des images, stockage des pages revalidées, exécution du middleware en périphérie. Sur un serveur ou dans un conteneur, elles doivent être remplacées explicitement, avec une sortie standalone, un stockage partagé pour le cache si plusieurs instances tournent, et un service d'images choisi en connaissance de cause. Nous avons fait ce déménagement pour notre propre site, ce qui nous évite de le théoriser. Si la localisation des données ou de l'hébergement compte pour votre organisation, notamment au regard du RGPD, ce point se tranche au départ et se vérifie auprès des textes officiels ou de votre conseil, pas sur la parole d'un prestataire.
Reste la question que peu d'agences posent. Un site de quelques pages, mis à jour par une personne non technique et sans besoin applicatif, sera souvent mieux servi par un outil qu'elle maîtrise déjà. Une application entièrement derrière authentification, sans enjeu de référencement, peut se contenter d'une architecture plus simple. Next.js se justifie quand un même projet doit à la fois être visible dans les moteurs, charger vite et porter une logique métier. Si votre besoin est ailleurs, nous vous le disons avant le devis, pas après.
