Référence des commandes Node.js pour les serveurs de développement local et en production

nodejs

Le codage assisté par l’IA a transformé la manière dont les projets sont développés. Vous décrivez le résultat souhaité, un assistant IA génère le code, et en quelques minutes vous avez déjà quelque chose qui fonctionne. Cependant, il y a une situation que aucun assistant ne peut gérer à votre place : lorsque vous êtes face à une fenêtre de terminal et que vous devez connaître la commande exacte à taper.

Peut-être qu’un déploiement échoue sur le serveur distant. Peut-être qu’une installation échoue en cours de route. Peut-être que les variables d’environnement refusent de se charger, ou qu’un processus s’arrête sans laisser de trace utile. Dans ces cas, vous ne voulez pas parcourir des pages entières de documentation — vous souhaitez un répertoire rapide que vous pouvez consulter en quelques secondes.

C’est là l’objectif de ce guide : un manuel compact des commandes Node.js pour deux contextes — travailler sur votre ordinateur local et gérer un serveur en production. Chaque commande est accompagnée d’une brève indication sur quand elle constitue l’outil approprié.

Démarrer Node.js

Commencez par les bases que vous devriez connaître sans hésiter :

# Run a JavaScript file
node app.js

# Run with an environment variable inline
NODE_ENV=production node app.js

# Open the REPL (Read-Eval-Print Loop) - interactive Node.js shell
node

# Evaluate JavaScript directly from the terminal
node -e "console.log(process.version)"

# Check the active Node.js version
node -v
node --version


# Check the active npm version
npm -v

Flagues CLI utiles

# Watch mode — auto-restart when files change (Node.js 18+, no nodemon needed)
node --watch app.js

# Enable ES Modules
node --input-type=module app.js

# Increase memory limit for heavy applications
node --max-old-space-size=4096 app.js

# Show longer stack traces
node --stack-trace-limit=50 app.js

# Inspect mode for debugging with Chrome DevTools
node --inspect app.js
node --inspect-brk app.js  # Pause at first line until debugger connects

Gestion des versions de Node.js — NVM

Pour toute personne gérant plusieurs projets exigeant chacun une version différente de Node.js, nvm (Node Version Manager) devient une nécessité plutôt qu’un simple avantage pratique.

# Install a specific Node.js version
nvm install 22
nvm install 20.11.0     # Exact version
nvm install --lts       # Latest LTS

# Switch versions
nvm use 22
nvm use --lts

# Set a default version
nvm alias default 22

# List all installed versions
nvm ls

# List available remote versions
nvm ls-remote --lts

# Use the version specified in .nvmrc
nvm use

# Create .nvmrc - lock the Node.js version for this project
echo "22" > .nvmrc

Gestionnaires de paquets — npm, yarn et pnpm

Choisir un gestionnaire de paquets va au-delà d’une simple préférence stylistique — chaque option présente des compromis réels.

Au début de 2026, pnpm est devenu le choix par défaut logique pour la plupart des équipes. Il s’installe rapidement, utilise efficacement l’espace disque, évite le problème des dépendances fantômes et offre les outils les plus performants pour les monorepos. Le support des outils a également suivi — des frameworks tels que Next.js, Nuxt et SvelteKit fonctionnent tous parfaitement avec pnpm.

Cependant, le choix du plus adapté dépend de votre situation :

• npm — inclus par défaut avec Node.js, fonctionne partout, c’est une option fiable pour les projets individuels et les paquets open source
• yarn — se distingue dans les grands monorepos à l’échelle d’entreprise, en particulier lorsqu’il est utilisé avec Plug’n’Play (PnP)
• pnpm — l’option la plus rapide et la plus économe en espace de stockage, ainsi que le choix privilégié pour les environnements de production et les monorepos en 2026

Commandes de base — Les trois gestionnaires de paquets côte à côte

# Install all dependencies from package.json
npm install
yarn install
pnpm install

# Add a new package
npm install express
yarn add express
pnpm add express

# Add as a devDependency
npm install -D typescript
yarn add -D typescript
pnpm add -D typescript

# Remove a package
npm uninstall express
yarn remove express
pnpm remove express

