Mardi soir, OpenAI a ajouté deux modèles de transcription à son API : GPT-Live-Transcribe, taillé pour l’audio en direct à faible latence, et GPT-Transcribe, pour les fichiers déjà enregistrés et les traitements par lots. La nouveauté tient moins aux deux moteurs qu’aux consignes que le développeur peut désormais transmettre avec l’audio.
Quatre champs en plus de l’audio, 3,6 points gagnés
Pour la transcription en direct, OpenAI annonce quatre entrées : un contexte libre décrivant l’enregistrement, une liste de mots-clés pour les noms propres et le vocabulaire métier, les langues attendues en entrée, et les tours de parole déjà transcrits.
Jusqu’ici, la plupart des API de reconnaissance automatique de la parole (ASR) fonctionnaient en boîte noire : vous envoyez un fichier, vous récupérez une chaîne de caractères. Pour améliorer le résultat, il fallait changer de moteur ou ré-entraîner le vôtre.
Le levier des mots-clés n’est pas inédit : Deepgram accepte déjà une centaine de termes prioritaires sur son modèle Nova-3, et Google Cloud Speech-to-Text pondère des listes de phrases depuis des années. Ce qu’OpenAI ajoute, c’est le contexte en texte libre et l’historique des tours de parole : deux entrées qui tiennent de la conversation plus que du dictionnaire.
L’éditeur chiffre l’apport du contexte libre. Sur le benchmark Context Aware ASR, la précision sémantique de GPT-Transcribe passe de 41,6 % sans contexte à 45,2 % avec. Même modèle, même audio. Ces 3,6 points viennent seulement de ce qu’on lui a dit avant de lui envoyer le fichier.
La précision sémantique reste sous les 50 %
Autant lire ce résultat pour ce qu’il est. Un score sémantique de 45,2 % signifie qu’un peu moins d’une intention sur deux est correctement restituée sur ce jeu de test : l’exercice est dur, et ces mesures sont celles de l’éditeur, pas d’une évaluation indépendante.
Le multilingue flatte davantage la démonstration : sur 22 langues de Common Voice, OpenAI revendique un taux d’erreur de transcription de 19,27 % pour GPT-Transcribe, contre 40,37 % pour le modèle qu’il retient comme point de comparaison. Un facteur deux sur l’erreur, c’est le genre d’écart qui décide du passage en production sur des langues jusqu’ici mal servies.
Deux points restent dans l’ombre. Le gain apporté par le contexte est mesuré sur la transcription en différé, jamais chiffré sur le direct, alors que c’est là que la liste de paramètres est mise en avant. Et la facture reste floue : le direct est affiché à 0,017 dollar la minute d’audio, sans que la documentation précise comment sont comptés les tokens du contexte et des mots-clés envoyés à chaque requête.
Le direct oblige à maintenir un état glissant
La séparation des deux modèles n’a rien de cosmétique. GPT-Transcribe vise les archives, les podcasts, les comptes rendus de réunion produits après coup : la latence n’y compte pas, et vous pouvez passer tout le dossier en contexte. GPT-Live-Transcribe vise les agents vocaux, le support téléphonique, le sous-titrage en séance, où chaque centaine de millisecondes se voit à l’écran.
Le paramètre des tours déjà transcrits déplace le travail. En direct, il ne suffit plus d’appeler une API et d’attendre le texte : il faut tenir un état glissant, décider quels tours on conserve, arbitrer entre la mémoire du dialogue et le budget de latence. C’est le chemin qu’a suivi le traitement du texte, avec les fenêtres de contexte puis le RAG (génération augmentée par la recherche).
Le vocabulaire métier prend la même direction. Un cabinet médical, un service client télécom et une salle de marché n’ont ni les mêmes noms propres, ni les mêmes acronymes, ni les mêmes homophones piégeux. La liste de mots-clés devient un actif à maintenir : versionnée, testée, révisée quand un produit change de nom. Un composant du logiciel, au même titre qu’un fichier de traduction.
Le lexique pèsera plus lourd que le nom du fournisseur
Mi-2027, dans les équipes qui exploitent sérieusement de l’audio, la qualité de la fiche de contexte devrait peser davantage sur la satisfaction des utilisateurs que le choix du fournisseur d’ASR. Cette bascule suppose trois conditions.
- Que les concurrents alignent des champs comparables : biais par mots-clés, langues attendues, historique des tours. Un standard de fait, même informel, suffirait.
- Que le coût des tokens de contexte reste marginal devant celui de l’audio traité, sinon les équipes rogneront la fiche pour tenir le budget et perdront le gain.
- Que ces paramètres soient documentés et mesurés sur le direct, pas seulement sur le différé : taille maximale du contexte, nombre de mots-clés au-delà duquel le gain plafonne, comportement en cas de conflit entre langues déclarées et langue réelle.
Si ces trois conditions tiennent, le moteur de transcription se banalise et la valeur migre vers l’ingénierie du contexte audio : constitution des lexiques, découpage des tours, jeux d’évaluation propres au métier. Sinon, chaque fournisseur gardera son dialecte de paramètres, et changer de moteur restera un chantier de plusieurs semaines.
Le jour où une même fiche de contexte pourra être rejouée telle quelle chez deux fournisseurs, le nom du modèle descendra dans un fichier de configuration. Et dans une équipe audio, la compétence rare sera celle de la personne qui écrit et entretient le lexique.
