Connecter Deepgram à n8n : transcription audio sans node natif, callback webhook et diarisation

Le node OpenAI de n8n couvre bien la transcription via Whisper, mais dès qu'un projet a besoin de reconnaissance de locuteurs fiable ou d'un gros volume d'appels à moindre coût par minute, Deepgram revient vite dans la discussion. Problème : n8n ne lui consacre aucun node natif. Toute l'intégration passe par un HTTP Request brut, et deux pièges concrets attendent qui essaie de reproduire un pattern « Whisper classique » — bloquer le workflow en attendant la réponse au lieu d'utiliser le callback asynchrone de Deepgram, et confondre l'API pré-enregistrée avec le streaming temps réel, qui suit un protocole entièrement différent.

Pas de node natif : tout passe par HTTP Request

L'API de transcription pré-enregistrée de Deepgram s'appelle avec une requête POST vers https://api.deepgram.com/v1/listen, un fichier ou une URL audio en corps de requête, et un en-tête Authorization: Token <clé API> — à ne pas confondre avec le schéma Bearer utilisé par la plupart des autres API IA, y compris OpenAI. Le modèle courant se sélectionne via le paramètre model (nova-3 au moment de la rédaction, successeur de nova-2), et la langue via language (ou language=multi pour la détection automatique selon les modèles).

Si vous avez déjà construit un pipeline de transcription avec le node OpenAI et Whisper, la structure du node HTTP Request reste proche : un Set node en amont prépare l'URL ou le binaire audio, puis le HTTP Request pointe vers /v1/listen avec les paramètres de requête choisis. La vraie différence apparaît sur ce que Deepgram permet de faire ensuite avec ce même appel — diarisation native et callback asynchrone — sans code supplémentaire.

Le callback asynchrone plutôt qu'un appel bloquant

Pour un fichier de quelques minutes, un appel synchrone classique (le node HTTP Request attend la réponse) fonctionne. Pour un enregistrement d'une heure, ce n'est plus tenable : le node reste ouvert le temps de la transcription complète, avec un risque de timeout selon la configuration de l'instance n8n — un problème déjà détaillé dans notre guide sur les timeouts d'agent IA.

Deepgram propose une alternative propre : ajouter le paramètre de requête callback avec l'URL d'un node Webhook de votre instance n8n. L'appel à /v1/listen répond alors immédiatement avec un simple request_id, et Deepgram envoie le résultat complet de la transcription dans une requête POST séparée vers cette URL callback dès qu'elle est prête (avec jusqu'à dix tentatives en cas d'échec de livraison, espacées de 30 secondes). Le workflow se scinde donc en deux : un premier déclenche l'envoi à Deepgram et se termine aussitôt, un second — démarré par le Webhook — reçoit le JSON de transcription et enchaîne le traitement (résumé par LLM, écriture dans Notion ou Supabase, notification Slack). C'est le même principe que le pattern de vérification de signature webhook déjà couvert pour SendGrid : un appel qui déclenche un traitement, et un webhook séparé qui en récupère le résultat.

Activer la diarisation (qui parle, et quand)

Whisper transcrit un flux continu sans distinguer les locuteurs ; Deepgram le fait nativement via le paramètre diarize=true. Chaque mot de la réponse JSON porte alors un champ speaker (0, 1, 2…), et ajouter utterances=true regroupe directement les mots en tours de parole par locuteur — un format bien plus exploitable en sortie qu'un tableau de mots individuels à reconstituer soi-même dans un node Code. Pour un compte-rendu de réunion avec plusieurs intervenants, ce champ speaker évite d'avoir à faire deviner à un LLM qui a dit quoi à partir du seul texte brut — une source d'erreur fréquente quand la diarisation est absente.

Deepgram vs Whisper : ce qui change concrètement pour un workflow n8n

Trois différences pèsent réellement sur le choix, au-delà des chiffres de performance publiés par les fournisseurs eux-mêmes (à prendre comme des ordres de grandeur, pas des benchmarks indépendants) :

