Zoom RTMS vs Meeting Bots : Ce que les Realtime Media Streams changent (et ce qu'ils ne changent pas)

Zoom a passé 2026 à remodeler la façon dont les développeurs accèdent aux données de meeting. D'abord est venue l'exigence du token OBF en mars, resserrant les conditions dans lesquelles les bots rejoignent des meetings externes. Puis Zoom a lancé le Realtime Media Streams (RTMS) : un pipeline de données qui diffuse en direct l'audio, la vidéo, les flux médias par participant et les transcriptions des meetings Zoom via des WebSockets sécurisés — sans aucun bot participant dans la salle.

Le discours de Zoom est explicite : « plus de bots suspects et déroutants qui rejoignent vos meetings. » Alors, le modèle bot est-il mort ? Loin de là — mais la réponse honnête est plus intéressante que l'un ou l'autre extrême.

Ce qu'est réellement RTMS

RTMS donne aux applications un accès direct aux médias d'un meeting Zoom sous forme de flux structurés : audio et vidéo par participant, données de transcription et événements des participants, diffusés via WebSockets pendant le déroulement du meeting. Aucun client automatisé ne rejoint l'appel — les données proviennent directement de l'infrastructure de Zoom.

C'est véritablement mieux qu'un bot à plusieurs égards :

• Aucun participant visible : rien à admettre depuis une salle d'attente, rien n'occupe de vignette dans la galerie — bien que Zoom affiche toujours la mention standard « le contenu de ce meeting est partagé avec une ou plusieurs applications » et puisse afficher des notifications d'activité d'application pendant qu'une application accède au meeting
• Flux par participant : séparation plus nette que la séparation des interlocuteurs d'un enregistrement mixte
• Aucun problème de fiabilité de connexion : il n'y a pas de client susceptible d'échouer à rejoindre

Ce que RTMS ne résout pas

• Le modèle sans participant de Zoom est inégalé. Google Meet dispose d'une Media API en Developer Preview et Microsoft Teams d'une Real-Time Media Platform — toutes deux donnent accès aux flux bruts, mais toutes deux nécessitent encore un client de type bot pour rejoindre l'appel ; Microsoft oriente explicitement les cas d'usage d'agents IA à l'écart de cette solution. Le RTMS de Zoom est le seul des trois à vous fournir des flux sans qu'aucun participant ne rejoigne l'appel. Un produit construit uniquement sur la capture sans participant couvre une seule plateforme aujourd'hui ; une API de meeting bot couvre les trois avec une seule intégration.
• Une configuration d'application côté Zoom est requise. RTMS fonctionne via une application Zoom avec les scopes appropriés et une activation au niveau du compte — le type de configuration par tenant que le modèle bot-en-tant-qu'invité évite.
• Les artefacts d'enregistrement sont de votre responsabilité. RTMS vous fournit des flux ; assembler des enregistrements, des transcriptions et des archives consultables à partir de ceux-ci est une infrastructure que vous construisez et exploitez.
• Les meetings auxquels vous êtes invités. Le cas d'usage principal du modèle bot — enregistrer les meetings auxquels vos utilisateurs participent dans d'autres organisations — dépend de la plateforme et des paramètres de l'hôte dans tous les cas. Sur Zoom, c'est également là que les implémentations divergent : les bots construits sur le Meeting SDK de Zoom ont besoin de l'autorisation OBF pour les meetings externes, avec l'obligation que l'utilisateur ayant autorisé reste présent. Le degré d'exposition d'un fournisseur donné à cette contrainte dépend de la façon dont son bot rejoint réellement l'appel — et si votre produit doit construire un écran de consentement Zoom ou non vaut la peine d'être demandé directement, car toutes les implémentations ne le requièrent pas.

L'architecture réaliste : les deux

Les équipes qui développent des produits de meeting en 2026 convergent vers un modèle hybride : RTMS là où il est disponible et activé, des bots partout ailleurs. C'est également notre position chez Meeting BaaS — la même API qui vous donne des bots pour Zoom, Google Meet et Microsoft Teams aujourd'hui est là où la capture basée sur RTMS s'intègre au fur et à mesure que Zoom la déploie, sans modifier votre intégration.

Si vous souhaitez des données de meeting en direct dès maintenant, sur les trois plateformes, le streaming en temps réel fournit déjà de l'audio en direct et des transcriptions via WebSockets depuis le bot lui-même — la même forme de données que promet RTMS, sans la contrainte d'une plateforme unique.

Que faire aujourd'hui

1. Vous développez uniquement sur Zoom, en entreprise, avec contrôle des locataires ? Suivez RTMS de près ; c'est le chemin sanctionné et Zoom y investit.
2. Vous développez sur plusieurs plateformes ? Le modèle bot reste votre intégration principale — une API, trois plateformes, sans déploiement d'application Zoom par locataire.
3. Vous utilisez déjà des bots sur Zoom ? Assurez-vous d'être compatible OBF — c'est le changement avec une échéance ferme qui est déjà passée (2 mars 2026).

Prochaines étapes

• API de meeting bot — capture multiplateforme dès aujourd'hui
• Transcription et streaming de meeting en temps réel — données WebSocket en direct sur les trois plateformes
• L'exigence du token OBF de Zoom expliquée
• Documentation RTMS de Zoom