Gemini 3.5 Transcribe sépare le direct du verbatim précis
Google a lancé Gemini 3.5 Transcribe le 26 août 2026 sous la forme de deux modèles spécialisés. Le journal des versions de Gemini API associe le modèle non streaming aux fichiers et aux annotations détaillées, tandis que la variante Live reçoit un flux audio bidirectionnel et renvoie des transcriptions intermédiaires puis finalisées.
Les développeurs peuvent donc déjà accéder au service, mais son statut est présenté de deux façons. Le journal des versions le classe en disponibilité générale, alors que le compte rendu de 9to5Google, reprenant les informations de lancement, parle d’une préversion publique dans Gemini API via Google AI Studio et sur la plateforme Gemini Enterprise Agent. Cette divergence de libellé ne change pas la décision technique immédiate : le direct et le traitement de fichiers ne donnent pas accès au même résultat.
Deux points d’accès pour deux contrats de sortie
Live API privilégie le délai de réponse. Le modèle gemini-3.5-transcribe-live reçoit l’audio en continu par WebSocket et produit du texte pendant que la personne parle. Il convient ainsi aux sous-titres instantanés, aux interfaces vocales et aux applications qui doivent réagir avant la fin d’un enregistrement.
Interactions API privilégie le relevé structuré. Le modèle gemini-3.5-transcribe traite un fichier déjà constitué. La fiche technique de Gemini 3.5 Transcribe réserve à ce parcours les horodatages par mot et la diarisation, absents du direct; elle indique aussi une détection automatique dans plus de 85 langues pour les deux variantes.
- Texte progressif pendant la parole : Live API.
- Attribution des interventions à des locuteurs : Interactions API.
- Alignement du texte avec l’audio mot par mot : Interactions API.
- Traitement d’un enregistrement long : Interactions API, dans les limites propres aux annotations demandées.
Le parcours fichier n’est donc pas une simple version différée du flux live. Il fournit des métadonnées différentes, destinées à une archive, à un éditeur de transcription ou à une recherche précisément alignée sur l’enregistrement.
La durée impose parfois un second traitement
Une session Live est limitée à dix minutes. Le traitement d’un fichier accepte jusqu’à une heure d’audio par requête, mais le plafond tombe à trente minutes lorsque la diarisation ou les horodatages par mot sont activés. La durée disponible dépend donc non seulement du point d’accès, mais aussi du niveau de détail demandé.
Pour une conversation prolongée, l’application doit renouveler les sessions Live et gérer elle-même la continuité entre les segments. Les résultats provisoires, les coupures de session et l’état affiché à l’utilisateur ne deviennent pas automatiquement un document continu du seul fait d’une reconnexion.
Un enregistrement de cinquante minutes peut être traité en une requête si seule la transcription textuelle est nécessaire. Le même fichier dépasse la limite enrichie dès que le produit réclame des repères par mot ou une séparation des locuteurs. Une segmentation devient alors nécessaire, avec un travail supplémentaire pour raccorder le texte et les interventions aux frontières des extraits.
Une application de réunion peut par conséquent combiner les deux parcours : Live API alimente les sous-titres pendant l’échange, puis l’enregistrement complet passe par Interactions API pour produire une version attribuée et horodatée. Ce double traitement est une conséquence directe des capacités distinctes, pas une obligation imposée à tous les usages.
Le direct ne produit pas le verbatim enrichi
Les deux modèles prennent en charge la transcription dite « Smart », qui retire notamment des hésitations et met le texte en forme pour le rendre plus lisible. Cette sortie répond à un autre contrat qu’un verbatim : elle transforme volontairement certains éléments de la formulation orale au lieu de les conserver mot pour mot.
Pour un relevé littéral, le traitement de fichiers propose le mode verbatim. C’est dans ce parcours que les mots peuvent être associés à leurs positions temporelles et que les prises de parole peuvent être attribuées. La documentation précise toutefois que les horodatages par mot peuvent dégrader la précision de la transcription et que l’attribution à partir de trois locuteurs reste expérimentale, bien que la fonction accepte jusqu’à huit locuteurs.
Le mot « précis » recouvre donc deux besoins qu’il faut distinguer. Une application interactive cherche d’abord un texte disponible rapidement; une archive exploitable cherche un alignement temporel et une attribution détaillée. Le second résultat n’est pas obtenu en activant une option du flux Live : il nécessite le modèle destiné aux fichiers.
Un accès ouvert, mais un statut encore présenté de deux façons
Au lancement, Gemini 3.5 Transcribe était utilisable dans Gemini API via Google AI Studio et dans Google Antigravity; Google indiquait également un accès pour les entreprises sur Gemini Enterprise Agent Platform. En revanche, les pages publiques consultées ne concordent pas sur l’étiquette de cycle de vie : disponibilité générale dans le journal des versions, préversion publique dans les informations de lancement reprises par la presse spécialisée.
Cette incohérence invite à ne pas déduire du seul sigle « GA » ou « preview » des garanties non documentées sur la stabilité contractuelle. Les frontières fonctionnelles, elles, sont explicites : dix minutes par session Live, jusqu’à une heure pour un fichier sans annotations avancées, trente minutes avec diarisation ou horodatages, et aucune de ces deux fonctions dans le flux direct.
L’état de l’histoire est donc double. Le service est accessible et ses deux points d’entrée sont documentés, mais Google devra harmoniser le statut affiché dans ses propres pages. Pour les développeurs, l’incompatibilité décisive est déjà connue : une transcription immédiate et un verbatim enrichi relèvent de deux traitements distincts.
À lire aussi:
Abonnez-vous à notre newsletter
Recevez directement les dernières actualités sur le Web3, l’IA et les cryptomonnaies.