hariri.ch
Prenez contact

Développement Intelligence artificielle

Gemini 3.5 Transcribe : ce que change le nouveau moteur de transcription vocale de Google

7 min de lecture

Une illustration abstraite montre des ondes sonores qui se transforment en flux de données structurées, avec un chemin pour la transcription en direct et un autre pour le traitement d’enregistrements.

Un nouveau modèle pensé pour deux usages distincts

Google a annoncé Gemini 3.5 Transcribe le 26 août 2026 et le présente comme son modèle de conversion parole-texte le plus précis à ce jour. En pratique, l’offre se divise en deux variantes qui répondent à des besoins différents.

Pour le temps réel, la référence est gemini-3.5-transcribe-live, exposée via la Live API. Elle vise les applications vocales interactives avec streaming bidirectionnel et une latence inférieure à la seconde selon Google. Pour l’audio préenregistré, le modèle à utiliser est gemini-3.5-transcribe, accessible via l’API de transcription audio de Gemini pour traiter des réunions, enregistrements ou journaux d’appels.

Cette séparation est importante côté architecture. Le mode live sert surtout aux assistants vocaux, agents conversationnels, sous-titrage en direct ou pipelines voix-vers-LLM. Le mode non temps réel cible davantage les workflows documentaires, la conformité, l’indexation de contenus audio et la production de comptes rendus.

Ce que le modèle apporte au-delà d’une transcription brute

Le point le plus notable n’est pas seulement la reconnaissance vocale, mais la façon dont Google structure la sortie. La documentation distingue deux modes de transcription : verbatim et smart.

Le mode verbatim, qui est le mode par défaut dans la Live API, restitue littéralement ce qui a été dit, y compris les hésitations, répétitions et faux départs. C’est le bon choix pour l’archivage fidèle, l’analyse conversationnelle ou certains usages réglementaires.

Le mode smart cherche au contraire à produire un texte plus lisible. Google indique qu’il gère les auto-corrections, supprime les mots de remplissage et applique un formatage automatique. Sur des réunions internes, des notes vocales ou des résumés d’appels, cela peut réduire le travail de nettoyage en aval.

Il faut toutefois noter une limite fonctionnelle importante : d’après la documentation, la transcription intelligente n’est pas compatible avec timestamp_granularities ni avec diarization_mode. Autrement dit, si une équipe a besoin d’un texte nettoyé et d’une segmentation détaillée par mot ou par intervenant, il faudra arbitrer ou prévoir un traitement complémentaire.

Multilingue, code-switching et vocabulaire métier : les leviers de qualité

Google indique que Gemini 3.5 Transcribe détecte et transcrit automatiquement plus de 85 langues ou locales, avec prise en charge des accents et dialectes régionaux. La documentation ajoute un point utile pour les environnements internationaux : le modèle gère le code-switching, c’est-à-dire l’alternance entre plusieurs langues au sein d’une même phrase ou conversation, sans configuration manuelle.

Pour les développeurs, cela simplifie les déploiements sur des bases utilisateurs hétérogènes. Dans la Live API, l’identification automatique de la langue est activée si language_codes est omis ou défini comme une liste vide.

Autre levier concret : le biaisage lexical via custom_vocabulary. La documentation autorise jusqu’à 1 000 expressions, noms propres, acronymes ou termes techniques. Google précise néanmoins que les meilleurs résultats sont généralement obtenus avec jusqu’à 100 termes. Pour des secteurs comme la santé, le juridique, l’industrie ou le support technique, cette capacité peut faire une différence sensible sur les noms de produits, les références internes ou le jargon métier.

Diarisation et horodatage : utile, mais avec des compromis

Sur l’audio préenregistré, Gemini 3.5 Transcribe propose la diarisation des locuteurs et les horodatages au niveau du mot. Ce sont deux fonctions clés pour les comptes rendus de réunion, l’analyse d’appels et la recherche dans les enregistrements.

La communication produit de Google met en avant une attribution fiable jusqu’à trois intervenants, avec prise en charge de plus de trois locuteurs marquée comme expérimentale. La documentation technique est plus détaillée : elle mentionne une prise en charge jusqu’à huit locuteurs, tout en précisant que l’attribution pour trois locuteurs ou plus reste expérimentale. Pour une équipe d’intégration, cela signifie qu’il faut tester soigneusement les scénarios réels avant de promettre une séparation robuste dans les réunions nombreuses.

Autre point à surveiller : la documentation avertit que l’activation des horodatages mot à mot peut dégrader la précision globale de la transcription. C’est un compromis classique, mais il mérite d’être explicité dans les choix produit. Si l’objectif principal est la meilleure fidélité textuelle possible, il peut être préférable de ne pas activer ce niveau de granularité partout.

