Produire la clé de chiffrement au premier démarrage

Le déploiement restait bloqué sur ENCRYPTION_KEY. J'ai tenu trop longtemps la
position « pas de valeur par défaut », en confondant deux choses : refuser une
clé livrée avec l'image — ce qui reste juste, une clé publiée dans un dépôt ne
protège rien — et exiger qu'un humain en fabrique une avant tout démarrage.

Une variable d'environnement n'est d'ailleurs pas un bon coffre : elle s'affiche
dans `docker inspect` et dans l'interface de gestion. Un fichier produit au
démarrage, dans un volume distinct de la base et des documents, n'est pas moins
protégé — et une sauvegarde de l'un n'emporte plus la clé de l'autre.

Le point d'entrée la produit donc si elle manque, l'écrit en 0600, et l'affiche
une fois dans les journaux avec ce qu'il faut en faire. Une clé fournie
explicitement l'emporte toujours : un déploiement qui gère ses secrets ailleurs
ne doit pas être contrarié. La pile démarre désormais sans aucune variable.

Éprouvé sur le script lui-même : première exécution, clé de 32 octets produite
et annoncée ; deuxième, reprise en silence depuis le fichier ; avec une clé
fournie, le fichier reste intact.

Corrigé au passage, révélé par un échec transitoire du test : une écriture
disque impossible — volume plein, droits, montage absent — remontait en
exception non traitée. L'écran restait muet, la pièce n'était pas déposée et
rien ne le disait.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Cr9dkEHwbDgkWPnyGj1Rjv

docker/entrypoint.sh

@@ -0,0 +1,54 @@
+#!/bin/sh
+set -eu
+
+# Démarrage du conteneur applicatif.
+#
+# La clé de chiffrement protège le NIR, l'IBAN, les secrets de second facteur et
+# les pièces du dossier salarié. Elle doit exister avant que quoi que ce soit
+# démarre — mais l'exiger en variable d'environnement rendait tout déploiement
+# impossible sans une étape manuelle, et une variable d'environnement n'est de
+# toute façon pas un bon coffre : elle s'affiche dans `docker inspect` et dans
+# l'interface de gestion.
+#
+# Elle est donc produite au premier démarrage et conservée dans un volume
+# **distinct** de la base et des documents : une sauvegarde de l'un ne doit pas
+# emporter la clé de l'autre.
+#
+# `ENCRYPTION_KEY` fournie explicitement l'emporte toujours : un déploiement qui
+# gère ses secrets par ailleurs ne doit pas être contrarié.
+
+KEY_FILE="${ENCRYPTION_KEY_FILE:-/secrets/encryption.key}"
+
+if [ -z "${ENCRYPTION_KEY:-}" ]; then
+  if [ -f "$KEY_FILE" ]; then
+    ENCRYPTION_KEY="$(cat "$KEY_FILE")"
+  else
+    mkdir -p "$(dirname "$KEY_FILE")"
+    ENCRYPTION_KEY="$(node -e "process.stdout.write(require('node:crypto').randomBytes(32).toString('base64'))")"
+    # Écriture puis restriction : le fichier ne doit jamais être lisible par
+    # d'autres, même brièvement.
+    (umask 077; printf '%s' "$ENCRYPTION_KEY" > "$KEY_FILE")
+
+    echo ''
+    echo '════════════════════════════════════════════════════════════════'
+    echo ' Clé de chiffrement produite au premier démarrage.'
+    echo ''
+    echo "   $ENCRYPTION_KEY"
+    echo ''
+    echo ' Conservez-la hors de ce serveur. Sans elle, le NIR, les IBAN et'
+    echo ' les pièces du dossier salarié sont définitivement illisibles.'
+    echo ''
+    echo " Elle est stockée dans $KEY_FILE, sur un volume distinct de la"
+    echo ' base et des documents — à sauvegarder séparément.'
+    echo '════════════════════════════════════════════════════════════════'
+    echo ''
+  fi
+fi
+
+export ENCRYPTION_KEY
+
+# Les migrations s'appliquent au démarrage : l'image se déploie sans étape
+# séparée.
+./node_modules/.bin/prisma migrate deploy
+
+exec node server.js