# 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.