Rendu & data fetching

Une page web, c'est du HTML. La seule vraie question, celle qui structure tout ce module, c'est : qui fabrique ce HTML, et à quel moment ? Le navigateur de l'utilisateur ? Le serveur, à l'instant de la requête ? Une machine de compilation, la semaine dernière ? Chaque réponse donne une expérience différente, un coût différent, un référencement différent. Et par-dessus vient la deuxième question, inséparable de la première : d'où viennent les données qui remplissent ce HTML, et combien de temps fait-on attendre l'utilisateur pour les obtenir.

Quatre façons de fabriquer une page

Avant Next.js, avant React, il n'y avait qu'une façon de faire : le serveur générait le HTML et l'envoyait. Puis les applications sont devenues interactives et le pendule est parti à l'autre extrême — page vide plus JavaScript, le navigateur construit tout. Aujourd'hui il est revenu au milieu, et le milieu a quatre positions, avec des acronymes que tu vas entendre en entrevue. Elles ne s'opposent pas : dans une vraie application, tu en emploies plusieurs, page par page — c'est tout l'intérêt de Next.js, te laisser choisir par route plutôt que pour l'application entière.

La première, le CSR (Client-Side Rendering : le navigateur assemble tout), a déjà été déroulée pas à pas dans le module Server et Client Components — page blanche, puis spinner, puis contenu, chaque étape coûtant un aller-retour. On ne la redéroule pas ici ; retiens qu'elle ne coûte presque rien au serveur, beaucoup au client, et qu'elle reste défendable derrière une authentification, là où le référencement n'importe pas et où l'utilisateur reste longtemps dans l'application (un tableau de bord d'administration, un éditeur). Les trois autres méritent qu'on s'y arrête.

SSR — Server-Side Rendering : le serveur rend à chaque requête

À chaque visite, le serveur exécute les composants, va chercher les données, produit le HTML complet et l'envoie. Le navigateur reçoit une page déjà remplie : le texte est lisible avant même que le moindre JavaScript ait été exécuté, celui-ci arrivant ensuite pour « brancher » l'interactivité par-dessus — l'hydratation du module sur les Server et Client Components.

Mille visiteurs = mille rendus, et autant de requêtes à ta base. Quand la choisir : quand le contenu dépend de l'instant présent ou de l'utilisateur — un panier, un tableau de bord personnalisé, des données qui changent d'une minute à l'autre.

SSG — Static Site Generation : rendu une fois, à la construction

Le HTML est fabriqué une seule fois, au déploiement (le build). Le résultat est un fichier sur disque, qu'on pose sur un CDN — un réseau de serveurs répartis dans le monde qui servent depuis la machine la plus proche de l'utilisateur. Plus aucun calcul à la visite : on lit un fichier et on l'envoie.

Indépassable en vitesse et gratuit à la visite ; en revanche le contenu est figé jusqu'au prochain déploiement, et avec cent mille pages produits le build peut durer très longtemps. Quand la choisir : pour tout ce qui ne change pas à la minute — une page « à propos », une documentation, un article de blogue, une liste de services.

ISR / régénération : statique, mais rafraîchi

L'Incremental Static Regeneration est le compromis malin : la page est servie comme du statique, mais elle porte une date de péremption. Passé ce délai, la prochaine visite déclenche en arrière-plan une re-fabrication ; le visiteur en cours reçoit encore l'ancienne version (donc instantanément), le suivant reçoit la neuve. Personne n'attend pour avoir de la fraîcheur — on accepte simplement quelques minutes de retard.

On paie un rendu occasionnel au lieu d'un rendu par visite, contre l'acceptation d'une fenêtre de données périmées. Quand la choisir : dès que la donnée change régulièrement mais pas continuellement et qu'un léger décalage est sans conséquence — un catalogue de prix, une liste d'articles, un classement.

// A — app/services/page.tsx
export default async function Page() {
  const services = await db.service.findMany({ where: { actif: true } });
  return <ListeServices services={services} />;
}

