Installer Node.js

Node.js est un runtime JavaScript côté serveur qui utilise le moteur V8 de Google Chrome. Cet article explique comment installer Node.js sur un serveur Linux, faire tourner une première application et gérer le tout comme un service système — pour les développeurs qui veulent faire tourner un backend ou une API en JavaScript.

Prérequis

• Un serveur Linux (Ubuntu 22.04 ou 24.04, Debian 12, ou une autre distribution avec systemd)
• Un accès au serveur via SSH avec un utilisateur disposant des droits `sudo`
• Aucune installation Node.js existante qui entre en conflit (vérifiez avec `node --version`)

Installer Node.js

La voie la plus rapide est le dépôt NodeSource. Il propose des versions plus récentes que les paquets standard de la distribution. Ubuntu 22.04 fournit par exemple Node.js 12 par défaut — qui est déjà en fin de vie depuis avril 2022. NodeSource vous donne Node.js 20 LTS ou 22 LTS, selon ce que vous choisissez.

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt-get install -y nodejs

Ceci ajoute le dépôt NodeSource à vos sources apt et installe à la fois `nodejs` et `npm`. Le drapeau `-E` avec sudo permet de conserver vos propres variables d'environnement, ce dont NodeSource a besoin pour sélectionner le bon dépôt.

Si vous choisissez Node.js 20 plutôt que 22, remplacez `setup_22.x` par `setup_20.x`. Node 20 est LTS jusqu'en avril 2026, Node 22 jusqu'en avril 2027. Pour un nouveau serveur, 22 est le choix le plus judicieux ; vous devrez migrer moins rapidement.

Faire tourner une première application

Créez un dossier de projet et un script HTTP minimal :

mkdir ~/node-app && cd ~/node-app
npm init -y

La commande `npm init -y` crée un fichier `package.json` avec des valeurs par défaut. Vous pourrez l'adapter plus tard ; pour l'instant, cela suffit pour pouvoir installer des dépendances.

Créez un fichier `server.js` :

const http = require('http');</p><p>const server = http.createServer((req, res) => {
  res.writeHead(200, { 'Content-Type': 'text/plain' });
  res.end('Node.js draait op Pixzo\n');
});</p><p>server.listen(3000, () => {
  console.log('Server luistert op poort 3000');
});

Ceci utilise volontairement le module `http` brut, pas Express. Pour un premier test, vous voulez voir que le runtime fonctionne, pas qu'un framework l'emballe proprement. Express viendra plus tard.

Démarrez le serveur :

node server.js

Ouvrez une deuxième session SSH et testez :

curl http://localhost:3000

Vous verrez la ligne de texte que le script renvoie. Le serveur tourne — mais seulement tant que votre session SSH est ouverte. Fermez le terminal et le serveur meurt. Pour un vrai déploiement, vous voulez un gestionnaire de processus ou un service systemd.

Faire tourner l'application comme service systemd

systemd est le système d'init standard sur pratiquement toutes les distributions Linux modernes. Il redémarre votre application en cas de crash, la démarre au démarrage du serveur et journalise proprement vers journald.

Créez un fichier de service :

sudo nano /etc/systemd/system/node-app.service

[Unit]
Description=Node.js applicatie
After=network.target</p><p>[Service]
ExecStart=/usr/bin/node /home/gebruikersnaam/node-app/server.js
Restart=always
RestartSec=10
Environment=NODE_ENV=production
User=gebruikersnaam</p><p>[Install]
WantedBy=multi-user.target

Remplacez `gebruikersnaam` par votre propre nom d'utilisateur. Le champ `User=` est important : ne faites pas tourner le service en tant que root. Si votre application Node.js est compromise, l'attaquant n'aura alors que les droits de cet utilisateur, pas ceux de tout le système.

sudo systemctl daemon-reload
sudo systemctl enable --now node-app

`enable` fait en sorte que le service soit démarré au démarrage, `--now` le démarre immédiatement. Vérifiez le statut :

sudo systemctl status node-app

Vous verrez `active (running)` et les dernières lignes de journal. Le serveur tourne maintenant indépendamment de votre session SSH.

Vérification

curl http://localhost:3000
node --version
npm --version

La première commande renvoie le texte de votre application. La deuxième et la troisième affichent respectivement les versions de Node.js et de npm. Node.js 22.x et npm 10.x sont les versions que vous devriez voir après une installation fraîche via NodeSource.

Problèmes fréquents

Le port 3000 est déjà occupé. Vous voyez un message d'erreur `EADDRINUSE`. Trouvez le processus qui occupe le port avec `sudo lsof -i :3000` et arrêtez-le, ou changez le port dans votre script vers par exemple 3001.

`node` n'est pas trouvé dans le service systemd. Le service utilise un chemin absolu vers le binaire. Vérifiez avec `which node` où se trouve votre installation Node.js et adaptez `ExecStart`. Avec une installation NodeSource, c'est généralement `/usr/bin/node`, mais si vous avez installé Node.js via nvm ou un autre gestionnaire de versions, il se trouve ailleurs et le chemin ne fonctionne pas.

Le service démarre mais ne cesse de redémarrer. Consultez les journaux avec `sudo journalctl -u node-app -n 50`. S'il y a une erreur dans votre JavaScript, vous la verrez ici. Le paramètre `Restart=always` fait en effet redémarrer le service en continu, même en cas d'erreur de syntaxe — les journaux vous disent ce qui ne va pas.

Wat dit u kost

Deze opzet is eenvoudig en robuust, maar niet volledig. Er staat geen reverse proxy voor, geen HTTPS, geen procesmanager met clustering. Voor een publieke server zet u er Nginx of Caddy voor, die de TLS-terminatie afhandelt en verkeer doorstuurt naar poort 3000. Voor een applicatie die meerdere CPU-kernen wil benutten, hebt u de cluster-module van Node.js of een procesmanager als PM2 nodig — systemd kan maar één proces per service draaien.

C'est le compromis : cet article vous donne un serveur Node.js opérationnel en dix minutes. Vous construirez ensuite une architecture évolutive, si la première version fait ses preuves. L'auto-hébergement semble magnifique, jusqu'à ce que quelque chose tombe en panne le dimanche soir à vingt-trois heures trente. Là, vous n'êtes pas un client qui attend le service d'assistance. Vous êtes le service d'assistance — et c'est alors bien pratique de savoir pourquoi le service est configuré comme il l'est.