Projet Cedar : Tester si les agents IA peuvent gérer un Wiki Markdown d’entreprise.

L’Obsidian peut transmettre le contexte entre les projets d’une personne et ses agents de codage. Les plans, décisions, exigences et contraintes survivent aux sessions individuelles ; Claude, Codex ou tout autre outil d’agent peut lire les mêmes fichiers de projet, et une personne peut examiner et corriger ces fichiers ainsi que changer de modèle sans que les connaissances liées au projet restent bloquées dans l’historique des conversations. Cela fonctionne bien au sein des projets d’une seule personne, car c’est elle qui prend la plupart des décisions et connaît l’organisation de tout le contenu.

Dans une entreprise, la situation est différente. Les connaissances sont dispersées dans diverses bases de données, tickets, réunions, documents et entre de nombreuses personnes différentes. Les sources se contredisent souvent, et les décisions sont parfois modifiées. Un ensemble de notes de réunion peut décrire une idée que l’équipe a finalement abandonnée, tandis qu’un document d’architecture approuvé contient la décision qui reste en vigueur. La question qui se pose donc est de savoir si une pratique propre à chaque projet peut être étendue à toute l’organisation, et si le Markdown partagé pourrait servir d’accord entre les employés et les agents.

L’idée du LLM Wiki

Cette approche provient d’une proposition récente d’Andrej Karpathy, qui l’a nommée LLM Wiki. Elle comporte trois niveaux :

• Des sources brutes qui ne sont jamais modifiées
• Un wiki en Markdown, interconnecté et géré par un agent
• Un schéma qui indique à l’agent comment organiser et maintenir ce wiki

Trois opérations agissent sur ces couches. Ingest permet d’ajouter de nouvelles sources. Query s’appuie sur les connaissances mises à jour. Lint vérifie le wiki en quête de lacunes, de matériel obsolète, de conflits et d’une mauvaise organisation.

Les sources possibles mentionnées dans la proposition incluent les conversations Slack, les réunions, les documents de projet et les appels avec les clients, que l’agent compile en connaissances persistantes d’une tâche à l’autre. Cela diffère d’un système de recherche qui ne trouve que quelques fragments pertinents chaque fois qu’on pose une question. Ici, l’agent conserve un artefact qui évolue au fur et à mesure que de nouvelles informations arrivent.

Une première architecture qui s’est avérée incorrecte

Une première interprétation naturelle de LLM Wiki suggère deux couches de connaissances distinctes : un wiki généré par l’agent, et des fichiers Obsidian placés par-dessus. C’était inutile, car cela double le contenu et crée un problème de synchronisation.

Le Markdown généré peut lui-même constituer le wiki, et Obsidian n’est qu’une fenêtre sur celui-ci, un endroit pour parcourir, lire et modifier les pages. Le Markdown est le contrat commun, tandis qu’Obsidian sert de table de travail pour les utilisateurs. En changeant de fenêtre, les connaissances qu’elle contient restent inchangées, c’est ainsi que fonctionne un véritable wiki. Une organisation peut publier des pages approuvées via SharePoint, Confluence ou un portail interne, tandis que les ingénieurs et les agents continuent de travailler à partir de la source maintenue.

Le flux proposé est le suivant. Les sources internes de l’entreprise fournissent des preuves brutes immuables. Un agent chargé de la maintenance du wiki utilise le schéma et les règles de gouvernance pour proposer des modifications, et ces modifications approuvées sont intégrées dans un wiki Markdown géré par Git après examen. Une couche de services gère l’authentification, les permissions, la recherche et l’historique des audits. Les utilisateurs accèdent aux connaissances via Obsidian ou un wiki interne à l’entreprise, tandis que les agents utilisent la même couche de services avec leurs propres identités et permissions.

Les connaissances d’une entreprise ont besoin de plus que des liens entre notes

Un coffre-fort personnel fonctionne en partie parce que son propriétaire se souvient du contexte entourant les fichiers : quelle note de réunion était spéculative, quand une exigence a changé même si toutes les pages associées n’ont pas été mises à jour, et quels deux fichiers décrivent une même décision sous des noms différents. Une entreprise ne peut pas compter sur une seule personne pour retenir tout cela.

Son système de connaissances doit distinguer :

• une simple proposition par rapport à une décision qui a été approuvée
• ce qui est valable aujourd’hui par rapport à ce qui n’est plus qu’histoire
• une politique officielle par rapport à une remarque éphémère lors d’une réunion
• une contradiction déjà résolue par rapport à une encore en suspens
• un manque dans les archives par rapport à un choix que personne n’a encore fait

