Bots Google Meet Authentifiés : Sortir de la File des Menaces Potentielles

En avril 2026, Google Meet s'est mis à trier les demandes d'accès en deux files. Les personnes invitées et les membres de l'organisation passent dans une file vérifiée et entrent sans encombre. Tous les autres atterrissent dans une seconde file, que les organisateurs voient étiquetée « Menaces potentielles » (« With potential threats »), où le bouton par défaut est Refuser et non Autoriser.

Les bots d'enregistrement tournent sur des IP de data center. Ils atterrissent tous dans la seconde file.

Nous avons commencé par la solution évidente. Les proxys résidentiels ne fonctionnent pas ici : les pools sont partagés, donc leur réputation est déjà grillée, et Google les signale de la même façon. La seule chose qui fasse réellement passer un bot dans la file vérifiée, c'est d'être un vrai utilisateur Google Workspace dans une vraie organisation.

C'est donc ce que nous avons construit. Un bot peut désormais se connecter à un compte Workspace qui vous appartient, et rejoindre le meeting en tant que cet utilisateur.

C'est opt-in, et bot par bot. Omettez meet_config de votre requête et rien ne change : vos bots continuent de rejoindre les meetings de façon anonyme, exactement comme avant.

Ce qui surprend les gens

Tout le monde suppose qu'un « bot authentifié » veut dire OAuth, et qu'il va falloir nous donner accès à son compte Google. Ce n'est pas ce qui se passe.

Le mécanisme, c'est SAML. Votre Workspace est configuré avec un profil SSO hérité (Legacy SSO profile) qui pointe vers notre endpoint de connexion. Quand le bot saisit son email dans la page de connexion Google, Google voit que le domaine est fédéré et le redirige vers nous. Nous signons une assertion SAML avec la clé privée correspondant au certificat que vous avez téléversé dans votre propre Workspace, le navigateur la renvoie à Google en POST, et le bot est connecté.

Vous n'accordez à MeetingBaaS aucun accès à une API Google. Vous téléversez un certificat public dans un Workspace que vous contrôlez. Nous détenons la clé privée correspondante et nous nous en servons pour exactement une chose.

Les trois approches auxquelles on pense d'abord s'effondrent toutes :

Approche	Pourquoi ça ne marche pas
Identifiant et mot de passe	Demandes de 2FA, rotation des mots de passe, captchas et vérifications « connexion inhabituelle ». Un navigateur headless ne sait répondre à aucune d'elles.
Google OAuth (3LO)	Exige une boîte de dialogue de consentement interactive pour chaque compte. Il n'y a personne pour cliquer dessus.
Comptes de service	Ne peuvent tout simplement pas rejoindre un appel Meet en tant que participant.

SAML contourne tout cela. Il n'y a pas de second facteur à satisfaire, parce que l'assertion est l'authentification.

Les bots anonymes en data-center atterrissent par défaut dans la file des menaces ; une assertion SAML signée déplace le même bot dans la file vérifiée en tant que véritable utilisateur Workspace

Deux ressources, pas une

L'API se divise en workspaces et en logins, et cette séparation n'a rien d'arbitraire.

Le profil SSO hérité de Google ne contient qu'un seul certificat de validation par Workspace, partagé par tous ses utilisateurs. Si nous rattachions le certificat au login, ajouter un compte bot voudrait dire soit générer une nouvelle paire de clés et écraser le certificat dans Google Admin — ce qui casse instantanément tous les logins déjà enregistrés avec l'ancien —, soit recopier à la main le même certificat et la même clé dans chaque appel de création.

Le certificat vit donc sur le workspace, et les identités s'y rattachent.

/v2/meet-workspaces   → domain + SAML certificate and private key
/v2/meet-logins       → the Workspace users, attached via workspace_id

Workspaces

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

Deux façons d'en créer un. Soit vous nous laissez générer la paire de clés :

{
  "name": "Acme Production",
  "domain": "bots.acme.com",
  "generate_keypair": true
}

Soit vous apportez la vôtre :

{
  "name": "Acme Production",
  "domain": "bots.acme.com",
  "cert_pem": "-----BEGIN CERTIFICATE-----...",
  "private_key_pem": "-----BEGIN PRIVATE KEY-----..."
}

Passez l'un ou l'autre. Passer les deux, ou aucun, est une erreur de validation. À la création, nous vérifions que le certificat et la clé se parsent bien, que la clé correspond au certificat, et que le domaine est un nom d'hôte valide que vous n'avez pas déjà enregistré.

La réponse inclut toujours cert_pem, quel que soit le chemin choisi, parce que c'est la valeur à coller dans Google Admin. private_key_pem n'est jamais renvoyé, par aucun endpoint, jamais.

domain est immuable après la création. Tout le reste peut être modifié par PATCH, y compris la rotation conjointe du certificat et de la clé.

Logins

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

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

Le domaine de l'email doit correspondre à celui du workspace parent, ou en être un sous-domaine. email et workspace_id sont immuables : pour déplacer un login, supprimez-le et créez-en un nouveau.

email_group est optionnel, et vaut le coup d'être renseigné. Les logins qui partagent un groupe forment un même pool en round-robin, et si vous mettez cette adresse de groupe dans vos invitations d'agenda, le bot assigné devient un invité, ce qui est le chemin le plus rapide possible à travers la salle d'attente.

Les deux ressources acceptent un objet extra pour vos propres métadonnées, sur lequel vous pouvez ensuite filtrer :

