AKB - une infrastructure de connaissances d’équipe lue et écrite à la fois par les humains et l’IA, avec gestion des autorisations en prime

Bonjour. Chez Dnotitia, l’entreprise à laquelle j’appartiens, nous développons AKB (Agent Knowledge Base), une base de connaissances d’équipe que les agents IA peuvent directement lire et écrire pendant leur travail.

Pourquoi l’avoir créé ?

Il existe déjà de nombreux wikis utilisés par les humains (Confluence·Notion). Côté agents, il existe aussi des outils comparables. mem0 accumule comme mémoire personnelle ce qu’il extrait des conversations, et LLM Wiki crée une base de connaissances personnelle que l’agent peut lire et écrire. Mais cela reste généralement au niveau individuel, et il est difficile de dire que ces outils ont été conçus comme une base commune que plusieurs personnes peuvent lire et écrire ensemble.

Le Open Knowledge Format (OKF) de Google part d’un constat similaire. Comme les connaissances sont dispersées entre wikis, catalogues et code, les agents doivent reconstituer le contexte à chaque fois ; ce qu’il faut, ce n’est donc pas un énième service fermé, mais un format commun que plusieurs outils peuvent lire et écrire ensemble. Le format proposé par OKF est simple. Il suffit de rassembler des fichiers Markdown dans un dossier et d’ajouter quelques lignes de YAML en tête de chaque fichier. Ensuite, la manière de produire ce format, de le lire et de l’étendre reste ouverte à chaque implémentation.

Que fait AKB ?

AKB est une infrastructure qui implémente ce format comme base de connaissances commune à l’équipe. Le vault est un ensemble de fichiers Markdown compatible avec OKF, mais ce n’est pas un simple index à consulter via la recherche : c’est un dépôt partagé dont humains et agents lisent et écrivent ensemble la même source. Les humains y accèdent via une interface web, les agents via MCP. Mais la source manipulée reste unique. Dès lors que les agents commencent à écrire, la question de « ce qui a changé, et comment » devient aussi importante. Comme le vault est un dépôt Git, chaque modification est conservée sous forme de commit et de diff.

Et il n’y a pas que des documents. Si OKF est un format qui décrit les connaissances en Markdown, AKB ajoute au même vault des tables interrogeables et un stockage de fichiers, tout en reliant les documents entre eux via un graphe de connaissances. Les documents restent des connaissances lisibles par l’humain et référencées par les agents, tandis que les données structurées comme les listes, états ou statistiques peuvent être stockées dans des tables séparées et interrogées. Il devient ainsi possible de faire des choses difficiles avec un simple wiki ou une simple recherche, par exemple développer et exploiter des applications métier en utilisant AKB comme couche de données et d’historique des changements.

Mais pour devenir une base de connaissances commune d’équipe, les données et l’historique ne suffisent pas. Un format comme OKF ne définit pas qui peut voir quoi. La partie sur laquelle nous avons le plus travaillé dans AKB, ce sont précisément les autorisations. Les agents sont authentifiés comme la personne qui a émis leur token, et héritent exactement des droits de cette personne sur le vault. Les mêmes frontières d’accès qui s’appliquent aux humains s’appliquent donc aussi telles quelles aux agents. Cette séparation est imposée à deux niveaux. Pour les accès classiques comme les documents, fichiers ou recherches, les autorisations sont vérifiées dans la couche applicative. Pour les chemins qui exécutent du SQL d’agrégation ou d’analyse sur les tables, une seconde barrière existe au niveau de la base de données. Comme les requêtes s’exécutent avec le rôle PostgreSQL de l’utilisateur selon un mécanisme de PG ACL, si une requête tente de référencer un vault hors autorisation, ce n’est pas l’application mais PostgreSQL lui-même qui la refuse.

Notre équipe utilise reef, un issue tracker, au-dessus de l’infrastructure AKB. Un issue y est à la fois un document Markdown dans le vault et une ligne de table interrogeable. Les développeurs travaillent avec des agents de code comme Claude Code ou Codex, et les PM avec l’agent dédié de reef, tous à partir du même document dans le vault. Même sans connaître la syntaxe de spécification destinée aux développeurs, les PM peuvent créer des issues en s’appuyant sur le contexte accumulé dans AKB ; de leur côté, les développeurs peuvent récupérer ce contexte via MCP et développer sans avoir à repartir fouiller des explications éparpillées. Nous constatons directement dans l’équipe que les barrières techniques et linguistiques entre développeurs et PM diminuent lorsqu’on passe par des agents.

Voir tout de suite

Pour jeter un œil sans installation, vous pouvez accéder à la démo publique (akb-demo.agent.seahorse.dnotitia.ai). (Une inscription est nécessaire, mais comme il s’agit d’une démo, toutes les données sont réinitialisées chaque semaine.)

Si vous voulez l’exécuter vous-même, lancez-le avec Docker Compose comme ci-dessous, puis accédez à localhost:3000. Même sans clé d’embedding, la recherche par mots-clés (BM25) fonctionne.

git clone https://github.com/dnotitia/akb && cd akb  
cp config/app.yaml.example   config/app.yaml  
cp config/secret.yaml.example config/secret.yaml  
docker compose up -d  

Il reste encore beaucoup de choses à améliorer. Si vous l’essayez, nous vous serions reconnaissants de laisser librement en commentaire tout bug, comportement étrange ou impression ressentie.