Voix dans Azure : de transcrire à converser

Toute app qui écoute gagne en accessibilité, et toute app qui répond en parlant devient plus humaine. « Introduction to speech in Azure » sur Microsoft Learn parcourt le cycle complet de l'audio dans Foundry : ce qu'il faut pour qu'un système écoute, comment la parole devient du texte, comment le texte redevient du son et ce qui est déjà servi quand la conversation devient continue. Ce post suit ce chemin (entrer, comprendre, sortir en parlant) et termine sur Voice Live, le service qui absorbe tout le pipeline.

Pourquoi la voix revient

Les fonctionnalités de voix d'IA (gérer des systèmes par la voix, obtenir des réponses parlées, générer des sous-titres) sont la voie directe pour augmenter l'accessibilité et l'inclusion de n'importe quel produit. Les usages qu'on voit tous les jours : dictée clinique en santé, transcription d'appels en support, sous-titres dans les médias, commentaire de prononciation en éducation et assistants de commerce. Chaque exemple applique les mêmes deux pièces avec une économie différente : la dictée remplace taper par parler ; la transcription d'appels rend texte une conversation qu'avant on ne pouvait qu'écouter ; les sous-titres rendent le contenu accessible à qui ne peut pas l'entendre ; le commentaire de prononciation renvoie une correction qui avant dépendait d'un professeur ; et l'assistant de commerce répond en parlant au lieu de forcer la navigation. Dans tous, le même motif : quelqu'un parle, le système comprend, et à un moment répond avec de la voix.

Écouter et parler : les deux fonctions du système

Un système d'IA qui interagit par la voix a besoin d'au moins deux choses. La reconnaissance de voix (STT) convertit la parole en données, normalement du texte. La synthèse vocale (TTS) vocalise des données, normalement en convertissant du texte en voix audible. Avec les deux, le système écoute et répond ; sans aucune des deux, ce qu'il reste est une app de pur texte qui attend un clavier.

À l'intérieur, le logiciel voix-vers-texte utilise généralement un modèle acoustique, qui convertit l'audio en phonèmes (représentations de sons), et un modèle de langage, qui associe les phonèmes à des mots. La séparation reflète les deux couches du problème : son reconnaissable et mots avec sens dans une langue. Les mots reconnus sont ensuite convertis en texte pour les sous-titres, les transcriptions ou la dictée automatisée.

flowchart LR
    A[Audio<br/>micro, fichier ou flux] --> B[Modèle acoustique<br/>audio vers phonèmes]
    B --> C[Modèle de langage<br/>phonèmes vers mots]
    C --> T[Texte<br/>sous-titres, transcription, dictée]

La figure complète de la reconnaissance est celle-là : il n'y a pas d'étape magique où l'audio « se comprend » ; il y a deux modèles enchaînés, un qui réduit le son en pièces reconnaissables et un autre qui de ces pièces assemble des mots avec sens.

Transcrire : le SDK et les deux modalités

Azure Speech vit dans Foundry Tools et apporte voix-vers-texte, texte-vers-voix et traduction. Le SDK voix-vers-texte (pip install azure-cognitiveservices-speech) capture ou envoie l'audio depuis le micro, un fichier ou un flux, l'envoie de façon sécurisée à Azure Speech et reçoit le texte transcrit quasiment en temps réel ou à la fin du traitement. Il gère réseaux, authentification, streaming d'audio et analyse de réponse pour que l'application se centre sur sa logique, et s'authentifie avec le point de terminaison et la clé de la ressource Foundry, ou avec un identifiant Microsoft Entra. La clé est la même que partout ailleurs dans Foundry : elle ne change pas de pièce à pièce.

Dans la division du travail, à l'application revient d'installer le paquet, fournir la clé et choisir la modalité ; au SDK restent les réseaux, l'authentification, le streaming d'audio et l'analyse de la réponse. Si le tronçon dur vient déjà résolu, ce qui reste dans votre code est de la logique métier.

Le schéma de code est court : un SpeechConfig avec clé et point de terminaison, un SpeechRecognizer avec AudioConfig(use_default_microphone=True), des gestionnaires pour les événements recognized (transcription finale) et recognizing (transcription partielle), et start_continuous_recognition() qui démarre l'écoute continue, celle qui s'arrête à la fin de la session. Les deux gestionnaires sont la différence entre voir la transcription se former en direct et la recevoir fermée : le premier pour les sous-titres en live, le second pour enregistrer le texte. Variante avec un fichier enregistré, le modèle minimal de toute transcription avec fichier :

On spécifie le point de terminaison, la clé et la source audio.
On transcrit avec le même SpeechRecognizer.
On affiche les résultats : le message de messagerie vocale est converti en texte.

Même reconnaîteur, même motif d'événements, source audio différente : aucun code nouveau pour passer du micro au fichier.

La décision de conception est la modalité, et les deux se distinguent en quatre lignes :

	Temps réel	Par lots
Entrée	Audio entrant écouté en direct	Fichiers stockés pointés par une URI de signature d'accès partagé (SAS)
Livraison	Texte au fil de la parole	Résultats asynchrones
Disponibilité	Immédiate, au rythme de la parole	Les travaux se planifient selon la meilleure disponibilité : ils commencent en général en minutes, sans estimation fiable de quand ils passent à l'exécution
Cas typique	Présentations et démos en live	Enregistrements déjà stockés dans un compte de stockage, un serveur distant ou le stockage d'Azure

