n8n + Zoom : automatiser la récupération et le résumé IA des enregistrements de réunion

Une réunion enregistrée sur Zoom finit presque toujours au même endroit : un fichier vidéo dans le cloud que personne ne rouvre. Ceux qui y étaient s'appuient sur leur mémoire, approximative, du contenu ; ceux qui étaient absents attendent un compte rendu qui arrive rarement. Une étude de Geimer, Leach, DeSimone, Rogelberg et Warr, publiée en 2015 dans le Journal of Business Research (voir sur Google Scholar), montre que moins de la moitié des participants jugent leurs réunions réellement efficaces — et l'absence de suivi structuré après coup en est une cause récurrente. Zoom expose une API et des webhooks qui permettent de brancher n8n directement sur la fin d'un enregistrement cloud, pour transcrire et résumer sans qu'un humain ait à rouvrir la vidéo. Ce guide construit ce pipeline de bout en bout.

Pourquoi partir du webhook Zoom plutôt que d'un upload manuel

Notre guide de transcription et résumé de réunions avec Whisper couvre le cas générique : un fichier audio déposé manuellement déclenche la transcription. Ça fonctionne pour un usage ponctuel, mais ça suppose que quelqu'un pense à déposer le fichier — ce qui, en pratique, arrive rarement de façon systématique. Brancher directement sur l'événement recording.completed de Zoom élimine cette étape manuelle : dès que Zoom termine le traitement cloud de l'enregistrement, n8n reçoit l'information et démarre le pipeline sans intervention. C'est le même principe que la détection native des no-shows chez Cal.com : un événement serveur fiable vaut mieux qu'un rappel humain.

Vue d'ensemble du pipeline

Le montage complet enchaîne cinq briques : un Webhook n8n qui reçoit recording.completed, un node HTTP Request qui télécharge le fichier audio, un appel à une API de transcription, un Basic LLM Chain qui structure le résumé, et une distribution finale (Slack, Notion, ou digest quotidien). Chaque brique reste remplaçable indépendamment — c'est la même logique modulaire que dans nos guides d'intégration IA habituels.

Étape 1 — Créer une app Zoom Server-to-Server OAuth

Dans le Zoom App Marketplace, le type d'app le plus adapté à un pipeline serveur comme n8n est Server-to-Server OAuth : il fournit à la fois un access token compte (sans redirection OAuth interactive, donc pas de ré-authentification à gérer) et la possibilité d'activer des Event Subscriptions (les webhooks) dans le même écran de configuration. Ajoutez le scope cloud_recording:read:recording (ou :admin pour couvrir tous les hôtes du compte), puis activez l'abonnement à l'événement recording.completed.

Étape 2 — Recevoir le webhook dans n8n et répondre au défi de validation

n8n n'a pas de node « Zoom Trigger » dédié : le node Webhook générique fait l'affaire, exactement comme documenté dans notre guide de sécurisation des webhooks n8n. Avant d'accepter le moindre événement réel, Zoom envoie un défi de validation (event: "endpoint.url_validation") au moment où vous collez l'URL du webhook dans le Marketplace, puis périodiquement toutes les 72 heures pour revalider l'endpoint. La réponse attendue est un JSON { "plainToken": ..., "encryptedToken": ... }, où encryptedToken est un HMAC-SHA256 du plainToken reçu, calculé avec le secret token de l'app comme clé. Un node IF juste après le Webhook sépare ce cas (event === "endpoint.url_validation") du flux normal, et un node Crypto calcule le hash attendu avant de le renvoyer via Respond to Webhook — la même mécanique que celle détaillée dans notre guide du node Crypto et des signatures HMAC. Pour tester ce montage avant de coller l'URL définitive dans le Marketplace, un tunnel comme ngrok fonctionne exactement comme pour tester n'importe quel webhook n8n en local.

Vérifier la signature sur les vrais événements

Sur chaque événement recording.completed reçu ensuite, Zoom signe la requête via l'en-tête x-zm-signature, calculé sur la chaîne v0:{x-zm-request-timestamp}:{corps-brut} avec le même secret token. Recalculer ce HMAC dans un node Crypto et le comparer à l'en-tête reçu évite qu'une URL de webhook découverte permette d'injecter de faux événements dans le pipeline — un point d'autant plus important ici que l'événement déclenche un téléchargement de fichier.

