Muse Voice Transcribe : le modèle de transcription vocale en streaming de Meta, expliqué

Muse Voice Transcribe est le modèle de transcription de la parole en flux de Meta. Il s'exécute sur Meta Model API à 0,18 $ par heure d'audio, sous l'identifiant de modèle muse-voice-transcribe-1.0, et le tarif est le même que vous diffusiez de l'audio en direct ou que vous fournissiez un enregistrement terminé. Ce qui en fait un modèle digne d'une page de référence plutôt qu'une simple vérification de tarif en une ligne, c'est l'endroit où le travail s'effectue : l'attribution des locuteurs pour plus de vingt voix et la détection de fin de parole s'exécutent au sein même du modèle de reconnaissance, et non dans une passe par lots greffée à la fin du flux. Il s'agit uniquement de transcription de la parole — la documentation destinée aux développeurs de Meta le dit en toutes lettres : il ne synthétise pas la parole et ne fournit pas d'API de conversation parole-parole.

Voici la page sur laquelle un lecteur atterrit après avoir recherché le nom du modèle lui-même ; elle est donc conçue pour être la réponse stable à deux questions — qu'est-ce que ce modèle, et combien coûte une heure d'audio — plutôt qu'une annonce. Une date doit être consignée avant toute autre chose, car c'est un fait concernant le modèle et non la raison d'être de cette page : Meta Superintelligence Labs a présenté Muse Voice Transcribe le 2026-09-01, dans la publication d'annonce datée Introducing Muse Voice Transcribe — publication que le lecteur peut encore atteindre via l'index du blog de Meta, même si elle ne répond plus sur sa propre URL. Tout ce qui suit a été lu sur les pages de Meta elles-mêmes le 2026-09-29, principalement la page du modèle ainsi que la documentation de l'API consacrée à la reconnaissance vocale (speech-to-text) et sa présentation générale. Là où Meta ne fournit aucun chiffre, cette page le dit plutôt que de recourir à une approximation.

Ce que c’est, dans les termes de Meta

La documentation de Meta ouvre sa description sans détour : « Muse Voice Transcribe est le modèle de transcription parole-texte de Meta sur Meta Model API. Transcrivez de l'audio en direct ou un enregistrement existant, avec détection des tours de parole, étiquettes de locuteur et biais de vocabulaire. » La page de présentation résume la même chose en une phrase : diarisation des locuteurs en streaming, détection native des fins d'énoncé et de l'activité vocale, biais contextuel et par mots-clés, et 25 langues évaluées avec alternance codique. Ainsi, la sortie est un flux de transcription unique portant trois étiquettes à la fois : les mots, qui parle, et si l'énoncé est terminé. C'est la combinaison que la plupart des piles de production assemblent actuellement à partir d'un moteur de reconnaissance, plus un détecteur d'activité vocale distinct, plus un modèle de diarisation distinct, chacun ayant son propre budget de latence.

La page du modèle de Meta présente cela comme « une latence compétitive et une précision de transcription en streaming avec attribution en direct pour plus de 20 locuteurs », et la documentation destinée aux développeurs décrit le champ de sortie comme « un texte de transcription avec un horodatage au niveau des tours de parole et des étiquettes de locuteur facultatives ». Deux choses en découlent, et toutes deux importent plus que le cadrage :

• C'est un modèle à entrée audio et sortie texte. Il n'est ni à entrée texte ni à sortie texte, et Meta précise explicitement qu'il ne s'agit pas d'un générateur de parole.

• C’est avant tout un modèle de streaming. Le chemin temps réel n’est pas un wrapper autour du chemin de fichier ; il s’agit d’une session WebSocket avec ses propres événements, modes et limites, décrits ci-dessous.

Combien coûte une heure d’audio

