docs: analyse fragilites dependances stack 43 containers

common/fragilites-dependances-stack-20260703.md

@@ -0,0 +1,48 @@
+# Fragilites de dependances — stack 43 containers (analyse 03/07/2026)
+
+Analyse systematique restart-policy / persistance / couplages, croisee avec les pieges deja documentes (allow_all_keys Bifrost, footer DOCX nyora-doc-api, Portainer ID dynamique). Etat REEL via socket Docker.
+
+## CRITIQUE
+
+### 1. n8n + n8n-DB en restart=on-failure
+Ne redemarrent PAS apres un arret systeme / coupure courant (Docker ne relance au boot que `always` et `unless-stopped` ; `on-failure` ne re-tente qu'apres un crash pendant que le demon tourne). n8n = orchestration centrale (veille, ingestion, routing LLM). Apres coupure EDF Sfax -> toute l'automatisation reste DOWN jusqu'a intervention manuelle.
+FIX : passer n8n ET n8n-DB en `restart: unless-stopped` (compose n8n) + recreate. Aucun changement d'image.
+
+### 2. rla-api pointe vers des services MORTS (couplage casse silencieux)
+Env rla-api : `GOTENBERG_URL` -> port 3001 (= pihole aujourd'hui, repond 403) et `PPTX_API_URL` -> 8015 (mort, 000). Ces deux services ont ete desinstalles (21/06 et 29/06). Toute generation PDF/PPTX des 55 contrats RLA echoue silencieusement.
+FIX : repointer rla-api vers nyora-doc-api (port 3050) qui remplace tout l'ancien stack doc. Mettre a jour les 2 variables d'env + recreate. Verifier le format d'appel attendu par nyora-doc-api.
+
+## ELEVE
+
+### 3. reglement-definitif-api : restart=no + image locale + 0 mount + 0 env
+Ne remonte jamais automatiquement (ni au boot, ni apres crash). Image `reglement-definitif:latest` construite localement (pas de registry -> irrecuperable si supprimee). 0 env visible = configuration entierement bakee dans l'image (fragile, non auditable). API metier TT.
+FIX : `restart: unless-stopped` ; verifier que le Dockerfile source est versionne sur Gitea ; documenter la config (actuellement opaque).
+
+### 4. Trilium en restart=no
+Notes personnelles ; ne remonte pas au boot. FIX : `unless-stopped`.
+
+### 5. Images construites localement sans registry (irrecuperables si prune -a)
+rla-api, reglement-definitif, dashboard-terrain, nyora-doc-api, family-help, context-hub, gsparc-mezzouna, nyora-veille, panda-dashboard : images locales sans tag registry. Un `docker image prune -a` (ou un prune agressif) les supprime DEFINITIVEMENT — reconstruction possible seulement si le Dockerfile source existe encore. Le protocole Hermes recommande un prune regulier (builds :latest empilent du GB) -> danger reel de supprimer une image metier.
+FIX : (a) versionner TOUS les Dockerfiles sur Gitea (backup source) ; (b) ne jamais utiliser `prune -a`, seulement `prune` (dangling) ; (c) idealement pousser les images critiques sur le registry Gitea.
+
+## MOYEN
+
+### 6. bifrost-proxy sans healthcheck
+Maillon auth-rewrite + cap 16384 tokens devant Bifrost ; tout Hermes + n8n passe par lui. S'il fige (up mais non-repondant), rien ne le detecte ni le relance. FIX : ajouter un healthcheck (curl interne) au compose bifrost-proxy.
+
+### 7. Services critiques sans healthcheck (up-but-broken indetectable)
+family-help, redaction-pro, context-hub, veille-backend/frontend, hermes-mail-proxy, dashboard-terrain, rla-api, reglement-definitif-api. FIX : ajouter healthcheck HTTP simple par service (progressif, non urgent).
+
+### 8. rla-api isole sur reseau bridge
+Appele via 172.17.0.1:3005 (IP host bridge). Ne peut pas joindre les autres services par nom Docker. Fonctionnel mais fragile. FIX (optionnel) : rattacher au reseau `n8n`.
+
+## VERIFIE SAIN (contrairement aux apparences)
+- **Bifrost allow_all_keys=1** actif sur toutes les VK/providers ET config.db bien monte dans /app/data -> le fix SURVIT au recreate. Seul vecteur de perte = editer via l'UI Bifrost (deja documente : bifrost-access.md, OPENCODE-GO-MIGRATION.md). Pas de nouvel equivalent DB cache trouve ailleurs.
+- **hermes-workspace-* : 0 mount = sandbox jetable BY DESIGN** (l'etat — soul.md, skills, memory — vit dans les hermes-agent-* qui montent /opt/data). Normal, pas une fuite.
+- **watchtower-nas en MONITOR_ONLY=true** : notifie mais n'update PAS automatiquement -> pas de risque de rupture surprise sur les :latest.
+- **veille-frontend / dashboard-terrain / panda-dashboard** : frontends statiques stateless, 0 mount normal.
+
+## Methode / pieges d'analyse
+- restart policy au boot systeme : seuls `always` + `unless-stopped` remontent. `on-failure` et `no` = NON.
+- 0 mount /volume1 = etat ephemere au recreate SAUF si le service est stateless (frontend, sandbox, ou lit un backend externe comme Baserow).
+- Chercher les couplages casses : comparer les URL/ports en env de chaque service au registre reel des services vivants (rla-api etait le cas).