Mémoire d'équipe et RAG : brancher une collègue sans tout lui ouvrir

Dans une petite entreprise, la mémoire est au mauvais endroit. Elle est dans la tête du dirigeant et dans des dossiers qu'il est seul à savoir retrouver. Une collègue arrive sur un sujet et a besoin de savoir ce qui a été décidé avec tel client ou pourquoi telle règle existe. Elle pose la question au dirigeant, qui répond entre deux réunions, ou elle cherche dans un disque partagé et reconstitue à moitié. Chaque question coûte du temps à deux personnes, et la réponse n'est écrite nulle part.

Chez nous, cette mémoire existe sous forme de base de connaissance interrogeable. Nos agents la lisent avant d'agir, nous l'avons déjà raconté. Mais jusqu'à cette quinzaine, elle n'était pas ouverte à l'équipe. Nous avons branché une collègue, depuis l'assistant d'intelligence artificielle qu'elle utilise déjà, et le chantier a moins porté sur la technique que sur une question de direction : ce qu'elle doit voir et ce qu'elle ne doit pas voir.

La mémoire de l'entreprise se partage par périmètre, pas par mot de passe

Avant de brancher quelqu'un sur la mémoire de l'entreprise, on décide ce qu'il verra, et cette décision appartient à la direction, pas au réglage technique. Notre base complète mêle tout ce que l'entreprise écrit : les pages de méthode et de clients, mais aussi des notes personnelles, des mails, les journaux de travail des agents, la comptabilité et l'activité d'une structure partenaire. Une collègue n'a besoin d'aucun de ces cinq blocs pour son travail.

Nous avons donc construit une source distincte, un miroir filtré de la base. Il ne reprend que ce qui est enregistré dans l'historique de la base, pas les fichiers en cours d'édition. Il retire les dossiers de ces cinq blocs. Sur une base 100 de pages dans la base complète, la source équipe en garde 32. Les deux tiers retirés sont, pour l'essentiel, des choses qui ne la concernent pas, et qui, mêlées à ce qui la concerne, rendraient chaque réponse plus bruyante.

Le filtre vit dans le code qui construit le miroir, pas dans une consigne donnée à l'assistant. Une consigne s'oublie, un filtre dans le code s'exécute à chaque fois.

La lecture d'abord, depuis l'assistant qu'elle utilise déjà

Nous n'avons ni souscrit une offre d'équipe ni installé un nouvel outil : la collègue garde son compte individuel, et son assistant se branche sur la source équipe par un connecteur personnalisé. Elle pose ses questions dans la fenêtre qu'elle utilise déjà.

Le branchement repose sur trois choix. D'abord une identification par un protocole standard, avec un client public sans secret à protéger, qui n'obtient qu'un droit de lecture et seulement sur la source équipe. Ensuite une approbation humaine de chaque connexion : la demande produit un lien d'approbation à usage unique, valable quelques minutes, que le propriétaire de la base doit ouvrir lui-même. Enfin, une fois la connexion faite, la session du propriétaire est refermée sur le serveur, et seuls les jetons de la collègue restent valides. Elle est connectée, le propriétaire ne l'est plus à travers elle.

Le 21 octobre, le test a été concluant : une question posée depuis son assistant, une réponse qui cite la page de la base dont elle vient. C'est exactement ce que nous demandons à une base de connaissance interrogeable : répondre avec la source, ou ne pas répondre.

Un point doit être dit clairement, parce qu'il pèse dans la décision. L'assistant qu'elle utilise est un service fermé, celui d'un éditeur américain. C'est le principe du connecteur : à chaque question, les passages de la source équipe qui servent à répondre lui sont transmis. Nous l'assumons pour ce périmètre, précisément parce que le tri a été fait avant : ce qui a été retiré du miroir ne lui parvient jamais, quelle que soit la question. Si la source avait contenu la comptabilité ou les mails, la réponse aurait été différente, et le branchement n'aurait pas eu lieu sous cette forme. La ligne que nous tenons sur les données est une ligne de risque, vérifiable, qui dépend de ce qui circule. Demandez par écrit où sont vos données et où tourne le modèle, et faites le tri avant de brancher.

