316 lines
11 KiB
Markdown
316 lines
11 KiB
Markdown
# 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
|