node n’est pas reconnu en tant que commande interne, que faire ?

Sur Windows, rien n’est plus frustrant que de lancer un projet JavaScript tout neuf, taper node dans l’invité de commande ou le terminal… et voir s’afficher « node n’est pas reconnu en tant que commande interne ou externe ». Au moment où cette erreur surgit, tout semble bloqué : impossible de lancer un serveur, d’installer un package ou de tester une API. Pourtant, il s’agit presque toujours d’un problème de configuration, pas d’un bug insoluble. Une fois compris le rôle des variables d’environnement et du path système, la résolution du problème devient logique, étape par étape.

Dans un atelier en entreprise, cette erreur a mis en pause tout un groupe pendant une demi-heure. L’orateur avançait, certains suivaient, d’autres étaient bloqués sur cette fameuse « commande non reconnue ». En expliquant calmement comment vérifier l’installation node, ajuster le chemin dans Windows et tester l’exécutable, chacun a pu repartir avec un environnement de développement fiable. C’est exactement l’objectif ici : donner des repères clairs et concrets pour que cette erreur node ne devienne plus jamais un frein à vos projets, que vous soyez développeur débutant ou marketeur qui teste un outil en ligne de commande.

Comprendre le message « node n’est pas reconnu » et ses causes réelles

Lorsque Windows affiche « node n’est pas reconnu en tant que commande interne ou externe », il indique simplement qu’il ne sait pas où se trouve l’exécutable node.exe. Autrement dit, la commande fonctionne potentiellement très bien, mais le système n’a pas le chemin permettant de la localiser. Cette situation touche aussi bien node.js que npm, npx ou d’autres outils comme ts-node.

Dans la plupart des cas, l’erreur vient de l’un de ces facteurs : l’application n’est pas installée, l’installation a été incomplète, ou le chemin d’accès à node n’a pas été ajouté correctement aux variables d’environnement. En effet, le path système est la liste de dossiers où Windows cherche les exécutables quand vous tapez une commande simple comme « node » sans préciser de chemin complet.

Pour clarifier, on peut considérer que chaque fois que vous lancez une commande dans l’invité de commande, Windows parcourt cette liste de dossiers, dans l’ordre, jusqu’à trouver un fichier portant le nom indiqué. S’il ne le trouve pas, le message « commande non reconnue » apparaît, même si le programme existe ailleurs sur le disque.

Plusieurs scénarios typiques déclenchent ce message d’erreur node :

• Installation absente ou corrompue : Node.js n’a jamais été installé ou l’installation a échoué sans message clair.
• Chemin non ajouté au PATH : node est bien là, mais son dossier n’apparaît pas dans les variables d’environnement.
• Conflit avec d’autres logiciels : un outil précédemment installé a modifié le path système et fait disparaître la référence à node.
• Terminal mal relancé : l’invité de commande ou l’éditeur (VS Code, par exemple) n’a pas été redémarré après installation.

Un exemple parlant : une agence digitale installe Node.js sur plusieurs postes pour automatiser son pipeline de build front. Sur certains ordinateurs, les développeurs peuvent lancer « node -v » directement. Sur d’autres, le message « commande non reconnue » apparaît. Après vérification, seuls les postes configurés avec un PATH correct vers « C:Program Filesnodejs » fonctionnent. Une différence minime à l’écran, mais décisive pour leur productivité au quotidien.

Pour poser les bases, voici un tableau qui résume les principales causes et leurs symptômes les plus fréquents.

Cause probable	Symptôme observé	Premier réflexe utile
Node.js non installé	« node n’est pas reconnu » sur tous les terminaux testés	Vérifier dans « Applications et fonctionnalités » si Node.js apparaît
Installation incomplète	Node absent mais des dossiers partiels présents sur le disque	Réinstaller Node.js via l’installateur officiel
PATH système mal configuré	node.exe accessible via son chemin complet, mais pas via « node »	Contrôler puis corriger les variables d’environnement
Conflit logiciel	Erreur apparue après installation d’un autre outil	Comparer le PATH avant/après, restaurer la ligne de Node.js
Redémarrage manquant	Nouvelle installation mais ancien terminal toujours ouvert	Fermer puis rouvrir le terminal ou redémarrer Windows

