Microsoft a annoncé MAI-Transcribe-2-Streaming le 1er octobre. Le modèle reçoit l’audio pendant qu’une personne parle et renvoie un texte évolutif avant la transcription finale. Pour un développeur qui ajoute des sous-titres en direct ou la saisie vocale à une application, la question utile est de savoir comment ces mises à jour lui parviennent et quand le texte peut être considéré comme définitif.

Ce guide d’intégration s’appuie sur la documentation et s’adresse aux développeurs qui évaluent la préversion publique. L’objectif est de décider s’il faut prototyper le modèle et de repérer le travail à effectuer côté client pour afficher le texte en direct et conserver la version finale. Microsoft documente la route et le code d’exemple ; BIG CHANGE n’a ni déployé le modèle, ni exécuté les exemples, ni mesuré sa précision ou sa latence.

Le grand changement

  • Microsoft a lancé un modèle en continu qui renvoie du texte provisoire à mesure que l’audio arrive, puis confirme les segments de transcription. Son autre voie de transcription de fichiers, MAI-Transcribe-2, traite des enregistrements et documente un ensemble différent d’options.
  • Une application utilisant l’API Realtime doit envoyer un audio au format correct, gérer les révisions du suffixe provisoire et décider quand demander une transcription terminée. Ces choix déterminent ce que voient les utilisateurs et à quel moment la logique en aval de l’application peut se fier au texte final.
  • Le modèle de transcription en continu est en préversion publique et ne bénéficie d’aucun accord de niveau de service. Microsoft ne le recommande pas pour les charges de production. Les chiffres de vitesse et de précision cités sont des affirmations de lancement et de benchmark, pas des mesures effectuées pour ce guide.

Choisir une voie de connexion

Le catalogue Microsoft Foundry répertorie MAI-Transcribe-2-Streaming, version 2026-08-06, comme modèle en préversion avec une entrée audio et une sortie texte. La présentation du 1er octobre décrit deux façons de l’intégrer : l’API Realtime, qui utilise un protocole WebSocket similaire à celui d’OpenAI Realtime, ou le SDK Azure Speech. Les deux renvoient des résultats de reconnaissance intermédiaires et finaux. Le SDK gère la connexion et le flux audio ; la voie Realtime expose directement les événements.

Pour l’API Realtime, Microsoft exige un abonnement Azure, une ressource Microsoft Foundry dans une région prise en charge et un déploiement du modèle de transcription en continu. Connectez-vous à wss://{your_resource_name}.services.ai.azure.com/mai/v1/realtime?intent=transcription avec un jeton porteur Microsoft Entra ou une clé d’API. La documentation recommande l’authentification Entra. Après session.created, envoyez session.update en indiquant le nom de votre déploiement et le format d’entrée. Ce réglage ne peut plus être modifié après le premier ajout audio, même après une validation.

Le format d’entrée documenté est du PCM16 brut, signé, mono et en petit-boutiste, à 16 ou 24 kHz, transmis sous forme de blocs base64 au moyen de l’événement nommé input_audio_buffer.append (messages d’ajout audio). Il s’agit de données PCM sans en-tête WAV. Microsoft recommande de petits blocs, par exemple de 10 à 20 millisecondes, pour réduire la latence, tout en précisant que de plus gros blocs diminuent la surcharge réseau. L’exemple Python lit l’audio du microphone par blocs de 100 ms ; la recommandation de petits blocs et la taille utilisée dans l’exemple sont deux choix distincts, et non des résultats mesurés par BIG CHANGE.

La voie du SDK Speech exige le SDK v1.52.0, un abonnement Azure et une ressource Foundry ou Speech. L’exemple Python de Microsoft définit speech_config.model sur MAI-Transcribe-2-Streaming, fournit un flux audio mono 16 kHz et 16 bits via un flux push, puis écoute les événements de type recognizing et recognized. L’exemple utilise un fichier audio.pcm préexistant pour illustrer le flux push ; une application fournirait sa propre source audio. Il s’agit des interfaces documentées et des types d’événements attendus, et non d’un test de compatibilité avec un compte réalisé par cette publication.

Séparer le texte provisoire du texte confirmé

La sémantique des événements Realtime compte pour l’interface en direct. Un événement conversation.item.input_audio_transcription.delta contient du texte nouvellement finalisé, que l’application ajoute à son tampon confirmé sans modifier les espaces. Un événement intermediate contient l’intégralité du suffixe provisoire courant. Chaque nouveau suffixe remplace le précédent. L’écran peut afficher le tampon confirmé suivi du suffixe courant ; enregistrer chaque événement intermédiaire comme une nouvelle ligne dupliquerait les mots à mesure que le modèle les révise.

