# Analyse Architecturale Complète - 4NK Environment **Date** : 2025-01-27 **Version** : 1.0 **Contexte** : Analyse complète de l'architecture 4NK et du projet LeCoffre ## 📋 Vue d'ensemble Cette analyse présente l'architecture complète de l'environnement 4NK, incluant tous les modules 4NK, le projet LeCoffre, et le système de gestion des configurations via 4NK_vault. ## 🏗️ Architecture Générale ### Environnement de Développement Centralisé ``` 4NK_env/ # Environnement centralisé ├── 4NK_modules/ # Modules 4NK (SDK, services) ├── projects/lecoffre/ # Projet LeCoffre (notaires) ├── IA_agents/ # Agents IA et documentation ├── docs/ # Documentation centralisée ├── scripts/ # Scripts de gestion centralisés └── confs/ # Configurations déployées (4NK_vault) ``` ## 🔧 Modules 4NK - Analyse Complète ### 1. **sdk_relay** - Service de Relais WebSocket **Rôle** : Relais central pour les communications WebSocket et la synchronisation mesh - **Port** : 8090 (WebSocket), 8091 (HTTP health) - **Fonctionnalités** : - Serveur WebSocket configurable - Synchronisation mesh entre relais - Gestion des processus et membres - Interface avec Bitcoin Core (RPC + ZMQ) - Intégration Blindbit pour Silent Payments - **Dépendances** : Bitcoin Core, Blindbit Oracle - **Architecture** : Rust avec gestion d'état locale ### 2. **sdk_storage** - Service de Stockage Temporaire **Rôle** : Stockage temporaire sécurisé avec TTL - **Port** : 8081 - **API** : - `POST /store` : Stockage avec clé/valeur/TTL - `GET /retrieve/:key` : Récupération des données - **Fonctionnalités** : - Stockage temporaire avec expiration - Clés hexadécimales 64 caractères - Valeurs hexadécimales - TTL optionnel (permanent si non spécifié) ### 3. **sdk_signer** - Service de Signature **Rôle** : Service de signature TypeScript pour l'écosystème 4NK - **Fonctionnalités** : - Gestion des processus et signatures - Communication sécurisée - Compatibilité WASM (stub temporaire) - Interface avec le réseau de relais - **Architecture** : TypeScript avec support WASM - **État** : Compatible avec stub sdk_client ### 4. **sdk_client** - Client SDK **Rôle** : Client SDK pour l'interaction avec l'écosystème 4NK - **Fonctionnalités** : - Interface avec les services 4NK - Gestion des connexions WebSocket - Support des processus et transactions - **Architecture** : Rust avec interface WebAssembly ### 5. **sdk_common** - Composants Communs **Rôle** : Bibliothèque commune partagée entre tous les modules - **Fonctionnalités** : - Types et structures communes - Utilitaires partagés - Protocoles de communication - **Usage** : Importé par tous les autres modules ### 6. **sdk-signer-client** - Client Signeur **Rôle** : Client pour l'interaction avec le service de signature - **Fonctionnalités** : - Interface avec sdk_signer - Gestion des signatures - Communication sécurisée ### 7. **ihm_client** - Interface Homme-Machine **Rôle** : Interface utilisateur pour la gestion des clés et processus - **Port** : 3003 - **Fonctionnalités** : - Interface de gestion des clés Bitcoin - Gestion des processus - Interface utilisateur web - **Dépendances** : sdk_relay, sdk_storage ### 8. **4NK_vault** - Système de Gestion des Configurations **Rôle** : API sécurisée pour la gestion centralisée des configurations - **Port** : 6666 (HTTPS) - **Fonctionnalités** : - Authentification par clés utilisateur - Chiffrement quantique résistant (ChaCha20-Poly1305) - Rotation automatique des clés - Résolution des variables d'environnement - Isolation par environnement (dev, prod) - **Sécurité** : - HTTPS obligatoire - Authentification par ID utilisateur - Clés individuelles par utilisateur/environnement - Rotation automatique (toutes les heures) - **Déploiement** : Synchronise les configurations vers `confs/` dans le docker de contrôle ### 9. **4NK_certificator** - Service d'Ancrage Cryptographique **Rôle** : Ancrage périodique sur Bitcoin mainnet des empreintes des échanges - **Fonctionnalités** : - Surveillance des messages du relay 4NK - Détection des paiements Bitcoin - Enregistrement périodique sur blockchain - Métriques de volume de données - **Architecture** : Rust avec base de données SQLite - **État** : MVP complet implémenté ### 10. **4NK_miner** - Service de Minage **Rôle** : Service de minage Bitcoin (développement/test) - **Fonctionnalités** : - Minage sur réseau Signet - Génération de blocs de test - Interface avec le réseau Bitcoin ### 11. **4NK_web_status** - Service de Statut **Rôle** : Service de monitoring et statut des services - **Fonctionnalités** : - Monitoring des services - Interface de statut - Métriques de santé ### 12. **blindbit-oracle** - Oracle Bitcoin **Rôle** : Service pour les paiements silencieux (Silent Payments) - **Port** : 8000 - **Fonctionnalités** : - Génération d'adresses Silent Payments - Validation des transactions - Interface HTTP REST - **Dépendances** : Bitcoin Core ### 13. **rust-silentpayments** - Implémentation Silent Payments **Rôle** : Implémentation Rust des Silent Payments - **Fonctionnalités** : - Génération d'adresses Silent Payments - Validation des transactions - Utilitaires cryptographiques ## 🏢 Projet LeCoffre - Architecture Notariale ### Contexte Métier Le projet LeCoffre est une plateforme de gestion de documents sécurisée pour les notaires, utilisant l'infrastructure 4NK pour la sécurité et l'intégrité des documents. ### Composants du Projet LeCoffre #### 1. **lecoffre_node** - Orchestrateur Principal **Rôle** : Docker de contrôle et déploiement pour LeCoffre - **Architecture** : Docker Compose avec Nginx intégré - **Services déployés** : - lecoffre-front (interface utilisateur) - ihm_client (gestion des clés) - sdk_relay (relais WebSocket) - sdk_storage (stockage temporaire) - bitcoin-signet (nœud Bitcoin) - blindbit-oracle (oracle Bitcoin) - tor-proxy (proxy anonyme) - Services de monitoring (Grafana, Loki, Promtail) - **Configuration** : Centralisée dans `confs/` (synchronisée depuis 4NK_vault) - **Déploiement** : Scripts automatisés avec phases de démarrage #### 2. **lecoffre-front** - Interface Utilisateur **Rôle** : Frontend Next.js pour l'application LeCoffre - **Technologie** : Next.js avec React - **Fonctionnalités** : - Interface utilisateur pour les notaires - Gestion des documents - Intégration avec l'écosystème 4NK - **Déploiement** : Conteneur Docker sur port 3004 #### 3. **lecoffre-back-mini** - Backend Centralisé **Rôle** : Backend centralisé pour les besoins spécifiques des notaires - **Fonctionnalités** : - APIs avec Stripe (paiements) - Intégration Mailchimp (email marketing) - Intégration OVH (SMS) - Intégration IdNot (HMR dev3 ↔ dev4 via OAuth2) - **Déploiement** : Sur dev3.4nkweb.com - **Architecture** : Service centralisé indépendant ## 🌐 Architecture de Déploiement ### Environnements - **dev4.4nkweb.com** : Machine principale (LeCoffre) - **dev3.4nkweb.com** : Nœud de bootstrap (signer centralisé, mini back) ### URLs et Services - **LeCoffre Front** : https://dev4.4nkweb.com/lecoffre - **4NK iframe** : https://dev4.4nkweb.com - **Signer centralisé** : dev3.4nkweb.com (module 4NK pour notaires) - **Mini back** : dev3.4nkweb.com (APIs Stripe, Mailchimp, OVH, IdNot) ### Architecture de Déploiement par Phases #### Phase 1: Services de Base (Parallèle) - tor, sdk_storage, status-api #### Phase 2: Services Blockchain (Séquentiel) - bitcoin → blindbit → sdk_relay #### Phase 3: Services Applicatifs (Séquentiel) - lecoffre-front, ihm_client #### Phase 4: Services de Monitoring (Indépendant) - loki → promtail → grafana #### Phase 5: Services Utilitaires - watchtower ## 🔐 Sécurité et Configuration ### 4NK_vault - Gestion Centralisée des Configurations - **Rôle** : API sécurisée pour la gestion des configurations - **Sécurité** : Chiffrement quantique résistant, authentification par clés - **Déploiement** : Synchronise vers `confs/` dans le docker de contrôle - **Isolation** : Variables d'environnement protégées, fichiers .env inaccessibles ### Protection des Secrets - **Fichiers .env** : Inaccessibles pour des raisons de sécurité - **Variables** : Séparées des secrets, remplacées dans storage/ - **Configurations** : Copie déployée dans confs/ pour visualisation ## 🤖 Agents IA - Organisation ### Structure IA_agents/ - **README.md** : Documentation principale et règles obligatoires - **deployment-architecture.md** : Architecture de déploiement par phases - **best-practices-deployment.md** : Bonnes pratiques et interdictions - **prompts/** : Prompts spécialisés pour différents aspects - **todo.md** : Liste des améliorations et optimisations ### Règles Critiques pour les Agents IA 1. **Interdictions absolues** : Pas de `docker compose up -d` direct 2. **Scripts obligatoires** : Utilisation des scripts spécialisés 3. **Phases respectées** : Ordre de démarrage par phases 4. **Monitoring indépendant** : Services de monitoring séparés 5. **Surveillance continue** : Suivi de progression obligatoire ## 📊 Monitoring et Observabilité ### Stack de Monitoring - **Grafana** : Dashboards et visualisation - **Loki** : Collecte et stockage des logs - **Promtail** : Agent de collecte des logs - **Watchtower** : Mise à jour automatique des images ### Dashboards Disponibles - Vue d'ensemble LeCoffre - Bitcoin & Miner - Services Applications - SDK Services - Frontend Services ## 🔄 CI/CD et Déploiement ### Branches et Tags - **Branche unifiée** : `ext` pour tous les dépôts - **Tag Docker** : `ext` pour toutes les images - **Déclenchement** : Push sur `ext` → Build automatique ### Scripts de Déploiement - **start.sh** : Démarrage complet avec phases - **validate-deployment.sh** : Validation du déploiement - **maintenance.sh** : Menu de maintenance interactif - **backup-data.sh** : Sauvegarde des données - **update-images.sh** : Mise à jour sécurisée ## 📚 Documentation Centralisée ### Structure docs/ - **Architecture** : Spécifications techniques - **Déploiement** : Guides de déploiement - **Services** : Documentation par service - **Scripts** : Documentation des scripts ### Mise à Jour Continue - **IA_agents/** : Documentation pour les agents IA - **docs/** : Documentation technique centralisée - **Alignement** : Synchronisation entre code et documentation ## 🎯 Points Clés de l'Architecture ### 1. **Séparation des Responsabilités** - Services applicatifs indépendants du monitoring - Monitoring observant sans impacter - Dépendances uniquement métier ### 2. **Sécurité Multi-Niveaux** - 4NK_vault pour la gestion centralisée des configurations - Chiffrement quantique résistant - Isolation des secrets et variables ### 3. **Déploiement Optimisé** - Phases de démarrage respectées - Scripts spécialisés obligatoires - Surveillance continue et diagnostic facilité ### 4. **Maintenance Facilitée** - Redémarrage sélectif possible - Scripts de maintenance interactifs - Documentation centralisée et à jour --- **Document créé le 2025-01-27** **Version** : 1.0 **Usage** : Documentation architecturale complète pour les agents IA et l'équipe de développement