---
title: "Types de notes"
description: "La classe d'une note est un ensemble de politiques de visibilité et d'indexation que le système déduit de l'emplacement — ce n'est pas un champ libre."
---

# Types de notes

Chaque note possède une **classe** — elle détermine où la note est visible et comment elle est indexée. La classe n'est pas une étiquette libre du frontmatter que l'on renseigne à la main : c'est un ensemble de politiques que le système **déduit de l'emplacement de stockage et applique de lui-même**. Dans une réponse d'API, la classe est en lecture seule.

## La classe est un ensemble de politiques

Derrière chaque classe se cache un ensemble de politiques — un oui/non pour chacune : la note est-elle indexée, apparaît-elle dans le graphe, dans le Fil, dans l'arborescence, dans la recherche exposée à l'utilisateur, est-elle accessible au `recall` d'un agent, est-elle versionnée, est-elle répliquée. L'essentiel : la visibilité est vérifiée à un seul endroit, et non par un filtre qu'il faut penser à ajouter à chaque requête. « Masquer des résultats » et « exclure de l'index » sont deux choses différentes, et Notarium ne les confond jamais.

L'identité d'une note, c'est son `notarium-id`, pas son chemin. C'est pourquoi la déplacer ou la renommer ne change jamais silencieusement sa classe ni ne casse les index.

## Le registre des classes

| Classe | Statut | Visibilité |
|---|---|---|
| `user-doc` | actif | Visible partout : arborescence, Fil, graphe, recherche. La classe par défaut pour tout le contenu utilisateur. |
| `agent-memory` | actif | Indexée et accessible au `recall` d'un agent, mais masquée des surfaces exposées à l'utilisateur ; visible par le propriétaire dans une section distincte. |
| `attachment` | porte des politiques | Les pièces jointes sont des données à part entière, mais ne sont pas indexées comme connaissance : seuls les fichiers `.md` sont interrogeables. |
| `derived` | porte des politiques | Artefacts régénérables (aperçus, rendus) ; ils n'atteignent pas l'index. |
| `profile` | actif | Masquée partout où vous cherchez et parcourez des notes ; accessible uniquement via Settings → Profile et à l'agent dans `start_session`. |

## Les deux classes avec lesquelles vous travaillez

En pratique, deux classes restent actives et continuent de se remplir.

**`user-doc`** — vos notes. La classe par défaut : librement organisée dans l'arborescence, alimentant la recherche, le graphe et le Fil. C'est exactement là qu'écrivent aussi bien une personne (via l'éditeur) qu'un agent (via `create_note`).

**`agent-memory`** — la mémoire de l'agent. Ce sont des notes lisibles, pas un stockage caché : l'agent ajoute ses observations à un fichier par catégorie plutôt que de multiplier les micro-fichiers. La mémoire vit dans un dossier de service distinct, `.notarium/memory/`, pour ne pas se mélanger à votre arborescence ni entrer en collision avec vos dossiers.

> [!note] La mémoire vous est visible, mais elle appartient à l'agent
> Vous **lisez, modifiez et supprimez** le contenu de la mémoire — c'est ainsi que vous auditez et contrôlez ce qui a pu se retrouver dans le contexte (l'historique montre qui a écrit quoi). Mais vous ne la **réorganisez** pas : la disposition appartient à l'agent (un ensemble plat de catégories plus un index dérivé). Déplacer des éléments est techniquement sans risque — l'interdiction de réorganiser est une décision produit, pour que le modèle de mémoire reste prévisible.

L'index de la mémoire est dérivé : il est assemblé à partir du champ `summary` de chaque fichier de mémoire et reconstruit par un rescan complet. Il se charge immédiatement dans `start_session`, tandis que les fichiers eux-mêmes sont récupérés à la demande via `recall`. Plus de détails dans [Mémoire de l'agent](/docs/agents/memory/).

## `profile` — « à propos de vous »

Une classe dédiée à la note de profil : du contenu rédigé par un humain à votre sujet (écrit par vous, pas par l'agent). Elle est masquée partout où vous cherchez et parcourez des notes, et ne peut être atteinte que de deux façons — via Settings → Profile et en laissant `start_session` la charger dans le contexte de l'agent par identifiant. Ce n'est pas la mémoire de l'agent ; c'est une fiche de contexte que vous entretenez.

La classe est déduite de l'emplacement de stockage et fixée par le système — l'agent ne choisit ni le dossier ni la classe. Pour comprendre comment cela s'articule avec l'isolation et l'adressage, voir [Espaces et projets](/docs/concepts/spaces-and-projects/).