// B — app/mes-rendez-vous/page.tsx
export default async function Page() {
  const session = await lireSession();
  const rdv = await db.rdv.findMany({ where: { patientId: session.id } });
  return <ListeRendezVous rdv={rdv} />;
}

Charger des données dans un Server Component

Passons au code, et à la bonne surprise de l'App Router. Dans un Server Component (module sur les Server et Client Components), le composant lui-même peut être async. Tu peux donc awaiter directement dans le corps du composant. Le rendu attend, et la fonction ne retourne son JSX qu'une fois les données là.

// Server Component : ce fichier ne part JAMAIS dans le navigateur.
// Le mot-clé `async` sur un composant n'existe QUE côté serveur.
export default async function Page() {
  // On attend la réponse ici, dans le composant lui-même.
  const res = await fetch('https://api.exemple.ca/services');

  // Le fetch honnête : vérifier le verdict soi-même (module HTTP & fetch).
  if (!res.ok) throw new Error('Chargement impossible');

  const services = await res.json();

  // Ce JSX n'est produit qu'une fois `services` disponible.
  return (
    <ul>
      {services.map((s) => (
        <li key={s.id}>{s.name} — {s.durationMin} min</li>
      ))}
    </ul>
  );
}

Neuf lignes utiles. Aucun état, aucun effet, aucun booléen isLoading. Le composant est la fonction de chargement.

Compare avec ce que tu écris tous les jours dans ton app mobile : un useState pour les données, un autre pour le chargement, un troisième pour l'erreur, un useEffect pour déclencher la requête après le premier rendu, la gestion du composant démonté avant la fin, et trois branches de rendu. Une trentaine de lignes pour afficher une liste.

Mais le gain n'est pas d'abord une histoire de lignes économisées : il est structurel, et il porte un nom, la cascade client (waterfall). Avec useEffect, une requête ne peut partir qu'après le premier rendu du composant, et un enfant ne se rend qu'après son parent. Si la page charge l'utilisateur, puis un enfant charge ses rendez-vous, puis un petit-enfant les détails d'un service, tu obtiens trois requêtes strictement en série et trois spinners qui s'allument l'un après l'autre — cette interface qui se remplit par étages pendant deux secondes.

Côté serveur, le problème disparaît en grande partie : le serveur est à côté de la base — pas à l'autre bout d'un réseau mobile — donc chaque requête coûte des millisecondes, et Next.js rend les segments de route en parallèle, chacun commençant à chercher ses données sans attendre ses voisins. La cascade qui reste — deux await l'un après l'autre dans le même composant — se règle en section « Séquentiel ou parallèle : le piège des deux await ».

export default async function Page() {
  const res = await fetch('https://api.exemple.ca/services');
  if (!res.ok) throw new Error('Chargement impossible');
  const services = await res.json();
  return <ListeServices services={services} />;
}

Le cache, honnêtement

Voici la section la plus importante du module, et celle où tu dois te méfier de ce que tu liras ailleurs.

Dans Next.js aujourd'hui, fetch n'est pas caché par défaut. Une requête non cachée bloque le rendu de la page jusqu'à ce qu'elle se résolve. Si ton API met 800 ms, la page met 800 ms de plus à commencer à s'afficher. C'est le comportement par défaut, et il est volontairement prudent : mieux vaut une page lente et juste qu'une page rapide affichant des données périmées à l'insu du développeur.

Pourquoi insister ? Parce que ce n'était pas le cas avant. À l'époque de Next.js 14, la situation était inversée : fetch était caché par défaut, agressivement, et il fallait désactiver ce cache explicitement pour obtenir de la fraîcheur. Ce renversement a fait couler beaucoup d'encre, parce qu'un cache par défaut invisible produisait des bugs déconcertants — « pourquoi ma page affiche encore l'ancien prix ? ». Le web est aujourd'hui plein de tutoriels, de billets de blogue et de réponses sur les forums qui décrivent l'ancien comportement. Ils ne sont pas malhonnêtes : ils sont datés. Quand tu lis un article sur le cache de Next.js, cherche sa date et sa version avant de lire son contenu.

