Pourquoi les agents IA multi-utilisateurs se compliquent très vite

La plupart des démos d’agents IA paraissent magiques jusqu’au moment où tu essaies de les utiliser avec une vraie équipe. C’est là que la jolie petite démo se transforme en vrai problème produit. Dès que plus d’une personne peut parler au même agent, tu ne construis plus un jouet. Tu conçois un système d’accès.

C’est la partie que beaucoup de gens sautent. Ils sont obsédés par la qualité du modèle, la latence des réponses et l’utilisation des outils. Pendant ce temps, la vraie question est à la fois beaucoup plus simple et beaucoup plus difficile : qui a le droit de voir quoi, de déclencher quoi et d’agir sur quoi ?

Si ton agent IA peut accéder aux tarifs, aux contrats, à l’historique client, aux documents internes, aux notes de réunion ou aux données financières, tu ne peux pas simplement le lâcher dans un environnement partagé en espérant que le prompt se tienne bien. Ce n’est pas de l’architecture. C’est de la pensée magique.

Dès qu’un agent devient multi-utilisateurs, le problème change

Un assistant IA personnel, c’est une chose. Un agent IA au service d’une équipe, c’en est une autre. Avec un seul utilisateur, le modèle de confiance est simple. L’agent travaille pour une personne, utilise ses outils et opère dans le périmètre de ses permissions. C’est gérable.

En entreprise, dès que plusieurs salariés, prestataires ou clients interagissent avec le même agent, tout devient plus compliqué. Les commerciaux ne doivent pas voir les mêmes données que la finance. Les clients ne doivent pas avoir de visibilité sur ta logique de tarification interne. Un account manager ne doit pas pouvoir consulter les conversations d’un autre simplement parce que le modèle a accès au même backend.

C’est exactement pour ça que les agents multi-utilisateurs se compliquent très vite. Le défi n’est pas seulement ce à quoi le modèle peut répondre. Le défi, c’est ce que le système devrait lui permettre de savoir, tout simplement.

Il n’y a vraiment que deux façons de construire ça

La première, c’est d’appliquer les restrictions dans le prompt. Tu dis au modèle de ne pas révéler certaines données. Tu lui dis d’ignorer certaines sources sensibles pour certains utilisateurs. Tu ajoutes de petites règles du genre ne mentionne pas les tarifs internes, n’expose pas les informations privées des clients, ne récupère pas de documents confidentiels sauf si l’utilisateur y est autorisé.

Cette approche est populaire parce qu’elle est rapide. Elle donne aussi l’impression d’être maligne. Malheureusement, ce n’est pas une frontière de sécurité.

La seconde, c’est d’intégrer la restriction dans la conception même de l’agent. Dans ce modèle, le système décide quelles données, quels outils et quelles actions sont disponibles avant même que le modèle commence à raisonner. On ne demande pas poliment au modèle d’éviter les zones interdites. Il n’a tout simplement pas les clés pour y entrer.

Cette distinction change tout. L’une est une suggestion écrite en langage naturel. L’autre est une vraie frontière.

Pourquoi la sécurité dans le prompt casse

Les grands modèles de langage sont extraordinairement utiles, mais ce ne sont pas des systèmes de permissions. Ils ne séparent pas naturellement les instructions fiables des instructions non fiables avec la rigueur qu’exige une vraie architecture de sécurité. Si le mauvais contenu entre dans la fenêtre de contexte, ou si le mauvais utilisateur formule sa demande de la bonne façon, le modèle peut être manipulé pour révéler, récupérer ou faire des choses que tu n’avais jamais prévues.

On appelle ça prompt injection, détournement de prompt ou jailbreak, mais l’étiquette importe presque peu. Le vrai problème, c’est qu’un prompt reste du texte. Le texte est malléable. Il peut être contourné, recadré, empoisonné ou embrouillé. Si toute ta stratégie de contrôle d’accès repose sur le fait que du texte gagne un débat à l’intérieur d’un modèle, tu finiras par perdre ce débat.

C’est encore plus vrai quand des outils entrent en jeu. La partie dangereuse d’un agent, c’est rarement la phrase qu’il écrit. C’est ce qu’il peut faire. S’il a un large accès à ton CRM, tes fichiers, tes agendas, tes grilles tarifaires ou tes systèmes internes, un échec n’est plus une réponse maladroite. Ça devient une fuite de données, une violation de politique interne ou une catastrophe pour la confiance de tes clients.

À quoi ressemble vraiment un contrôle intégré à l’architecture

Un vrai agent multi-utilisateurs a besoin d’accès cloisonnés dans le système lui-même. Autrement dit, chaque session utilisateur doit hériter de la bonne identité, des bonnes permissions et des bonnes frontières de données. Le modèle ne doit pouvoir appeler que les outils disponibles pour cette personne précise, dans ce contexte précis, pour ce rôle précis.

