Quand votre agent IA rejoint l'équipe

De l'apprentissage au contrôle d'accès

Dans mon article précédent, j'ai décrit la construction d'un agent IA qui apprend entre les sessions. Un agent doté d'une mémoire structurée, d'une boucle d'autocorrection et d'un système d'accumulation d'expérience d'une exécution à l'autre.

Dès que d'autres personnes ont eu besoin d'y accéder, le problème a complètement changé. Il ne s'agissait plus de savoir si l'agent pouvait apprendre. Il s'agissait de savoir qui avait le droit de lui enseigner.

Que se passe-t-il quand votre équipe accède à un agent IA

La plupart des articles sur les agents IA se concentrent sur ce que l'agent peut faire. Très peu parlent de ce qui se passe quand quelqu'un d'autre que son créateur commence à l'utiliser.

J'ai construit un bot Slack. L'idée était simple : donner à l'équipe un moyen d'interagir directement avec l'agent — poser des questions, demander des analyses, obtenir des rapports. Pas de terminal. Pas de code. Juste Slack.

Ça a fonctionné immédiatement. Et c'est là que le vrai problème est apparu.

Le chat libre avec un agent IA est une interface puissante. C'est aussi un risque. Si n'importe qui dans l'équipe peut écrire n'importe quoi à l'agent, n'importe qui peut accidentellement écraser sa mémoire, modifier son comportement ou déclencher des actions non prévues. L'agent ne juge pas l'autorité. Il traite les entrées.

La question n'était pas de savoir si l'équipe devait avoir accès. La question était : quel type d'accès ?

Contrôle d'accès basé sur les rôles pour les agents IA

J'ai fini par mettre en place un système de rôles. Trois niveaux : administrateur, analyste, observateur.

L'observateur peut lire les rapports et voir ce que l'agent produit. Rien de plus. Pas de commandes, pas de chat, aucune influence sur le comportement.

L'analyste peut faire davantage. Il peut poser des questions. Il peut exécuter des commandes prédéfinies. Et — c'est le point important — il peut écrire dans la mémoire de l'agent. Mais uniquement via une commande explicite, pas par une conversation libre. Si un analyste tape une instruction de mémorisation dans le bon format, l'agent l'enregistre. S'il essaie de l'écrire comme un message informel, le système l'ignore.

L'administrateur a un accès illimité. Chat libre, commandes directes, écritures en mémoire, modifications de configuration.

Cela ressemble à un modèle de permissions classique. Mais la distinction qui compte n'est pas qui peut lire ou écrire. C'est qui peut enseigner. Parce que chaque entrée en mémoire change ce que l'agent sait. Et ce que l'agent sait façonne chaque production future.

Pourquoi la mémoire d'un agent IA devient une base de connaissances partagée

C'est quelque chose que je n'ai pleinement compris qu'en le voyant en pratique.

Dans l'article précédent, j'ai décrit la couche de mémoire structurée — un fichier que l'agent lit avant chaque exécution, contenant les leçons des sessions passées. Ce que je n'avais pas dit, c'est ce qui se passe quand cette mémoire devient partagée.

Dès que plusieurs personnes contribuent à la mémoire de l'agent, il cesse d'être un outil personnel. Il devient une base de connaissances partagée. Chaque entrée affecte chaque session future — pas seulement pour la personne qui l'a écrite, mais pour tous ceux qui interagissent avec l'agent.

Un accès non contrôlé à cette mémoire est un vrai risque. Non pas parce que les gens ont de mauvaises intentions. Mais parce que l'agent ne fait pas la différence entre un insight méthodologique mûrement réfléchi et une remarque désinvolte tapée sans réfléchir. Il traite les deux comme des vérités équivalentes.

L'accès à la mémoire uniquement par commande pour les analystes était le compromis. On peut contribuer. Mais on le fait délibérément, dans un format structuré, et c'est consigné.

Que se passe-t-il quand l'agent se trompe de méthodologie

Celle-là, je ne l'avais pas vue venir.