En résumé, comprendre ce message revient à comprendre comment Windows localise ses exécutables. Cette vision claire prépare le terrain pour la prochaine étape : vérifier si node.js est bien présent sur la machine.

Vérifier la présence réelle de Node.js sur votre machine

Avant de réinstaller ou de modifier vos variables d’environnement, il est judicieux de répondre à une question simple : Node.js est-il vraiment installé sur votre poste, et où se trouve-t-il exactement ? Cette vérification évite de multiplier les tentatives inutiles et vous donne un diagnostic précis.

Le premier niveau de contrôle passe par les paramètres Windows. Dans la rubrique des applications installées, Node.js doit apparaître avec sa version, par exemple « Node.js 22.x ». Si ce n’est pas le cas, l’installation node est soit inexistante, soit corrompue. Dans ce cas, aucun réglage de PATH ne suffira, il faudra repartir d’une installation propre.

Ensuite, un contrôle plus technique consiste à chercher directement l’exécutable node.exe. Classiquement, il se trouve dans un dossier proche de :

• C:Program Filesnodejs pour une installation par défaut 64 bits
• C:Program Files (x86)nodejs pour certaines configurations 32 bits ou anciennes

Si vous lancez l’Explorateur de fichiers et que vous atteignez ce dossier, la présence de node.exe et de npm.cmd est un bon indicateur. Toutefois, tous les outils ne se contentent pas de ce répertoire. Certains développeurs utilisent des gestionnaires de versions comme fnm ou nvm qui créent leurs propres sous-dossiers dans le profil utilisateur.

Dans les cas plus complexes, il est possible de rechercher « node.exe » sur l’ensemble du disque. Cette méthode prend plus de temps, mais peut révéler des installations oubliées, utiles pour comprendre pourquoi tel terminal lance une ancienne version, tandis qu’un autre affiche l’erreur node.

Une agence de formation a par exemple découvert que plusieurs versions de Node cohabitaient sur leurs machines de démo. Selon le raccourci utilisé, les stagiaires n’avaient ni la même version ni le même comportement. En rationalisant ces installations et en conservant un seul exécutable principal référencé dans le PATH, les incidents ont cessé.

Cette étape d’audit est essentielle : elle détermine si vous partez sur une réparation du path système ou sur une remise à plat de l’installation node. Une fois ce point éclairci, vient la question clé : comment lancer node même quand le PATH est incorrect, pour tester plus finement la situation.

Contourner temporairement l’erreur node avec les bons chemins

Dans le cas où l’exécutable est bien présent, mais que la commande non reconnue apparaît toujours, il est possible de contourner rapidement le problème en utilisant le chemin complet du programme. Cette approche permet de continuer à travailler, tout en préparant un correctif durable au niveau des variables d’environnement.

Concrètement, au lieu de taper simplement « node server.js » dans l’invité de commande, vous pouvez saisir le chemin complet jusqu’à node.exe puis le fichier JavaScript. Par exemple :

• « C:Program Filesnodejsnode.exe » server.js
• « C:UsersVotreNomOutilsnodenode.exe » app.js pour une installation personnalisée

Les guillemets sont importants dès que le chemin contient des espaces, ce qui est le cas de « Program Files ». Sans ces guillemets, Windows coupe le chemin au premier espace et croit que « C:Program » est le nom du programme, ce qui déclenche à nouveau l’erreur node. En entourant le tout de guillemets, vous lui indiquez qu’il s’agit d’un seul bloc.

Cette méthode est particulièrement utile dans des contextes projet. Imaginons une équipe marketing qui doit lancer un script de collecte de données prévu par l’équipe technique. Le script se trouve dans un dossier spécifique et l’installation globale de Node pose problème. En ajoutant dans la documentation interne une commande avec chemin complet, l’équipe peut exécuter le script sans toucher au path système, ce qui rassure l’IT sur l’absence de modifications profondes.

Il existe aussi un autre contournement, plus radical mais parfois pratique : copier provisoirement l’exécutable dans un dossier déjà présent dans le PATH, comme C:WindowsSystem32. Dans ce cas, le simple mot « node » devient à nouveau suffisant, car ce répertoire est systématiquement parcouru par Windows lorsqu’il interprète une commande.

Cependant, cette solution doit rester exceptionnelle, pour plusieurs raisons :

