Architecture du Système Genesis
Cette page présente une vue d'ensemble approfondie de l'architecture du système Genesis AI, de ses composants interconnectés et des principes de conception qui guident son développement.
🏛️ Vue d'ensemble Architecturale
Genesis AI suit une architecture distribuée en couches où chaque projet joue un rôle spécifique dans le flux de traitement des requêtes AI et de l'orchestration de workflows.
Principes Architecturaux Fondamentaux
- Séparation des préoccupations : Chaque projet a une responsabilité unique et bien définie
- Couplage lâche : Les projets communiquent via des protocoles standardisés (A2A, gRPC, REST)
- Exécution durable : Tous les workflows critiques sont persistés et reprenables
- Zero-Knowledge : Les données sensibles restent chiffrées de bout en bout
- Local-First : Priorité à l'exécution locale avec synchronisation cloud optionnelle
🗺️ Carte des Projets
📐 Diagrammes par Projet
1. igon7 Engine - Architecture DAG
Flux de traitement :
- L'utilisateur définit un workflow DAG
- Le DAG Builder valide et optimise le graphe
- Le Core Engine orchestre l'exécution via Temporal
- Le Monitoring tracke la progression et les erreurs
2. Genesis Nexus - Protocole A2A
Fonctionnement du routage neural :
- La requête utilisateur est analysée sémantiquement
- Le Neural Router identifie les agents compétents
- Les messages sont routés via A2A Protocol
- Les réponses sont agrégées et retournées
3. Clisis Agent - Guardian Layer
Flux de sécurité :
- Chaque requête système passe par le Guardian Layer
- Validation des permissions et du contexte
- Audit de sécurité avant exécution
- Exécution dans un environnement sandboxé
4. Genesis Temporal - CHASM Layer
Cycle de vie d'un workflow :
- Frontend reçoit la requête de démarrage
- History crée l'état initial et l'event log
- Matching queue les tâches pour les workers
- Worker exécute et rapporte la complétion
- CHASM coordonne les machines à états multiples
5. Cloud API - Zero-Knowledge Sync
Flux de synchronisation :
- Les données sont chiffrées côté client avant envoi
- Cloud API stocke les données chiffrées sans les déchiffrer
- La synchronisation push notifie les autres appareils
- Chaque appareil déchiffre localement avec ses clés
🔄 Flux de Données Complets
Scénario : Exécution d'un Workflow AI
🛡️ Architecture de Sécurité
Modèle de Confiance Zéro
Détail des Couches
| Couche | Mécanisme | Protection |
|---|---|---|
| L1 | JWT + MFA | Authentification forte des utilisateurs |
| L2 | RBAC | Contrôle d'accès basé sur les rôles |
| L3 | Guardian | Validation contextuelle des requêtes |
| L4 | Sandbox | Isolation des processus agents |
| L5 | E2EE | Chiffrement des données sensibles |
📊 Stratégies de Scaling
Scaling Horizontal
Points de Scaling
- Nexus : Partitionnement par namespace d'agents
- Temporal : Augmentation des shards (défaut: 4, max: 128+)
- Cloud API : Réplication PostgreSQL + read replicas
- igon7 : Workers distribués sur plusieurs noeuds
🔧 Points d'Intégration
APIs Exposées
| Projet | API | Protocole | Port |
|---|---|---|---|
| Nexus | A2A Protocol | WebSocket/gRPC | 8080/9090 |
| Temporal | Workflow API | gRPC/HTTP | 7233/7243 |
| Cloud API | REST API | HTTPS | 3000 |
| Marketplace | Blockchain RPC | JSON-RPC | 8545 |
| Desktop | IPC Local | Unix Socket/Named Pipe | - |
SDK Disponibles
- TypeScript SDK : Généré depuis OpenAPI (Cloud API)
- Go SDK : Temporal client natif
- Deno SDK : Wrapper pour A2A Protocol
- Python SDK : En développement
🎯 Décisions Architecturales Clés
1. Pourquoi Deno pour igon7 et Nexus ?
- Sécurité native : Permissions explicites (fs, net, env)
- TypeScript first : Typage fort sans configuration
- Module URL : Imports directs depuis CDN
- Runtime moderne : Top-level await, ES modules
2. Pourquoi Go pour Temporal ?
- Performance : Compilation native, goroutines légères
- Écosystème Temporal : Serveur de référence en Go
- Concurrency : Modèle CSP idéal pour workflows
- Stabilité : ABI stable, déploiement simple
3. Pourquoi NestJS pour Cloud API ?
- Architecture modulaire : Injection de dépendances
- TypeScript : Typage end-to-end
- Écosystème : Guards, interceptors, pipes intégrés
- Scalabilité : Utilisable avec microservices
4. Pourquoi Electron pour Desktop ?
- Cross-platform : Code unique pour Windows/macOS/Linux
- Intégration Nexus : Embedding direct du runtime Deno
- UI riche : React + Vite pour performances
- IPC sécurisé : Isolation main/renderer processes