674109ea22
Monorepo pnpm avec NestJS backend en architecture hexagonale. - Structure hexagonale complète (ports, adapters, domain entities) - 9 entities TypeORM (Home, User, Device, Credentials, Session, Message, Memory, Timer) - Migration initiale SQL avec pgvector support - Docker Compose (PostgreSQL 16 + pgvector + Redis 7) - Config partagée (tsconfig, ESLint, Prettier) - Outbound ports définis (STT, TTS, LLM, Cache, Storage, VectorStore) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
228 lines
8.7 KiB
Markdown
228 lines
8.7 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 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.
|