docs: normalisation titres H2 et mises à jour

docs/API.md

@@ -0,0 +1,16 @@
+## API
+
+### Portée
+- Contrats d’interface entre clients WebSocket et serveur sdk-signer.
+
+### Contrats d’interface
+- Enum MessageType: connexion, token, processus, merkle, device, erreurs.
+- Messages: porteurs d’un type, d’un messageId, et de champs spécifiques à l’opération.
+- Statuts: DeliveryStatus (PENDING, SENT, DELIVERED, FAILED, RETRY).
+- Priorités: MessagePriority (LOW, NORMAL, HIGH, CRITICAL).
+
+### Erreurs et statuts
+- Réponse de type ERROR en cas d’échec; gestion de timeouts côté serveur/clients.
+
+### Versionnage et compatibilité
+- Alignement strict avec sdk_signer_client pour les énumérations et structures.

docs/ARCHITECTURE.md

@@ -0,0 +1,30 @@
+## ARCHITECTURE
+
+### Contexte
+- Service serveur « sdk-signer » pour gérer des messages typés via WebSocket.
+- Fournit des opérations de processus, hashing/merkle, gestion de device et validation d’état.
+
+### Composants
+- src/index.ts: point d’entrée, exporte Service, Server, config, models et utilitaires.
+- src/simple-server.ts: serveur WebSocket simple (gestion des connections et du cycle de vie).
+- src/service.ts: logique métier des messages et routage par type.
+- src/relay-manager.ts: interaction avec le réseau de relais.
+- src/database.service.ts: persistance simple pour l’état serveur si nécessaire.
+- src/models.ts: énumérations et types de messages, priorités, statuts de livraison.
+- src/config.ts: configuration serveur (port, clés, délais, options).
+- src/utils.ts, src/wasm_compat.ts: utilitaires globaux et compatibilité WASM si utilisée.
+
+### Flux et dépendances
+- Client se connecte en WebSocket → message LISTENING → échanges de messages typés corrélés.
+- Gestion du messageId pour corrélation, priorités de traitement et statut de livraison.
+
+### Données et modèles
+- Typage via MessageType et statuts (DeliveryStatus), niveaux de priorité (MessagePriority).
+- Dérivation de contrats communs alignés avec le client (sdk_signer_client).
+
+### Sécurité
+- Clé API côté serveur (vérification attendue au niveau des messages entrants).
+- Logs d’erreurs et gestion de timeouts.
+
+### Observabilité
+- Journalisation des connexions, erreurs, et transitions d’état des processus.

docs/DEPLOYMENT.md

@@ -0,0 +1,20 @@
+## DEPLOYMENT
+
+### Docker
+- Image: sdk-signer:latest (build depuis Dockerfile)
+- Port: 9090 (exposé)
+- Commande: node dist/index.js
+- Volume: ./data monté sur /data
+
+### Intégration dans 4NK_node
+- Variable RELAY_URLS à pointer vers ws://sdk_relay_1:8090 (réseau partagé)
+- BASE: PORT=9090, DATABASE_PATH=/data/server.db, API_KEY défini côté env
+
+### CI/CD appliquée
+- Build multi-stage Node 20 alpine
+- Vérifier la génération de dist/ avant build image
+
+### Configuration
+- Variables: PORT, API_KEY, DATABASE_PATH, RELAY_URLS
+- Ports: 9090
+- Utilisateur: nodejs (non-root)

docs/USAGE.md

@@ -0,0 +1,16 @@
+## USAGE
+
+### Prérequis
+- Node.js et accès réseau aux clients WebSocket.
+- Variables: PORT, API_KEY, DATABASE_PATH, RELAY_URLS.
+
+### Démarrage
+- Construire le projet puis démarrer le serveur (dist/index.js) via Docker ou Node.
+
+### Opérations
+- Accepter les connexions WebSocket et traiter les messages typés.
+- Utiliser Service et Server pour router et gérer les opérations (processus, merkle, validation, notifications).
+
+### Dépannage
+- Vérifier les logs serveur pour les erreurs réseau ou de clé API.
+- Ajuster les timeouts et les politiques de reconnexion côté clients.