Avatar & TTS : un tuteur IA parlant en temps réel

Comment ça fonctionne (single-provider)

L'avatar est opt-in par cours et utilise un seul fournisseur pour la voix et la vidéo, ce qui évite toute désynchronisation audio/lèvres ainsi qu'une étape TTS séparée :

HeyGen → LiveAvatar API (mode FULL) : le backend crée un session token et démarre une salle LiveKit ; le client se connecte à LiveKit pour la vidéo et la parole en publiant un événement speak_text dans le data channel LiveKit. HeyGen gère le TTS + la vidéo.
D-ID → clips/streams : le backend proxyfie SDP/ICE ; le tuteur parle avec du texte et D-ID se charge du TTS.

Le client se connecte en WebRTC directement au fournisseur — la vidéo ne transite jamais par le serveur de Studeia. Le backend crée uniquement la session, proxyfie speak/sdp/ice (D-ID) et enregistre l'usage à l'arrêt.

Configuration

Par tenant : connecter une clé HeyGen ou D-ID (chiffrée AES-256-GCM), tester et définir le quota mensuel de minutes.
Par cours : Course.avatarProvider, avatarId, avatarVoiceId, avatarQuality et le flag avatarEnabled. Une clé → N avatars (l'avatar est un paramètre par session).

Sécurité & quota

La master API key n'est jamais transmise au client ; seuls des tokens éphémères de session/LiveKit le sont. Speak/SDP/ICE sont proxyfiés côté serveur avec vérification de AvatarSession.userId.
Le quota mensuel (monthlyMinuteCap) est vérifié avant de démarrer la session (fail-closed → quota_exceeded). L'usage et le coût sont enregistrés dans AvatarUsageLog.
Conditions d'accès : avatarEnabled + fournisseur/avatar configuré sur le cours + inscription active + opt-in de l'apprenant.

Dégradation gracieuse

full_avatar → audio_only (TTS + image statique) → text_only, ainsi le tuteur répond toujours même si le fournisseur de l'avatar est défaillant.

Mobile

Sur mobile, l'avatar s'exécute dans une WebView qui charge la même page /avatar-embed utilisée sur le web (sans modules WebRTC natifs dans Expo) ; un bridge React Native relaie les messages de contrôle.

Pas encore disponible (roadmap)

La voix en entrée — l'apprenant parlant au tuteur (parole → STT → chat) — n'est pas implémentée. Aujourd'hui l'avatar est uniquement en sortie (tête parlante + voix).

Voir aussi

FAQ

Le tuteur IA de Studeia dispose-t-il d'un avatar parlant ?

Oui. Le tuteur peut répondre avec un avatar parlant en temps réel — vidéo plus voix avec lip-sync en direct — via WebRTC. L'établissement connecte son propre compte HeyGen (LiveAvatar) ou D-ID (BYO key chiffrée au repos), associe un avatar/une voix par cours et l'active par cours. C'est single-provider : le fournisseur gère à la fois le TTS et la vidéo, de sorte que l'audio et les lèvres restent synchronisés.

L'avatar est-il sécurisé et privé ?

La master API key du fournisseur n'atteint jamais le client — la création de session ainsi que les appels speak/SDP/ICE sont proxyfiés côté serveur avec vérification de la propriété de session ; seuls des tokens éphémères parviennent au navigateur. Les identifiants sont chiffrés AES-256-GCM, l'usage est mesuré (AvatarUsageLog) avec un quota mensuel, et l'accès dépend d'une inscription active + opt-in de l'apprenant.

Que se passe-t-il si le fournisseur de l'avatar tombe en panne ?

La dégradation est gracieuse : full_avatar → audio_only (TTS + image statique) → text_only. La voix en entrée (apprenant parlant → speech-to-text) est une fonctionnalité distincte, pas encore implémentée (roadmap) ; aujourd'hui l'avatar est uniquement en sortie.