Trois pièges au premier branchement, trente secondes une fois le chemin trouvé

Le premier branchement a buté sur trois pièges qui n'avaient rien à voir avec la base de connaissance, et c'est le retour utilisateur le plus utile de la quinzaine. Un lien d'essai a montré que le mécanisme lui-même était sain. Ce qui a coincé, c'est le chemin.

Premier piège, le menu. L'assistant propose un annuaire de connecteurs tout faits, avec un bouton d'installation. Le nôtre n'y est pas, il se déclare ailleurs, dans un réglage de connecteur personnalisé. Une personne qui suit son intuition clique au mauvais endroit et ne trouve rien.

Deuxième piège, le réglage d'identification. Une seule configuration fonctionne avec notre serveur, celle où l'on déclare son propre client et où l'on laisse le secret vide, parce que le serveur refuse qu'un client s'enregistre tout seul. Rien dans l'interface ne pousse vers cette configuration plutôt qu'une autre.

Troisième piège, et le plus instructif. Le lien d'approbation ne sert qu'une fois. Nous l'avons envoyé à la collègue par la messagerie de l'entreprise. La messagerie, pour afficher un aperçu du lien, l'a ouvert avant elle. Le lien était consommé quand elle a cliqué. Même placé dans un bloc de code, l'aperçu le mange. La machine a fait ce qu'elle devait, et c'est précisément pour cela qu'elle nous a bloqués.

La solution retenue tient en une phrase : tout faire sur un même poste, dans une même fenêtre de navigation privée, la collègue connectée à son compte, le propriétaire qui approuve dans la même fenêtre. Environ trente secondes. La leçon est plus large que ce chantier. Le mode d'emploi s'écrit après le premier vrai utilisateur, pas avant. Le nôtre est parti une fois le chemin connu.

Un dernier enseignement est arrivé le lendemain. Quand nous avons voulu ajouter le droit d'écriture, l'assistant de la collègue lui a annoncé qu'elle pouvait écrire dans la base, sous son préfixe. Le serveur avait bien accordé ce droit, mais le jeton qu'elle utilisait ne portait que la lecture : le connecteur avait redemandé le droit mémorisé lors de la première connexion, et seule une recréation complète permettra d'en changer. L'assistant lisait un profil et le racontait, le droit vivait dans le jeton. Ce que l'assistant dit de ses propres droits n'est pas une preuve. Seul le droit porté par le jeton fait foi, et le serveur le vérifie à chaque écriture.

L'écriture vient ensuite, par un guichet borné

Le volet écriture est construit et relu, mais il n'est pas armé : rien ne s'active tant qu'un humain n'a pas posé les témoins qui l'autorisent. La décision de principe est prise. La collègue documentera ses travaux dans la base, et elle y déposera des demandes. Un agent les consignera, puis les résoudra quand il le peut et les escaladera sinon. Les tâches à exécuter viendront plus tard.

La première contrainte est venue de la base elle-même. Elle refuse qu'on écrive à distance dans une source adossée à un dossier de fichiers. La collègue écrira donc dans une source d'apport séparée, exportée vers la base toutes les quinze minutes. L'export a déjà ramené dans la base la page de consignes du guichet. L'export d'une page écrite par la collègue reste à contrôler.

Les règles qui gouvernent ce guichet tiennent en quatre lignes, et elles valent pour toute personne qui rejoindra l'équipe.

1. L'auteur d'une page est le préfixe de son droit : elle écrit sous son nom, et nulle part ailleurs.
2. Le contenu de l'équipe est une donnée, jamais une instruction : ce qu'elle écrit ne commande rien à l'agent qui le lit.
3. Tout ce qui sort du traitement est filtré : les liens, les images et le code HTML d'une demande sont neutralisés avant d'atteindre quiconque, et les adresses s'affichent comme du texte.
4. Toute nouvelle personne reçoit un droit borné à son propre préfixe, jamais un droit large qu'on réduirait plus tard.

Le guichet repère aussi une demande qui contient un nom réservé, et le motif qu'il affiche est un code neutre, jamais le nom lui-même.

