StillHammer
ba42b6d9c7
- Add hybrid deployment modes: local_dev (MVP) and production_pwa (optional) - Integrate WarFactory engine reuse with hot-reload 0.4ms - Define multi-target compilation strategy (DLL/SO/WASM) - Detail both deployment modes with cost analysis - Add progressive roadmap: Phase 1 (local), Phase 2 (POC WASM), Phase 3 (cloud) - Budget clarified: $10-20/mois (local) vs $13-25/mois (cloud) - Document open questions for technical validation 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
1165 lines
49 KiB
Markdown
1165 lines
49 KiB
Markdown
# Cahier des Charges - AISSIA (AI Smart Schedule & Interactive Assistant)
|
||
|
||
**Version:** 0.4 - Architecture Hybride Proposée
|
||
**Date:** 27 octobre 2025
|
||
**Auteur:** Alexis Trouvé
|
||
|
||
---
|
||
|
||
## 1. Contexte et Problématique
|
||
|
||
### 1.1 Besoin Utilisateur
|
||
Difficulté majeure dans la gestion du temps et des priorités, caractérisée par :
|
||
- **Hyperfocus** : Incapacité à stopper une tâche une fois démarrée (travail ou jeu vidéo)
|
||
- **Absence de limites claires** : Continuer jusqu'à épuisement physique ("body tell me I can't")
|
||
- **Multi-tâches impossibles** : Difficulté à gérer 2-3 activités différentes dans une journée
|
||
- **Régulation de l'attention défaillante** : Besoin d'un système externe pour gérer les transitions
|
||
|
||
### 1.2 Solution Proposée
|
||
Assistant personnel intelligent et proactif qui :
|
||
- Pense le planning en arrière-plan
|
||
- Intervient de manière proactive (pas seulement réactif)
|
||
- S'adapte aux patterns comportementaux de l'utilisateur
|
||
- Force les transitions quand nécessaire
|
||
|
||
---
|
||
|
||
## 2. Objectifs du Projet
|
||
|
||
### 2.1 Objectifs Fonctionnels
|
||
1. **Planning Intelligent** : IA qui organise automatiquement les tâches selon priorités et contraintes
|
||
2. **Assistant Proactif** : Détection d'hyperfocus et intervention automatique
|
||
3. **Tracking Automatique** : Suivi du temps passé sur chaque activité
|
||
4. **Interaction Naturelle** : Dialogue avec l'IA pour ajuster le planning en temps réel
|
||
5. **Notifications Intelligentes** : Rappels adaptatifs basés sur le contexte
|
||
|
||
### 2.2 Objectifs Techniques
|
||
- **Dev Windows-first** : Développement et debug 100% sur Windows avec WarFactory engine
|
||
- **Déploiement flexible** : Mode local (DLL) OU mode cloud (WASM + PWA) selon besoin
|
||
- **Hot-reload dev** : 0.4ms iteration en mode local (WarFactory)
|
||
- **Cross-platform automatique** : Deploy sur tous OS via Docker/WASM (sans effort dev)
|
||
- **Mobile optionnel** : PWA installable (Phase 2+, pas obligatoire MVP)
|
||
- **Offline-first** : Fonctionne en local (SQLite) ou avec sync cloud optionnel
|
||
- **Performance** : Native en local (DLL), quasi-native en WASM (~2x plus lent acceptable)
|
||
- **Privacy** : Mode local = données jamais uploadées, mode cloud = processing client-side
|
||
- **Coûts optimisés** : $0 en mode local, $3-5/mois en mode cloud (70% processing client)
|
||
|
||
### 2.3 Objectifs Business
|
||
- **Usage personnel** : Version pour usage propre en priorité
|
||
- **Commercialisation** : Potentiel de monétisation futur (Freemium)
|
||
- **Itérations courtes** : Cycles de développement de 1-2 semaines
|
||
- **Versions fonctionnelles** : Chaque itération doit produire une version utilisable
|
||
|
||
---
|
||
|
||
## 3. Fonctionnalités
|
||
|
||
### 3.1 MVP - Phase 1 (Semaines 1-2)
|
||
|
||
#### Gestion des Tâches
|
||
- ✅ Création/édition/suppression de tâches
|
||
- ✅ Priorités (Haute/Moyenne/Basse)
|
||
- ✅ Durée estimée
|
||
- ✅ Deadlines optionnelles
|
||
- ✅ Tags/catégories
|
||
|
||
#### Tracking du Temps
|
||
- ✅ Timer manuel (start/stop)
|
||
- ✅ Historique du temps passé par tâche
|
||
- ✅ Vue journalière/hebdomadaire
|
||
|
||
#### IA Basique
|
||
- ✅ Suggestions de planning pour la journée
|
||
- ✅ Réorganisation des tâches selon priorités
|
||
- ✅ Estimation durée réaliste basée sur historique
|
||
|
||
#### Notifications
|
||
- ✅ Rappels de début de tâche
|
||
- ✅ Alertes de fin de tâche planifiée
|
||
- ✅ Notifications push sur tous les appareils
|
||
|
||
#### Authentification
|
||
- ✅ Inscription/connexion email/password
|
||
- ✅ Synchronisation multi-appareils
|
||
|
||
### 3.2 Phase 2 - IA Proactive (Semaines 3-4)
|
||
|
||
#### Détection d'Hyperfocus
|
||
- ⏳ Analyse du temps passé vs temps planifié
|
||
- ⏳ Détection de patterns anormaux (>2h sans pause)
|
||
- ⏳ Alertes progressives (douce → insistante → forcée)
|
||
|
||
#### Assistant Conversationnel
|
||
- ⏳ Chat avec l'IA pour ajuster le planning
|
||
- ⏳ Commandes vocales (optionnel)
|
||
- ⏳ Suggestions contextuelles ("Tu devrais faire une pause")
|
||
|
||
#### Apprentissage des Patterns
|
||
- ⏳ Analyse des heures productives
|
||
- ⏳ Détection des activités "dangereuses" (jeux vidéo, etc.)
|
||
- ⏳ Adaptation du planning selon l'état de fatigue
|
||
|
||
#### Interventions Proactives
|
||
- ⏳ Blocage d'applications (optionnel, sur demande)
|
||
- ⏳ Rappels de breaks forcés
|
||
- ⏳ Réorganisation automatique si dérive détectée
|
||
|
||
### 3.3 Phase 3 - Fonctionnalités Avancées (Semaines 5+)
|
||
|
||
#### Intelligence Contextuelle
|
||
- 🔮 Détection automatique d'activité (via tracking d'apps)
|
||
- 🔮 Prédiction des risques d'hyperfocus
|
||
- 🔮 Suggestions de planning optimal selon l'énergie
|
||
|
||
#### Intégrations
|
||
- 🔮 Calendrier (Google, Outlook)
|
||
- 🔮 Outils de productivité (Notion, Todoist)
|
||
- 🔮 Tracking d'activité (RescueTime, ActivityWatch)
|
||
|
||
#### Gamification (Optionnel)
|
||
- 🔮 Système de points/récompenses
|
||
- 🔮 Streaks (jours consécutifs avec planning respecté)
|
||
- 🔮 Achievements
|
||
|
||
#### Analytics
|
||
- 🔮 Rapports hebdomadaires/mensuels
|
||
- 🔮 Visualisations de productivité
|
||
- 🔮 Insights IA sur les habitudes
|
||
|
||
---
|
||
|
||
## 4. Architecture Technique
|
||
|
||
### 4.1 Proposition Architecturale : Architecture Hybride WarFactory + WASM
|
||
|
||
**PROPOSITION ARCHITECTURALE** : AISSIA pourrait réutiliser l'architecture modulaire WarFactory avec compilation multi-target optionnelle (DLL/SO/WASM).
|
||
|
||
**⚠️ IMPORTANT - Phases d'implémentation :**
|
||
- **Phase 1 (local_dev) = OBLIGATOIRE** : Cible principale MVP avec WarFactory DLL Windows uniquement
|
||
- **Phase 2 (POC WASM) = VALIDATION** : Tester faisabilité avant engagement
|
||
- **Phase 3 (production_pwa) = CONDITIONNELLE** : Seulement si Phase 2 validée ET besoin justifié
|
||
|
||
**Concept Révolutionnaire : Meilleur des Deux Mondes**
|
||
|
||
```
|
||
MÊME code C++ (IModule WarFactory)
|
||
↓ CMake multi-target
|
||
├─ monitoring.dll (Dev Windows local + Hot-reload 0.4ms)
|
||
├─ monitoring.so (Serveur Linux Docker - Phase 3)
|
||
└─ monitoring.wasm (Client PWA browser - Phase 3)
|
||
|
||
UN SEUL CODE, TROIS DÉPLOIEMENTS !
|
||
```
|
||
|
||
**Architecture Hybride Proposée (À valider par POC) :**
|
||
- 🎯 **Réutilisation WarFactory** : Interfaces IModule/IEngine/IIO/ITaskScheduler inchangées (validé)
|
||
- 🎯 **Développement 100% Windows** : Visual Studio 2022, DLL, ImGui, hot-reload 0.4ms (validé)
|
||
- ⚠️ **Modules C++ écrits UNE FOIS** : Compilés en DLL (dev), SO (serveur), WASM (browser) (hypothétique - à tester)
|
||
- ⚠️ **Déploiement flexible** : gameconfig.json bascule entre mode `local_dev` et `production_pwa` (hypothétique)
|
||
- ✅ **MVP = Mode Local OBLIGATOIRE** : aissia-core.exe + DLL + ImGui + SQLite ($0 coût)
|
||
- ⚠️ **Production optionnelle CONDITIONNELLE** : React PWA + WASM client + Docker serveur ($3-5/mois) - SI Phase 2 validée
|
||
- ⚠️ **Cross-platform automatique** : Docker + WASM = tourne partout sans effort (hypothétique - complexité à évaluer)
|
||
- ⚠️ **Mobile optionnel** : PWA installable (Phase 3+, SEULEMENT si besoin validé)
|
||
|
||
**Raisons de cette proposition :**
|
||
- ✅ **Réutilisation code existant** : Économie 3-4 semaines dev (WarFactory validé)
|
||
- ✅ **Hot-reload ultra-rapide** : 0.4ms en mode local_dev (DLL validé)
|
||
- ✅ **Types stricts C++** : Pas de "wildcode", headers et interfaces bien définis (validé)
|
||
- ✅ **Modularité** : Chaque fonctionnalité = module isolé (200-300 lignes, validé WarFactory)
|
||
- ✅ **Évolution progressive** : Commencer local ($0), décider cloud plus tard (stratégie validée)
|
||
- ⚠️ **Performance maximale** : Native en local (validé), quasi-native en WASM (hypothétique - à benchmarker)
|
||
- ✅ **Développement parallèle** : Multiples modules développés simultanément (validé WarFactory)
|
||
- ✅ **Coûts minimaux Phase 1** : $0 en MVP garanti
|
||
- ⚠️ **Pipeline flexible hypothétique** : Un seul codebase, multiples déploiements (complexité à évaluer)
|
||
|
||
### 4.2 Modes de Déploiement
|
||
|
||
**AISSIA propose DEUX modes de déploiement distincts, potentiellement sélectionnables via `gameconfig.json` :**
|
||
|
||
**⚠️ Clarification priorités :**
|
||
- **Mode 1 (local_dev) = OBLIGATOIRE** : Cible MVP, sera implémenté en Phase 1
|
||
- **Mode 2 (production_pwa) = OPTIONNEL** : Sera considéré SEULEMENT si Phase 2 (POC WASM) validée
|
||
|
||
#### Mode 1 : `local_dev` (MVP - Phase 1 OBLIGATOIRE)
|
||
|
||
**Architecture :**
|
||
```
|
||
┌─────────────────────────────────────┐
|
||
│ Windows PC │
|
||
│ ┌───────────────────────────────┐ │
|
||
│ │ aissia-core.exe │ │
|
||
│ │ (WarFactory Engine) │ │
|
||
│ │ ├─ IEngine (DebugEngine) │ │
|
||
│ │ ├─ IModuleSystem (Sequential)│ │
|
||
│ │ └─ IIO (IntraIO) │ │
|
||
│ └───────────────────────────────┘ │
|
||
│ ┌───────────────────────────────┐ │
|
||
│ │ Modules DLL │ │
|
||
│ │ ├─ monitoring.dll │ │
|
||
│ │ ├─ scheduler.dll │ │
|
||
│ │ ├─ ai.dll │ │
|
||
│ │ ├─ voice.dll │ │
|
||
│ │ ├─ storage.dll │ │
|
||
│ │ └─ ui-imgui.dll │ │
|
||
│ └───────────────────────────────┘ │
|
||
│ SQLite local (aissia.db) │
|
||
└─────────────────────────────────────┘
|
||
```
|
||
|
||
**Caractéristiques :**
|
||
- ✅ **Hot-reload** : 0.4ms (750,000x plus rapide que rebuild complet)
|
||
- ✅ **UI** : Dear ImGui (C++, intégré WarFactory)
|
||
- ✅ **Storage** : SQLite local (aissia.db)
|
||
- ✅ **Coût** : $0 (tout local)
|
||
- ✅ **Privacy** : Données jamais uploadées (sauf appels Claude API)
|
||
- ✅ **Performance** : Native C++ (pas de WASM overhead)
|
||
- ✅ **Development** : Visual Studio 2022, debugging natif
|
||
|
||
**Utilisation :**
|
||
```json
|
||
// gameconfig.json
|
||
{
|
||
"active_mode": "local_dev"
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
#### Mode 2 : `production_pwa` (Phase 3 - CONDITIONNEL, après validation Phase 2)
|
||
|
||
**Architecture :**
|
||
```
|
||
┌────────────────────────┐ ┌───────────────────────────────┐
|
||
│ CLIENT (PWA - Vercel) │ │ SERVEUR (fly.io) │
|
||
│ ┌────────────────────┐ │ │ ┌───────────────────────────┐ │
|
||
│ │ React + TypeScript │ │ │ │ Docker Linux │ │
|
||
│ │ - Dashboard UI │ │ │ │ Backend C++ │ │
|
||
│ │ - Task management │ │ │ │ ├─ auth.so │ │
|
||
│ └────────────────────┘ │ │ │ ├─ sync.so │ │
|
||
│ ┌────────────────────┐ │ │ │ ├─ ai-proxy.so │ │
|
||
│ │ WASM Modules │ │ │ │ └─ monitoring.so │ │
|
||
│ │ ├─ scheduler.wasm │ │ │ │ PostgreSQL │ │
|
||
│ │ ├─ voice.wasm │ │ │ └───────────────────────────┘ │
|
||
│ │ └─ storage.wasm │ │ │ Port: 8080 (WebSocket) │
|
||
│ └────────────────────┘ │ └───────────────────────────────┘
|
||
│ IndexedDB (cache) │ ▲
|
||
│ Service Worker │ │ WebSocket
|
||
└────────┬───────────────┘ │
|
||
│ │
|
||
└──────────────────────────────┘
|
||
```
|
||
|
||
**Caractéristiques :**
|
||
- ✅ **UI** : React moderne + Tailwind CSS
|
||
- ✅ **Storage** : Hybrid (IndexedDB client + PostgreSQL serveur)
|
||
- ✅ **Coût** : $3-5/mois (fly.io + Vercel gratuit)
|
||
- ✅ **Mobile** : PWA installable iOS/Android
|
||
- ✅ **Scalable** : 70% processing client = coûts serveur minimaux
|
||
- ✅ **Cross-platform** : Fonctionne sur tous devices
|
||
- ⚠️ **Performance** : WASM ~2x plus lent que C++ natif (acceptable)
|
||
|
||
**Utilisation :**
|
||
```json
|
||
// gameconfig.json
|
||
{
|
||
"active_mode": "production_pwa"
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
### 4.3 Stack Technologique Détaillée
|
||
|
||
#### Développement (Windows - Les Deux Modes)
|
||
- **IDE** : Visual Studio 2022 / VSCode
|
||
- **Compilateur** :
|
||
- MSVC (Windows DLL)
|
||
- GCC/Clang (Linux SO via Docker)
|
||
- Emscripten (WASM browser)
|
||
- **Build System** : CMake (multi-target)
|
||
- **Containerization** : Docker Desktop (builds Linux SO)
|
||
- **Version Control** : Git + GitHub
|
||
- **CI/CD** : GitHub Actions
|
||
|
||
#### Mode `local_dev` - Modules C++ (DLL)
|
||
- **Core Engine** : WarFactory (aissia-core.exe)
|
||
- IEngine (DebugEngine)
|
||
- IModuleSystem (SequentialModuleSystem)
|
||
- IIO (IntraIO pour communication locale)
|
||
- ICoordinationModule (charge gameconfig.json)
|
||
- **Modules DLL** :
|
||
- `monitoring.dll` : Win32 API tracking apps (GetForegroundWindow)
|
||
- `scheduler.dll` : Algorithmes planning, détection procrastination
|
||
- `ai.dll` : Claude Haiku API integration
|
||
- `voice.dll` : SAPI TTS (Windows) + Whisper.cpp STT
|
||
- `storage.dll` : SQLite local (aissia.db)
|
||
- `ui-imgui.dll` : Interface ImGui
|
||
- **Base de données** : SQLite local (aissia.db)
|
||
- **Coût** : $0 (tout local, sauf appels Claude API $10-20/mois)
|
||
|
||
#### Mode `production_pwa` - Backend Serveur (SO)
|
||
- **Runtime** : Docker Linux container (Alpine ou Ubuntu)
|
||
- **Langage** : C++20
|
||
- **Modules Serveur (SO)** :
|
||
- `auth.so` : Authentification JWT
|
||
- `sync.so` : Synchronisation données PostgreSQL
|
||
- `ai-proxy.so` : Proxy sécurisé pour Claude API (cache API key)
|
||
- `monitoring.so` : Tracking apps (optionnel, serveur dédié)
|
||
- `websocket-server.so` : API WebSocket pour clients PWA
|
||
- **Base de données** : PostgreSQL (fly.io managed)
|
||
- **Déploiement** : fly.io ($3-5/mois)
|
||
|
||
#### Mode `production_pwa` - Frontend Client (WASM)
|
||
- **Framework** : React 18 + TypeScript
|
||
- **Build** : Vite (hot-reload ultra-rapide)
|
||
- **UI Library** : Tailwind CSS + shadcn/ui
|
||
- **State Management** : Zustand ou Jotai (léger)
|
||
- **Modules Client (WASM)** :
|
||
- `scheduler.wasm` : Algorithmes de planning (client-side)
|
||
- `voice.wasm` : TTS/STT via Web Speech API
|
||
- `storage.wasm` : Cache local IndexedDB
|
||
- **Offline** : Service Workers + IndexedDB
|
||
- **Notifications** : Web Push API
|
||
- **Déploiement** : Vercel (gratuit)
|
||
|
||
---
|
||
|
||
### 4.4 Modules C++ Partagés (Un Code, Trois Targets)
|
||
|
||
**Concept Clé** : Chaque module C++ implémente `IModule` de WarFactory et compile en 3 targets :
|
||
|
||
```cpp
|
||
// modules/scheduler/src/SchedulerModule.cpp
|
||
// MÊME CODE pour DLL/SO/WASM !
|
||
|
||
class SchedulerModule : public IModule {
|
||
public:
|
||
json process(const json& input) override {
|
||
// Logique pure (200-300 lignes)
|
||
if (IsProcrastinating(input)) {
|
||
return {
|
||
{"event", "intervention_needed"},
|
||
{"urgency", "high"}
|
||
};
|
||
}
|
||
return {{"status", "ok"}};
|
||
}
|
||
|
||
void setConfiguration(const IDataNode& config,
|
||
IIO* io,
|
||
ITaskScheduler* scheduler) override {
|
||
m_io = io;
|
||
m_io->subscribe("task_changed", [this](const json& e) {
|
||
process(e);
|
||
});
|
||
}
|
||
|
||
json getHealthStatus() override {
|
||
return {{"status", "healthy"}};
|
||
}
|
||
|
||
void shutdown() override { /* cleanup */ }
|
||
|
||
private:
|
||
IIO* m_io = nullptr;
|
||
};
|
||
|
||
// ======== EXPORTS MULTI-TARGET ========
|
||
|
||
#ifdef _WIN32
|
||
// Export DLL Windows (dev local)
|
||
extern "C" __declspec(dllexport)
|
||
IModule* CreateModule() {
|
||
return new SchedulerModule();
|
||
}
|
||
#endif
|
||
|
||
#ifdef __linux__
|
||
// Export SO Linux (serveur Docker)
|
||
extern "C"
|
||
IModule* CreateModule() {
|
||
return new SchedulerModule();
|
||
}
|
||
#endif
|
||
|
||
#ifdef __EMSCRIPTEN__
|
||
// Export WASM (client browser)
|
||
#include <emscripten.h>
|
||
extern "C" {
|
||
EMSCRIPTEN_KEEPALIVE
|
||
const char* ProcessScheduler(const char* inputJson) {
|
||
static SchedulerModule module;
|
||
json input = json::parse(inputJson);
|
||
json result = module.process(input);
|
||
static std::string output = result.dump();
|
||
return output.c_str();
|
||
}
|
||
}
|
||
#endif
|
||
```
|
||
|
||
**Compilation :**
|
||
```cmake
|
||
# modules/scheduler/CMakeLists.txt (extrait)
|
||
# Target 1: DLL (Windows)
|
||
add_library(scheduler MODULE src/SchedulerModule.cpp)
|
||
set_target_properties(scheduler PROPERTIES SUFFIX ".dll")
|
||
|
||
# Target 2: SO (Linux)
|
||
add_library(scheduler MODULE src/SchedulerModule.cpp)
|
||
set_target_properties(scheduler PROPERTIES SUFFIX ".so")
|
||
|
||
# Target 3: WASM (Browser)
|
||
add_executable(scheduler src/SchedulerModule.cpp)
|
||
set_target_properties(scheduler PROPERTIES SUFFIX ".wasm")
|
||
target_link_options(scheduler PRIVATE -s WASM=1)
|
||
```
|
||
|
||
**Build Script :**
|
||
```powershell
|
||
# scripts/build-all.ps1
|
||
# Build DLL (dev Windows)
|
||
cmake -B build-windows -G "Visual Studio 17 2022"
|
||
cmake --build build-windows --config Release
|
||
|
||
# Build SO (serveur Linux via Docker)
|
||
docker build -t aissia-backend -f docker/Dockerfile.backend .
|
||
|
||
# Build WASM (client browser via Emscripten)
|
||
emcmake cmake -B build-wasm
|
||
emmake make -C build-wasm
|
||
```
|
||
|
||
**Résultat :**
|
||
```
|
||
build-windows/modules/scheduler.dll (Dev local)
|
||
build-linux/modules/scheduler.so (Serveur Docker)
|
||
build-wasm/modules/scheduler.wasm (Client PWA)
|
||
```
|
||
|
||
#### Communication Client-Serveur
|
||
- **Protocole** : WebSocket (temps réel) + REST API (fallback)
|
||
- **Format** : JSON pour messages
|
||
- **Events Pub/Sub** :
|
||
- Client → Serveur : `task_created`, `user_action`, `sync_request`
|
||
- Serveur → Client : `ai_suggestion`, `sync_complete`, `notification`
|
||
- **Authentification** : JWT tokens (localStorage client)
|
||
- **Sécurité** : HTTPS/WSS obligatoire, CORS configuré
|
||
|
||
---
|
||
|
||
### 4.5 Configuration gameconfig.json (Unifié)
|
||
|
||
**Un seul fichier de configuration bascule entre les deux modes :**
|
||
|
||
```json
|
||
{
|
||
"deployment_modes": {
|
||
"local_dev": {
|
||
"enabled": true,
|
||
"description": "Dev Windows local avec hot-reload WarFactory",
|
||
"modules": [
|
||
{"name": "MonitoringModule", "type": "dll", "execution": "local"},
|
||
{"name": "SchedulerModule", "type": "dll", "execution": "local"},
|
||
{"name": "AIModule", "type": "dll", "execution": "local"},
|
||
{"name": "VoiceModule", "type": "dll", "execution": "local"},
|
||
{"name": "StorageModule", "type": "dll", "execution": "local"},
|
||
{"name": "UIModule", "type": "dll", "execution": "local"}
|
||
],
|
||
"io": "IntraIO",
|
||
"engine": "DebugEngine",
|
||
"ui": "ImGui",
|
||
"storage": "SQLite",
|
||
"cost": "$0"
|
||
},
|
||
|
||
"production_pwa": {
|
||
"enabled": false,
|
||
"description": "PWA React + WASM client + Serveur Docker",
|
||
"client_modules_wasm": [
|
||
{"name": "SchedulerModule", "file": "scheduler.wasm"},
|
||
{"name": "VoiceModule", "file": "voice.wasm"},
|
||
{"name": "StorageModule", "file": "storage.wasm"}
|
||
],
|
||
"server_modules_so": [
|
||
{"name": "AuthModule", "file": "auth.so"},
|
||
{"name": "SyncModule", "file": "sync.so"},
|
||
{"name": "AIProxyModule", "file": "ai-proxy.so"},
|
||
{"name": "MonitoringModule", "file": "monitoring.so"}
|
||
],
|
||
"io": "WebSocket",
|
||
"engine": "HighPerfEngine",
|
||
"ui": "React PWA",
|
||
"storage": "PostgreSQL + IndexedDB",
|
||
"cost": "$3-5/mois"
|
||
}
|
||
},
|
||
|
||
"active_mode": "local_dev"
|
||
}
|
||
```
|
||
|
||
**Bascule entre modes :**
|
||
```json
|
||
// Mode local (MVP - Phase 1 OBLIGATOIRE)
|
||
"active_mode": "local_dev"
|
||
|
||
// Mode production (Phase 3 CONDITIONNEL - seulement si Phase 2 validée)
|
||
"active_mode": "production_pwa"
|
||
```
|
||
|
||
---
|
||
|
||
### 4.6 Risques Techniques de l'Architecture Multi-Target
|
||
|
||
**⚠️ ATTENTION : Cette section documente les risques identifiés de la compilation multi-target (DLL/SO/WASM).**
|
||
|
||
#### Risques Majeurs Identifiés
|
||
|
||
| Risque | Impact | Probabilité | Mitigation Proposée |
|
||
|--------|--------|-------------|---------------------|
|
||
| **Complexité CMake multi-target** | Élevé | Moyenne | Phase 2 POC validera faisabilité avant engagement |
|
||
| **Maintenance 3 builds par module** | Moyen | Élevée | Si trop complexe, rester mode `local_dev` uniquement |
|
||
| **Performance WASM insuffisante** | Élevé | Moyenne | Benchmarks Phase 2, accepter 2x overhead max |
|
||
| **Debugging WASM complexe** | Moyen | Élevée | Développer en DLL (facile), compiler WASM uniquement prod |
|
||
| **Différences comportementales DLL/SO/WASM** | Élevé | Faible | Tests automatisés sur 3 targets, CI/CD obligatoire |
|
||
| **Emscripten limitations (threads, I/O)** | Moyen | Moyenne | Design modules sans dépendances système (pure logic) |
|
||
| **Overhead développement pipeline** | Moyen | Élevée | Si Phase 2 montre complexité excessive, ABANDONNER multi-target |
|
||
|
||
#### Stratégie de Validation (Phase 2)
|
||
|
||
**Avant tout engagement Phase 3, Phase 2 DOIT valider :**
|
||
|
||
1. **POC Technique** (2-3 jours max) :
|
||
- Créer `HelloModule.cpp` minimal (IModule WarFactory)
|
||
- Compiler en `.dll` (Windows MSVC)
|
||
- Compiler en `.wasm` (Emscripten)
|
||
- Tester intégration React + WASM
|
||
- **Go/No-Go** : Si POC échoue ou trop complexe, ARRÊTER ici
|
||
|
||
2. **Benchmark Performance** (1 jour) :
|
||
- Mesurer overhead WASM vs DLL natif
|
||
- Algorithme test : SchedulerModule (calculs intensifs)
|
||
- **Critère acceptation** : WASM < 2x DLL
|
||
- **Go/No-Go** : Si WASM > 2x, reconsidérer architecture
|
||
|
||
3. **Évaluation Complexité Build** (1 jour) :
|
||
- Setup complet Emscripten + Docker
|
||
- Temps build 3 targets (DLL + SO + WASM)
|
||
- **Critère acceptation** : < 30 min build complet CI/CD
|
||
- **Go/No-Go** : Si build > 30 min, trop lent pour itérations
|
||
|
||
#### Scénarios de Sortie
|
||
|
||
**Si Phase 2 invalide multi-target :**
|
||
|
||
- **Option A (recommandée)** : Rester 100% mode `local_dev`
|
||
- MVP fonctionnel DLL Windows uniquement
|
||
- $0 coût, 0.4ms hot-reload conservé
|
||
- Abandon PWA/WASM, focus usage perso desktop
|
||
|
||
- **Option B** : Pivot vers architecture alternative
|
||
- Évaluer Electron (desktop cross-platform)
|
||
- Évaluer Flutter Desktop
|
||
- Réévaluer AlternativesAnalysis.md
|
||
|
||
**⚠️ ACCEPTER L'ÉCHEC MULTI-TARGET :**
|
||
Le mode `local_dev` seul reste une excellente solution pour le besoin initial (hyperfocus management personnel). L'architecture multi-target est un BONUS, pas une nécessité.
|
||
|
||
---
|
||
|
||
### 4.7 Architecture Système (Hypothétique - Si Phase 3)
|
||
|
||
```
|
||
┌───────────────────────────────────────────────────────────────┐
|
||
│ DÉVELOPPEMENT (Windows PC) │
|
||
│ ┌─────────────────────────────────────────────────────────┐ │
|
||
│ │ Visual Studio 2022 / VSCode │ │
|
||
│ │ /modules/ │ │
|
||
│ │ ├─ SchedulerModule/ (C++) │ │
|
||
│ │ ├─ StorageModule/ (C++) │ │
|
||
│ │ ├─ VoiceModule/ (C++) │ │
|
||
│ │ └─ AIModule/ (C++) │ │
|
||
│ │ │ │
|
||
│ │ Build Scripts: │ │
|
||
│ │ → .dll (Windows dev local) │ │
|
||
│ │ → .so (Linux serveur via Docker) │ │
|
||
│ │ → .wasm (Browser client via Emscripten) │ │
|
||
│ └─────────────────────────────────────────────────────────┘ │
|
||
└───────────────────────────────────────────────────────────────┘
|
||
│
|
||
│ Git Push
|
||
▼
|
||
┌───────────────────────────────────────────────────────────────┐
|
||
│ CI/CD (GitHub Actions) │
|
||
│ 1. Build backend Linux (Docker) │
|
||
│ 2. Build modules WASM (Emscripten) │
|
||
│ 3. Deploy backend → fly.io │
|
||
│ 4. Deploy PWA + WASM → Vercel │
|
||
└───────────────────────────────────────────────────────────────┘
|
||
│
|
||
┌────────────────┴────────────────┐
|
||
▼ ▼
|
||
┌────────────────────────┐ ┌───────────────────────────────┐
|
||
│ SERVEUR (fly.io) │ │ CLIENT (PWA - Vercel) │
|
||
│ Docker Linux │ │ React + TypeScript │
|
||
│ ┌──────────────────┐ │ │ ┌─────────────────────────┐ │
|
||
│ │ Backend C++ │ │ │ │ UI Components (React) │ │
|
||
│ │ - AuthModule.so │ │ │ │ - Dashboard │ │
|
||
│ │ - SyncModule.so │ │ │ │ - Task management │ │
|
||
│ │ - AIProxy.so │ │ │ │ - Settings │ │
|
||
│ │ - Monitoring.so │ │ │ └─────────────────────────┘ │
|
||
│ │ - WebSocket API │ │ │ │
|
||
│ └──────────────────┘ │ │ ┌─────────────────────────┐ │
|
||
│ PostgreSQL/SQLite │ │ │ WASM Modules (C++) │ │
|
||
│ Port: 8080 (WSS) │ │ │ - scheduler.wasm │ │
|
||
└────────┬───────────────┘ │ │ - voice.wasm │ │
|
||
│ │ │ - storage.wasm │ │
|
||
│ WebSocket │ │ (IndexedDB wrapper) │ │
|
||
└────────────────────┤ └─────────────────────────┘ │
|
||
│ │
|
||
│ Service Worker (offline) │
|
||
│ Web Push API (notifications) │
|
||
└────────────────────────────────┘
|
||
│
|
||
┌────────────────────┼────────────────────┐
|
||
▼ ▼ ▼
|
||
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
|
||
│ Windows PC │ │ iPhone │ │ Android │
|
||
│ (Chrome PWA) │ │ (Safari PWA) │ │ (Chrome PWA) │
|
||
└──────────────┘ └──────────────┘ └──────────────┘
|
||
│ │ │
|
||
└────────────────────┴────────────────────┘
|
||
│
|
||
Tous accèdent à la même PWA
|
||
https://aissia.app
|
||
|
||
┌───────────────────────────────────────────────────────────────┐
|
||
│ SERVICES EXTERNES │
|
||
│ ┌─────────────────────────────────────────────────────────┐ │
|
||
│ │ Claude Haiku 4.5 API (Anthropic) │ │
|
||
│ │ - Appelé UNIQUEMENT par le serveur (API key sécurisée) │ │
|
||
│ │ - Planning suggestions, conversational AI │ │
|
||
│ │ - Coût: ~$10-20/mois usage personnel │ │
|
||
│ └─────────────────────────────────────────────────────────┘ │
|
||
└───────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
### 4.8 Répartition Client/Serveur (Hypothétique - Phase 3 uniquement)
|
||
|
||
| Module | Où ? | Raison | Impact Coût Serveur |
|
||
|--------|------|--------|---------------------|
|
||
| **SchedulerModule** | ✅ Client (WASM) | Algorithmes purs, pas d'I/O | **Économie $$$** |
|
||
| **VoiceModule** | ✅ Client (Web Speech API) | TTS/STT natif browser | **Économie $$$** |
|
||
| **StorageModule** | 🔀 Hybrid | IndexedDB client + PostgreSQL serveur | **Économie $$** |
|
||
| **UIModule** | ✅ Client (React) | Rendu interface | **Économie $$$** |
|
||
| **AIModule** | ❌ Serveur uniquement | Sécurité API key Claude | Nécessaire |
|
||
| **AuthModule** | ❌ Serveur uniquement | Sécurité credentials | Nécessaire |
|
||
| **SyncModule** | ❌ Serveur uniquement | Base de données centrale | Nécessaire |
|
||
| **MonitoringModule** | ❌ Serveur uniquement | Tracking apps desktop impossible en browser | Optionnel |
|
||
|
||
**Résultat :**
|
||
- **70% du processing sur client** (gratuit pour l'utilisateur)
|
||
- **Serveur minimaliste** : Auth + Sync + AI proxy + Monitoring
|
||
- **Coût serveur** : $3-5/mois au lieu de $20-30/mois
|
||
|
||
### 4.9 Communication Client-Serveur (Hypothétique - Phase 3 uniquement)
|
||
|
||
**WebSocket Events (Temps Réel) :**
|
||
|
||
```typescript
|
||
// Client PWA → Serveur
|
||
{
|
||
"event": "task_created",
|
||
"data": {
|
||
"task_id": "123",
|
||
"title": "Finir le CDC",
|
||
"priority": "high"
|
||
}
|
||
}
|
||
|
||
// Serveur → Client PWA
|
||
{
|
||
"event": "ai_suggestion",
|
||
"data": {
|
||
"message": "Tu devrais faire une pause, ça fait 2h que tu codes",
|
||
"urgency": "medium",
|
||
"actions": ["dismiss", "take_break"]
|
||
}
|
||
}
|
||
```
|
||
|
||
**Module WASM (Client-side) :**
|
||
|
||
```cpp
|
||
// SchedulerModule.cpp (compilé en .wasm)
|
||
extern "C" {
|
||
// Exporté vers JavaScript
|
||
EMSCRIPTEN_KEEPALIVE
|
||
bool IsProcrastinating(const char* currentApp, const char* tasksJson) {
|
||
// Logique pure C++, tourne dans le browser
|
||
json tasks = json::parse(tasksJson);
|
||
return CheckProcrastination(currentApp, tasks);
|
||
}
|
||
}
|
||
```
|
||
|
||
```typescript
|
||
// Frontend React appelle le module WASM
|
||
import schedulerModule from './wasm/scheduler.wasm';
|
||
|
||
const isProcrastinating = schedulerModule.IsProcrastinating(
|
||
'steam.exe',
|
||
JSON.stringify(currentTasks)
|
||
);
|
||
|
||
if (isProcrastinating) {
|
||
// Affiche alerte côté client, pas besoin du serveur !
|
||
showNotification('Retourne au travail !');
|
||
}
|
||
```
|
||
|
||
**Avantages de cette architecture :**
|
||
- ✅ Réactivité instantanée (pas de latence réseau)
|
||
- ✅ Fonctionne offline (modules WASM = autonomes)
|
||
- ✅ Coûts serveur minimaux
|
||
- ✅ Scalabilité : 1000 utilisateurs = même coût serveur
|
||
|
||
### 4.10 Modèle de Données (Simplifié)
|
||
|
||
```
|
||
User
|
||
- id, email, password_hash, created_at
|
||
- settings (JSON: notifications, ai_proactivity_level, etc.)
|
||
|
||
Task
|
||
- id, user_id, title, description
|
||
- priority (high/medium/low)
|
||
- estimated_duration, actual_duration
|
||
- deadline, status (todo/in_progress/done)
|
||
- tags[], category
|
||
|
||
TimeEntry
|
||
- id, user_id, task_id
|
||
- start_time, end_time, duration
|
||
- auto_tracked (boolean)
|
||
|
||
AIInteraction
|
||
- id, user_id, timestamp
|
||
- type (suggestion/alert/chat)
|
||
- context (JSON), ai_response
|
||
|
||
Schedule
|
||
- id, user_id, date
|
||
- planned_tasks[] (ordered list)
|
||
- ai_generated (boolean)
|
||
```
|
||
|
||
---
|
||
|
||
## 5. Contraintes et Exigences
|
||
|
||
### 5.1 Contraintes Techniques
|
||
- ✅ **Dev Windows uniquement** : Développement, debug, et tests 100% sur Windows
|
||
- ✅ **Cross-platform automatique** : Via Docker (serveur) et WASM (client)
|
||
- ✅ **Mobile via PWA** : Progressive Web App (pas d'app native Android/iOS)
|
||
- ✅ **Performance** : WASM ~2x plus lent que C++ natif (acceptable)
|
||
- ✅ **Offline-first** : Service Workers + IndexedDB + modules WASM autonomes
|
||
- ✅ **Sécurité** : JWT auth, HTTPS/WSS obligatoire, API keys serveur uniquement
|
||
- ✅ **Pipeline stable** : GitHub Actions (reproductible, pas de surprises)
|
||
|
||
### 5.2 Contraintes Budget
|
||
- 💰 **Mode local_dev (MVP)** : $0 hosting + $10-20/mois Claude API = **$10-20/mois total**
|
||
- 💰 **Mode production_pwa (Phase 3)** :
|
||
- Serveur fly.io : $3-5/mois
|
||
- Frontend Vercel : $0 (gratuit)
|
||
- Claude API : $10-20/mois
|
||
- **Total** : $13-25/mois
|
||
- 🎯 **Optimisation production_pwa** : 70% processing client → économie serveur massive
|
||
- 📊 **Monétisation future** : Freemium (gratuit: 50 requêtes IA/jour, client-side illimité)
|
||
|
||
### 5.3 Contraintes Développement
|
||
- 🔄 **Itérations courtes** : Cycles de 1-2 semaines
|
||
- ✅ **Versions fonctionnelles** : Chaque release doit être utilisable
|
||
- 🪟 **Dev Windows-first** : Zéro VM/émulateurs, tout sur Windows
|
||
- 🐋 **Docker Desktop** : Seul prérequis pour builds cross-platform
|
||
- 🧪 **Tests** : Jest (frontend), Google Test (backend C++)
|
||
- 📝 **Documentation** : README, architecture diagrams, module interfaces
|
||
- 🤖 **CI/CD automatique** : GitHub Actions (build + deploy automatique)
|
||
|
||
---
|
||
|
||
## 6. Planification (Roadmap)
|
||
|
||
**⚠️ IMPORTANT - Structure des phases :**
|
||
- **Phase 0 + Phase 1 = OBLIGATOIRES** : Cible MVP mode `local_dev`
|
||
- **Phase 2 = VALIDATION** : POC multi-target (Go/No-Go décision)
|
||
- **Phase 3 = CONDITIONNELLE** : Seulement SI Phase 2 validée
|
||
- **Phase 4 = HYPOTHÉTIQUE** : Dépend succès Phase 3
|
||
|
||
### Phase 0 - Setup (Semaine 0) - OBLIGATOIRE
|
||
- [ ] Copier interfaces WarFactory (IModule, IEngine, IIO, ITaskScheduler, IDataTree)
|
||
- [ ] Structure projet modules/ (MonitoringModule/, SchedulerModule/, etc.)
|
||
- [ ] CMakeLists.txt pour DLL Windows (Phase 1 uniquement, SO/WASM Phase 2+)
|
||
- [ ] gameconfig.json initial (mode `local_dev` uniquement)
|
||
- [ ] Scripts build Windows (build-dll.ps1)
|
||
- [ ] ⚠️ Setup Docker Desktop (OPTIONNEL - seulement si Phase 2)
|
||
- [ ] ⚠️ Setup Emscripten SDK (OPTIONNEL - seulement si Phase 2)
|
||
|
||
### Phase 1 - MVP Local (Semaines 1-2) - OBLIGATOIRE
|
||
|
||
**Objectif** : Version locale fonctionnelle avec hot-reload WarFactory (mode `local_dev` DLL uniquement)
|
||
|
||
**Core Engine :**
|
||
- [ ] aissia-core.exe (WarFactory engine)
|
||
- IEngine (DebugEngine)
|
||
- IModuleSystem (SequentialModuleSystem)
|
||
- IIO (IntraIO)
|
||
- ICoordinationModule (charge gameconfig.json)
|
||
|
||
**Modules DLL (Windows) :**
|
||
- [ ] MonitoringModule.dll
|
||
- Win32 API (GetForegroundWindow)
|
||
- Tracking temps par application
|
||
- Publish event "app_changed"
|
||
- [ ] SchedulerModule.dll
|
||
- Planning algorithmes basiques
|
||
- Détection procrastination contextuelle
|
||
- Publish event "intervention_needed"
|
||
- [ ] AIModule.dll
|
||
- Claude Haiku 4.5 API integration
|
||
- Context building pour suggestions
|
||
- Subscribe "intervention_needed", publish "ai_response"
|
||
- [ ] VoiceModule.dll
|
||
- SAPI TTS (Windows text-to-speech)
|
||
- Whisper.cpp STT (speech-to-text local)
|
||
- Subscribe "ai_response", speak()
|
||
- [ ] StorageModule.dll
|
||
- SQLite local (aissia.db)
|
||
- CRUD tâches, historique, métriques
|
||
- [ ] UIModule-ImGui.dll
|
||
- Dear ImGui interface
|
||
- Dashboard planning
|
||
- Settings
|
||
|
||
**Bénéfices Phase 1 :**
|
||
- ✅ Hot-reload 0.4ms
|
||
- ✅ Développement ultra-rapide
|
||
- ✅ $0 coût (tout local)
|
||
- ✅ Dogfooding immédiat (usage perso)
|
||
- ✅ Interventions vocales proactives (besoin core)
|
||
|
||
---
|
||
|
||
### Phase 2 - POC WASM (Semaines 3-4) - VALIDATION (Go/No-Go)
|
||
|
||
**⚠️ CRITIQUE : Cette phase décide si Phase 3 est viable ou non.**
|
||
|
||
**Objectif** : Valider faisabilité multi-target (WASM) + performance acceptable
|
||
|
||
**⚠️ RÈGLE : Phase 1 DOIT être complétée et fonctionnelle AVANT Phase 2.**
|
||
|
||
**POC Expérimental :**
|
||
- [ ] Compiler SchedulerModule.wasm (test WASM simple)
|
||
- [ ] Frontend React minimal (Vite + TypeScript)
|
||
- [ ] Intégrer scheduler.wasm dans React
|
||
- [ ] Tester performance WASM vs DLL (benchmark)
|
||
- [ ] Évaluer complexité build Emscripten
|
||
|
||
**Validation Phase 2 (Go/No-Go) :**
|
||
- ⚠️ Performance WASM acceptable pour scheduler ? (< 2x DLL)
|
||
- ⚠️ Complexité build supportable ? (< 30 min CI/CD)
|
||
- ⚠️ Debugging WASM pas trop problématique ?
|
||
- ⚠️ Intérêt réel mobile PWA validé par usage Phase 1 ?
|
||
|
||
**🚦 Décision Go/No-Go :**
|
||
- **✅ GO (Phase 3)** : Si TOUS les critères validés ET besoin mobile confirmé
|
||
- **❌ NO-GO (Arrêt)** : Si UN SEUL critère invalidé → Rester mode `local_dev` définitif
|
||
|
||
**⚠️ NO-GO n'est PAS un échec :** Mode `local_dev` seul répond parfaitement au besoin initial.
|
||
|
||
---
|
||
|
||
### Phase 3 - Production PWA (Semaines 5-8) - CONDITIONNELLE (Seulement si Phase 2 GO)
|
||
|
||
**⚠️ ATTENTION : Cette phase n'existe QUE si Phase 2 validée.**
|
||
|
||
**Objectif** : Déploiement cloud avec PWA React + WASM client
|
||
|
||
**Backend Docker (Serveur SO) :**
|
||
- [ ] auth.so (JWT authentication)
|
||
- [ ] sync.so (PostgreSQL synchronisation)
|
||
- [ ] ai-proxy.so (Claude API proxy, sécurise API key)
|
||
- [ ] websocket-server.so (API temps réel pour clients)
|
||
- [ ] Dockerfile backend (Alpine Linux)
|
||
- [ ] Deploy fly.io ($3-5/mois)
|
||
|
||
**Frontend PWA React :**
|
||
- [ ] UI complète (Tailwind + shadcn/ui)
|
||
- [ ] scheduler.wasm intégré
|
||
- [ ] voice.wasm (Web Speech API)
|
||
- [ ] storage.wasm (IndexedDB wrapper)
|
||
- [ ] Service Workers (offline)
|
||
- [ ] Web Push notifications
|
||
- [ ] PWA manifest (installable)
|
||
- [ ] Deploy Vercel (gratuit)
|
||
|
||
**CI/CD GitHub Actions :**
|
||
- [ ] Build multi-target automatique (DLL/SO/WASM)
|
||
- [ ] Deploy backend fly.io
|
||
- [ ] Deploy frontend Vercel
|
||
- [ ] Tests automatisés
|
||
|
||
**Mode Dual Opérationnel :**
|
||
- Développement Windows : `local_dev` (DLL + ImGui + hot-reload)
|
||
- Production : `production_pwa` (WASM + React + Cloud)
|
||
|
||
---
|
||
|
||
### Phase 4 - Optimisation & Monétisation (Semaines 9-12) - HYPOTHÉTIQUE (Dépend Phase 3)
|
||
- [ ] Système Freemium (rate limiting IA)
|
||
- [ ] Paiements Stripe (backend)
|
||
- [ ] Landing page marketing
|
||
- [ ] Beta publique (early access)
|
||
- [ ] Optimisations performance WASM
|
||
- [ ] Monitoring & observability (Sentry, Prometheus)
|
||
|
||
---
|
||
|
||
## 7. Risques et Mitigations
|
||
|
||
| Risque | Probabilité | Impact | Mitigation |
|
||
|--------|-------------|--------|------------|
|
||
| Coût IA trop élevé | Moyenne | Élevé | Caching côté serveur, rate limiting, 70% processing client |
|
||
| Complexité WASM | Moyenne | Moyen | Commencer simple (scheduler.wasm), monter progressivement |
|
||
| Performance WASM insuffisante | Faible | Moyen | WASM ~2x C++ natif acceptable, fallback serveur possible |
|
||
| Docker/Emscripten setup difficile | Faible | Faible | Scripts d'installation automatiques, docs détaillées |
|
||
| Adoption utilisateur faible | Élevée | Élevé | Dogfooding (usage perso), beta privée, feedback loops courts |
|
||
| Problèmes de privacy | Faible | Critique | Processing client-side, JWT auth, HTTPS/WSS, pas de tracking |
|
||
| PWA pas assez "native" | Moyenne | Moyen | Web Push, Service Workers, install prompt, works offline |
|
||
| Hyperfocus sur le dev du projet | Élevée | Moyen | Utiliser l'app elle-même pour se contraindre 😅 |
|
||
|
||
---
|
||
|
||
## 8. KPIs de Succès
|
||
|
||
### Phase 1 - MVP Local
|
||
- ✅ aissia-core.exe fonctionnel (WarFactory engine)
|
||
- ✅ 6 modules DLL opérationnels (monitoring, scheduler, ai, voice, storage, ui)
|
||
- ✅ Hot-reload 0.4ms validé
|
||
- ✅ Utilisation personnelle quotidienne (dogfooding)
|
||
- ✅ Réduction mesurable de l'hyperfocus (via tracking)
|
||
- ✅ Interventions vocales proactives fonctionnelles
|
||
|
||
### Phase 2 - POC WASM (Validation)
|
||
- ⚠️ SchedulerModule.wasm compilé et fonctionnel
|
||
- ⚠️ Performance WASM acceptable (< 2x C++ natif)
|
||
- ⚠️ Intégration React + WASM validée
|
||
- ⚠️ Décision Go/No-Go pour Phase 3
|
||
|
||
### Phase 3 - Production PWA (Si Phase 2 validée)
|
||
- 📊 PWA déployée et fonctionnelle (desktop + mobile)
|
||
- 📊 100 utilisateurs actifs (beta privée)
|
||
- 📊 80%+ retention hebdomadaire
|
||
- 📊 NPS > 50
|
||
- 💰 $500 MRR (objectif monétisation)
|
||
- 🚀 Coût serveur < $10/mois pour 100 users (grâce à WASM client-side)
|
||
- ⚡ PWA installée sur 50%+ des devices utilisateurs
|
||
|
||
---
|
||
|
||
## 9. Stack Finale Retenue
|
||
|
||
### Architecture Hybride : WarFactory + Multi-Target (DLL/SO/WASM)
|
||
|
||
**Concept Révolutionnaire :**
|
||
```
|
||
MÊME code C++ (IModule WarFactory)
|
||
↓ CMake multi-target
|
||
├─ .dll (Dev Windows local - Hot-reload 0.4ms)
|
||
├─ .so (Serveur Linux Docker - Phase 3)
|
||
└─ .wasm (Client PWA browser - Phase 3)
|
||
```
|
||
|
||
**Mode 1 : `local_dev` (Phase 1 MVP) :**
|
||
- **Dev** : Windows 10/11, Visual Studio 2022, WarFactory engine
|
||
- **Modules** : DLL (monitoring, scheduler, ai, voice, storage, ui-imgui)
|
||
- **UI** : Dear ImGui (C++, intégré)
|
||
- **Storage** : SQLite local (aissia.db)
|
||
- **Coût** : $0 hosting + $10-20/mois Claude API
|
||
|
||
**Mode 2 : `production_pwa` (Phase 3 - Optionnel) :**
|
||
- **Backend** : C++ modules (.so), Docker Linux, fly.io ($3-5/mois)
|
||
- **Frontend** : React + TypeScript, WASM modules, Vercel (gratuit)
|
||
- **Mobile** : PWA installable (pas d'app native)
|
||
- **Coût** : $3-5/mois serveur + $10-20/mois Claude API
|
||
|
||
**Pourquoi cette architecture hybride :**
|
||
- ✅ **Réutilisation WarFactory** : Économie 3-4 semaines dev
|
||
- ✅ **Hot-reload 0.4ms** : Productivité maximale en dev local
|
||
- ✅ **Types stricts C++** : Pas de wildcode, interfaces bien définies
|
||
- ✅ **Évolution progressive** : Commence local ($0), migre cloud si besoin
|
||
- ✅ **Modules écrits UNE FOIS** : Compilés en DLL/SO/WASM automatiquement
|
||
- ✅ **Déploiement flexible** : gameconfig.json bascule entre modes
|
||
- ✅ **Coûts minimaux** : $0 en MVP, $3-5/mois optionnel production
|
||
- ✅ **Mobile optionnel** : PWA Phase 3 si besoin validé
|
||
|
||
**Évolution par phases :**
|
||
- **Phase 0** : Setup projet (interfaces WarFactory, CMakeLists multi-target)
|
||
- **Phase 1 (MVP)** : Mode `local_dev` (DLL + ImGui + SQLite local)
|
||
- **Phase 2 (Validation)** : POC WASM (test performance + faisabilité)
|
||
- **Phase 3 (Production)** : Mode `production_pwa` (WASM + React + Cloud) SI validé
|
||
|
||
**Pourquoi PAS d'autres options :**
|
||
- ❌ **Pas de WarFactory** : Perte 3-4 semaines dev + hot-reload 0.4ms
|
||
- ❌ **Cloud obligatoire dès MVP** : Coûts permanents + complexité inutile
|
||
- ❌ **App native mobile** : Trop complexe, pas prioritaire
|
||
- ❌ **Flutter/Node.js** : Pas de réutilisation WarFactory + wildcode
|
||
- ❌ **Electron seul** : Poids énorme, pas cross-platform mobile
|
||
|
||
---
|
||
|
||
## 10. Prochaines Étapes
|
||
|
||
### Immédiat (Aujourd'hui)
|
||
1. ✅ **CDC draft finalisé** : Architecture proposée et documentée
|
||
2. **Validation faisabilité technique** :
|
||
- POC : Hello World C++ → WASM
|
||
- Test setup Emscripten sur Windows
|
||
- Vérifier performance WASM acceptable
|
||
3. **Création structure projet** (si POC validé) :
|
||
```
|
||
aissia/
|
||
├── modules/ # C++ modules sources
|
||
│ ├── SchedulerModule/
|
||
│ ├── StorageModule/
|
||
│ ├── AIProxyModule/
|
||
│ └── AuthModule/
|
||
├── backend/ # Serveur C++ Docker
|
||
├── frontend/ # PWA React
|
||
├── scripts/ # Build scripts (build-all.ps1)
|
||
├── .github/workflows/ # CI/CD
|
||
└── docs/ # Documentation
|
||
```
|
||
3. **Setup environnement Windows** :
|
||
- Installer Docker Desktop
|
||
- Installer Emscripten SDK
|
||
- Tester builds multi-target (DLL/SO/WASM)
|
||
|
||
### Cette Semaine (Phase 0)
|
||
4. **Boilerplates** :
|
||
- Backend C++ minimal (CMake, WebSocket server)
|
||
- Frontend React minimal (Vite + TypeScript)
|
||
- Premier module WASM (hello world)
|
||
5. **CI/CD GitHub Actions** :
|
||
- Build automatique DLL/SO/WASM
|
||
- Deploy fly.io (backend) + Vercel (frontend)
|
||
6. **gameconfig.json initial** :
|
||
- Configuration modules basique
|
||
- Définir stratégie déploiement (client vs serveur)
|
||
|
||
### Semaine Prochaine (Phase 1)
|
||
7. **MVP fonctionnel** :
|
||
- Auth + CRUD tâches
|
||
- scheduler.wasm opérationnel
|
||
- PWA déployée et accessible
|
||
|
||
---
|
||
|
||
## Notes
|
||
|
||
### Principes de Design
|
||
- Ce projet répond à un besoin personnel réel
|
||
- La proactivité de l'IA est **critique** (pas juste un assistant réactif)
|
||
- L'hyperfocus est le problème #1 à résoudre
|
||
- Commercialisation = bonus, pas l'objectif principal du MVP
|
||
|
||
### Contraintes Retenues (Draft)
|
||
- 🎯 **Dev 100% Windows** (confort dev prioritaire)
|
||
- 🎯 **Cross-platform automatique** (Docker + WASM)
|
||
- 🎯 **Mobile via PWA** (pas de dev natif Android/iOS)
|
||
- 🎯 **Coûts minimaux** (70% client-side processing)
|
||
- 🎯 **Pipeline stable** (GitHub Actions, zéro surprise)
|
||
|
||
### Décisions Architecturales Proposées (À valider)
|
||
1. **Modules C++ partagés** : 1 codebase → DLL/SO/WASM
|
||
2. **Client-first** : Déporter calculs sur client pour économiser serveur
|
||
3. **PWA installable** : Équivalent app native sans complexité dev
|
||
4. **gameconfig.json** : Configuration flexible du déploiement
|
||
|
||
---
|
||
|
||
**Status:** 📐 **Architecture Hybride Proposée** - En phase de conception et validation (POC requis)
|
||
**Version:** 0.4 - Architecture Hybride Proposée (Hypothétique)
|
||
**Date:** 27 octobre 2025
|
||
|
||
### Proposition Architecturale (À Valider)
|
||
|
||
**Architecture Proposée : Hybride WarFactory + Multi-Target Conditionnel**
|
||
|
||
**Concept (Hypothétique) :**
|
||
- Un seul code C++ (IModule WarFactory)
|
||
- Compilé en 3 targets : DLL (dev local OBLIGATOIRE), SO (serveur CONDITIONNEL), WASM (browser CONDITIONNEL)
|
||
- Deux modes de déploiement : `local_dev` (Phase 1 MVP OBLIGATOIRE) et `production_pwa` (Phase 3 CONDITIONNELLE)
|
||
|
||
**Avantages validés Phase 1 :**
|
||
- ✅ Réutilise WarFactory (économie 3-4 semaines validée)
|
||
- ✅ Hot-reload 0.4ms en mode local (validé WarFactory)
|
||
- ✅ $0 coût en mode local (garanti)
|
||
- ✅ Types stricts C++ (validé)
|
||
|
||
**Avantages hypothétiques Phase 3 (À valider Phase 2) :**
|
||
- ⚠️ Évolution progressive vers cloud si besoin (hypothétique)
|
||
- ⚠️ Multi-target DLL/SO/WASM viable (à tester)
|
||
|
||
**Questions ouvertes avant implémentation :**
|
||
- ⚠️ Faisabilité réelle compilation multi-target (DLL/SO/WASM) ?
|
||
- ⚠️ Complexité CMakeLists.txt multi-target supportable ?
|
||
- ⚠️ Performance WASM réellement acceptable (~2x C++ natif) ?
|
||
- ⚠️ Effort réel intégration React + WASM ?
|
||
- ⚠️ gameconfig.json peut vraiment basculer entre modes sans friction ?
|
||
|
||
### Prochaines Étapes
|
||
|
||
**🎯 PRIORITÉ ABSOLUE - Phase 1 (Mode local_dev uniquement) :**
|
||
|
||
1. **Setup Phase 0** :
|
||
- Interfaces WarFactory
|
||
- Structure projet modules/
|
||
- CMakeLists.txt DLL Windows uniquement (PAS multi-target encore)
|
||
- gameconfig.json mode `local_dev` uniquement
|
||
|
||
2. **Implémentation Phase 1** :
|
||
- aissia-core.exe (WarFactory engine)
|
||
- 6 modules DLL (monitoring, scheduler, ai, voice, storage, ui-imgui)
|
||
- Validation dogfooding usage personnel
|
||
|
||
**⚠️ SEULEMENT si Phase 1 complète ET besoin mobile confirmé → Phase 2 (POC WASM)**
|
||
|
||
**Phase 2 (Validation multi-target) - CONDITIONNEL :**
|
||
- POC hello-world .dll + .wasm
|
||
- Benchmark performance WASM vs DLL
|
||
- Décision Go/No-Go pour Phase 3
|
||
|
||
**Phase 3+ - CONDITIONNEL (Dépend résultat Phase 2)**
|
||
|
||
### État Actuel
|
||
|
||
- 📝 CDC rédigé avec architecture hybride proposée (v0.4)
|
||
- 📝 Alternatives analysées et documentées (AlternativesAnalysis.md)
|
||
- 📚 Documentation WarFactory copiée dans docs/
|
||
- 📝 Retour externe Claude reçu et intégré
|
||
- 📝 Section risques techniques ajoutée
|
||
- ⏸️ **Phase 1 (local_dev) validée** : Architecture WarFactory DLL prouvée
|
||
- ⚠️ **Phases 2-3 (multi-target) hypothétiques** : POC requis avant engagement
|
||
- ⏸️ **Pas encore d'implémentation** : Conception et validation uniquement
|
||
|
||
### Notes Importantes
|
||
|
||
- **✅ Phase 1 = GO** : Mode `local_dev` est validé et sera implémenté
|
||
- **⚠️ Phases 2-3 = CONDITIONNEL** : Multi-target reste hypothétique jusqu'à POC Phase 2
|
||
- **Ne PAS setup Emscripten/Docker avant Phase 2** : Éviter complexité prématurée
|
||
- **Architecture multi-target = proposition, pas garantie** : Peut être abandonnée
|
||
- **Focus MVP Phase 1** : Livrer version locale fonctionnelle d'abord
|
||
- **Accepter local_dev seul comme succès** : Si multi-target invalide, pas un échec
|