HTTP & fetch : parler au réseau

Chaque écran qui « charge des données » fait la même chose sous le capot : il envoie un message texte à un serveur et attend un message texte en retour. Ce protocole s'appelle HTTP, l'outil du navigateur s'appelle fetch, et tu t'en sers déjà tous les jours sans le voir — Supabase le fait pour toi. Ce module soulève le capot : en entrevue frontend, HTTP est un incontournable absolu.

Le modèle requête/réponse — la conversation la plus simple du monde

HTTP (HyperText Transfer Protocol) repose sur une idée d'une simplicité désarmante : un client (ton navigateur, ton app mobile) envoie une requête à un serveur, qui renvoie une réponse. Une question, une réponse, fin de la conversation. Le client a toujours l'initiative : le serveur ne parle que quand on l'interroge.

Détail crucial, souvent demandé en entrevue : HTTP est sans état (stateless). Chaque paire requête/réponse est indépendante : la réponse envoyée, le serveur oublie tout. Imagine un guichet où l'employé perd la mémoire entre chaque client — pour qu'il sache qui tu es, tu dois re-présenter ta carte à chaque passage. D'où le jeton (Authorization: Bearer ...) embarqué dans chaque requête authentifiée.

Avant d'envoyer une requête, il faut savoir où : c'est le rôle de l'URL, une adresse postale structurée. Prenons-en une de RendezVous, notre app-exemple :

https://rendezvous.app/api/services?service=bone-scan&lang=fr
└─┬─┘   └─────┬──────┘└─────┬─────┘└───────────┬────────────┘
protocole    hôte         chemin          query string

Quatre morceaux, quatre rôles : comment parler, à qui, quoi demander, et avec quelles précisions.