En plus de cela, il y a des propriétaires désignés, des étapes d’examen, des références aux sources, des règles concernant la fraîcheur des informations, des limites d’accès ainsi qu’un historique montrant quelles modifications un agent a apportées. La base de connaissances d’un individu peut tolérer l’ambiguïté, car le propriétaire se souvient de ce qui manque. Une couche commune à l’entreprise ne doit jamais permettre à une remarque superficielle de se transformer silencieusement en décision approuvée.

C’est pourquoi le schéma est important. Il va au-delà de la simple désignation des dossiers et fichiers. Grâce à lui, l’agent comprend comment l’entreprise encode ses connaissances. Les métadonnées d’une page wiki individuelle pourraient ressembler à ceci :

status: verified
owner: platform-team
last-reviewed: 2026-08-02
review-after: 2026-11-02
sources:
  - adr-014
  - meeting-2026-07-29
supersedes:
  - authentication-proposal-v1

Il est facile de faire en sorte qu’un agent génère du Markdown. Définir ce qu’il peut considérer comme la vérité organisationnelle est la partie difficile.

Une entreprise fictive en tant que laboratoire

Un dépôt de logiciels public ne présente pas suffisamment de complexité organisationnelle pour aborder cette question. Un dépôt bien organisé permet d’expérimenter l’ingestion, les liens et des questions de base, mais il ne contient pas naturellement des exigences changeantes des clients, des désaccords entre les parties prenantes, des notes informelles, une architecture obsolète ou des sources d’autorité inégales.

Afin de contourner ce problème, l’expérience a imaginé le Projet Cedar : une collaboration fictive dans laquelle Northstar AI Consulting travaille pour Prairie Health Network. Tout y est faux. La société de conseil développe un système capable de transformer des documents de politique et des enregistrements d’analyses de qualité en résumés préliminaires liés à leurs sources, ainsi que d’offrir une fonction de recherche interne. Ce scénario reflète des préoccupations réelles telles que la confidentialité des données, le choix entre traitement local et en cloud, l’évaluation par des humains, l’évaluation des modèles, les choix architecturaux, la traçabilité des sources et les exigences en constante évolution.

Le corpus synthétique contient 25 artefacts Markdown initiaux. Dans la réalité, ceux-ci arriveraient sous de nombreux formats, mais le test accepte cette compromission. Le matériel inclut des informations sur les entreprises, les politiques et exigences du client, les décisions architecturales, les notes de réunion, les évaluations des modèles, les archives des travaux d’implémentation, les rapports de suivi et les entrées relatives aux risques.

Un deuxième ensemble de huit artefacts ultérieurs modifie le projet : les exigences de sécurité se renforcent, une évaluation de modèle invalide une hypothèse antérieure, les critères d’acceptation changent, et une nouvelle décision architecturale remplace la conception initiale, tandis qu’une note de réunion informelle continue de décrire certaines parties de l’ancienne conception. Ces changements permettent de tester si une application peut faire évoluer les connaissances stockées.

Deux autres fichiers existent uniquement pour l’évaluateur. L’un est une carte des connaissances qui enregistre les faits, décisions, conflits et relations délibérément intégrés dans le corpus, servant de source de vérité. L’autre est un ensemble de questions d’évaluation avec des réponses attendues et des preuves sources requises, utilisées pour déterminer si les connaissances ont été mises à jour correctement. L’agent chargé de la maintenance du wiki ne doit jamais les voir pendant le processus de construction, de sorte que le test permet de vérifier s’il a véritablement reconstitué ce que la société fictive savait, et non simplement rédigé un wiki dont l’apparence semble convaincante.

Une expérience qui peut échouer

Le protocole prévu comporte deux étapes.

Au stade A, l’agent reçoit le corpus initial et crée la première wiki Markdown. Il doit indiquer ce que l’entreprise est en train de développer, quels sont les contraintes qui régissent le système, les raisons sous-jacentes à l’architecture initiale, quels risques restent non résolus, quelles décisions sont encore en suspens et quelles sources soutiennent chaque réponse. La wiki ainsi que ses réponses sont enregistrées avant l’apparition de tout nouvel élément de preuve.

Au stade B, le corpus mis à jour est déployé. L’agent doit alors réviser chaque page concernée, conserver les décisions obsolètes en tant qu’historique, rendre visibles les désaccords non résolus, et résister à la tentation de considérer le document le plus récent comme définitif. La différence générée par Git devient également une preuve : elle montre si les connaissances existantes ont été maintenues cohérentes ou simplement remplacées par un autre résumé.