• Accumulation de fichiers : le dossier System32 peut rapidement se remplir d’exécutables non prévus.
• Outils dépendants d’un répertoire spécifique : certains binaires doivent rester dans leur dossier d’origine pour fonctionner correctement.
• Lisibilité de la configuration : déplacer les exécutables complique le support technique ultérieur.

Pour trancher sur l’approche à adopter, il est intéressant de visualiser l’impact de ces contournements par rapport à une correction du PATH lui-même.

Solution de contournement	Avantage principal	Limite ou risque
Utiliser le chemin complet avec guillemets	Fonctionne immédiatement, sans modifier la configuration globale	Commandes longues, peu pratiques au quotidien
Déplacer node.exe dans System32	Permet d’utiliser « node » partout sans autre modification	Entretien difficile, risque de confusion et d’incompatibilité
Scripts batch avec chemin codé en dur	Simplifie l’usage pour des non-techniciens	Nécessite une mise à jour à chaque changement de version

Ces options de secours sont pratiques pour débloquer un atelier, une démo client ou une campagne urgente. Toutefois, pour un environnement de travail stable, la vraie solution passe par une configuration propre des variables d’environnement, sujet du prochain volet.

Bien utiliser l’invité de commande et le terminal pour tester Node.js

Un point souvent négligé dans la résolution de problème tient au choix du terminal. Sur Windows, entre l’invité de commande classique, PowerShell, le nouveau Terminal Windows et le terminal intégré à un éditeur comme Visual Studio Code, les comportements peuvent sembler incohérents si le PATH est modifié en cours de route.

Après une nouvelle installation node ou une correction des variables d’environnement, il est indispensable de fermer les fenêtres de terminal ouvertes, puis de les rouvrir. Sinon, elles continuent d’utiliser une ancienne version du PATH, ce qui laisse croire que la configuration n’a pas été prise en compte. Ce simple réflexe évite de nombreux allers-retours inutiles.

Pour valider une configuration, une séquence de tests cohérente peut être suivie :

• Ouvrir un nouveau terminal.
• Lancer node -v pour vérifier que la version de Node s’affiche.
• Lancer npm -v pour contrôler la disponibilité du gestionnaire de paquets.
• Créer un petit fichier « test.js » qui affiche un message, puis exécuter node test.js.

Une entreprise qui forme régulièrement des équipes non techniques à l’usage d’outils en ligne de commande a institutionnalisé cette séquence. Avant chaque atelier, un check rapide sur ces quatre commandes permet de garantir que tout le monde part sur une base identique. Les incidents de type « commande non reconnue » ont été divisés par deux.

En maîtrisant ces contournements et ces tests, vous disposez déjà d’une trousse de secours efficace. L’étape structurante consiste maintenant à corriger le problème à la racine : le path système.

Configurer correctement les variables d’environnement et le PATH pour Node

La solution la plus robuste pour ne plus voir « node n’est pas reconnu en tant que commande interne ou externe » consiste à ajuster précisément les variables d’environnement, en particulier le path système. Il s’agit de déclarer à Windows où se trouve Node.js, afin qu’il puisse le lancer dès que vous tapez « node », quel que soit le dossier courant dans votre terminal.

Dans la pratique, cela se fait via les propriétés système avancées. Une fois cette fenêtre ouverte, on accède aux Variables d’environnement. Deux sections apparaissent alors : les variables de l’utilisateur courant et celles du système entier. Selon les politiques de sécurité de votre entreprise, vous pourrez intervenir sur l’une ou l’autre.

La démarche type pour corriger un erreur node liée au PATH ressemble à ceci :

• Ouvrir les propriétés système puis les Variables d’environnement.
• Repérer la variable Path dans la partie « Variables utilisateur ».
• L’éditer et ajouter une nouvelle entrée pointant vers le dossier d’installation de Node, par exemple C:Program Filesnodejs.
• Valider les modifications, fermer toutes les boîtes de dialogue puis relancer le terminal.

Cette simple manipulation change tout. Désormais, lorsque l’invité de commande reçoit la commande « node », il consulte sa liste de chemins, trouve celui de Node.js, et exécute le bon fichier. De la même manière, npm et npx seront également disponibles si le dossier d’installation contient leurs exécutables.

Dans certaines organisations, une question se pose : faut-il ajouter ce chemin au PATH utilisateur ou au PATH système ? Pour trancher, il est utile de comparer les approches.