Comment intégrer la version live dans une application

La Live API impose un cadre technique assez clair. L’entrée audio attendue est du PCM brut 16 bits, en mono, à 16 kHz, little-endian. Google recommande d’envoyer l’audio par blocs de 100 ms, soit environ 1 024 à 2 048 frames.

La réponse côté serveur distingue deux types de sorties :

  • interim_input_transcription pour les hypothèses partielles spéculatives, utiles pour afficher du texte en cours de saisie vocale ;
  • input_transcription pour les segments finalisés.

Cette distinction est importante pour l’UX. Une interface de sous-titrage en direct ou un agent vocal peut afficher les hypothèses intermédiaires pour gagner en réactivité, puis les remplacer par la version finalisée lorsque le serveur confirme le segment.

La documentation mentionne aussi la prise en charge du VAD manuel et hybride. En mode hybride, une détection de fin de parole côté client peut déclencher une finalisation immédiate du tour de parole, ce qui réduit la latence perçue. Pour les applications conversationnelles, c’est souvent un paramètre plus déterminant que la seule qualité brute du modèle.

Performances annoncées : ce qui est mesuré, et ce qui reste à valider

Google avance plusieurs indicateurs de performance, mais ils doivent être lus comme des résultats rapportés par l’éditeur. Selon Google, Artificial Analysis a mesuré un taux moyen d’erreur sur les mots de 4,0 % en streaming et de 2,6 % hors streaming. Google affirme aussi qu’Artificial Analysis a observé une amélioration de 70 % du temps nécessaire pour obtenir la transcription finale par rapport à Chirp 3.

Sur le benchmark FLEURS, Google indique que Gemini 3.5 Transcribe a atteint 5,50 % de WER en mode streaming et 5,04 % en usage non streaming, sur un ensemble de langues et de locales de premier plan.

Ces chiffres donnent une direction, mais ils ne remplacent pas une évaluation sur données métier. En transcription, les écarts de performance dépendent fortement de l’acoustique, du chevauchement des voix, du vocabulaire spécialisé, des accents, du débit de parole et du besoin éventuel d’horodatage ou de diarisation.

Disponibilité et cas d’usage immédiats

Google place Gemini 3.5 Transcribe en préversion publique dans l’API Gemini via Google AI Studio et Google Antigravity. Côté entreprise, le modèle est aussi en préversion publique via Gemini Enterprise Agent Platform, avec une arrivée annoncée plus tard dans Gemini Enterprise for Customer Experience.

Pour les utilisateurs finaux, Google indique une disponibilité dans l’application Gemini sur macOS en anglais, dans Rambler sur Android dans certains pays et certaines langues, et une arrivée prochaine dans Chrome. Google précise également que les appels de fonctions permettant de déléguer certaines tâches à d’autres modèles Gemini sont actuellement disponibles dans l’application Gemini sur macOS.

Enfin, selon Agora, une intégration Gemini ASR en aperçu anticipé permet d’utiliser gemini-3.5-transcribe-live comme composant ASR dans un pipeline temps réel avec d’autres briques LLM et TTS. Agora indique aussi un endpoint dédié et un en-tête agora-feature: gemini-live pour cet accès de préversion. Pour les équipes qui assemblent déjà des chaînes vocales multi-fournisseurs, c’est un signal d’intégration intéressant, même s’il s’agit d’informations communiquées par le partenaire.

Au fond, l’intérêt de Gemini 3.5 Transcribe tient moins à une seule métrique qu’à l’ensemble du package : temps réel, transcription de fichiers, nettoyage intelligent, multilingue, vocabulaire métier et options de diarisation. La vraie question pour les équipes techniques n’est pas seulement de savoir si le modèle transcrit bien, mais quel compromis il permet entre fidélité, lisibilité, latence et structure des données de sortie.

À retenir

  • Google a annoncé Gemini 3.5 Transcribe le 26 août 2026, avec deux modèles distincts pour le live et l’audio préenregistré.
  • Le modèle propose un mode verbatim pour la fidélité brute et un mode smart pour nettoyer et formater le texte.
  • La détection automatique couvre plus de 85 langues ou locales et gère le code-switching sans configuration manuelle.
  • La Live API attend de l’audio PCM 16 bits à 16 kHz mono, envoyé idéalement par blocs de 100 ms.
  • La diarisation, les horodatages mot à mot et le mode smart impliquent des compromis qu’il faut tester sur des données réelles.

Publié par :

Sources