Diarisation avec AssemblyAI : modèles, usages et tarifs

Choisissez AssemblyAI pour créer un produit qui tire d’un même audio une transcription, une diarisation et des notes structurées. Le choix décisif concerne le mode de traitement : le modèle phare actuel pour les enregistrements couvre 18 langues, contre 32 pour celui du temps réel. Pour des comptes rendus de réunion, commencez par l’audio enregistré ; passez au streaming si l’application doit réagir avant la fin de la conversation.

À quoi sert AssemblyAI ?

AssemblyAI est une plateforme pour développeurs qui convertit l’audio en texte et propose des API complémentaires pour analyser ce texte, générer de la parole et appeler des modèles de langage. Vous fournissez un enregistrement ou un flux audio en direct, puis construisez votre application à partir des résultats : entretien consultable par recherche, compte rendu de réunion, écran d’analyse des appels ou agent vocal. La plateforme fournit les briques vocales ; l’interface, le stockage, les autorisations et les actions métier restent à développer.

Modèles, fonctionnalités et tarifs vérifiés sur les pages publiques d’AssemblyAI le 5 novembre 2026. Cette évaluation repose sur la documentation, les pages produit publiques et les calculs de coût ci-dessous ; elle ne constitue pas un test de précision ou de latence sur des fichiers audio.

À qui s’adresse AssemblyAI, et dans quels cas l’écarter ?

AssemblyAI mérite de figurer dans votre sélection si le résultat attendu comprend une transcription et des informations qui en sont tirées. Un outil de recrutement a besoin de notes d’entretien attribuées aux bons interlocuteurs. Un outil d’assistance doit rendre les appels consultables et en extraire les problèmes. Un assistant vocal doit recevoir les paroles de l’appelant et disposer d’un signal exploitable indiquant qu’il a fini de parler.

Les critères qui guident cet avis sont le mode de traitement, les langues nécessaires, l’attribution des paroles, le résultat à produire et le coût de cette configuration. Une promesse générale de précision ne répond à aucune de ces questions.

AssemblyAI ou Deepgram ?

Deepgram convient mieux lorsque la maîtrise des tours de parole est le problème central : Flux intègre au modèle la détection de fin de tour et permet d’en configurer le comportement. Son guide de démarrage Flux précise aussi une contrainte d’intégration : Flux utilise /v2/listen ; une connexion de transcription existante sur /v1/listen ne peut donc pas être reprise telle quelle. Retenez cette piste pour un assistant téléphonique qui interrompt les appelants ou attend trop longtemps après leur dernière phrase ; comparez ces comportements sur vos propres appels.

Quand préférer ElevenLabs ?

ElevenLabs convient mieux pour élargir le choix des langues en direct ou transcrire des médias : sa documentation de transcription annonce Scribe v2 et Scribe v2 Realtime dans 90+ langues, avec des étiquettes d’événements sonores non vocaux dans les résultats traités par lots. Vérifiez chaque mode séparément avant de promettre les mêmes fonctionnalités. Cette documentation précise aussi l’absence de mode verbatim : si chaque hésitation doit être conservée, c’est une raison concrète d’évaluer une autre solution.

Quand préférer OpenAI ?

OpenAI convient mieux si votre application utilise déjà son API et doit y ajouter la transcription. Son guide de migration pour la transcription distingue GPT-Transcribe (gpt-transcribe), destiné aux fichiers audio terminés, de GPT-Live-Transcribe (gpt-live-transcribe), destiné aux flux continus en direct. Les fichiers avec attribution des locuteurs passent par un workflow distinct, gpt-4o-transcribe-diarize ; ne présumez pas qu’un modèle plus récent conserve les formats de sous-titres ou les horodatages.

Pour élargir votre sélection, consultez notre comparatif des API de transcription audio. Si vous cherchez uniquement une application de comptes rendus de réunion prête à l’emploi, examinez cette catégorie avant de vous engager dans une intégration d’API.

Transcription avec AssemblyAI : audio enregistré et choix du modèle

L’API d’AssemblyAI pour l’audio préenregistré est le point de départ naturel pour les réunions, entretiens et appels terminés. Le traitement est asynchrone : votre application soumet une tâche, puis récupère le résultat une fois le traitement achevé. La personne qui lit les notes n’a pas besoin que la transcription arrive pendant que les participants parlent encore.

