Dire ce qu'il faut faire quand la connexion à la base est refusée

L'application redémarrait en boucle sur « P1000 » sans rien indiquer. Le point
d'entrée distingue désormais les deux causes et donne le remède.

Les deux codes ne disent pas la même chose, et c'est la mesure qui a permis de
les séparer : **P1010** signifie que le rôle n'existe pas, **P1000** qu'il existe
mais que son mot de passe ne correspond pas à celui que porte la pile — le cas
d'un rôle posé lors d'un déploiement antérieur avec une autre valeur. Le remède
est le même : `db-init` crée le rôle ou réaligne son mot de passe.

Le script d'initialisation lui-même a été éprouvé une fois de plus, y compris
avec l'argument parasite que Docker ajoute quand `entrypoint` est surchargé sans
`command` : il aboutit et pose le rôle.

Ce que je ne peux pas voir d'ici, et qu'il faut regarder sur le serveur : si le
service `db-init` figure dans la pile déployée, et ce qu'il a journalisé. Un
rôle dont le mot de passe ne correspond pas est précisément ce qu'il corrige.

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

docker-compose.yml

@@ -105,6 +105,8 @@ services:
       # salarié écrites dans la couche du conteneur disparaîtraient au premier
       # redéploiement, et une pièce d'identité perdue ne se reconstitue pas.
       DOCUMENT_STORE: /data/documents
+      # Sert uniquement au diagnostic affiché quand la connexion est refusée.
+      APP_DB_USER: ${APP_DB_USER:-planflow_app}
     volumes:
       - documents:/data
       # Volume distinct de la base et des documents : sauvegarder l'un ne doit