En pratique, ça veut dire concevoir selon le principe du moindre privilège dès le premier jour. Un espace de travail ouvert aux clients ne doit pas avoir accès à la logique de tarification interne. Un agent de support ne doit pas hériter de la visibilité d’un fondateur. Un prestataire ne doit pas obtenir de larges droits de récupération simplement parce qu’il est dans le même canal Slack que le fondateur. Chaque chemin d’accès doit être délibéré, cloisonné et applicable.

Ça veut aussi dire isolation. Les équipes, les clients et les contextes ne doivent pas déborder les uns sur les autres. Les systèmes d’agents multi-utilisateurs les plus propres ne sont pas ceux qui ont les prompts les plus longs. Ce sont ceux qui ont les frontières les plus claires.

Et puis il y a la traçabilité. Si un agent peut déclencher des workflows, récupérer des données ou rédiger des contenus sensibles, tu dois savoir qui a demandé quoi, à quoi le système a accédé et pourquoi une action donnée a eu lieu. Sans ça, tu n’as pas de confiance opérationnelle. Tu as des impressions.

C’est là que la plupart des plateformes d’agents s’effondrent sans bruit

Beaucoup de frameworks d’agents ont en réalité été construits avec un modèle de confiance d’assistant personnel. Ça va très bien si l’agent sert une seule personne dans un seul environnement. Ça ne va plus du tout quand tu essaies d’étendre ces mêmes fondations à une équipe, et encore moins à des clients.

C’est le cœur du problème. OpenClaw et les approches similaires peuvent être impressionnants pour un usage individuel. Mais quand tu essaies de les faire fonctionner comme un système multi-utilisateurs sécurisé, tu commences à te battre contre l’architecture. Tu finis par empiler des prompts sur des prompts, colmater des trous et espérer que personne ne pose la seule question qui fait tomber tout l’édifice.

Les fondateurs ressentent vite cette douleur, parce que les PME n’ont pas de temps pour un théâtre de sécurité élégant. Si ton client peut découvrir par accident que quelqu’un d’autre a obtenu un meilleur tarif, ou si ton équipe peut consulter des données auxquelles elle n’était jamais censée accéder, le problème n’est plus théorique. Il est commercial.

Pourquoi on a construit Notis autrement

Chez Notis, on a traité ce sujet comme un problème de conception produit dès le départ. Pas comme un exercice de rédaction de prompts. Pas comme un contournement. Un vrai agent pour une vraie entreprise doit comprendre le contexte, oui, mais il doit aussi respecter des frontières. Ça veut dire cloisonner ce à quoi chaque utilisateur peut accéder, ce que chaque automatisation peut déclencher et ce que chaque workflow peut voir.

L’objectif n’est pas de rendre le modèle plus obéissant. L’objectif est de rendre le système plus digne de confiance. Quand le contrôle d’accès vit dans l’architecture, le modèle peut être utile sans devenir imprudent. C’est le standard que les entreprises devraient exiger.

C’est aussi pour ça que je pense que le marché sous-estime encore ce que signifie déployer des agents sérieusement. Tout le monde veut des workflows autonomes. Très peu de gens veulent parler de frontières de permissions, de niveaux de validation et de pistes d’audit. Ce sont pourtant exactement ces éléments qui rendent l’autonomie viable en dehors d’une démo.

Ce que les fondateurs de PME devraient demander avant d’adopter une plateforme d’agents

Si tu évalues un agent IA pour ton équipe, ne t’arrête pas à la démo. Demande ce qui se passe quand plusieurs utilisateurs avec des rôles différents interagissent avec le système. Demande si l’accès aux outils est cloisonné par utilisateur ou partagé en coulisses. Demande si les données clients sont isolées. Demande si les actions sont traçables. Demande s’il existe des validations pour les workflows à haut risque.

Si la réponse se résume à ne t’inquiète pas, le prompt s’en occupe, continue de creuser.

Parce que dans le monde réel, la qualité d’un produit d’IA ne se mesure pas à quel point il est impressionnant quand tout se passe bien. Elle se mesure à la sécurité de son comportement quand quelqu’un demande la mauvaise chose, a les mauvaises permissions ou essaie de le pousser au-delà de ses limites prévues.

L’architecture d’abord, sinon les regrets plus tard

Les agents IA multi-utilisateurs sont puissants. Ils peuvent tout à fait transformer le fonctionnement des PME. Mais dès que tu dépasses le cadre d’un seul utilisateur de confiance, tu dois arrêter de penser comme un prompt engineer et commencer à penser comme un concepteur de systèmes.

C’est la vraie ligne de partage de ce marché. Certains produits traitent le contrôle d’accès comme une phrase dans le prompt. D’autres le traitent comme un élément central de l’architecture. Une seule de ces approches survit au contact d’une vraie entreprise.

C’est pour ça que je pense que la conception d’agents multi-utilisateurs commence par des frontières, pas par de la bravade. Et c’est pour ça qu’on a construit Notis comme ça dès le premier jour.