Les noms des modèles comptent : le modèle stable pour les enregistrements, sa version preview et le modèle phare du direct sont des produits différents. Le catalogue actuel des modèles et les pages de sélection propres à chaque mode présentent la gamme suivante :

La présence du même identifiant universal-3-5-pro dans les lignes enregistrement et temps réel ne rend pas leurs API interchangeables. Les requêtes pour les enregistrements utilisent le tableau speech_models, au pluriel ; les connexions en streaming emploient le paramètre speech_model, au singulier.

Pour les enregistrements, Universal-3.5 Pro couvre l’anglais, l’espagnol, l’allemand, le français, le portugais, l’italien, le turc, le néerlandais, le suédois, le norvégien, le danois, le finnois, l’hindi, le vietnamien, l’arabe, l’hébreu, le japonais et le mandarin. L’alternance de langues, ou code switching, permet de reconnaître une conversation qui passe d’une langue à l’autre, sans imposer une seule langue par enregistrement.

La documentation de sélection des modèles pour les enregistrements indique la combinaison par défaut : ["universal-3-5-pro", "universal-2"]. Le premier modèle compatible avec la langue détectée ou spécifiée est retenu. Vérifiez speech_model_used dans le résultat au lieu de supposer que chaque tâche a utilisé le modèle phare.

Prenons un produit qui traite des entretiens en anglais et en coréen. L’anglais peut passer par Universal-3.5 Pro ; le coréen ne figure pas dans sa liste de langues et nécessite le parcours pour enregistrements à couverture plus large. Présenter l’ensemble de l’application comme une solution de « transcription en 99 langues » masque un changement de modèle que votre évaluation doit prendre en compte.

Un workflow pour les réunions enregistrées

Le guide de démarrage pour transcrire un fichier accepte une URL audio hébergée ou un fichier local téléversé. Pour une fonctionnalité de comptes rendus de réunion, voici la séquence utile :

1. 1

   Choisir le modèle et le parcours linguistique

   Définissez explicitement le tableau speech_models souhaité. Activez language_detection si l’application ne connaît pas déjà la langue. Conservez le modèle sélectionné dans les métadonnées de la tâche pour distinguer les différents parcours pendant l’évaluation.

2. 2

   Demander la transcription dont le produit a besoin

   Envoyez l’enregistrement à POST /v2/transcript avec speaker_labels: true si l’interface doit attribuer les répliques. Ajoutez des termes clés pertinents, comme les noms de clients et de produits, lorsque les enregistrements d’évaluation montrent qu’ils posent problème.

3. 3

   Attendre la fin du traitement

   Interrogez GET /v2/transcript/{id} ou utilisez un webhook de fin de traitement. Gérez explicitement les échecs. Stockez l’identifiant de transcription avec votre propre identifiant de réunion pour rattacher les futurs résumés et corrections à la bonne réunion.

4. 4

   Rédiger des notes à partir de passages attribués

   Conservez les interventions des locuteurs et les horodatages avant de générer un résumé. Un responsable doit pouvoir ouvrir le passage source d’une décision contestée, plutôt que de recevoir un paragraphe sans justification vérifiable.

Les termes clés et les prompts contextuels répondent à des besoins différents. Les premiers indiquent le vocabulaire probable ; les seconds décrivent la situation. Universal-3.5 Pro accepte jusqu’à 1,000 termes clés, contre 200 pour Universal-2. Dans les deux cas, un échantillon propre composé de mots familiers ne suffit pas à juger la réussite.

Quand choisir Sync ou Dictation ?

L’API Sync de transcription audio d’AssemblyAI renvoie une transcription complète dans une seule réponse HTTP. Elle convient à un court message vocal ou à une interaction pour laquelle une tâche asynchrone compliquerait inutilement la gestion de l’état de l’application. Son guide de démarrage Sync distingue les envois HTTP directs, limités à 20 minutes, des requêtes via SDK ou en téléversement en direct, plafonnées à 120 secondes. Cette limite propre à l’interface compte si vous prototypez avec un SDK avant d’accepter des enregistrements plus longs.

L’API Dictation ajoute un texte corrigé ou mis en forme à la transcription dans la même requête. Elle convient à un message dicté qui doit devenir un texte prêt à envoyer. Gardez la transcription classique lorsque la formulation d’origine est le résultat attendu ; choisissez la dictée lorsque la reformulation fait partie de la demande.

Le streaming pour les agents vocaux et les sous-titres en direct

