STT natif vs Deepgram : quel moteur vocal choisir ?

Quand j'ai lancé TAMSIV, toute la reconnaissance vocale passait par Deepgram. Un service cloud excellent, précis, rapide. Le français ? Impeccable. Les accents régionaux ? Gérés. La ponctuation automatique ? Parfaite. Il y avait juste un détail : chaque seconde d'audio transcrite avait un prix. Et quand ton app repose entièrement sur la voix, ce prix grimpe vite.

J'ai donc dû faire un choix stratégique : soit je maintiens Deepgram pour tout le monde et je répercute le coût sur les abonnements, soit je trouve une alternative gratuite pour le plan Free et je réserve Deepgram aux utilisateurs payants. J'ai choisi la deuxième option. Voici comment j'ai construit une architecture duale STT natif + Deepgram, et ce que j'ai appris en comparant les deux en conditions réelles.

Points clés à retenir :
- Le STT natif (Google/Apple) est gratuit, local et suffisant pour des dictées courtes
- Deepgram reste supérieur en précision, surtout dans le bruit et avec des accents
- Une architecture duale permet d'offrir un plan gratuit viable sans sacrifier la qualité premium
- L'abstraction frontend fait que les composants ignorent quel moteur tourne
- Le choix STT natif vs cloud est configurable par l'admin sans mise à jour de l'app

Pourquoi la reconnaissance vocale est-elle si centrale dans une app de productivité ?

TAMSIV n'est pas une app de productivité classique où tu tapes des listes. C'est une app où tu parles. Tu dictes une tâche, un mémo, un événement. L'assistant vocal comprend ce que tu dis, crée l'élément, et te répond. Tout passe par la voix.

Ça veut dire que la qualité de la transcription impacte directement l'expérience. Si le STT comprend mal "acheter du pain" et transcrit "acheter du bain", l'utilisateur perd confiance. Si la ponctuation est absente, le mémo devient un bloc de texte illisible. Le STT n'est pas un gadget — c'est le fondement de toute l'expérience utilisateur.

C'est pourquoi j'ai passé du temps à construire le pipeline vocal complet avec soin. Le STT est la première étape de la chaîne : Audio → STT → Texte → LLM → Function Calling → TTS → Audio. Si la première étape échoue, tout le reste s'effondre.

Comment fonctionne le STT natif sur Android et iOS ?

Chaque smartphone moderne embarque un moteur de reconnaissance vocale. Sur Android, c'est le SpeechRecognizer de Google. Sur iOS, c'est le Speech framework d'Apple. Ces moteurs sont intégrés au système d'exploitation et fonctionnent localement — aucune donnée ne quitte le téléphone.

Les avantages sont clairs :

• Gratuit : Pas de coût par seconde, pas de limite de requêtes, pas de facture surprise.
• Local : Les données vocales restent sur le device. Parfait pour la confidentialité.
• Rapide : Pas de latence réseau. La transcription commence quasi-instantanément.
• Hors ligne : Fonctionne même sans connexion internet (avec les modèles téléchargés).

Mais il y a des limites. Le STT natif n'est pas conçu pour des cas d'usage professionnels. La ponctuation est souvent absente ou approximative. La précision baisse significativement dans un environnement bruyant. Et pour le français avec des accents (québécois, africain, belge), les résultats varient beaucoup.

Qu'est-ce que Deepgram apporte de plus ?

Deepgram est un service de STT cloud spécialisé. Son modèle Nova-2 est entraîné sur des milliards d'heures d'audio et offre une précision remarquable. Voici ce qui le distingue du STT natif :

• Ponctuation automatique : Les phrases sont correctement ponctuées, ce qui rend les mémos immédiatement lisibles.
• VAD (Voice Activity Detection) : Deepgram détecte quand tu parles et quand tu fais une pause. Pas de transcription du bruit ambiant.
• Streaming WebSocket : L'audio est transcrit en temps réel via WebSocket, mot par mot. L'utilisateur voit sa dictée apparaître au fur et à mesure.
• Multi-langues natif : Le français, y compris avec des accents, est bien supporté.
• Endpointing intelligent : Deepgram sait quand tu as fini de parler, ce qui déclenche le traitement LLM au bon moment.

