12 KiB
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|physicalpour 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 AutomationManagerpour 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
- Itérer vite — Chaque phase produit quelque chose de testable. Pas de "big bang release".
- 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…).
- Mesurer — Logger la latence, le taux de succès STT, les erreurs de function call. Les métriques guident les priorités.
- Documenter au fur et à mesure — Pas de "on documentera plus tard". Chaque feature est documentée à sa livraison.
- 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.