Le streaming d’AssemblyAI s’adresse aux applications qui doivent réagir pendant la conversation. Une connexion WebSocket persistante reçoit l’audio et émet des événements de transcription au fil des paroles. Une interface de sous-titrage affiche ces mises à jour ; l’orchestrateur d’un agent vocal s’en sert pour décider de la suite.

Pour une nouvelle intégration, commencez l’évaluation par Universal-3.6 Pro Realtime. La page de sélection des modèles de streaming le désigne comme modèle par défaut lorsque speech_model est omis. Fixez explicitement le modèle pour que la configuration indique clairement ce que vous comptiez déployer.

Les options économiques couvrent moins de langues. Universal-Streaming English, nommé Universal-Streaming sur la page des tarifs, traite l’anglais. Universal-Streaming Multilingual couvre l’anglais, l’espagnol, l’allemand, le français, le portugais et l’italien, avec une gestion des langues par tour de parole. Le modèle phare du temps réel gère nativement l’alternance de langues dans son ensemble linguistique plus étendu. Un appelant bilingue qui change de langue au milieu d’une phrase mérite donc un enregistrement d’évaluation distinct de celui qui change de langue entre deux tours.

Pour un assistant de réservation, le résultat utile est une demande de rendez-vous correcte, suivie d’une réponse au bon moment. Un fragment de transcription peut contenir la bonne date alors que le client est encore en train de corriger l’heure. Considérer chaque fragment comme une instruction complète peut produire une mauvaise réservation, même si les mots reconnus sont justes.

Le guide de démarrage du streaming décrit les messages Begin, Turn et Termination. Un Turn avec end_of_turn: true indique un tour finalisé. Un signal de fin de parole marque une frontière dans le discours ; il n’autorise pas une transaction. Traitez séparément le texte partiel et celui que votre logique métier valide, adaptez l’encodage audio et la fréquence d’échantillonnage à votre source, puis fermez la session à la fin de l’appel.

Une évaluation utile distingue les erreurs de mots, les erreurs sur les entités, les réponses prématurées et les attentes trop longues après une demande terminée. Mesurez le délai complet entre la fin de la demande et la réponse de l’agent, en plus du temps de transcription : l’application, le modèle de langage et la synthèse vocale y contribuent tous.

Diarisation avec AssemblyAI : qui a dit quoi ?

La diarisation d’AssemblyAI regroupe les paroles par locuteur. Elle répond à la question « quelle voix a prononcé ces mots ? ». Speaker Identification est une fonctionnalité distincte, qui tente d’associer des noms ou des rôles aux voix. Une transcription avec les étiquettes « A » et « B » n’a pas encore établi qui est le recruteur ou le client.

Pour l’audio enregistré, speaker_labels: true produit des interventions attribuées aux locuteurs, comme le montre la documentation de diarisation des enregistrements. Ces segments servent notamment à un lecteur d’entretien qui met le locuteur en évidence et permet d’accéder au passage audio correspondant.

Pour l’audio en direct, AssemblyAI renvoie des valeurs speaker_label au niveau du tour de parole et des champs de locuteur sur les mots finalisés. Ces attributions restent toutefois suffisamment provisoires pour imposer la prise en charge des corrections. La documentation des locuteurs en streaming décrit des messages SpeakerRevision qui corrigent les tours précédents ; les dernières révisions arrivent avant Termination.

Imaginez une réunion de projet où un bref « je m’en occupe » devient une tâche attribuée. Si l’étiquette initiale est erronée et que l’application n’applique jamais la révision, le compte rendu peut affecter la tâche à la mauvaise personne. Stockez les tours avec turn_order, appliquez les corrections et générez les notes finales à partir de la transcription corrigée. Un journal immuable du premier événement textuel est une mauvaise architecture de stockage pour cette fonctionnalité.

Deux contraintes moins évidentes méritent votre attention :

• max_speakers est un plafond strict. Au-delà, les locuteurs supplémentaires sont fusionnés avec les étiquettes existantes. Régler ce plafond sur le nombre de participants prévu, sans marge pour une arrivée tardive, peut dégrader l’attribution.
• Les réponses brèves peuvent être PENDING. Considérez-les comme non attribuées tant qu’il manque des éléments ou qu’aucune correction n’est arrivée. Les chevauchements de parole restent aussi difficiles : selon la documentation, des voix simultanées ne peuvent pas simplement être séparées en voix indépendantes.

