Installer Node.js sur Ubuntu - Le guide DevOps essentiel

Installer Node.js sur Ubuntu ne se résume pas à lancer une commande. Le vrai enjeu est de choisir une méthode cohérente avec votre contexte: poste de développement, serveur, CI ou environnement de préproduction. Dans un workflow DevOps, je regarde surtout la stabilité, la facilité de mise à jour et la capacité à figer une version sans surprises.

Choisir la bonne méthode selon votre usage

Je commence presque toujours par cette question, parce qu’elle change tout. Sur une machine de dev, je veux pouvoir basculer entre plusieurs versions sans toucher au système. Sur un serveur, je veux surtout une chaîne de mise à jour lisible, reproductible et facile à documenter.

Au moment actuel, la branche la plus raisonnable pour un serveur est Node.js 24 LTS. Les versions LTS sont celles que je retiens pour la production, car elles suivent un cycle de maintenance plus long, tandis que les branches Current avancent plus vite et bougent davantage.

Méthode	Avantage principal	Limite à connaître	Quand je la choisis
nvm	Plusieurs versions par utilisateur, bascule rapide	Pas pensé pour un service système partagé	Développement local, essais, multi-projets
apt via Ubuntu	Installation simple, intégrée au système	Version souvent plus prudente que l’amont	VM simple, serveur minimal, POC court
apt via NodeSource LTS	Bon compromis entre fraîcheur et gestion système	Dépôt externe à maintenir et documenter	Serveur de production ou de préproduction
Branche Current	Nouveautés plus tôt, utile pour valider la compatibilité	Évolution plus rapide, donc plus de vigilance	Tests, compatibilité, montée de version contrôlée
Tarball officiel	Version exacte, contrôle fin	Gestion manuelle du chemin et des mises à jour	Environnements verrouillés ou très spécifiques

Si vous hésitez encore, ma règle est simple: nvm pour la flexibilité, LTS pour l’exploitation. Une fois cette base posée, la commande d’installation devient presque secondaire, et c’est précisément ce qui évite les mauvais choix au moment où la charge arrive.

Installer avec nvm pour garder plusieurs versions

nvm est mon choix par défaut sur une machine de développement. Il est pensé pour un usage par utilisateur et par shell, ce qui est exactement ce que je veux quand plusieurs projets réclament des versions différentes de Node.js.

L’installation initiale de nvm passe par son installateur officiel, puis je charge le shell avant d’installer la version voulue. Une fois nvm en place, voici la séquence que j’utilise le plus souvent:

nvm install --lts
nvm use --lts
nvm alias default 'lts/*'
node -v
npm -v

Si vous voulez figer une version précise pour un projet, vous pouvez aussi installer une branche donnée plutôt qu’un alias dynamique. C’est utile quand un backend ou un outil interne a déjà été validé sur une ligne de version spécifique.

nvm install 24
nvm use 24
nvm alias default 24

Le point important, c’est que nvm vit dans votre environnement utilisateur. Sur un serveur géré par systemd ou dans un contexte où plusieurs comptes doivent exécuter le même binaire, ce modèle devient moins confortable. C’est là que l’installation système reprend l’avantage, et c’est la transition naturelle vers la voie apt.

Passer par apt quand vous voulez un socle système simple

Si je veux un environnement sobre, documenté et facile à administrer, je pars d’abord du dépôt Ubuntu. C’est la solution la plus directe pour un prototype, une VM éphémère ou un serveur qui ne doit pas jongler avec plusieurs versions. La contrepartie, c’est que la version disponible dépend de la distribution et de son cycle de stabilisation.

sudo apt update
sudo apt install -y nodejs npm
node -v
npm -v

Selon la version d’Ubuntu, npm peut être proposé séparément ou installé avec Node.js. Je ne pars jamais du principe que le packaging sera identique d’une version à l’autre: je teste toujours ce que la machine expose réellement après l’installation.