GET /v2/meet-logins?extra=environment:production

L'utiliser sur un bot

{
  "meeting_url": "https://meet.google.com/abc-defg-hij",
  "bot_name": "Recording Bot",
  "meet_config": {
    "email_group": "bots@bots.acme.com",
    "fallback": "fail"
  }
}

Comment meet_config est résolu :

Ce que vous envoyez	Ce qui se passe
`null` (la valeur par défaut)	Bot anonyme. Pas de login, pas de SAML, comportement actuel.
`{ "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.

L'assignation prend le login qui a le moins de sessions actives, départage par le moins récemment utilisé, et réserve le slot avec une mise à jour conditionnelle atomique, pour que deux bots simultanés ne puissent pas prendre le même.

Quand le pool est saturé, c'est fallback qui décide. "fail" est la valeur par défaut et renvoie FST_ERR_MEET_LOGIN_UNAVAILABLE. "anonymous" bascule sans bruit sur une connexion non authentifiée, ce qui est le bon choix quand avoir un enregistrement compte plus que d'en avoir un vérifié.

Capacité

Chaque login porte un plafond de sessions simultanées, 20 par défaut. C'est délibérément en dessous du seuil à partir duquel Google est réputé commencer à limiter, et c'est un plancher que vous pouvez relever une fois votre propre trafic mesuré.

GET /v2/meet-logins/utilization vous donne tout le tableau en un seul appel :

{
  "logins_total": 5,
  "logins_active": 5,
  "logins_invalid": 0,
  "concurrent_sessions": 47,
  "concurrent_capacity": 100,
  "utilization_pct": 47,
  "by_email_group": [
    { "email_group": "bots@bots.acme.com", "logins": 5, "concurrent": 47, "capacity": 100 }
  ]
}

Surveillez utilization_pct. S'il dépasse régulièrement 70, il vous faut plus d'utilisateurs Workspace, parce que la queue de votre trafic tape déjà dans fallback.

Les workspaces comme les logins ont un state qui vaut active ou invalid. Seul le système positionne invalid, et il le fait quand la connexion d'un bot échoue d'une façon qui va continuer d'échouer : une assertion SAML rejetée, ce qui veut généralement dire que le certificat dans Google Admin ne correspond plus au nôtre, ou un utilisateur Workspace suspendu ou supprimé. Les timeouts passagers ne font basculer personne.

Un login invalidé cesse de recevoir des assignations et enregistre last_error_message, last_error_at, et un objet failure_data avec le bot qui est tombé dessus. La réactivation est délibérément manuelle, une fois la cause corrigée :

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

PATCH n'accepte que "active". Essayer de positionner "invalid" vous-même est rejeté par la validation de la requête, avec un 400.

Supprimer un login ou un workspace alors que des sessions sont en cours renvoie 409, plutôt que d'arracher l'identifiant à un bot en train de tourner. Supprimer un workspace supprime en cascade ses logins.

Mise en place

Prenez un Workspace ou un sous-domaine dédié

Utilisez un Google Workspace séparé, ou au minimum un sous-domaine dédié du type bots.acme.com. N'utilisez pas votre organisation principale.

La configuration SSO dans Google Admin s'applique à toute l'organisation. La faire pointer vers nous sur le Workspace où vos employés se connectent redirigerait aussi leurs connexions. Un forfait payant est nécessaire, les profils SSO n'étant pas disponibles dans l'offre gratuite.

Créez le workspace

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

Conservez le cert_pem de la réponse.

Configurez le SSO dans Google Admin

Sécurité → Configurer l'authentification unique (SSO) avec un fournisseur d'identité tiers → Ajouter un profil SAML → Profil SSO hérité (Legacy SSO profile).

Champ	Valeur
URL de la page de connexion	`https://api.meetingbaas.com/v2/meet-sso/sign-in`
URL de la page de déconnexion	`https://api.meetingbaas.com/v2/meet-sso/sign-out`
Certificat de validation	le `cert_pem` de l'étape 2
Utiliser un émetteur spécifique au domaine	Oui

Activez le profil, puis affectez-le dans « Gérer les attributions de profils SSO » (Manage SSO profile assignments).

Créez les utilisateurs Workspace

Un utilisateur Google Workspace par slot du pool de bots simultanés.

Chacun doit passer une fois, de façon interactive, par l'onboarding « Bienvenue dans Google Workspace » avant de fonctionner. C'est l'étape que les gens sautent, et elle produit un échec de connexion qui ressemble à un problème de certificat mais n'en est pas un. Profitez-en pour régler la langue du compte sur anglais (États-Unis) depuis myaccount.google.com.

Vous pouvez aussi créer un groupe Google, y mettre les utilisateurs bots, et ajouter ce groupe à vos invitations d'agenda.

curl -X POST https://api.meetingbaas.com/v2/meet-logins \
  -H "x-meeting-baas-api-key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workspace_id": "...",
    "name": "bot1",
    "email": "bot1@bots.acme.com",
    "email_group": "bots@bots.acme.com"
  }'

Envoyez un bot

Ajoutez meet_config à votre appel POST /v2/bots et regardez-le entrer directement dans le meeting.

Une limite à connaître dès le départ

Google affiche le nom propre de l'utilisateur Workspace dans la liste des participants, et écrase ce que vous passez dans bot_name. Si le nom affiché compte pour vous, le seul contournement aujourd'hui est un utilisateur Workspace par nom que vous voulez afficher, ce qui ne monte pas très loin en charge. Nous y travaillons.