Si le système d’enregistrement capture déjà chaque participant sur un canal distinct, conservez cette structure et évaluez la transcription multicanale. La séparation des canaux et la diarisation sont deux outils différents : la première exploite la structure de l’enregistrement, la seconde déduit les changements de locuteur d’un audio mixé. Le traitement multicanal modifie aussi la facture.

Speech Understanding et fonctionnalités LLM

Les fonctionnalités Speech Understanding constituent l’argument le plus solide pour préférer AssemblyAI à une intégration limitée à la transcription. La documentation Speech Understanding répertorie Action Items, Auto Chapters, Custom Formatting, Entity Detection, Key Phrases, Sentiment Analysis, Speaker Identification, Summarization, Topic Detection et Translation.

Pour les comptes rendus de réunion, le workflow utile est précis : transcrire, résoudre l’attribution des locuteurs, générer un résumé, puis extraire les actions et leurs responsables. Pour l’analyse du support, il peut s’agir d’extraire les entités et les sujets des appels terminés. Activer toutes les fonctions d’analyse par défaut augmente les dépenses sans démontrer que le produit exploite leurs résultats.

Utilisez LLM Gateway si le résultat doit respecter votre propre schéma ou vos consignes de raisonnement. Un grand modèle de langage, ou LLM, peut transformer la transcription en champs tels que decision, owner, due_date et evidence. Le guide de démarrage Gateway décrit l’injection de transcription via transcript_id, les sorties structurées, l’appel d’outils, les nouvelles tentatives et les modèles de repli via une API commune.

Il reste à définir ce qu’est une réponse valide. Si quelqu’un dit « dans le courant de la semaine prochaine », l’extraction doit conserver cette incertitude au lieu d’inventer une date. Si personne n’accepte une tâche, un champ de responsable vide est plus utile qu’un nom plausible. Rattachez les éléments extraits à l’intervention correspondante pour permettre leur vérification.

Une réponse JSON valide prouve que la sortie respecte la structure demandée. Elle ne prouve ni que l’action proposée a eu lieu, ni qu’une personne l’a acceptée. Prévoyez une étape de validation dans l’application avant que les notes extraites modifient des dossiers clients ou attribuent des tâches à conséquences importantes.

Medical Mode est une option de spécialisation pour le vocabulaire médical, disponible sur les modèles compatibles pour les enregistrements et le streaming en anglais, espagnol, allemand et français. Son périmètre est plus restreint que la couverture linguistique globale de la plateforme. Un produit clinique multilingue doit évaluer ce mode spécialisé lui-même, sans supposer que toutes les langues de transcription bénéficient du même traitement.

AssemblyAI-TTS-1 fait le trajet inverse : il transforme le texte en audio parlé via WebSocket en streaming ou HTTP. Il couvre l’anglais, l’espagnol, l’allemand, le français, l’italien et le portugais, et propose le clonage vocal et les horodatages des mots. Pour un agent vocal, le modèle d’entrée, le modèle de raisonnement et la voix de sortie exigent donc des vérifications distinctes. La liste des langues de transcription en temps réel ne devient pas automatiquement celle de la synthèse vocale.

Tarifs d’AssemblyAI

Le paiement à l’usage d’AssemblyAI constitue un point de départ pertinent pour le lecteur visé ici : sans engagement minimum, la facture dépend des modèles et des fonctionnalités activés. Les tarifs publics ci-dessous proviennent de la page des prix d’AssemblyAI, vérifiée le 5 novembre 2026. Pour les enregistrements, la facturation porte sur l’audio traité ; pour le streaming, sur la durée d’ouverture des sessions.

• Universal-3.5 Pro : $0.21 par heure d’audio préenregistré.
• Universal-2 : $0.15 par heure d’audio préenregistré.
• Universal-3.6 Pro Realtime : $0.45 par heure de session en streaming.
• Universal-Streaming : $0.15 par heure de session en streaming ; il s’agit d’Universal-Streaming English dans la documentation.
• Universal-Streaming Multilingual : $0.15 par heure de session en streaming.
• Universal-3.6 Pro Preview : aucun tarif distinct sur la page actuelle ; à confirmer avant de budgéter un déploiement de la preview.
• Universal-3.5 Pro Realtime : toujours documenté comme pris en charge, mais sans ligne tarifaire distincte sur la page actuelle ; confirmez le tarif de votre intégration fixée sur ce modèle.
• Sync API : $0.30 par heure d’audio.
• Dictation API : $0.62 par heure, avec les fonctions de mise en forme et de prompting indiquées.
• AssemblyAI-TTS-1 : $15 par million de caractères en entrée.

