Node.js : comprendre le runtime JavaScript côté serveur

C'est quoi Node.js, concrètement

Node.js, c'est un programme que tu installes sur ta machine et qui sert à exécuter des fichiers JavaScript. Voilà, c'est la description la plus simple, et elle est juste. Quand tu tapes node script.js, Node lit le fichier, le transmet au moteur V8 de Google (le même moteur JavaScript que celui de Chrome), puis l'exécute — avec en plus une grosse bibliothèque d'API pour gérer tout ce que V8 ne sait pas faire tout seul.

V8 sait exécuter du JavaScript. En revanche, il ne sait pas ouvrir un fichier, écouter sur un socket TCP, lancer un processus ou lire une variable d'environnement. C'est Node qui se charge de tout ça, en C++, et qui expose ces fonctionnalités à ton code JavaScript sous forme de modules natifs.

node --version
node script.js

Node, ce n'est pas un langage. Ce n'est pas non plus un framework. C'est un runtime : V8, plus une bibliothèque standard, plus un système de modules, plus une boucle d'événements. Voilà, c'est tout.

Un premier script

N'importe quel fichier .js est un programme Node valide. Pas de code standard à recopier, pas de fonction main :

console.log fonctionne exactement comme dans le navigateur. Les template literals, Date, les tableaux, les promesses — toutes les fonctionnalités du langage que vous connaissez déjà viennent de V8 et se comportent à l'identique. Ce qui change avec Node, c'est ce qui est disponible autour du langage.

Les globales propres à Node.js

Le navigateur dispose de window, document, localStorage, fetch. Node, lui, expose un autre jeu de globales, pensé pour un runtime côté serveur :

• process représente le processus Node en cours d'exécution. Il expose les variables d'environnement (process.env), les arguments de la ligne de commande (process.argv), et des méthodes pour quitter le programme (process.exit(1)).
• __filename et __dirname te donnent le chemin absolu du fichier courant et de son dossier. (En modules ES, ils n'existent pas — il faut passer par import.meta.url à la place.)
• global est l'objet de plus haut niveau, l'équivalent Node de window.

Pas de document, pas de window. Si tu essaies de les utiliser, tu récoltes une ReferenceError. C'est d'ailleurs souvent le premier indice qu'une bibliothèque a été écrite pour le navigateur et ne tournera pas telle quelle dans Node.

Arguments de la ligne de commande et variables d'environnement

Une bonne partie de ce à quoi sert Node — outils en ligne de commande, scripts de build, serveurs — consiste à lire des arguments et des variables d'environnement. Les deux sont accessibles via process :

process.argv est un tableau : les deux premières entrées correspondent au chemin du binaire Node et au chemin du script, donc les vrais arguments commencent à l'index 2. Quant à process.env, c'est un simple objet qui contient les variables d'environnement — y lire NODE_ENV, PORT ou des clés d'API est une pratique courante.

Les modules natifs de Node.js

Node embarque une bibliothèque standard accessible via require (CommonJS) ou import (ESM). Les noms de modules sont préfixés par node: pour bien signaler qu'il s'agit de modules natifs :

Ceux dont tu te serviras le plus souvent :

• node:fs — lire et écrire des fichiers. Passe par node:fs/promises pour la version async/await.
• node:path — assembler, résoudre et analyser des chemins de fichiers de façon multiplateforme.
• node:http / node:https — monter des serveurs HTTP et envoyer des requêtes.
• node:url — analyser et construire des URL.
• node:os — récupérer des infos sur la machine hôte.
• node:crypto — hachage, octets aléatoires, chiffrement.

Pas besoin de les installer : ils sont livrés avec Node. Tout le reste arrive via npm.

L'event loop de Node.js, en bref

Node exécute ton JavaScript sur un seul thread, et pourtant il arrive à gérer plein de choses en parallèle. Le secret, c'est l'event loop. Quand tu lances une opération asynchrone — une lecture de fichier, une requête HTTP, un timer — Node délègue le vrai travail à l'OS (ou à son pool de threads) et continue d'exécuter la suite. Une fois l'opération terminée, un callback est mis en file d'attente, et la boucle le récupère dès que le code en cours a fini de tourner.

L'ordre affiché est 1, 4, 2, 3. Le code synchrone s'exécute en premier. Ensuite viennent les microtâches (les promesses résolues). Et enfin les timers. C'est précisément pour ça qu'une boucle gourmande en CPU bloque tout votre serveur : il n'y a qu'un seul thread pour votre code. La concurrence dans Node concerne les I/O, pas le calcul.

Un petit serveur HTTP

Le vrai bénéfice de tout ça, c'est qu'un serveur web fonctionnel tient en quelques lignes :

Pas de framework, pas de dépendances. createServer reçoit une fonction exécutée à chaque requête, et listen démarre l'event loop qui traite les connexions entrantes. Les vraies applis s'appuient sur Express ou Fastify, mais en dessous c'est le même module natif http.

Node vs le navigateur

Autant être clair sur ce qui fonctionne des deux côtés et ce qui ne passe pas :

Des deux côtés	Node uniquement	Navigateur uniquement
Fonctionnalités du langage (classes, promesses, async/await)	fs, http, process, __dirname	window, document, DOM
console.log	CommonJS require / particularités d'ESM côté Node	localStorage, sessionStorage
fetch (Node 18+)	Accès au système de fichiers et aux sockets réseau	Événements utilisateur, rendu
setTimeout, setInterval	Processus enfants, streams	History API, navigator

Node récent a récupéré plusieurs APIs du navigateur — fetch, URL, AbortController, structuredClone — du coup l'écart s'est bien réduit. Mais le DOM n'arrivera jamais dans Node, et le système de fichiers ne débarquera jamais dans le navigateur.

Node vs Deno vs Bun

Node reste la valeur par défaut, mais ce n'est plus le seul runtime JavaScript. Deno et Bun sont des alternatives — Deno vient du créateur original de Node, Bun d'une équipe plus récente obsédée par la performance. Les deux exécutent du JavaScript (et du TypeScript, nativement), embarquent leur propre outillage (test runner, bundler...) et se démarquent de Node sur la gestion des modules, les permissions et l'installation des paquets.

Pour apprendre JavaScript, c'est toujours autour de Node que se concentrent la documentation, les tutos et les offres d'emploi. Les concepts — event loop, modules, APIs natives — se transposent quasiment tels quels sur les autres runtimes. Commence par Node ; tu piocheras dans les autres quand un projet le justifiera.

Exécuter des scripts, vite fait

Quelques façons concrètes de lancer du code pendant que tu bosses :

# Exécuter un fichier
node script.js

# Exécuter une ligne unique
node -e "console.log(2 ** 10)"

# Ouvrir le REPL (invite interactive)
node

# Surveiller un fichier et ré-exécuter à la sauvegarde (Node 18.11+)
node --watch script.js

Le REPL est un petit bac à sable bien pratique quand tu veux juste voir ce que renvoie une méthode sans créer de fichier. Quant à --watch, c'est un vrai confort en développement : tu sauvegardes, et Node relance ton script tout seul.

La suite : gérer les erreurs

Exécuter du code, c'est une chose. Encaisser les pépins, c'en est une autre. Une lecture de fichier qui échoue, une requête HTTP qui part en timeout, un JSON mal formé qui explose au parsing... Le prochain chapitre s'attaque à try/catch, aux types d'erreurs et aux schémas classiques pour gérer ce qui casse — parce que dans un programme Node, à un moment ou à un autre, tout finit par casser.