La page du modèle Muse Voice Transcribe de Meta indique le prix ainsi : « Build with a single model at $0.18/hour », et son tableau de spécifications répertorie muse-voice-transcribe-1.0 à 0,18 $ par heure d'audio et 3,00 $ par 1 000 minutes. Il s'agit de deux formulations d'unités d'un même tarif, et les deux figurent sur la page de Meta elle-même, telle que consultée le 2026-09-29. La documentation destinée aux développeurs énonce le même tarif d'une troisième manière : « Pricing is 0,18 $ par heure d'audio traité. » Aucun chiffre de cette page ne provient d'une page de tarification de Meta, car il n'existe aucune page de tarification Meta lisible : la documentation renvoie le tarif vers une page « Pricing and rate limits » qui répond This page isn't available telle que consultée le 2026-09-29 ; la page du modèle constitue donc la source de référence pour le tarif, et c'est la seule utilisée ici.

Le détail de facturation figure dans la documentation destinée aux développeurs et vaut la peine d’être connu avant de dimensionner une charge de travail :

• Le streaming et le non-streaming coûtent le même prix. Il n’y a pas de supplément pour le point de terminaison en temps réel.

• Le traitement à rétention nulle des données est facturé au même tarif que le niveau Standard, d'après la documentation — il ne s'agit pas d'une ligne de supplément.

• La facturation arrondit à la seconde entière inférieure, donc un tour de deux secondes est facturé comme deux secondes et non trois.

• Les échecs qui se produisent avant qu'une transcription ne soit produite ne sont pas facturés, et il en va de même pour les 429 réponses de limitation de débit.

• Les crédits gratuits existent au niveau de la plateforme, et non au niveau du modèle. La documentation de reconnaissance vocale de Meta termine son paragraphe tarifaire par la phrase : « Les crédits du palier gratuit de la plateforme s'appliquent. » C'est la seule formulation évoquant une gratuité sur les pages de ce modèle, et elle est délibérément non spécifique : elle renvoie à un dispositif de crédits de plateforme plutôt que de promettre une allocation gratuite pour la transcription, et aucun chiffre, aucune durée ni règle d'éligibilité n'y est indiqué. Interprétez-la comme un crédit susceptible de réduire une facture, et non comme un palier gratuit pour le modèle. La déclaration de Meta à destination du grand public, selon laquelle son agent personnel est « gratuit pour la plupart de ce dont les gens ont besoin », est une phrase distincte concernant l'application Muse et ne s'étend pas à Model API.

Exemple concret, parce qu'un tarif horaire est difficile à ressentir : un entretien enregistré de deux heures représente 0,36 $ de transcription. Mille heures d'audio d'appels — soit à peu près le volume mensuel d'un centre de contact de taille moyenne — représentent 180 $. À cette échelle, le tarif est tout l'argument, et un tarif est aussi la seule chose qui peut bouger sous vos pieds : la page de Meta fait autorité en la matière, et si le chiffre y change, il change ici.

L’interface de streaming, endpoint par endpoint

This is the part a reference page owes a reader that a launch write-up cannot carry, so here it is in the order you meet it. Base URL for Model API is https://api.meta.ai/v1 with a Bearer token, and Muse Voice Transcribe adds two endpoints on top of it.

• Audio en direct — wss://api.meta.ai/v1/asr/realtime. Le transport est WebSocket, et le détail de l'authentification est un piège : vous vous authentifiez dans la trame de handshake, et l'en-tête Authorization est ignoré. Le handshake doit être la première trame de texte JSON et doit arriver dans les 10 secondes. Une session dure jusqu'à 60 minutes, un nouveau WebSocket crée une nouvelle session, et il n'y a pas de jeton de reprise.

• Enregistrements — POST https://api.meta.ai/v1/asr/transcribe. Téléversement multipart, et celui-ci s'authentifie bien avec l'en-tête Authorization. Le format d'entrée est restreint : WAV PCM mono 16 bits à 16 ou 24 kHz uniquement. Les limites maximales sont de 32 Mo par corps et de 10 minutes d'audio par requête.