Pour les workflows de comptes rendus et d’agents vocaux décrits plus haut, les suppléments suivants pèsent sur le choix :

• Speaker Diarization : ajouter $0.02 par heure enregistrée ou $0.12 par heure de session en streaming.
• Summarization : ajouter $0.02 par heure au niveau d’effort faible, activé par défaut, ou $0.07 au niveau moyen.
• Speaker Identification : ajouter $0.02 par heure au niveau d’effort faible, activé par défaut, ou $0.10 au niveau moyen.
• Medical Mode : ajouter $0.15 par heure sur les modèles éligibles.
• Prompting d’Universal-3.5 Pro : les termes clés et les prompts contextuels sont facturés séparément, à $0.05 par heure chacun ; Universal-2 inclut les termes clés.
• Termes clés en streaming : inclus avec Universal-3.6 Pro Realtime ; ajouter $0.04 par heure avec Universal-Streaming.

LLM Gateway facture séparément les tokens d’entrée et de sortie du modèle choisi. Un token est une unité de texte traitée par ce modèle. Les tarifs annoncés pour Gateway reposent sur un routage mondial ; la page des prix précise que le routage régional US/EU coûte 10% de plus. Intégrez ce choix au chiffrage d’un workflow d’extraction personnalisé.

Cette comparaison rend le choix concret. Si les deux modèles pour enregistrements respectent vos critères d’acceptation, Universal-2 réduit la facture. Si le modèle plus cher évite suffisamment de corrections pour justifier l’écart, choisissez-le. Le calcul ne présume pas que l’un ou l’autre réussit votre évaluation audio.

Pour les sessions en direct, la documentation de facturation précise l’unité : le compteur tourne tant que le WebSocket reste ouvert, y compris pendant les périodes d’inactivité. À titre d’exemple, 1,000 heures de session avec Universal-3.6 Pro Realtime et diarisation coûtent $570, avant les appels LLM et la parole générée. Une connexion ouverte pendant une heure facture toujours une heure d’usage si elle ne contient que 20 minutes de parole. Fermez-la dès la fin de l’interaction.

La transcription multicanale est facturée par canal. Un enregistrement d’une heure traité sur deux canaux indépendants représente deux heures de transcription. Budgétez la structure de l’enregistrement autant que le modèle : une réunion en mono et un appel à canaux séparés ne constituent pas la même base de calcul.

La page des tarifs annonce une inscription gratuite sans carte et jusqu’à 185 heures de transcription préenregistrée et jusqu’à 333 heures de transcription en streaming. Considérez ces chiffres comme des plafonds publiés, pas comme un droit à ces durées pour chaque configuration. L’offre gratuite de streaming autorise 5 nouvelles connexions par minute ; le paiement à l’usage démarre à 100 nouvelles sessions par minute, avec montée en charge automatique. Il s’agit de débits d’ouverture de connexions, pas de nombres d’appels simultanés. Un lancement qui ouvre de nombreuses sessions à la fois peut atteindre cette limite gratuite avant d’épuiser le crédit.

Les limites susceptibles de changer votre choix

La diversité des modèles et des fonctionnalités d’AssemblyAI fait qu’une transcription d’essai réussie n’est que le début de l’évaluation. Voici les contraintes les plus susceptibles de modifier l’implémentation ou le choix du fournisseur.

La couverture linguistique varie selon l’étape du workflow. Un modèle de repli pour les enregistrements peut étendre la transcription, tandis qu’une option spécialisée, un modèle en direct ou une voix de synthèse peut couvrir moins de langues. Formulez un besoin de bout en bout, comme « produire des notes de réunion en coréen avec attribution des paroles à partir d’un audio coréen », puis vérifiez chaque étape.

L’attribution en direct exige un état modifiable. La documentation des locuteurs en streaming décrit des étiquettes provisoires, des réponses PENDING et des corrections ultérieures. Son champ expérimental de confiance dans l’attribution du locuteur n’est pas non plus une probabilité calibrée. N’en faites pas une garantie sur le responsable d’une action. Soumettez les segments incertains à vérification et appliquez les révisions avant de produire le document final.

