# 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`).
- Intégration dans un site via iframe (voir `docs/INTEGRATION_IFRAME.md`).