# 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é)