Bloquant et non bloquant
Pourquoi l’attente est un problème, et la réponse JS.
Objectifs
À la fin de cette leçon, vous saurez :
- expliquer pourquoi l'attente est un problème en programmation ;
- distinguer code synchrone et asynchrone ;
- reconnaître les opérations asynchrones types (réseau, timers, fichiers).
Le problème de l'attente
Certaines opérations prennent du temps :
lire un fichier sur disque → millisecondes
interroger une API réseau → dizaines/centaines de ms
une requête SQL → variable
un calcul d'image → secondes
Si le programme s'arrête pendant ces attentes (code bloquant ou synchrone), rien d'autre ne se passe : dans un navigateur, l'interface se fige ; sur un serveur, tous les autres clients attendent.
Pourquoi cette gravité ? Souvenez-vous de l'event loop à venir : JavaScript n'a qu'UN fil. Pendant une attente bloquante, ce fil est occupé à... attendre. Il ne peut ni peindre l'écran, ni répondre au clic suivant, ni servir un autre client. L'attente passive devient un gel total.
Faites l'expérience en console sur n'importe quelle page :
const debut = Date.now();
while (Date.now() - debut < 3000) { /* rien */ }
// pendant 3 secondes : impossible de cliquer, scroller, sélectionner
La réponse de JavaScript : un modèle non bloquant. On lance l'opération, on fournit « quoi faire quand ce sera fini », et on continue :
SYNCHRONE ASYNCHRONE
lireFichier("a.txt") lireFichierAsync("a.txt").then(afficher)
afficher("suite") afficher("suite") ← s'exécute AVANT le fichier !
Dans la version asynchrone, afficher("suite") ne patiente pas : elle tourne pendant que le fichier se lit. Le résultat arrive plus tard, via la fonction fournie. Ce décalage contre-intuitif (« ma ligne s'exécute AVANT celle du dessus ? ») est LE saut mental du chapitre.
Les trois styles historiques
// 1. callback (l'ancien style)
lireFichier("a.txt", function (err, contenu) { ... });
// 2. Promise (le pont)
lireFichierAsync("a.txt").then(function (contenu) { ... });
// 3. async / await (le style moderne, sucre syntaxique des Promises)
const contenu = await lireFichierAsync("a.txt");
Ces trois formes expriment la même chose : fais-le, et continue quand c'est prêt. Les deux prochaines leçons les détaillent.
Opérations asynchrones que vous rencontrerez partout
| Source | Exemple |
|---|---|
| Réseau | fetch(...), appels HTTP client et serveur |
| Fichiers | lecture/écriture avec node:fs/promises |
| Base de données | requêtes SQL vers PostgreSQL |
| Timers | setTimeout, setInterval |
| Interface | réponses aux événements utilisateur |
Une conséquence contre-intuitive à accepter dès maintenant : dans une fonction asynchrone, le code après un await s'exécute plus tard — potentiellement bien après le reste du fichier. La prochaine leçon montre précisément pourquoi avec l'event loop.
Exercice
- Classez : calculer une somme, appeler une API, écrire un fichier, trier un tableau — bloquants ou non ?
- Pourquoi figer l'interface est-il particulièrement grave dans un navigateur ?
Résumé
- Attentes = danger ; JavaScript gère par non-blocage.
- Synchrone = séquentiel ; asynchrone = « rappelle-moi quand c'est prêt ».
- Callbacks → Promises → async/await : même mécanisme, lisibilité croissante.
Correction disponibleCherchez d’abord par vous-même.Voir la correction
Correction
Réponses détaillées
Question 1. Somme et tri : calcul pur CPU → synchrones (rapides). API, fichiers : attente externe → asynchrones.
Question 2. Le thread qui peint l'interface est le même que celui qui exécute votre JS. S'il bloque, aucun clic ni scroll n'est traité : la page semble « plantée ». D'où l'obligation de rendre asynchrone tout ce qui peut durer.