Le client envoie input_audio_buffer.commit lorsqu’il détecte une pause ou à la fin d’un enregistrement. Selon Microsoft, cela demande la transcription finale dès que possible ; input_audio_buffer.committed confirme la validation, et conversation.item.input_audio_transcription.completed fournit le texte final complet de l’audio depuis la validation précédente. Le guide Realtime indique que la détection des tours côté serveur et la validation automatique ne sont pas disponibles avec la configuration de session de ce modèle. Une application vocale doit donc définir elle-même une pause ou une limite de tour si elle veut terminer automatiquement les segments. La documentation décrit le contrat d’événements ; elle ne prescrit pas un détecteur de limites qui conviendrait à tous les cas.

Le guide de Microsoft limite chaque session Realtime à une heure. Il précise aussi qu’un ajout audio ne reçoit pas de confirmation individuelle et peut produire zéro, un ou plusieurs événements de transcription. Les développeurs qui évaluent un prototype devraient distinguer la réception des messages audio de celle du texte finalisé et décider comment l’application gérera une déconnexion. L’exemple Python du guide public comprend une file d’attente pour le microphone et la gestion des erreurs, mais BIG CHANGE ne l’a pas exécuté pour observer les comportements en cas d’échec.

Accès, régions et prix

Microsoft indique que le modèle est accessible dans le monde entier et qu’Azure achemine les requêtes vers les régions de service. Les deux pages d’intégration du 1er octobre donnent des listes de régions disponibles différentes : le guide Realtime cite Sweden Central, Central US et South India ; le guide du SDK Speech cite Sweden Central, Central US et Southeast Asia. Les deux indiquent East US 2 comme prochainement disponible. Vérifiez les options de déploiement et de région actuellement proposées pour la voie choisie ; ces pages ne fournissent pas une liste unique et cohérente. L’accès mondial ne garantit pas un lieu de traitement particulier.

L’annonce indique un tarif de lancement de 0,54 $ par heure d’audio jusqu’à la fin de 2026. Cela équivaut, par calcul, à 9 $ pour 1 000 minutes d’audio, avant les autres services ou l’infrastructure utilisés par une application. Depuis ses guides, Microsoft renvoie vers les pages tarifaires Foundry Models et Speech service pour les deux voies respectives. Les sources consultées ne donnent ni tarif après la période de lancement ni facture testée ; un budget de déploiement nécessite donc de vérifier les tarifs en vigueur.

Microsoft affirme que le modèle de transcription en continu prend en charge 60 langues avec détection automatique continue. L’entreprise dit que le premier résultat partiel apparaît un peu plus de 100 ms après réception de l’audio et cite Artificial Analysis pour affirmer que le modèle se classe parmi les meilleurs en précision. Le benchmark de transcription en continu d’Artificial Analysis mesure le taux d’erreur de mots sur environ huit heures de jeux de données pondérés et chronomètre les résultats partiels et finaux par rapport à la fin de parole détectée. Ce benchmark porte sur des données audio et des règles de mesure précises ; il ne garantit pas qu’une application donnée affichera les mots correctement en 100 ms. Nous n’avons pas pu vérifier de façon indépendante le rang exact de Microsoft à partir d’une ligne de résultats propre au modèle dans le texte public du benchmark consulté pour cet article.

Le guide distinct d’Azure Speech consacré à MAI-Transcribe-2 documente l’entrée de fichiers et des options comme la diarisation des locuteurs, les horodatages au niveau des mots, la pondération de mots-clés et les styles nettoyé ou verbatim. Ne supposez pas que ces réglages fonctionnent avec MAI-Transcribe-2-Streaming : les guides d’intégration en continu ne les documentent pas. Si un produit a besoin de ces sorties, évaluez le modèle de transcription de fichiers ou confirmez la prise en charge du flux dans la documentation à jour et par un test avant de vous appuyer dessus.

Sources et lectures complémentaires

  • Annonce de Microsoft AI, 1er octobre 2026 : lancement et affirmations concernant les langues, la vitesse et le tarif initial. Les affirmations de Microsoft sur la précision et la vitesse interne sont attribuées dans le texte ci-dessus.
  • Catalogue des modèles Microsoft Foundry, consulté le 2 octobre : version du modèle, statut de préversion et types d’entrée et de sortie ; le catalogue n’est pas un test de performance.
  • Présentation du modèle en continu, Guide de l’API Realtime et Guide du SDK Speech, mis à jour le 1er octobre : les deux voies d’intégration documentées, les conditions de préversion, le fonctionnement des événements, les exemples et les tableaux de régions. BIG CHANGE n’a pas exécuté les exemples.
  • MAI-Transcribe-2 dans Azure Speech, consulté le 2 octobre : voie distincte de transcription de fichiers et commandes documentées. Sa liste de fonctions ne décrit pas celles du modèle en continu.
  • Benchmark de transcription en continu d’Artificial Analysis et Méthodologie, consultés le 2 octobre : conception du benchmark indépendant et définitions des mesures de temps. Le texte public consulté ne présentait pas la ligne de résultats précise du modèle, ce qui empêche de confirmer indépendamment son rang.