# Update packages
npm update
yarn upgrade
pnpm update

# Update to latest (beyond semver range in package.json)
npm install express@latest
yarn add express@latest
pnpm add express@latest

# Install without modifying the lockfile - required in CI/CD
npm ci
yarn install --frozen-lockfile
pnpm install --frozen-lockfile

# Run a script from package.json
npm run build
yarn build
pnpm build

# Run a package executable without installing globally
npx create-next-app
yarn dlx create-next-app
pnpm dlx create-next-app

package.json — Les éléments les plus importants

{
  "name": "my-app",
  "version": "1.0.0",
  "engines": {
    "node": ">=20.0.0",
    "npm": ">=10.0.0"
  },
  "scripts": {
    "dev": "node --watch src/index.js",
    "start": "node src/index.js",
    "build": "tsc -p tsconfig.json",
    "test": "node --test",
    "lint": "eslint src/",
    "format": "prettier --write src/"
  },
  "dependencies": {},
  "devDependencies": {},
  "type": "module"
}

Audit et sécurité

# Check for vulnerabilities in dependencies
npm audit
yarn audit
pnpm audit

# Auto-fix vulnerabilities where possible
npm audit fix
yarn audit --fix
pnpm audit --fix

# List all installed packages (including nested)
npm list
npm list --depth=0    # Top-level only

# Check for outdated packages
npm outdated
yarn outdated
pnpm outdated

Variables d’environnement

Les variables d’environnement vous permettent de séparer la configuration entre le développement et la production. Évitez d’insérer des secrets tels que des clés API ou des adresses de base de données directement dans vos fichiers sources.

# Create a .env file
cat > .env << EOF
NODE_ENV=development
PORT=3000
DATABASE_URL=postgresql://localhost:5432/mydb
JWT_SECRET=your-secret-key
EOF

# Make sure .env never enters version control
echo ".env"            >> .gitignore
echo ".env.local"      >> .gitignore
echo ".env.production" >> .gitignore

# Create .env.example as a template for your team
cp .env .env.example

# Then remove the sensitive values from .env.example

Dans votre code Node.js :

// Node.js 20.6+ — load .env without any extra package
// Run with: node --env-file=.env app.js

// Or use dotenv for more flexibility
import 'dotenv/config';
const port    = process.env.PORT         || 3000;
const dbUrl   = process.env.DATABASE_URL;
const nodeEnv = process.env.NODE_ENV     || 'development';

// Validate required env vars at startup - fail fast
const required = ['DATABASE_URL', 'JWT_SECRET'];
for (const key of required) {
    if (!process.env[key]) {
        console.error(`Missing required environment variable: ${key}`);
        process.exit(1);
    }
}

Système de modules — CommonJS contre ES Modules

Node.js prend toujours en charge deux formats de modules, mais les nouveaux projets devraient privilégier les ES Modules, car il s’agit de la norme moderne partagée avec les navigateurs.

// CommonJS (CJS) — the legacy format, .js or .cjs files
const fs      = require('fs');
const path    = require('path');
const express = require('express');

module.exports = { myFunction };
module.exports.default = MyClass;

// ES Modules (ESM) - the modern format, .mjs or .js with "type":"module"
import fs      from 'fs';
import path    from 'path';
import express from 'express';
import { readFile, writeFile } from 'fs/promises';
export function myFunction() {}
export default class MyClass {}

// Dynamic import - for lazy loading
const module = await import('./heavy-module.js');

Système de fichiers — Les opérations les plus utilisées

import { readFile, writeFile, appendFile,
         mkdir, rm, stat, readdir,
         copyFile, rename } from 'fs/promises';
import { existsSync }       from 'fs';
import path                 from 'path';

// Read a file
const content = await readFile('data.txt', 'utf-8');
const json    = JSON.parse(await readFile('config.json', 'utf-8'));

// Write a file
await writeFile('output.txt', 'Hello World', 'utf-8');
await writeFile('data.json', JSON.stringify(data, null, 2));

// Append to an existing file
await appendFile('log.txt', `${new Date().toISOString()} - event\n`);

// Create a directory (including missing parents)
await mkdir('logs/2026/06', { recursive: true });

