expria-frontend/docs/adr/007-deepgram-vs-gemini-eo-live.md

ADR 007 — Migration architecture audio EO Live : Gemini Live → Deepgram

Statut : Accepté Date : 2026-07-02 Décideur : Hermann

---

Contexte

L'Expression Orale Live (T1 + T2) repose depuis les Sprints 6-7 sur Gemini Live (modèle audio-à-audio natif, geminiLive.ts côté backend). Cette architecture présente un défaut rédhibitoire : une transcription de mauvaise qualité qui biaise systématiquement les corrections DeepSeek vers la sévérité (FTD-46) — un problème de fiabilité produit, pas cosmétique, sur un service qui évalue un examen officiel. Gemini pose également des questions de relance sans lien avec le discours du candidat (FTD-45, T1 Live). Ces deux défauts sont eux-mêmes une extension de la dette backend TD-23 (en VAD manuel, inputTranscription n'est flushé qu'à activityEnd, donc sans transcription token-par-token fiable pour ancrer les relances).

Un test comparatif (POC) a été mené entre l'architecture actuelle et une architecture découplée Deepgram (STT nova-3 + DeepSeek LLM + TTS Aura-2), pour évaluer si ces défauts sont propres à Gemini ou inhérents au produit.

Résultats du test comparatif (POC)

• Transcription : à débit de parole lent du candidat, Deepgram approche la perfection sur la tâche T1 Live (quasi 100 %). Gemini produit des confusions de langue et des omissions de phrases entières en conditions réelles.
• Relances/interruptions : Deepgram (LLM + orchestration) pose des questions ancrées sur le discours réel du candidat, contrairement à Gemini qui relance hors-sujet.
• Coût : Deepgram + DeepSeek + Aura-2 ≈ 0,015-0,020 $/session de 2 min vs Gemini Live ≈ 0,075-0,080 $/session — 4-5x moins cher. Réserve : tarifs volatils, le calcul Gemini n'inclut pas la réaccumulation de contexte par tour — à revérifier avant tout engagement budgétaire.
• Seul point faible identifié : débit vocal Aura-2 FR légèrement lent et non naturel à T2, aucun paramètre de vitesse fiable trouvé sans risque de régression. Jugé préférable malgré tout à un débit naturel qui s'accompagne de confusions de langue et d'omissions de phrases côté Gemini — compromis assumé, pas un point bloquant.
• Détail d'implémentation validé sur le POC (Fable 5, agent de code) : succès one-shot sur T1 (contrainte d'ancrage sur tout le monologue, point d'échec de Gemini) ; T2 a nécessité du debug itératif mais les causes étaient des artefacts d'exécution (build obsolète), pas des limites structurelles.

Options envisagées

Option A — Statu quo : Gemini Live

• Avantages : modèle unique audio-à-audio natif, pas d'orchestration multi-service, déjà en production (T1 + T2 livrés Sprints 6-7).
• Inconvénients : transcription de qualité inégale biaisant systématiquement les corrections DeepSeek vers la sévérité (FTD-46) ; relances hors-sujet en T1 (FTD-45) ; caveat TD-23 (flush transcription à activityEnd seulement) bloquant l'affichage incrémental prévu au Sprint 7e.

Option B — Architecture découplée Deepgram (STT nova-3 + DeepSeek LLM + TTS Aura-2)

• Avantages : transcription quasi parfaite à débit lent (T1), relances ancrées sur le discours réel du candidat, coût 4-5x inférieur, nativement streaming (résout TD-23 sans contournement), POC one-shot réussi sur T1.
• Inconvénients : complexité d'orchestration accrue (3 services au lieu d'1), débit vocal Aura-2 FR légèrement lent/non naturel à T2 (aucun paramètre de vitesse fiable trouvé), T2 a nécessité du debug itératif (causes non structurelles), tarifs à revérifier avant engagement budgétaire.

Décision

Option B — migration actée de Gemini Live vers Deepgram, pour T1 ET T2 Live.

Plan d'implémentation en deux temps

1. Temps 1 — Construction en parallèle : construire le module Deepgram à côté de Gemini Live, activé par un flag EO_STT_PROVIDER=gemini|deepgram, pour permettre des tests comparatifs en conditions réelles avant toute bascule définitive.
2. Temps 2 — Bascule + retrait : une fois la comparaison validée, bascule complète sur Deepgram et retrait du code Gemini Live (geminiLive.ts et son usage dans t1live.ts / t2live.ts côté backend).

Clause de non-maintien à long terme : le flag EO_STT_PROVIDER est un outil de transition de sprint, pas une fonctionnalité permanente. Aucune intention de maintenir les deux architectures en parallèle à long terme.

Conséquences

Positives :

• Résout FTD-45 et FTD-46 à la racine.
• Résout également le caveat TD-23 du Sprint 7e (flush inputTranscription à activityEnd seulement) — Deepgram est nativement streaming, l'affichage incrémental candidat devient possible sans contournement.

Négatives :

• Complexité d'orchestration accrue pendant la phase de transition (3 services au lieu d'1) — mitigée par le fait que le flag est temporaire, pas un choix d'architecture permanent à deux branches.
• Travail de retrait à prévoir en fin de migration : suppression du code Gemini Live une fois Deepgram validé (hors scope de cette session doc-only).

À revisiter si :

• Les tarifs Deepgram / DeepSeek / Aura-2 évoluent défavorablement (réserve explicite sur la volatilité tarifaire et sur le calcul Gemini incomplet ci-dessus).
• Un paramètre de vitesse Aura-2 FR fiable devient disponible (lèverait le seul point faible identifié).

Références

• TECH_DEBT.md FTD-45, FTD-46 (renvoi vers cet ADR), FTD-47
• ROADMAP.md Sprint 7c (migration, à planifier en détail dans une session dédiée)
• expria-backend/docs/TECH_DEBT-backend.md TD-22, TD-23 (dette backend directement concernée — non modifiée dans cette session, dépôt séparé)