Le coût ? Environ $0.0043 par minute d'audio en streaming. Ça paraît peu, mais pour une app vocale où chaque interaction dure 10 à 30 secondes, ça s'additionne vite avec des centaines d'utilisateurs actifs.

Comment j'ai conçu l'architecture duale dans TAMSIV ?

L'objectif était clair : offrir deux moteurs STT interchangeables, sans que le code de l'interface ait besoin de savoir lequel tourne. Le pattern est celui de l'abstraction — une interface commune, deux implémentations.

Côté frontend (React Native), j'expose une interface unifiée :

// Interface commune
interface STTEngine {
  start(): void;
  stop(): void;
  onResult(callback: (text: string) => void): void;
  onError(callback: (error: Error) => void): void;
}

// Deux implementations
class NativeSTTEngine implements STTEngine { ... }
class DeepgramSTTEngine implements STTEngine { ... }

Le choix du moteur est déterminé par deux facteurs :

1. Le plan de l'utilisateur : Free → natif, Pro/Team → Deepgram (configurable).
2. La configuration admin : Via la table app_config dans Supabase, je peux forcer un moteur pour tous les utilisateurs. Utile pour les tests A/B ou en cas de problème avec un provider.

Les composants UI (le Dictaphone, l'écran de conversation) ne savent pas quel moteur tourne. Ils appellent start(), stop(), et reçoivent du texte. C'est le principe de responsabilité unique appliqué au pipeline vocal.

Quels sont les résultats de la comparaison en conditions réelles ?

J'ai testé les deux moteurs sur trois scénarios concrets, avec le même contenu dicté en français :

Scénario	STT natif	Deepgram
Environnement calme	~92%	~98%
Bruit de fond (café, rue)	~75%	~94%
Français avec accents	~80%	~95%
Dictée rapide (>150 mots/min)	~70%	~93%

Le verdict est sans appel : Deepgram est objectivement supérieur dans tous les scénarios. L'écart se creuse particulièrement dans les environnements bruyants et avec les accents. La ponctuation automatique de Deepgram est un avantage énorme pour les mémos vocaux — un mémo sans ponctuation est un bloc de texte pénible à relire.

Mais — et c'est la nuance importante — pour dicter une tâche courte ("Acheter du lait demain matin"), le STT natif est suffisant. Dans un environnement calme, 92% de précision sur une phrase de 5 mots, ça fonctionne. L'utilisateur peut toujours éditer le texte après la création vocale.

Comment cette architecture sert-elle le modèle économique ?

L'architecture duale n'est pas qu'une prouesse technique — c'est un choix business. Elle permet trois choses :

1. Un plan Free viable : L'utilisateur gratuit peut utiliser la voix sans que ça me coûte quoi que ce soit en STT. Le coût est zéro car le traitement est local.
2. Un argument pour le premium : "Tu veux une meilleure précision, surtout dans le bruit ? Passe Pro." L'utilisateur qui a essayé le natif et qui veut mieux a une raison concrète de payer. C'est le même principe que j'applique aux abonnements RevenueCat.
3. Un fallback de sécurité : Si Deepgram a une panne (ça arrive), je peux basculer tous les utilisateurs sur le natif en changeant une valeur dans app_config. Pas de mise à jour de l'app nécessaire. C'est le même pattern de fallback que j'utilise pour le LLM via OpenRouter.

Quelles sont les difficultés techniques de l'intégration STT natif en React Native ?

Intégrer le STT natif dans React Native n'est pas trivial. Voici les problèmes que j'ai rencontrés :

• API différentes Android/iOS : Le SpeechRecognizer Android et le Speech framework iOS ont des APIs complètement différentes. La librairie React Native que j'utilise abstrait une partie de ces différences, mais pas tout.
• Gestion du lifecycle : Sur Android, le SpeechRecognizer doit être correctement nettoyé quand l'app passe en arrière-plan. Sinon, il continue d'écouter et consomme de la batterie. J'ai dû ajouter des listeners sur l'AppState pour gérer ça.
• Timeout de sécurité : Le STT natif peut rester bloqué en état "listening" indéfiniment. J'ai ajouté un timeout de 30 secondes (le même pattern que dans l'AudioPlayerService) avec cleanup automatique.
• Pas de streaming fiable : Contrairement à Deepgram qui envoie les mots au fur et à mesure, le STT natif retourne des résultats partiels qui peuvent être contradictoires. J'ai dû implémenter un debounce pour éviter le "flickering" du texte affiché.