Au sein de la session en temps réel, trois modes modifient ce qui vous est transmis. PUSH_TO_TALK est celui par défaut et effectue une transcription à tour unique. ENDPOINTING fournit des limites de tour détectées par le modèle, un tour par segment de parole détecté, en émettant speechStart, et des transcript, speechEnd et speechComplete — avec l'avertissement que speechEnd n'est pas la transcription. DIARIZATION ajoute la détection et l'attribution automatiques des locuteurs, en émettant des speaker avec des étiquettes comme A et B. Les transcriptions partielles sont soit cumulatives, où chaque partielle remplace la précédente, soit sous forme de deltas.

Deux détails opérationnels issus de la même documentation sont faciles à négliger et coûteux à découvrir en production :

• La diarisation signale un possible nouveau locuteur plutôt qu'un point de fin de parole net, et Meta indique qu'elle n'est pas optimisée pour une utilisation à faible latence avec des commandes vocales. Considérez les étiquettes comme des identifiants propres à la session — A dans une session n'est pas la même personne que A dans la suivante.

• Les tours peuvent se chevaucher, donc l’état par tour doit être indexé sur l’identifiant du tour plutôt que sur l’ordre d’arrivée.

• Les plafonds publiés par tenant sont de 128 flux simultanés et de 16 000 flux par heure.

Ce qui s’exécute à l’intérieur du modèle, et ce qu’il remplace

La page du modèle de Meta formule une affirmation spécifique sur l'architecture plutôt que sur les scores : « L'attribution des locuteurs pour plus de 20 locuteurs et la détection de fin de parole se produisent à l'intérieur du modèle de reconnaissance » — et elle l'oppose explicitement à une passe par lots à la fin du flux audio. La différence pratique est qu'il n'y a pas de seconde étape à attendre. Les étiquettes de locuteur et les frontières de tour arrivent sur le même flux que les mots, de sorte qu'un agent vocal en aval ou une interface de sous-titrage en direct obtient un tour complet et une identité sans étape de post-traitement.

Les autres capacités que Meta documente comme résidant dans le modèle :

• Détection native de fin d’énoncé et de l’activité vocale, ce qui vous évite d’exécuter votre propre VAD en amont de l’API. Selon la formulation de la documentation, vous obtenez une transcription complète par énoncé sans exécuter votre propre détection d’activité vocale, et une fin de parole détectée ne met pas fin à la session.

• Biais contextuel et par mots-clés, sans fine-tuning. La page du modèle de Meta décrit une précision maintenue « grâce au biais contextuel et par mots-clés, sans fine-tuning », ce qui est la fonctionnalité qui rend l’ASR en streaming utilisable sur le vocabulaire métier — noms de médicaments, symboles boursiers, références produit (SKU) — plutôt que sur la moyenne de la langue générale. La documentation est précise sur les limites : les mots-clés influencent la reconnaissance mais ne garantissent pas une orthographe exacte, et les mots-clés comme le biais linguistique sont fixés au démarrage de la session.

• 25 langues évaluées avec alternance codique. La documentation les répertorie : arabe, bengali, néerlandais, anglais, français, allemand, hébreu, hindi, indonésien, italien, japonais, kannada, coréen, malais, chinois mandarin, marathi, polonais, portugais, espagnol, tagalog, tamoul, télougou, thaï, turc et vietnamien. L’alternance codique — au milieu d’une phrase et au milieu d’un énoncé, sans qu’on indique quelle langue arrive — est la capacité que les systèmes de reconnaissance monolingues ne peuvent structurellement pas offrir. Une mise en garde à garder en tête : le biais linguistique est une liste de langues, non un contexte libre, et il n’oblige pas le modèle à les employer.

Le billet d’annonce daté va plus loin : il affirme que le modèle a été entraîné sur plus de 70 langues, dont 25 « vérifiées de façon approfondie » — information rapportée par le fournisseur —, et la liste des 25 vérifiées est le sous-ensemble que Meta soutient. C’est cette couverture qu’il faut prendre comme base de planification, pas les 70.

Les limites documentées

Une page de référence ne vaut que par les contraintes qu'elle imprime, et Meta en imprime plusieurs.