C’était là le protocole complet. La première mise en œuvre réelle a suivi une voie différente, car elle a été développée dans le cadre d’un autre experiment où un agent IA a créé un projet logiciel pendant un long trajet en voiture.

La première version

La première version de Cedar est née de cet experiment de conduite, dont les détails sont secondaires. Ce qui compte, c’est ce que l’agent a produit. Ses données d’entrée provenaient du corpus Cedar, des instructions relatives au projet ainsi qu’un ensemble d’évaluation gardé hors de sa vue. Le projet ChatGPT en usage limitait les téléchargements à 25 fichiers, de sorte que seuls huit des 25 artefacts initiaux sont parvenus à l’agent, et le corpus des modifications a été retenu pour être fourni plus tard afin de tester sa capacité à intégrer ces modifications dans les documents.

Ce qui est revenu, c’était un programme en ligne de commande local écrit en Python. Il lisait les sources Markdown ainsi que leur frontmatter, extrayait les éléments marqués des lignes exactes d’où ils provenaient, et évaluait le degré d’autorité d’une source indépendamment de la date de sa publication. Les documents disposant de versions explicites étaient étiquetés comme actuels ou historiques. L’outil pouvait également générer un rapport de connaissances au format Markdown, récupérer des éléments pertinents pour une question, et auditer le wiki à la recherche de défauts structurels. Les documents sources étaient stockés séparément du dossier wiki/ généré, et le répertoire conservait les instructions pour les mainteneurs, les enregistrements d’exécution, le matériel d’évaluation ainsi que les résultats dans des emplacements distincts. Tous les 26 tests ont été réussis. Il s’agissait d’une première version fonctionnelle, bien que le corpus réduit ne permette de tester qu’une partie du protocole Cedar.

Pouvait-il conserver ce que l’entreprise savait ?

Lors de l’évaluation contrôlée, le système a obtenu 50 %. Il était bon pour conserver les preuves : les références sources ainsi que l’origine au niveau des lignes indiquaient précisément d’où provenaient les faits extraits. La difficulté résidait dans le fait de trouver et de lire les preuves appropriées lorsqu’une question réaliste était posée.

Une véritable question d’entreprise peut exiger la fusion de données provenant de plusieurs fichiers, privilégier une décision validée plutôt qu’une note informelle, remarquer qu’un document plus récent peut avoir moins de poids, distinguer une question en suspens d’une lacune dans les archives, et maintenir l’incertitude tant qu’aucune décision définitive n’a été prise. La préservation des preuves s’est avérée plus importante que leur sélection. L’audit structurel a révélé des défauts mécaniques tels que l’absence de métadonnées ou un format défectueux, mais les conflits sémantiques ont été plus facilement négligés, car deux documents pouvaient contenir des positions incompatibles dans un langage non lié, sans que le système ne détecte toujours ce conflit.

En bref, les citations ont été conservées sans qu’on comprenne celles qui avaient de la valeur. C’est un véritable point faible pour les connaissances d’entreprise, car une réponse bien citée peut encore être erronée si elle s’appuie sur une source de faible autorité, ignore une décision approuvée ultérieurement ou combine des faits qui ne devraient pas être associés.

Le corpus incomplet limite également les conclusions. L’agent n’a jamais reçu le corpus mis à jour, ce qui signifie que cette expérience n’a pas testé la partie la plus difficile du concept initial : mettre à jour les connaissances actuelles lorsque des sources fiables changent, tout en conservant l’état antérieur comme historique. La réponse partielle est qu’un agent peut créer une représentation structurée des connaissances de l’entreprise, liée aux sources, mais il n’existe pas encore suffisamment de preuves qu’il puisse la maintenir de manière fiable au fil des changements de l’entreprise.

Le wiki a besoin d’une interface entreprise

Cet essai a également mis en évidence un aspect important de l’architecture. Obsidian est utile pour examiner du Markdown généré, suivre des liens, vérifier les métadonnées et modifier manuellement une page. Cela suffit pour une configuration personnelle ou un prototype, mais aucune entreprise ne peut accorder à chaque employé et agent un accès direct à un coffre-fort. Entre le wiki Markdown et ses utilisateurs, un système réel nécessite une couche intermédiaire qui couvrirait :