Emplacement du PATH	Portée de la configuration	Cas d’usage recommandé
Path (Variables utilisateur)	Uniquement pour l’utilisateur connecté	Postes partagés ou environnements sensibles où chaque profil gère ses outils
Path (Variables système)	Pour tous les utilisateurs de la machine	Stations de développement dédiées, environnements pédagogiques, postes de build

Une ESN qui équipe ses développeurs front a ainsi choisi d’utiliser le PATH utilisateur, pour laisser à chacun la liberté de gérer plusieurs versions de Node avec des outils dédiés. À l’inverse, dans une école de code, le PATH système est privilégié pour garantir une expérience homogène à chaque session de formation, quel que soit le compte utilisé.

Dans tous les cas, l’essentiel est de documenter la configuration retenue. Une fiche interne ou un mini-guide partagé sur l’intranet permet à chacun de corriger un erreur node rapidement, sans solliciter inutilement l’équipe IT. Autrement dit, bien gérer ses variables d’environnement, c’est sécuriser son quotidien de travail numérique.

Sécuriser le PATH et éviter les conflits entre outils

Modifier le path système reste une action sensible, surtout sur des postes de travail utilisés dans un contexte professionnel. Une mauvaise manipulation peut faire disparaître d’autres chemins essentiels, ce qui entraîne à son tour de nouvelles erreurs de « commande non reconnue » pour d’autres outils.

Pour limiter ces risques, quelques précautions simples s’imposent :

• Faire une copie du PATH avant modification, dans un fichier texte.
• Éviter d’écraser la variable existante, toujours ajouter une entrée plutôt que remplacer.
• Vérifier les doublons pour Node.js ou npm afin de ne pas entretenir de confusion.

Au moment de l’édition, il est courant de voir plusieurs chemins similaires. Par exemple, différents dossiers « nodejs » peuvent être présents, liés à d’anciennes installations. Dans ce cas, il est utile de se poser deux questions : lesquels sont encore utilisés, et quelles versions de Node sont effectivement nécessaires pour les projets actuels.

Une DSI qui a encouragé l’usage de Node pour des scripts d’automatisation internes a rencontré ce cas. Certains collaborateurs avaient installé Node plusieurs fois, par différents canaux, puis modifié manuellement leur PATH. Résultat : des comportements aléatoires d’un terminal à l’autre. En auditant ces configurations et en standardisant une unique entrée dans le PATH, l’équipe a retrouvé un environnement stable et prévisible.

En gérant le PATH avec rigueur, vous évitez que la correction d’un erreur node n’en crée deux autres. La suite logique consiste maintenant à regarder le lien entre Node et npm, car l’un ne va pas sans l’autre dans la majorité des projets modernes.

Réinstaller proprement Node.js et corriger npm « commande non reconnue »

Quand la situation est trop confuse, qu’aucune correction de variables d’environnement ne résout le problème, une réinstallation node propre devient la voie la plus sûre. En effet, le gestionnaire de paquets npm, essentiel pour installer bibliothèques et frameworks, dépend étroitement de la qualité de cette installation.

La première étape consiste à désinstaller toute version existante de Node.js via les paramètres Windows. Après un redémarrage, le téléchargement du nouvel installateur se fait sur le site officiel de Node. Celui-ci propose généralement deux versions principales : une version LTS, plus stable, et une version « current », plus récente mais potentiellement moins éprouvée.

Le processus d’installation standard, lorsque l’on clique simplement sur « Next », coche en général l’option qui ajoute automatiquement Node et npm au path système. Ce détail fait toute la différence : en activant cette case, vous limitez drastiquement le risque de voir réapparaître l’erreur node ou l’alerte « npm n’est pas reconnu en tant que commande interne ou externe ».

Une fois l’installation terminée, il est pertinent de vérifier que tout fonctionne bien, dans cet ordre :

• node -v pour contrôler la version de Node.js installée.
• npm -v pour vérifier la présence de npm et son intégration au PATH.
• Un npm init -y dans un nouveau dossier de test, pour s’assurer que la création de projet fonctionne.

Dans certains cas, notamment sur des postes où plusieurs outils de versioning de Node sont utilisés, il reste nécessaire de paramétrer une variable spécifique qui pointe vers le dossier d’installation de Node. Cette variable peut s’appeler par exemple NODE_HOME et prendre pour valeur « C:Program Filesnodejs ». Elle est alors parfois utilisée par des IDE ou des scripts d’entreprise pour localiser plus facilement l’exécutable.