// Delete a file or directory
await rm('temp-file.txt');
await rm('dist/', { recursive: true, force: true });

// Check if a file or directory exists
if (existsSync('config.json')) {
    // file exists
}

// Get file metadata
const info = await stat('app.js');
console.log(info.size);           // size in bytes
console.log(info.isDirectory());
console.log(info.mtime);          // last modified time

// Read directory contents
const files   = await readdir('./src');
const jsFiles = files.filter(f => f.endsWith('.js'));

// Path helpers - always use path.join, never string concatenation
const filePath = path.join(__dirname, 'public', 'index.html');
const ext      = path.extname('script.js');       // '.js'
const base     = path.basename('/src/app.js');    // 'app.js'
const dir      = path.dirname('/src/app.js');     // '/src'

Serveur HTTP — Intégré, aucun framework requis

import { createServer }     from 'http';
import { createReadStream } from 'fs';

const server = createServer(async (req, res) => {
    const url    = new URL(req.url, `http://${req.headers.host}`);
    const method = req.method;

    // Simple routing
    if (url.pathname === '/' && method === 'GET') {
        res.writeHead(200, { 'Content-Type': 'text/html' });
        res.end('<h1>Hello World</h1>');
        return;
    }

    if (url.pathname === '/api/health' && method === 'GET') {
        res.writeHead(200, { 'Content-Type': 'application/json' });
        res.end(JSON.stringify({ status: 'ok', timestamp: new Date() }));
        return;
    }

    // Read body from a POST request
    if (method === 'POST') {
        let body = '';
        for await (const chunk of req) {
            body += chunk;
        }
        const data = JSON.parse(body);
        // process data...
    }

    // 404
    res.writeHead(404, { 'Content-Type': 'application/json' });
    res.end(JSON.stringify({ error: 'Not Found' }));
});

const PORT = process.env.PORT || 3000;
server.listen(PORT, () => {
    console.log(`Server running at http://localhost:${PORT}`);
});

Gestion des processus

// Graceful shutdown — close connections before the process exits
process.on('SIGTERM', async () => {
    console.log('SIGTERM received, shutting down...');
    await db.disconnect();
    server.close(() => {
        console.log('Server closed');
        process.exit(0);
    });
});

process.on('SIGINT', async () => {
    // Ctrl+C in terminal
    await cleanup();
    process.exit(0);
});

// Catch unhandled errors
process.on('uncaughtException', (err) => {
    console.error('Uncaught Exception:', err);
    process.exit(1); // Must exit - process state is now unreliable
});

process.on('unhandledRejection', (reason, promise) => {
    console.error('Unhandled Rejection:', reason);
    process.exit(1);
});

// Process information
console.log(process.pid);           // Process ID
console.log(process.env.NODE_ENV);  // Environment
console.log(process.argv);          // CLI arguments
console.log(process.cwd());         // Current working directory
console.log(process.memoryUsage()); // Memory usage

Débogage

# Inspect mode — open chrome://inspect in your browser
node --inspect app.js

# Pause at the first line until the debugger connects
node --inspect-brk app.js

# Enable verbose logging for specific modules
NODE_DEBUG=http,net node app.js

# CPU profiling
node --prof app.js
node --prof-process isolate-*.log > processed.txt

# Memory leak detection
node --expose-gc --inspect app.js

Dans votre code :

// util.debuglog — only outputs when the DEBUG env var is set
import { debuglog } from 'util';
const debug = debuglog('myapp');

debug('This only appears when: NODE_DEBUG=myapp node app.js');

// Simple timing
console.time('database-query');
await db.query('SELECT * FROM users');
console.timeEnd('database-query');

// Output: database-query: 23.456ms

PM2 — Gestionnaire de processus pour le production

PM2 est l’outil idéal pour exécuter Node.js en environnement de production. Il redémarre automatiquement votre application après une panne ou un redémarrage du serveur, et peut s’adapter à plusieurs cœurs CPU avec très peu de configuration.

# Install PM2 globally
npm install -g pm2

# Start an application
pm2 start app.js
pm2 start app.js --name "my-api"