La preview pour les enregistrements présente des faiblesses explicites. La documentation de sélection des modèles avertit qu’Universal-3.6 Pro Preview peut produire moins de ponctuation dans certaines langues européennes et perdre en précision sur des audios comportant une alternance de langues complexe. Ce sont des limites déclarées par le fournisseur, pas les résultats de cet avis. Évaluez-la séparément d’Universal-3.5 Pro stable ; un numéro de version supérieur ne tranche pas le choix.

La gestion des données se décide au niveau du compte. La documentation sur la conservation des données et l’entraînement des modèles distingue la conservation en production de l’usage pour l’entraînement. L’éligibilité à l’entraînement dépend du contrat et des contrôles applicables ; l’option documentée de streaming sans conservation est conditionnée au refus de l’entraînement, et des métadonnées opérationnelles subsistent. Vérifiez le compte et la région de traitement choisis avant d’envoyer des enregistrements clients.

L’analyse vocale ne livre pas une application complète. Il faut encore gérer les échecs de traitement, corriger les notes, rattacher les données aux clients et décider quelles actions extraites doivent être validées. L’appel d’outils de Gateway peut faciliter une intégration, mais les autorisations et la logique d’action viennent de votre application. Ce travail d’ingénierie fait partie du choix d’achat, même si la facture de transcription est faible.

Verdict : choisir en fonction du résultat attendu

AssemblyAI mérite sa place dans la sélection des produits qui transforment des conversations en informations structurées et attribuées. Pour des comptes rendus de réunions enregistrées, commencez par Universal-3.5 Pro avec les seules fonctions d’analyse exploitées par l’interface ; comparez Universal-2 si le coût ou une couverture linguistique plus large comptent. Pour un nouvel assistant en direct, évaluez Universal-3.6 Pro Realtime face au modèle de streaming économique adapté et à Deepgram Flux.

La règle de décision : choisissez AssemblyAI lorsque le modèle précis, le parcours linguistique et les garanties de sortie sur les locuteurs répondent aux besoins de votre produit, et lorsque ses fonctions d’analyse des transcriptions réduisent le travail d’intégration à réaliser. Préférez une autre solution si elle correspond mieux aux langues requises, au comportement des tours de parole ou au format de sortie. Une démonstration réussie sur un audio propre ne suffit pas à justifier un changement de fournisseur.

La semaine prochaine, prenez un petit ensemble d’enregistrements que vous êtes autorisé à utiliser : conversations ordinaires, noms inconnus, interruptions, réponses brèves et changements de langue pratiqués par vos utilisateurs. Listez les champs nécessaires à votre application avant de comparer les sorties. Vérifiez les notes finales attribuées autant que la transcription, puis calculez l’usage avec les options retenues et la durée réelle des connexions. Le playground public constitue un bon point de départ ; votre configuration de production reste le véritable test d’acceptation.

Questions fréquentes

Comment obtenir une clé API AssemblyAI ?

Créez un compte et récupérez votre clé dans le tableau de bord. Conservez la clé permanente sur votre serveur. L’API de transcription des enregistrements l’utilise dans l’en-tête authorization, sans préfixe Bearer ; suivez les consignes d’authentification de l’API concernée au lieu de supposer que tous les endpoints fonctionnent à l’identique.

À quoi sert le playground d’AssemblyAI ?

Le playground public permet de choisir un exemple audio, de téléverser un fichier ou de fournir une URL, puis de configurer le contexte du modèle et les fonctions d’analyse compatibles. Il aide à examiner le produit avant l’intégration. Utilisez des audios représentatifs et évaluez la configuration que vous comptez déployer.

Quelle API AssemblyAI choisir ?

Utilisez l’API pour les enregistrements lorsque les tâches terminées peuvent être traitées de manière asynchrone, le streaming pour l’audio en cours et les réponses en direct, ou Sync pour une transcription complète dans un seul échange requête-réponse. Dictation ajoute un texte remanié si l’application a besoin d’un écrit prêt à l’emploi.

Par où commencer dans la documentation AssemblyAI ?

Commencez par la page actuelle de sélection des modèles pour votre mode de traitement, puis par le guide de démarrage correspondant. Copiez l’identifiant API actuel, vérifiez les langues et les fonctions compatibles, puis fixez le modèle dans votre configuration. Un nom de produit repris d’un ancien tutoriel peut désigner une autre génération de modèle.

Utilisez la AI Business Workflow Audit Checklist pour cartographier votre source audio, le résultat attendu et les passages de relais entre applications. Obtenir la checklist.