Bots Microsoft Teams Authentifiés : Éviter la Salle d'Attente

Un bot anonyme qui rejoint un meeting Teams atterrit dans la salle d'attente. Il faut que quelqu'un remarque la notification « quelqu'un attend » et le laisse entrer. Si personne ne le fait, le bot expire et vous n'avez pas d'enregistrement. Microsoft ajoute par ailleurs de plus en plus de captchas sur le parcours d'accès invité, qu'un navigateur headless ne sait pas résoudre.

Un bot connecté à un vrai compte Microsoft 365 saute tout ça. Pas de salle d'attente, pas de notification que l'organisateur peut rater, pas de captcha. Son nom dans la liste des participants vient du compte.

Un bot invité attend dans le lobby derrière un captcha ; un bot connecté à Microsoft 365 rejoint directement le meeting

Opt-in, bot par bot. Omettez teams_config et vos bots continuent de rejoindre les meetings en tant qu'invités, sans changement.

Pourquoi ce n'est pas du SAML

Nous avons livré les bots Google Meet authentifiés avec SAML, notre API jouant le rôle de fournisseur d'identité pour un Workspace qui vous appartient. La question évidente, c'est pourquoi Teams ne fonctionne pas pareil.

Microsoft n'offre aucun chemin équivalent. Faire accepter un IdP tiers à Entra ID suppose une fédération complète du tenant, ce qui est un engagement bien plus lourd que téléverser un certificat dans un profil SSO hérité, et pas quelque chose que nous demanderions à un client. Teams s'authentifie donc comme le ferait une personne : email, puis mot de passe, saisis dans login.microsoftonline.com.

Cette seule différence entraîne tout le reste :

	Google Meet	Microsoft Teams
Mécanisme	Assertion SAML, nous jouons l'IdP	Identifiant et mot de passe
Ce que contient la ressource workspace	Domaine, certificat, clé privée	Domaine du tenant uniquement
L'identifiant quitte-t-il nos serveurs ?	Non. Nous signons une assertion côté serveur.	Oui. Le bot le récupère une fois, en TLS.
Secret stocké	`private_key_pem`	`password`, chiffré
Mode de défaillance	Certificat qui ne correspond plus, utilisateur suspendu	Mauvais mot de passe, demande de MFA

Le bot Teams doit détenir le vrai mot de passe au moment de rejoindre, parce qu'il n'y a pas d'autre moyen de le saisir. Il le récupère une seule fois depuis un endpoint de résolution authentifié, indexé par un identifiant de session à durée de vie courte, sur le même modèle que la récupération du token OBF par le bot Zoom. Le mot de passe est chiffré au repos en AES-256-GCM et n'est jamais renvoyé par aucun endpoint de lecture.

L'API

Même structure à deux niveaux que pour Meet : un workspace qui représente un tenant Microsoft 365, et des logins rattachés à celui-ci.

POST   /v2/teams-workspaces
GET    /v2/teams-workspaces
GET    /v2/teams-workspaces/:workspace_id
PATCH  /v2/teams-workspaces/:workspace_id
DELETE /v2/teams-workspaces/:workspace_id

POST   /v2/teams-logins
GET    /v2/teams-logins
GET    /v2/teams-logins/utilization
GET    /v2/teams-logins/:credential_id
PATCH  /v2/teams-logins/:credential_id
DELETE /v2/teams-logins/:credential_id

Le workspace est léger, puisqu'il n'y a pas de certificat à stocker. Il existe pour que les comptes d'un même tenant soient regroupés et puissent être désactivés d'un bloc :

{
  "name": "Contoso Production Tenant",
  "domain": "contoso.onmicrosoft.com"
}

Les comptes situés sur n'importe lequel des domaines vérifiés du tenant peuvent y être ajoutés.

Puis chaque compte :

{
  "workspace_id": "f0e1d2c3-b4a5-6789-0123-456789abcdef",
  "name": "Teams Bot Pool — Account 1",
  "email": "bot1@contoso.onmicrosoft.com",
  "password": "...",
  "email_group": "bots@contoso.onmicrosoft.com"
}