• Horodatages au niveau du tour de parole, et non au niveau du mot.La page du modèle comme la documentation l'indiquent clairement : « Il renvoie des horodatages au niveau du tour de parole, mais pas au niveau du mot. » Les tours comportent des heures de début et de fin en millisecondes. Si votre produit a besoin d'un clic pour se positionner mot par mot — mise en surbrillance karaoké, routage de la confiance mot par mot, alignement forcé — ce modèle n'est pas le bon, et aucun travail d'ingénierie de prompt n'y changera rien.

• Aucun score de confiance, pas de détection d’événements sonores, pas de détection d’émotions, pas de reformatage de transcription.Meta indique que ces quatre éléments sont indisponibles. Vous obtenez les mots, les tours de parole, les horodatages et les étiquettes d’intervenant, et rien sur le degré de certitude du modèle.

• Ni synthèse vocale ni API de conversation parole à parole. Ce n'est que dans un seul sens.

• Les formats audio acceptés pour le chemin de fichier sont restreints. Mono PCM WAV 16 bits, 16 ou 24 kHz. Tout autre format doit être converti avant d'être téléversé.

Poids ouverts, et la confusion Muse Glimmer

Muse Voice Transcribe est propriétaire et servi via l'API — ce n'est pas une publication à poids ouverts, et la documentation de Meta ne prétend jamais le contraire. C'est important, car les lecteurs attribuent le parcours à poids ouverts de la famille Muse au mauvais nom. Muse Glimmer est ce parcours : la documentation de Meta le décrit comme un modèle multimodal à poids ouverts distillé à partir de Muse Spark, distribué sous la licence permissive Apache 2.0, que vous téléchargez et exécutez sur votre propre matériel via un runtime tel que vLLM, SGLang, llama.cpp ou ExecuTorch. Muse Voice Transcribe est regroupé sur la même page avec Muse Spark, Muse Image et SAM comme des modèles que vous appelez plutôt que vous téléchargez.

Donc : pas de poids pour Muse Voice Transcribe, pas d'option auto-hébergée, aucun moyen de l'auditer ou de le fine-tuner. Si une page vous dit le contraire, elle l'a confondu avec Muse Glimmer. Lorsque les poids d'un modèle ne sont pas publiés, la plateforme de service est tout ce qui compte — et c'est ce dont traite la section suivante.

Comment un client y accède

Le Model API de Meta est conçu pour être intégré directement dans les clients que vous avez déjà. L’affirmation du fournisseur, imprimée sur la page d’aperçu de l’API, est que Model API « est compatible sans modification avec les bibliothèques clientes compatibles OpenAI et Anthropic, ainsi qu’avec les CLI d’agents compatibles OpenAI. Définissez l’URL de base de votre client, ajoutez votre clé, et conservez le reste de votre code. » De manière générale, pour Model API, trois formats de requête sont proposés — l’API Responses, l’API Chat Completions et l’API Messages — de sorte qu’une intégration existante dispose généralement d’une surface correspondante sans réécriture. Une mise en garde concernant la portée : cette phrase de compatibilité et ces trois formats sont des capacités de Model API dans son ensemble, et non des lignes imprimées sur la page de modèle propre à Muse Voice Transcribe. Le démarrage rapide propre à la page de modèle est plus restreint — il indique seulement que vous « pointez votre client compatible OpenAI existant vers Meta Model API », et que vous obtiendrez une première requête fonctionnelle en moins de cinq minutes.

Une lacune honnête qu'il vaut la peine de signaler sur une page de référence : la documentation de Meta pour ce modèle ne nomme aucune bibliothèque cliente officielle pour Muse Voice Transcribe, et sa page « Client libraries » se trouve dans la section SAM plutôt que dans celle consacrée à Voice. Ce que le guide de la transcription parole-texte vous donne à la place, c'est une liste de dépendances concrète — Python 3.9 ou version ultérieure avec les paquets websockets et sounddevice — plus un cookbook des fondamentaux de l'API vocale. Ainsi, l'affirmation de remplacement immédiat (« drop-in ») décrit la surface de requête de Model API en général ; le point de terminaison ASR temps réel lui-même est un WebSocket avec ses propres règles de handshake et aucun wrapper documenté.