Pour visualiser la différence entre une installation partielle et une installation maîtrisée, le tableau suivant offre un bon repère.

Type d’installation	Résultat pour l’utilisateur	Impact sur la productivité
Installation sans ajout au PATH	Node accessible uniquement via le chemin complet, erreurs fréquentes dans le terminal	Temps perdu à corriger les commandes ou à chercher les exécutables
Installation avec PATH mal configuré	Comportement variable selon le terminal, messages de « commande non reconnue »	Incompréhension pour les profils non techniques, support IT sollicité régulièrement
Installation propre + PATH correctement ajouté	node et npm disponibles partout, commandes « node », « npm », « npx » fonctionnelles	Flux de travail fluide, adoption facilitée des outils JavaScript modernes

Dans une entreprise où les équipes marketing et produit expérimentent régulièrement des outils en ligne de commande (générateurs de sites statiques, outils d’analyse, scripts internes), cette rigueur sur l’installation node et npm fait gagner des heures. Un environnement fiable permet de se concentrer sur la valeur créée, pas sur la chasse aux erreurs de configuration.

Pourquoi npm échoue alors que node fonctionne parfois

Il arrive que « node » fonctionne correctement, mais que le terminal affiche « npm n’est pas reconnu en tant que commande interne ou externe ». Ce cas précis illustre bien la manière dont Windows gère les chemins et les exécutables associés.

Dans une installation standard, Node.js place plusieurs fichiers dans son dossier : l’exécutable node proprement dit et des scripts ou commandes comme npm.cmd. Si le path système pointe vers ce dossier, tout va bien. En revanche, si une mise à jour manuelle supprime ou déplace certains fichiers, ou si le PATH ne contient qu’un sous-dossier partiel, il est possible que node soit identifié, mais pas npm.

Pour résoudre ce scénario spécifique, un diagnostic rapide est utile :

• Vérifier la présence de npm.cmd et npx.cmd dans le dossier de Node.
• Comparer le chemin de ce dossier au contenu du PATH actuel.
• Réparer ou réinstaller Node.js si des fichiers manquent clairement.

Une startup SaaS qui déploie régulièrement des prototypes en Node a rencontré ce problème après un nettoyage automatique du disque sur plusieurs machines. Des utilitaires de « nettoyage » ont supprimé des fichiers jugés inutiles dans le dossier de Node, rompant le lien avec npm. Depuis, la règle interne est claire : aucun outil de nettoyage ne doit toucher à ces dossiers, et une procédure de vérification est lancée après chaque mise à jour majeure.

Cette vigilance autour de npm complète la montée en compétence sur Node lui-même. L’étape suivante, pour être vraiment à l’aise, consiste à réfléchir à de bonnes pratiques globales pour gérer les mises à jour, les scripts et les environnements, afin de ne plus subir ces messages d’erreurs, mais de les maîtriser.

Bonnes pratiques pour un environnement Node.js stable en entreprise ou en freelance

Au-delà de la correction ponctuelle d’un « erreur node », la question clé est d’éviter que ces incidents ne se répètent à chaque mise à jour ou à chaque nouveau poste de travail. Il s’agit donc de mettre en place quelques bonnes pratiques, simples mais efficaces, autour de Node.js, npm et des variables d’environnement.

Première bonne habitude : documenter un standard d’installation node pour votre équipe. Ce standard peut préciser la version recommandée, la source officielle de téléchargement, les options à cocher pendant l’installation, ainsi que le chemin attendu dans le path système. Une fois ce référentiel établi, chaque nouveau poste est configuré de la même manière, ce qui réduit drastiquement les variations imprévues.

Deuxième réflexe : centraliser les scripts courants dans un dépôt partagé. Plutôt que de laisser chaque collaborateur écrire ses propres commandes, vous pouvez proposer des scripts npm documentés, avec des instructions claires. Par exemple, un script « start » pour lancer un serveur local, ou un script « build » pour générer une version de production. Chaque script peut être testé dans un environnement contrôlé avant d’être diffusé, ce qui limite le risque d’erreur node ou de « commande non reconnue » auprès des utilisateurs finaux.