Étape 3 — Télécharger l'enregistrement avec le download_token

Le payload recording.completed contient un tableau recording_files, chacun avec son download_url, et surtout un champ download_token généré spécifiquement pour ce webhook. En ajoutant ce token en paramètre de requête (?access_token={{ $json.download_token }}) sur l'URL de téléchargement dans un node HTTP Request, aucun appel OAuth séparé n'est nécessaire pour récupérer le fichier — à condition de le faire dans les 24 heures suivant la réception du webhook, durée de validité du token. Filtrez sur file_type === "M4A" (ou MP4 selon vos besoins) pour ne télécharger que la piste audio et éviter de rapatrier inutilement la vidéo complète.

Étape 4 — Transcrire l'audio

Un node HTTP Request vers l'API de transcription (Whisper d'OpenAI, ou un modèle équivalent) transforme le fichier binaire téléchargé en texte. Pour les réunions longues, découpez l'audio en segments de moins de 25 Mo avant l'envoi — la limite classique de ce type d'API — sur le même principe de découpage que celui déjà couvert dans notre guide générique de transcription.

Étape 5 — Générer un résumé structuré par IA

Une transcription brute de quarante-cinq minutes ne se lit pas plus facilement qu'un replay vidéo. Un Basic LLM Chain connecté à Claude ou GPT, avec un prompt qui impose une structure fixe — décisions prises, actions à faire avec responsable assigné, points en suspens — transforme le texte brut en compte rendu exploitable en trente secondes de lecture. Demander explicitement au modèle de citer l'horodatage approximatif de chaque décision (déductible du minutage de la transcription) permet de retrouver rapidement le passage exact dans l'enregistrement en cas de doute, plutôt que de devoir tout réécouter.

Étape 6 — Distribuer le résumé

Le résumé généré part ensuite vers Slack (message dans le canal de l'équipe concernée), vers une page Notion créée automatiquement, ou s'agrège dans un digest quotidien si le volume de réunions le justifie — sur le même principe que le digest quotidien du Pack Inbox IA, qui applique cette logique aux emails plutôt qu'aux réunions. Pour les équipes qui gèrent aussi des tickets ou des dossiers liés à ces réunions, journaliser chaque résumé dans une table Supabase (voir notre guide de connexion n8n ↔ Supabase) rend l'historique interrogeable plus tard, plutôt que dispersé entre plusieurs canaux Slack.

RGPD et enregistrements de réunion : ce qu'il faut cadrer

Un enregistrement audio ou vidéo de réunion contient des données personnelles au sens du RGPD dès qu'il capture la voix de participants identifiables. Trois points à cadrer avant de déployer ce pipeline en production : informer les participants que la réunion est enregistrée et transcrite par IA (mention en début de réunion ou dans l'invitation suffit dans la plupart des cas) ; limiter la durée de conservation du fichier source une fois le résumé généré, sur le même principe que notre guide de purge automatique des données RGPD ; et vérifier que l'API de transcription choisie n'utilise pas le contenu audio pour entraîner ses modèles, selon les conditions du fournisseur retenu.

Bonnes pratiques et limites

• recording.completed ne se déclenche que pour l'enregistrement cloud, pas pour un enregistrement local stocké sur le poste de l'hôte — un point à vérifier dans les paramètres du compte Zoom avant de construire le pipeline.
• Le download_token expire en 24 heures : un pipeline qui traite l'enregistrement immédiatement n'y est jamais confronté, mais une reprise différée après erreur doit repasser par un appel API classique avec un access_token OAuth pour régénérer l'URL.
• Ne pas sauter la vérification de signature sur les événements réels, même en environnement de test : une URL de webhook, une fois connue, reste appelable par n'importe qui tant qu'aucune vérification n'est en place.
• Séparer proprement le défi de validation du flux normal avec un node IF en tête de workflow, pour éviter qu'une revalidation périodique de Zoom ne parte dans la branche de traitement des enregistrements par erreur.