NVM for Windows, gérer Node. js sans casser vos projets

NVM for Windows est un gestionnaire de versions de Node.js pour Windows. Il permet d’installer plusieurs versions de Node sur le même poste, puis de basculer de l’une à l’autre selon le projet. C’est utile quand un ancien projet demande Node 16, qu’un outil récent exige Node 22, ou qu’une équipe veut tester une montée de version sans casser tout l’environnement local.

Il faut cependant lever une confusion fréquente : nvm-windows n’est pas le même projet que nvm pour Unix/macOS. L’idée est proche, mais l’implémentation, les commandes et certaines limites diffèrent. Sur Windows, le bon réflexe consiste donc à lire la documentation du projet nvm-windows, pas à copier aveuglément un tutoriel Linux.

À quoi sert vraiment NVM for Windows ?

Node.js évolue vite. Les projets, eux, ne migrent pas tous au même rythme. Un site ancien peut dépendre d’une version LTS déjà dépassée, pendant qu’un framework récent réclame une version plus moderne. Installer et désinstaller Node manuellement devient vite pénible, surtout si les outils globaux et les chemins Windows se mélangent.

NVM for Windows répond à ce problème en ajoutant une couche de sélection. Vous installez plusieurs versions de Node, puis vous choisissez celle qui doit être active dans le terminal. Le gain est concret : moins de bricolage, moins de conflits, et une meilleure séparation entre projets.

Ce n’est pas un outil magique. Il ne corrige pas les dépendances cassées, ne remplace pas un fichier de verrouillage propre et ne dispense pas de lire les prérequis du projet. Il aide surtout à stabiliser l’environnement local.

Quand l’utiliser, et quand s’en passer

Utilisez NVM for Windows si vous travaillez sur plusieurs projets Node, si vous contribuez à des dépôts anciens, si vous testez une migration, ou si vous devez reproduire l’environnement d’une équipe. C’est aussi pratique en formation, quand chaque exercice ou template impose une version précise.

En revanche, si vous utilisez Node pour un seul outil, un seul projet ou quelques scripts personnels, l’installateur officiel Node.js peut suffire. Ajouter un gestionnaire de versions crée une petite complexité : chemins, droits, commandes, dossiers d’installation. Cette complexité est rentable seulement si vous avez un vrai besoin de bascule.

La bonne question n’est donc pas “est-ce plus moderne ?”. Elle est plus simple : avez-vous régulièrement besoin de changer de version Node sans casser vos autres projets ?

Préparer Windows avant l’installation

Le point sensible est souvent l’existant. Si Node.js est déjà installé via l’installateur officiel, via un outil tiers ou via un ancien nvm, il faut comprendre ce qui est présent avant d’ajouter nvm-windows. Deux installations concurrentes peuvent laisser des exécutables dans le PATH et provoquer des résultats incohérents.

Avant de commencer, ouvrez un terminal et vérifiez les versions visibles avec les commandes habituelles. Contrôlez aussi l’emplacement de l’exécutable Node si nécessaire. L’objectif est de savoir si Windows pointe déjà vers un ancien chemin Node, un dossier système, un dossier utilisateur ou un lien géré par nvm-windows.

Sur un poste professionnel, vérifiez aussi les droits administrateur et la politique de sécurité. Certains environnements verrouillent les installations, les liens symboliques, les scripts ou les dossiers système. Dans ce cas, l’installation doit être validée avec l’équipe IT.

Installer sans polluer le PATH

La documentation du projet nvm-windows insiste sur un point pratique : l’installation doit être propre. Le gestionnaire crée son propre emplacement et pilote la version active. Si un ancien Node reste prioritaire dans le PATH, vous risquez de croire que la bascule fonctionne alors que le terminal appelle toujours l’ancienne version.

Après installation, ouvrez un nouveau terminal. Installez une version de Node, activez-la, puis vérifiez Node et npm. Ce test doit être fait dans un terminal neuf, car un terminal déjà ouvert peut conserver un ancien environnement. C’est un détail banal, mais il explique beaucoup de faux diagnostics.

Gardez aussi une règle simple : évitez d’installer Node avec plusieurs méthodes sur le même poste. L’installateur officiel, nvm-windows, un gestionnaire de paquets et une installation manuelle peuvent cohabiter par accident, mais ce n’est pas un environnement fiable.

Diagnostiquer un conflit de version

Le symptôme le plus courant est une version qui ne correspond pas à celle que vous venez d’activer. Dans ce cas, ne réinstallez pas tout immédiatement. Vérifiez d’abord le terminal utilisé, le chemin réellement appelé et l’ordre des entrées dans le PATH. Sur Windows, l’ordre du PATH décide souvent quel exécutable répond en premier.