Si vous voulez rester dans le monde apt tout en visant une branche plus récente, je préfère le dépôt NodeSource. Je ne l’utilise pas pour “avoir la dernière version à tout prix”, mais pour garder une gestion système propre avec un Node.js plus proche de l’écosystème amont. Pour un serveur, je reste sur la branche LTS; pour des tests de compatibilité, je peux envisager Current.

sudo apt install -y nodejs

Cette dernière commande vient après l’ajout du dépôt correspondant via l’assistant officiel de NodeSource. L’idée n’est pas de multiplier les couches, mais de choisir une seule source de vérité pour la machine. Si vous mélangez plusieurs origines sans discipline, les conflits arrivent vite.

Vérifier que le shell pointe sur la bonne version

L’installation n’est pas terminée quand le paquet est posé. Le vrai contrôle, c’est de vérifier quel Node.js répond réellement dans votre shell. C’est un réflexe que je garde sur tous les environnements, parce qu’il détecte immédiatement les collisions entre une version système, une version nvm et parfois un ancien binaire resté dans le chemin.

which node
which npm
node -p "process.version"
node -p "process.execPath"

Ces commandes me disent trois choses utiles: la version active, le chemin du binaire et l’endroit exact d’où Node.js est lancé. Si vous utilisez nvm, vous devez voir un chemin qui pointe vers votre répertoire utilisateur. Si vous êtes sur une installation système, le chemin doit être cohérent avec /usr/bin ou avec le dépôt que vous avez choisi.

Je vérifie aussi npm -v et, quand le projet l’utilise, je regarde si Corepack est bien activable pour Yarn ou pnpm. Ce n’est pas obligatoire dans tous les cas, mais c’est souvent ce qui évite des écarts entre la machine locale et la CI.

Quand les versions ne correspondent pas à ce que vous attendiez, le problème vient presque toujours d’un mauvais mélange entre plusieurs installations, et non de Node.js lui-même.

Éviter les conflits de PATH, de sudo et de versions

Les erreurs les plus coûteuses sont rarement spectaculaires. Elles ressemblent plutôt à un node qui n’est pas celui que vous pensiez, à un sudo qui ne voit pas nvm, ou à un service système qui démarre avec une autre version que votre terminal. En DevOps, c’est ce type de détail qui fait perdre du temps au pire moment.

• Je garde une méthode principale par machine chaque fois que c’est possible.
• Je n’installe pas nvm et Node.js système sans raison claire sur le même serveur.
• Je me méfie de sudo node, parce que l’environnement ne sera pas le même que dans ma session utilisateur.
• Je pinne une version dans .nvmrc quand le projet dépend de nvm.
• Si le projet compile des modules natifs, j’ajoute les outils de build nécessaires avant de lancer l’installation des dépendances.

sudo apt install -y build-essential python3 make g++

Cette dernière commande ne sert pas à tous les projets, mais elle devient vite indispensable dès que des dépendances npm doivent compiler du code natif. Je préfère l’anticiper dans la documentation plutôt que découvrir l’erreur pendant un déploiement ou dans une pipeline.

La même logique s’applique aux environnements CI: plus la version de Node.js est explicite, moins vous avez de surprises entre les runs.

Le choix que je ferais pour un projet DevOps en 2026

Ma position est assez nette. Sur un poste de travail, j’utilise nvm avec une version LTS et un fichier .nvmrc par projet. Sur un serveur de production, je choisis une branche LTS installée via apt, idéalement avec un dépôt maintenu si la version du dépôt Ubuntu est trop en retrait pour mon besoin.

• Développement local : nvm, pour changer de version sans toucher au système.
• Serveur de production : LTS, pour garder une base stable et prévisible.
• Préproduction et tests de compatibilité : branche Current ou version précisément figée.
• Conteneurs : je pars souvent d’une image Node officielle plutôt que d’installer Node à la main sur une base Ubuntu générique.

Si je devais résumer la méthode la plus robuste, je dirais ceci: choisissez un seul chemin d’installation, vérifiez tout de suite le binaire actif, puis documentez la version dans le projet ou dans l’infrastructure. C’est cette discipline simple qui rend l’installation de Node.js sur Ubuntu vraiment exploitable dans un contexte DevOps.