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
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.
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 patient pas : elle tourne pendant que le fichier se lit. Le résultat arrive plus tard, via la fonction fournie.
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.