ti-pote/docs/roadmap.md
ordinarthur 4ac7bd16d2 add doc
2026-04-01 17:10:18 +02:00

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