• l’authentification gérée par le fournisseur d’identité de l’entreprise
• des règles d’accès liées aux utilisateurs, équipes, projets et rôles
• des identités distinctes avec leurs propres droits pour chaque agent
• une étape d’examen et d’approbation pour chaque modification proposée par un agent
• des résultats de recherche filtrés selon ce que la personne qui pose la demande peut voir
• des commentaires, des notifications et des attributions de propriété
• des modifications simultanées et des conflits de versions
• un journal d’audit indiquant qui ou quoi a modifié chaque page

politiques de conservation et de suppression

une interface que le personnel non technique peut réellement utiliser

L’authentification permet de déterminer qui pose la demande, tandis que l’autorisation décide de ce à quoi cette identité peut accéder, en termes de sources, de pages et d’opérations. Les agents relèvent également de cette distinction. L’agent d’une équipe financière ne devrait pas pouvoir consulter des dossiers cliniques simplement parce que ces deux ensembles de fichiers se trouvent dans la même wiki ; par conséquent, les agents ont besoin de leurs propres identités de service, de permissions limitées ainsi que des obligations d’audit propres aux humains. Les permissions doivent également suivre les informations au fur et à mesure qu’un agent les modifie : un résumé de projet tiré d’un document d’architecture public et une revue de sécurité restreinte pourraient révéler des détails confidentiels, même si la page semble inoffensive.

Obsidian peut rester l’outil de travail des responsables de maintenance et des réviseurs techniques, tandis que la plupart des employés accèdent aux connaissances via un site wiki ou un portail interne qui lit les mêmes informations gérées à l’aide d’un service contrôlé, sans en créer de copie supplémentaire. L’architecture se compose donc de quatre parties :

1. Couche des preuves : sources internes de l’entreprise immuables, avec leurs permissions d’origine
2. Couche des connaissances : le wiki Markdown géré par Git et ses relations de source
3. Couche de contrôle : identité, permissions, révision, historique d’audit et recherche
4. Couche d’interface : Obsidian pour ceux qui maintiennent le wiki, un site wiki interne pour les employés, et des API restreintes pour les agents

L’interface de l’entreprise ne duplique pas les connaissances. Elle contrôle la manière dont les personnes et les agents interagissent avec elles.

Que tester ensuite

La prochaine exécution doit utiliser l’ensemble complet du corpus Cedar : intégrer les 25 artefacts initiaux, évaluer la wiki initiale et l’enregistrer, puis introduire les huit artefacts de modification et vérifier si l’agent met à jour chaque page concernée, marque les décisions anciennes comme obsolètes, conserve l’historique à conserver, respecte les règles d’autorité source, met en évidence les désaccords non résolus, s’abstient de prendre des décisions arbitraires, et génère un diff Git que quelqu’un puisse examiner.

Le processus de récupération des informations devrait également être évalué séparément de l’entretien du système. Un système peut conserver les connaissances nécessaires mais fournir des éléments erronés en réponse à une question, ou donner la bonne réponse en consultant des sources brutes tandis que son wiki d’entretien devient obsolète ; ces échecs exigent des critères d’évaluation différents. Une étape ultérieure devrait intégrer les identités des utilisateurs et des agents dans le corpus, afin que les questions puissent s’assurer qu’un réviseur autorisé reçoit la bonne réponse, tandis qu’un autre utilisateur se voit refuser des informations restreintes. Cela rapproche l’expérience d’un déploiement réel au sein d’une entreprise.

Les agents peuvent-ils maintenir les connaissances d’une entreprise ?

La première version de Cedar ne prend en charge qu’une réponse qualifiée. L’agent a fourni un système fonctionnel capable d’accepter des documents similaires à ceux d’une entreprise, de conserver les références sources, d’étiqueter les versions des documents, de générer un wiki en Markdown et d’auditer sa structure. L’évaluation a ensuite montré que ces compétences étaient insuffisantes, car la gestion des connaissances d’une entreprise exige également le choix judicieux des preuves, la réflexion sur l’autorité, la détection des conflits, la gestion de l’incertitude, ainsi que le contrôle des accès et des révisions.

Markdown peut servir d’outil commun, mais une entreprise a néanmoins besoin d’une interface bien gérée autour de lui. Les personnes comme les agents ont besoin d’identités, les permissions doivent être transmises depuis la source originale vers les pages générées, les modifications effectuées par les agents nécessitent une révision, et chaque changement accepté doit faire l’objet d’un historique. Créer le wiki était la partie facile ; ce qui exige vraiment des efforts, c’est de décider ce que l’entreprise considère comme du savoir, qui peut y accéder et comment un agent est autorisé à le modifier.