Troisième axe : former les équipes à lire et comprendre les messages d’erreur basiques du terminal. Savoir interpréter un « command is not recognized » comme un problème de PATH, et non comme un bug de l’outil lui-même, change la dynamique. Les non-développeurs gagnent en autonomie, l’IT est moins sollicitée pour des incidents mineurs, et les temps de blocage diminuent.

• Standardiser les versions de Node sur les projets critiques.
• Créer une courte fiche mémo sur l’usage de l’invité de commande et des chemins complets.
• Planifier des mises à jour plutôt que de les subir au fil de l’eau.

Pour les organisations plus matures techniquement, l’adoption d’outils de gestion de versions de Node (comme des gestionnaires multi-versions) peut également stabiliser les environnements. L’idée est de définir par projet une version précise de Node, afin d’éviter les écarts entre postes. Dans ce cadre, la configuration du PATH et des variables d’environnement reste au cœur du sujet, mais elle est pilotée par un outil dédié.

Un cabinet de conseil digital qui réalise des sites et des applications pour des clients variés a choisi cette voie. Chaque projet a son fichier de configuration de version, et l’outillage associé ajuste automatiquement le PATH en conséquence. Résultat : la phrase « node n’est pas reconnu » a quasiment disparu des échanges quotidiens, remplacée par des questions plus directement tournées vers le cœur métier.

Pour visualiser ces bonnes pratiques dans une optique opérationnelle, un tableau synthétique peut servir de check-list à adapter à votre contexte.

Pratique recommandée	Bénéfice concret	Niveau d’effort
Standardiser l’installation de Node.js	Moins d’écarts entre postes, déploiements plus prévisibles	Faible, une fois le standard défini
Documenter le PATH et les variables clés	Résolution plus rapide des erreurs de « commande non reconnue »	Moyen, nécessite une mise à jour régulière
Former aux bases de l’invité de commande	Autonomie accrue des équipes, moins de tickets IT	Variable, selon la taille des équipes
Utiliser un gestionnaire de versions de Node	Versions alignées par projet, moins de régressions	Moyen à élevé, selon l’outillage choisi

En définitive, faire disparaître la petite phrase « node n’est pas reconnu en tant que commande interne ou externe » ne tient pas à un coup de chance. Cela repose sur un mélange de configuration technique fiable, de documentation claire et de pédagogie auprès des équipes. Une fois cet équilibre trouvé, Node.js devient un allié fluide au service de vos projets, plutôt qu’une source récurrente de blocages dans le terminal.

FAQ

Comment vérifier rapidement si Node.js est bien installé sur Windows ?

Ouvrez un nouvel invité de commande ou terminal, puis tapez node -v. Si une version s’affiche, Node.js est installé et reconnu dans le PATH. Si le message « node n’est pas reconnu en tant que commande interne ou externe » apparaît, soit Node n’est pas installé, soit le chemin d’installation n’est pas présent dans les variables d’environnement.

Que faire si npm n’est pas reconnu alors que node fonctionne ?

Commencez par vérifier que npm.cmd est bien présent dans le dossier d’installation de Node.js. Ensuite, contrôlez que ce dossier figure dans le path système ou le PATH utilisateur. Si nécessaire, réinstallez Node.js depuis le site officiel en laissant l’option d’ajout au PATH activée.

Pourquoi dois-je redémarrer le terminal après avoir modifié le PATH ?

Chaque fenêtre de terminal charge les variables d’environnement au moment où elle s’ouvre. Si vous modifiez le PATH ensuite, l’ancienne fenêtre ne connaît pas ces nouveaux réglages. La fermer puis la rouvrir permet de charger la version à jour des variables et de faire disparaître l’erreur node.

Faut-il modifier le PATH utilisateur ou le PATH système pour Node.js ?

Pour un usage individuel, le PATH utilisateur suffit et limite l’impact des changements. Pour un poste partagé ou une machine de formation, ajouter Node.js au PATH système garantit que tous les comptes peuvent lancer la commande node sans configuration supplémentaire.

Est-il risqué de copier node.exe dans le dossier System32 ?

Cette méthode dépanne, mais elle n’est pas idéale. Elle peut compliquer la maintenance à long terme, notamment lors des mises à jour de Node.js, et encombrer System32. Il est préférable de laisser node dans son dossier d’installation et d’ajuster correctement les variables d’environnement.