# Start in cluster mode - uses all available CPU cores
pm2 start app.js -i max   # Automatically matches CPU core count
pm2 start app.js -i 4     # Exactly 4 instances

# View status of all applications
pm2 list
pm2 status

# Real-time monitoring (CPU, memory, logs)
pm2 monit

# View logs
pm2 logs
pm2 logs my-api
pm2 logs --lines 100

# Restart, reload, stop, delete
pm2 restart my-api
pm2 reload my-api    # Zero-downtime reload (cluster mode only)
pm2 stop my-api
pm2 delete my-api

# Auto-restart on server reboot
pm2 startup          # Generates the systemd command - follow the output
pm2 save             # Saves the current process list

# Configuration file

// ecosystem.config.js
export default {
    apps: [{
        name:               'my-api',
        script:             'src/index.js',
        instances:          'max',
        exec_mode:          'cluster',
        watch:              false,
        max_memory_restart: '500M',
        env: {
            NODE_ENV: 'development',
            PORT:     3000,
        },
        env_production: {
            NODE_ENV: 'production',
            PORT:     8080,
        },
        error_file:      'logs/err.log',
        out_file:        'logs/out.log',
        log_date_format: 'YYYY-MM-DD HH:mm:ss',
    }]
};

# Start from the config file
pm2 start ecosystem.config.js
pm2 start ecosystem.config.js --env production

Déploiement sur un serveur Linux

Voici la séquence à suivre pour installer Node.js sur un VPS ou une machine Linux pour la première fois.

# 1. Update the system
sudo apt update && sudo apt upgrade -y

# 2. Install Node.js via NodeSource (latest LTS)
curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt install -y nodejs

# Or install via nvm for easier version management
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
source ~/.bashrc
nvm install --lts
nvm use --lts

# 3. Verify the installation
node -v
npm -v

# 4. Install PM2 globally
npm install -g pm2

# 5. Clone and set up the project
git clone https://github.com/username/my-app.git
cd my-app

# 6. Install production dependencies only
npm ci --omit=dev

# or with pnpm
pnpm install --prod --frozen-lockfile

# 7. Create the production .env
nano .env

# 8. Start with PM2
pm2 start ecosystem.config.js --env production
pm2 save
pm2 startup   # Follow the printed instructions

Mettre à jour une déploiement sans interruption de service

# Pull the latest code
git pull origin main

# Install any new dependencies
npm ci --omit=dev

# Build if needed
npm run build

# Zero-downtime reload (cluster mode only)
pm2 reload my-api

# Or a standard restart
pm2 restart my-api

Commandes Linux que vous utiliserez réellement lors de la maintenance de Node.js

# Check what's running on a specific port
lsof -i :3000
sudo netstat -tlnp | grep :3000
sudo ss -tlnp | grep :3000

# Kill whatever is on a port
kill $(lsof -t -i:3000)

# Or forcefully
kill -9 $(lsof -t -i:3000)

# Real-time resource monitoring
htop                   # Interactive (install with: apt install htop)
top                    # Built-in alternative

# Disk usage
df -h                  # Per partition
du -sh node_modules/   # Size of a specific directory
du -sh *               # Size of everything in the current directory

# Follow logs in real time
journalctl -u pm2-root -f   # PM2 logs via systemd
tail -f /var/log/syslog     # System log
tail -f logs/err.log        # Your application error log

# Memory overview
free -h

# Active network connections
ss -s

# Find all running Node.js processes
ps aux | grep node

# Find files by name or age
find . -name "*.log" -mtime +7   # .log files older than 7 days
find . -name "*.env"             # Any .env files

# Clean up old logs
find ./logs -name "*.log" -mtime +30 -delete

# Archive a folder for backup
tar -czf backup-$(date +%Y%m%d).tar.gz dist/ .env

# Transfer files to/from a server
scp -r ./dist user@server:/var/www/my-app/
rsync -avz ./dist/ user@server:/var/www/my-app/dist/

.npmrc et .nvmrc — Deux petits fichiers importants

Ces deux fichiers de configuration peuvent sembler anodins, mais ils deviennent très importants lorsque vous travaillez en équipe.

