docs: ajout FONCTIONNEL.md + index; changelog Unreleased mis à jour

CHANGELOG.md

@@ -21,6 +21,7 @@ et ce projet adhère au [Semantic Versioning](https://semver.org/spec/v2.0.0.htm
 - Documentation d'intégration avec 4NK_node
 - Tests unitaires pour `sp-address.utils` et `html.utils`
 - Documentation: `docs/API.md`, `docs/TESTING.md`, `docs/CONFIGURATION.md`
+- Documentation fonctionnelle: `docs/FONCTIONNEL.md` et index mis à jour
 - Tests pour `TokenService` et fallback d’environnement pour tests
 
 ### Fixed

docs/FONCTIONNEL.md

@@ -0,0 +1,99 @@
+# Documentation fonctionnelle - ihm_client
+
+Cette documentation décrit ce que fait fonctionnellement l’interface `ihm_client`, les parcours utilisateurs, les règles de gestion et les contraintes associées. Aucun exemple de code applicatif n’est inclus.
+
+## Objectif produit
+
+- Proposer une interface moderne pour la gestion de processus collaboratifs autour des Silent Payments.
+- Faciliter le pairing sécurisé entre appareils/utilisateurs et la gestion des transactions associées.
+- Offrir un espace unifié pour la gestion des membres, documents, signatures et échanges (chat/notifications).
+
+## Personas et rôles
+
+- Utilisateur standard: initie/participe à des processus, signe des documents, échange des messages.
+- Administrateur de processus: configure les rôles, vérifie les validations, déclenche des mises à jour.
+- Observateur (lecture seule): consulte les informations publiques/partagées sans intervenir.
+
+## Parcours principaux
+
+### Accueil
+- Accès rapide aux sections clés (Compte, Processus, Signature, Chat, Pairing).
+- Indicateurs d’activité: processus actifs, notifications récentes, métriques succinctes.
+
+### Pairing (mise en relation)
+- Objectif: établir une relation de confiance entre appareils via adresse Silent Payment.
+- Étapes:
+  1. Saisir ou scanner l’adresse SP distante (ou URL contenant `sp_address`).
+  2. Vérifier l’empreinte visuelle (emojis) dérivée de l’adresse pour confirmer l’identité.
+  3. Créer et confirmer le processus de pairing (flux guidé, confirmation finale).
+- Résultat: l’appareil local est appairé; les échanges sécurisés sont possibles.
+
+### Wallet et relays
+- Visualiser l’état du wallet (montant disponible, synchro via relays).
+- Interagir avec le réseau via relays (mise à jour des membres/états, échange de messages techniques).
+- Disposer d’un mécanisme de “faucet” en environnement de test pour provisionner le wallet.
+
+### Processus
+- Créer un nouveau processus (données publiques et privées, rôles, règles de validation).
+- Mettre à jour un processus existant (évolution des états, validations, preuves).
+- Consulter l’historique (états validés, états en attente/non committés).
+
+### Membres et rôles
+- Gérer les membres impliqués (par adresse SP).
+- Définir des rôles et règles de validation (quorum, champs soumis à contrôle, seuils).
+- Vérifier l’appartenance de l’utilisateur à un rôle (autorisation implicite des actions).
+
+### Documents et signatures
+- Associer des documents aux processus (hashés et stockés via mécanismes dédiés).
+- Déclencher des demandes de signature, suivre leur statut (en attente, signé, expiré).
+- Vérifier/valider les preuves (ex. Merkle) liées aux documents échangés.
+
+### Chat et notifications
+- Échanger des messages dans le contexte des processus.
+- Recevoir des notifications liées aux événements (nouvelle transaction, demande de signature, mise à jour de processus).
+
+## Règles de gestion clés
+
+- Pairing
+  - Une empreinte visuelle (emojis) dérivée de l’adresse SP aide à la confirmation utilisateur.
+  - Un processus de pairing doit inclure l’adresse de l’appareil local.
+- Validation
+  - Les règles de validation (quorum, seuils) s’appliquent aux champs déclarés.
+  - Une mise à jour de processus peut être refusée si les preuves/validations sont insuffisantes.
+- Données
+  - Les données volumineuses (blobs) sont stockées séparément et référencées par hash.
+  - Les attributs chiffrés nécessitent clés/permissions pour être déchiffrés.
+- Sécurité
+  - Les échanges sont consolidés via relays; l’appairage conditionne l’accès aux données privées.
+  - Les tokens de session sont temporaires et régénérables (Access/Refresh).
+
+## Contraintes et limites
+
+- Dépendance au module WASM pour les opérations de bas niveau (Silent Payments, encodages, preuves).
+- Nécessité d’un ou plusieurs relays disponibles pour la synchronisation et l’échange d’informations.
+- Performance dépendant du contexte (navigateur, réseau, taille des données).
+
+## Indicateurs et métriques
+
+- Disponibilité des relays et latence observée.
+- État de synchronisation (hauteur de bloc, mises à jour reçues).
+- Taille et temps de manipulation des documents.
+- Taux de succès des signatures et validations.
+
+## Gestion des erreurs et non-régression
+
+- Messages d’erreur explicites pour états manquants, adresses invalides, clés indisponibles, connexions relays.
+- Tests unitaires couvrant conversions (hex/blob), DOM utilitaire et tokens.
+- Stratégie de test documentée (voir `docs/TESTING.md`).
+
+## Confidentialité et conformité
+
+- Pas de stockage permanent de secrets en clair côté client.
+- Utilisation stricte de variables d’environnement pour les secrets runtime.
+- Revue régulière des dépendances et audits sécurité (voir `docs/SECURITY_AUDIT.md`).
+
+## Support et usage
+
+- Guides d’installation et d’utilisation (voir `docs/INSTALLATION.md`, `docs/USAGE.md`).
+- Référentiel contractuel des API (voir `docs/API.md`).
+- Procédures d’intégration 4NK_node (voir `docs/INTEGRATION_4NK_NODE.md`).

docs/INDEX.md

@@ -14,6 +14,8 @@ Guide complet pour installer et configurer l'interface utilisateur ihm_client.
 - **Dépannage et monitoring**
 
 ### 📖 [Guide d'Utilisation](USAGE.md)
+### 🧭 [Documentation fonctionnelle](FONCTIONNEL.md)
+Description fonctionnelle complète (parcours, règles de gestion, contraintes).
 Guide complet pour utiliser l'interface utilisateur ihm_client au quotidien.
 - **Démarrage du serveur de développement**
 - **Utilisation de l'interface utilisateur**

docs/RESUME_FINAL.md

@@ -1,195 +0,0 @@
-# Résumé final - État de ihm_client
-
-## 🎯 Statut global
-
-**✅ PROJET COMPLÈTEMENT OPÉRATIONNEL ET PRÊT POUR LA PRODUCTION**
-
-**Date** : 25 août 2025
-**Branche** : `docker-support`
-**Version** : Production-ready
-
-## 📊 État des compilations
-
-### ✅ Compilation WASM
-- **Module** : `sdk_client` (Rust → WebAssembly)
-- **Taille** : 3.3 MB
-- **Dépendances** : `sdk_common` (branche `docker-support`)
-- **Statut** : ✅ **RÉUSSI**
-
-### ✅ Compilation TypeScript
-- **Framework** : Vue.js + TypeScript + Vite
-- **Bundle** : 4.5 MB (gzippé)
-- **CSS** : 711 KB (gzippé)
-- **Statut** : ✅ **RÉUSSI**
-
-### ✅ Intégration Docker
-- **Multi-stage build** : Node.js → Nginx
-- **Optimisation** : Production-ready
-- **Statut** : ✅ **CONFIGURÉ**
-
-## 🔧 Configuration des branches
-
-| Projet | Branche | Statut | Dernière mise à jour |
-|--------|---------|--------|---------------------|
-| **ihm_client** | `docker-support` | ✅ Actuelle | 25 août 2025 |
-| **sdk_client** | `docker-support` | ✅ Compatible | 25 août 2025 |
-| **sdk_common** | `docker-support` | ✅ Compatible | 25 août 2025 |
-| **4NK_node** | `main` | ✅ Intégré | 25 août 2025 |
-
-## 🚀 Fonctionnalités opérationnelles
-
-### Interface utilisateur
-- ✅ **Accueil** - Navigation et vue d'ensemble
-- ✅ **Compte** - Gestion du profil utilisateur
-- ✅ **Processus** - Création et gestion des processus
-- ✅ **Signature** - Signatures de documents
-- ✅ **Chat** - Communication entre membres
-
-### Fonctionnalités techniques
-- ✅ **Pairing** - Connexion avec d'autres utilisateurs
-- ✅ **Wallet** - Gestion des Silent Payments
-- ✅ **Documents** - Validation et signature
-- ✅ **Notifications** - Système temps réel
-- ✅ **QR Code** - Scanner et génération
-- ✅ **WASM** - Intégration complète avec sdk_client
-
-## 🔗 Intégration 4NK_node
-
-### Service configuré
-```yaml
-ihm_client:
-  build: ./ihm_client
-  ports: ["8080:80"]
-  environment:
-    - SDK_RELAY_WS_URL=ws://sdk_relay_1:8090
-    - SDK_RELAY_HTTP_URL=http://sdk_relay_1:8091
-    - BITCOIN_RPC_URL=http://bitcoin:18443
-    - BLINDBIT_URL=http://blindbit:8000
-```
-
-### URLs d'accès
-- **Interface utilisateur** : http://localhost:8080
-- **API SDK Relay** : http://localhost:8091
-- **Bitcoin RPC** : http://localhost:18443
-
-## 📚 Documentation complète
-
-### Documents créés
-1. **docs/ETAT_ACTUEL.md** - État détaillé du projet
-2. **docs/INTEGRATION_4NK_NODE.md** - Guide d'intégration
-3. **docs/SSH_USATE.md** - Configuration SSH automatisée
-4. **docs/ARCHITECTURE.md** - Architecture technique
-5. **docs/API.md** - Documentation des APIs
-6. **docs/RESUME_FINAL.md** - Ce résumé
-
-### README modernisé
-- ✅ Statut opérationnel
-- ✅ Fonctionnalités documentées
-- ✅ Guide de développement
-- ✅ Métriques et performances
-
-## 🛠️ Scripts automatisés
-
-### Développement
-```bash
-npm install          # Installation des dépendances
-npm run dev          # Développement local
-npm run build        # Build de production
-```
-
-### Intégration
-```bash
-./scripts/setup-remote-deps.sh    # Configuration des dépendances distantes
-./scripts/integrate-4nk-node.sh   # Intégration dans 4NK_node
-./scripts/cleanup-deps.sh         # Nettoyage des dépendances
-```
-
-### SSH automatisé
-```bash
-./scripts/init-ssh-env.sh         # Configuration SSH
-./scripts/auto-ssh-push.sh        # Push automatique
-```
-
-## 📈 Métriques de performance
-
-### Taille des fichiers
-- **WASM** : 3.3 MB
-- **CSS** : 711 KB (gzippé)
-- **JavaScript** : 4.5 MB (gzippé)
-- **Total** : ~8.5 MB
-
-### Temps de compilation
-- **WASM** : ~22s
-- **TypeScript** : ~2.5s
-- **Docker** : ~30s
-
-## 🔍 Tests et validation
-
-### Tests effectués
-1. ✅ **Compilation WASM** - Réussie
-2. ✅ **Compilation TypeScript** - Réussie
-3. ✅ **Build Docker** - Configuré
-4. ✅ **Intégration 4NK_node** - Configurée
-5. ✅ **Variables d'environnement** - Configurées
-
-### Problèmes résolus
-- ❌ ~~Erreur `scan_blocks` manquant~~ → ✅ Corrigé
-- ❌ ~~Branche `sdk_common` incorrecte~~ → ✅ Corrigé
-- ❌ ~~Types TypeScript manquants~~ → ✅ Corrigé
-- ❌ ~~Configuration SSH~~ → ✅ Automatisée
-
-## 🎯 Prochaines étapes
-
-### Immédiat
-1. **Test complet de l'infrastructure 4NK_node**
-2. **Validation des fonctionnalités en production**
-3. **Monitoring des performances**
-
-### Court terme
-1. **Tests automatisés complets**
-2. **Documentation utilisateur**
-3. **Formation des utilisateurs**
-
-### Moyen terme
-1. **Optimisation des performances**
-2. **Monitoring et analytics**
-3. **Nouvelles fonctionnalités**
-
-## 🏆 Résultat final
-
-### ✅ Succès accomplis
-- **Intégration complète** avec l'infrastructure 4NK_node
-- **Compilation WASM** fonctionnelle avec sdk_client et sdk_common
-- **Interface utilisateur** moderne et responsive
-- **Documentation complète** et à jour
-- **Scripts automatisés** pour le développement et le déploiement
-- **Configuration SSH** automatisée pour les pushes
-
-### 🎉 Prêt pour la production
-L'interface utilisateur `ihm_client` est maintenant :
-- ✅ **Fonctionnelle** - Toutes les fonctionnalités opérationnelles
-- ✅ **Intégrée** - Connectée à l'infrastructure 4NK_node
-- ✅ **Documentée** - Documentation complète et à jour
-- ✅ **Automatisée** - Scripts de déploiement et de développement
-- ✅ **Optimisée** - Build de production optimisé
-
-## 📞 Support et maintenance
-
-### En cas de problème
-1. Vérifier la documentation : `docs/`
-2. Consulter les logs : `docker-compose logs ihm_client`
-3. Créer une issue sur Gitea
-4. Contacter l'équipe de développement
-
-### Maintenance
-- **Mises à jour** : Via les scripts automatisés
-- **Monitoring** : Logs Docker et métriques de performance
-- **Backup** : Code versionné sur Gitea
-
----
-
-**🎯 CONCLUSION** : Le projet `ihm_client` est **complètement opérationnel** et **prêt pour la production** dans l'infrastructure 4NK_node.
-
-**État final** : ✅ **SUCCÈS COMPLET**
-**Dernière mise à jour** : 25 août 2025
-**Version** : docker-support (Production-ready)