# Politique de centralisation des variables et secrets (.env.master)

Objectif: toutes les variables d’environnement (publiques et privées) utilisées par les services doivent être centralisées dans `lecoffre_node/.env.master`. Aucun fichier Dockerfile ni docker-compose ne doit redéclarer des valeurs en dur qui divergeraient.

## Règles

- Fichier source unique: `lecoffre_node/.env.master`
- Chargement docker-compose: tous les services référencent `env_file: .env.master` et n’overrident pas les clés déjà définies.
- Aucune valeur sensible dans les Dockerfile/images. Utiliser exclusivement les variables passées par l’environnement (build args pour le front, runtime env pour les autres).
- Variables publiques Next.js: préfixe `NEXT_PUBLIC_` (intégrées au build). Variables privées: sans préfixe (non exposées au client).
- Secrets: clés API, tokens, mots de passe restent dans `.env.master` (jamais commités hors de ce dépôt privé). Fournir un `ENV_EXAMPLE.md` synchronisé.

## Mapping par service

- lecoffre-front (Next.js)
  - Build-time: `NEXT_PUBLIC_*` via docker-compose build args → Dockerfile ARG/ENV → Next publicRuntimeConfig/env
  - Runtime: idem (les valeurs restent exportées pour l’inspection)
- sdk_signer
  - Runtime uniquement: `SIGNER_*` (ex: `SIGNER_API_KEY`, `SIGNER_WS_URL`, etc.) chargées via `env_file` sans override local.
- sdk_relay, sdk_storage, ihm_client
  - Runtime: variables `SDK_RELAY_*`, `VITE_*` (pour IHM), etc. via `.env.master`
- Autres services (bitcoin, blindbit, …)
  - Utiliser l’env pour toute config personnalisable; ne pas coder en dur.

## Bonnes pratiques

- N’ajouter de nouvelles variables qu’en les documentant dans `ENV_EXAMPLE.md` et ce fichier.
- Préférer des URLs de services Docker (ex: `http://service:port`) au lieu d’IP/host externes.
- Interdire toute duplication: si une valeur existe dans `.env.master`, ne pas la re-déclarer ailleurs.
- Logique de fallback uniquement côté code applicatif (jamais dans l’infra).

## Vérification rapide

- Front: `GET /lecoffre/api/env` et `/lecoffre/env` (no-store) pour voir les `NEXT_PUBLIC_*` en vigueur.
- Container: `docker exec <svc> env | grep -E '^(PREFIX_)'` pour contrôler.

## Process

1) Ajouter/mettre à jour la variable dans `.env.master`
2) Mettre à jour `ENV_EXAMPLE.md`
3) Rebuild/restart si nécessaire (front: rebuild; autres: recreate)
4) Vérifier via endpoints/container