AGENTUX

La sortie de la plateforme Buzz par Block permet de mettre en lumière une problématique agentique sur laquelle je bosse depuis pas mal de temps :

“quelle UX/UI pour des agents IA utilisés conjointement par une équipe, et pas forcément dev/tech ?”

Vivre dans le flux de travail, pas à côté

Mon parti pris depuis longtemps est que les agents doivent interagir au milieu du flux de travail, donc pas d’app dédiée qui nécessite une interface supplémentaire — du Slack, du Teams, du GChat, du mail, bref ce qui est déjà utilisé en entreprise pour communiquer.

Tout doit pouvoir se faire depuis ces interfaces : créer un nouvel agent spécialisé sur un sujet, faire du CRUD de documents et d’artefacts, paramétrer les utilisateurs, etc.

Exécuter des commandes en langage naturel est possible (“Tu vas créer un agent dédié au projet XXX pour le client YYY avec Thierry comme owner”). Mais il est plus intéressant de viser une plateforme qui permette la création de micro-applications riches, facilement utilisables. Les commandes en /slash c’est sympa, mais on a déjà perdu tous les utilisateurs non tech à ce stade.

Le workspace par projet

Un autre point complexe est la ségrégation des workspaces et la gestion des contextes / sessions.

Imaginons un cabinet d’avocats avec plusieurs spécialités, au hasard droit du travail et droit administratif — j’y connais rien et ce n’est pas le sujet. Ce cabinet est équipé de deux agents spécialisés sur chacun de ces types de droit, invocables à la volée pour chaque affaire : pour le licenciement de Dominique S., un agent de type droit du travail va être créé et dédié à cette affaire — documents, comptes-rendus, timeline.

Comme avec des êtres humains, on crée un workspace dédié, avec ses propres ressources et des collaborateurs dédiés. Ce workspace n’est pas une nouvelle application : c’est un canal, plus une base de connaissances liée à ce canal. On reste dans l’outil de communication existant, mais chaque affaire garde son contexte propre, isolé des autres.

DM : le cas facile

Parlons maintenant des interactions agents/humains. Dans l’idéal, comme pour tout collaborateur, l’agent peut être joint en DM et être ajouté à un canal dédié à chaque dossier : il doit être immergé là où se passent les échanges.

Pour les DM, pas de problème : l’utilisateur interagit directement avec l’agent. Reste la gestion des sessions et du contexte. Pour des raisons de métier, de coûts et de performance, il faut que l’utilisateur puisse facilement démarrer une nouvelle “conversation”, c’est-à-dire créer une nouvelle session de travail avec l’agent.

C’est par exemple complexe avec WhatsApp, faute de gestion de topic ou de thread, sauf à mettre en place des règles de création de nouvelle session programmatiquement — un /new par exemple, ce qui reste compliqué et peu utilisable pour la plupart des utilisateurs — ou en s’aidant d’un LLM pour détecter si le message nécessite une nouvelle session ou la poursuite de l’existante. Cette dernière approche fonctionne, mais elle ajoute une couche d’ambiguïté et de coût à chaque message.

C’est là que les messageries de type Slack sont performantes, avec la notion de thread : un thread = une session de travail, les contextes peuvent être maîtrisés et isolés correctement. Un avocat veut faire une recherche de jurisprudence ? Un thread. Préparer une plaidoirie à partir des pièces du dossier et de la mémoire de l’agent ? Un thread.

Le canal partagé : là où tout se complique

Là où ça se complique vraiment, c’est l’interaction de l’agent avec plusieurs utilisateurs dans un canal partagé.

Reprenons notre exemple : dans un canal dédié à l’affaire “Dominique S.”, il y a trois avocats, un juriste, un assistant, un stagiaire, et Bob, notre agent IA. Si l’agent répond à tout le monde dans le fil principal, c’est le chaos assuré : perte de contexte, spam, coûts qui explosent et quiproquos croisés — je n’utilise pas le mot “hallucination” par hasard : en agentique, une hallucination est le plus souvent le fruit d’une mauvaise ingénierie du contexte, pas d’un défaut intrinsèque du modèle.

Si quelqu’un pose une question en taggant l’agent @bob, le plus simple est de créer un thread : l’agent répond en ouvrant un thread avec son propre contexte. Mais que se passe-t-il si le tag référence des échanges précédents — “hey @bob, tu en penses quoi ?” Charge à l’implémentation de fournir le contexte nécessaire pour créer ce thread et cette session, la vraie difficulté étant de savoir quoi fournir pour bien contextualiser, sans noyer l’agent ni faire exploser les coûts en rejouant tout l’historique à chaque fois.

Qui a le droit de savoir quoi

Autre difficulté, plus structurante encore : imaginons que c’est Coralie, l’avocate en chef, qui interpelle l’agent, et Thierry le stagiaire qui intervient plus tard dans le même thread. Si l’agent est implémenté au plus simple, Coralie = Thierry = “user”, et l’agent traite les deux de la même façon.

Mais est-ce que Thierry a les mêmes droits que Coralie ? Dans un DM, la réponse est simple : Thierry ne peut pas, par exemple, contacter la partie adverse ou son agent. La règle est binaire et facile à poser en amont.

Dans un canal partagé, ça se complique sur deux axes différents :

• Un axe vertical, hiérarchique : le stagiaire n’a pas les mêmes habilitations que l’avocate en chef, et l’agent devrait pouvoir adapter son registre, ce qu’il révèle, ou ce qu’il exécute, selon qui lui parle.
• Un axe horizontal, plus rarement évoqué : à mesure que les agents seront amenés à interagir entre eux, potentiellement avec l’agent d’une autre organisation (l’avocat de la partie adverse, par exemple), la question n’est plus seulement “qui dans mon équipe a le droit de savoir quoi”, mais aussi “quel agent externe a le droit de parler à quel agent, et sur quoi”. C’est un chantier de contrôle d’accès qui dépasse largement le prompt engineering : il touche à l’authentification, aux ACL, et à un référentiel de rôles qui doit être mappé aux identités de la plateforme de communication utilisée.

L’expérience commence à être vraiment intéressante quand on arrive à transmettre à l’agent qu’il est en conversation avec N personnes et leur rôle respectif : il peut alors adapter son comportement, moduler ses droits d’action, refuser certaines requêtes selon l’interlocuteur. Mais cette complexité est loin d’être négligeable, et elle est d’autant plus difficile qu’elle reste fortement dépendante de la plateforme de communication utilisée — Slack, Teams et Gmail n’exposent pas les mêmes primitives de rôles ni les mêmes garanties d’identité.

En résumé

Faire parler un agent dans Slack, c’est facile. Faire en sorte que les utlisateurs puissent interagir avec lui comme un collègue en prenant en compte leurs droits, c’est un peu plus complexe