# .nvmrc — pin the Node.js version for this project
# Place at the project root
echo "22" > .nvmrc

# Everyone on the team just runs:
nvm use
# NVM automatically reads the version from .nvmrc

# .npmrc — npm/pnpm configuration for this project
# Place at the project root

# Save exact versions (no ^ or ~ prefix)
save-exact=true

# Set registry (if using a private registry)
registry=https://registry.npmjs.org/

# For pnpm - allow hoisting if a package requires it
# shamefully-hoist=true
# For pnpm - set the node linker
# node-linker=hoisted

Tests — Exécuteur de tests intégré à Node.js

Dès Node.js 20, un exécuteur de tests est inclus avec le runtime lui-même. Pour des suites de tests basiques, vous pouvez complètement éviter d’installer Jest ou Mocha.

// test/app.test.js
import { test, describe, beforeEach, afterEach } from 'node:test';
import assert from 'node:assert/strict';

describe('Calculator', () => {
    test('addition works correctly', () => {
        assert.equal(1 + 1, 2);
    });

    test('throws on division by zero', () => {
        assert.throws(
            () => divide(10, 0),
            { message: 'Cannot divide by zero' }
        );
    });

    test('async operation resolves correctly', async () => {
        const result = await fetchUser(1);
        assert.equal(result.id, 1);
        assert.ok(result.name);
    });
});

# Run all tests
node --test

# Run a specific test file
node --test test/app.test.js

# Watch mode - re-run on file changes
node --test --watch

# With coverage (Node.js 22+)
node --test --experimental-test-coverage

Checklist avant mise en production

Vérifiez cette liste avant de mettre votre application Node.js en ligne :

• NODE_ENV=production est défini — cela active les optimisations de performance dans Express et d’autres bibliothèques
• Toute variable d’environnement nécessaire à votre application existe sur le serveur lui-même, et non seulement dans votre fichier .env local
• Vous exécutez npm ci --omit=dev au lieu de npm install, de sorte que seules les dépendances de production sont installées
• Le fichier de verrouillage (package-lock.json ou pnpm-lock.yaml) est intégré à git — l’omettre peut permettre au système CI/CD d’utiliser des versions de dépendances différentes de celles que vous avez testées
• Une logique de arrêt propre est en place, avec un traitement correct des signaux SIGTERM et SIGINT
• La surveillance des erreurs est activée — les événements unhandledRejection et uncaughtException sont enregistrés et déclenchent des alertes

Démarrage de PM2 a été configuré de manière à ce que l’application redémarre automatiquement après un redémarrage du serveur

Limitation des débits est activée pour protéger votre API contre les abus

Point d’entrée de vérification de santé est exposé, car les balanceurs de charge et les moniteurs de disponibilité en dépendent

Remarques finales

Il n’est pas nécessaire de mémoriser tout ce qui figure dans ce guide d’un seul coup. Ajoutez-le à vos favoris, revenez-y chaque fois qu’une commande vous échappe, et avec le temps, le flux de travail s’imposera sans effort.

Les outils d’intelligence artificielle sont excellents pour générer du code et structurer des projets entiers durant cette phase de codage rapide — mais lorsque vous faites face à un serveur en panne au milieu de la nuit, ce qui est vraiment utile, c’est de connaître par cœur vos outils. Pas d’essais-erreurs. Pas de panique.

Concentrez-vous d’abord sur les éléments que vous manipulerez constamment : les gestionnaires de paquets, les variables d’environnement et PM2. Tout le reste s’organisera naturellement au fur et à mesure de vos besoins.

Lectures complémentaires

npm vs pnpm : Comparaison du stockage, de la vitesse et des compromis dans le monde réel — Cet article compare la manière dont npm et pnpm gèrent le stockage des dépendances, la vitesse d’installation ainsi que les workflows de monorepo afin de vous aider à choisir l’outil adapté à votre projet.

Développement local d’Azure Functions : Correction des points de défaillance courants — Découvrez comment les outils de base, les environnements de exécution des langages et Azurite doivent être en harmonie, et obtenez des solutions pratiques pour local.settings.json, les déclencheurs et les erreurs de débogage.