Construire un pipeline vocal temps réel : de l'audio brut à la réponse IA
Le cœur de TAMSIV, c'est la voix. Pas un gadget — la voix EST l'interface principale. Construire un pipeline vocal temps réel en solo, c'est entrer dans un monde où chaque milliseconde compte.
L'architecture du pipeline
Audio PCM 16kHz mono → WebSocket (JWT) → Deepgram Live STT (VAD) → OpenRouter LLM → Function calling → OpenAI TTS → Audio responseL'audio doit être en PCM 16 bits, 16kHz, mono. Le téléphone envoie des chunks binaires bruts via WebSocket.
Le WebSocket authentifié
Token JWT Supabase en query string : ws://backend:3001?token=eyJhbG.... Validation à la connexion. Si le token expire en pleine conversation, reconnexion automatique avec un token frais.
Deepgram Live STT et le VAD
Le VAD (Voice Activity Detection) de Deepgram détecte quand l'utilisateur a fini de parler. Sans VAD, il faut un timeout silence côté client — trop court on coupe, trop long ça rame. Deepgram gère ça avec précision.
La difficulté : gérer les résultats intermédiaires (is_final: false) vs finaux (is_final: true). Il faut accumuler les résultats finaux pour construire la transcription complète.
L'orchestration LLM
La transcription part vers OpenRouter avec function calling. Le modèle est configurable avec fallback automatique. La latence totale : finalisation STT (~200ms) + LLM (~800ms-2s) + TTS (~500ms). Entre 1.5 et 3 secondes.
OpenAI TTS
Voix nova. L'audio est streamé en retour via le même WebSocket. Le frontend commence à jouer dès les premiers chunks, sans attendre la réponse complète.
Les leçons du temps réel
Tout peut échouer à tout moment. Retry intelligents, circuit breakers, fallbacks à chaque étape. Le pipeline est robuste aujourd'hui, mais chaque ligne de gestion d'erreur représente un bug vécu.