C'est le paradoxe le plus déroutant — et le plus génial — de Node, et le comprendre éclaire tout son fonctionnement. Oui, votre code JavaScript s'exécute sur un seul thread (un seul fil d'exécution). Intuitivement, on imagine qu'un seul thread ne peut traiter qu'une chose à la fois, donc un seul utilisateur à la fois — ce qui serait catastrophique pour un serveur. La clé est de distinguer « exécuter du code » et « attendre une opération lente ». Dans un serveur typique, l'essentiel du temps n'est PAS passé à calculer, mais à attendre : attendre la réponse d'une base de données, la lecture d'un fichier disque, une requête vers une autre API, l'arrivée de données réseau. Ces attentes durent des millisecondes, une éternité à l'échelle du processeur. Un serveur « bloquant » classique consacrerait son thread à attendre passivement — pendant ce temps, il ne peut rien faire d'autre (d'où le besoin de multiplier les threads pour servir plusieurs clients, chaque thread coûtant de la mémoire). Node fait radicalement différent grâce au non-bloquant : quand votre code lance une opération lente (par exemple « lis ce fichier »), Node ne bloque PAS le thread à attendre. Il délègue l'opération au système (qui la réalise en arrière-plan, via des threads systèmes gérés par la bibliothèque libuv, hors de votre code), enregistre une fonction de rappel (callback) à exécuter quand ce sera prêt, et rend immédiatement la main — le thread est libre de traiter la requête suivante. La boucle d'événements tourne en permanence : elle exécute le code disponible, et dès qu'une opération lente se termine (le fichier est lu, la base a répondu), elle exécute le callback correspondant. Ainsi, pendant que la requête de l'utilisateur A attend sa base de données, le thread traite la requête de l'utilisateur B, puis C, etc. — et quand la base de A répond, Node reprend le traitement de A. Le thread n'est JAMAIS oisif à attendre : il jongle en continu entre des milliers de requêtes qui sont, la plupart du temps, en train d'attendre des I/O. Une analogie : un serveur bloquant est comme un serveur de restaurant qui prend une commande, va en cuisine, ATTEND que le plat soit prêt, le sert, puis seulement passe à la table suivante — désastreux. Node est comme un bon serveur qui prend la commande de la table A, la transmet en cuisine, va aussitôt prendre la commande de la table B, puis C, et sert chaque plat quand la cuisine le signale prêt — un seul serveur gère toute la salle efficacement, parce qu'il ne reste jamais planté à attendre la cuisine. La limite de ce modèle : si UNE tâche monopolise le thread en calculant longtemps (un gros calcul CPU, une boucle interminable), elle BLOQUE la boucle d'événements — le « serveur » reste coincé en cuisine et ne peut plus servir personne. C'est pourquoi Node excelle pour l'I/O (beaucoup d'attente, peu de calcul) mais souffre sur les tâches CPU-intensives (que l'on traite alors autrement — clustering, worker threads, section 5-2). Retenez : mono-thread + non-bloquant + boucle d'événements = un seul thread qui gère des milliers de connexions en ne perdant jamais de temps à attendre. C'est l'essence de Node, et la raison de son efficacité pour les serveurs web.

Choisir Node.js (ou non) est une décision d'architecture, et la réponse honnête dépend du type d'application, de l'équipe et du contexte — voici une grille de décision. Node BRILLE quand : (1) Application I/O-intensive : serveurs web, API REST, back-ends qui passent leur temps à lire/écrire en base, appeler d'autres services, servir des requêtes — c'est le terrain de prédilection de Node (son modèle non-bloquant y est optimal). (2) Temps réel : chat, notifications live, jeux multijoueurs, tableaux de bord en direct — Node et les WebSockets (section 4-3) gèrent excellemment des milliers de connexions persistantes. (3) Équipe JavaScript / full-stack JS : si votre équipe maîtrise déjà JavaScript (pour le front), utiliser Node pour le back permet UN SEUL langage, un partage de code et de compétences, une productivité accrue. C'est un argument majeur des stacks modernes (MERN, etc.). (4) Microservices et API : Node est léger, rapide à démarrer, idéal pour de petits services. (5) Outils en ligne de commande et scripts : Node est très utilisé pour l'outillage (build, automatisation) de l'écosystème JS. (6) Prototypage rapide : l'écosystème npm (des centaines de milliers de paquets) permet d'assembler vite une application. Node est MOINS adapté quand : (1) Application CPU-intensive : calculs scientifiques lourds, traitement d'images/vidéos massif, machine learning, cryptographie intensive — ces tâches monopoliseraient l'unique thread et bloqueraient tout. On préférera des langages/plateformes conçus pour le calcul parallèle (ou on délègue ces calculs à des services spécialisés). (2) Besoin de calcul parallèle intensif : là où le multi-threading natif est central, d'autres langages (Go, Rust, Java, C++) sont plus naturels. (3) Systèmes exigeant une sûreté de type forte ou des performances extrêmes : selon le contexte, des langages typés/compilés (Rust, Go, C++) peuvent être préférables — même si TypeScript sur Node (section 5-1) répond en partie au besoin de typage. Comparaisons courantes : (1) Node vs Python (Django/Flask/FastAPI) : Python excelle en data science, ML, scripts ; Node en temps réel et full-stack JS. Les deux sont excellents pour les API web ; le choix se fait souvent sur l'équipe et l'écosystème. (2) Node vs Go : Go offre un vrai parallélisme et d'excellentes performances pour les services très sollicités et CPU ; Node offre l'écosystème JS et le full-stack. (3) Node vs Java/.NET : ces plateformes matures conviennent aux grosses applications d'entreprise ; Node est plus léger et rapide à démarrer. Un principe important : il n'y a pas de « meilleur » langage dans l'absolu — le bon choix dépend du PROBLÈME (I/O vs CPU, temps réel, échelle), de l'ÉQUIPE (compétences existantes), de l'ÉCOSYSTÈME (bibliothèques disponibles) et du CONTEXTE (existant, contraintes). Node est un excellent choix par défaut pour le web moderne (API, temps réel, full-stack JS), très largement adopté (de nombreuses grandes entreprises l'utilisent en production) ; mais il n'est pas universel. Apprendre Node vous donne une compétence très demandée ET transférable (les concepts d'asynchrone, d'API, de déploiement se retrouvent ailleurs). Et rassurez-vous : maîtriser Node ne vous « enferme » pas — au contraire, les concepts que vous apprendrez (asynchrone, HTTP, API REST, bases de données, déploiement) sont universels et vous serviront quel que soit le langage que vous utiliserez ensuite. Commencez par comprendre pour quoi Node est fait (l'I/O et le web), et vous saurez naturellement quand il convient.