auto_clea

2025-09-25 15:25:14 +00:00 · 2025-09-25 15:25:14 +00:00 · c0b3bda6da
commit c0b3bda6da
parent be23ef77c0
71 changed files with 2377 additions and 258 deletions
--- a/IA_agents/prompts/prompt-tests.md
+++ b/IA_agents/prompts/prompt-tests.md
@ -0,0 +1,70 @@
+## Politique de tests (centralisés)
+
+### Objectifs
+- Centraliser tous les tests dans `4NK_env/tests/<projet>/`.
+- Garantir l’isolation (pas d’état partagé entre tests).
+- Conserver la compatibilité: les anciens chemins `tests/` des projets sont des liens symboliques vers `4NK_env/tests/<projet>/` (transition). À terme, référencer directement les chemins centralisés dans docs/CI.
+
+### Arborescence cible
+```
+4NK_env/
+└── tests/
+    ├── lecoffre_node/
+    ├── lecoffre-front/
+    ├── ihm_client/
+    ├── sdk_relay/
+    └── sdk_storage/
+```
+
+### Isolation et données
+- Chaque test doit isoler son stockage dans un répertoire unique: `/tmp/.4nk/<uuid>`.
+- Éviter toute dépendance à un état global ou à des fichiers hors du répertoire de test.
+- Ne jamais écrire dans `./data` des projets; préférer des répertoires temporaires par test.
+
+### Exemples d’exécution (projets)
+- lecoffre_node (scripts custom):
+```bash
+cd /home/debian/4NK_env/lecoffre_node
+# Exemples (si présents): ./scripts/test-monitoring.sh, ./scripts/test-dashboards.sh
+```
+
+- lecoffre-front (Next/Node):
+```bash
+cd /home/debian/4NK_env/lecoffre-front
+npm test
+```
+
+- ihm_client (Vite/Node):
+```bash
+cd /home/debian/4NK_env/ihm_client
+npm test
+```
+
+- sdk_relay / sdk_storage:
+```bash
+cd /home/debian/4NK_env/sdk_relay && cargo test || true
+cd /home/debian/4NK_env/sdk_storage && cargo test || true
+```
+
+### Bonnes pratiques
+- Tests hermétiques: créer/détruire ressources durant le test; pas de dépendance sur l’ordre d’exécution.
+- Logs: si des logs sont nécessaires, écrire vers `/home/debian/4NK_env/logs/tests/<projet>/`.
+- CI: ne pas utiliser de chemins relatifs aux anciens `tests/`; cibler `4NK_env/tests/<projet>/`.
+
+### Migration (transition → cible)
+1. Les dossiers `tests/` dans les projets pointent actuellement par symlink vers `4NK_env/tests/<projet>/`.
+2. Mettre à jour progressivement documentation, scripts, CI pour référencer directement les chemins centralisés.
+3. Supprimer les symlinks une fois la migration complète validée.
+
+### Vérifications
+- Pas de dépendances résiduelles aux anciens chemins `./tests` dans scripts/CI: rechercher `\b\./tests\b` et corriger si présent.
+- Pas d’écriture dans `./data` des projets par les tests; utilisation de `/tmp/.4nk/<uuid>`.
+
+### Commandes utiles
+```bash
+# Lister les suites de tests centralisées
+find /home/debian/4NK_env/tests -maxdepth 2 -type d
+
+# Rechercher références aux anciens chemins dans le repo
+grep -R "\b\./tests\b" /home/debian/4NK_env || true
+```
--- a/docs/ihm_client/ANALYSE.md
+++ b/docs/ihm_client/ANALYSE.md
@ -0,0 +1,39 @@
+## Analyse détaillée
+
+### Périmètre
+
+Client front (Vite) intégrant un package WASM pré‑construit `pkg/` et Nginx pour le dev.
+
+### Stack
+
+- **Outillage**: Vite 5, TypeScript 5
+- **WASM**: paquet `sdk_client` précompilé (copié dans `pkg/`)
+- **UI/Libs**: axios, QR, SweetAlert2, plugins Vite (React/Vue activables)
+- **Serveur**: Nginx en dev via `start-dev.sh`
+
+### Build et exécution
+
+- Scripts: `build_wasm`, `start` (Vite host 0.0.0.0), `build`, `deploy`.
+- Dockerfile: Node 20‑alpine, installe `git` et `nginx`, `npm install`, copie `nginx.dev.conf`, script de démarrage.
+
+### Ports
+
+- 3003 (exposition dev), 80 via Nginx.
+
+### Risques et points d’attention
+
+- Coexistence double serveur (Vite + Nginx) en dev: veiller au routage, CORS et proxys.
+- Paquet WASM précompilé: vérifier cohérence de version avec `sdk_client`.
+- Absence de tests automatiques; ajouter stratégie `tests/` (unit/integration).
+
+### Actions proposées
+
+- Documenter matrice compatibilité `pkg/` ↔ `sdk_client` (source, commit/tag, date).
+- Ajouter lints/tests en CI; unifier serveur dev (proxy Nginx vers Vite ou inverse).
+- Paramétrer variables d’env front (URLs relais, API) et fournir `.env.example`.
+
+
+
+
+
+
--- a/docs/ihm_client/ARCHITECTURE.md
+++ b/docs/ihm_client/ARCHITECTURE.md
@ -0,0 +1,21 @@
+# Architecture - IHM Client
+
+## Composants
+- Frontend embarqué en iframe dans `lecoffre-front`.
+
+## Dépendances
+- `sdk_relay` via `VITE_WS_URL`.
+- Backend `lecoffre-back-mini` via `VITE_API_BASE_URL`.(sur dev3.4nkweb.com)
+
+## Réseau et ports
+- Exposé derrière Nginx via `https://dev4.4nkweb.com/`.
+
+## Variables d’environnement (centralisées)
+- Chargement depuis `lecoffre_node/.env.master`.
+
+## Monitoring
+- Logs → Promtail → Loki → Grafana (Frontend Services).
+
+## Notes
+- Code splitting (`React.lazy`, `Suspense`).
+- Pas de `.env` local, configuration via Docker Compose.
--- a/docs/ihm_client/CORRECTIONS_APPLIQUEES.md
+++ b/docs/ihm_client/CORRECTIONS_APPLIQUEES.md
@ -0,0 +1,40 @@
+# Corrections Appliquées - IHM Client
+
+## Date: 20 Septembre 2025
+
+### 🔧 Corrections Majeures
+
+#### 1. Problème de Configuration WebSocket
+**Problème:** L'iframe était bloquée sur "Chargement de l'authentification..." car elle tentait de se connecter à une URL WebSocket inaccessible.
+
+**Solution:**
+- Correction de `VITE_BOOTSTRAPURL` pour pointer vers le bootstrap externe
+- Configuration des `RELAY_URLS` pour utiliser le relais local et externe
+- Mise à jour des variables d'environnement
+
+**Fichiers modifiés:**
+- `.env` - Configuration WebSocket corrigée
+- `docker-compose.yml` - Variables d'environnement mises à jour
+
+#### 2. Configuration des URLs
+**Variables d'environnement:**
+```env
+BOOTSTRAPURL=wss://dev3.4nkweb.com/ws/
+RELAY_URLS=ws://sdk_relay:8090,wss://dev3.4nkweb.com/ws/
+```
+
+#### 3. Installation des Outils
+**Ajouté dans le Dockerfile:**
+- `curl`, `git`, `wget`, `jq`, `telnet`, `npm`, `wscat`
+- Outils de diagnostic et de connectivité
+
+### 📊 État Actuel
+- **Statut:** ✅ Healthy
+- **Connectivité:** Bootstrap et relais configurés
+- **URLs:** Correctement mappées
+- **Logs:** Optimisés
+
+### 🔄 Prochaines Étapes
+- Tests de connectivité WebSocket
+- Monitoring des performances
+- Optimisations supplémentaires
--- a/docs/ihm_client/DEPLOIEMENT.md
+++ b/docs/ihm_client/DEPLOIEMENT.md
@ -0,0 +1,23 @@
+# Déploiement - IHM Client
+
+## Préparation
+- Branche `ext` sur tous les dépôts.
+- Variables dans `lecoffre_node/.env.master` (pas de `.env` local).
+- Ne pas utiliser `docker compose up -d`.
+
+## Déploiement (orchestrateur)
+```bash
+cd /home/debian/4NK_env/lecoffre_node
+./scripts/start.sh | cat
+./scripts/validate-deployment.sh | cat
+```
+
+## Vérifications
+- `https://dev4.4nkweb.com/` (iframe OK)
+- WS `wss://dev4.4nkweb.com/ws/`
+- `./scripts/monitor-progress.sh | cat`
+
+## Règles
+- Pousser sur `ext` sans déclencher de CI tant que non nécessaire.
+- Config centralisée uniquement.
+- Logs via Promtail → Loki → Grafana.
--- a/docs/ihm_client/FLUX.md
+++ b/docs/ihm_client/FLUX.md
@ -0,0 +1,10 @@
+# Description des Flux - IHM Client
+
+```mermaid
+documentation
+```
+
+## Flux principaux
+1. Auth notaire via front → IdNot → front → iframe IHM.
+2. IHM ↔ Signer (opérations signées).
+3. IHM ↔ Relay (WebSocket) pour évènements.
--- a/docs/ihm_client/FONCTIONNEL.md
+++ b/docs/ihm_client/FONCTIONNEL.md
@ -0,0 +1,17 @@
+# Description Fonctionnelle - IHM Client
+
+## Objectif
+Fournir l’interface d’interaction utilisateur (iframe) pour les flux métiers et les opérations liées aux clés Bitcoin (Silent Payment).
+
+## Parcours clés
+- Authentification via redirection IdNot (depuis `lecoffre-front`).
+- Échanges temps réel via `sdk_relay` (WebSocket).
+
+## Rôles
+- Notaire: initie les dossiers, suit l’état.
+- Client: accède aux dossiers, valide via SMS, téléverse des pièces.
+
+## Résultats attendus
+- Affichage fiable de l’iframe.
+- Opérations signées validées.
+- Erreurs affichées à l’utilisateur, logs collectés.
--- a/docs/ihm_client/INSTALLATION.md
+++ b/docs/ihm_client/INSTALLATION.md
@ -0,0 +1,35 @@
+# Installation - IHM Client
+
+## Prérequis
+- Accès au dépôt `4NK_env` (branche `ext`).
+- Docker/Compose installés.
+- Variables centralisées dans `lecoffre_node/.env.master`.
+
+## Récupération du code
+```bash
+cd /home/debian/4NK_env
+# Assure-toi d'être sur la branche ext dans tous les dépôts
+```
+
+## Configuration
+- Ne pas créer de `.env` local.
+- Renseigner/valider `VITE_*` dans `lecoffre_node/.env.master`.
+
+## Démarrage (via orchestrateur)
+- Lancer via `lecoffre_node` (recommandé) :
+```bash
+cd /home/debian/4NK_env/lecoffre_node
+./scripts/start.sh | cat
+```
+
+## Accès
+- `https://dev4.4nkweb.com/` (intégré via Nginx).
+
+## Vérifications
+- Page statut: `https://dev4.4nkweb.com/status/`
+- WebSocket: `wss://dev4.4nkweb.com/ws/`
+- Logs Grafana.
+
+## Notes
+- Brancher IHM via iframe dans `lecoffre-front`.
+- Ne pas déclencher de CI depuis ce dépôt; builds images depuis pipelines tag `ext` si nécessaire.
--- a/docs/ihm_client/QUALITE.md
+++ b/docs/ihm_client/QUALITE.md
@ -0,0 +1,6 @@
+# Qualité Logicielle - IHM Client
+
+- Lint/format: respecter config projet.
+- Tests: ajouter vérifs WS et intégration iframe.
+- Performance: code splitting et lazy loading.
+- Observabilité: logs structurés, erreurs gérées.
--- a/docs/ihm_client/SECURITE.md
+++ b/docs/ihm_client/SECURITE.md
@ -0,0 +1,6 @@
+# Sécurité - IHM Client
+
+- Pas de secrets dans le code/dépôt.
+- Variables via `.env.master` uniquement.
+- CSP/headers via Nginx.
+- WS sécurisé via `wss://`.
--- a/docs/ihm_client/TECHNIQUE.md
+++ b/docs/ihm_client/TECHNIQUE.md
@ -0,0 +1,22 @@
+# Description Technique - IHM Client
+
+## Tech stack
+- Node.js 20, Vite/React.
+- Code splitting (`React.lazy`, `Suspense`).
+
+## Configuration
+- Variables `VITE_*` via `lecoffre_node/.env.master`.
+- Aucune lecture de `.env` local.
+
+## Interfaces
+- WebSocket `VITE_WS_URL` (relay).
+- REST `VITE_API_BASE_URL` (backend).
+- `VITE_SIGNER_URL` (signer).
+
+## Sécurité
+- Aucune clé en dépôt.
+- Headers sécurisés via Nginx.
+
+## Observabilité
+- Logs Promtail → Loki.
+- Dashboards Grafana.
--- a/docs/ihm_client/TODO.md
+++ b/docs/ihm_client/TODO.md
@ -0,0 +1,6 @@
+# TODO - IHM Client
+
+- Vérifier intégration iframe avec `lecoffre-front`.
+- Tester WS `wss://dev4.4nkweb.com/ws/`.
+- Vérifier configuration `VITE_*` via `.env.master`.
+- Ajouter dashboards Grafana si manquants.
--- a/docs/ihm_client/WEBSOCKET_CONNECTION.md
+++ b/docs/ihm_client/WEBSOCKET_CONNECTION.md
@ -0,0 +1,124 @@
+# Connexion WebSocket - ihm_client
+
+## Architecture de l'iframe
+
+### Structure de fonctionnement
+L'iframe `ihm_client` suit une architecture modulaire :
+
+1. **Initialisation** (`router.ts`) :
+   - `init()` initialise les services
+   - `Services.getInstance()` crée l'instance singleton
+   - `connectAllRelays()` établit les connexions WebSocket
+
+2. **Services** (`services/service.ts`) :
+   - Gestion des connexions WebSocket
+   - Communication avec les relays
+   - Gestion des messages et handshakes
+
+3. **WebSocket** (`websockets.ts`) :
+   - API WebSocket native
+   - Gestion des événements (open, message, error, close)
+
+## Configuration WebSocket
+
+### Variables d'environnement
+```bash
+VITE_BOOTSTRAPURL=wss://dev4.4nkweb.com/ws/
+RELAY_URLS=wss://dev4.4nkweb.com/ws/,wss://dev3.4nkweb.com/ws/
+```
+
+### Connexion aux relays
+```typescript
+// Dans service.ts
+const BOOTSTRAPURL = [import.meta.env.VITE_BOOTSTRAPURL || `wss://${BASEURL}/ws/`];
+
+// Connexion à tous les relays
+await services.connectAllRelays();
+```
+
+## Gestion des messages
+
+### Handshake
+```typescript
+public async handleHandshakeMsg(url: string, parsedMsg: any) {
+  const handshakeMsg: HandshakeMessage = JSON.parse(parsedMsg);
+  this.updateRelay(url, handshakeMsg.sp_address);
+  this.currentBlockHeight = handshakeMsg.chain_tip;
+}
+```
+
+### Mise à jour des adresses relay
+```typescript
+public updateRelay(wsurl: string, spAddress: string): void {
+  this.relayAddresses[wsurl] = spAddress;
+  console.log(`Updated: ${wsurl} -> ${spAddress}`);
+}
+```
+
+## Communication avec le parent
+
+### Écoute des messages
+```typescript
+// Dans router.ts
+if (window.self !== window.top) {
+  // L'iframe écoute les messages du parent
+  window.addEventListener('message', handleMessage);
+}
+```
+
+### Gestion des erreurs
+```typescript
+// Détection des fonds insuffisants
+if (insufficientFunds) {
+  await this.triggerAutomaticFundsTransfer();
+}
+```
+
+## Problèmes résolus
+
+### 1. Configuration WebSocket incorrecte
+**Problème :** L'iframe utilisait `ws://sdk_relay:8090/` au lieu de `wss://dev4.4nkweb.com/ws/`.
+
+**Solution :** Correction des variables d'environnement et redémarrage du container.
+
+### 2. Mixed Content errors
+**Problème :** Tentative de connexion WS depuis une page HTTPS.
+
+**Solution :** Utilisation de WSS (WebSocket Secure) pour toutes les connexions.
+
+### 3. Headers WebSocket manquants
+**Problème :** Nginx ne transmettait pas les headers WebSocket.
+
+**Solution :** Configuration Nginx avec headers WebSocket explicites.
+
+## Problème persistant
+
+### 502 Bad Gateway
+**Statut :** ⚠️ Problème persistant
+- L'iframe reçoit 502 Bad Gateway lors de la connexion WebSocket
+- Nginx ne transmet pas les headers WebSocket vers le relay
+- Le relay rejette les connexions sans headers
+
+**Investigation :** La configuration Nginx semble correcte mais les headers ne sont pas transmis.
+
+## Tests
+
+### Test de connexion WebSocket
+```bash
+# Depuis l'iframe
+wget -O- https://dev4.4nkweb.com/ws/
+```
+
+**Résultat actuel :** 502 Bad Gateway
+
+### Test avec headers WebSocket
+```bash
+curl -v -H "Upgrade: websocket" \
+     -H "Connection: upgrade" \
+     -H "Sec-WebSocket-Version: 13" \
+     -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
+     https://dev4.4nkweb.com/ws/
+```
+
+## Date de mise à jour
+2025-01-20 - Architecture de l'iframe analysée et problèmes de connexion WebSocket identifiés
--- a/docs/ihm_client/analyse.md
+++ b/docs/ihm_client/analyse.md
@ -0,0 +1,31 @@
+### Objet
+Analyse synthétique de `ihm_client` (iframe chargée par `lecoffre-front`).
+
+### Stack et build
+- **Outil**: Vite
+- **Langage**: TypeScript + HTML templates
+- **Cible**: `index.html` + `src/main.ts` (SPA montée en iframe)
+- **Serveur dev**: `nginx.dev.conf` et script `start-dev.sh`
+
+### Arborescence notable
+- `src/components`: header, modales (confirmation/creation/waiting), login-modal, qrcode-scanner
+- `src/pages`: home, chat, account, process, signature (+ variantes)
+- `src/services`: database, storage, token, modal, service générique
+- `src/utils`: documents, HTML helpers, notifications store, subscriptions utils
+- `src/websockets.ts`: temps-réel côté iframe
+
+### Intégrations et communication
+- **Token/Session**: `src/services/token.ts`
+- **Stockage**: `src/services/storage.service.ts`
+- **Base de données**: `src/services/database.service.ts` (cache/worker)
+- **Workers**: `service-workers/` (cache/database)
+- **Échanges avec parent**: via postMessage (cf. utils/services) et WebSockets
+
+### Points d’attention
+- Sécurité iframe (sandbox, `postMessage` sécurisé par origine)
+- Gestion des tokens (renouvellement, stockage, effacement)
+- Cohérence de version avec `lecoffre-front` (API bus/messages)
+
+### Déploiement
+- **Dockerfile**: fourni
+- **Nginx**: `nginx.dev.conf` pour dev local
--- a/docs/lecoffre-front/ARCHITECTURE.md
+++ b/docs/lecoffre-front/ARCHITECTURE.md
@ -0,0 +1,21 @@
+# Architecture - LeCoffre Front
+
+## Composants
+- Next.js (branche `ext`).
+- Intègre `ihm_client` via iframe.
+
+## Dépendances
+- Redirections IdNot (dev3.4nkweb.com).
+
+## Réseau et ports
+- Servi via Nginx: `https://dev4.4nkweb.com/lecoffre/`.
+
+## Variables d’environnement (centralisées)
+- `NEXT_PUBLIC_*` depuis `lecoffre_node/.env.master`.
+
+## Monitoring
+- Logs Promtail → Loki.
+- Dashboard Grafana: Frontend Services.
+
+## Notes
+- Pas de `.env` local, utilisation variables runtime.
--- a/docs/lecoffre-front/CORRECTIONS_APPLIQUEES.md
+++ b/docs/lecoffre-front/CORRECTIONS_APPLIQUEES.md
@ -0,0 +1,38 @@
+# Corrections Appliquées - LeCoffre Front
+
+## Date: 20 Septembre 2025
+
+### 🔧 Corrections Majeures
+
+#### 1. Problème de Healthcheck
+**Problème:** Le healthcheck échouait car `curl` n'était pas installé et Next.js écoutait sur l'IP du conteneur.
+
+**Solution:**
+- Changement du healthcheck pour vérifier le processus `next-server`
+- Healthcheck: `ps aux | grep -v grep | grep next-server`
+- Correction de l'entrypoint pour `npm start`
+
+**Fichiers modifiés:**
+- `docker-compose.yml` - Healthcheck corrigé
+- Configuration - Entrypoint optimisé
+
+#### 2. Installation des Outils
+**Ajouté dans le Dockerfile:**
+- `curl`, `git`, `wget`, `jq`, `telnet`, `npm`, `wscat`
+- Outils de diagnostic et de connectivité
+
+#### 3. Configuration Next.js
+- Port: 3000 (mappé sur 3004)
+- Processus: `next-server`
+- Healthcheck: Vérification du processus
+
+### 📊 État Actuel
+- **Statut:** ✅ Healthy
+- **Processus:** next-server en cours d'exécution
+- **Port:** 3000 accessible sur 172.20.0.11
+- **URL:** https://dev4.4nkweb.com/lecoffre
+
+### 🔄 Prochaines Étapes
+- Tests de connectivité frontend
+- Monitoring des performances
+- Optimisations supplémentaires
--- a/docs/lecoffre-front/DEPLOIEMENT.md
+++ b/docs/lecoffre-front/DEPLOIEMENT.md
@ -0,0 +1,20 @@
+# Déploiement - LeCoffre Front
+
+## Préparation
+- Branche `ext`.
+- `NEXT_PUBLIC_*` dans `lecoffre_node/.env.master`.
+
+## Déploiement (orchestrateur)
+```bash
+cd /home/debian/4NK_env/lecoffre_node
+./scripts/start.sh | cat
+./scripts/validate-deployment.sh | cat
+```
+
+## Vérifications
+- `https://dev4.4nkweb.com/lecoffre/` s'affiche.
+- Iframe `ihm_client` s'ouvre.
+
+## Règles
+- Pas de compose direct.
+- Push `ext` sans CI pour docs.
--- a/docs/lecoffre-front/DEPLOYMENT_FIXES_2025-09-24.md
+++ b/docs/lecoffre-front/DEPLOYMENT_FIXES_2025-09-24.md
@ -0,0 +1,81 @@
+# Corrections de déploiement - 24 septembre 2025
+
+## Problèmes résolus
+
+### 1. Configuration Next.js conditionnelle
+- **Problème**: `output: 'export'` et `basePath` appliqués en dev bloquaient HMR
+- **Solution**: Configuration conditionnelle dans `next.config.js`
+  ```js
+  const isProd = process.env.NODE_ENV === 'production';
+  const nextConfig = {
+    ...(isProd ? {
+      output: 'export',
+      basePath: '/lecoffre',
+      assetPrefix: '/lecoffre',
+      trailingSlash: true,
+      images: { unoptimized: true }
+    } : {})
+  };
+  ```
+
+### 2. Nginx - Redirection et proxy
+- **Problème**: `/lecoffre/` retournait 404 car l'image CI ne respectait pas `basePath`
+- **Solution**: Rewrite Nginx dans `location ^~ /lecoffre/`
+  ```nginx
+  rewrite ^/lecoffre/(.*)$ /$1 break;
+  proxy_pass http://localhost:3004;
+  ```
+
+### 3. Assets Next.js manquants
+- **Problème**: `/_next/static/` retournait 404 (assets non servis)
+- **Solution**: Route Nginx dédiée
+  ```nginx
+  location ^~ /_next/ {
+      proxy_pass http://localhost:3004/_next/;
+      add_header Cache-Control "public, max-age=31536000, immutable";
+  }
+  ```
+
+### 4. HMR en développement
+- **Problème**: Besoin d'HMR sans impacter la prod
+- **Solution**: Route dédiée `/lecoffre-hmr/` avec WebSocket support
+  ```nginx
+  location ^~ /lecoffre-hmr/ {
+      proxy_http_version 1.1;
+      proxy_set_header Upgrade $http_upgrade;
+      proxy_set_header Connection "upgrade";
+      rewrite ^/lecoffre-hmr/(.*)$ /$1 break;
+      proxy_pass http://localhost:3000;
+  }
+  ```
+
+## Architecture finale
+
+### Production
+- `https://dev4.4nkweb.com/` → ihm_client (iframe)
+- `https://dev4.4nkweb.com/lecoffre/` → lecoffre-front (app principale)
+- `https://dev4.4nkweb.com/_next/` → assets Next.js
+
+### Développement (HMR)
+- `https://dev4.4nkweb.com/lecoffre-hmr/` → Next.js dev server (port 3000)
+
+### Flux IdNot
+- CORS dev3 configuré pour `https://dev4.4nkweb.com`
+- State management via `/api/v1/idnot/state` sur dev3
+- Callback vers `/authorized-client` (prod ou HMR)
+
+## Variables d'environnement
+- `NEXT_PUBLIC_*` cohérentes entre build CI et runtime
+- `NODE_ENV=production` pour activer basePath/export
+- CORS dynamique pour dev4.4nkweb.com
+
+## Tests validés
+- ✅ Redirection 301: `/lecoffre` → `/lecoffre/`
+- ✅ Page d'accueil: `/lecoffre/` → 200
+- ✅ Assets: `/_next/static/` → 200
+- ✅ HMR: `/lecoffre-hmr/` → 200
+- ✅ CORS dev3: OPTIONS 204 + POST state 200
+- ✅ ihm_client: `/` → 200
+
+
+
--- a/docs/lecoffre-front/ENV-RESUME.md
+++ b/docs/lecoffre-front/ENV-RESUME.md
@ -0,0 +1,30 @@
+## Résumé des environnements (front)
+
+### Contexte
+
+- **Hôte iframe**: `https://dev4.4nkweb.com`
+- **Site principal**: `https://dev4.4nkweb.com/lecoffre` (Next.js `basePath: '/lecoffre'`)
+- **Signer utilisé**: `https://dev3.4nkweb.com`
+
+### Variables `NEXT_PUBLIC_*` à aligner
+
+- `NEXT_PUBLIC_4NK_URL=https://dev4.4nkweb.com`
+- `NEXT_PUBLIC_4NK_IFRAME_URL=https://dev4.4nkweb.com`
+- `NEXT_PUBLIC_API_URL` → URL publique de l’API back (chemin stable, CORS OK)
+- `NEXT_PUBLIC_BACK_API_PROTOCOL=https`
+- `NEXT_PUBLIC_BACK_API_HOST=dev4.4nkweb.com`
+- `NEXT_PUBLIC_BACK_API_PORT` (vide en prod 443)
+- `NEXT_PUBLIC_BACK_API_ROOT_URL` et `NEXT_PUBLIC_BACK_API_VERSION` si composées côté front
+- `NEXT_PUBLIC_IDNOT_*`, `NEXT_PUBLIC_DOCAPOSTE_API_URL` selon intégrations
+- `NEXT_PUBLIC_DEFAULT_VALIDATOR_ID`, `NEXT_PUBLIC_DEFAULT_STORAGE_URLS` selon besoins
+
+### Points d’attention
+
+- Vérifier que toutes les URLs tiennent compte du `basePath` `/lecoffre`.
+- Le service de signature est externalisé sur `dev3.4nkweb.com`.
+
+
+
+
+
+
--- a/docs/lecoffre-front/FLUX.md
+++ b/docs/lecoffre-front/FLUX.md
@ -0,0 +1,6 @@
+# Description des Flux - LeCoffre Front
+
+## Flux principaux
+1. Auth notaire: Front → IdNot → Front (callback).
+2. Intégration IHM: Front → iframe → IHM.
+3. API: Front → Back (REST).
--- a/docs/lecoffre-front/FONCTIONNEL.md
+++ b/docs/lecoffre-front/FONCTIONNEL.md
@ -0,0 +1,15 @@
+# Description Fonctionnelle - LeCoffre Front
+
+## Objectif
+Fournir l’interface principale (Next.js) orchestrant l’UX, incluant l’iframe IHM Client.
+
+## Parcours clés
+- Authentification notaire (redirections IdNot).
+- Navigation dossiers et intégration iframe IHM.
+- Appels API backend, feedback utilisateur et gestion d’erreurs.
+
+## Rôles
+- Notaire, utilisateur interne.
+
+## Résultats attendus
+- UX fluide, chargements différés (code splitting), gestion session robuste.
--- a/docs/lecoffre-front/HMR_IDNOT_STATE.md
+++ b/docs/lecoffre-front/HMR_IDNOT_STATE.md
@ -0,0 +1,43 @@
+HMR + IdNot + dev3 via state (mise à jour: 2025-09-24)
+
+Vue d’ensemble
+
+- HMR (Hot Module Replacement)
+  - En local, Next.js sert le HMR (ex: port 3000) et recharge les modules sans redémarrage.
+  - Les appels API sont effectués en same-origin via le proxy Nginx/compose: le front cible `/api/...`, Nginx route vers dev3. Pas de CORS ni reconfig lors des reloads.
+  - En dev4/prod, pas de HMR: `next start` sert l’app buildée sous `/lecoffre/`.
+
+- Émission du state (dev3)
+  - Front → `POST /api/v1/idnot/state` (same-origin `/api`). Nginx (dev4) relaie vers `https://dev3.4nkweb.com/api/v1/idnot/state`.
+  - Body: `{ "next_url": "https://dev4.4nkweb.com/lecoffre/authorized-client" }`.
+  - Réponse: `{ "state": "<state_signé>" }`. CORS dynamique côté Nginx (dev3) autorise l’origine dev4.
+
+- Redirection IdNot avec state
+  - URL d’autorisation:
+    - base = `NEXT_PUBLIC_IDNOT_BASE_URL + NEXT_PUBLIC_IDNOT_AUTHORIZE_ENDPOINT`
+    - `client_id = NEXT_PUBLIC_IDNOT_CLIENT_ID`
+    - `redirect_uri = NEXT_PUBLIC_IDNOT_REDIRECT_URI_FIXED` (stable)
+    - `scope = openid,profile`, `response_type = code`
+    - `state = <state_signé>` (depuis l’API state dev3)
+  - IdNot renvoie `code` (et le `state` validé côté backend) vers dev3, qui enchaîne selon `next_url`.
+
+- Pourquoi ça marche bien avec HMR
+  - Le front n’appelle pas dev3 directement depuis le navigateur: toujours `/api` (reverse-proxy Nginx).
+  - Nginx masque les headers CORS upstream et réinjecte des headers valides dynamiquement (Origin dev4/local).
+  - Le `state` est demandé via `/api`, donc indépendant du HMR.
+  - Les `NEXT_PUBLIC_*` pilotent IdNot et `next_url`; endpoints de debug: `/api/env` et `/env`.
+
+- Canonicalisation URL
+  - Canonical sous-sous-chemin: `/lecoffre/`.
+  - Next: `basePath: '/lecoffre'`, `assetPrefix: '/lecoffre'`, `trailingSlash: true`.
+  - Nginx (dev4): rediriger `/lecoffre` → `/lecoffre/`; proxy `^~ /lecoffre/` vers `http://localhost:3004`.
+
+- Validation (script `scripts/deploy_front_ext.sh`)
+  - Vérifie: variables `NEXT_PUBLIC_*` (conteneur vs `.env.master`).
+  - CORS dev3: OPTIONS 204 + en-têtes (A-C-A-Origin = dev4).
+  - `POST /api/v1/idnot/state`: 200 + `state` présent.
+  - Checks publics: `/lecoffre` = 301 → `/lecoffre/`, `/lecoffre/` = 200.
+
+
+
+
--- a/docs/lecoffre-front/INSTALLATION.md
+++ b/docs/lecoffre-front/INSTALLATION.md
@ -0,0 +1,26 @@
+# Installation - LeCoffre Front
+
+## Prérequis
+- Dépôts sous `/home/debian/4NK_env` (branche `ext`).
+- Docker/Compose.
+- Variables `NEXT_PUBLIC_*` dans `lecoffre_node/.env.master`.
+
+## Configuration
+- Pas de `.env` local.
+- Vérifier URLs backend et iframe IHM.
+
+## Démarrage (orchestrateur)
+```bash
+cd /home/debian/4NK_env/lecoffre_node
+./scripts/start.sh | cat
+```
+
+## Accès
+- `https://dev4.4nkweb.com/lecoffre/`
+
+## Vérifications
+- Ouverture iframe IHM.
+- Appels API vers `/api/` OK.
+
+## Notes
+- CI via tag `ext`.
--- a/docs/lecoffre-front/PORTS.md
+++ b/docs/lecoffre-front/PORTS.md
@ -0,0 +1,27 @@
+Ports et usages (mise à jour: 2025-09-24)
+
+Contexte: déploiement sur dev4 avec Nginx en frontal, lecoffre-front en Docker.
+
+- 80 (TCP) — Nginx HTTP (host)
+- 443 (TCP) — Nginx HTTPS (host)
+
+- 3004 (TCP) — docker-proxy → lecoffre-front:8080 (port public du front via Docker)
+  - Interne conteneur: 8080 (Next.js `next start`)
+
+- 3005 (TCP) — docker-proxy → Grafana:3000
+- 3006 (TCP) — docker-proxy → status-api:3006
+- 3100 (TCP) — docker-proxy → Loki:3100
+- 8000 (TCP) — docker-proxy → blindbit-oracle:8000
+- 8081 (TCP) — docker-proxy → sdk_storage:8080
+
+Ports désactivés/libérés
+
+- 3000 (TCP) — vhost local Nginx `local.4nkweb.com-3000` désactivé
+- 7777/7778 (TCP) — anciens processus Node arrêtés
+- 8080 (TCP host) — ancien Node local arrêté (ne pas confondre avec 8080 interne du conteneur front)
+
+Notes
+
+- Canonical front sous sous-chemin: `/lecoffre/`
+- Next.js: `basePath: '/lecoffre'`, `assetPrefix: '/lecoffre'`, `trailingSlash: true`
+- Nginx: rediriger `/lecoffre` → `/lecoffre/`, et proxy sur `^~ /lecoffre/` vers `http://localhost:3004`
--- a/docs/lecoffre-front/QUALITE.md
+++ b/docs/lecoffre-front/QUALITE.md
@ -0,0 +1,6 @@
+# Qualité Logicielle - LeCoffre Front
+
+- Lint/format: respecter règles Next/TS.
+- Tests: E2E parcours IdNot et iframe IHM.
+- Performance: audit Lighthouse, lazy loading.
+- Observabilité: logs client minimaux, erreurs capturées.
--- a/docs/lecoffre-front/RESUME-ANALYSE.md
+++ b/docs/lecoffre-front/RESUME-ANALYSE.md
@ -0,0 +1,159 @@
+# Résumé de l'Analyse - lecoffre-front
+
+## Vue d'ensemble
+
+L'analyse complète du repository **lecoffre-front** a été effectuée le $(date). Ce document présente un résumé des principales découvertes et recommandations.
+
+## Structure du projet
+
+### Type d'application
+- **Framework**: Next.js 14.2.3 avec TypeScript 4.9.5
+- **Architecture**: Application frontend SPA avec intégrations multiples
+- **Déploiement**: Docker multi-stage + Kubernetes
+- **Version actuelle**: v0.1.6 (package.json) / v2.5.1 (frontend)
+
+### Architecture technique
+```
+Frontend (Next.js) → API Backend → Services externes
+     ↓                    ↓              ↓
+  Material-UI         Base de données  4NK/IDNot/Docaposte
+```
+
+## Variables d'environnement
+
+### Configuration identifiée
+- **21 variables d'environnement** configurées
+- **4 environnements** supportés (dev/staging/preprod/production)
+- **Gestion centralisée** via Next.js config et FrontendVariables
+
+### Variables critiques
+```bash
+# API Backend
+NEXT_PUBLIC_BACK_API_PROTOCOL=https://
+NEXT_PUBLIC_BACK_API_HOST=api.example.com
+NEXT_PUBLIC_BACK_API_PORT=443
+
+# Intégrations
+NEXT_PUBLIC_4NK_URL=https://dev4.4nkweb.com
+NEXT_PUBLIC_IDNOT_BASE_URL=https://idnot.example.com
+NEXT_PUBLIC_DOCAPOSTE_API_URL=https://api.docaposte.com
+```
+
+## Déploiement et infrastructure
+
+### Docker
+- **Multi-stage build** avec 4 cibles (deps/development/builder/ext)
+- **Sécurité**: Utilisateur non-root, support SSH agent
+- **Optimisation**: Cache npm, build standalone Next.js
+
+### Kubernetes
+- **Namespace**: lecoffre
+- **Ressources**: 1Gi RAM (request) / 2Gi RAM (limit)
+- **Sécurité**: Vault Agent pour injection des secrets
+- **Ingress**: TLS avec cert-manager
+
+### CI/CD
+- **Registre**: git.4nkweb.com (Docker registry)
+- **Tagging**: Contrôlé par message de commit
+- **Secrets**: Gestion via Vault + External Secrets
+
+## Dépendances
+
+### État général
+- **46 dépendances** principales
+- **5 dépendances** de développement
+- **Statut**: Majoritairement à jour et sécurisées
+
+### Recommandations
+- ✅ **Maintenir**: Next.js 14.2.3, React 18.2.0, MUI 5.11.13
+- ⚠️ **Mettre à jour**: TypeScript 4.9.5 → 5.x
+- ✅ **Sécurisé**: Toutes les autres dépendances
+
+## Points forts identifiés
+
+### Architecture
+- ✅ Structure modulaire bien organisée
+- ✅ Séparation claire des responsabilités
+- ✅ Configuration multi-environnement
+- ✅ Intégration Docker/Kubernetes robuste
+
+### Sécurité
+- ✅ Variables d'environnement externalisées
+- ✅ Gestion des secrets via Vault
+- ✅ Utilisateur non-root dans Docker
+- ✅ Support SSH agent pour dépendances privées
+
+### Développement
+- ✅ TypeScript pour le typage statique
+- ✅ ESLint + Prettier pour la qualité du code
+- ✅ Tests organisés dans le dossier tests/
+- ✅ Documentation complète
+
+## Points d'attention
+
+### Améliorations recommandées
+
+1. **TypeScript**
+   - Mettre à jour vers la version 5.x
+   - Bénéficier des dernières fonctionnalités
+
+2. **Monitoring**
+   - Ajouter des métriques de performance
+   - Monitoring des erreurs en production
+
+3. **Tests**
+   - Étendre la couverture de tests
+   - Tests d'intégration avec les services externes
+
+4. **Documentation**
+   - Maintenir la documentation des variables d'environnement
+   - Documenter les processus de déploiement
+
+### Risques identifiés
+
+1. **Dépendances privées**
+   - Dépendance à git.4nkweb.com pour le-coffre-resources
+   - Nécessite un accès SSH configuré
+
+2. **Variables d'environnement**
+   - Variables NEXT_PUBLIC_* exposées côté client
+   - Nécessite une validation stricte des valeurs
+
+3. **Intégrations externes**
+   - Dépendance à plusieurs services externes
+   - Nécessite une gestion des pannes
+
+## Recommandations prioritaires
+
+### Court terme (1-2 semaines)
+1. Mettre à jour TypeScript vers la version 5.x
+2. Effectuer un audit de sécurité complet (`npm audit`)
+3. Vérifier la configuration des variables d'environnement
+
+### Moyen terme (1-2 mois)
+1. Étendre la couverture de tests
+2. Ajouter des métriques de monitoring
+3. Documenter les processus de déploiement
+
+### Long terme (3-6 mois)
+1. Évaluer l'optimisation des performances
+2. Considérer l'ajout de tests d'intégration
+3. Planifier les mises à jour des dépendances
+
+## Conclusion
+
+Le projet **lecoffre-front** présente une architecture solide et bien structurée. Les technologies utilisées sont modernes et appropriées pour le contexte. La configuration Docker/Kubernetes est robuste et sécurisée.
+
+Les principales améliorations concernent la mise à jour de TypeScript et l'extension des tests. Le projet est globalement en bon état et prêt pour la production.
+
+## Documentation créée
+
+1. **ANALYSE-REPOSITORY.md**: Analyse complète du repository
+2. **VARIABLES-ENVIRONNEMENT.md**: Documentation détaillée des variables d'environnement
+3. **ANALYSE-DEPENDANCES.md**: Analyse des dépendances et recommandations
+4. **RESUME-ANALYSE.md**: Ce résumé exécutif
+
+---
+
+*Analyse effectuée le $(date) - Repository lecoffre-front*
+*Analyste: Assistant IA Claude*
--- a/docs/lecoffre-front/SECURITE.md
+++ b/docs/lecoffre-front/SECURITE.md
@ -0,0 +1,6 @@
+# Sécurité - LeCoffre Front
+
+- Aucune donnée sensible côté client.
+- Variables exposées en `NEXT_PUBLIC_*` contrôlées.
+- CSP/headers via Nginx.
+- Sanitation des entrées utilisateur.
--- a/docs/lecoffre-front/TECHNIQUE.md
+++ b/docs/lecoffre-front/TECHNIQUE.md
@ -0,0 +1,19 @@
+# Description Technique - LeCoffre Front
+
+## Tech stack
+- Next.js, Node.js 19.
+
+## Configuration
+- Variables `NEXT_PUBLIC_*` via `lecoffre_node/.env.master`.
+
+## Interfaces
+- Iframe vers `ihm_client`.
+- REST vers `/api/`.
+
+## Sécurité
+- Aucun secret côté client.
+- Headers via Nginx.
+
+## Observabilité
+- Logs Promtail → Loki.
+- Dashboards Grafana.
--- a/docs/lecoffre-front/TODO.md
+++ b/docs/lecoffre-front/TODO.md
@ -0,0 +1,6 @@
+# TODO - LeCoffre Front
+
+- Vérifier URLs backend et iframe IHM.
+- Tester parcours IdNot.
+- Valider variables `NEXT_PUBLIC_*`.
+- Vérifier dashboards Grafana Frontend.
--- a/docs/lecoffre-front/VARIABLES-ENVIRONNEMENT.md
+++ b/docs/lecoffre-front/VARIABLES-ENVIRONNEMENT.md
@ -0,0 +1,336 @@
+# Variables d'Environnement - lecoffre-front
+
+## Vue d'ensemble
+
+Ce document détaille toutes les variables d'environnement utilisées dans l'application lecoffre-front, leur utilisation et leur configuration.
+
+## Variables d'environnement supportées
+
+### 1. Configuration API Backend
+
+#### `NEXT_PUBLIC_BACK_API_PROTOCOL`
+- **Description**: Protocole utilisé pour communiquer avec l'API backend
+- **Valeurs possibles**: `https://`, `http://`
+- **Exemple**: `https://`
+- **Utilisation**: Construction des URLs d'API
+
+#### `NEXT_PUBLIC_BACK_API_HOST`
+- **Description**: Nom d'hôte de l'API backend
+- **Exemple**: `api.lecoffre.com`, `dev4.4nkweb.com`
+- **Utilisation**: Construction des URLs d'API
+
+#### `NEXT_PUBLIC_BACK_API_PORT`
+- **Description**: Port de l'API backend
+- **Exemple**: `443`, `8080`, `3001`
+- **Utilisation**: Construction des URLs d'API
+- **Note**: Peut être vide pour les ports par défaut (80/443)
+
+#### `NEXT_PUBLIC_BACK_API_ROOT_URL`
+- **Description**: Chemin racine de l'API
+- **Exemple**: `/api`, `/`
+- **Utilisation**: Construction des URLs d'API
+
+#### `NEXT_PUBLIC_BACK_API_VERSION`
+- **Description**: Version de l'API
+- **Exemple**: `v1`, `v2`
+- **Utilisation**: Construction des URLs d'API
+
+### 2. Configuration Frontend
+
+#### `NEXT_PUBLIC_FRONT_APP_HOST`
+- **Description**: URL de base de l'application frontend
+- **Exemple**: `https://app.lecoffre.com`
+- **Utilisation**: Redirections et liens internes
+
+#### `NEXT_PUBLIC_FRONT_APP_PORT`
+- **Description**: Port de l'application frontend
+- **Exemple**: `443`, `3000`
+- **Utilisation**: Construction des URLs frontend
+
+### 3. Intégration IDNot (Authentification)
+
+#### `NEXT_PUBLIC_IDNOT_AUTHORIZE_ENDPOINT`
+- **Description**: Point d'entrée pour l'autorisation OAuth
+- **Exemple**: `/oauth/authorize`
+- **Utilisation**: Flux d'authentification
+
+#### `NEXT_PUBLIC_IDNOT_CLIENT_ID`
+- **Description**: Identifiant client OAuth
+- **Exemple**: `lecoffre-client-id`
+- **Utilisation**: Authentification OAuth
+
+#### `NEXT_PUBLIC_IDNOT_BASE_URL`
+- **Description**: URL de base du service IDNot
+- **Exemple**: `https://idnot.lecoffre.com`
+- **Utilisation**: Authentification OAuth
+
+#### `NEXT_PUBLIC_IDNOT_REDIRECT_URI`
+- **Description**: URI de redirection après authentification
+- **Exemple**: `https://app.lecoffre.com/callback`
+- **Utilisation**: Flux d'authentification
+
+### 4. Intégration Docaposte
+
+#### `NEXT_PUBLIC_DOCAPOSTE_API_URL`
+- **Description**: URL de l'API Docaposte
+- **Exemple**: `https://api.docaposte.com`
+- **Utilisation**: Services postaux
+
+### 5. Intégration 4NK (Blockchain)
+
+#### `NEXT_PUBLIC_4NK_URL`
+- **Description**: URL de base des services 4NK
+- **Exemple**: `https://dev4.4nkweb.com`
+- **Utilisation**: Services blockchain et signature
+
+#### `NEXT_PUBLIC_4NK_IFRAME_URL`
+- **Description**: URL spécifique pour l'iframe 4NK
+- **Exemple**: `https://dev4.4nkweb.com`
+- **Utilisation**: Communication iframe
+- **Note**: Peut être différente de `NEXT_PUBLIC_4NK_URL`
+
+### 6. Analytics et Monitoring
+
+#### `NEXT_PUBLIC_HOTJAR_SITE_ID`
+- **Description**: Identifiant du site Hotjar
+- **Exemple**: `123456`
+- **Utilisation**: Analytics et heatmaps
+
+#### `NEXT_PUBLIC_HOTJAR_VERSION`
+- **Description**: Version de Hotjar
+- **Exemple**: `6`
+- **Utilisation**: Analytics et heatmaps
+
+### 7. Configuration système
+
+#### `NEXT_PUBLIC_API_URL`
+- **Description**: URL générique de l'API
+- **Exemple**: `https://api.lecoffre.com`
+- **Utilisation**: Appels API génériques
+
+#### `NEXT_PUBLIC_DEFAULT_VALIDATOR_ID`
+- **Description**: Identifiant du validateur par défaut
+- **Exemple**: `862406317a35064537ac959cb5d8bbdf4f849283b63db3ffa9904de2b3427c43:0`
+- **Utilisation**: Validation des entités système
+- **Valeur par défaut**: Définie dans `AppConstants.ts`
+
+#### `NEXT_PUBLIC_DEFAULT_STORAGE_URLS`
+- **Description**: URLs de stockage par défaut (séparées par des virgules)
+- **Exemple**: `https://dev3.4nkweb.com/storage,https://backup.4nkweb.com/storage`
+- **Utilisation**: Stockage des données
+- **Valeur par défaut**: `https://dev3.4nkweb.com/storage`
+
+### 8. Variables d'environnement système
+
+#### `NEXTJS_APP_ENV_NAME`
+- **Description**: Nom de l'environnement
+- **Valeurs possibles**: `development`, `staging`, `preprod`, `production`
+- **Utilisation**: Sélection de la configuration par environnement
+- **Valeur par défaut**: `development`
+
+#### `NODE_ENV`
+- **Description**: Environnement Node.js
+- **Valeurs possibles**: `development`, `production`
+- **Utilisation**: Configuration Next.js
+
+## Configuration par environnement
+
+### Développement
+```bash
+NEXTJS_APP_ENV_NAME=development
+NODE_ENV=development
+NEXT_PUBLIC_BACK_API_PROTOCOL=http://
+NEXT_PUBLIC_BACK_API_HOST=localhost
+NEXT_PUBLIC_BACK_API_PORT=3001
+NEXT_PUBLIC_4NK_URL=https://dev4.4nkweb.com
+```
+
+### Staging
+```bash
+NEXTJS_APP_ENV_NAME=staging
+NODE_ENV=production
+NEXT_PUBLIC_BACK_API_PROTOCOL=https://
+NEXT_PUBLIC_BACK_API_HOST=stg-api.lecoffre.com
+NEXT_PUBLIC_BACK_API_PORT=443
+NEXT_PUBLIC_4NK_URL=https://dev4.4nkweb.com
+```
+
+### Production
+```bash
+NEXTJS_APP_ENV_NAME=production
+NODE_ENV=production
+NEXT_PUBLIC_BACK_API_PROTOCOL=https://
+NEXT_PUBLIC_BACK_API_HOST=api.lecoffre.com
+NEXT_PUBLIC_BACK_API_PORT=443
+NEXT_PUBLIC_4NK_URL=https://4nk.lecoffre.com
+```
+
+## Utilisation dans le code
+
+### Configuration Next.js
+
+Les variables sont configurées dans `next.config.js`:
+
+```javascript
+const nextConfig = {
+  publicRuntimeConfig: {
+    NEXT_PUBLIC_BACK_API_PROTOCOL: process.env.NEXT_PUBLIC_BACK_API_PROTOCOL,
+    // ... autres variables
+  },
+  serverRuntimeConfig: {
+    // Même configuration pour le serveur
+  },
+  env: {
+    // Configuration pour le build
+  }
+};
+```
+
+### Initialisation dans l'application
+
+Les variables sont initialisées dans `_app.tsx`:
+
+```typescript
+const { publicRuntimeConfig } = getConfig();
+
+MyApp.getInitialProps = async () => {
+  return {
+    backApiProtocol: publicRuntimeConfig.NEXT_PUBLIC_BACK_API_PROTOCOL,
+    // ... autres variables
+  };
+};
+```
+
+### Utilisation dans les services
+
+```typescript
+// DatabaseService.ts
+private static buildBaseUrl(): string {
+  return `${publicRuntimeConfig.NEXT_PUBLIC_BACK_API_PROTOCOL}${publicRuntimeConfig.NEXT_PUBLIC_BACK_API_HOST}:${publicRuntimeConfig.NEXT_PUBLIC_BACK_API_PORT}${publicRuntimeConfig.NEXT_PUBLIC_BACK_API_ROOT_URL}${publicRuntimeConfig.NEXT_PUBLIC_BACK_API_VERSION}`;
+}
+```
+
+## Déploiement Docker
+
+### Variables de build
+
+```dockerfile
+ARG NEXT_PUBLIC_BACK_API_PROTOCOL
+ARG NEXT_PUBLIC_BACK_API_HOST
+# ... autres variables
+```
+
+### Variables d'environnement runtime
+
+```dockerfile
+ENV NEXT_PUBLIC_BACK_API_PROTOCOL=${NEXT_PUBLIC_BACK_API_PROTOCOL} \
+    NEXT_PUBLIC_BACK_API_HOST=${NEXT_PUBLIC_BACK_API_HOST} \
+    # ... autres variables
+```
+
+### Exécution
+
+```bash
+docker run -e NEXT_PUBLIC_BACK_API_PROTOCOL=https:// \
+           -e NEXT_PUBLIC_BACK_API_HOST=api.example.com \
+           lecoffre/front:latest
+```
+
+## Déploiement Kubernetes
+
+### Via Vault (recommandé)
+
+```yaml
+annotations:
+  vault.hashicorp.com/agent-inject: "true"
+  vault.hashicorp.com/agent-inject-secret-envs: secret/data/lecoffre-front-stg/config/envs
+  vault.hashicorp.com/agent-inject-template-envs: |
+    {{ with secret "secret/data/lecoffre-front-stg/config/envs" }}
+      {{ range $k, $v := .Data.data }}
+          export {{ $k }}="{{ $v }}"
+      {{ end }}
+    {{ end }}
+```
+
+### Via ConfigMap
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: lecoffre-front-config
+data:
+  NEXT_PUBLIC_BACK_API_PROTOCOL: "https://"
+  NEXT_PUBLIC_BACK_API_HOST: "api.example.com"
+  # ... autres variables
+```
+
+## Validation et tests
+
+### Vérification des variables requises
+
+```typescript
+const requiredVars = [
+  'NEXT_PUBLIC_BACK_API_PROTOCOL',
+  'NEXT_PUBLIC_BACK_API_HOST',
+  'NEXT_PUBLIC_BACK_API_PORT',
+  'NEXT_PUBLIC_BACK_API_ROOT_URL',
+  'NEXT_PUBLIC_BACK_API_VERSION'
+];
+
+for (const varName of requiredVars) {
+  if (!publicRuntimeConfig[varName]) {
+    throw new Error(`${varName} is not defined in environment variables`);
+  }
+}
+```
+
+### Tests d'environnement
+
+```bash
+# Vérifier les variables définies
+env | grep NEXT_PUBLIC_
+
+# Tester la construction d'URL
+curl -I $(echo $NEXT_PUBLIC_BACK_API_PROTOCOL$NEXT_PUBLIC_BACK_API_HOST:$NEXT_PUBLIC_BACK_API_PORT$NEXT_PUBLIC_BACK_API_ROOT_URL$NEXT_PUBLIC_BACK_API_VERSION/health)
+```
+
+## Bonnes pratiques
+
+1. **Sécurité**: Ne jamais exposer de secrets dans les variables `NEXT_PUBLIC_*`
+2. **Validation**: Toujours valider la présence des variables requises
+3. **Documentation**: Maintenir la documentation des variables
+4. **Tests**: Tester avec différentes configurations d'environnement
+5. **Fallbacks**: Prévoir des valeurs par défaut quand possible
+
+## Dépannage
+
+### Variables non définies
+
+```bash
+# Vérifier les variables d'environnement
+docker exec -it <container> env | grep NEXT_PUBLIC_
+
+# Vérifier la configuration Vault
+vault kv get secret/data/lecoffre-front-stg/config/envs
+```
+
+### URLs malformées
+
+```bash
+# Tester la construction d'URL
+node -e "
+const config = {
+  protocol: process.env.NEXT_PUBLIC_BACK_API_PROTOCOL,
+  host: process.env.NEXT_PUBLIC_BACK_API_HOST,
+  port: process.env.NEXT_PUBLIC_BACK_API_PORT,
+  root: process.env.NEXT_PUBLIC_BACK_API_ROOT_URL,
+  version: process.env.NEXT_PUBLIC_BACK_API_VERSION
+};
+console.log(\`\${config.protocol}\${config.host}:\${config.port}\${config.root}\${config.version}\`);
+"
+```
+
+---
+
+*Documentation mise à jour le $(date) - Variables d'environnement lecoffre-front*
--- a/docs/lecoffre-front/ci.md
+++ b/docs/lecoffre-front/ci.md
@ -0,0 +1,115 @@
+### CI/CD — Fonctionnement observé et architecture de déploiement
+
+Cette documentation décrit le pipeline CI/CD tel qu’il peut être déduit des artefacts présents dans le dépôt : `Dockerfile`, `package.json`, et les manifestes Kubernetes rendus dans `temp.yaml`. Aucune configuration de pipeline explicite n’est présente dans le dépôt (pas de `.gitea/`, `.github/workflows/`, `.gitlab-ci.yml`, `.drone.yml`). Le flux ci-dessous s’appuie donc sur ces éléments pour décrire le fonctionnement attendu.
+
+### Portée
+
+- **Build applicatif**: Next.js (Node 19-alpine) avec dépendance privée `le-coffre-resources` via SSH.
+- **Image Docker**: construction multi-étapes, publication vers le registre Docker hébergé sur `git.4nkweb.com` (accès via clés SSH).
+- **Déploiement Kubernetes**: namespace `lecoffre`, intégration Vault Agent pour l’injection d’ENV, `ExternalSecret` pour le secret de pull Docker, `Ingress` TLS via cert-manager, ressources de `Deployment`/`Service`.
+ - **Variables front ajoutées**: `NEXT_PUBLIC_4NK_IFRAME_URL` pour distinguer l’URL complète de l’iframe de son origin (`NEXT_PUBLIC_4NK_URL`).
+
+### Chaîne de build
+
+- **Dépendances**
+  - `package.json` indique Next.js 14, TypeScript 4.9, ESLint 8.36, etc.
+  - La dépendance privée `le-coffre-resources` est récupérée depuis `git.4nkweb.com` via SSH (`git+ssh`).
+
+- **Dockerfile** (multi-étapes, Node 19-alpine)
+  - Étape `deps`: installation des dépendances avec `npm install` en utilisant BuildKit et le forward d’agent SSH pour accéder au dépôt privé.
+  - Étape `development`: copie du code, exécution sous un utilisateur non-root, commande par défaut `npm run dev` (pour le développement local). Pour la prod, l’image utilisée en cluster exécute `npm run start` (cf. manifeste).
+
+- **Build Next.js**
+  - Script `build`: `NEXT_TELEMETRY_DISABLED=1 next build --no-lint`
+  - Script `start`: `next start`
+  - Le lint n’est pas bloquant au build (flag `--no-lint`).
+
+### Image, registre et version
+
+- **Registre**: Docker registry interne sur `git.4nkweb.com`.
+- **Tagging**: contrôlé par la CI via le message de commit (préfixe `ci: docker_tag=<valeur>`), sinon fallback `dev-test`. La branche peut être utilisée comme tag par défaut selon la CI. Recommandation: utiliser un tag non versionné `ext`.
+
+### Déploiement Kubernetes (extrait de `temp.yaml`)
+
+- **Namespace**: `lecoffre`
+- **ServiceAccount**: `lecoffre-front-sa` avec `Secret` token associé.
+- **ExternalSecret**: création de `imagePullSecret` à partir de Vault via `external-secrets.io` en lisant `secret/data/lecoffre-front-stg/config/dockerpullsecret` (clé `.dockerconfigjson`).
+- **Deployment**: `apps/v1` nommé `lecoffre-front` avec:
+  - `image`: `rg.fr-par.scw.cloud/lecoffre/front:v0.1.9`
+  - `imagePullPolicy`: `Always`
+  - `resources`: `requests` (cpu 200m, ram 1Gi), `limits` (ram 2Gi)
+  - **Vault Agent Injector**: annotations pour injecter des variables d’environnement depuis `secret/data/lecoffre-front-stg/config/envs` en exportant chaque paire `clé=valeur` dans `/vault/secrets/envs`.
+  - **Commande de démarrage**: `['sh','-c', '. /vault/secrets/envs && npm run start']`
+
+- **Service**: type ClusterIP exposant le port 80 vers le `targetPort` 3000 du conteneur Next.js.
+
+- **Ingress**: classe `nginx` avec TLS géré par `cert-manager` (ClusterIssuer `letsencrypt-prod`) pour `app.stg.lecoffre.smart-chain.fr`.
+
+### Flux CI/CD attendu (déduit)
+
+1. **Checkout + préparation**
+   - Récupération du code et configuration de l’agent SSH (accès à `git.4nkweb.com`).
+
+2. **Installation des dépendances**
+   - `npm install` avec BuildKit (`--mount=type=ssh`) pour la dépendance privée.
+
+3. **Build applicatif**
+   - `npm run build` (désactive la télémétrie et le lint bloquant).
+
+4. **Construction de l’image**
+   - Réalisée par la CI (BuildKit + forward d’agent SSH) après un `git push` sur `git.4nkweb.com`.
+   - Taggage déterminé par le message de commit et/ou la branche.
+
+5. **Push au registre**
+   - Réalisé par la CI vers le registre `git.4nkweb.com`.
+
+6. **Déploiement Kubernetes**
+   - Application des manifestes (ou rendu Helm) dans le namespace `lecoffre`.
+   - Les secrets de pull sont fournis via `ExternalSecret` connecté à Vault.
+   - Au runtime, Vault Agent injecte les variables d’environnement nécessaires avant `npm run start`.
+
+### Sécurité et secrets
+
+- **Build**: le forward d’agent SSH évite d’écrire la clé privée dans l’image.
+- **Runtime**: aucune variable sensible n’est stockée dans l’image; elles sont injectées à l’exécution par Vault.
+- **Pull de l’image**: la config Docker (`.dockerconfigjson`) est fournie par `ExternalSecret` à partir de Vault.
+
+### Secrets CI requis
+
+- **USER**: identifiant du compte CI sur `git.4nkweb.com` disposant des droits requis (lecture repo, push d’image vers le registry).
+- **TOKEN**: jeton d’accès (API/registry) associé à `USER`. Utilisé par la CI pour:
+  - Authentifier les actions git/HTTP vers `git.4nkweb.com` (si nécessaire)
+  - Authentifier le `docker login` vers le registry Gitea si la CI ne repose pas sur des credentials intégrés.
+
+Notes:
+- Préférer des tokens à portée restreinte, régénérés périodiquement.
+- Stocker `USER` et `TOKEN` dans le gestionnaire de secrets CI et ne jamais les committer.
+
+### Points à confirmer
+
+- Outil CI utilisé (Gitea Actions, Woodpecker/Drone, GitLab CI, autre) et fichiers de pipeline hébergés ailleurs.
+- Règles de nommage des tags d’image et gouvernance de version (`vX.Y.Z`, tags d’environnement).
+- Stratégie de déploiement (Helm chart source exact, commandes d’apply, gestion multi-env: dev/stg/prod).
+- Politique de lint/test avant build (actuellement `--no-lint` au build Next.js).
+ - Passage des variables `NEXT_PUBLIC_4NK_URL` et `NEXT_PUBLIC_4NK_IFRAME_URL` à l’étape de build Docker (ARG/ENV) dans la CI.
+
+### Bonnes pratiques recommandées
+
+- Activer un job de lint et tests unitaires avant build d’image.
+- Signer les images (Cosign) et activer des scans SCA/Container.
+- Gérer explicitement les tags et le changelog en CI.
+- Déployer via Helm chart versionné, avec valeurs par environnement (`values.{env}.yaml`).
+
+### Validation de l'image Docker « ext » (intégration des variables)
+
+- Objectif: vérifier que les variables `NEXT_PUBLIC_*` sont bien injectées dans l'image construite par la CI.
+- Commande:
+
+```
+docker pull git.4nkweb.com/4nk/lecoffre-front:ext
+docker run --rm git.4nkweb.com/4nk/lecoffre-front:ext sh -lc "env | grep '^NEXT_PUBLIC_' | sort"
+```
+
+- Attendus clés:
+  - `NEXT_PUBLIC_4NK_URL` et `NEXT_PUBLIC_4NK_IFRAME_URL` doivent être définies.
+  - Les URLs API (`NEXT_PUBLIC_API_URL`, `NEXT_PUBLIC_BACK_API_*`) doivent refléter l'environnement.
--- a/docs/lecoffre-front/ext.md
+++ b/docs/lecoffre-front/ext.md
@ -0,0 +1,58 @@
+### Image Docker "ext" (Next.js) – variables d'environnement et publication
+
+Cette image exécute l'app Next.js en mode production via `next start` et lit la configuration via les variables d'environnement exposées (préfixe `NEXT_PUBLIC_`). L'objectif est d'éviter toute dépendance à `localhost` dans les appels API : les URLs sont construites dynamiquement côté front à partir de ces variables.
+
+#### Variables d'environnement supportées
+
+- **NEXT_PUBLIC_BACK_API_PROTOCOL**: protocole de l'API (ex: `https://`)
+- **NEXT_PUBLIC_BACK_API_HOST**: hôte de l'API (ex: `api.example.com`)
+- **NEXT_PUBLIC_BACK_API_PORT**: port de l'API (ex: `443`)
+- **NEXT_PUBLIC_BACK_API_ROOT_URL**: racine (ex: `/` ou `/api`)
+- **NEXT_PUBLIC_BACK_API_VERSION**: version (ex: `v1`)
+- **NEXT_PUBLIC_FRONT_APP_HOST**: base publique du front (ex: `https://app.example.com`)
+- **NEXT_PUBLIC_FRONT_APP_PORT**: port front si nécessaire (ex: `443`)
+- **NEXT_PUBLIC_IDNOT_AUTHORIZE_ENDPOINT**
+- **NEXT_PUBLIC_IDNOT_CLIENT_ID**
+- **NEXT_PUBLIC_IDNOT_BASE_URL**
+- **NEXT_PUBLIC_DOCAPOSTE_API_URL**
+- **NEXT_PUBLIC_HOTJAR_SITE_ID**
+- **NEXT_PUBLIC_HOTJAR_VERSION**
+- **NEXT_PUBLIC_4NK_URL**
+- **NEXT_PUBLIC_API_URL**
+- **NEXT_PUBLIC_DEFAULT_VALIDATOR_ID**
+- **NEXT_PUBLIC_DEFAULT_STORAGE_URLS** (liste séparée par des virgules)
+
+Notes:
+
+- Le front initialise ses variables via `next.config.js` et `_app.tsx`, ce qui alimente `FrontendVariables`. Les appels API utilisent ces valeurs et n'emploient pas `localhost`.
+- Les valeurs doivent être passées au conteneur au runtime (`docker run -e ...` ou manifest K8s via `env:`/`secretRef`).
+
+#### Construction de l'image (cible "ext")
+
+Prérequis: Docker BuildKit activé et agent SSH opérationnel pour cloner `le-coffre-resources` depuis `git.4nkweb.com`.
+
+1. `cd /home/debian/lecoffre-front`
+2. `export DOCKER_BUILDKIT=1`
+3. `docker build --target ext --ssh default -t lecoffre/front:ext -f /home/debian/lecoffre-front/Dockerfile /home/debian/lecoffre-front`
+
+#### Exécution locale (validation)
+
+Exemple minimal (adapter les valeurs):
+
+```bash
+docker run --rm -p 3000:3000 \
+  -e NEXT_PUBLIC_BACK_API_PROTOCOL=https:// \
+  -e NEXT_PUBLIC_BACK_API_HOST=api.example.com \
+  -e NEXT_PUBLIC_BACK_API_PORT=443 \
+  -e NEXT_PUBLIC_BACK_API_ROOT_URL=/ \
+  -e NEXT_PUBLIC_BACK_API_VERSION=v1 \
+  -e NEXT_PUBLIC_FRONT_APP_HOST=https://app.example.com \
+  -e NEXT_PUBLIC_4NK_URL=https://app.example.com \
+  lecoffre/front:ext
+```
+
+#### Publication via CI (git.4nkweb.com)
+
+- Le push d'image est effectué par la CI de `git.4nkweb.com` suite à un `git push`.
+- Définir le tag Docker dans le message de commit: `ci: docker_tag=ext` (fallback CI: `dev-test`).
+- La branche peut être utilisée par la CI comme tag en l’absence d’override.
--- a/docs/sdk_relay/AMELIORATIONS_RECENTES.md
+++ b/docs/sdk_relay/AMELIORATIONS_RECENTES.md
@ -0,0 +1,43 @@
+# Améliorations Récentes - SDK Relay
+
+## Date: 20 Septembre 2025
+
+### 🔧 Corrections Majeures
+
+#### 1. Problème de Scan Bloquant
+**Problème:** Le service se bloquait lors du scan initial des blocs Bitcoin.
+
+**Solution:**
+- Optimisation du `last_scan` pour éviter les scans trop importants
+- Réduction des logs de `DEBUG` à `INFO`
+- Amélioration du healthcheck
+
+**Fichiers modifiés:**
+- `Dockerfile` - Ajout des outils système
+- `Cargo.toml` - Mise à jour des dépendances
+- Configuration - Optimisation des paramètres
+
+#### 2. Installation des Outils Système
+**Ajouté dans le Dockerfile:**
+```dockerfile
+RUN apt-get update && apt-get upgrade -y && \
+    apt-get install -y ca-certificates dnsutils jq curl git wget telnet npm coreutils && \
+    npm install -g wscat && \
+    rm -rf /var/lib/apt/lists/* /root/.npm
+```
+
+#### 3. Configuration Bootstrap
+- URL bootstrap: `wss://dev3.4nkweb.com/ws/`
+- Faucet activé: `bootstrap_faucet=true`
+- Adresse SP permanente configurée
+
+### 📊 État Actuel
+- **Version:** 0.1.2
+- **Statut:** ✅ Healthy
+- **Logs:** Niveau INFO (optimisé)
+- **Scan:** Optimisé pour éviter les blocages
+
+### 🔄 Prochaines Étapes
+- Monitoring des performances
+- Tests de connectivité bootstrap
+- Optimisations supplémentaires si nécessaire
--- a/docs/sdk_relay/ANALYSE.md
+++ b/docs/sdk_relay/ANALYSE.md
@ -0,0 +1,85 @@
+## Analyse détaillée
+
+### Périmètre
+
+Service Rust `sdk_relay` interfaçant Bitcoin (RPC), Blindbit et WebSocket, avec configuration injectée.
+
+### Stack
+
+- **Langage**: Rust 2021
+- **Dépendances**: `tokio`, `tokio-tungstenite`, `zeromq`, `bitcoincore-rpc`, `serde[_json]`, `env_logger`, `futures-util`, `sdk_common` (git, branche `dev`, features `parallel`, `blindbit-backend`).
+
+### Build et image
+
+- Docker multi‑étapes: build dans `rust:latest` avec SSH pour deps privées, exécution `debian:bookworm-slim`.
+- Binaire: `/usr/local/bin/sdk_relay`.
+- Conf: build‑arg `CONF` écrit dans `/home/bitcoin/.conf`.
+- Volumes: `/home/bitcoin/.4nk`, `/home/bitcoin/.bitcoin`.
+
+### Réseau et healthcheck
+
+- **WebSocket**: serveur lié sur `Config.ws_url` (ex. `0.0.0.0:8090`) via `tokio_tungstenite`.
+- **Health**: serveur TCP léger interne sur port `8091` retournant `{"status":"ok"}`.
+- **Ports exposés**: `8090` (WS), `8091` (HTTP /health) dans le `Dockerfile`.
+
+Références code:
+
+```396:625:src/main.rs
+async fn handle_health_endpoint(mut stream: TcpStream) {
+    let response = "HTTP/1.1 200 OK\r\nContent-Type: application/json\r\nContent-Length: 15\r\n\r\n{\"status\":\"ok\"}";
+    let _ = stream.write_all(response.as_bytes()).await;
+    let _ = stream.shutdown().await;
+}
+
+async fn start_health_server(port: u16) { /* ... */ }
+
+// Start health server on port 8091
+tokio::spawn(start_health_server(8091));
+```
+
+Configuration:
+
+```1:7:.conf.model
+core_url=""
+ws_url=""
+wallet_name="default"
+network="signet"
+electrum_url="tcp://localhost:60601"
+blindbit_url="tcp://localhost:8000"
+zmq_url=""
+```
+
+### Logs
+
+- `RUST_LOG` géré par env; dans `lecoffre_node`, sortie tee vers `/home/bitcoin/.4nk/logs/sdk_relay.log`.
+
+### Risques et points d’attention
+
+- Dépendance `sdk_common` via git/branche `dev`: geler par tag/commit pour reproductibilité.
+- Image d’exécution embarque `strace`; vérifier nécessité en prod.
+- Permissions volume Windows: note de chown partiel dans compose parent.
+
+### Actions proposées
+
+- Pinner `sdk_common` sur un commit ou tag; documenter politique de mise à jour.
+- Séparer images `-dev` et `-prod` si `strace` non requis.
+- Documenter format du fichier de conf (`sdk_relay.conf`) et valeurs par défaut.
+
+### CI / Image
+
+- Pipeline `build-and-push-ext` construit et pousse l’image avec un tag calculé depuis le message de commit (préfixe `ci: docker_tag=` sinon `dev-test`).
+- L’image expose `8090 8091` et lance `sdk_relay --config /home/bitcoin/.conf`.
+
+Références:
+
+```1:46:Dockerfile
+EXPOSE 8090 8091
+ENTRYPOINT ["sdk_relay", "--config", "/home/bitcoin/.conf"]
+```
+
+```1:73:.gitea/workflows/build-ext.yml
+name: build-and-push-ext
+```
+
+
+
--- a/docs/sdk_relay/ARCHITECTURE.md
+++ b/docs/sdk_relay/ARCHITECTURE.md
@ -0,0 +1,20 @@
+# Architecture - SDK Relay
+
+## Composants
+- Service Rust WebSocket relay + intégration Bitcoin/BlindBit.
+
+## Dépendances
+- `bitcoin` (RPC/ZMQ), `blindbit-proxy`, `sdk_storage`.
+
+## Réseau et ports
+- WS: `0.0.0.0:8090` (exposé derrière Nginx `wss://dev4.4nkweb.com/ws/`).
+
+## Variables d’environnement (centralisées)
+- `SDK_RELAY_*` depuis `lecoffre_node/.env.master`.
+
+## Monitoring
+- Healthcheck avec progression IBD/attentes.
+- Logs centralisés Loki/Grafana (SDK Services).
+
+## Notes
+- Démarre après Bitcoin et BlindBit.
--- a/docs/sdk_relay/CONFIGURATION.md
+++ b/docs/sdk_relay/CONFIGURATION.md
@ -0,0 +1,74 @@
+# Configuration SDK Relay
+
+## Variables d'environnement
+
+Le service `sdk_relay` peut être configuré via les variables d'environnement suivantes :
+
+### Variables principales
+
+- **`SDK_RELAY_WS_URL`** : URL WebSocket pour les tests (défaut: `ws://0.0.0.0:8090`)
+- **`WS_BIND_URL`** : URL de binding WebSocket (override de la configuration, défaut: valeur de `ws_url`)
+- **`HEALTH_PORT`** : Port du serveur de santé (défaut: `8091`)
+- **`HEALTH_BIND_ADDRESS`** : Adresse de binding du serveur de santé (défaut: `0.0.0.0`)
+- **`RUST_LOG`** : Niveau de logging (défaut: `INFO`)
+
+### Configuration via fichier
+
+Le service utilise un fichier de configuration (`sdk_relay.conf`) avec les paramètres suivants :
+
+```ini
+core_url="http://bitcoin:38332"
+ws_url="0.0.0.0:8090"
+wallet_name="default"
+network="signet"
+blindbit_url="http://blindbit-oracle:8000"
+zmq_url="tcp://bitcoin:29000"
+storage="https://dev4.4nkweb.com/storage"
+data_dir="/home/bitcoin/.4nk"
+bitcoin_data_dir="/home/bitcoin/.bitcoin"
+bootstrap_url="wss://dev3.4nkweb.com/ws/"
+bootstrap_faucet=true
+RUST_LOG="INFO"
+sp_address="tsp1qqgmwp9n5p9ujhq2j6cfqe4jpkyu70jh9rgj0pwt3ndezk2mrlvw6jqew8fhsulewzglfr7g2aa48wyj4n0r7yasa3fm666vda8984ke8tuaf9m89"
+```
+
+## Changements récents
+
+### v0.1.3 - Configuration externalisée avancée
+
+- **Ajout** : Variables d'environnement `WS_BIND_URL`, `HEALTH_PORT`, `HEALTH_BIND_ADDRESS`
+- **Ajout** : Support de la variable d'environnement `SDK_RELAY_WS_URL` pour les tests
+- **Modification** : Remplacement de `localhost` par `0.0.0.0` dans les tests WebSocket
+- **Amélioration** : Configuration plus flexible pour les environnements Docker
+- **Correction** : Résolution du problème de binding sur 127.0.0.1 au lieu de 0.0.0.0
+
+### Tests
+
+Les tests WebSocket utilisent maintenant `ws://0.0.0.0:8090` au lieu de `ws://localhost:8090` pour une meilleure compatibilité avec les environnements Docker.
+
+## Configuration Docker
+
+```yaml
+environment:
+  - WS_BIND_URL=0.0.0.0:8090
+  - HEALTH_PORT=8091
+  - HEALTH_BIND_ADDRESS=0.0.0.0
+  - RUST_LOG=INFO
+volumes:
+  - ./relay/sdk_relay.conf:/home/bitcoin/.conf:ro
+```
+
+## Endpoints
+
+- **WebSocket** : `0.0.0.0:8090` - Communication WebSocket
+- **Health** : `0.0.0.0:8091` - Vérification de santé
+
+## Dépannage
+
+### Problème de connexion WebSocket
+
+Si le service n'écoute pas sur `0.0.0.0:8090`, vérifiez :
+
+1. La configuration `ws_url` dans le fichier de configuration
+2. Les variables d'environnement Docker
+3. Les logs du service pour les erreurs de binding
--- a/docs/sdk_relay/DEPLOIEMENT.md
+++ b/docs/sdk_relay/DEPLOIEMENT.md
@ -0,0 +1,21 @@
+# Déploiement - SDK Relay
+
+## Préparation
+- Branche `ext`.
+- `SDK_RELAY_*` dans `lecoffre_node/.env.master`.
+- Accès `bitcoin` RPC/ZMQ et `blindbit-proxy`.
+
+## Déploiement (orchestrateur)
+```bash
+cd /home/debian/4NK_env/lecoffre_node
+./scripts/start.sh | cat
+./scripts/validate-deployment.sh | cat
+```
+
+## Vérifications
+- WS: `wss://dev4.4nkweb.com/ws/`.
+- `./scripts/monitor-progress.sh | cat` (attente IBD/BlindBit).
+
+## Règles
+- Pas de compose direct.
+- Push `ext` sans CI si pas de binaire à reconstruire.
--- a/docs/sdk_relay/FLUX.md
+++ b/docs/sdk_relay/FLUX.md
@ -0,0 +1,6 @@
+# Description des Flux - SDK Relay
+
+## Flux principaux
+1. Bitcoin (RPC/ZMQ) → Relay (indexation, signaux IBD).
+2. BlindBit → Relay (résolution secrets SP).
+3. Clients WS ↔ Relay (évènements NewTx, notifications).
--- a/docs/sdk_relay/FONCTIONNEL.md
+++ b/docs/sdk_relay/FONCTIONNEL.md
@ -0,0 +1,13 @@
+# Description Fonctionnelle - SDK Relay
+
+## Objectif
+Assurer le relais temps réel WebSocket et l’orchestration des évènements blockchain (Bitcoin/BlindBit) pour les services applicatifs.
+
+## Parcours clés
+- Abonnement clients WS.
+- Relais d’évènements (nouveaux blocs, transactions, notifications NewTx).
+- Attente synchronisation Bitcoin et disponibilité BlindBit avant diffusion.
+
+## Résultats attendus
+- Canal temps réel fiable.
+- Mise en file d’attente/retente en cas d’indisponibilité dépendances.
--- a/docs/sdk_relay/INSTALLATION.md
+++ b/docs/sdk_relay/INSTALLATION.md
@ -0,0 +1,24 @@
+# Installation - SDK Relay
+
+## Prérequis
+- Dépôts sous `/home/debian/4NK_env` (branche `ext`).
+- Docker/Compose.
+- Variables `SDK_RELAY_*` dans `lecoffre_node/.env.master`.
+
+## Configuration
+- Pas de `.env` local.
+- Vérifier accès `bitcoin` (RPC/ZMQ) et `blindbit-proxy`.
+
+## Démarrage (orchestrateur)
+```bash
+cd /home/debian/4NK_env/lecoffre_node
+./scripts/start.sh | cat
+```
+
+## Vérifications
+- WS: `wss://dev4.4nkweb.com/ws/`
+- Health: scripts `monitor-progress.sh`, `logs-with-progress.sh`.
+
+## Notes
+- Démarre après Bitcoin et BlindBit.
+- CI via tag `ext`.
--- a/docs/sdk_relay/QUALITE.md
+++ b/docs/sdk_relay/QUALITE.md
@ -0,0 +1,6 @@
+# Qualité Logicielle - SDK Relay
+
+- Lint/format: Rustfmt/Clippy.
+- Tests: unitaires, intégration WS, tests de charge.
+- Performance: backpressure WS, gestion erreurs.
+- Observabilité: logs structurés, métriques si dispo.
--- a/docs/sdk_relay/SECURITE.md
+++ b/docs/sdk_relay/SECURITE.md
@ -0,0 +1,6 @@
+# Sécurité - SDK Relay
+
+- Aucune clé ou secret en dur.
+- Accès Bitcoin RPC/ZMQ sécurisés sur réseau interne Docker.
+- Validation stricte des messages WS.
+- Journaux sans secrets.
--- a/docs/sdk_relay/TECHNIQUE.md
+++ b/docs/sdk_relay/TECHNIQUE.md
@ -0,0 +1,19 @@
+# Description Technique - SDK Relay
+
+## Tech stack
+- Rust, WebSocket server.
+
+## Configuration
+- Variables `SDK_RELAY_*` via `lecoffre_node/.env.master`.
+- Connexion Bitcoin (RPC/ZMQ), BlindBit URL.
+
+## Interfaces
+- WS `0.0.0.0:8090` (derrière Nginx).
+
+## Sécurité
+- Aucun secret en dur.
+- Validation stricte des messages.
+
+## Observabilité
+- Healthcheck avec progression.
+- Logs Loki/Grafana.
--- a/docs/sdk_relay/TODO.md
+++ b/docs/sdk_relay/TODO.md
@ -0,0 +1,6 @@
+# TODO - SDK Relay
+
+- Vérifier connexion Bitcoin (RPC/ZMQ) et BlindBit.
+- Tester WebSocket public via Nginx.
+- Valider healthchecks et progression IBD.
+- Surveiller logs et mettre en place alertes Grafana.
--- a/docs/sdk_relay/VALIDATION.md
+++ b/docs/sdk_relay/VALIDATION.md
@ -0,0 +1,40 @@
+## Validation opérationnelle
+
+### Pré‑requis
+
+- Image `git.4nkweb.com/4nk/sdk_relay:<tag>` construite par la CI (workflow `build-and-push-ext`).
+- Fichier de configuration accessible dans le conteneur à `/home/bitcoin/.conf` avec au minimum: `core_url`, `ws_url`, `wallet_name`, `network`, `blindbit_url`, `zmq_url`.
+- Ports hôtes libres: `8090` (WebSocket), `8091` (HTTP /health).
+
+### Démarrage / Redémarrage du service
+
+1. Arrêter l’instance en cours (si gérée via Docker/compose parent), puis démarrer avec la nouvelle image taggée `ext` (ou le tag CI calculé) en veillant à monter les volumes `/home/bitcoin/.4nk` et `/home/bitcoin/.bitcoin`.
+2. Vérifier les logs de démarrage et la ligne: `Health server listening on port 8091`.
+
+### Tests de santé
+
+- HTTP: `curl -sS http://localhost:8091/health` doit renvoyer `{"status":"ok"}` avec un code 200.
+
+### Tests WebSocket
+
+- Connexion: ouvrir un client vers `ws://localhost:8090` (adresse selon `ws_url`). La poignée de main doit réussir.
+- Réception initiale: un message de type Handshake (avec adresse SP, membres et processus) est diffusé à la connexion.
+- Diffusion: émettre un message valide (selon protocole `sdk_common`) et vérifier qu’il est redistribué selon le `BroadcastType`.
+
+### Parcours fonctionnel complet
+
+1. IdNot: initialiser un identifiant et vérifier la persistance locale dans le volume `.4nk`.
+2. iframe: intégrer le client (IHM) et établir la communication vers le WebSocket du `sdk_relay`.
+3. Ajout de service: exécuter le flux d’ajout et confirmer la mise à jour de l’état et la diffusion côté WS.
+
+### Attendus CI/CD
+
+- La CI construit automatiquement l’image incluant l’endpoint `/health` et pousse avec le tag calculé (préfixe commit `ci: docker_tag=...`, sinon `dev-test`).
+- Une fois l’image disponible (tag `ext` si prévu), redémarrer le service pour résoudre les problèmes de connexion.
+
+### Dépannage
+
+- Port occupé: vérifier qu’aucun service n’écoute déjà sur `8090/8091`.
+- Conf manquante/invalide: le binaire échoue avec `Failed to find conf file` ou erreurs `No "..."`; corriger `/home/bitcoin/.conf`.
+- ZMQ/Blindbit: si pas joignables, les fonctionnalités associées peuvent être dégradées; le `/health` reste OK si le service tourne.
+- Volumes: en environnement Windows, vérifier les permissions et l’utilisateur `bitcoin`.
--- a/docs/sdk_relay/WEBSOCKET_CONFIGURATION.md
+++ b/docs/sdk_relay/WEBSOCKET_CONFIGURATION.md
@ -0,0 +1,68 @@
+# Configuration WebSocket - sdk_relay
+
+## Configuration actuelle
+
+### Variables d'environnement
+- `WS_BIND_URL` : URL de binding WebSocket (défaut: `0.0.0.0:8090`)
+- `HEALTH_PORT` : Port du serveur de santé (défaut: `8091`)
+- `HEALTH_BIND_ADDRESS` : Adresse de binding du serveur de santé (défaut: `0.0.0.0`)
+
+### Configuration dans sdk_relay.conf
+```ini
+ws_url="0.0.0.0:8090"
+blindbit_url="http://blindbit-oracle:8000"
+bootstrap_url="wss://dev3.4nkweb.com/ws/"
+bootstrap_faucet=true
+sp_address="tsp1qqgmwp9n5p9ujhq2j6cfqe4jpkyu70jh9rgj0pwt3ndezk2mrlvw6jqew8fhsulewzglfr7g2aa48wyj4n0r7yasa3fm666vda8984ke8tuaf9m89"
+RUST_LOG="INFO"
+```
+
+## Problèmes résolus
+
+### 1. Binding sur 127.0.0.1 au lieu de 0.0.0.0
+**Problème :** Le relay se liait sur `127.0.0.1:8090` au lieu de `0.0.0.0:8090`.
+
+**Solution :** Externalisation de la configuration via variables d'environnement et correction du code Rust.
+
+### 2. Gestion des erreurs WebSocket
+**Problème :** Erreurs de handshake WebSocket non gérées correctement.
+
+**Solution :** Amélioration de la gestion d'erreurs avec `log::warn!` au lieu de `log::error!` pour les tentatives de connexion non-WebSocket.
+
+### 3. Configuration externalisée
+**Problème :** IP et ports hardcodés dans le code Rust.
+
+**Solution :** Externalisation de tous les paramètres de configuration via variables d'environnement.
+
+## Tests WebSocket
+
+### Test avec headers corrects
+```bash
+curl -v -H "Upgrade: websocket" \
+     -H "Connection: upgrade" \
+     -H "Sec-WebSocket-Version: 13" \
+     -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
+     http://127.0.0.1:8090/
+```
+
+**Résultat attendu :** `HTTP/1.1 101 Switching Protocols`
+
+### Test sans headers WebSocket
+```bash
+curl -v http://127.0.0.1:8090/
+```
+
+**Résultat attendu :** Erreur de handshake WebSocket (normal)
+
+## Problème persistant
+
+### Nginx ne transmet pas les headers WebSocket
+**Statut :** ⚠️ Problème persistant
+- Nginx configuré avec tous les headers WebSocket
+- Le relay reçoit toujours des connexions sans headers
+- Erreur : `"No Upgrade: websocket header"`
+
+**Investigation :** La configuration Nginx semble correcte mais les headers ne sont pas transmis.
+
+## Date de mise à jour
+2025-01-20 - Configuration WebSocket externalisée et problèmes de binding résolus
--- a/docs/sdk_storage/AMELIORATIONS_RECENTES.md
+++ b/docs/sdk_storage/AMELIORATIONS_RECENTES.md
@ -0,0 +1,35 @@
+# Améliorations Récentes - SDK Storage
+
+## Date: 20 Septembre 2025
+
+### 🔧 Améliorations Majeures
+
+#### 1. Installation des Outils Système
+**Ajouté dans le Dockerfile:**
+```dockerfile
+RUN apt-get update && apt-get upgrade -y && \
+    apt-get install -y ca-certificates dnsutils jq curl git wget telnet npm coreutils && \
+    npm install -g wscat && \
+    rm -rf /var/lib/apt/lists/* /root/.npm
+```
+
+#### 2. Optimisation de l'Image
+- Mise à jour des packages système
+- Installation des outils de diagnostic
+- Nettoyage des caches pour réduire la taille
+
+#### 3. Configuration des Services
+- Port: 8081 (mappé sur 8081)
+- Healthcheck: Vérification de la connectivité
+- Logs: Niveau optimisé
+
+### 📊 État Actuel
+- **Statut:** ✅ Running
+- **Port:** 8081 accessible
+- **Outils:** Tous les outils système installés
+- **Logs:** Optimisés
+
+### 🔄 Prochaines Étapes
+- Tests de connectivité storage
+- Monitoring des performances
+- Optimisations supplémentaires
--- a/docs/sdk_storage/ANALYSE.md
+++ b/docs/sdk_storage/ANALYSE.md
@ -0,0 +1,40 @@
+## Analyse détaillée
+
+### Périmètre
+
+Service Rust `sdk_storage` (Tide) offrant stockage clé/valeur avec TTL optionnel.
+
+### Stack
+
+- **Langage**: Rust 2021
+- **Serveur**: `tide@0.16`, runtime `async-std`
+- **Utilitaires**: `serde`, `serde_json`, `hex`, `env_logger`
+- **Tests**: `tempfile`, `surf` (h1-client)
+
+### API
+
+- POST `/store` { key(hex64), value(hex), ttl? (s) }
+- GET `/retrieve/:key`
+
+### Build et image
+
+- Docker: build dans `rust:1`, exécution `debian:stable-slim`, utilisateur non‑root, `RUST_LOG=info`.
+- Expose: 8081; `CMD ["--permanent"]` (clé sans TTL).
+
+### Risques et points d’attention
+
+- Validation stricte des formats hex requis (taille/charset) à documenter et tester.
+- Absence de persistance volumée par défaut: fournir stratégie de stockage (répertoire, montage, quotas).
+- Logging et rotation à cadrer si charge élevée.
+
+### Actions proposées
+
+- Documenter schéma d’erreurs (HTTP, payload) et ajouter tests d’intégration dans `tests/`.
+- Ajouter option de répertoire de stockage configurable et exemple `.env.example`.
+- Mettre en place CI rust (build, test, fmt, clippy, audit).
+
+
+
+
+
+
--- a/docs/sdk_storage/CONFIGURATION.md
+++ b/docs/sdk_storage/CONFIGURATION.md
@ -0,0 +1,50 @@
+# Configuration SDK Storage
+
+## Variables d'environnement
+
+Le service `sdk_storage` peut être configuré via les variables d'environnement suivantes :
+
+### Variables principales
+
+- **`STORAGE_DIR`** : Répertoire de stockage des données (défaut: `./storage`)
+- **`PORT`** : Port d'écoute du serveur HTTP (défaut: `8080`)
+- **`NO_TTL_PERMANENT`** : Si définie, les requêtes sans TTL sont traitées comme permanentes
+
+### Exemples d'utilisation
+
+```bash
+# Configuration personnalisée
+export STORAGE_DIR="/var/lib/sdk_storage"
+export PORT="8080"
+export NO_TTL_PERMANENT="1"
+
+# Lancement du service
+./sdk_storage
+```
+
+## Changements récents
+
+### v0.2.2 - Configuration externalisée
+
+- **Ajout** : Support des variables d'environnement pour `STORAGE_DIR` et `PORT`
+- **Modification** : Remplacement de `127.0.0.1` par `0.0.0.0` dans les tests
+- **Amélioration** : Configuration plus flexible pour les déploiements Docker
+
+### Tests
+
+Les tests utilisent maintenant `0.0.0.0:0` au lieu de `127.0.0.1:0` pour une meilleure compatibilité avec les environnements Docker.
+
+## Configuration Docker
+
+```yaml
+environment:
+  - STORAGE_DIR=/app/storage
+  - PORT=8080
+  - NO_TTL_PERMANENT=1
+```
+
+## API Endpoints
+
+- `GET /health` - Vérification de santé
+- `POST /store` - Stockage de données
+- `GET /retrieve/{key}` - Récupération de données
--- a/docs/sdk_storage/README.md
+++ b/docs/sdk_storage/README.md
@ -0,0 +1,39 @@
+# Documentation du projet sdk_storage
+
+Ce dossier documente l'API HTTP, l'architecture et les décisions techniques.
+
+## API
+
+- POST `/store` : stocke une valeur hex pour une clé hex 64 chars, `ttl` optionnel (secondes). Quand `--permanent` est passé au binaire, l'absence de `ttl` rend la donnée permanente.
+- GET `/retrieve/:key` : retourne `{ key, value }` où `value` est encodée en hex.
+
+## Architecture
+
+- Service `StorageService` (voir `src/lib.rs`) encapsule la logique de stockage, récupération et nettoyage TTL.
+- `src/main.rs` démarre Tide avec état `StorageService` et une boucle de nettoyage périodique (60s).
+
+Voir aussi:
+- `architecture.md`
+- `configuration.md`
+- `guides_principaux.md`
+- `guides_techniques.md`
+- `guides_test.md`
+- `tests_monitoring.md`
+- `reseau_de_relais.md`
+- `developpement.md`
+- `depannage.md`
+- `performance.md`
+- `api_json_spec.md`
+- `api_contrats.md`
+- `release_guide.md`
+- `ci_docker_registry.md`
+
+## REX technique
+
+- Docker
+  - Build local: `docker build -t sdk_storage:local .`
+  - Run: `docker run --rm -p 8081:8081 -v $PWD/storage:/app/storage sdk_storage:local`
+  - Par défaut `--permanent` est activé via CMD, override possible: `docker run ... sdk_storage -- --permanent`
+
+- Refactor initial de la logique depuis `main.rs` vers `lib.rs` pour testabilité et séparation des responsabilités.
+- Durées TTL maintenant validées dans le handler, calcul d'expiration converti en `SystemTime` avant l'appel service.
--- a/docs/sdk_storage/api_contrats.md
+++ b/docs/sdk_storage/api_contrats.md
@ -0,0 +1,21 @@
+# Contrats API
+
+## Garanties de Contrat
+- Content-Type JSON, réponses structurées.
+- Clé: 64 hex (validation stricte), sinon 400.
+- Valeur: hex valide, sinon 400.
+- Conflit de clé: 409 si la clé existe déjà.
+- TTL: min 60, max 31 536 000; par défaut 86 400 si non `--permanent`.
+- Récupération:
+  - 200 avec `{ key, value }` si trouvée.
+  - 400 si clé invalide.
+  - 404 si absente.
+
+## Couverture de Tests
+- Stockage et récupération (succès).
+- Conflit de clé.
+- Suppression des expirés via nettoyage.
+- HTTP `/store`: succès, conflit, clé invalide, valeur invalide.
+- HTTP `/retrieve`: succès, clé invalide, clé absente.
+
+Voir `api_json_spec.md` pour les schémas et contraintes détaillés.
--- a/docs/sdk_storage/api_json_spec.md
+++ b/docs/sdk_storage/api_json_spec.md
@ -0,0 +1,113 @@
+# Spécification JSON des API
+
+## Généralités
+- Content-Type: `application/json; charset=utf-8`
+- Encodage des valeurs: chaînes hexadécimales minuscules (0-9a-f).
+- Modèle d'erreur: corps `{ "message": string }` avec code HTTP approprié.
+
+## POST /store
+- Objet requête: `StoreRequest`
+- Objet réponse (succès/erreur): `ApiResponse`
+
+### Schéma JSON (StoreRequest)
+```json
+{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "title": "StoreRequest",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["key", "value"],
+  "properties": {
+    "key": {
+      "type": "string",
+      "description": "Clé hexadécimale 64 caractères (32 octets).",
+      "pattern": "^[0-9a-fA-F]{64}$"
+    },
+    "value": {
+      "type": "string",
+      "description": "Valeur encodée en hexadécimal.",
+      "pattern": "^[0-9a-fA-F]+$"
+    },
+    "ttl": {
+      "type": "integer",
+      "minimum": 60,
+      "maximum": 31536000,
+      "description": "Durée de vie en secondes. Si absent: défaut 86400 sauf si mode --permanent (aucune expiration)."
+    }
+  }
+}
+```
+
+### Règles de validation et sémantique
+- `key`: exactement 64 caractères hex (
+32 octets).
+- `value`: chaîne hex valide, longueur paire recommandée (représentation d'octets).
+- `ttl`:
+  - min: 60, max: 31 536 000.
+  - si absent et binaire lancé sans `--permanent`: valeur par défaut 86 400.
+  - si absent et binaire lancé avec `--permanent`: aucune expiration.
+
+### Réponses
+- 200 OK: `ApiResponse` (message de succès)
+- 400 Bad Request: `ApiResponse` (clé/ttl/valeur invalides)
+- 409 Conflict: `ApiResponse` (clé déjà existante)
+- 500 Internal Server Error: `ApiResponse`
+
+### Schéma JSON (ApiResponse)
+```json
+{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "title": "ApiResponse",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["message"],
+  "properties": {
+    "message": { "type": "string" }
+  }
+}
+```
+
+## GET /retrieve/:key
+## GET /health
+- Aucune donnée d'entrée.
+- Réponse 200 avec `ApiResponse` `{ "message": "ok" }`.
+
+- Paramètre de chemin: `key` (hex 64).
+- Objet réponse (succès): `RetrieveResponse`
+- Objet réponse (erreur): `ApiResponse`
+
+### Contraintes
+- `key` doit respecter `^[0-9a-fA-F]{64}$`.
+
+### Réponses
+- 200 OK: `RetrieveResponse`
+- 400 Bad Request: `ApiResponse` (clé invalide)
+- 404 Not Found: `ApiResponse` (clé inconnue)
+- 500 Internal Server Error: `ApiResponse`
+
+### Schéma JSON (RetrieveResponse)
+```json
+{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "title": "RetrieveResponse",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["key", "value"],
+  "properties": {
+    "key": {
+      "type": "string",
+      "description": "Clé hexadécimale 64 caractères.",
+      "pattern": "^[0-9a-fA-F]{64}$"
+    },
+    "value": {
+      "type": "string",
+      "description": "Valeur encodée en hexadécimal.",
+      "pattern": "^[0-9a-fA-F]+$"
+    }
+  }
+}
+```
+
+## Codes d'état et messages
+- Les messages d'erreur sont informatifs mais ne divulguent pas d'informations sensibles.
+- Les champs `message` sont destinés à l'humain; ne pas les parser côté client.
--- a/docs/sdk_storage/architecture.md
+++ b/docs/sdk_storage/architecture.md
@ -0,0 +1,13 @@
+# Architecture
+
+## Flux de Données
+
+- Entrées: requêtes HTTP `/store`, `/retrieve/:key`.
+- Traitements: validation clés/TTL, encodage hex, stockage FS hiérarchique, métadonnées TTL.
+- Sorties: réponses JSON normalisées.
+
+## Composants
+
+- Service `StorageService` (I/O disque, TTL, nettoyage).
+- Serveur HTTP Tide (routes, état partagé).
+- Nettoyage périodique (60s) basé sur fichiers `.meta`.
--- a/docs/sdk_storage/ci_docker_registry.md
+++ b/docs/sdk_storage/ci_docker_registry.md
@ -0,0 +1,11 @@
+# CI - Variables pour Registre Docker
+
+Le workflow `.gitea/workflows/docker.yml` requiert ces secrets:
+
+- `DOCKER_REGISTRY`: registre cible (ex: registry.git.4nkweb.com/4nk)
+- `DOCKER_USERNAME`: utilisateur du registre
+- `DOCKER_PASSWORD`: mot de passe/token
+
+Configurer ces secrets dans les paramètres du dépôt (ou de l’organisation) côté Gitea.
+
+La cible d’image est `DOCKER_REGISTRY/sdk_storage:latest` (et multi-arch si activé).
--- a/docs/sdk_storage/configuration.md
+++ b/docs/sdk_storage/configuration.md
@ -0,0 +1,8 @@
+# Configuration
+
+## Services Disponibles
+- HTTP sur port 8081
+
+## Variables d'Environnement
+- `RUST_LOG` (optionnel): niveau de logs.
+- Pour Docker, monter `/app/storage` si persistance souhaitée.
--- a/docs/sdk_storage/demarrage_rapide.md
+++ b/docs/sdk_storage/demarrage_rapide.md
@ -0,0 +1,15 @@
+# Démarrage Rapide
+
+## Prérequis
+- Rust stable et Cargo
+- Optionnel: Docker
+
+## Installation
+- `cargo build`
+
+## Lancement
+- `cargo run -- --permanent`
+
+## Docker (optionnel)
+- Build: `docker build -t sdk_storage:local .`
+- Run: `docker run --rm -p 8081:8081 -v $PWD/storage:/app/storage sdk_storage:local`
--- a/docs/sdk_storage/depannage.md
+++ b/docs/sdk_storage/depannage.md
@ -0,0 +1,12 @@
+# Dépannage
+
+## Problèmes Courants
+1. Ports déjà utilisés: changer le port de publication Docker.
+2. Permissions storage: vérifier l'UID/GID et droits du volume.
+3. Clés invalides: s'assurer d'un hex 64 caractères.
+
+## Logs détaillés
+- Exécuter avec `RUST_LOG=info`.
+
+## Healthchecks
+- Ajouter une route `/health` (évolution possible) ou ping sur `/retrieve` avec clé connue.
--- a/docs/sdk_storage/developpement.md
+++ b/docs/sdk_storage/developpement.md
@ -0,0 +1,13 @@
+# Développement
+
+## Structure du Projet
+- `src/lib.rs`: service métier
+- `src/main.rs`: serveur HTTP Tide
+- `tests/`: scénarios d'intégration
+
+## Ajout d'un Nouveau Service
+- Créer une abstraction dédiée dans `src/lib.rs` ou module séparé.
+- Câbler dans `main.rs` via `tide::with_state` si nécessaire.
+
+## Modification de la Configuration
+- Mettre à jour `docs/configuration.md` et secrets CI/CD.
--- a/docs/sdk_storage/guides_principaux.md
+++ b/docs/sdk_storage/guides_principaux.md
@ -0,0 +1,5 @@
+# Guides Principaux
+
+- Concepts de base: clés hex 64, valeurs hex, TTL en secondes.
+- API: `/store` (POST), `/retrieve/:key` (GET).
+- Persistance: système de fichiers, sous-dossiers par préfixe de clé.
--- a/docs/sdk_storage/guides_techniques.md
+++ b/docs/sdk_storage/guides_techniques.md
@ -0,0 +1,6 @@
+# Guides Techniques
+
+- `StorageService`: abstraction des opérations de stockage.
+- TTL: sérialisé dans `*.meta` (UNIX timestamp secondes).
+- Nettoyage: parcours des dossiers, suppression données expirées.
+- Journalisation: sorties standard, intégration possible avec superviseur.
--- a/docs/sdk_storage/guides_test.md
+++ b/docs/sdk_storage/guides_test.md
@ -0,0 +1,5 @@
+# Guides de Test
+
+- Tests unitaires recommandés sur `StorageService` via répertoires temporaires.
+- Tests d'intégration HTTP optionnels via client HTTP.
+- Stratégies: cas TTL min/max, clés invalides, conflits de clé.
--- a/docs/sdk_storage/performance.md
+++ b/docs/sdk_storage/performance.md
@ -0,0 +1,9 @@
+# Performance
+
+## Ressources Recommandées
+- Disque rapide si grand volume d'écritures.
+- Mémoire suffisante pour buffers I/O.
+
+## Optimisations
+- Paramétrer la taille des blocs et la stratégie de fsync selon contraintes.
+- Éviter les collisions de clés, supervision du cleanup TTL.
--- a/docs/sdk_storage/release_guide.md
+++ b/docs/sdk_storage/release_guide.md
@ -0,0 +1,21 @@
+# Guide de Release
+
+## Préparation
+- S’assurer que la suite `cargo test` est verte.
+- Mettre à jour `CHANGELOG.md` avec la version cible.
+
+## Tagging
+- Créer un tag annoté: `git tag -a vX.Y.Z -m 'vX.Y.Z'`
+- Pousser le tag: `git push origin vX.Y.Z`
+
+## CI
+- Build binaire (workflow release) déclenché sur tag `v*.*.*`.
+- Build/push image Docker via workflow `docker.yml` (variables `DOCKER_*` requises).
+
+## Assets
+- Binaires disponibles via artefacts CI.
+- Images Docker taggées `latest` (et potentiellement `vX.Y.Z` selon configuration).
+
+## Post-release
+- Mettre à jour la documentation si nécessaire.
+- Ouvrir une issue pour les améliorations/retours.
--- a/docs/sdk_storage/reseau_de_relais.md
+++ b/docs/sdk_storage/reseau_de_relais.md
@ -0,0 +1,10 @@
+# Réseau de Relais
+
+## Architecture Mesh
+- À définir selon déploiement.
+
+## Ajout de Nœuds Externes
+- Procédure à documenter si nécessaire.
+
+## Configuration Externe
+- Ports, sécurité, endpoints à exposer.
--- a/docs/sdk_storage/tests_monitoring.md
+++ b/docs/sdk_storage/tests_monitoring.md
@ -0,0 +1,9 @@
+# Tests et Monitoring
+
+## Tests
+- Unitaires et intégration via `cargo test`.
+
+## Monitoring
+- Healthcheck HTTP: endpoint `/health` retourne `{ "message": "ok" }` et code 200.
+- Exposer métriques avec un reverse proxy/sidecar si nécessaire.
+- Configurer l'orchestrateur pour vérifier périodiquement `/health`.
--- a/2
+++ b/2
@ -1 +1 @@
-Subproject commit 09c2d1f96915979ef21b233bd1535225f981a4c5
+Subproject commit b1be8e65ac578f7b2d9ef536ebdb1e4b864bcad7
--- a/2
+++ b/2
@ -1 +1 @@
-Subproject commit 573a3e49e5391c49ed8169711d14275fd5d70dad
+Subproject commit 91ed42e87923f749a54ceb8ebb39cfea325edc5c
--- a/scripts/lecoffre_node/README.md
+++ b/scripts/lecoffre_node/README.md
@ -1,236 +0,0 @@
-# Scripts LeCoffre Node
-
-Ce répertoire contient tous les scripts nécessaires au déploiement et à la gestion de l'architecture LeCoffre Node.
-
-## 🚀 Scripts de Déploiement
-
-### `start.sh`
-**Script principal de démarrage séquentiel**
- Lance tous les services dans l'ordre logique
- Affiche la progression détaillée en temps réel
- Compatible avec le réseau Bitcoin Signet
- Gestion des timeouts et erreurs
-
-```bash
-./scripts/start.sh
-```
-
-### `deploy-master.sh`
-**Déploiement de l'architecture autonome**
- Construit et lance le conteneur master
- Configure tous les ports et volumes
- Lance automatiquement les services
-
-```bash
-./scripts/deploy-master.sh
-```
-
-### `deploy-autonomous.sh`
-**Déploiement autonome complet**
- Déploiement sans intervention manuelle
- Configuration automatique de tous les services
-
-```bash
-./scripts/deploy-autonomous.sh
-```
-
-## 💾 Scripts de Gestion des Données
-
-### `backup-data.sh`
-**Sauvegarde des données critiques**
- Sauvegarde Bitcoin, BlindBit, SDK Storage, SDK Signer
- Création d'archives compressées
- Gestion des permissions
-
-```bash
-./scripts/backup-data.sh
-```
-
-### `restore-data.sh`
-**Restauration des données**
- Restaure depuis une sauvegarde
- Remplace les données existantes
- Confirmation de sécurité
-
-```bash
-./scripts/restore-data.sh <backup_name>
-```
-
-### `update-images.sh`
-**Mise à jour des images Docker**
- Sauvegarde automatique avant mise à jour
- Téléchargement des nouvelles images
- Protection des données
-
-```bash
-./scripts/update-images.sh
-```
-
-## 📊 Scripts de Monitoring
-
-### `collect-logs.sh`
-**Collecte des logs de tous les services**
- Collecte automatique ou par service
- Organisation par répertoires
- Timestamps sur les fichiers
-
-```bash
-# Tous les services
-./scripts/collect-logs.sh
-
-# Service spécifique
-./scripts/collect-logs.sh bitcoin-signet
-```
-
-### `test-monitoring.sh`
-**Tests des services de monitoring**
- Vérification Grafana, Loki, Promtail
- Tests de connectivité
- Validation des dashboards
-
-```bash
-./scripts/test-monitoring.sh
-```
-
-### `test-dashboards.sh`
-**Tests des dashboards Grafana**
- Vérification des dashboards
- Tests des données sources
- Validation des métriques
-
-```bash
-./scripts/test-dashboards.sh
-```
-
-## 🔧 Scripts de Configuration
-
-### `sync-configs.sh`
-**Synchronisation des configurations**
- Copie des configs vers les conteneurs
- Mise à jour des paramètres
- Redémarrage des services
-
-```bash
-./scripts/sync-configs.sh
-```
-
-### `sync-monitoring-config.sh`
-**Configuration du monitoring**
- Configuration Grafana
- Configuration Loki/Promtail
- Déploiement des dashboards
-
-```bash
-./scripts/sync-monitoring-config.sh
-```
-
-### `setup-logs.sh`
-**Configuration des logs**
- Création des répertoires de logs
- Configuration des permissions
- Setup des rotations
-
-```bash
-./scripts/setup-logs.sh
-```
-
-## 🛠️ Scripts de Maintenance
-
-### `fix_relay_funds.sh`
-**Correction des fonds du relay**
- Vérification des fonds
- Correction des problèmes
- Tests de connectivité
-
-```bash
-./scripts/fix_relay_funds.sh
-```
-
-### `optimize-relay-startup.sh`
-**Optimisation du démarrage du relay**
- Optimisation des paramètres
- Amélioration des performances
- Tests de stabilité
-
-```bash
-./scripts/optimize-relay-startup.sh
-```
-
-### `verify_mining_fix.sh`
-**Vérification du minage**
- Tests du minage Signet
- Vérification des blocs
- Validation des transactions
-
-```bash
-./scripts/verify_mining_fix.sh
-```
-
-## 🔒 Scripts de Sécurité
-
-### `generate-ssl-certs.sh`
-**Génération des certificats SSL**
- Création des certificats
- Configuration HTTPS
- Sécurisation des communications
-
-```bash
-./scripts/generate-ssl-certs.sh
-```
-
-### `uninstall-host-nginx.sh`
-**Désinstallation de Nginx host**
- Nettoyage de Nginx
- Suppression des configurations
- Libération des ports
-
-```bash
-./scripts/uninstall-host-nginx.sh
-```
-
-## 📁 Structure des Volumes
-
-Les données sont persistées dans les volumes Docker suivants :
-
- `4nk_node_bitcoin_data` : Données Bitcoin Signet
- `4nk_node_blindbit_data` : Données BlindBit Oracle
- `4nk_node_sdk_data` : Données SDK Relay
- `4nk_node_sdk_storage_data` : Données SDK Storage
- `4nk_node_grafana_data` : Données Grafana
- `4nk_node_loki_data` : Données Loki
-
-## 🔄 Workflow de Déploiement
-
-1. **Déploiement initial** : `./scripts/deploy-master.sh`
-2. **Démarrage des services** : `./scripts/start.sh`
-3. **Vérification** : `./scripts/test-monitoring.sh`
-4. **Sauvegarde** : `./scripts/backup-data.sh`
-
-## 🔄 Workflow de Mise à Jour
-
-1. **Sauvegarde** : `./scripts/backup-data.sh`
-2. **Mise à jour** : `./scripts/update-images.sh`
-3. **Redémarrage** : `./scripts/start.sh`
-4. **Vérification** : `./scripts/test-monitoring.sh`
-
-## 🆘 Récupération d'Urgence
-
-En cas de problème :
-
-1. **Arrêt des services** : `docker compose down`
-2. **Restauration** : `./scripts/restore-data.sh <backup>`
-3. **Redémarrage** : `./scripts/start.sh`
-
-## 📝 Logs et Debugging
-
- **Logs des services** : `./logs/<service>/`
- **Collecte des logs** : `./scripts/collect-logs.sh`
- **Monitoring** : Grafana sur port 3005
- **Status API** : Port 3006
-
-## ⚠️ Notes Importantes
-
- Tous les scripts préservent les données importantes
- Les sauvegardes sont automatiques lors des mises à jour
- Le réseau Bitcoin Signet est utilisé par défaut
- Les volumes Docker garantissent la persistance des données
--- a/scripts/push-ext-commit.sh
+++ b/scripts/push-ext-commit.sh
@ -13,44 +13,71 @@ git submodule init >/dev/null 2>&1 || true
 git submodule foreach --recursive '
  set -e
  echo "[submodule] Enter: $name ($path)"
-  git fetch origin ext || true
-  if ! git rev-parse --verify ext >/dev/null 2>&1; then
-    if git show-ref --verify --quiet refs/remotes/origin/ext; then
+  # Ensure remote exists
+  git remote show origin >/dev/null 2>&1 || { echo "[submodule] missing origin remote"; exit 0; }
+  git config pull.rebase true || true
+  git fetch --prune origin +refs/heads/*:refs/remotes/origin/* || true
+  # Ensure local ext tracking origin/ext when available
+  if git show-ref --verify --quiet refs/remotes/origin/ext; then
+    if git rev-parse --verify ext >/dev/null 2>&1; then
+      git switch ext
+      git branch --set-upstream-to=origin/ext ext || true
+    else
      git switch -C ext origin/ext
+    fi
+  else
+    # Fallback: create ext if missing on remote
+    if git rev-parse --verify ext >/dev/null 2>&1; then
+      git switch ext
    else
      git switch -C ext
    fi
-  else
-    git switch ext
  fi
-  git pull --ff-only || true
+  # Rebase on remote if present to avoid non-fast-forward
+  git fetch origin ext || true
+  git rev-parse --verify origin/ext >/dev/null 2>&1 && git pull --rebase --autostash origin ext || true
+  # Stage and commit if needed
  git add -A
  if ! git diff --cached --quiet; then
    git commit -m "auto_clea"
-    git push -u origin ext || true
-  else
-    echo "[submodule] No changes to commit"
+  fi
+  # Push with upstream set; handle non-FF by one-time rebase+retry
+  if ! git push -u origin ext; then
+    echo "[submodule] push failed, retrying after rebase"
+    git fetch origin ext || true
+    git pull --rebase --autostash origin ext || true
+    git push -u origin ext || echo "[submodule] push still failing for $name"
  fi
 '

 echo "[root] Process root repository"
-git fetch origin ext || true
-if ! git rev-parse --verify ext >/dev/null 2>&1; then
-  if git show-ref --verify --quiet refs/remotes/origin/ext; then
+git config pull.rebase true || true
+git fetch --prune origin +refs/heads/*:refs/remotes/origin/* || true
+if git show-ref --verify --quiet refs/remotes/origin/ext; then
+  if git rev-parse --verify ext >/dev/null 2>&1; then
+    git switch ext
+    git branch --set-upstream-to=origin/ext ext || true
+  else
    git switch -C ext origin/ext
+  fi
+else
+  if git rev-parse --verify ext >/dev/null 2>&1; then
+    git switch ext
  else
    git switch -C ext
  fi
-else
-  git switch ext
 fi
-git pull --ff-only || true
+git fetch origin ext || true
+git rev-parse --verify origin/ext >/dev/null 2>&1 && git pull --rebase --autostash origin ext || true
 git add -A
 if ! git diff --cached --quiet; then
  git commit -m "auto_clea"
-  git push -u origin ext
-else
-  echo "[root] No changes to commit"
+fi
+if ! git push -u origin ext; then
+  echo "[root] push failed, retrying after rebase"
+  git fetch origin ext || true
+  git pull --rebase --autostash origin ext || true
+  git push -u origin ext || echo "[root] push still failing"
 fi

 echo "[push-ext-commit] Done."
--- a/2
+++ b/2
@ -1 +1 @@
-Subproject commit a20dbd2f9f0b51ea08529a3ab4b220b4a89b1535
+Subproject commit 0133e31bc4ebb0faf5536a388d25f7ba0c85c1c3
--- a/2
+++ b/2
@ -1 +1 @@
-Subproject commit bc9bd7b92a3da2a6efa3454997375dd611ca5dba
+Subproject commit 4dad51241c559f9895f3f986b5deea7484189e88