0.1Qu'est-ce que Node.js ?
L'essentiel en 30 secondes
- Node.js = JavaScript hors du navigateur : le même langage qu'au front, via le moteur V8, pour serveurs, API et outils.
- Modèle asynchrone non-bloquant : une opération lente n'arrête pas le programme — Node enregistre un rappel et continue.
- Mono-thread mais des milliers de connexions : la boucle d'événements rappelle chaque fonction quand son résultat arrive.
Mini-cas filé — Salim situe son premier outil serveur
Salim, développeur junior à Alger, ne connaît que le JavaScript du navigateur. Son responsable lui demande un petit serveur qui répond aux requêtes d'une page. Salim découvre que Node.js exécute son JavaScript côté serveur grâce au moteur V8, qu'une lecture de fichier n'y bloque pas le programme, et que la boucle d'événements orchestre les rappels. Il note sur une fiche « JS partout, non-bloquant, boucle d'événements » et choisit son premier test : afficher un message puis simuler une opération lente sans bloquer.
Cas autonome de cette section : il revient dans le cours, le schéma, le script et le défi 48h de la section 0.1.
1. JavaScript hors du navigateur
Node.js est un environnement d'exécution qui fait tourner du JavaScript en dehors du navigateur, notamment côté serveur. Il associe le moteur V8 (le moteur JavaScript rapide de Chrome) à une bibliothèque d'accès au système (fichiers, réseau). Salim comprend l'idée : il garde son langage du front et l'utilise pour écrire un serveur, une API ou un outil en ligne de commande. C'est le « JavaScript full-stack » : un seul langage pour tout le web.
2. Asynchrone non-bloquant et boucle d'événements
La caractéristique qui définit Node est son modèle asynchrone non-bloquant à boucle d'événements (event loop). Beaucoup de tâches d'un serveur consistent à attendre : base de données, fichier, réseau. Au lieu d'attendre passivement, Node enregistre une fonction à rappeler (un callback) quand ce sera prêt et passe aussitôt à autre chose. La boucle d'événements tourne en permanence : elle exécute le code disponible et déclenche chaque rappel dès que son opération se termine. Salim retient l'image : prendre la commande suivante au lieu de poireauter en cuisine.
3. Mono-thread, fort en I/O, faible en calcul lourd
Conséquence : Node est mono-thread pour votre code mais gère des milliers de connexions simultanées, car il ne reste jamais bloqué à attendre. Il excelle pour l'I/O-intensif (serveurs web, API, temps réel) et est moins adapté au CPU-intensif (longs calculs qui monopoliseraient l'unique thread). Tout le reste — callbacks, Promises, async/await — découle de ce modèle. Salim l'a noté en bas de sa fiche à Alger : comprendre la boucle d'événements avant tout le reste.
Le saviez-vous ? Le serveur qui ne poireaute jamais
Ne jamais attendre : enregistrer un rappel et continuer.
🔎 Exemple concret — 🔎 Exemple concret — Bloquant vs non-bloquant
console.log("Début");
setTimeout(() => {
console.log("Réponse de l'opération lente");
}, 100);
console.log("Fin (affichée avant la réponse)");Lecture : Salim lance ce script avec Node : « Fin » s'affiche avant « Réponse », preuve que le programme n'a pas attendu.
Leçon : le résultat arrive plus tard via le rappel ; le thread reste libre entre-temps.
Vocabulaire de la section
- Node.js
- Environnement d'exécution qui fait tourner du JavaScript hors du navigateur (côté serveur), basé sur le moteur V8 plus une bibliothèque d'accès au système.
Exemple simple : Salim lance son premier serveur écrit en JavaScript avec Node à Alger.
Ce que ce n'est pas : un langage différent du JavaScript du navigateur.
Réflexe : devant un besoin serveur ou outil, demander « puis-je le faire en JS avec Node ? ».
- Moteur V8
- Moteur JavaScript rapide du navigateur Chrome, qui compile et exécute le JS ; le cœur de Node.js.
Exemple simple : Salim sait que son JS serveur tourne sur le même moteur que son JS front.
Ce que ce n'est pas : une bibliothèque réseau ou un gestionnaire de paquets.
Réflexe : retenir V8 = rapidité d'exécution, Node = V8 + accès système.
- Asynchrone non-bloquant
- Modèle où une opération lente ne bloque pas le programme : Node enregistre un rappel et continue aussitôt.
Exemple simple : Salim lance une lecture de fichier et affiche la suite sans attendre la fin.
Ce que ce n'est pas : attendre passivement la fin d'une opération avant de continuer.
Réflexe : toujours prévoir « quoi faire quand ce sera prêt » (le rappel).
- Boucle d'événements (event loop)
- Mécanisme central qui orchestre l'exécution : il lance les opérations lentes et rappelle les fonctions quand les résultats arrivent.
Exemple simple : Salim visualise la boucle qui sert chaque réponse dès que le fichier ou la base répond.
Ce que ce n'est pas : un thread supplémentaire par utilisateur.
Réflexe : penser « la boucle rappelle », pas « le programme attend ».
- I/O-intensif vs CPU-intensif
- I/O-intensif : beaucoup d'attentes (serveurs, API) où Node excelle ; CPU-intensif : calculs lourds qui bloqueraient l'unique thread.
Exemple simple : Salim réserve Node à une API qui lit une base, et écarte un encodage vidéo massif.
Ce que ce n'est pas : deux noms pour la même chose.
Réflexe : classer chaque besoin en I/O ou CPU avant de choisir Node.
En pratique — En pratique — Situer Node.js et son modèle
- Retenez la nature de Node : un environnement pour exécuter du JavaScript HORS du navigateur (serveurs, API, outils), grâce au moteur V8.
- Identifiez l'atout « un seul langage » : JavaScript côté front ET back (full-stack JS), comme Salim à Alger.
- Comprenez le modèle non-bloquant : lancez le script d'exemple et constatez que « Fin » arrive avant la réponse.
- Situez les bons usages : Node brille pour l'I/O (serveurs web, API, temps réel), moins pour les calculs CPU lourds.
Script prêt à dire — expliquer Node à un collègue (30 s)
« Node, c'est notre JavaScript qui tourne côté serveur grâce au moteur V8. Quand il lit un fichier ou interroge une base, il n'attend pas : il enregistre un rappel et traite la suite, et la boucle d'événements rappelle quand c'est prêt. Un seul thread gère plein de requêtes, parfait pour nos API. »
À dire avec le script d'exemple sous les yeux ; montrer l'ordre d'affichage Début, Fin, Réponse.
Modèle copier-coller — observer le non-bloquant
console.log("Salim lance la lecture");
setTimeout(() => {
console.log("Lecture terminée : Salim reprend ici");
}, 50);
console.log("Salim continue sans attendre");Venant du front
Vous connaissez déjà le JS navigateur : concentrez-vous sur ce qui change (pas de DOM, boucle d'événements, I/O) et lancez le script d'exemple pour voir l'ordre réel.
Débutant total
Sans base JS : relancez le script trois fois en changeant le délai (50, 200, 0) et notez l'ordre constant Début, suite, réponse — l'intuition du non-bloquant.
Binôme à Alger
Salim fait deviner l'ordre d'affichage à son collègue avant d'exécuter : celui qui se trompe explique la boucle d'événements au tableau.
Choix d'architecture
Avant un projet : classez le besoin en I/O (API, serveur, temps réel → Node adapté) ou CPU lourd (calcul massif → à déporter ailleurs).
✓ Bonnes pratiques
- Pensez « un seul langage » pour le front et le back (full-stack JS).
- Réservez Node aux tâches I/O (serveurs, API, temps réel).
- Comprenez la boucle d'événements avant tout le reste.
✗ Pièges fréquents
- Croire que mono-thread = un seul utilisateur à la fois.
- Lancer un gros calcul CPU qui bloque la boucle d'événements.
- Oublier que l'asynchrone (callbacks, Promises) découle de ce modèle.
Points clés à retenir
- Node.js exécute du JavaScript HORS du navigateur (serveurs, API, outils CLI) via le moteur V8 — un SEUL langage pour le front ET le back.
- Modèle ASYNCHRONE NON-BLOQUANT : les opérations lentes ne bloquent pas — Node enregistre un rappel et continue.
- La BOUCLE D'ÉVÉNEMENTS orchestre tout ; Node est MONO-THREAD mais gère des milliers de connexions simultanées.
- Excellent pour l'I/O (serveurs web, API, temps réel) ; moins adapté aux tâches CPU-intensives.
Défi 48h — appliquez demain
Exécutez le script non-bloquant de Salim, changez le délai deux fois, et expliquez à voix haute pourquoi « Fin » arrive avant la réponse.
- Je peux expliquer Node.js (JS serveur via V8) avec un exemple.
- J'ai exécuté le script et constaté l'ordre non-bloquant.
- Je sais dire quand Node est adapté (I/O) et quand il ne l'est pas (CPU lourd).
Questions fréquentes
Node.js est mono-thread : comment peut-il gérer des milliers d'utilisateurs à la fois ?
Il faut distinguer « exécuter du code » et « attendre une opération lente ». Un serveur passe l'essentiel de son temps à attendre (base, fichier, réseau). Un serveur bloquant y consacrerait son thread passivement. Node, non-bloquant, délègue l'opération au système, enregistre un callback et rend aussitôt la main : le thread traite la requête suivante. La boucle d'événements exécute chaque rappel dès que son opération se termine. Comme dans un restaurant où un bon serveur prend les commandes à la chaîne et sert chaque plat quand la cuisine le signale prêt. Limite : un gros calcul CPU monopolise le thread et bloque tout.
Quand choisir Node.js, et quand préférer une autre technologie ?
Node brille pour : les applications I/O-intensives (API REST, back-ends qui lisent en base), le temps réel (chat, notifications), les équipes full-stack JS (un seul langage), les microservices et l'outillage. Il est moins adapté aux tâches CPU-intensives (calcul scientifique, traitement massif d'images, apprentissage automatique) qui monopoliseraient l'unique thread — on préfère alors d'autres plateformes ou on déporte ces calculs vers des services spécialisés. Le bon choix dépend du problème (I/O vs CPU), de l'équipe et de l'écosystème.
Qu'est-ce qui définit le modèle de Node.js ?