password est en écriture seule. Relire le login vous rend tout sauf le mot de passe :

{
  "credential_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "workspace_id": "f0e1d2c3-b4a5-6789-0123-456789abcdef",
  "name": "Teams Bot Pool — Account 1",
  "email": "bot1@contoso.onmicrosoft.com",
  "email_group": "bots@contoso.onmicrosoft.com",
  "state": "active",
  "last_error_message": null,
  "last_error_at": null,
  "last_used_at": "2026-08-10T14:22:03.000Z",
  "active_session_count": 3,
  "extra": null,
  "created_at": "2026-08-01T09:12:44.000Z",
  "updated_at": "2026-08-10T14:22:03.000Z"
}

Changer un mot de passe, c'est un PATCH avec le nouveau. Rien d'autre ne bouge et les bots en cours gardent leurs slots.

Sur un bot

{
  "meeting_url": "https://teams.microsoft.com/l/meetup-join/...",
  "bot_name": "Recording Bot",
  "teams_config": {
    "email_group": "bots@contoso.onmicrosoft.com",
    "fallback": "anonymous"
  }
}

teams_config se résout exactement comme meet_config :

Ce que vous envoyez	Ce qui se passe
`null` (la valeur par défaut)	Accès en tant qu'invité anonyme.
`{ "email_group": "X" }`	Round-robin sur les logins actifs du groupe X.
`{ "credential_id": "Y" }`	Force le login Y.
Les deux, avec un groupe non vide	`email_group` l'emporte, `credential_id` est ignoré.
`{ "email_group": "" }` seul	Round-robin sur tous les logins actifs de l'équipe, sans filtre de groupe.
`{ "email_group": "", "credential_id": "Y" }`	Le login Y est forcé. Un groupe vide n'est pas un groupe, donc `credential_id` reprend la main.

En cas de saturation, fallback: "fail" renvoie FST_ERR_TEAMS_LOGIN_UNAVAILABLE avec un 503, et fallback: "anonymous" retombe sur un accès invité. Pour Teams en particulier, "anonymous" est une valeur par défaut plus raisonnable que pour Meet, parce qu'un accès invité fonctionne encore souvent : il est juste plus lent et moins fiable.

Combien de bots un même compte peut-il faire tourner en même temps ?

La question revient sans arrêt, parce que tout le monde a déjà vu Teams annoncer qu'on ne peut être actif que dans un seul meeting et qu'il faut mettre les autres en attente.

Cette limite est par session cliente, pas par compte. Elle vient du fait qu'une instance de l'app Teams possède une seule pile audio. La page des limites publiées par Microsoft ne mentionne aucun plafond par utilisateur sur les meetings simultanés, et leur propre recommandation pour être dans deux meetings à la fois est d'utiliser un deuxième appareil ou un deuxième profil de navigateur.

Chaque bot MeetingBaaS est son propre pod, avec son propre navigateur et sa propre connexion, neuve, à login.microsoftonline.com. Chaque bot est une session cliente distincte. Un même compte peut donc alimenter de nombreux bots dans des meetings différents, en simultané.

Le plafond par défaut est de 20 sessions simultanées par login, et GET /v2/teams-logins/utilization vous situe par rapport à lui :

{
  "logins_total": 3,
  "logins_active": 3,
  "logins_invalid": 0,
  "concurrent_sessions": 41,
  "concurrent_capacity": 60,
  "utilization_pct": 68,
  "by_email_group": [
    { "email_group": "bots@contoso.onmicrosoft.com", "logins": 3, "concurrent": 41, "capacity": 60 }
  ]
}

Le vrai plafond, ce n'est pourtant pas Teams. C'est Entra ID. N connexions simultanées d'un même compte depuis N IP de pods différentes, c'est exactement le motif que l'accès conditionnel basé sur les risques est fait pour signaler, et quand il se déclenche vous récupérez une demande de MFA à laquelle un navigateur headless ne peut pas répondre. Si vous arrivez à saturation, augmenter le plafond par compte vaut le coup d'être tenté avant de provisionner d'autres comptes, mais mesurez à 5, puis 10, puis 20 sur un seul compte et guettez les échecs de connexion, plutôt que de sauter directement à un chiffre élevé.

