Hier, l'enterprise-managed auth est passé en disponibilité générale sur les plans Team et Enterprise de Claude. Derrière le nom barbare, une seule idée : l'admin autorise un connecteur une fois, depuis l'annuaire d'identité de la boîte, et tout le monde en hérite au premier login. Ce guide reprend tout : le schéma des deux décisions, les 10 connecteurs compatibles, les prérequis réels, la config écran par écran, ce qui se passe sous le capot, et un plan de pilote sur une seule équipe.
1Le schéma des deux décisions
Brancher un outil dans Claude, ça n'a jamais été une décision. C'en a toujours été deux, prises par deux personnes différentes, à deux moments différents. C'est la deuxième qui vient de changer de main.
| La décision | Avant | Maintenant |
|---|---|---|
| Quels outils Claude a le droit de toucher | L'admin, dans les paramètres de l'organisation | L'admin, au même endroit |
| Avec quel compte on s'y connecte | Le salarié, seul devant son écran d'autorisation OAuth | ★ L'admin, via l'annuaire d'identité |
| Qui a le pouvoir de couper l'accès | Le salarié (ou personne, en pratique) | ★ L'annuaire, comme pour tout le reste du SI |
Le nouveau scénario. Un salarié arrive, se logue à Claude lundi matin, et ses outils sont déjà branchés. Slack, Notion, Atlassian, Figma. Zéro écran d'autorisation, zéro ticket au support. L'accès suit les rôles et les groupes qui existent déjà dans l'annuaire — tu ne recrées pas une deuxième cartographie des droits en parallèle. Anthropic appelle ça le « zero-touch connector setup ».
2Les quatre problèmes que ça règle
L'onboarding. Les connecteurs sont là dès le premier login, au lieu d'une semaine passée à cliquer « Autoriser » outil par outil. Pour une boîte qui intègre plusieurs personnes par mois, c'est le poste de friction n°1 qui disparaît — et surtout, l'usage de Claude ne dépend plus de la bonne volonté de chacun à finir sa configuration.
L'offboarding. Tu désactives la personne dans l'annuaire, et ses connecteurs tombent avec. La révocation côté annuaire met fin aux sessions de connecteur en cours — au lieu d'un jeton d'accès qui traîne quelque part parce que personne ne sait qu'il existe. C'est le point qui fait basculer la sécurité, parce que c'est le seul du lot qui ferme un risque au lieu d'ouvrir un confort.
Le mélange perso/pro. Tu peux exiger qu'un connecteur ne passe que par l'annuaire, et donc exclure les comptes personnels. Fini le salarié qui branche son Notion perso sur l'espace de travail de la boîte sans mauvaise intention — et fini la donnée d'entreprise qui transite par un compte que tu ne contrôles pas.
Le pilote. Tu ouvres un connecteur à une seule équipe, tu observes, puis tu élargis. C'est le point détaillé en section 8 — c'est aussi celui qui fait passer le sujet en comité, parce qu'il transforme « on déploie l'IA » en « on teste sur douze personnes ».
3Les 10 connecteurs compatibles
Au passage en disponibilité générale, dix connecteurs officiels supportent l'autorisation gérée. Chaque éditeur maintient sa propre documentation de configuration, et Claude affiche le lien directement dans la console d'admin au moment où tu actives le connecteur. Le point d'entrée côté Claude est la page d'aide « Authorize MCP connectors for your entire organization ».
| Connecteur | Ce que ça ouvre à Claude | Depuis |
|---|---|---|
| Slack | Conversations, canaux, historique d'équipe | ★ La GA (hier) |
| Notion | Bases de connaissances, docs, bases de données | ★ La GA (hier) |
| Datadog | Métriques, logs, monitoring | ★ La GA (hier) |
| Atlassian | Jira & Confluence : tickets, specs, documentation | La bêta (juin) |
| Asana | Projets, tâches, charges d'équipe | La bêta (juin) |
| Linear | Issues, cycles, roadmap produit | La bêta (juin) |
| Figma | Fichiers de design, composants, specs | La bêta (juin) |
| Canva | Créations, gabarits, kit de marque | La bêta (juin) |
| Supabase | Base de données, schémas, projets | La bêta (juin) |
| Granola | Notes de réunion | La bêta (juin) |
Une nuance qui compte. Chaque connecteur du répertoire s'appuie sur une seule application OAuth partagée : il n'y a pas de client OAuth dédié par organisation. Ce qui délimite ce que Claude peut voir, ce sont les droits que la personne possède déjà dans l'outil concerné. Autrement dit, l'autorisation gérée branche un accès — elle n'en crée pas un nouveau. Un salarié qui n'a pas accès à un canal Slack ne l'obtient pas parce que Claude est branché.
4Les prérequis, avant même de regarder les connecteurs
C'est là que 80 % des boîtes vont s'arrêter, et autant le savoir tout de suite plutôt qu'après avoir vendu le projet en interne.
Un plan Team ou Enterprise. La fonctionnalité n'existe pas sur les formules individuelles.
Un annuaire d'identité branché sur ton organisation Claude. Le SSO doit déjà fonctionner. Si tes salariés se connectent à Claude avec une adresse et un mot de passe, il n'y a pas d'annuaire pour porter la décision — donc rien à déléguer.
Okta au lancement, d'autres fournisseurs d'identité annoncés. Ce n'est pas un choix arbitraire : le mécanisme s'appuie sur un standard ouvert qu'Okta a porté (voir section 7), et l'écosystème s'aligne progressivement.
5La config, écran par écran
Tu la fais une fois par connecteur. Compte une poignée de minutes si ton annuaire est déjà branché.
Le point de départ. Paramètres de l'organisation → Connectors → tu choisis le connecteur → onglet Configuration → « Set up » à côté de Managed authorization.
Étape « Connect ». Tu confirmes la liaison avec ton annuaire d'identité et tu lances un test. Si le test ne passe pas, rien n'est activé — tu ne casses rien en essayant.
Étape « Roles ». Le cœur du sujet : tu choisis qui reçoit ce connecteur automatiquement. Tu peux cocher les rôles intégrés (User, Admin, Owner, Primary owner) ou t'appuyer sur des rôles personnalisés. Laisser les rôles intégrés décochés, c'est exactement ce qui te donne un pilote.
Étape « Scopes ». Tu définis les permissions que Claude a le droit de demander via ton annuaire. C'est là que tu réponds à la sécurité avec des cases, pas avec une promesse.
Puis « Save & turn on ». Un troisième réglage existe côté rôle : dans l'onglet Connectors d'un rôle personnalisé, tu choisis entre Individually, Managed authorization ou Set per connector. Traduction : tu peux traiter un connecteur sensible différemment des autres, pour le même rôle. C'est le réglage le plus fin du dispositif, et le moins connu.
| Réglage du rôle | Ce que ça veut dire | Quand l'utiliser |
|---|---|---|
| Individually | Chacun s'authentifie lui-même, comme avant | Rôles externes, prestataires, cas hors annuaire |
| Managed authorization | Tout passe par l'annuaire | ★ Le cas standard des salariés |
| Set per connector | Tu arbitres connecteur par connecteur | Quand un seul outil est sensible (finance, RH, prod) |
6Ce que voit le salarié (et le filet de sécurité)
Rien. C'est tout l'intérêt. Il ouvre Claude, le connecteur est là, il travaille — avec l'identité fournie par l'annuaire de la boîte, pas avec un compte qu'il a choisi. Son accès s'élargit ou se retire au rythme de son provisionnement dans l'annuaire, sans qu'il ait quoi que ce soit à faire.
Le filet. Si l'autorisation gérée échoue, Claude propose quand même la connexion individuelle pour ne bloquer personne. Utile au quotidien — mais à garder en tête si ton objectif est de fermer l'accès par comptes personnels : c'est un réglage à poser explicitement, ce n'est pas un effet automatique du dispositif.
À noter aussi : les connecteurs personnels restent possibles en parallèle pour l'usage individuel. L'autorisation gérée n'efface pas l'ancien monde, elle lui ajoute une voie officielle.
7Sous le capot — la page à transmettre à ta DSI
Cette section est plus technique. Elle sert à une chose : quand ton RSSI demandera « concrètement, il se passe quoi ? », tu auras la réponse au lieu d'un « c'est automatique ».
Le principe. Au lieu d'afficher un écran de consentement, Claude présente au serveur d'autorisation de l'éditeur une assertion d'identité : un jeton JWT signé par l'annuaire du client, qui atteste de l'identité de l'utilisateur. Le serveur vérifie la signature et renvoie un jeton d'accès, en un seul échange en arrière-plan. Pas de redirection navigateur, pas de page de consentement. Le connecteur est simplement disponible.
Les standards utilisés. C'est l'extension « enterprise managed authorization » du protocole MCP, construite sur le JWT bearer authorization grant (RFC 7523) : le serveur doit accepter urn:ietf:params:oauth:grant-type:jwt-bearer sur son endpoint de token et l'annoncer dans ses métadonnées (RFC 8414). Quand l'annuaire le permet, Claude ajoute aussi un resource indicator (RFC 8707) pointant l'URL du serveur MCP, pour lier le jeton à la bonne ressource.
Les garde-fous. Le serveur d'autorisation doit maintenir une liste blanche d'émetteurs de confiance par client, et rejeter toute assertion dont l'émetteur n'y figure pas — même si la signature est valable. Signature, émetteur, audience, expiration et sujet sont vérifiés à chaque requête. Point important : l'enregistrement dynamique de client (DCR) n'est pas supporté dans ce mode, parce que l'annuaire inscrit un client_id fixe dans chaque assertion.
Durées de vie. La durée du jeton d'accès est fixée par l'éditeur, celle de l'assertion par l'annuaire du client — Anthropic ne contrôle ni l'une ni l'autre. Un jeton court (une heure, typiquement) ne force pas le salarié à se ré-authentifier : Claude redemande une assertion à l'annuaire en silence, puis un nouveau jeton d'accès. C'est aussi ce qui rend la révocation crédible : couper à la source coupe partout.
Ce qui n'entre pas dans le cadre. Un serveur totalement sans authentification ne renvoie jamais de 401, donc il n'y a aucun moment où l'échange d'assertion peut avoir lieu : l'autorisation gérée ne s'y applique pas.
8D'où ça vient (et pourquoi ce n'est pas un gadget)
Ce n'est pas une fonctionnalité inventée dans son coin. C'est l'atterrissage dans Claude d'un standard ouvert construit depuis plus d'un an, sous le nom de Cross App Access (XAA) — une extension d'OAuth pensée pour sécuriser les connexions agent-vers-application.
| Quand | Quoi |
|---|---|
| Juin 2025 | Introduction de Cross App Access |
| Septembre 2025 | Adoption par le groupe de travail OAuth |
| Novembre 2025 | Intégration au protocole MCP sous le nom « Enterprise Managed Auth » |
| 18 juin 2026 | Bêta dans Claude : 7 connecteurs, Okta en fournisseur d'identité |
| ★ 24 août 2026 | Disponibilité générale : 10 connecteurs, Team & Enterprise |
Des entreprises l'ont déployé pendant la phase bêta — HubSpot, Ramp et Webflow ont été citées publiquement par Anthropic et Okta. Et l'argument officiel d'Anthropic tient en une ligne : c'est ce qui manquait à MCP pour passer à l'échelle dans une entreprise. La lecture est simple : le protocole savait déjà brancher des outils, il ne savait pas encore le faire à 500 personnes sans créer 500 décisions individuelles.
9Tester sur une équipe avant d'ouvrir à tous
La bonne pratique tient en une phrase : crée un rôle personnalisé, ne coche aucun rôle intégré. Le connecteur n'arrive alors que chez les personnes de ce rôle. Tu élargis ensuite, quand tu as des réponses au lieu des hypothèses.
| Semaine | Ce que tu fais | Ce que tu observes |
|---|---|---|
| 1 | Un rôle pilote, un seul connecteur, l'équipe la plus demandeuse | Est-ce que ça se branche vraiment tout seul au premier login ? |
| 2 | Tu ajoutes 2 connecteurs au même rôle | Est-ce que les scopes choisis suffisent aux usages réels ? |
| 3 | Tu testes un départ : désactivation d'un compte test dans l'annuaire | Est-ce que les accès tombent comme prévu ? |
| 4 | Tu ouvres aux rôles intégrés, connecteur par connecteur | Tu passes en comité avec une démo, pas avec un slide |
10Les 8 questions à préparer avant la réunion sécurité
Sors cette liste en réunion : elle change le statut de la discussion, parce qu'elle montre que tu as instruit le sujet côté accès, pas seulement côté usage.
1. Notre SSO est-il déjà branché sur l'organisation Claude, et à jour ?
2. Quels rôles et groupes existants portent la décision — et sont-ils fiables aujourd'hui ?
3. Quel connecteur ouvre-t-on en premier, et pour quelle équipe exactement ?
4. Quels scopes accorde-t-on, et lesquels refuse-t-on volontairement au premier tour ?
5. Veut-on interdire les comptes personnels sur ce connecteur, oui ou non ?
6. A-t-on testé une désactivation de bout en bout, avec un compte de test ?
7. Quelle durée de vie de jeton l'éditeur applique-t-il de son côté ?
8. Qui, chez nous, est propriétaire de ce réglage dans six mois ?
11Ce que ça ne fait pas
Autant être clair, parce que c'est là que les projets déraillent.
Ça ne range pas ta donnée. Brancher Notion sur Claude ne rend pas ton Notion lisible. Si ta base de connaissances est un cimetière, tu auras un cimetière accessible plus vite.
Ça ne définit pas tes cas d'usage. L'accès n'est pas l'adoption. Un connecteur disponible et jamais utilisé, c'est un projet qui a réglé le mauvais problème.
Ça ne remplace pas ta gouvernance. Ça l'applique. Si tes droits sont mal rangés dans l'annuaire, ils seront mal rangés dans Claude — mais plus vite, et sur plus d'outils.