Humains et agents sur un socle commun
Le postulat central de Notarium : une même base de connaissances est disponible de façon identique pour les humains et les agents IA. L'humain passe par l'interface web (REST), l'agent par le point d'accès MCP intégré, et tous deux voient le même graphe de notes sur un unique socle portable. Ce n'est pas un « mode bot » ajouté à côté : c'est une parité de fonctionnalités par conception.
Un socle, plusieurs transports
L'architecture repose sur un seul principe : la logique métier vit dans un socle unique, et les transports ne font qu'adapter l'accès à celui-ci.
flowchart LR
human([Humain]) -->|REST · éditeur web| core
agent([Agent IA]) -->|MCP · POST /mcp| core
core[Socle Notarium] --> files[(Fichiers Markdown)]
C'est toujours le socle qui décide, jamais le transport. Une note créée par un agent suit donc exactement le même chemin qu'une modification faite depuis l'éditeur : elle est écrite dans le même fichier .md, versionnée dans le journal, limitée par les mêmes accès et dotée d'un enregistrement de provenance.
Ce que signifie la « parité »
La modification d'un agent et celle d'un humain sont indiscernables dans leur traitement :
- Versionnage. Chaque modification est une révision dans le journal, rattachée à un
notarium-id. Voir Historique des versions. - Portée. Le jeton d'un agent n'accorde rien de plus que l'appartenance du principal : un jeton en lecture seule ne voit même pas les outils d'écriture. Voir Modèle d'accès.
- Provenance. Chaque révision indique d'où vient la modification : un humain (
user:<name>), un agent précis (pat:<name>:<id>) ou un éditeur de fichiers externe. Qui a modifié quoi, et comment : c'est toujours transparent.
Les modifications d'un agent ne se dissolvent pas dans un historique commun. Vous pouvez toujours ouvrir une note et constater que telle ligne précise a été ajoutée par un agent donné sous un jeton donné — et la ramener à une version antérieure si besoin.
Comment travaille un agent
Un agent accède à la base de connaissances par un point d'accès unique, POST /mcp — un ensemble restreint de 21 commandes prêtes à l'emploi (créer une note, rappeler du contexte, chercher, écrire en mémoire), et non des opérations de stockage de bas niveau. Les outils expriment une intention, tandis que le système impose l'emplacement et la classe de la note : l'agent désigne un projet par son nom mais ne choisit pas l'espace ni la classe de la note (une protection contre les erreurs).
Le point d'entrée habituel est un appel start_session : l'agent reçoit un profil, la liste de ses projets et le contexte pertinent. La connexion et l'ensemble complet des outils sont détaillés dans Agents et MCP ; la première étape pratique est Connecter un agent.
Des limites délibérées
Un socle commun ne signifie pas que l'agent peut tout faire :
- L'agent n'a pas de suppression irréversible. L'écrasement, oui (il est réversible via le journal) ; la suppression définitive de conteneurs, non.
- Aucune opération inter-espaces. L'agent travaille strictement à l'intérieur des espaces qu'il peut atteindre.
- Les outils n'ont aucun canal vers le monde extérieur, et du contenu non fiable n'est jamais mêlé à leurs descriptions — cela rompt la chaîne « données privées × entrée non fiable × chemin vers l'extérieur ».
- Notarium n'est délibérément pas un produit E2EE : un serveur intelligent a besoin de voir le contenu pour offrir la recherche, la sémantique et les agents. La confidentialité vient de l'auto-hébergement et de la possession de vos fichiers, pas d'un chiffrement de bout en bout.
Pour en savoir plus sur la protection du périmètre des agents : Sécurité et visibilité.