Ceci dit, il y a une chose que Next.js fait bel et bien tout seul, et qu'il ne faut pas confondre avec du cache : la mémoïsation par requête. Deux fetch identiques dans le même arbre de rendu, pendant le traitement de la même requête entrante, ne partent qu'une seule fois sur le réseau ; le second reçoit le résultat du premier. Détail crucial : cette déduplication ne dure que le temps d'une requête. Le visiteur suivant repart de zéro. Ce n'est donc pas du cache — c'est un anti-doublon.

La conséquence pratique est libératrice, et elle mérite d'être soulignée parce qu'elle va contre un réflexe très ancré : tu n'as plus besoin de faire descendre les données en props. Si l'entête et le pied de page ont tous les deux besoin des coordonnées de la clinique, chacun peut simplement les demander là où il en a besoin. Une seule requête réseau partira. Fini le prop drilling, ce cortège de props qu'on fait traverser cinq composants qui ne s'en servent pas, juste pour atteindre le sixième.

// `cache` de React mémoïse une fonction pour la durée d'UNE requête entrante.
// Utile quand ce n'est pas un fetch identique (ex. une requête base de données),
// que la mémoïsation automatique de fetch ne couvre pas.
import { cache } from 'react';

export const getClinique = cache(async () => {
  const res = await fetch('https://api.exemple.ca/clinique');
  if (!res.ok) throw new Error('Clinique introuvable');
  return res.json();
});

// Dix composants peuvent appeler getClinique() pendant le rendu :
// le travail n'est fait qu'une fois. Mais la requête suivante,
// venue d'un autre visiteur, repart avec un cache vide.

React.cache() est un anti-doublon intra-requête, comme la mémoïsation de fetch — pas un cache entre visiteurs.

Alors comment cache-t-on vraiment, c'est-à-dire d'une visite à l'autre ? Par un opt-in explicite — autrement dit, rien ne se cache tant que tu ne l'as pas demandé — avec la directive 'use cache'. On la pose en première ligne du corps d'une fonction asynchrone, ou d'un composant, et son résultat devient réutilisable. Elle s'accompagne d'un modèle plus large appelé Cache Components, activé par une option de configuration, et bâti sur le Partial Pre-Rendering : l'idée qu'une même page peut mélanger des morceaux pré-rendus servis instantanément et des morceaux calculés à la requête, dans le même document.

import { cacheLife, cacheTag } from 'next/cache';

// Composant caché : tout le monde voit la même liste de services.
async function ListeServices() {
  'use cache';         // ← l'opt-in explicite : ce résultat est réutilisable
  cacheLife('hours');  // ← sa durée de vie
  cacheTag('services'); // ← une étiquette, pour l'invalider plus tard

  const res = await fetch('https://api.exemple.ca/services');
  const services = await res.json();

  return (
    <ul>
      {services.map((s) => <li key={s.id}>{s.name}</li>)}
    </ul>
  );
}

'use cache' est une directive : une chaîne de caractères en tête de fonction, comme 'use client'. Ce n'est pas un appel de fonction, et c'est pour ça qu'elle se place à cet endroit précis.

Un mot sur cacheTag('services'), parce que c'est la moitié d'un aller-retour et que la seconde moitié arrive deux modules plus loin. Poser une étiquette ne sert à rien en soi : elle prend son sens le jour où quelqu'un modifie les services et doit dire à Next.js « ce que tu as gardé sous cette étiquette est périmé, jette-le ». Cette phrase-là s'écrit revalidateTag('services'), et tu la verras dans le module Route Handlers & Server Actions. Retiens la boucle entière plutôt que ses deux moitiés : on étiquette à la lecture, on invalide par la même étiquette à l'écriture. Une étiquette qu'on ne révoque jamais est un cache qui ment ; une révocation sur une étiquette qu'on n'a jamais posée ne fait rien.

Retiens la ligne de partage, plus que la syntaxe exacte : ce que tout le monde voit pareil se cache ; ce qui dépend de l'utilisateur ou de l'instant présent ne se cache pas. La liste des services de la clinique : cachée. Les rendez-vous de Patrick : jamais. Et pour ce qui ne se cache pas mais met du temps, il existe une autre réponse que le cache — l'envoyer plus tard, sans bloquer le reste. C'est le streaming, et c'est la section suivante.

