async / await : attendre une réponse sans bloquer la page

Ce que vous saurez faire

Lire une fonction async en sachant ce qui est suspendu et ce qui continue, distinguer un échec réseau d’une réponse d’erreur, et placer le catch au bon endroit.

Les exemples se collent dans la console d’un navigateur ou s’exécutent avec node fichier.js (Node.js 18 ou plus récent, où fetch est disponible). Ceux qui appellent /api/users/42 supposent en revanche un serveur qui répond sur cette adresse : sans lui, l’appel échoue.

1. Une Promise est un état, pas un résultat

Une Promise se trouve dans l’un de trois états : en attente, tenue avec une valeur, ou rejetée avec une raison. await ne fabrique pas la valeur, il attend le passage de l’attente vers l’un des deux états finaux.

const promesse = new Promise((resolve) => {
  setTimeout(() => resolve('résultat tardif'), 300);
});

console.log(promesse);         // Promise en attente
console.log(await promesse);   // résultat tardif

Dans la console d’un navigateur, le premier affichage montre une Promise en attente, le second la chaîne, environ trois cents millisecondes plus tard. Ce await au niveau supérieur fonctionne dans la console et dans un module ECMAScript ; dans un fichier .js exécuté par Node.js, placez-le à l’intérieur d’une fonction async.

Référence : Promise.

2. await suspend une fonction, pas le programme

La distinction est facile à vérifier avec de simples minuteurs, sans aucun serveur.

function attendre(ms) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

async function lente() {
  console.log('début de lente');
  await attendre(1000);
  console.log('fin de lente');
}

lente();
console.log('après l’appel');
setTimeout(() => console.log('minuteur indépendant'), 200);

Résultat attendu : début de lente, puis après l’appel, puis minuteur indépendant vers deux cents millisecondes, puis fin de lente vers une seconde. La preuve est là : pendant l’attente, le reste du code s’est exécuté. Seule la suite de lente était suspendue.

L’inverse mérite attention : un calcul synchrone long, placé avant ou après un await, bloque bel et bien tout le reste. await n’ajoute pas de parallélisme, il organise l’attente.

3. Deux familles d’erreurs, un seul catch

fetch() rejette en cas d’échec réseau : serveur injoignable, connexion coupée, requête annulée. Il ne rejette pas parce que la réponse porte un statut 404 ou 500, puisque de son point de vue la réponse est bien arrivée. Ces deux situations demandent donc deux traitements distincts.

async function getUser(id) {
  const response = await fetch('/api/users/' + id); // rejette si le réseau échoue
  if (!response.ok) {                               // 404, 500… à traiter soi-même
    throw new Error('Réponse HTTP ' + response.status);
  }
  return response.json();
}

Une erreur levée dans une fonction async ne se propage pas comme une erreur synchrone : elle transforme la Promise renvoyée en Promise rejetée. Autrement dit, getUser(42) ne plante pas au moment de l’appel ; c’est l’attente de son résultat qui échoue. L’appelant doit donc écrire son propre try / catch, ou attacher un .catch(). Un appel getUser(42); sans rien autour laisse un rejet non géré.

Référence : Utiliser fetch.

Pièges et limites

• Confondre suspension et blocage. await suspend la fonction courante. Une boucle de calcul d’une seconde, elle, gèle réellement la page.
• Oublier le catch de l’appelant. Une fonction async qui lève renvoie une Promise rejetée. Sans catch en aval, l’erreur devient un rejet non géré, souvent visible seulement dans la console.
• Croire que fetch signale les erreurs HTTP. Sans response.ok, un corps d’erreur au format HTML sera passé à response.json(), et l’échec apparaîtra beaucoup plus loin, sous une forme trompeuse.
• Enchaîner des await indépendants. Trois attentes successives s’additionnent alors que les opérations pourraient partir ensemble.

À vous de jouer

Écrivez une fonction lireTitre(url) qui récupère du JSON et renvoie son champ title. Elle doit lever une erreur explicite si le statut n’est pas satisfaisant. Appelez-la ensuite avec une adresse volontairement inexistante de votre propre serveur, et affichez un message lisible dans la console plutôt qu’un rejet non géré. Observez enfin ce qui change si vous retirez le catch de l’appelant.

Correction commentée

async function lireTitre(url) {
  const response = await fetch(url);
  if (!response.ok) {
    throw new Error('Statut inattendu : ' + response.status);
  }
  const donnees = await response.json();
  return donnees.title;
}

lireTitre('/api/articles/introuvable')
  .then((titre) => console.log('Titre :', titre))
  .catch((error) => console.error('Lecture impossible :', error.message));

Pourquoi c’est la bonne réponse. Le contrôle response.ok transforme une réponse d’erreur, que fetch considère comme un succès, en erreur applicative explicite. Le throw placé dans une fonction async produit une Promise rejetée : voilà pourquoi le catch se met sur l’appel, et non dans la fonction. Sans lui, l’environnement signale un rejet non géré et le message reste illisible. Enfin, await response.json() est nécessaire parce que la lecture du corps est elle aussi asynchrone : le corps arrive en flux, pas d’un seul bloc.