• Le protocole (https://) : la langue de l'échange. Le s signifie que la conversation est chiffrée — personne entre toi et le serveur ne peut la lire. Aujourd'hui, tout est en HTTPS.
• L'hôte (rendezvous.app) : le nom du serveur, que le DNS — l'annuaire du web — traduit en adresse IP.
• Le chemin (/api/services) : la ressource demandée sur ce serveur. Un couloir et un numéro de porte dans l'immeuble.
• La query string (?service=bone-scan&lang=fr) : des paramètres optionnels en paires clé=valeur séparées par des &, toujours après le ?. Ici : « filtre sur bone-scan, en français ».

Anatomie d'une requête et d'une réponse

Une requête et une réponse HTTP sont — littéralement — du texte structuré, lisible à l'œil nu. Chacune a trois parties, en miroir. La requête : ligne de commande (méthode + chemin), en-têtes (métadonnées en Clé: valeur), corps optionnel. La réponse : ligne de statut (le verdict chiffré), en-têtes, corps (souvent du JSON, parfois du HTML, une image…).

Voici une vraie paire complète, telle qu'elle circule quand RendezVous charge sa liste de services. Lis-la lentement — c'est la Pierre de Rosette de tout le module :

─── REQUÊTE (du navigateur vers le serveur) ───────────────

GET /api/services HTTP/1.1
Host: rendezvous.app
Accept: application/json
Authorization: Bearer eyJhbGciOiJIUzI1...

(pas de corps : un GET ne fait que demander)

─── RÉPONSE (du serveur vers le navigateur) ───────────────

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 182

[
  { "id": "bone-scan",  "name": "Scintigraphie osseuse", "durationMin": 45 },
  { "id": "blood-test", "name": "Prise de sang",         "durationMin": 10 }
]

En haut : « donne-moi /api/services, je comprends le JSON, voici mon jeton ». En bas : « 200, tout va bien, le voilà ». Toute l'infrastructure du web transporte des messages de cette forme.

Remarque la symétrie : la requête ouvre par ce qu'elle veut, la réponse par comment ça s'est passé. Les en-têtes sont des post-its collés sur l'enveloppe : ils décrivent le contenu sans en faire partie. Le corps, séparé par une ligne vide, transporte les données. L'onglet Network des DevTools (dernière section) te présentera exactement ces trois blocs.

Les méthodes : le verbe de la phrase

Le premier mot d'une requête est sa méthode — le verbe, qui annonce l'intention : lire, créer, modifier, supprimer ? Le serveur décide quoi faire selon le couple méthode + chemin. Cinq verbes couvrent l'essentiel :

La distinction la plus importante : GET est sans effet (« safe ») — il ne doit jamais rien modifier côté serveur. C'est un contrat, pas une contrainte technique, mais tout le web repose dessus : les navigateurs pré-chargent des GET, les moteurs de recherche les suivent, les proxys les mettent en cache.

Deuxième notion, adorée des recruteurs : l'idempotence. Une opération est idempotente si la refaire produit le même état que la faire une fois — appuyer cinq fois sur « éteindre » laisse la lampe éteinte. GET, PUT et DELETE le sont ; POST, non, puisqu'il crée du nouveau : envoyer deux fois « réserver ce créneau » risque deux réservations. D'où les « ne cliquez pas deux fois sur Payer » et la protection anti double-tap de tes boutons dans Halterofit.

Ces verbes prennent leur sens dans le style d'API le plus répandu, REST : on expose des ressources (des noms au pluriel dans le chemin) et on agit dessus avec les méthodes. Le mapping canonique de RendezVous :

GET    /api/appointments        → lister mes rendez-vous
GET    /api/appointments/42     → lire le rendez-vous n°42
POST   /api/appointments        → créer un rendez-vous (corps = les détails)
PATCH  /api/appointments/42     → modifier le n°42 (ex. changer l'heure)
DELETE /api/appointments/42     → annuler le n°42

Remarque : le chemin ne contient que des noms (les ressources), jamais de verbes — le verbe, c'est la méthode. Pas de /api/createAppointment : le POST sur la collection dit déjà « créer ».

await fetch(`/api/appointments/${id}`, { method: 'DELETE' });

Les codes de statut : le verdict en trois chiffres

Chaque réponse commence par un nombre à trois chiffres : le code de statut, le verdict du serveur. Le premier chiffre suffit à connaître la famille de l'histoire :

• 2xx — succès. Ta demande a été comprise et exécutée.
• 3xx — redirection. « C'est ailleurs, va voir là-bas » — le navigateur suit tout seul.
• 4xx — erreur du client. Ta requête a un problème : mal formée, pas authentifiée, ressource inexistante.
• 5xx — erreur du serveur. Ta requête était correcte, mais lui a planté.

Retiens la maxime, qui départage 90 % des débogages : 4xx = ta faute, 5xx = la sienne. Un 400 t'invite à corriger ce que tu envoies, un 500 à aller voir les logs du serveur. Le petit panthéon des codes que tu croiseras vraiment, chacun avec sa scène :

Note la nuance 401/403, grand classique d'entrevue : 401 = « je ne sais pas qui tu es » (authentification — présente ta carte) ; 403 = « je sais qui tu es, et tu n'as pas le droit » (autorisation — ta carte n'ouvre pas cette porte). Deux réactions différentes côté frontend : le 401 envoie vers l'écran de connexion, le 403 affiche « accès refusé ».

try {
  const res = await fetch(`/api/appointments/${id}`);
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  render(await res.json());
} catch {
  // « une erreur, c'est que la session a expiré »
  router.push('/connexion');
}

Les en-têtes qui comptent (et le JSON comme lingua franca)

Il existe des dizaines d'en-têtes HTTP, mais en tant que frontend, deux reviennent dans quasiment chaque requête que tu écriras :

Content-Type déclare le format du corps ; sans lui, le destinataire reçoit des octets et doit deviner. application/json, text/html, image/png… Quand toi tu envoies du JSON dans un POST, c'est à toi de poser cet en-tête — l'oublier est une cause classique de 400.

Authorization transporte ta preuve d'identité, au format Bearer <jeton> — une longue chaîne signée (souvent un JWT) obtenue à la connexion. Bearer signifie « porteur » : qui porte le jeton est considéré comme son propriétaire, d'où l'importance de ne jamais le faire fuiter. HTTP étant sans état, il part avec chaque requête — ce que le client Supabase fait silencieusement pour ton app.

Et le corps ? Dans les API modernes, presque toujours du JSON (JavaScript Object Notation) : du texte décrivant objets et tableaux, de syntaxe presque identique aux littéraux JavaScript (clés entre guillemets doubles, pas de fonctions, pas de commentaires). Deux fonctions font le pont entre le monde JS et le monde texte :

// Objet JS → chaîne JSON : pour ENVOYER (le réseau ne transporte que du texte)
const corps = JSON.stringify({ serviceId: 'bone-scan', date: '2026-08-12' });
// → '{"serviceId":"bone-scan","date":"2026-08-12"}'

// Chaîne JSON → objet JS : pour RECEVOIR (redonner vie au texte)
const objet = JSON.parse('{"id":42,"status":"confirmed"}');
// → { id: 42, status: 'confirmed' }  — un vrai objet, avec objet.status

stringify pour émettre, parse pour recevoir. Le réseau ne transporte que du texte ; ces deux fonctions traduisent dans les deux sens.

fetch en profondeur — et LE piège à connaître

Passons à l'outil. fetch est la fonction intégrée au navigateur (et à Node, et à React Native) pour envoyer des requêtes HTTP : tu lui donnes une URL et des options, elle te rend… une Promesse. Tout ce que tu sais de l'asynchrone (JavaScript moderne & l'asynchrone) s'applique mot pour mot.

Mais il y a une subtilité que beaucoup de juniors ratent : fetch se déroule en deux temps, chacun avec sa Promesse. Le premier await fetch(...) se résout dès que les en-têtes sont arrivés — tu obtiens un Response qui connaît le statut, mais dont le corps coule peut-être encore dans le tuyau. Pour lire ce corps, il faut un deuxième await : response.json() rend elle aussi une Promesse.

// Temps 1 : envoyer la requête, attendre le début de la réponse.
const res = await fetch('/api/services');

// L'objet Response sait déjà tout du VERDICT :
res.status  // → 200 (le code de status, un nombre)
res.ok      // → true si le status est entre 200 et 299, false sinon

// Temps 2 : lire le corps en entier et le parser comme du JSON.
// C'est une DEUXIÈME Promesse → un deuxième await.
const services = await res.json();
// services est maintenant un vrai tableau d'objets JS

res.json() finit de télécharger le corps, puis lui applique l'équivalent de JSON.parse. D'où la Promesse : c'est encore de l'attente.

Pour envoyer des données — notre réservation — on passe un deuxième argument à fetch : un objet d'options avec méthode, en-têtes et corps. Toute la théorie des sections précédentes s'assemble ici :

const res = await fetch('/api/appointments', {
  method: 'POST',                                  // le verbe : créer
  headers: {
    'Content-Type': 'application/json',            // "le corps est du JSON"
    'Authorization': `Bearer ${token}`,            // la carte, à chaque requête
  },
  body: JSON.stringify({                           // objet JS → texte JSON
    serviceId: 'bone-scan',
    date: '2026-08-12',
    time: '14:30',
  }),
});

if (!res.ok) throw new Error(`HTTP ${res.status}`); // on y revient juste après
const appointment = await res.json();               // ex. { id: 57, status: 'confirmed' }

Chaque option de fetch correspond à un morceau du message HTTP de la section « Anatomie d'une requête et d'une réponse » : method = le verbe, headers = les post-its, body = le colis.

Venons-en au piège central du module, celui qui justifie la ligne if (!res.ok). Intuition naturelle : « un 404 ou un 500 est une erreur, donc la Promesse de fetch est rejetée et mon catch l'attrape ». Faux. Pour fetch, un 500 est une réussite : la requête est partie, une réponse est revenue. Le facteur a livré l'enveloppe ; que la lettre dise « non » n'est pas son problème. fetch ne rejette que si le réseau lui-même a échoué. C'est donc à toi de vérifier le verdict — la ligne que les juniors oublient, parce qu'en développement tout renvoie 200.

const res = await fetch('/api/services');
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const services = await res.json();

async function loadServices() {
  const res = await fetch('/api/services');
  const services = await res.json();
  return services.map((s) => s.name);
}

const res = await fetch('/api/services');
const services = res.json();

console.log(services.length);
const names = services.map((s) => s.name);

try/catch autour d'un await fetch : quelles erreurs atterrissent où

Armé du fetch honnête, tu peux tracer la carte complète des échecs. Autour d'un await fetch dans un try/catch, il n'existe que trois chemins — savoir lequel produit quoi distingue le frontend qui débogue vite de celui qui patauge :

Deux enseignements. Le catch unifie les deux familles d'échec en un seul endroit où réagir — c'est précisément pour ça qu'on lance soi-même une erreur sur !res.ok, pour faire tomber les deux cas dans le même filet. Et une requête a trois moments — ça charge, ça a marché, ça a raté — qu'une interface honnête affiche tous les trois :

afficherChargement();                                    // 1. ça charge
try { /* le fetch honnête, puis afficherListe(services) */ }  // 2. ça a marché
catch { afficherErreur('Impossible de charger. Réessayer ?'); } // 3. ça a raté
finally { masquerChargement(); }                         // toujours : éteindre le spinner

C'est mot pour mot la structure du handleSignUp décortiqué dans l'asynchrone du guide Halterofit — sablier avant, try/catch autour, finally pour éteindre. Inutile de la re-décortiquer : même patron, autre contexte.

En React, afficherChargement et afficherErreur deviendront des états (isLoading, error) qui pilotent le rendu, et Next.js fournira même des fichiers dédiés loading et error par page. La logique à trois moments, elle, ne changera plus jamais.

POST /api/appointments HTTP/1.1
Host: rendezvous.app
Content-Type: application/json
Authorization: Bearer eyJhbGci...

{"serviceId":"blood-test","date":"2026-08-12","time":"09:00"}

───────────────────────────────────────────

HTTP/1.1 409 Conflict
Content-Type: application/json

{"error":"slot_taken","message":"Ce créneau vient d'être réservé."}

setLoading(true);
try {
  const res = await fetch('/api/appointments');
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  setAppointments(await res.json());
  setLoading(false);          // on éteint le sablier
} catch (err) {
  setError(err.message);
}

CORS, en survol honnête

Un jour — c'est une certitude — tu verras ce message rouge dans la console : « … has been blocked by CORS policy ». Ce module ne fera pas de toi un expert CORS (personne ne l'est vraiment), mais il t'apprend à reconnaître l'erreur et à en parler juste.

Le contexte : ton navigateur exécute du code téléchargé depuis un site, auquel il n'a aucune raison de faire confiance. Sans garde-fou, n'importe quel onglet pourrait envoyer en douce des requêtes à ta-banque.com avec tes cookies de session et lire les réponses. D'où la politique de même origine : le code d'une origine (le trio protocole + hôte + port) ne peut pas lire les réponses d'une autre origine. CORS (Cross-Origin Resource Sharing) est le mécanisme d'exception : le serveur interrogé déclare, via l'en-tête de réponse Access-Control-Allow-Origin, « j'accepte que les pages de telle origine lisent mes réponses ».

Le point qui échappe à presque tout le monde, et qu'il faut savoir dire en entrevue : CORS est une politique du NAVIGATEUR, pas du serveur. Quand une requête est « bloquée par CORS », il arrive qu'elle soit partie et que le serveur ait répondu — c'est le navigateur qui, faute d'en-tête d'autorisation, refuse de livrer la réponse à ton JavaScript. Preuves : la même requête via curl ou Postman passe sans problème, et ton app React Native n'a jamais eu ce souci avec Supabase. Une erreur CORS ne dit donc pas « le serveur refuse », mais « le serveur n'a pas déclaré qu'il acceptait ton origine ».

const res = await fetch('https://api.partenaire.com/slots', {
  mode: 'no-cors',
});
const slots = await res.json();

L'onglet Network : ton réflexe n°1 quand « ça ne charge pas »

Dernière pièce, un outil et non un concept. L'onglet Network des DevTools enregistre toutes les requêtes émises par la page : chaque fetch, chaque image, chaque fichier. Quand quelque chose « ne charge pas », le réflexe professionnel n'est pas de relire son code en plissant les yeux, c'est d'ouvrir Network, de recharger et de regarder ce qui s'est réellement passé sur le réseau. En trente secondes tu sais si la requête est partie, vers quelle URL, et ce que le serveur a répondu.

Tu y vois d'abord la waterfall (cascade) : la liste chronologique des requêtes, chacune avec une barre montrant son début et sa durée. Elle se lit comme un récit — le HTML, puis le CSS et le JS qu'il référence, puis les requêtes API, puis les images. Barre anormalement longue = goulot d'étranglement ; ligne rouge = échec ; barres en escalier bien séquentiel = requêtes qui s'attendent alors qu'elles auraient pu partir en parallèle. Clique sur l'une d'elles et tu retrouves en onglets les morceaux de la section « Anatomie d'une requête et d'une réponse » : Headers (méthode, URL, statut, en-têtes des deux sens — c'est là qu'on vérifie qu'un Authorization est parti), Payload (le corps envoyé), Response (le corps reçu, brut) et Preview (le même, déplié).

La checklist de débogage tient en quatre questions : la requête apparaît-elle ? (sinon ton code ne l'a jamais émise) — l'URL est-elle la bonne ? — le statut est-il 2xx ? (sinon : 4xx, regarde ta requête ; 5xx, le serveur) — le corps contient-il ce que tu crois ? Neuf « bugs » de chargement sur dix tombent avant la fin de la liste.

Name                    Status    Type       Size      Time
appointments            401       fetch      89 B      210 ms