export default async function Page() {
  const res = await fetch('https://api.exemple.ca/services');
  const services = await res.json();
  return <ListeServices services={services} />;
}

// LECTURE — app/services/liste.tsx
import { cacheLife, cacheTag } from 'next/cache';

async function ListeServices() {
  'use cache';
  cacheLife('hours');
  cacheTag('services');

  const res = await fetch('https://api.exemple.ca/services');
  return <Liste services={await res.json()} />;
}

// ÉCRITURE — la fonction serveur qu'appelle l'outil interne
export async function modifierPrix(id: string, prix: number) {
  await db.service.update({ where: { id }, data: { prix } });
  // ... et c'est tout
}

Le streaming : envoyer la page en morceaux

Le rendu serveur a un défaut structurel : il est tout ou rien. Le serveur assemble la page complète, puis l'envoie. Conséquence mécanique : la donnée la plus lente détermine le temps d'affichage de toute la page. Si l'entête, le menu et la liste des services sont prêts en 20 ms mais que les créneaux disponibles demandent 900 ms à un système de réservation externe, l'utilisateur regarde une page blanche pendant 900 ms. Alors qu'on avait de quoi remplir son écran presque tout de suite.

Le streaming casse cette règle. Au lieu d'attendre que tout soit prêt, le serveur découpe la page en morceaux et les envoie au fur et à mesure, sur la même réponse HTTP maintenue ouverte. Le navigateur affiche ce qu'il reçoit dès qu'il le reçoit. Concrètement : l'entête, le menu et les services arrivent immédiatement, avec un espace réservé — un squelette — à la place des créneaux ; puis, quand le système de réservation répond enfin, le morceau manquant arrive et vient remplacer le squelette. Une seule navigation, aucun appel réseau supplémentaire, et un écran utile dès la première centaine de millisecondes.

Il y a deux façons de faire du streaming, et elles se distinguent par leur granularité.

loading.js — le segment entier

Tu crées un fichier loading.tsx à côté de ton page.tsx, dans le même dossier. Il exporte un composant qui décrit l'écran d'attente. Next.js s'occupe du reste : en coulisses, il enveloppe automatiquement ta page dans une frontière <Suspense> dont le fallback est ce composant. Zéro câblage à écrire — c'est une convention de nom, comme page et layout (module sur le routing).

// Ce composant s'affiche pendant que app/creneaux/page.tsx charge ses données.
// Next.js l'enveloppe tout seul dans un <Suspense> : rien à câbler.
export default function Loading() {
  return (
    <div className="squelette">
      {/* Des blocs gris à la forme des vraies cartes de créneaux */}
      <div className="squelette__ligne" />
      <div className="squelette__ligne" />
      <div className="squelette__ligne" />
    </div>
  );
}

Une convention de fichier, pas une API à mémoriser. Le layout parent, lui, reste affiché : seule la zone de la page est remplacée par cet écran d'attente.

<Suspense> — le grain fin

loading.js est grossier : il masque toute la page, même les parties qui étaient prêtes. Pour un contrôle plus fin, tu places toi-même des frontières <Suspense> autour des seuls composants qui attendent des données. Tout ce qui est hors de la frontière part immédiatement ; ce qui est dedans est remplacé par son fallback, puis streamé quand il est prêt.

import { Suspense } from 'react';
import AvailableSlots from './slots-disponibles';
import SqueletteCreneaux from './squelette-slots';
import ListeServices from '@/components/liste-services';

// La page elle-même n'est PAS async : elle n'attend rien.
export default function Page() {
  return (
    <div>
      {/* Envoyé tout de suite : ces morceaux n'attendent aucune donnée lente */}
      <h1>Prendre rendez-vous</h1>
      <ListeServices />

      {/* Seul ce bloc attend. Le squelette part dans le premier envoi,
          le vrai contenu arrive plus tard sur la même réponse. */}
      <Suspense fallback={<SqueletteCreneaux />}>
        <AvailableSlots />
      </Suspense>
    </div>
  );
}

