Un agent IA sur Teams ou sur Slack : ce qui change

Vous ne choisissez pas, et c’est la première chose à dire. La messagerie est déjà installée, on n’en change pas pour un agent, et la vraie question est de savoir si l’agent que vous évaluez existe sur la vôtre. Beaucoup n’existent que sur Slack.

Ce décalage mérite d’être regardé en face, parce qu’il n’est pas près de se refermer. Teams pèse environ 37 % du marché de la messagerie d’entreprise contre 13 % à Slack, avec de l’ordre de 320 millions d’utilisateurs mensuels contre 79 millions d’utilisateurs quotidiens, et il domine dans les grandes structures et les secteurs régulés. Slack domine ailleurs, et notamment chez les entreprises technologiques de moins de cinq cents personnes, où il approche les 52 %.

Pourquoi l’outillage sort là où il n’y a pas le marché

Parce que les entreprises qui construisent ces produits utilisent Slack, et qu’on construit d’abord pour la pièce dans laquelle on se tient.

L’exemple le plus net de 2026 est l’arrivée de Claude Tag, un agent installé comme membre d’un canal, disponible sur Slack uniquement au lancement. Anthropic annonce vouloir l’étendre, et il n’y a aucune raison d’en douter, mais entre l’annonce et la disponibilité une entreprise française équipée en Microsoft 365 attend. Le même schéma se répète chez la plupart des éditeurs d’agents : Slack d’abord, Teams quand le marché le réclame assez fort.

Il y a une raison technique honnête à cela, et elle n’est pas anecdotique. L’API de Slack est plus simple, mieux documentée, et surtout elle reflète assez fidèlement ce que l’on peut faire dans l’interface. Du côté de Microsoft, on compose avec plusieurs kits de développement, un modèle de permissions à trois classes et une distinction entre ce que voit un bot et ce que voit un annuaire. Le coût de construction n’est pas le même, et il se paie en semaines.

La conséquence pour un acheteur est simple à formuler. La disponibilité sur votre surface est une question d’évaluation à part entière, à poser avant les fonctionnalités, parce qu’un produit excellent sur une messagerie que vous n’avez pas vaut exactement zéro.

Ce qu’un bot ne peut pas faire sur Teams

Trois limites, relevées en août 2026 en construisant, et ce sont des limites de conception plutôt que des manques que quelqu’un comblera bientôt.

Il ne peut pas réagir à un message. L’ajout d’une réaction par un bot n’existe pas dans les opérations disponibles, et l’appel équivalent côté annuaire n’accepte pas les permissions applicatives, qui sont précisément celles que détient un bot. La réaction n’existe qu’en entrée, c’est-à-dire que l’agent voit qu’on a réagi à ses messages sans pouvoir répondre de la même façon. Ce n’est pas cosmétique : l’accusé de réception discret est le geste le moins coûteux qu’un collègue puisse faire, et il faut le remplacer par un message, donc par du bruit.

Il ne peut pas lire une adresse e-mail sur la liste des membres d’une conversation. La liste paginée des membres ne la renvoie pas à un bot. L’annuaire, lui, la renvoie. Vous avez donc deux sources d’information sur les mêmes personnes, dont une seule sait comment leur écrire, et il faut décider laquelle fait foi. Nous avons tranché en faisant que la recherche de personne prenne un nom plutôt qu’une adresse.

Il ne peut pas rejoindre un canal de lui-même. Il faut l’y installer, ce qui suppose des droits au niveau du catalogue d’applications du locataire. C’est aussi vrai chez Slack aujourd’hui, et c’est une bonne chose dans les deux cas : quelqu’un invite l’agent, toujours, et personne ne découvre un lundi qu’il écoutait depuis trois semaines.

Ce qu’un bot ne peut pas faire sur Slack

Il serait malhonnête de présenter Teams comme la surface contrainte et Slack comme la surface libre, parce que la limite la plus gênante que nous ayons rencontrée est du côté de Slack.

Un bot n’y a aucune recherche. La recherche de messages exige un jeton d’utilisateur, qu’un bot n’a pas. Une question aussi banale que « qu’est-ce qui s’est dit sur ce client le mois dernier » ne se traite donc pas par une recherche mais par une boucle sur les canaux, un par un.

Et cette boucle rencontre un plafond. Pour une application distribuée en dehors de la place de marché, le débit disponible sur ces lectures tombe à une requête par minute et quinze objets par page. Faites le calcul sur un espace de travail de quarante canaux avec de l’historique : la question n’est pas lente, elle est impossible, et aucune optimisation ne la rattrape.