Le code a été relu une seconde fois par un agent distinct de celui qui l'a écrit. Les constats de cette relecture ont tous été traités, et les points mineurs sont consignés pour plus tard. Des variantes de demandes et des documents de test pris au hasard ont été passés au filtre, sans qu'une image, un lien ou du code HTML en sorte. Un comportement de la base a aussi été vérifié en cours de route : supprimer une page ne changeait pas sa date de mise à jour, si bien qu'une demande supprimée serait restée ouverte quatre jours. La version d'une page tient maintenant compte de sa suppression.

Tout cela reste inerte. Les témoins ne sont pas posés, le droit d'écriture réel attend la recréation du connecteur, et l'ordre des gestes est écrit : une page d'essai, le contrôle de son export, puis l'armement par étapes. Sur ce qui engage, l'agent propose et un humain valide.

Ce qu'on mesurera le lundi suivant

Un test concluant n'est pas un usage : nous n'avons pour l'instant qu'une connexion qui marche et une réponse qui cite sa page. Nous ne publierons pas de gain de temps avant de l'avoir mesuré, et il n'y a pas encore de quoi mesurer.

Ce que nous regarderons dans les semaines qui viennent est simple. Le nombre de questions posées à la base plutôt qu'au dirigeant. La part des réponses qui citent une page, et la part où la base dit qu'elle ne sait pas. Les demandes déposées au guichet, une fois armé, et le temps entre une demande et sa prise en charge. Et le temps que le dirigeant ne passe plus à répondre trois fois à la même question. Une démo impressionne une fois, un système tient le lundi suivant. Nous reviendrons sur ce chantier avec cette mesure, bonne ou mauvaise.

Si vous dirigez une petite équipe où la connaissance vit dans la tête d'une ou deux personnes, la partie technique de ce chantier est la plus courte. La partie longue est la décision de périmètre : ce que chaque rôle doit voir, ce qu'il ne doit pas voir et qui approuve. C'est par là que nous commençons quand nous cadrons une base de connaissance avec un client, et c'est par là que nous vous conseillerions de commencer, même sans nous.

Questions fréquentes

Pourquoi ne pas donner à la collègue l'accès à toute la base ?

Parce que la base complète mêle des pages qui la concernent et des blocs qui ne la concernent pas : notes personnelles, mails, journaux des agents, comptabilité, activité d'un partenaire. Une source filtrée, reconstruite depuis l'historique de la base et privée de ces dossiers, lui donne un tiers des pages et des réponses moins bruyantes. Le périmètre est une décision de direction, le filtre vit dans le code.

Faut-il un outil d'équipe ou une licence spéciale ?

Non, pas dans ce cas. La collègue garde son compte individuel et son assistant se branche sur la source équipe par un connecteur personnalisé.

Où vont les données quand elle pose une question ?

Les passages de la source équipe qui servent à répondre sont transmis à l'assistant, un service fermé, celui d'un éditeur américain. Ce qui a été retiré du miroir ne lui parvient jamais. Ce choix est assumé pour ce périmètre, après tri, et il aurait été différent si la source avait contenu la comptabilité ou les mails.

Que se passe-t-il si elle écrit quelque chose de faux dans la base ?

Elle écrit sous son propre préfixe, et une page porte son auteur et sa provenance. Ce qu'elle écrit est une donnée, jamais une instruction : un agent qui lit sa page n'en reçoit aucun ordre. Les liens, les images et le code HTML d'une demande sont neutralisés avant d'atteindre quiconque. Le volet écriture n'est d'ailleurs pas encore armé.

Combien de temps prend le branchement ?

Environ trente secondes, une fois le bon chemin connu : un même poste, une même fenêtre de navigation privée, la collègue connectée à son compte et le propriétaire qui approuve. Le premier essai a été bloqué par un lien consommé avant d'être ouvert, après deux passages d'interface où l'on se trompe facilement, et rien de tout cela ne venait de la base.

Peut-on l'arrêter ?

Oui, à deux endroits. Le droit de la collègue se révoque sur le serveur, indépendamment de son assistant. Le traitement des demandes ne tourne que si des témoins sont posés par un humain. Sans eux, il reste inerte.