Ce que Meta n'a pas publié

Un benchmark absent est un fait concernant la documentation, donc il est énoncé ici comme tel. La page de modèle de Meta consacrée à Muse Voice Transcribe ne comporte aucun tableau de précision imprimé : ses preuves de précision sont fournies sous forme de trois ressources d’image — un classement des taux d’erreur de mots en streaming, une comparaison des taux d’erreur de diarisation et un indice de précision en streaming — sans aucun chiffre dans le texte extractible. La page du modèle elle-même ne donne aucun taux d’erreur de mots, aucun taux d’erreur de diarisation et aucune ventilation langue par langue.

Le billet d'annonce comporte bien des chiffres rapportés par le fournisseur, notamment un taux d'erreur de mots en streaming et un taux d'erreur de diarisation moyen, et ce sont les chiffres que nous avons repris au lancement du modèle ; il s'agit des mesures de Meta elle-même, et elles n'ont toujours pas été reproduites par un tiers. Cette page ne refait pas cette comparaison, car refaire un benchmark fournisseur du jour de la sortie sur une page de référence reviendrait à présenter un chiffre non reproduit comme un chiffre établi. Ce que l'on peut dire clairement est plus limité : Meta ne publie, pour ce modèle, aucune évaluation comparative directe face à un rival nommé, à effort égal et avec un banc d'essai identique, de sorte que toute comparaison que vous lisez où que ce soit est une comparaison de chiffres de fournisseurs recueillis dans des conditions différentes.

Une date reste également volontairement non établie. La page du modèle n'indique aucune date de sortie — son seul marqueur de version est le -1.0 dans l'identifiant du modèle. La date du 2026-09-01 dans cet article provient de cette annonce datée, et elle sert ici à dater le modèle plutôt qu'à rapporter un événement.

Qui devrait y recourir, et qui ne devrait pas

L'argument en faveur de Muse Voice Transcribe est circonscrit et solide : de l'audio en direct où vous avez besoin des mots, de l'identité du locuteur et des fins de tour sur le même flux, à un prix suffisamment bas pour fonctionner en continu plutôt qu'à la demande. Les agents vocaux, le sous-titrage en direct, l'intelligence de réunion et d'appel, la dictée et la transcription à haut volume sont les charges de travail que Meta nomme, et ce sont les charges de travail pour lesquelles l'interface est réellement conçue — un WebSocket de 60 minutes avec des modes d'endpointing et des étiquettes de locuteur à l'échelle de la session.

L’argument contre lui est tout aussi précis. Si vous avez besoin d’horodatages au niveau des mots, d’un indice de confiance par mot, de détection d’événements sonores ou d’émotions, ou de reformatage de transcription, ce modèle ne les propose pas, et c’est une absence documentée plutôt qu’un bug. Si votre audio arrive dans des formats autres que le WAV mono 16 bits à 16 ou 24 kHz et que vous utilisez le point de terminaison fichier, vous payez une étape de conversion que vous ne paieriez pas ailleurs. Et si votre besoin est la transcription par lots d’enregistrements archivés, où la précision est le seul axe qui compte, l’argument de vente du streaming ne vous apporte rien — le prix est le même sur les deux voies, donc vous payez pour une capacité temps réel que vous n’utiliserez pas.

La seule chose à vérifier avant de vous engager dans une voie de production est le chiffre que cette page est là pour apporter, et c’est le seul chiffre qui peut changer sans que le modèle change du tout : 0,18 $ par heure d’audio, comme indiqué aujourd’hui sur la page de modèle de Meta elle-même. La page de Meta fait autorité en la matière. Quand il évolue, tout ce qui est calibré sur lui — le mois de mille heures, le coût par entretien, l’arithmétique construire ou acheter — suit le mouvement.