ti-pote/docs/roadmap.md

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 2            Phase 3           Phase 4
Setup &          Conversation      Services           Intelligence      Expansion
Infra            vocale            métier             avancée
─────────────────────────────────────────────────────────────────────────────────►
[2-3 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 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
• Domotique (Home Assistant, Philips Hue…)

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