Configuration du tenant

C'est la partie qui demande de l'attention, alors lisez toute la section avant de changer quoi que ce soit.

Utilisez un tenant dédié

Créez les comptes bots dans un tenant qui leur est propre, par exemple bot1@contoso-bots.onmicrosoft.com. Business Basic suffit.

Les bots authentifiés ont besoin de réglages au niveau du compte que vous ne devriez pas appliquer à un tenant où de vraies personnes se connectent. Un tenant séparé ramène ce rayon d'impact à zéro. Ce n'est pas un confort, c'est le prérequis de tout ce qui suit.

Assurez-vous que les comptes bots ne déclenchent pas de demande de MFA

Un tenant neuf arrive avec les paramètres de sécurité par défaut (Security Defaults) activés, ce qui impose la page d'inscription « Aidez-nous à protéger votre compte » (« Let's keep your account secure ») à la première connexion. Un navigateur headless ne sait pas la franchir, et c'est de loin la raison la plus fréquente d'échec d'une connexion Teams.

Il y a deux chemins possibles, et lequel choisir dépend du tenant :

Tenant bots dédié, sans compte humain. Désactivez les paramètres de sécurité par défaut pour tout le tenant : entra.microsoft.com → Identité → Vue d'ensemble → Propriétés → Gérer les paramètres de sécurité par défaut → Désactivé.

Tenant contenant des comptes humains. Laissez la MFA activée. Mettez les comptes bots dans un groupe, et excluez uniquement ce groupe de votre stratégie d'accès conditionnel « exiger la MFA ». Cela nécessite Entra ID P1. Plus long à mettre en place, et bien meilleure hygiène.

Dans les deux cas, vérifiez aussi que la MFA par utilisateur héritée est désactivée pour les comptes bots, et coupez la campagne d'inscription aux méthodes d'authentification pour qu'elle ne réintroduise pas la demande plus tard.

L'état visé : se connecter avec un compte bot donne email, mot de passe, puis « Rester connecté ? » (« Stay signed in? »), et rien entre les deux.

Connectez-vous une fois, à la main

Connectez-vous manuellement à chaque compte bot dans un navigateur normal et passez tous les écrans de premier lancement que Microsoft affiche. Même raisonnement que pour l'étape d'onboarding Workspace côté Meet : la première connexion est interactive que ça vous plaise ou non, alors autant s'en débarrasser avant qu'un bot ait besoin du compte.

Enregistrez le workspace et les logins

curl -X POST https://api.meetingbaas.com/v2/teams-workspaces \
  -H "x-meeting-baas-api-key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"domain": "contoso-bots.onmicrosoft.com"}'

Puis un POST /v2/teams-logins par compte.

À quoi ressemble un échec

Une connexion qui échoue d'une façon qui va continuer d'échouer bascule le login en invalid et l'exclut des assignations. Les trois causes :

Cause	Ce que ça veut dire
Identifiants invalides	Le mot de passe a changé, ou a été mal saisi à la création.
MFA requise	Les paramètres de sécurité par défaut, une stratégie d'accès conditionnel ou une détection de risque soumettent le compte à une vérification.
Timeout	Microsoft était lent, ou le flux s'est bloqué.

Les timeouts sont traités comme passagers et n'invalident rien. Les deux autres, si, et enregistrent last_error_message, last_error_at et failure_data avec le bot qui est tombé dessus.

Réactivez une fois la cause corrigée :

PATCH /v2/teams-logins/:credential_id
{ "state": "active" }

Si un compte se met à échouer sur « MFA requise » après avoir fonctionné sans problème pendant des semaines, c'est presque toujours l'accès conditionnel basé sur les risques qui réagit à votre concurrence, pas un mot de passe modifié. Regardez les journaux de connexion dans Entra avant d'aller réinitialiser quoi que ce soit.

Supprimer un login alors que des sessions sont en cours renvoie 409. Les slots sont libérés quand le processus du bot se termine, y compris quand il crashe, donc un pod mort ne fuit pas de capacité de façon permanente.