Pour une démo en live, le premier convient ; pour traiter le dépôt d'enregistrements d'une entreprise, le second. La règle pour n'importe quel projet est la même : si l'audio vient en direct, temps réel ; s'il est déjà stocké, lots.

Le retour : synthèse vocale

Du côté de la génération de voix, le processus a sa propre chorégrapie. Il part du texte à dire et de la voix choisie, et suit cinq étapes :

Il segmente le texte en mots.
Il attribue des sons phonétiques.
Il divise la transcription phonétique en unités prosodiques (phrases, clauses, propositions).
Il crée les phonèmes.
Il les synthétise en audio, en appliquant une voix, un débit, un ton et un volume donnés.

L'entrée est du texte brut et un choix de voix ; le pipeline fait tout le reste.

Les voix viennent en trois registres, décrits par ce qu'elles font :

Voix	Ce que c'est	Quand ça sert
Par défaut	Langues et variantes régionales prêtes à l'emploi	Démarrer sans configurer autre chose
Neuronal	Réseaux neuronaux qui dépassent les limites habituelles de la synthèse comme l'intonation	Quand il importe que ça sonne naturel
Personnalisée	Développée sur mesure et utilisée avec la même API texte-vers-voix	Quand la voix fait partie de la marque

Les trois cohabitent dans la même API texte-vers-voix : passer de l'une à l'autre, c'est changer le nom de la voix, pas le code. C'est aussi la taille de la décision : essayer une autre voix n'ouvre pas un nouveau projet, ça ne change qu'une valeur de configuration.

Dans le code, le motif suit la même forme que le SDK de reconnaissance : un SpeechConfig avec clé et point de terminaison, speech_synthesis_voice_name fixé à une voix neuronale multilingue, un SpeechSynthesizer avec AudioOutputConfig(use_default_speaker=True) et un appel à speak_text_async(text).get(). Le résultat se vérifie contre ResultReason.SynthesizingAudioCompleted ou Canceled, en affichant les détails d'erreur s'il y en a.

Voix à voix : du pipeline au service administré

La voix à voix prend de l'audio parlé en entrée et produit de l'audio parlé en sortie, sans que l'utilisateur lise ni écrive. Elle combine conversion voix-vers-texte, traitement ou raisonnement (analyse, traduction, résumé ou décision d'un agent) et texte-vers-voix, et ses scénarios sont les assistants et agents d'IA, la traduction vocale, les applications mains libres, l'accessibilité et les bots de support.

flowchart LR
    I[Audio parlé] --> S[STT<br/>voix vers texte]
    S --> R[Raisonnement<br/>analyse, traduction ou décision]
    R --> Y[TTS<br/>texte vers voix]
    Y --> O[Audio de sortie]

Monter ce pipeline à la main implique de tenir des pièces indépendantes et un back-end propre. C'est là qu'intervient Azure Speech Voice Live : un service administré qui réunit STT, raisonnement d'IA et TTS en un seul service pour des conversations en temps réel. Il utilise le modèle d'IA générative choisi ainsi que les propres modèles acoustiques d'Azure Speech, peut aussi renvoyer des objets visuels comme des avatars et déclencher des actions, admet l'interaction proactive (l'agent initie la conversation) et peut s'intégrer dans le mode Voice d'un agent Foundry, en encapsulant la configuration vocale dans l'agent et en réduisant le code client. La configuration vocale reste dans l'agent : pas de back-end audio séparé à maintenir ni à synchroniser.

Démarrer une application Voice Live en Python est aussi direct que d'installer azure-ai-voicelive (avec pyaudio, python-dotenv et azure-identity), de partir du code d'exemple du portail Foundry — qui gère déjà la connexion, les périphériques audio, les flux entrants et sortants et les interruptions — et de lancer : l'assistant envoie l'audio du micro vers Azure Voice Live et joue la réponse par les haut-parleurs.

Où vit chaque pièce

Avec trois entrées possibles, la carte de décision est courte :

Transcrire seulement : le SDK voix-vers-texte, en temps réel si l'audio vient en direct ou par lots s'il est déjà stocké.
Parler seulement : le SDK texte-vers-voix, avec une voix neuronale pour que ça sonne naturel et les paramètres voix, débit, ton et volume où vous en avez besoin.
Converser : le pipeline complet STT, raisonnement et TTS ; là Voice Live emporte les trois pièces dans un seul service administré.

La pièce qu'on choisit d'abord définit le reste : transcrire est le cas le plus court, et converser est celui qui économise le plus d'infrastructure quand on le monte à la main.

De la lecture à l'exécution

La pratique de reconnaissance vocale dans Foundry est restée en lecture : sa description a été relue, mais pas exécutée. Ce que ce parcours rend clair, c'est la carte de la voix dans Azure (quelle fonction fait chaque pièce, ce que le SDK absorbe, ce que Voice Live absorbe, et quand le temps réel ou les lots conviennent) ; ce qui manque à tester, c'est l'extrémité à extrémité sur un abonnement à soi, avec micro, haut-parleur et un vrai ressource déployée, parce que l'audio ne se juge qu'en le faisant tourner. L'ordre pour reprendre est clair : d'abord une transcription de fichier avec le SDK, ensuite une synthèse qu'on entend, et seulement ensuite la conversation complète avec Voice Live ; chaque étape élimine un bloc d'incertitude avant de passer à la suivante.

---

*Source : le module « Introduction to speech in Azure » de Microsoft Learn.*