• Diarisation native : intégrée à l'appel Deepgram (diarize=true), absente du node OpenAI/Whisper de n8n, qui ne renvoie qu'un texte continu.
• Traitement asynchrone intégré : le paramètre callback de Deepgram évite de construire soi-même une file d'attente pour les longs enregistrements, alors qu'un appel Whisper reste synchrone par défaut.
• Architecture temps réel : Deepgram propose un vrai flux streaming en WebSocket (wss://api.deepgram.com/v1/listen), que Whisper ne propose pas nativement — mais ce protocole à connexion persistante sort du cadre d'un node HTTP Request n8n, voir plus bas.

Ces éléments d'architecture sont vérifiables dans la documentation des deux fournisseurs ; les écarts de coût par minute ou de taux d'erreur de mots (WER) varient selon la langue et le type d'audio et ne sont pas repris ici faute de benchmark indépendant récent.

La limite du streaming temps réel avec HTTP Request

Le endpoint wss://api.deepgram.com/v1/listen permet de transcrire un flux audio en direct, mot par mot, avec une latence de l'ordre de quelques centaines de millisecondes. C'est un WebSocket : une connexion persistante et bidirectionnelle, à l'opposé du modèle requête-réponse d'une API REST. Le node HTTP Request de n8n ne sait pas maintenir ce type de connexion — il n'est pas conçu pour ça, et aucun node natif n8n ne couvre ce cas au moment de la rédaction.

En pratique, pour un usage n8n, deux options raisonnables : rester sur l'API pré-enregistrée avec callback (adaptée à la quasi-totalité des cas — compte-rendu de réunion, transcription d'appel après coup, sous-titrage différé), ou déporter la connexion WebSocket vers un petit service externe (une fonction serverless, par exemple) qui reçoit le flux en temps réel et transmet des segments déjà transcrits à n8n via un Webhook classique. Le vrai temps réel piloté entièrement depuis n8n reste, pour l'instant, hors de portée du node HTTP Request.

Une étude de Cao, Ganesh, Cai et al. (2023), A Comparative Analysis of Automatic Speech Recognition Errors in Small Group Classroom Discourse, publiée à ACM UMAP, rappelle un point utile pour tout pipeline de transcription automatisé : le taux d'erreur d'un moteur de reconnaissance vocale grimpe nettement dès que plusieurs locuteurs se chevauchent ou parlent avec un accent éloigné des données d'entraînement — un rappel que la diarisation et la relecture humaine restent utiles même avec un moteur performant, plutôt que de considérer la sortie brute comme définitive.

Un cas concret : transcription d'appels support avec identification des locuteurs

1. Un enregistrement d'appel (client + conseiller) est déposé dans un dossier Drive ou reçu par webhook depuis l'outil de téléphonie.
2. Un premier workflow n8n envoie l'URL du fichier à /v1/listen avec diarize=true, utterances=true et le paramètre callback pointant vers un second webhook n8n, puis se termine.
3. Le second workflow reçoit le JSON de Deepgram, sépare les tours de parole par speaker, et passe le tout dans une Basic LLM Chain pour un résumé structuré (motif d'appel, résolution, points de friction côté client).
4. Le résumé est archivé dans Supabase pour un audit ultérieur, avec une alerte Slack si le motif détecté correspond à une réclamation.

Pièges fréquents

• Utiliser le schéma Bearer au lieu de Token dans l'en-tête Authorization : Deepgram rejette l'appel avec une erreur d'authentification qui ressemble, à tort, à une clé API invalide.
• Laisser le HTTP Request bloqué en attente sur un fichier long au lieu d'utiliser le paramètre callback, avec un risque de timeout de l'exécution.
• Oublier utterances=true et devoir reconstruire soi-même le regroupement des mots par locuteur dans un node Code, alors que Deepgram le fournit directement.
• Tenter de piloter le streaming WebSocket avec un node HTTP Request : ce protocole n'est simplement pas celui que ce node sait parler.

Pour aller plus loin

Ce pipeline de transcription et de résumé automatique — qu'il tourne sur Deepgram ou sur Whisper via le node OpenAI — s'intègre naturellement à un système de traitement d'appels ou de réunions plus large : tri et priorisation avec le Pack Inbox IA (79 €), ou archivage et piste d'audit avec le Pack Conformité & Audit (149 €) pour les secteurs qui doivent conserver une trace exploitable de chaque échange client. Le Bundle FlowKit Complet (269 € au lieu de 347 € pris séparément) réunit les deux avec le Pack Assistant RAG pour rendre ces transcriptions interrogeables a posteriori.