Teams ferme la porte aux bots externes : le videur passe enfin en mode automatique

l fut un temps où l’invité surprise d’une réunion Teams était un collègue d’un autre service qui s’était trompé de lien. Aujourd’hui, c’est un preneur de notes IA envoyé par un participant externe, qui écoute tout, transcrit tout et expédie le tout vers un cloud tiers dont personne n’a lu les conditions générales. Microsoft vient d’apporter une réponse plus musclée à ce phénomène.

De la détection au blocage

Le sujet n’est pas né cette rentrée. Teams sait déjà détecter les bots de réunion et les signaler aux organisateurs et administrateurs, grâce à un système d’identification déployé plus tôt en 2026 qui s’appuie sur des signaux comportementaux et d’infrastructure pour distinguer un bot d’un humain. Cette détection est activée par défaut sur tous les tenants : auparavant, Teams présentait un tel bot comme un participant ordinaire.

Le problème de ce premier mécanisme tenait au facteur humain. La réponse la plus ferme disponible consistait à envoyer les bots suspects en salle d’attente et à laisser l’organisateur les accepter ou les rejeter un par un. Or, en début de réunion, avec douze personnes qui arrivent en même temps et un micro qui grésille, un participant inconnu peut être admis par mégarde. Chacun a déjà cliqué sur « Admettre tout le monde » pour lancer enfin la réunion. Le bot remercie.

Ce qui arrive concrètement

Annoncée dans le message center sous la référence MC1459141 et au roadmap sous l’ID 566201, la nouveauté ajoute un troisième mode, BlockDetectedBots, qui refuse purement et simplement l’entrée aux bots externes identifiés, sans passage par la salle d’attente ni décision de l’organisateur. Initialement prévue pour mai 2026, la fonction a finalement été livrée avec la mise à jour Teams du 23 septembre 2026. Elle est désactivée par défaut : rien ne change tant que l’administrateur ne l’active pas.

Sur le plan technique, tout passe par l’attribut ExternalBotAccessMode des stratégies de réunion, qui accepte trois valeurs : AllowAllBots (aucune détection, les bots entrent directement), RequireApprovalWhenDetected (les bots détectés sont routés vers la salle d’attente, c’est la valeur par défaut) et BlockDetectedBots (les bots détectés sont bloqués). Dans le centre d’administration Teams, le réglage se trouve dans la section Participation à la réunion et salle d’attente, sous l’intitulé « Manage external bots and their access to meetings ». Côté PowerShell, une ligne suffit :

Set-CsTeamsMeetingPolicy -Identity "<nom de la stratégie>" -ExternalBotAccessMode BlockDetectedBots

Comme toute stratégie de réunion, elle peut s’appliquer à l’ensemble du tenant ou être ciblée sur des utilisateurs et des groupes précis. Notons que certaines sources signalaient il y a quelques semaines que l’option n’était encore configurable que via PowerShell : vérifiez dans votre propre console si l’interface a rattrapé le moteur.

Ce qui n’est pas concerné

Point important pour les architectes : le réglage ne vise que les bots tiers externes. Microsoft 365 Copilot et les bots enregistrés comme applications Entra ID dans votre propre tenant relèvent d’autres licences et permissions, et continuent donc de fonctionner. De même, les bots d’enregistrement de conformité ne jouent pas dans la même cour : invités par le backend Teams via l’API Graph et imposés par une stratégie d’administration, ils contournent totalement la salle d’attente.

Le regard critique

Saluons le progrès, puis grattons un peu le vernis.

D’abord, le mot clé est « identifiés ». Le blocage ne vaut que ce que vaut la détection. Un bot qui se présente comme un utilisateur fédéré authentifié, ou un humain qui enregistre la réunion avec une application installée sur son poste, passera tranquillement. BlockDetectedBots réduit une surface d’attaque, il ne garantit pas la confidentialité d’une réunion.

Ensuite, le dispositif reste binaire à ce stade. Pas de liste blanche : si votre direction commerciale utilise un assistant tiers validé par la DSI, il sera refoulé avec les autres. Microsoft annonce des listes d’autorisation pour les bots approuvés, des rapports et journaux d’audit sur la détection et la présence des bots, ainsi que des contrôles plus granulaires, mais pour l’instant il faudra jouer sur le périmètre des stratégies plutôt que sur une exception par outil. we-fix-pc

Troisième point, la portée. La stratégie protège les réunions organisées par vos utilisateurs. Lorsque vos collaborateurs participent à la réunion d’un partenaire, ce sont les règles du tenant hôte qui s’appliquent. La fuite d’information peut donc continuer, simplement chez le voisin.

Enfin, impossible d’ignorer la dimension concurrentielle. Bloquer Otter, Fireflies ou Read.ai tout en laissant Copilot prendre des notes en toute sérénité, c’est aussi une manière élégante de rappeler aux clients qu’il existe une solution « maison » déjà intégrée. L’argument sécurité est réel (données hébergées dans le périmètre Microsoft 365, gouvernance Purview, conformité RGPD plus simple à démontrer), mais l’argument commercial n’est pas loin derrière. Les deux peuvent être vrais en même temps.

Nos recommandations

Avant d’activer quoi que ce soit, faites un inventaire. Les rapports du centre d’administration Teams et les journaux d’audit Microsoft 365 des 30 derniers jours permettent de voir quels bots externes ont rejoint des réunions dans votre tenant. Vous serez peut-être surpris par le nombre de passagers clandestins.

Ensuite, segmentez. Les équipes juridique, finance, RH ou direction générale justifient souvent BlockDetectedBots, tandis que RequireApprovalWhenDetected convient bien au reste de l’organisation. Pilotez sur un groupe restreint, communiquez avant de basculer (rien de pire qu’un directeur commercial dont l’assistant IA a disparu sans explication), et documentez la doctrine : quels outils sont autorisés, pour quels usages, avec quelle base légale vis-à-vis des participants enregistrés.

Pour compléter le tableau, rappelons que depuis décembre, les administrateurs peuvent aussi bloquer des utilisateurs Teams externes depuis le portail Defender pour contrer des groupes cybercriminels, rançongiciels compris, qui abusent de Teams dans des attaques d’ingénierie sociale. La réunion Teams est devenue une surface d’attaque à part entière. Il était temps que le videur ait le droit de refuser l’entrée sans consulter l’organisateur de la soirée.

Votre commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur la façon dont les données de vos commentaires sont traitées.