Créer le rôle applicatif à chaque démarrage, pas seulement au premier

Les migrations échouaient sur « Authentication failed for planflow_app ». Le
script qui crée ce rôle était monté dans /docker-entrypoint-initdb.d, lequel ne
s'exécute qu'à la **toute première** initialisation du volume : une pile dont le
volume existait déjà — créé par une tentative antérieure — n'a jamais vu passer
le rôle. Je l'avais noté dans le README au lieu de le traiter.

Un service `db-init` rejoue désormais le script à chaque démarrage, et le script
est rendu rejouable : il crée le rôle ou aligne son mot de passe, transfère la
propriété de la base, du schéma et des objets déjà présents. Les identifiants du
superutilisateur restent dans ce service ; les confier au conteneur applicatif
lui donnerait de quoi contourner la row-level security, ce que tout ce montage
cherche à empêcher.

Éprouvé sur une base créée par le superutilisateur, comme celle du client :
rôle posé en NOSUPERUSER NOBYPASSRLS, propriétaire de la base et des tables
préexistantes, capable de se connecter et d'exécuter du DDL ; les 22 migrations
s'appliquent ; la RLS le filtre — deux comptes visibles par le superutilisateur,
zéro par lui hors périmètre. Rejoué une seconde fois sans effet de bord.

Non vérifiable ici : l'authentification par mot de passe, mon cluster de
développement étant en mode `trust`.

Corrigé au passage une interférence entre tests : celui qui retire « Gérer les
rôles » aux rôles semés, pour atteindre le refus de verrouillage, s'exécutait en
parallèle de ceux qui s'appuient sur cette capacité et les faisait échouer par
intermittence. Le fichier passe en série.

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

docker-compose.yml

@@ -39,6 +39,36 @@ services:
     expose:
       - '5432'
 
+  # Pose le rôle applicatif à **chaque** démarrage de la pile.
+  #
+  # `/docker-entrypoint-initdb.d` ne s'exécute qu'à la toute première
+  # initialisation du volume : un volume créé par une tentative antérieure
+  # n'aurait jamais vu passer ce rôle, et l'application échouerait à
+  # s'authentifier sans que rien n'explique pourquoi. Le script est rejouable,
+  # ce service le rejoue.
+  #
+  # Les identifiants du superutilisateur restent ici : les confier au conteneur
+  # applicatif lui donnerait de quoi contourner la row-level security, ce que
+  # tout ce montage cherche précisément à empêcher.
+  db-init:
+    image: postgres:16-alpine
+    restart: 'no'
+    depends_on:
+      db:
+        condition: service_healthy
+    environment:
+      PGHOST: db
+      PGPASSWORD: ${POSTGRES_PASSWORD:-planflow-interne}
+      POSTGRES_USER: ${POSTGRES_USER:-planflow}
+      POSTGRES_DB: ${POSTGRES_DB:-planflow}
+      APP_DB_USER: ${APP_DB_USER:-planflow_app}
+      APP_DB_PASSWORD: ${APP_DB_PASSWORD:-planflow-app-interne}
+    volumes:
+      - ./docker/init-app-role.sh:/init-app-role.sh:ro
+    entrypoint: ['sh', '/init-app-role.sh']
+    networks:
+      - interne
+
   app:
     build:
       context: .
@@ -46,6 +76,8 @@ services:
     depends_on:
       db:
         condition: service_healthy
+      db-init:
+        condition: service_completed_successfully
     environment:
       NODE_ENV: production
       # Le compte applicatif, **pas** le superutilisateur d'amorçage : un