Google a publié le 2026-08-26 le modèle de transcription dédié Gemini 3.5 Transcribe. On sépare d'abord les deux API, puis on regarde le WordInfo JSON natif et les timestamps. Un Schema de compte-rendu, c'est l'étape suivante — pas la même requête que l'annotation ASR.
Le « sortie JSON » du titre pousse à écrire tout de suite un responseSchema. Le modèle dédié renvoie d'abord une annotation ASR. Le JSON de réunion dont vous avez besoin se plie en local, ou dans un second appel Structured Output.
Qu'est-ce que Gemini 3.5 Transcribe ?
Gemini 3.5 Transcribe est le modèle de transcription dédié de Google, en prévisualisation publique depuis le 2026-08-26. Ce n'est pas « n'importe quel audio envoyé à Gemini Flash ». Position officielle : transformer un enregistrement ou un flux micro en texte lisible, et sur le chemin préenregistré fournir labels de locuteur et timestamps au mot.
Google cite Artificial Analysis : WER moyen en streaming 4,0 %, hors streaming 2,6 % ; le délai jusqu'à la version finale est environ 70 % plus court que Chirp 3. Sur FLEURS, un groupe de langues principales fait 5,50 % en streaming et 5,04 % hors streaming. Ce sont des chiffres de lancement, pas votre ligne de recette sur de vrais meetings.
- Transcription Smart : « mardi — non, mercredi », suppression de um / ah, ponctuation et format des nombres automatiques.
- Vocabulaire personnalisé : marques, SKU, noms de médicaments, codes internes.
- 85+ langues détectées automatiquement, y compris un changement de langue dans le même extrait.
- Côté grand public déjà dans Android Rambler et l'app Gemini macOS ; côté développeur Gemini API / AI Studio, côté entreprise Gemini Enterprise Agent Platform.
Deux API, deux identifiants de modèle
Choisissez d'abord le chemin, ensuite on parle JSON. L'annonce et la doc Cloud n'utilisent pas les mêmes suffixes d'ID. Copiez celui de votre plateforme, ne les mélangez pas.
| Cas d'usage | Gemini API (annonce) | Agent Platform (Cloud) | Ce que vous obtenez |
|---|---|---|---|
| Réunion, appel, fichier uploadé | gemini-3.5-transcribe · Interactions API |
gemini-3.5-transcribe-preview · generate_content |
Texte complet + WordInfo optionnel (temps au mot, locuteur) |
| Sous-titres, micro, UI vocale | gemini-3.5-transcribe-live · Live API |
gemini-3.5-transcribe-live-preview · BidiGenerateContent |
hypothèse interim + version final ; temps au niveau phrase ; pas de locuteur / pas de timestamp au mot |
Le chemin temps réel convient à « afficher d'abord, committer ensuite ». Alignement de sous-titres, contrôle qualité d'appel et découpe par locuteur passent par le préenregistré.
JSON natif : WordInfo n'est pas un responseSchema
Dans l'Interactions API, une fois timestamp_granularities: ["word"] activé, chaque mot est un WordInfo :
type: toujoursword_infotext: le mot lui-mêmestart_offset/end_offset: temps relatif au début de l'audio (seulement avec les timestamps au mot)speaker: par ex.spk_1(seulement avecdiarization_mode: speaker)
L'API synchrone Agent Platform est plus directe : audio_transcription.words[] porte word, start_offset, end_offset ; le locuteur est dans speaker_label du part.
Figez la frontière. La doc Cloud indique que le modèle dédié ne prend pas en charge Structured Output. N'attendez pas un { summary, segments[] } selon responseSchema. Ça, c'est la compréhension audio Gemini générale, ou un pliage local.
« Sortie JSON » a donc deux couches :
- JSON ASR : tableau WordInfo / words, champs fixés par Google.
- JSON métier : votre compte-rendu, axe de sous-titres, fiche QA. Inversez le Schema depuis un échantillon avec Structured Output, puis second appel ou conversion locale.
Timestamps : comment les activer, ce qui disparaît
1. Préenregistré : start_offset / end_offset au mot
Gemini API : timestamp_granularities: ["word"] ; Agent Platform : word_timestamp=True. Google le dit clairement : les timestamps au mot baissent la précision de transcription. Pour des sous-titres type karaoké, acceptez « meilleur alignement, WER parfois pire », puis contrôlez chiffres et noms propres sur un second enregistrement calme.
Configuration minimale côté Interactions (esquisse de structure, pas une requête d'auth complète) :
{
"model": "gemini-3.5-transcribe",
"input": [{
"role": "user",
"content": [{
"type": "audio",
"uri": "FILE_URI",
"mime_type": "audio/mp3"
}]
}],
"generation_config": {
"transcription_config": {
"language_hints": ["zh-CN", "en-US"],
"diarization_mode": "speaker",
"timestamp_granularities": ["word"]
}
}
}
2. Temps réel : niveau phrase seulement, pas le mot
La Live API pousse deux types d'événements : interim_input_transcription (hypothèse qui bouge) et input_transcription (version commitable). Doc Cloud : le temps réel a des timestamps au niveau phrase, pas de timestamps au mot ni de diarisation. Une session continue tient environ 10 minutes ; plus long, découpez et rassemblez vous-même.
À l'écran : interim. En base : uniquement final. Ranger les hypothèses en base décale l'axe temporel.
Diarisation : combien de locuteurs, quand c'est expérimental
Le billet de lancement insiste sur le chemin préenregistré « 3 locuteurs max » ; au-delà, Experimental. Le tableau Agent Platform monte à 8, et marque aussi 3+ Experimental. En planning : jusqu'à 3 locuteurs comme utilisable, davantage comme sondage.
Le temps réel n'a pas de locuteur. « Qui a dit le n° de commande à 01:12 » : enregistrez d'abord, puis le modèle préenregistré.
Ne mélangez pas Smart et verbatim
verbatim garde fillers, lapsus et autocorrections — utile pour preuves, QA, source de sous-titres. Smart nettoie lapsus et fillers, met en forme nombres et listes. Dans la doc actuelle, Smart est incompatible avec locuteur / timestamps au mot.
Deux passages sur le même enregistrement : verbatim + timestamps comme source ; Smart comme compte-rendu lisible. Ne laissez pas Smart écraser la source.
Un échantillon de transcription qui donne un Schema
Ci-dessous une forme courante une fois WordInfo plié côté métier. Les temps en secondes numériques, pas en chaîne "00:12" — comparaison, tri et axe n'en seront que plus simples.
{
"source": "gemini-3.5-transcribe",
"mode": "verbatim",
"language": "zh-CN",
"segments": [
{
"speaker": "spk_1",
"start": 1.24,
"end": 4.08,
"text": "把订单 ORD-1024 推到预发。"
},
{
"speaker": "spk_2",
"start": 4.21,
"end": 6.9,
"text": "好,我先对一下 SKU。"
}
]
}
Selon les règles d'inférence actuelles du site, cet échantillon donne :
| Champ | Type inféré | À faire après génération |
|---|---|---|
source / mode |
string | enum seulement si les valeurs doivent être figées |
segments |
object[] | Un tableau vide est-il licite ? L'inférence ne voit que les premiers éléments |
start / end |
number | Des nombres dans l'échantillon ; "1.24" devient string |
speaker |
string | Absent du chemin Live — pas required sauf si vous ne prenez que du préenregistré |
Échantillon prêt : générez les enveloppes dans l'outil Structured Output, puis relisez à la main required et additionalProperties.
Durée, langues et statut Preview
- Toujours Preview. Quotas, régions et suffixes d'ID peuvent bouger. Avant de monter en charge, passez vos propres enregistrements de réunion.
- Durée. Cloud : temps réel environ 10 minutes ; fichier synchrone avec diarisation / timestamps environ 15 minutes. L'annonce ne fige pas « une heure » comme limite dure — suivez la doc actuelle de votre plateforme, découpez le trop long vous-même.
- Langues. 85+ en détection auto. Si vous connaissez la langue, passez du BCP-47, par ex.
cmn-Hans-CN,en-US. Vocabulaire : 1000 entrées max ; officiellement, restez d'abord sous 100 noms propres. - Vocabulaire personnalisé. Marques, noms, SKU seulement — pas le vocabulaire courant.
Recetter dans la Boîte à outils JSON
- Collez un vrai WordInfo ou des
segmentsdéjà pliés dans le formatage JSON, pour confirmer que ça parse. - Générez le brouillon avec JSON → Schema ou Structured Output.
- Passez le résultat d'un second enregistrement dans la validation Schema. Le premier échantillon est toujours trop optimiste.
- Axe décalé : Comparaison JSON pour voir si
startdérive ou si les coupes speaker ont changé. - Validation front : Zod ; doc d'API si besoin : OpenAPI 3.1.
Tout se traite dans le navigateur, rien n'est envoyé au serveur.
FAQ
Qu'est-ce que Gemini 3.5 Transcribe ?
Le modèle de transcription dédié publié par Google le 2026-08-26. Préenregistré : gemini-3.5-transcribe ; temps réel : gemini-3.5-transcribe-live.
Renvoie-t-il directement un JSON horodaté ?
Oui. WordInfo porte text, start_offset, end_offset, plus speaker si la diarisation est active. C'est une annotation ASR, pas un responseSchema.
Smart peut-il combiner locuteur et timestamps au mot ?
D'après la doc actuelle, ne les mélangez pas. Pour des labels ou des timestamps, passez d'abord par verbatim.
La Live API sépare-t-elle les locuteurs ?
Non. Live n'a que le texte interim / final et un temps au niveau phrase.
Le modèle de transcription dédié, c'est la même chose que Structured Output ?
Non. Un summary + segments personnalisé demande un second appel au modèle général, ou de plier WordInfo localement dans votre Schema.
En résumé
Gemini 3.5 Transcribe résout « entendre, marquer qui parle, aligner le temps ». Le JSON a deux couches : d'abord WordInfo, ensuite le Schema métier. Timestamps au mot et locuteur uniquement en préenregistré ; ne mélangez pas Smart avec ces annotations. Un seul Schema cœur ; validation, Zod et OpenAPI en descendent.