// Ce composant-là est async : c'est lui qui bloque, et lui seul.
async function AvailableSlots() {
  const res = await fetch('https://api.exemple.ca/slots');
  const slots = await res.json();
  return <SlotGrid slots={slots} />;
}

Le patron à reconnaître : la page devient synchrone, et l'await descend dans un composant enfant qu'on emballe dans <Suspense>. L'attente est ainsi confinée.

Ce déplacement de l'await vers le bas de l'arbre est le geste central à retenir. Plus l'attente est profonde dans l'arbre, plus la partie de la page qui peut partir immédiatement est grande. À l'inverse — et c'est le piège de la section « Des états de chargement et d'erreur qui ne mentent pas » — un await haut placé, dans un layout par exemple, bloque tout ce qui est en dessous.

import { Suspense } from 'react';

export default async function Page() {
  const creneaux = await getCreneaux();   // 900 ms

  return (
    <div>
      <h1>Prendre rendez-vous</h1>
      <ListeServices />

      <Suspense fallback={<SqueletteCreneaux />}>
        <SlotGrid creneaux={creneaux} />
      </Suspense>
    </div>
  );
}

Séquentiel ou parallèle : le piège des deux await

Voici un bug de performance que tu écriras — tout le monde l'écrit — parce que le code fautif est parfaitement lisible et parfaitement naturel :

export default async function Page() {
  // ⚠️ Ces deux requêtes s'exécutent l'une APRÈS l'autre.
  const services = await getServices();   // 400 ms
  const cliniques = await getCliniques(); // 300 ms
  // Total : 700 ms — alors qu'elles ne dépendent pas l'une de l'autre.

  return <Reservation services={services} cliniques={cliniques} />;
}

Le mot await signifie littéralement « arrête-toi ici et attends ». La deuxième requête ne part même pas avant que la première soit revenue.

await met la fonction en pause : tant que getServices() n'a pas répondu, la ligne suivante n'existe pas. La requête vers les cliniques ne part donc qu'à la 401^e milliseconde, alors que rien ne l'obligeait à attendre — on additionne deux latences qui auraient pu se recouvrir.

La correction repose sur un point de JavaScript à avoir bien en tête : une fonction asynchrone démarre son travail dès qu'on l'appelle, pas au moment où on l'await. Appeler sans await, c'est allumer le feu sous la casserole et passer à autre chose ; on obtient une Promesse. On lance donc les deux, puis on attend les deux ensemble avec Promise.all :

export default async function Page() {
  // On APPELLE sans await : les deux requêtes partent tout de suite,
  // on récupère deux Promesses (deux « accusés de réception »).
  const promesseServices = getServices();
  const promesseCliniques = getCliniques();

  // Puis on attend les deux ensemble. Le tableau destructuré donne
  // les résultats dans le MÊME ordre que les promesses fournies.
  const [services, cliniques] = await Promise.all([
    promesseServices,
    promesseCliniques,
  ]);
  // Total : ~400 ms — la durée de la PLUS LENTE, pas la somme.

  return <Reservation services={services} cliniques={cliniques} />;
}

Deux caractères déplacés, 300 ms gagnées. La règle visuelle : deux await consécutifs qui ne s'utilisent pas l'un l'autre = un drapeau rouge.

