Anthropic vient d’inviter Claude dans Slack. On retient le geste spectaculaire : taguez @Claude dans un canal, et l’IA devient un coéquipier qui prend des tâches en charge pendant que vous faites autre chose. Multijoueur, asynchrone, proactif. La démo est belle.
Sauf que le multijoueur n’est que la partie visible. Ce que Claude Tag installe en coulisses, c’est un changement de modèle d’accès dont personne ne parle, et qui décidera de la suite bien plus que la fonctionnalité de tag.
Ce que tout le monde a retenu
Le récit est simple à raconter. Claude rejoint un canal Slack, n’importe qui peut le mentionner, lui déléguer une analyse de métriques, un ticket de support ou la traque d’un bug. Il garde le contexte du canal, planifie des tâches pour plus tard, et peut même prendre l’initiative de relancer un fil resté sans réponse si le mode « ambiant » est activé.
Anthropic avance un chiffre qui frappe : 65 % du code de son équipe produit est désormais écrit par sa version interne de Claude Tag, y compris l’essentiel du code de Claude Tag lui-même. C’est l’argument-massue, et il a tourné en boucle dans les reprises. L’outil passe en bêta pour les offres Enterprise et Team.
Tout cela est exact. Mais s’arrêter là, c’est confondre l’interface avec le moteur.
Pourquoi « agir comme l’utilisateur » ne tient plus
Dans une IA personnelle, le modèle d’accès est trivial : vous connectez votre Google Drive, votre GitHub, votre agenda, et l’assistant agit avec vos droits, en votre nom. Une seule personne, une seule identité, une seule responsabilité.
Ce modèle s’effondre dès qu’on passe au collectif. Anthropic le dit noir sur blanc dans sa documentation : quand trois ingénieurs et un chef de produit débuggent ensemble dans un canal, les droits de qui s’appliquent ? Aucun choix d’individu n’est jamais le bon. Et le problème s’aggrave avec l’autonomie : selon Anthropic, la durée d’une tâche qu’un agent mène seul de façon fiable double environ tous les quatre mois. L’agent programme ses propres tâches, répond à des événements des heures après que le demandeur s’est déconnecté. Faire agir l’IA « comme l’utilisateur » n’a plus de sens quand l’utilisateur est parti depuis longtemps.
La réponse d’Anthropic porte un nom : agent identity, l’identité d’agent. Claude n’emprunte plus les droits de personne. Il a ses propres comptes.
Claude agit comme lui-même
Concrètement, Claude poste dans Slack en tant qu’application Claude, ouvre ses pull requests via la Claude GitHub App, interroge l’entrepôt de données sous un compte de service créé par un administrateur. Pas d’identifiants personnels en jeu. La conséquence est plus profonde qu’elle n’en a l’air : un canal partagé ne peut plus devenir une porte dérobée vers les documents privés de quelqu’un. L’IA ne voit que ce qu’on lui a explicitement confié, pas ce que voit la personne qui la mentionne.
Les permissions migrent ainsi du « par utilisateur » au « par canal ». L’administrateur définit une identité de base au niveau de l’espace de travail, et chaque canal en hérite. Puis il affine : accès GitHub et entrepôt de données pour le canal d’ingénierie, connecteur CRM confiné à un seul canal privé, droits en lecture seule ici, en écriture là. À cela s’ajoutent les dépôts accessibles, les connecteurs et leurs clés d’API, les skills et plugins chargés à la demande, et des instructions permanentes propres à chaque canal.
Le résultat ? Le périmètre d’action de l’IA cesse d’être une propriété de l’humain qui parle pour devenir une propriété du lieu où elle parle.
Le chantier laissé dans l’ombre
Voilà où le consensus passe à côté. La fonctionnalité « tag » est confortable, mais reproductible : c’est de l’interface. Le modèle d’identité d’agent, lui, est une décision d’architecture qui engage la sécurité de toute l’organisation. Mal calibré, un canal trop permissif donne à une IA proactive des droits d’écriture sur un dépôt critique ou un accès en écriture à l’entrepôt de données, sans qu’aucun humain n’ait validé l’action en temps réel.
Le gros du déploiement ne portera pas sur la façon de taguer Claude, mais sur la modélisation, canal par canal, de ce qu’une IA autonome a le droit de lire et d’écrire, et sur la traçabilité de ses actions sous sa propre identité plutôt que noyées dans l’historique d’un employé. La question de sécurité classique « qui a accès à quoi » devient « qu’a le droit de faire cet agent, et où ». C’est un sujet de gouvernance, pas d’ergonomie.
L’IA d’équipe se jouera sur les droits
Claude Tag mérite l’attention, mais pas pour la raison qu’on lui prête. Le fait qu’une IA rejoigne une conversation d’équipe n’est qu’une commodité. Qu’elle y arrive avec sa propre identité, ses propres clés et un périmètre défini par l’administrateur plutôt que par l’utilisateur du moment : voilà le précédent qui comptera.
Anthropic n’est d’ailleurs ni la première ni la dernière à devoir trancher cette question : Microsoft a déjà doté ses agents Copilot d’une identité propre, gouvernée comme celle d’un employé, avec son Microsoft Entra Agent ID. Dès lors que des agents agissent seuls sur des heures ou des jours, savoir qui ils sont aux yeux de vos systèmes pèsera davantage que la manière dont on les appelle. La fonctionnalité multijoueur fera la une ; le modèle de permissions fera la différence.
