Un bot exécutant Chrome en mode anonyme dans Docker a enregistré 1 170 réunions et produit un résumé en 4,6 minutes

Les décisions prises en réunion ne survivent généralement que jusqu’à la réunion suivante. Personne ne rédige de compte rendu et, une semaine plus tard, les participants ne se souviennent que d’environ 10 % de ce qui a été dit. Un second problème, plus récent, s’y ajoute : l’entreprise utilise des agents IA, mais ceux-ci ne connaissent que les informations enregistrées et indexées. Tout ce qui a été décidé oralement n’existe pas pour eux. L’auteur de l’article publié sur Habr a décidé de combler ces deux lacunes avec son propre assistant de réunion et a présenté des chiffres issus de la production.

Pourquoi ni Copilot ni la transcription native

Copilot ne fonctionne que pour les utilisateurs disposant d’un abonnement, ce qui ne convient pas à une automatisation « pour toutes les équipes, sans intervention manuelle ». Il ne couvre pas non plus les tenants externes, Telemost, MTS Link et TrueConf. De plus, l’auteur voulait traiter l’audio des réunions avec les clients sur les serveurs de l’entreprise.

La transcription native de Teams en russe ne lui convenait pas davantage. Sur les mêmes réunions, elle produisait 26–37 mots par minute, alors que le débit normal d’une conversation professionnelle est d’environ 100 mots et que le pipeline de l’auteur en restituait 99–108. Teams transcrit aussi les termes techniques en phonétique, par exemple « ed baton » au lieu de add button. L’échantillon est limité, et l’auteur présente honnêtement cette comparaison comme un ordre de grandeur plutôt que comme un benchmark.

Deux flux au lieu d’un

Il n’a pas été possible de créer une solution universelle, car il existe deux types de réunions Teams.

Les réunions de canal — daily meetings, planifications et rétrospectives — sont automatiquement enregistrées conformément à la politique interne, puis stockées sur SharePoint. Elles ne disposent pas d’une conversation de groupe classique : les messages se trouvent dans un fil sous la publication racine du canal, auquel un invité anonyme ne peut pas accéder. Un bot est donc installé dans l’équipe. Il lit le canal et intercepte l’événement système CallRecording portant le statut Success. Il récupère le MP4, le convertit en WAV 16 kHz, l’envoie au système de reconnaissance vocale, puis publie le résumé dans le fil de la réunion. Cela nécessite l’autorisation RSC ChannelMessage.Read.Group, accordée par le propriétaire de l’équipe sans consentement administrateur à l’échelle du tenant.

Toutes les autres réunions sont prises en charge par « Assistant de réunion ». Celui-ci est ajouté à l’invitation comme un participant ordinaire et, au début de la réunion, une instance anonyme de Chrome exécutée dans Docker la rejoint. L’enregistrement ne commence qu’après un consentement explicite : si l’assistant a été invité et admis, il enregistre ; sinon, il ne fait rien. Les deux flux sont physiquement séparés, avec leurs propres inscriptions, applications et droits. La fuite d’une clé de l’un n’affecte donc pas l’autre.

Les pièges à retenir

Condition de concurrence pendant l’enregistrement. Au départ, l’état était conservé dans des fichiers JSON. Dès la première semaine, le listener et une tâche cron de secours ont envoyé deux fois le même enregistrement. La solution a consisté à utiliser Postgres avec INSERT … ON CONFLICT DO NOTHING et SELECT … FOR UPDATE. La commande claim renvoie alors l’un des modes new, retake, attach ou skip.

Impasses liées aux transcriptions. L’autorisation RSC ChannelMeetingTranscript.Read.Group renvoyait une erreur 403 ; SharePoint refusait les jetons app-only dépourvus de certificat ; et Graph onlineMeetings/transcripts exigeait une application access policy pour l’organisateur. Le pipeline repose donc principalement sur le MP4 et sur un système de reconnaissance vocale interne, tandis que le VTT de Teams sert de source auxiliaire.

Noms des locuteurs. Le nombre de locuteurs — utilisé comme indication num_speakers — et leurs noms sont extraits du VTT. Les segments sont ensuite associés aux clusters de diarisation selon leur décalage temporel. Sur trois réunions vérifiées manuellement, 94–99 % des segments ont reçu le bon nom. Toute association incertaine devient « Anonyme » : attribuer une réplique à la mauvaise personne est pire que de la laisser anonyme.

Par ailleurs, Graph API ne voit pas le calendrier d’Exchange on-premises, ce qui a imposé de passer par EWS. La session du bot navigateur expirait silencieusement à cause du cookie de session. Quant au détecteur de locuteur, il ne captait qu’un quart des paroles avant le remplacement des événements par une interrogation de l’état.

Ce que cela signifie en pratique

Si vous construisez un système similaire, la conclusion est la suivante. N’essayez pas de couvrir toutes les plateformes avec une solution unique : les réunions de canal Teams coûtent moins cher à traiter avec un bot intégré à l’équipe, tandis que le reste nécessite une présence effective dans la conversation. Conservez l’état dans une base de données avec des verrous, pas dans des fichiers. Adaptez les prompts de résumé au type de réunion — daily meeting, rétrospective ou planification — et rechargez-les à chaque envoi afin de pouvoir les modifier sans redémarrage. Surtout, les transcriptions indexées par la plateforme donnent aux agents une mémoire des décisions prises oralement. C’est le socle d’agents proactifs.

Le système présente aussi des limites. Le flux 1 ne prend pas en charge les canaux privés ; lors des réunions externes, le bot doit être admis depuis le lobby ; et Teams lui-même rencontre parfois des bugs qui empêchent le bot de recevoir les mises à jour du canal — issue msteams-docs #11106. Les chiffres proviennent en outre d’une seule entreprise et n’ont pas fait l’objet d’une vérification indépendante. Toutefois, quatre mois de production avec 93 organisateurs constituent un argument convaincant.