273 lines
12 KiB
Markdown
273 lines
12 KiB
Markdown
# Roadmap
|
|
|
|
## Vue d'ensemble
|
|
|
|
Le développement de Ti-Pote est découpé en phases progressives. Chaque phase produit un livrable fonctionnel et testable. L'objectif est de valider chaque brique avant d'empiler la suivante.
|
|
|
|
```
|
|
Phase 0 Phase 1 Phase 1.5 Phase 2 Phase 3 Phase 4
|
|
Setup & Conversation Robot Client Services Intelligence Expansion
|
|
Infra vocale & Domotique métier avancée
|
|
──────────────────────────────────────────────────────────────────────────────────────────────────►
|
|
[2-3 sem] [3-4 sem] [3-4 sem] [4-6 sem] [4-6 sem] [Continu]
|
|
```
|
|
|
|
---
|
|
|
|
## Phase 0 — Setup & Infrastructure (2-3 semaines)
|
|
|
|
### Objectif
|
|
Mettre en place tout l'environnement de développement et l'infrastructure de base pour que l'équipe puisse coder efficacement.
|
|
|
|
### Livrables
|
|
|
|
**Infra & DevOps**
|
|
- Repo Git initialisé avec la structure du projet (monorepo ou multi-repo — à décider)
|
|
- Docker Compose fonctionnel avec PostgreSQL + pgvector + Redis
|
|
- CI/CD basique (GitHub Actions : lint, tests, build)
|
|
- VPS provisionné avec Docker, Nginx, Certbot (TLS)
|
|
- Domaine configuré (ex: api.tipote.dev)
|
|
|
|
**Backend**
|
|
- Projet NestJS initialisé avec la structure hexagonale
|
|
- Configuration de base (env vars, logger, config module)
|
|
- Connexion PostgreSQL (TypeORM ou Prisma — à choisir)
|
|
- Connexion Redis
|
|
- Migrations initiales (tables User, Device, Home)
|
|
- Authentification basique (JWT, inscription/connexion)
|
|
|
|
**Frontend**
|
|
- Projet Next.js initialisé
|
|
- Page de login/inscription
|
|
- Dashboard vide (skeleton)
|
|
|
|
**Hardware** (Juliann)
|
|
- Raspberry Pi 5 configuré (OS, réseau, dépendances)
|
|
- Micro + haut-parleur fonctionnels (test audio basique)
|
|
- Script de test : enregistrer un audio et le rejouer
|
|
|
|
### Critère de validation
|
|
Un utilisateur peut s'inscrire, se connecter via l'app web, et le Pi est opérationnel avec audio fonctionnel.
|
|
|
|
---
|
|
|
|
## Phase 1 — Conversation vocale (3-4 semaines)
|
|
|
|
### Objectif
|
|
Réaliser le premier aller-retour vocal complet : l'utilisateur parle au robot, Ti-Pote comprend et répond vocalement.
|
|
|
|
### Livrables
|
|
|
|
**Robot (firmware)**
|
|
- Wake word detection avec OpenWakeWord ("Hey Ti-Pote")
|
|
- Streaming audio vers le core via WebSocket
|
|
- VAD (Voice Activity Detection) pour détecter la fin de parole
|
|
- Réception et lecture des chunks audio TTS
|
|
- Feedback LED (écoute / réflexion / parole)
|
|
|
|
**Backend**
|
|
- WebSocket Gateway NestJS pour la connexion robot
|
|
- Intégration STT (Deepgram en streaming)
|
|
- Intégration LLM (OpenAI GPT-4 ou Claude) avec system prompt
|
|
- Intégration TTS (ElevenLabs en streaming)
|
|
- ConversationService : orchestration du flux complet
|
|
- Mémoire de session (Redis) — historique de la conversation en cours
|
|
|
|
**Frontend**
|
|
- Page de configuration du device (associer un robot au compte)
|
|
- Indicateur de statut du robot (online/offline)
|
|
|
|
### Critère de validation
|
|
L'utilisateur dit "Hey Ti-Pote, raconte-moi une blague" → le robot répond vocalement avec une blague. Conversation à plusieurs tours fonctionnelle. Latence < 2 secondes.
|
|
|
|
---
|
|
|
|
## Phase 1.5 — Robot Client & Domotique (3-4 semaines)
|
|
|
|
### Objectif
|
|
Remplacer le simulateur comme client direct du backend par un vrai **robot-client** TypeScript (`apps/robot-client`) qui reflète l'architecture cible du robot physique. Ajouter le provisioning WiFi et les premières intégrations domotiques.
|
|
|
|
### Livrables
|
|
|
|
**Robot Client (`apps/robot-client`)**
|
|
- Application Node.js TypeScript qui tourne sur le Pi (ou en mode simulateur sur PC de dev)
|
|
- Communication WebSocket bidirectionnelle avec le backend cloud (même protocole que le simulateur)
|
|
- Bridge UART avec l'ESP32-S3 via `serialport` (mode physical) ou mock (mode simulator)
|
|
- Flag `ROBOT_MODE=simulator|physical` pour switcher entre les deux modes
|
|
- Intégration du wake word (OpenWakeWord via subprocess Python)
|
|
- Système de health check et heartbeat avec le backend
|
|
|
|
**WiFi Provisioning**
|
|
- Setup WiFi par BLE (méthode principale) : le robot advertise en BLE, l'app envoie les credentials
|
|
- Setup WiFi par AP mode + captive portal (fallback) : hotspot `Ti-Pote-XXXX`, portail web local
|
|
- Flux de premier démarrage (onboarding) complet : power on → WiFi → cloud → prêt
|
|
|
|
**Domotique — première intégration**
|
|
- Architecture de bridges domotiques avec interface `IAutomationBridge`
|
|
- `AutomationManager` pour orchestrer plusieurs bridges
|
|
- Bridge **Philips Hue** : découverte mDNS, appairage, contrôle des lampes (on/off, brightness, color)
|
|
- Bridge **Home Assistant** : connexion WebSocket API, listing des entités, exécution de commandes
|
|
- Bridge **MQTT** : connexion broker, support Zigbee2MQTT / Tasmota
|
|
- Découverte automatique des hubs sur le réseau local (mDNS)
|
|
- Tools LLM : `list_smart_devices`, `control_device`, `get_device_state`, `execute_scene`, `get_sensor_value`
|
|
|
|
**Simulateur (évolution)**
|
|
- Le simulateur web (`apps/simulator`) devient un frontend de debug pour le robot-client en mode simulator
|
|
- Nouvelle topologie : Browser ↔ robot-client (PC) ↔ Backend cloud
|
|
|
|
**Frontend**
|
|
- Page de configuration WiFi (pour le setup initial)
|
|
- Section domotique : bridges détectés, appairage, liste des appareils, test de commande
|
|
|
|
### Critère de validation
|
|
Le robot-client tourne sur un PC de dev en mode simulator. L'utilisateur peut parler via le simulateur web, la requête transite par le robot-client avant d'atteindre le backend. Depuis la voix, l'utilisateur peut allumer/éteindre une lampe Hue ou un appareil Home Assistant. Le setup WiFi fonctionne en AP mode sur un Pi physique.
|
|
|
|
---
|
|
|
|
## Phase 2 — Services métier & Function calling (4-6 semaines)
|
|
|
|
### Objectif
|
|
Ajouter les premiers services concrets que Ti-Pote peut appeler, et implémenter le function calling custom.
|
|
|
|
### Livrables
|
|
|
|
**Function calling**
|
|
- Système de définition et registre des tools
|
|
- Logique d'exécution des function calls dans le ConversationService
|
|
- Gestion des erreurs de function call (retry, feedback utilisateur)
|
|
|
|
**Agenda / Calendrier**
|
|
- Intégration OAuth2 Google Calendar
|
|
- Functions : create/list/update/delete events, find free slots
|
|
- Flux complet : "Mets un RDV demain à 15h" → création de l'événement → confirmation vocale
|
|
|
|
**Minuteurs & Alarmes**
|
|
- TimerAlarmService avec stockage Redis + PostgreSQL
|
|
- Notification via WebSocket quand un timer expire
|
|
- Functions : set/cancel/list timers et alarmes
|
|
|
|
**Emails**
|
|
- Intégration SMTP (envoi) + Gmail API (lecture)
|
|
- Functions : send/list/read/reply emails
|
|
- Flux complet : "Envoie un email à Pierre" → rédaction par le LLM → envoi → confirmation
|
|
|
|
**Recherche web**
|
|
- Intégration API de recherche (SearXNG ou Brave Search)
|
|
- Function : web_search, get_weather
|
|
- Flux complet : "Quel temps fait-il demain ?" → recherche → réponse vocale
|
|
|
|
**Frontend**
|
|
- Page de connexion des services (OAuth Google, config SMTP)
|
|
- Configuration du modèle LLM et de la voix TTS
|
|
- Configuration du wake word (liste prédéfinie)
|
|
|
|
### Critère de validation
|
|
L'utilisateur peut, par la voix : créer un rendez-vous, mettre un minuteur, envoyer un email, poser une question factuelle. Chaque action est confirmée vocalement.
|
|
|
|
---
|
|
|
|
## Phase 3 — Intelligence avancée (4-6 semaines)
|
|
|
|
### Objectif
|
|
Ajouter la mémoire conversationnelle, les notifications proactives, et la reconnaissance visuelle.
|
|
|
|
### Livrables
|
|
|
|
**Mémoire conversationnelle**
|
|
- Worker d'extraction de faits à la fin de chaque session
|
|
- Génération d'embeddings et stockage pgvector
|
|
- ContextBuilder avec recherche sémantique
|
|
- Profil utilisateur auto-enrichi
|
|
- Interface dans l'app pour consulter/supprimer les souvenirs
|
|
- Droit à l'oubli via la voix ("Oublie ce que je t'ai dit sur X")
|
|
|
|
**Notifications proactives**
|
|
- Scheduler de vérification (rendez-vous, météo, emails)
|
|
- Système de notification push via WebSocket
|
|
- Configuration des notifications dans l'app (types, horaires, DND)
|
|
- Résumé matinal configurable
|
|
|
|
**Reconnaissance visuelle (si module caméra)**
|
|
- Capture d'image à la demande
|
|
- Envoi au LLM vision (GPT-4V ou Claude Vision)
|
|
- Functions : capture_image, analyze_image
|
|
- OCR basique (lire du texte sur une image)
|
|
|
|
**Frontend**
|
|
- Page de mémoire (ce que Ti-Pote sait sur moi)
|
|
- Historique des conversations avec replay
|
|
- Configuration des notifications
|
|
- Dashboard enrichi (activité, stats d'usage)
|
|
|
|
### Critère de validation
|
|
Ti-Pote se souvient des conversations précédentes. "Tu te souviens du restaurant ?" → réponse pertinente. Notifications proactives fonctionnelles (rappel de RDV). Reconnaissance d'image basique ("Qu'est-ce que tu vois ?").
|
|
|
|
---
|
|
|
|
## Phase 4 — Expansion (continu)
|
|
|
|
### Objectif
|
|
Améliorer, étendre et polish le produit. Cette phase est continue et n'a pas de fin définie.
|
|
|
|
### Chantiers prévus
|
|
|
|
**Intégrations supplémentaires**
|
|
- Apple Calendar (CalDAV)
|
|
- Microsoft Outlook (Graph API)
|
|
- WhatsApp Business API
|
|
- Telegram Bot API
|
|
- Spotify / services de musique
|
|
- Nouveaux bridges domotiques (Matter/Thread, Apple HomeKit, Tuya, KNX…)
|
|
|
|
**Mobilité**
|
|
- Firmware pour le module base mobile
|
|
- Communication Pi ↔ Arduino pour le contrôle moteur
|
|
- Commandes vocales de déplacement
|
|
- Navigation basique (évitement d'obstacles)
|
|
|
|
**Multi-utilisateur**
|
|
- Reconnaissance vocale par utilisateur (voice fingerprint)
|
|
- Gestion des permissions par Home
|
|
- Profils et mémoire séparés par utilisateur
|
|
|
|
**App mobile**
|
|
- React Native (ou Expo)
|
|
- Push notifications sur le téléphone
|
|
- Configuration et monitoring du robot à distance
|
|
|
|
**Améliorations UX**
|
|
- Wake word personnalisable (fine-tuning de modèle)
|
|
- Personnalité configurable de Ti-Pote
|
|
- Animations et expressions sur l'écran du robot
|
|
- Mode enfant (contenu filtré, voix adaptée)
|
|
|
|
**Sécurité et scalabilité**
|
|
- Migration vers HashiCorp Vault pour les secrets
|
|
- Rate limiting et quotas par utilisateur
|
|
- Logs d'audit
|
|
- Monitoring avancé (alerting, anomaly detection)
|
|
|
|
---
|
|
|
|
## Jalons clés
|
|
|
|
| Jalon | Phase | Description |
|
|
|-------|-------|-------------|
|
|
| "Hello World" vocal | Phase 1 | Premier aller-retour audio complet |
|
|
| Robot-client opérationnel | Phase 1.5 | Le robot-client fait le pont simulateur ↔ backend |
|
|
| "Allume la lumière" | Phase 1.5 | Ti-Pote contrôle une lampe Hue ou un device HA par la voix |
|
|
| Setup WiFi autonome | Phase 1.5 | Le robot se configure sur un réseau WiFi via AP mode ou BLE |
|
|
| Premier function call | Phase 2 | Ti-Pote crée un événement dans Google Calendar |
|
|
| "Tu te souviens ?" | Phase 3 | Ti-Pote retrouve un souvenir d'une conversation passée |
|
|
| Notification proactive | Phase 3 | Ti-Pote rappelle un RDV sans qu'on lui demande |
|
|
| Robot mobile | Phase 4 | Ti-Pote se déplace dans la pièce |
|
|
| Multi-user | Phase 4 | Plusieurs personnes utilisent Ti-Pote dans un foyer |
|
|
|
|
## Principes de développement
|
|
|
|
1. **Itérer vite** — Chaque phase produit quelque chose de testable. Pas de "big bang release".
|
|
2. **Tester en conditions réelles** — Dès la Phase 1, le robot doit être utilisé quotidiennement pour découvrir les vrais problèmes (latence, bruit, faux positifs du wake word…).
|
|
3. **Mesurer** — Logger la latence, le taux de succès STT, les erreurs de function call. Les métriques guident les priorités.
|
|
4. **Documenter au fur et à mesure** — Pas de "on documentera plus tard". Chaque feature est documentée à sa livraison.
|
|
5. **Software d'abord** — La plupart des features peuvent être testées sans le robot physique (via un client WebSocket de test, un micro de PC, etc.). Ne pas bloquer le dev software sur le hardware.
|