Comment gérez-vous la configuration et les secrets dans Node ?

Question

Accepted Answer

La configuration (URL des bases de données, clés API, ports, drapeaux de fonctionnalités) doit vivre **en dehors de votre code** dans des variables d'environnement — jamais en dur. Cela garde les secrets hors du contrôle de version et permet au même code de s'exécuter en dev, staging et production avec des paramètres différents.

## Le principe : configuration de l'environnement

```js
// ❌ NEVER hardcode secrets — they end up in git history forever
const dbUrl = "postgres://admin:password123@db.example.com";

// ✅ read from the environment
const dbUrl = process.env.DATABASE_URL;
const port = process.env.PORT || 3000;
```

Cela suit le principe **twelve-factor app** : séparation stricte entre la configuration et le code, de sorte que le déploiement dans un nouvel environnement signifie changer les variables d'env, pas le code.

## Développement local : fichiers .env

```bash
# .env — local values, GITIGNORED (never committed)
DATABASE_URL=postgres://localhost/myapp_dev
JWT_SECRET=dev-secret
PORT=3000
```

```js
// load .env into process.env (older: dotenv; newer Node: --env-file flag)
import "dotenv/config";        // or: node --env-file=.env app.js
const secret = process.env.JWT_SECRET;
```

Un fichier `.env` contient la configuration locale ; il **doit être ignoré par git**. Validez un `.env.example` (avec les clés mais sans vraies valeurs) pour documenter ce qui est requis.

## Validez la configuration au démarrage

```js
import { z } from "zod";

const env = z.object({
  DATABASE_URL: z.string().url(),
  JWT_SECRET: z.string().min(16),
  PORT: z.coerce.number().default(3000),
}).parse(process.env); // ❗ fail FAST at startup if config is missing/invalid
```

Valider les variables d'env au démarrage (avec zod/envalid) signifie qu'un secret manquant ou mal formé s'écrase immédiatement avec un message clair — bien mieux qu'une défaillance d'exécution confuse au cœur d'une requête.

## Secrets en production

```text
Dev:        .env file (gitignored)
Production: injected by the platform/orchestrator —
            cloud secret managers (AWS Secrets Manager, GCP Secret Manager, Vault),
            container/orchestrator env vars, CI/CD secrets.
Never put production secrets in .env files committed or shipped with the app.
```

## Accès centralisé

```js
// config.js — one validated config module the app imports (don't sprinkle process.env everywhere)
export const config = { dbUrl: env.DATABASE_URL, port: env.PORT };
```

## Pourquoi c'est important

La gestion appropriée de la configuration et des secrets est à la fois une nécessité **sécurité** et **opérationnelle**.

Le codage en dur des secrets les divulgue au contrôle de version (une brèche grave et courante) ; mélanger la configuration au code rend le déploiement sur les environnements difficile.

L'approche standard — variables d'env, `.env` ignorée par git pour le développement local, `.env.example` pour la documentation, validation au démarrage et gestionnaires de secrets de plateforme en production — garde les secrets sûrs, rend l'application portable sur les environnements et expose les erreurs de configuration tôt.

C'est fondamental pour exécuter les apps Node de manière responsable.