Latence vocale : où passent les secondes
Décomposition d'un tour de parole, du silence de fin à la première syllabe audible, et les trois optimisations qui comptent vraiment.
- voix
- latence
- STT
- TTS
- streaming
title: 'Latence vocale : où passent les secondes' description: "Décomposition d'un tour de parole, du silence de fin à la première syllabe audible, et les trois optimisations qui comptent vraiment." published: '2026-07-08' domain: 'ia-generative' tags: ['voix', 'latence', 'STT', 'TTS', 'streaming']
Une conversation vocale devient inconfortable bien avant de devenir lente. Le seuil se situe autour d'une seconde entre la fin de votre phrase et le début de la réponse : au-delà, on recommence à parler par-dessus, ou on se demande si le système a compris.
Ce budget se dépense en quatre postes, et l'intuition sur leur poids relatif est presque toujours fausse.
Le découpage réel
Détecter la fin de parole. Un détecteur d'activité vocale attend un silence continu avant de conclure que le tour est terminé. Trop court, il coupe au milieu d'une hésitation ; trop long, il ajoute directement son délai au total. Autour de 1,4 seconde, l'équilibre tient pour du français parlé normalement — et ce poste est, de loin, le plus gros du budget.
Transcrire. Si la reconnaissance tourne dans le navigateur, le transcrit final est déjà là quand le silence est détecté : le coût est nul. S'il faut téléverser l'audio vers un service, comptez le temps d'envoi plus l'inférence, soit typiquement 300 à 800 millisecondes pour dix secondes de parole. L'écart entre les deux chemins est le premier arbitrage à faire.
Générer. Seule compte la latence du premier token, pas celle de la réponse complète. Un modèle qui commence à répondre en 400 millisecondes et met quatre secondes à finir est vécu comme plus rapide qu'un modèle qui réfléchit deux secondes puis vide sa réponse d'un coup.
Synthétiser. La synthèse du navigateur démarre en quelques dizaines de millisecondes. Une voix neurale distante ajoute un aller-retour réseau et, si elle ne diffuse pas en flux, la durée de génération de tout le premier segment.
Trois optimisations qui comptent
Garder la reconnaissance sur l'appareil quand c'est possible. L'API de reconnaissance du navigateur supprime un poste entier du budget et évite d'envoyer l'audio de quelqu'un sur un serveur. Elle n'existe pas partout, d'où le repli serveur — mais le repli doit rester le repli, pas le chemin par défaut.
Ne pas attendre la fin de la génération pour parler. Dès la première phrase complète, la synthèse peut démarrer. Attention au faux ami : synthétiser token par token produit une prosodie hachée, avec des accentuations placées au hasard. L'unité utile est la phrase, pas le mot.
Enlever la récupération du chemin critique quand elle n'est pas nécessaire. Une recherche hybride suivie d'un reclassement ajoute facilement 600 millisecondes avant le premier token. Sur une question de suivi qui porte sur les passages déjà récupérés, elle est du gaspillage pur.
Mesurer, et mesurer au bon endroit
Le serveur ne voit ni le début ni la fin du tour de parole. Il ignore quand l'utilisateur s'est tu et quand la première syllabe est sortie des haut-parleurs. Une latence mesurée côté serveur décrit un fragment du problème, et généralement le plus court.
Les seuls chiffres qui décrivent l'expérience réelle sont mesurés dans le navigateur, entre la fin détectée de la parole et chaque étape suivante, puis envoyés au serveur une fois le tour terminé. C'est ce que fait ce site : quatre marqueurs par tour, agrégés en médianes dans la console d'administration. La médiane, pas la moyenne — un seul démarrage à froid de dix secondes suffit à rendre une moyenne inutilisable comme signal de santé.