Comment configurer le choix STT à distance sans déployer ?

Un des avantages de cette architecture, c'est la configurabilité à distance. Dans Supabase, j'ai une table app_config qui stocke des paramètres globaux de l'application. Le choix du moteur STT est l'un d'eux.

Quand l'app démarre, elle lit la config depuis Supabase (ou depuis le cache, grâce au ContentCacheService). Si la config dit "natif pour tous", même les utilisateurs Pro utilisent le natif. C'est utile dans plusieurs cas :

• Panne Deepgram : Basculer instantanément sans mise à jour.
• Tests A/B : Comparer les métriques de rétention entre les deux moteurs sur un panel d'utilisateurs.
• Réduction de coûts temporaire : Si le budget cloud est serré un mois donné, je peux désactiver Deepgram temporairement.

Le dashboard admin affiche les métriques d'utilisation par moteur STT, ce qui permet de prendre des décisions informées.

Quel est le futur du STT dans les apps mobiles ?

Le paysage du STT évolue rapidement. Whisper d'OpenAI a démocratisé les modèles STT open-source de haute qualité. Des projets comme whisper.cpp permettent de faire tourner Whisper directement sur mobile, avec une qualité proche de Deepgram et zéro coût cloud.

Je surveille cette évolution de près. Le jour où un modèle Whisper tourne suffisamment bien sur un smartphone standard avec le support du français en temps réel, le STT cloud deviendra optionnel pour tout le monde. En attendant, l'architecture duale que j'ai mise en place est parfaitement positionnée pour intégrer un troisième moteur sans toucher aux composants UI.

FAQ

Le STT natif fonctionne-t-il hors ligne ?

Oui, à condition que le modèle de langue soit téléchargé sur le device. Sur Android, Google propose le téléchargement des modèles vocaux dans les paramètres. Sur iOS, les modèles sont généralement déjà présents. La qualité hors ligne est légèrement inférieure à la version en ligne.

Deepgram est-il le meilleur service STT cloud ?

Deepgram Nova-2 est parmi les meilleurs pour le rapport qualité/prix. Google Cloud Speech-to-Text et AWS Transcribe sont des alternatives sérieuses. J'ai choisi Deepgram pour son API WebSocket native et sa facturation à la seconde (pas à la minute).

L'utilisateur peut-il choisir son moteur STT ?

Actuellement, le choix est lié au plan (Free = natif, Pro = Deepgram). À terme, je prévois d'ajouter un toggle dans les paramètres pour que l'utilisateur Pro puisse choisir le natif s'il préfère la confidentialité locale.

Comment gérer les langues autres que le français ?

TAMSIV supporte 6 langues. Le STT natif et Deepgram supportent tous les deux ces langues. La détection de la langue est basée sur les paramètres de l'app (pas de détection automatique), ce qui évite les confusions entre langues proches.

Le STT natif consomme-t-il beaucoup de batterie ?

Moins que le STT cloud, car il n'y a pas de transfert réseau. Mais le traitement local utilise le processeur du téléphone. Sur une dictée courte (30 secondes), l'impact est négligeable. Sur une dictée longue (5+ minutes), le STT natif peut consommer plus de batterie que le cloud car le processeur tourne en continu.