C’est le genre de contrainte qui ne se voit dans aucune démonstration, puisqu’une démonstration se fait sur un espace de travail neuf avec trois canaux. Elle décide pourtant de ce que l’agent peut être, et elle nous a coûté une hypothèse de conception qu’il a fallu abandonner.

Ce que la parité coûte réellement

Nous avons fait le choix que les deux surfaces offrent les mêmes verbes, et je peux dire ce que ça représente, parce que nous venons de le faire.

Ce n’est pas un renderer à écrire. C’est un consentement de fichier à implémenter là où l’autre surface se contente d’un envoi, une pagination de membres qui ne renvoie pas les mêmes champs, un partage de document qui passe par un chemin différent, et une matrice de permissions à documenter ligne par ligne pour que personne ne construise ensuite contre une supposition. La partie visible par l’utilisateur, qui est de recevoir le même livrable des deux côtés, représente une fraction du travail.

La leçon générale vaut au-delà de notre cas, et elle contredit une intuition répandue. On imagine volontiers que ces plateformes sont la même pièce repeinte, et qu’un adaptateur suffit. Elles sont deux modèles différents de ce qu’un programme a le droit de faire dans une conversation entre humains, et chacune interdit quelque chose que l’autre autorise. La parité est donc une décision produit qu’il faut vouloir, pas une case à cocher dans une feuille de route.

Et si vous avez les deux ?

C’est plus fréquent qu’on ne le dit, et presque personne ne l’annonce en réunion. La technique est sur Slack, le reste de l’entreprise sur Teams, ou bien une acquisition a laissé deux messageries qui coexistent depuis trois ans sans que la fusion n’arrive jamais tout à fait.

La tentation est d’installer deux agents, un par surface, et c’est l’erreur. Vous obtenez deux mémoires qui divergent sur le même client, deux jeux de préférences, et une même personne à qui il faut réexpliquer les choses selon la pièce où elle se trouve. La règle que nous appliquons tranche ce cas sans hésiter : un agent qui détient du contexte sur vous doit être unique, un agent qui détient une expertise peut être appelé autant qu’on veut. Ici c’est le premier cas, et la surface n’est qu’une porte d’entrée.

Ce qu’il faut vérifier auprès de l’éditeur est donc précis, et ce n’est pas la disponibilité sur les deux. C’est de savoir si les deux portes mènent au même agent. Une conversation commencée dans Teams le mardi doit être connue de celle qui reprend dans Slack le jeudi, sans quoi vous avez acheté deux agents qui ne se parlent pas en croyant en acheter un.

La question annexe, celle des droits, se règle au même endroit. Une personne qui n’a pas accès à un dossier ne doit pas y accéder davantage en changeant de messagerie, ce qui paraît évident et ne l’est pas dès que les deux surfaces ont chacune leur propre notion d’appartenance à un canal.

Là où Teams a raison contre Slack

Une chose mérite d’être portée au crédit de Microsoft, et elle concerne exactement le sujet qui nous occupe le plus.

Le modèle de permissions distingue trois classes. Celles qu’un propriétaire de conversation consent à l’installation et qui ne valent que pour cette conversation. Celles qu’un administrateur consent une fois pour toute l’organisation. Et une troisième, plus rare, où le consentement de la portée n’accorde rien du tout : l’accès n’apparaît qu’après un octroi explicite, objet par objet, et disparaît quand on le retire.

Cette troisième classe est le moindre privilège fait correctement par la plateforme plutôt que bricolé par l’application. C’est précisément ce que nous réclamons quand nous écrivons qu’un agent doit agir avec les droits du demandeur et qu’une limite ne tient que si elle est inscrite dans le produit. Voir une plateforme l’offrir nativement est plus utile que n’importe quelle politique interne.

Ce qu’il faut demander avant de signer

Quatre questions, dans cet ordre, et la première élimine beaucoup de candidats.

Sur quelle surface le produit existe-t-il aujourd’hui, en production, chez des clients qui ne sont pas des références de lancement. Une feuille de route n’est pas une disponibilité, et « Teams arrive au trimestre prochain » est une phrase dont la valeur se mesure à l’historique de celui qui la prononce.

Les deux surfaces offrent-elles les mêmes verbes, et si non, lesquels manquent. Demandez la liste plutôt qu’une réponse rassurante, parce que la réponse est presque toujours oui et la liste presque jamais vide.

Que se passe-t-il quand l’agent ne peut pas faire quelque chose sur votre surface. Le bon comportement est de le dire ; le mauvais est de faire semblant, ce qui est aussi la marque d’un agent qui ne sait pas refuser.

Et enfin, faut-il changer quoi que ce soit à votre messagerie pour l’installer. La réponse doit être non, comme elle doit être non pour votre ATS, et pour la même raison : un agent qui exige une migration n’est pas un agent, c’est un projet.