Lundi soir, le compte Claude Devs a annoncé en quelques lignes la disponibilité générale de l’authentification gérée par l’entreprise pour les connecteurs MCP (Model Context Protocol, le protocole ouvert qui branche un modèle sur des outils et des données externes). Derrière la note de version, c’est l’endroit où se décide l’accès des agents aux outils de l’entreprise qui change d’adresse.
Dix éditeurs accompagnent l’annonce : Asana, Atlassian, Canva, Datadog, Figma, Granola, Linear, Notion, Slack et Supabase. Tous acceptent que l’accès à leurs données, depuis Claude, soit arbitré par l’annuaire d’identité du client plutôt que par chaque salarié dans son coin.
L’autorisation quitte le poste de travail pour l’annuaire
Jusqu’ici, l’autorisation d’un connecteur se négociait poste par poste. Chacun reliait son compte Notion, son Slack ou son Jira à l’assistant, avec ses propres droits, sans que personne à la direction technique ne sache exactement quel agent lisait quoi. Vu d’un responsable sécurité, cela ressemblait beaucoup à du shadow IT (des outils installés en dehors du contrôle de la direction informatique) repeint en productivité. La concurrence n’a pas tranché autrement : dans un espace ChatGPT Enterprise, l’administrateur choisit quelles applications sont activées, mais chaque salarié relie ensuite son propre compte, application par application.
Anthropic remonte l’arbitrage dans l’IdP (Identity Provider, l’annuaire d’entreprise qui gère déjà les comptes et l’authentification unique), à commencer par Okta. Concrètement, un administrateur Claude Team ou Enterprise accorde ou retire l’accès à Notion ou à Jira depuis l’annuaire, pour toutes les équipes d’un coup. La contrepartie se lit dans la même phrase : l’éditeur du modèle prend place dans la chaîne qui décide de l’accès aux outils métier.
Cette place vaut plus qu’une fonctionnalité d’administration. Elle transforme un assistant que l’on autorise en une couche que l’on configure une fois, pour toute l’entreprise.
Après les dix logos, le répertoire ouvert à tous les éditeurs
Le second volet de l’annonce est passé plus discrètement : les développeurs peuvent ajouter le même mécanisme d’authentification à leurs propres connecteurs MCP tiers, dans le répertoire Claude. Dix logos font une vitrine. Un mécanisme ouvert à tous les éditeurs fabrique une norme.
La mécanique est familière à quiconque a vu une plateforme s’installer. On commence par des partenaires de premier rang qui légitiment le format. On ouvre ensuite ce format à la longue traîne, qui n’a plus aucun intérêt à en inventer un autre. À l’arrivée, l’endroit où un éditeur SaaS (Software as a Service, les logiciels d’entreprise loués en ligne) doit se déclarer pour être atteignable par des agents devient un actif stratégique, et cet actif ne lui appartient pas.
Pour les dix signataires, l’arbitrage a été rationnel : leurs clients grands comptes réclamaient une administration centralisée, et refuser la porte d’entrée revenait à rendre son produit moins accessible aux agents que celui du concurrent d’à côté. Les décisions les plus lourdes se prennent souvent pour de bonnes raisons de court terme.
Changer de modèle coûte moins cher que changer de guichet
Le protocole lui-même n’enferme personne : MCP a été publié en ouvert, plusieurs plateformes d’agents s’en servent, et un connecteur écrit pour l’un peut vivre ailleurs. Le point d’appui se situe en amont du protocole.
Remplacer un modèle par un autre relève d’une ligne de configuration et d’une campagne d’évaluation. Défaire une chaîne d’autorisation validée par les équipes sécurité, la conformité et une dizaine d’éditeurs, puis la reconstruire sur une autre plateforme, se compte en trimestres et en comités. Anthropic vend des modèles dans un marché où les écarts de performance se resserrent et se renversent à chaque version. L’entreprise consolide donc la couche que personne ne rebranche pour trois points de benchmark.
Le choix du client visé se lit dans les conditions d’accès. Une fonction réservée aux plans Team et Enterprise, articulée à l’annuaire interne, ne cherche pas l’usage individuel : elle vise le contrat pluriannuel, signé par une direction des systèmes d’information.
La révocation, l’audit et le périmètre restent à éprouver
L’annonce publique reste brève et renvoie au billet de blog pour le détail technique. Avant de généraliser en interne, trois points se testent sur pièces plutôt qu’en réunion :
- la révocation : couper un accès dans l’annuaire doit réellement invalider les jetons déjà émis côté connecteur, et pas seulement bloquer la prochaine connexion ;
- la traçabilité : pouvoir répondre à la question « quel agent a lu quel document, et à quelle heure », et sortir cette réponse lors d’un contrôle ;
- le périmètre : la centralisation ne couvre que les espaces Team et Enterprise, alors que les connexions personnelles déjà en place dans les équipes continuent d’exister à côté.
Une administration centralisée réduit le nombre de décisions d’accès, elle n’en réduit pas la portée. Un jeton distribué à un agent ouvre un périmètre bien plus large qu’un salarié qui consulte trois tickets, et l’audit doit suivre à cette échelle.
Les éditeurs SaaS, eux, ont un calcul à faire : chaque annuaire d’agents qu’ils alimentent est une intégration à maintenir, et celui qui concentrera les autorisations de leurs grands comptes deviendra leur principal point de contact avec ces clients. Les dix premiers ont tranché lundi. Le suivant signera en sachant ce qu’il achète.