Un autre symptôme fréquent apparaît avec npm. Vous activez une version de Node, mais un outil global installé auparavant continue de se comporter bizarrement. C’est normal si cet outil dépendait d’une autre version ou si son installation globale n’est plus alignée. La correction passe souvent par une réinstallation propre des outils globaux nécessaires, pas par une accumulation de commandes au hasard.

Pour éviter de perdre du temps, notez trois informations dans chaque diagnostic : la version Node affichée, la version npm affichée et le dossier d’où vient l’exécutable. Ce trio suffit souvent à comprendre si le problème vient de nvm-windows, d’un ancien Node, d’un terminal non rouvert ou d’un projet mal documenté.

Utiliser une version par projet

Le vrai bénéfice apparaît quand chaque projet documente sa version Node. Cette information peut être indiquée dans un README, un fichier de configuration, un fichier .nvmrc selon les habitudes d’équipe, ou dans la documentation interne. Sur Windows, l’important est que la version attendue soit explicite.

Quand vous ouvrez un projet, vérifiez la version demandée, activez-la avec nvm-windows, puis installez les dépendances. Ne mélangez pas les installations créées sous plusieurs versions sans nettoyer si le projet se comporte bizarrement. Certains modules natifs, caches ou outils globaux gardent des traces.

Pour approfondir ce point, consultez consent mode v2, qui traite plus précisément de consent mode v2 : déployer proprement sans casser vos données marketing.

Pour une équipe, la règle doit être écrite. Sinon, chacun installe la version qui fonctionne chez lui, et les bugs d’environnement reviennent à chaque onboarding.

Organiser un workflow propre en équipe

Dans une équipe, le sujet dépasse le poste individuel. Si trois développeurs utilisent trois versions différentes de Node, les erreurs deviennent difficiles à reproduire. Le dépôt doit donc indiquer la version attendue, la commande d’installation et les prérequis. Cette information doit être visible au même endroit que les autres étapes de lancement du projet.

Le plus simple est de garder une procédure courte : installer nvm-windows, activer la version documentée, installer les dépendances, lancer les tests ou le serveur local. Si une version change, la modification doit être notée dans le changelog technique ou dans la documentation interne. Ce n’est pas administratif : c’est une assurance onboarding.

Pour les projets critiques, gardez aussi une version de référence dans l’intégration continue ou dans l’image de développement. Le poste Windows reste alors aligné avec le reste de la chaîne. NVM for Windows facilite le quotidien local, mais il ne doit pas devenir la seule source de vérité.

Les erreurs les plus fréquentes

La première erreur consiste à installer nvm-windows sans retirer ou comprendre une ancienne installation Node. Le résultat est classique : la commande de version affiche autre chose que prévu, npm semble incohérent, ou un projet fonctionne dans un terminal mais pas dans un autre.

La deuxième erreur est de confondre les tutoriels. Une commande valable pour nvm Unix/macOS n’est pas toujours valable sur Windows. Il faut lire la documentation nvm-windows, surtout pour l’installation, la désinstallation, les chemins et les commandes disponibles.

La troisième erreur est d’utiliser la toute dernière version de Node parce qu’elle est disponible. Un projet doit être testé avec la version qu’il supporte réellement. Une version trop récente peut casser un outil de build, un module natif, un framework ou une dépendance abandonnée.

Le cas classique arrive pendant une migration : l’équipe active une version récente, l’installation semble passer, puis un script échoue uniquement sur certaines machines. Avant de modifier le code, comparez la version Node, la version npm, le lockfile, les modules natifs et le terminal utilisé. Cette vérification paraît longue, mais elle évite de confondre un problème d’environnement avec un vrai bug applicatif, surtout sur des projets qui ont plusieurs années d’historique.

Ce qu’il faut retenir

NVM for Windows est un bon outil pour les développeurs qui jonglent entre plusieurs versions de Node.js sur Windows. Il apporte de la souplesse, mais seulement si l’installation est propre et si chaque projet indique clairement la version attendue.

Pour un usage simple, l’installateur officiel Node.js peut suffire. Pour un poste de développement plus actif, nvm-windows devient intéressant dès que la gestion des versions évite des conflits, des réinstallations ou des surprises entre projets.

Pour approfondir ce point, consultez Vider le cache DNS Windows avec ipconfig, qui traite plus précisément de vider le cache dns windows avec ipconfig /flushdns.