auto_clea

2025-09-25 15:25:00 +00:00 · 2025-09-25 15:25:00 +00:00 · 91ed42e879
commit 91ed42e879
parent 573a3e49e5
19 changed files with 3 additions and 1012 deletions
--- a/README.md
+++ b/README.md
@ -36,3 +36,6 @@ You can check out [the Next.js GitHub repository](https://github.com/vercel/next
 The easiest way to deploy your Next.js app is to use the [Vercel Platform](https://vercel.com/new?utm_medium=default-template&filter=next.js&utm_source=create-next-app&utm_campaign=create-next-app-readme) from the creators of Next.js.
 Check out our [Next.js deployment documentation](https://nextjs.org/docs/deployment) for more details.
 ### Documentation centralisée
 - Les documents de ce projet sont centralisés dans: `/home/debian/4NK_env/docs/lecoffre-front/`
--- a/docs/ARCHITECTURE.md
+++ b/docs/ARCHITECTURE.md
@ -1,21 +0,0 @@
 # 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/CORRECTIONS_APPLIQUEES.md
+++ b/docs/CORRECTIONS_APPLIQUEES.md
@ -1,38 +0,0 @@
 # 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/DEPLOIEMENT.md
+++ b/docs/DEPLOIEMENT.md
@ -1,20 +0,0 @@
 # 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/DEPLOYMENT_FIXES_2025-09-24.md
+++ b/docs/DEPLOYMENT_FIXES_2025-09-24.md
@ -1,81 +0,0 @@
 # 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/ENV-RESUME.md
+++ b/docs/ENV-RESUME.md
@ -1,30 +0,0 @@
 ## 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/FLUX.md
+++ b/docs/FLUX.md
@ -1,6 +0,0 @@
 # 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/FONCTIONNEL.md
+++ b/docs/FONCTIONNEL.md
@ -1,15 +0,0 @@
 # 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/HMR_IDNOT_STATE.md
+++ b/docs/HMR_IDNOT_STATE.md
@ -1,43 +0,0 @@
 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/INSTALLATION.md
+++ b/docs/INSTALLATION.md
@ -1,26 +0,0 @@
 # 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/PORTS.md
+++ b/docs/PORTS.md
@ -1,27 +0,0 @@
 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/QUALITE.md
+++ b/docs/QUALITE.md
@ -1,6 +0,0 @@
 # 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/RESUME-ANALYSE.md
+++ b/docs/RESUME-ANALYSE.md
@ -1,159 +0,0 @@
 # 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/SECURITE.md
+++ b/docs/SECURITE.md
@ -1,6 +0,0 @@
 # 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/TECHNIQUE.md
+++ b/docs/TECHNIQUE.md
@ -1,19 +0,0 @@
 # 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/TODO.md
+++ b/docs/TODO.md
@ -1,6 +0,0 @@
 # TODO - LeCoffre Front
 - Vérifier URLs backend et iframe IHM.
 - Tester parcours IdNot.
 - Valider variables `NEXT_PUBLIC_*`.
 - Vérifier dashboards Grafana Frontend.
--- a/docs/VARIABLES-ENVIRONNEMENT.md
+++ b/docs/VARIABLES-ENVIRONNEMENT.md
@ -1,336 +0,0 @@
 # 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/ci.md
+++ b/docs/ci.md
@ -1,115 +0,0 @@
 ### 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/ext.md
+++ b/docs/ext.md
@ -1,58 +0,0 @@
 ### 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.