Gemini Live : une API voix-à-voix, fiche technique

Gemini Live est une API de Google qui échange de l'audio en temps réel avec un modèle, sans passer par une chaîne de reconnaissance et de synthèse séparées. Cette fiche résume la documentation officielle lue le 15/11/2026. Elle ne dit pas ce que vaut l'API pour votre cas : il faut la tester. Le site est édité par IArche, qui édite ALMA ; IArche ne fournit pas cette API.

Les formats d'entrée et de sortie

Entrée audio : PCM brut, 16 bits, 16 kHz, little-endian.
Entrée image : des images JPEG, au plus une par seconde.
Entrée texte : acceptée.
Sortie audio : PCM brut, 16 bits, 24 kHz, little-endian.
Transcriptions : la documentation indique que des transcriptions de l'entrée et de la sortie sont disponibles.

Si la téléphonie envoie un autre format, la conversion doit être prévue. Voir le branchement SIP.

La connexion

La connexion est décrite comme une connexion WebSocket sécurisée (WSS), avec état (« stateful »). Deux schémas sont proposés :

Serveur à serveur : votre backend ouvre la connexion et transmet le flux du client.
Client à serveur : le navigateur ou l'application se connecte directement à l'API.

Pour la production côté client, la page recommande des jetons éphémères plutôt que la clé API standard. C'est un point de sécurité : une clé exposée dans un navigateur peut être utilisée par n'importe qui.

Les langues

La documentation indique deux formulations : « Converse in 70 supported languages » pour la conversation, et « Real-time voice-to-voice translation in 70+ languages » pour la traduction en direct. La page ne publie pas de liste nominative. Le français n'est donc pas nommé dans les extraits lus, même s'il fait partie des 70 langues revendiquées. Vérifiez-le avec vos propres phrases.

La latence

La page qualifie l'API de « low-latency » et de réponses « immediate, human-like spoken responses ». Elle ajoute que le schéma client à serveur « generally offers better performance for streaming audio and video », parce qu'il évite de passer par votre backend. Elle ne donne aucun chiffre de latence. Toute mesure doit donc venir de vos propres appels (voir la latence d'un agent vocal).

Ce que la page ne précise pas

Le nom du modèle : la page parle de traduction et de conversation, mais ne dit pas explicitement qu'il s'agit d'un modèle à audio natif. Ce point ne doit pas être affirmé sans vérification.
Le prix : non relevé dans cette session.
Les outils et les appels de fonction : non décrits dans la page lue.

Point de vigilance avec un framework

La documentation LiveKit Agents, sur la détection de fin de tour, précise qu'un modèle temps réel dont la détection se fait côté serveur rend largement inopérants les réglages d'interruption de l'agent, et que désactiver les interruptions avec ce type de modèle lève une erreur. Avant d'intégrer une API voix-à-voix dans un framework, lisez ces réglages. Voir la détection de fin de parole.

Quand la fiche sert

Vous voulez une seule API pour l'audio et le raisonnement, et vous acceptez de ne pas voir le texte intermédiaire autrement que par les transcriptions.
Vous comparez cette voie à une chaîne en cascade : lisez l'architecture d'un agent vocal avant de choisir.
Vous devez informer l'appelant qu'il parle à une IA : la règle ne dépend pas de l'API (voir prévenir l'appelant).