Un détail de comportement à connaître : Promise.all est tout ou rien. Si une seule promesse échoue, l'ensemble échoue et les autres résultats sont perdus — souvent ce qu'on veut (sans les services, la page n'a pas de sens). Mais quand un échec doit rester local — les créneaux sont indispensables, les avis des patients sont un bonus — on utilise Promise.allSettled, qui attend tout le monde et rend pour chaque promesse un objet décrivant sa réussite ou son échec.

Quand le séquentiel est inévitable

Il existe un cas où l'on ne peut pas paralléliser : quand la deuxième requête a besoin du résultat de la première — pour charger les créneaux d'un service, il faut d'abord connaître son identifiant. C'est une dépendance de données, pas une maladresse d'écriture. Mais si on ne peut pas supprimer l'attente, on peut la rendre supportable : au lieu de bloquer la page entière, on affiche ce que la première requête a rapporté et on streame le reste.

export default async function Page({ params }: { params: Promise<{ slug: string }> }) {
  const { slug } = await params;

  // 1re requête : indispensable pour connaître le service.
  const service = await getService(slug);

  return (
    <>
      {/* Le titre et la description s'affichent DÈS la 1re requête revenue. */}
      <h1>{service.name}</h1>
      <p>{service.description}</p>

      {/* La 2e requête a besoin de service.id : elle ne peut pas
          démarrer avant. Mais elle n'a plus à bloquer le titre. */}
      <Suspense fallback={<SqueletteCreneaux />}>
        <Creneaux serviceId={service.id} />
      </Suspense>
    </>
  );
}

On ne supprime pas la dépendance, on la découpe : ce qui est prêt part, ce qui dépend d'autre chose attend derrière sa propre frontière.

Et pour que la première attente elle-même ne montre pas de page blanche, on ajoute un loading.tsx au segment : écran d'attente immédiat, puis le titre, puis les créneaux. Le principe se résume en une phrase : fais partir tout ce qui peut partir, et mets une frontière devant tout ce qui doit attendre.

export default async function Page() {
  const clinique = await getClinique();   // 120 ms
  const services = await getServices();   // 350 ms
  const avis     = await getAvis();       // 800 ms (service externe, capricieux)

  return (
    <>
      <Entete clinique={clinique} />
      <ListeServices services={services} />
      <Avis avis={avis} />
    </>
  );
}

export default async function Page({
  params,
}: { params: Promise<{ slug: string }> }) {
  const { slug } = await params;

  const service  = await getService(slug);          // 200 ms
  const avis     = await getAvis(slug);             // 500 ms
  const creneaux = await getCreneaux(service.id);   // 300 ms

  return <Fiche service={service} avis={avis} creneaux={creneaux} />;
}

Charger côté client quand il le faut

Tout ce qui précède se passe sur le serveur. Mais certaines données ne peuvent pas venir de là : celles qui apparaissent après une interaction — le patient tape dans un champ de recherche, coche un filtre, clique sur « page suivante », ou tu rafraîchis les créneaux toutes les trente secondes. Il n'y a plus de « rendu initial » pour les porter : elles arrivent en cours de vie de l'écran. Deux voies pour ça.

Le hook use(promise) : le serveur commence, le client termine

Le module « Server et Client Components » a annoncé ce patron du point de vue de la frontière. Voici sa démonstration, sous l'angle du chargement : un Server Component appelle sa fonction de chargement sans l'awaiter, passe la Promesse obtenue en prop, et un Client Component la lit avec le hook use() — en se suspendant, donc en déclenchant le fallback du <Suspense> parent, tant qu'elle n'est pas résolue.

import { Suspense } from 'react';
import SlotGrid from './grille-slots';

export default function Page() {
  // PAS de await : on veut la Promesse elle-même, pas son résultat.
  // La requête part quand même immédiatement (une fonction async
  // démarre à l'appel, pas à l'await).
  const promesseCreneaux = getCreneaux();

  return (
    <Suspense fallback={<SqueletteCreneaux />}>
      <SlotGrid slots={promesseCreneaux} />
    </Suspense>
  );
}

'use client';
import { use, useState } from 'react';

export default function SlotGrid({
  slots,
}: {
  slots: Promise<Creneau[]>; // ← le type dit bien : une Promesse, pas des données
}) {
  // `use` lit la Promesse. Le composant se SUSPEND tant qu'elle n'est
  // pas résolue → c'est le fallback du <Suspense> parent qui s'affiche.
  const liste = use(slots);

  // Et comme on est côté client, on peut être interactif :
  const [selection, setSelection] = useState<string | null>(null);

  return (
    <div>
      {liste.map((c) => (
        <button key={c.id} onClick={() => setSelection(c.id)}>
          {c.heure}
        </button>
      ))}
    </div>
  );
}

Le meilleur des deux mondes : la requête part du serveur, au plus tôt, mais le composant qui l'affiche est interactif. Aucune cascade client.

Sans ce patron, tu aurais deux mauvaises options : awaiter côté serveur et perdre l'interactivité, ou faire un useEffect côté client — et alors la requête ne partirait qu'après le téléchargement du JavaScript, son exécution et le premier rendu. Ici, la requête part au plus tôt (serveur) et le rendu arrive au plus tôt (client). React précise qu'on peut aussi passer cette Promesse par un contexte, si plusieurs Client Components ont besoin du même résultat.

SWR et TanStack Query : quand la donnée vit après le chargement

Le hook use résout un chargement initial ; dès que la donnée doit être rechargée en réponse à une interaction, il faut autre chose. C'est le terrain de deux bibliothèques que tu croiseras dans à peu près toutes les offres d'emploi frontend : SWR (par l'équipe de Vercel) et TanStack Query (anciennement React Query, plus riche et indépendante du framework).

'use client';
import useSWR from 'swr';

const fetcher = (url: string) => fetch(url).then((r) => r.json());

export default function RechercheCreneaux({ date }: { date: string }) {
  // La clé (l'URL) contient `date` : quand la date change, SWR
  // refait la requête tout seul et sert d'abord la donnée en cache.
  const { data, error, isLoading } = useSWR(
    `/api/slots?date=${date}`,
    fetcher,
  );

  if (isLoading) return <SqueletteCreneaux />;
  if (error) return <p>Impossible de charger les créneaux.</p>;

  return <SlotGrid slots={data} />;
}

Une ligne de hook remplace trois useState et un useEffect — et apporte en prime tout ce que tu n'aurais pas écrit à la main.

Ce que ces bibliothèques apportent réellement, au-delà de la concision, tient en quatre points qu'il vaut la peine de savoir énumérer en entrevue :

• Un cache côté client, indexé par clé. Deux composants qui demandent la même clé partagent une requête et une copie ; revenir sur une date déjà consultée affiche la donnée instantanément.
• La revalidation en arrière-plan — le sens du sigle SWR, stale-while-revalidate : on affiche immédiatement la donnée en cache, même un peu vieille, et on va en chercher une fraîche en silence ; si elle a changé, l'écran se met à jour. L'utilisateur ne voit jamais de spinner sur une donnée déjà vue.
• Les états de chargement et d'erreur, gratuits — isLoading, error, et le suivi du composant démonté avant la fin : tout le code ennuyeux du useEffect manuel est déjà écrit, testé, correct.
• La déduplication et le rafraîchissement automatiques. Les requêtes identiques rapprochées sont fusionnées ; un rafraîchissement peut se déclencher quand la fenêtre reprend le focus ou quand la connexion revient — exactement ce que fait ton app mobile quand elle resynchronise au retour au premier plan.

Des états de chargement et d'erreur qui ne mentent pas

Une requête a trois moments — ça charge, ça a marché, ça a raté — et une interface honnête affiche les trois (module HTTP & fetch). Ce qui change ici, c'est qui les affiche : plus toi avec des états, mais des conventions de fichiers.

Pour le chargement, un conseil que la documentation de Next.js formule elle-même : préfère les squelettes aux spinners. Un spinner dit « quelque chose se passe », rien d'autre ; un squelette — des blocs gris à la forme et à la place du contenu à venir — dit « voici ce qui arrive, et où ». Trois bénéfices : la structure se comprend avant d'être remplie, la page ne saute pas quand le contenu arrive (la place était réservée), et l'attente paraît plus courte parce que l'œil a de quoi parcourir. Un bon écran d'attente est un avant-goût fidèle, pas un cache-misère — on peut y mettre les parties déjà connues, image d'entête ou titre, plutôt que de tout masquer.

Pour l'erreur, la convention est le fichier error.tsx, qui définit une frontière d'erreur (error boundary) : si un composant du segment lance une exception pendant le rendu, elle remonte jusqu'à cette frontière, qui affiche son interface de repli au lieu de faire s'effondrer la page. C'est la destination du throw du fetch honnête — le if (!res.ok) throw ... de la section « Charger des données dans un Server Component » finit ici.

'use client'; // une frontière d'erreur est TOUJOURS un Client Component :
              // elle doit pouvoir réagir au clic sur « Réessayer ».

export default function Error({
  error,
  reset,
}: {
  error: Error;
  reset: () => void; // fourni par Next.js : retente le rendu du segment
}) {
  return (
    <div role="alert">
      <h2>Les créneaux n'ont pas pu être chargés.</h2>
      <p>
        Le service de réservation est momentanément indisponible.
        Tu peux réessayer, ou nous joindre au 555-0199.
      </p>
      <button onClick={reset}>Réessayer</button>
    </div>
  );
}

Remarque le message : il dit ce qui a échoué, il propose une action, il offre une porte de sortie. Il n'affiche pas la error.message brute à l'utilisateur.

Un point de conception, plus important que le code : ne montre jamais le message d'erreur technique à l'utilisateur. « TypeError: Cannot read properties of undefined » ne lui apprend rien, l'inquiète, et peut divulguer des détails d'infrastructure. Le message technique va dans les journaux du serveur ; l'utilisateur, lui, reçoit une phrase en français qui dit ce qui a échoué, ce qu'il peut faire et par où passer autrement. « Une erreur est survenue » n'est pas un message, c'est un aveu qu'on n'a pas réfléchi au cas.

Le placement de ces frontières compte autant que leur contenu. Un error.tsx placé à la racine transforme n'importe quel échec en page d'erreur pleine — l'utilisateur perd la navigation, l'entête, tout. Placé au niveau du segment des créneaux, il ne remplace que cette zone. Même logique que pour <Suspense> : plus la frontière est proche du problème, moins l'utilisateur perd.

// app/creneaux/layout.tsx
export default async function Layout({ children }: { children: React.ReactNode }) {
  // Donnée fraîche à chaque requête, non cachée, et lente.
  const clinique = await getCliniqueEnDirect(); // ~900 ms

  return (
    <section>
      <BandeauClinique clinique={clinique} />
      {children}
    </section>
  );
}

// app/creneaux/error.tsx
'use client';

export default function Error({
  error,
  reset,
}: { error: Error; reset: () => void }) {
  return (
    <div role="alert">
      <h2>Une erreur est survenue</h2>
      <p>{error.message}</p>
      <button onClick={reset}>Réessayer</button>
    </div>
  );
}

Le pont offline-first : deux stratégies inverses, un même objectif

Terminons par le lien qui va faire le plus pour ta compréhension, parce qu'il relie ce module à ce que tu fais déjà tous les jours. Dans ton app mobile, l'architecture est local-first : la donnée vit d'abord dans une base SQLite sur l'appareil (WatermelonDB & offline-first, guide Halterofit). Quand un écran s'ouvre, il lit la base locale — quelques millisecondes, pas de réseau — et s'affiche plein immédiatement ; la synchronisation se fait après, en arrière-plan. La source de vérité de l'affichage est locale, le réseau est un rattrapage.

Sur le web, l'architecture est exactement inverse : il n'y a pas de base locale, le premier chargement arrive sur une machine qui ne sait rien de ton application. La donnée vient donc du serveur, et c'est ensuite qu'on la garde sous la main — cache serveur ('use cache'), cache d'un CDN, cache client de SWR ou TanStack Query, cache du routeur pour les navigations suivantes. La source de vérité est distante, le cache est un rattrapage.

Deux stratégies opposées, un seul objectif : que l'écran soit rempli vite. Et deux façons opposées de payer le même prix, celui de la fraîcheur — en local-first tu affiches vite une donnée qui peut être périmée et tu la corriges après ; en server-first avec cache, tu affiches vite une donnée qui peut être périmée et tu la revalides après. Le même compromis, vitesse contre exactitude, résolu depuis deux points de départ. En entrevue, cette mise en perspective vaut de l'or : peu de candidats juniors peuvent expliquer le cache d'une application web en le comparant à une architecture offline-first qu'ils ont réellement mise en œuvre.