Gemini 3.5 Transcribe sépare enfin la voix en temps réel et l’audio enregistré

Google a lancé Gemini 3.5 Transcribe, un modèle de speech-to-text pensé pour les interfaces vocales en direct et l’audio enregistré, avec deux points d’entrée séparés. D’un côté, gemini-3.5-transcribe-live pour le streaming bidirectionnel via Live API ; de l’autre, gemini-3.5-transcribe pour les fichiers préenregistrés via Interactions API. Ce choix compte pour les équipes produit, car les deux voies n’offrent ni les mêmes fonctions, ni les mêmes limites, ni les mêmes prix.

Deux API, deux usages, et deux compromis à assumer

La Live API vise la transcription continue avec une latence annoncée comme inférieure à la seconde. Elle renvoie des transcriptions partielles pendant que l’utilisateur parle, puis une version finale une fois le tour de parole terminé. En face, l’Interactions API s’adresse à l’audio stocké et ajoute des fonctions plus lourdes pour l’exploitation des données, comme la diarisation des locuteurs — c’est-à-dire l’identification de qui parle quand — et les horodatages mot à mot.

Ce découpage n’est pas anodin. Les sessions Live sont limitées à 10 minutes de streaming continu, sans diarisation ni timestamps au niveau du mot. Les requêtes Interactions acceptent jusqu’à une heure d’audio, mais ce plafond tombe à 30 minutes dès que la diarisation ou les timestamps sont activés. Dans ce contexte, Google oblige presque à choisir entre fluidité en temps réel et transcript exploitable pour l’audit. Le modèle ne fait pas de magie, il fait de l’arbitrage.

Le mode smart simplifie la lecture, pas la vie des développeurs

Chaque endpoint expose deux modes. Le mode verbatim conserve les hésitations, répétitions et débuts de phrase abandonnés ; le mode smart les nettoie, corrige les auto-réparations orales et applique une mise en forme plus structurée. L’exemple documenté par Google est parlant : une phrase truffée de « um », « uh » et d’hésitations ressort en version nette et compacte.

Mais cette propreté a un coût fonctionnel. Smart ne peut pas être combiné avec les timestamps mot à mot ni avec la diarisation. Autrement dit, un transcript lisible et un transcript forensique deviennent deux appels différents. Pour les centres de contact, la santé, le juridique ou l’assurance, ce détail change la façon de concevoir les pipelines.

Des performances solides, mais à lire avec le bon périmètre

Google cite, via Artificial Analysis, un taux moyen d’erreur de mots de 4,0 % en streaming et 2,6 % en non-streaming. Sur le benchmark multilingue FLEURS, le modèle affiche 5,50 % en streaming et 5,04 % en non-streaming, toujours selon les chiffres communiqués. Par rapport à Chirp 3, le précédent modèle de transcription de Google, le temps jusqu’au résultat final s’améliore de 70 %.

La couverture linguistique dépasse 85 langues et prend en charge le code-switching en cours de phrase, sans configuration spécifique. Pour les usages mondiaux, c’est un vrai confort opérationnel. Cela évite à une équipe produit de jouer au chef d’orchestre à chaque changement de langue dans une même conversation.

Une brique déjà branchée sur plusieurs outils

Le Live API est déjà intégré à LiveKit, Pipecat, Agora, Fishjam, Vercel et Vision Agents. Côté produits grand public, Google indique que le modèle alimente Rambler sur Android, l’application Gemini sur macOS et Google Antigravity, tandis que Chrome est annoncé « coming soon ». Le message est clair : la technologie ne reste pas au stade du labo, elle cherche déjà sa place dans des interfaces existantes.

Reste un autre point de travail pour les équipes : l’accès est API-only. Aucun poids ouvert, aucun hébergement autonome. Les développeurs peuvent démarrer via le niveau gratuit de Google AI Studio, les équipes intermédiaires passer sur l’offre payante, et les entreprises réglementées sur Gemini Enterprise Agent Platform, qui ajoute des contrôles de conformité et du throughput provisionné. Les deux parcours sont en public preview, donc avec la prudence qui va avec.