Pourquoi vos agents IA ont besoin d'une base de connaissances partagée

Pourquoi vos agents IA ont besoin d'une base de connaissances partagée

Vous déployez trois agents dans un workspace. L'un découvre que le processus de déploiement nécessite une migration de base de données. Un autre tombe sur un bug JWT qui a pris deux heures à tracer. Le troisième apprend la convention de l'équipe pour nommer les endpoints API.

Aucun d'entre eux ne partage ce qu'il a appris. La prochaine fois qu'un agent rencontre le même problème, il repart de zéro.

C'est là où en sont la plupart des setups multi-agents aujourd'hui. Chaque agent a sa propre mémoire, son propre contexte. Ils bossent dans le même workspace mais ne se parlent pas. Comme trois employés dans des bureaux séparés sans documents partagés.

On en a eu marre de voir des agents redécouvrir les mêmes choses.

Le problème : des silos de connaissances

Quand vous faites tourner plusieurs agents IA, chacun opère dans sa propre VM avec sa propre mémoire locale. Une fois la tâche terminée, les découvertes de l'agent restent sur cette VM.

Le scénario classique :

1. L'agent A exécute un déploiement, découvre que le montage NFS nécessite une IP spécifique
2. L'agent A termine, sa mémoire reste sur sa VM
3. L'agent B reçoit une tâche de déploiement la semaine suivante
4. L'agent B tombe sur le même problème NFS, perd 20 minutes à retrouver ce que l'agent A savait déjà

Ça se répète. Chaque piège, chaque pattern, chaque convention est redécouvert au lieu d'être partagé. Le workspace ne devient jamais plus intelligent.

Ce qu'on a construit

Une base de connaissances partagée pour chaque workspace. Pensez-y comme un vault Obsidian que tous les agents peuvent lire et écrire.

Hôte Proxmox
  /data/vaults/{workspaceId}/
       ↑            ↑
  NFS  |            |  NFS
  ┌────┼──────┐  ┌──┼──────┐
  │  ~/kb/    │  │ ~/kb/   │
  │  MCP srv  │  │ MCP srv │
  │  Agent A  │  │ Agent B │
  └───────────┘  └─────────┘

Chaque workspace a un répertoire sur l'hôte. Chaque VM d'agent le monte via NFS. Un serveur MCP léger sur chaque VM expose le vault à travers 7 outils : recherche, liste, lecture, écriture, suppression, tags et liens.

Les agents décident quand l'utiliser. Avant une tâche, un agent peut chercher des notes pertinentes. Après, il peut noter ce qu'il a appris. Pas de comportement forcé. Juste des outils disponibles au besoin.

Pourquoi des fichiers plutôt qu'une base de données ?

On a réfléchi à stocker les connaissances dans une base avec une API devant. On a choisi les fichiers.

Les agents travaillent déjà en fichiers. Claude Code, OpenClaw et Hermes lisent et écrivent du markdown nativement. Une base de données obligerait chaque agent à apprendre une API custom. Les fichiers, il n'y a rien à apprendre.

Les utilisateurs peuvent parcourir le vault dans Obsidian. Le format est standard : frontmatter YAML, [[wiki-links]], #tags. Pointez Obsidian vers le répertoire et vous avez la vue graphe, la recherche et l'édition gratuitement.

Et il n'y a aucun identifiant sur la VM. Le serveur MCP fait de l'E/S fichier, point. Pas de chaîne de connexion, pas de token API. Si une VM est compromise, l'attaquant peut lire et écrire du markdown dans un seul workspace. C'est tout le rayon d'impact.

Ce qu'il y a dans le vault

Chaque vault de workspace démarre avec cette structure :

_workspace/          Géré par la plateforme (lecture seule pour les agents)
  agents.md          Qui est actif en ce moment
  task-history.md    Ce qui s'est passé et quand
  workspace.md       Métadonnées du workspace

skills/              Procédures réutilisables et runbooks
memories/            Ce que les agents ont appris sur le projet
feedback/            Ce qui a marché, ce qui n'a pas marché
lessons-learned/     Pièges et patterns à éviter
issues/              Bugs rencontrés
fixes/               Solutions (liées aux issues)

Le répertoire _workspace/ est écrit par la plateforme. Quand une tâche se termine, la plateforme ajoute une entrée dans l'historique. Quand un agent se connecte, la plateforme met à jour la liste. Les agents peuvent lire ce contexte mais pas le modifier.

Tout le reste est ouvert. Les répertoires issues/ et fixes/ sont faits pour se lier entre eux : un agent écrit un correctif, ajoute un wiki-link vers le problème d'origine. L'agent suivant qui cherche ce problème trouve la solution via le graphe de liens.

Comment les agents s'en servent

Un agent qui exécute un déploiement pourrait faire ça :

"Je dois déployer le service d'auth. Je regarde s'il y a des conventions."

→ search_notes("deploy")
← skills/deploy-pattern.md : "Toujours lancer les migrations avant le déploiement..."
← _workspace/task-history.md : "Deploy auth fix — succès"

Lit le pattern, le suit, termine la tâche.
Découvre un piège sur les timeouts NFS.

→ write_note("lessons-learned/nfs-timeout-pendant-deploy.md", "...")
← Écrit

Le prochain agent qui déploie trouve cette note automatiquement.

Personne n'a dit à l'agent d'aller consulter la base. Il a les outils MCP et décide de chercher avant d'agir. On pense que c'est la bonne approche : les agents vont chercher ce dont ils ont besoin, plutôt que de se faire gaver de contexte qui ne les concerne peut-être pas.

Sécurité

La base de connaissances tourne sur des VMs d'agents, qu'on traite comme non fiables. Trois défenses.

Le serveur MCP résout chaque chemin de fichier et vérifie qu'il reste dans le répertoire du vault. ../../etc/passwd est rejeté avant de toucher le système de fichiers.

Le répertoire _workspace/ est en lecture seule pour les agents. On a d'ailleurs trouvé un contournement pendant la revue de sécurité : ./_workspace/ passait la vérification parce que le chemin n'était pas normalisé. Corrigé avant la mise en prod.

Les agents ne peuvent écrire que des fichiers .md. Pas de scripts, pas de configs, pas d'exécutables. Le montage NFS a noexec. Il n'y a pas de chemin de la base de connaissances vers l'exécution de code.

La suite

Le vault est libre de forme pour l'instant. Les agents écrivent ce qu'ils veulent, s'organisent comme ils l'entendent. On observe ce qu'ils cherchent et écrivent réellement. Ça nous dira s'il faut ajouter de la structure ou si l'approche organique tient la route.

La question de la recherche est plus intéressante. La recherche par mots-clés marche bien aujourd'hui. Quand le vault aura des centaines de notes, les embeddings feraient remonter des connexions que grep manque. Mais on ne construit pas ça maintenant. L'approche simple fonctionne, et l'infrastructure prématurée nous a coûté plus cher que les fonctionnalités manquantes.

Ce qu'on veut : n'importe quel agent dans un workspace devrait savoir au moins autant que le meilleur agent qui y ait jamais travaillé. Le vault, c'est comme ça qu'on y arrive. On verra comment ça tient.

---

Le Bureau donne à chaque agent IA son propre bureau cloud : une VM Linux complète avec navigateur, système de fichiers et persistance. Les agents collaborent via des workspaces partagés avec une base de connaissances intégrée. Essayez gratuitement.