---
title: "Règles de l'agent"
description: "Comment inscrire Notarium dans le fichier de règles de votre agent (CLAUDE.md, AGENTS.md, règles Cursor) pour qu'une session s'ouvre sur start_session."
---

# Règles de l'agent

Brancher l'endpoint MCP, c'est la moitié du travail. L'autre moitié consiste à amener l'agent à démarrer **de lui-même** depuis la base de connaissances, plutôt qu'après votre « va d'abord voir dans Notarium ». Cette page explique comment le graver une bonne fois pour toutes.

## Pourquoi la connexion ne suffit pas

Quel outil appeler, c'est le modèle qui en décide. De son côté de la connexion, Notarium fait tout ce qu'il peut : à l'initialisation, il transmet le champ `instructions` (« appelle `start_session` en premier »), et la description de l'outil lui-même dit noir sur blanc qu'il est idempotent et qu'on peut le rappeler sans risque. Cela améliore nettement les chances, mais ce n'est **pas une garantie** — et, par construction du protocole, cela ne peut pas l'être.

La garantie, elle, vit de votre côté : dans les instructions permanentes de l'agent. L'effet pratique est simple : soit l'agent ouvre une session avec le contexte du projet, soit vous le lui rappelez à la main chaque fois, et l'interaction cesse d'être native.

> [!note] Un appel manqué ne casse rien
> L'absence de `start_session` ne casse pas le travail : les autres outils se suffisent à eux-mêmes, et les limites d'accès sont tenues par le jeton, pas par la discipline de l'agent. La seule différence tient au contexte — l'agent ne verra ni votre profil, ni le delta des changements, ni le dictionnaire des catégories convenues, ce qui le rend plus enclin à créer un doublon ou à nommer les choses à sa façon.

## Où l'écrire

Presque tous les clients d'agents disposent d'un fichier d'instructions permanentes, injecté dans chaque session :

| Client | Où il se trouve habituellement |
|---|---|
| Claude Code | `CLAUDE.md` à la racine du dépôt (plus un fichier global dans votre répertoire personnel) |
| Codex | `AGENTS.md` à la racine du dépôt |
| Cursor | les règles de projet dans `.cursor/rules` |
| Votre propre agent ou une intégration API | le prompt système |

Le format et les chemins exacts sont fixés par le client, qui les fait évoluer indépendamment de nous — reportez-vous à sa documentation. Notarium n'exige rien de ce fichier : c'est du texte brut que lit votre agent.

## Le bloc minimal

Trois règles couvrent le scénario principal — partir du contexte, ne pas créer de doublons, ranger le savoir là où il doit aller :

```markdown
## Notarium — la base de connaissances du projet

- Au début d'une nouvelle session, appelle `start_session(project: "acme/website")`
  sur le serveur MCP `notarium` — profil, projets accessibles, index de ce
  projet, delta des changements depuis ta dernière visite et dictionnaire
  des catégories.
- **Cherche avant d'écrire :** `search("<sujet>", project: "acme/website")` —
  la recherche couvre aussi ta propre mémoire, les doublons sont donc repérés.
- Consigne les faits durables sur le projet via `remember_about_project`,
  ceux sur le propriétaire via `remember_about_user`, le savoir partagé
  et visible via `create_note`.
```

Mettez-y votre propre handle de projet. Il a généralement la forme `space/project`, mais pour le projet racine d'un espace il se réduit à un seul segment — simplement `space`. Ne le déduisez pas d'une règle : `get_my_projects` renvoie la liste toute faite, reprenez-le de là mot pour mot. Dans un fichier de règles, mieux vaut figer la valeur exacte, pour que l'agent n'ait pas à la chercher chaque fois.

> [!tip] Un appel au lieu de cinq
> `start_session` est fait exactement pour ça : une seule requête renvoie ce qui, autrement, coûterait plusieurs appels exploratoires et du contexte en trop. Il est idempotent — le rappeler après une compaction du contexte est sans risque et sans effet de bord. La seule chose qui ne se répétera pas, c'est le delta des changements : par défaut, le premier appel déplace le signet de la « dernière visite », si bien qu'un second appel revient vide. Pour jeter un œil au delta sans déplacer le signet, appelez-le avec `acknowledge: false`.

## Le bloc étendu : une carte du canon

Si un projet contient des notes à lire pour un rôle ou une tâche donnés, n'obligez pas l'agent à les retrouver à chaque session — donnez-lui une carte. Charger quelques notes précises coûte moins cher que « lis tout le projet » :

```markdown
## Notarium

- Premier appel — `start_session(project: "acme/website")`.
- Ensuite, charge des notes précises plutôt que de lire le projet entier :
  - conventions de développement — `get_note("<id>")` ;
  - checklist de revue — `get_note("<id>")` ;
  - contexte autour d'un sujet — `recall("<sujet>", project: "acme/website")`.
- Avant toute écriture — `search("<sujet>", project: "acme/website")`.
- Tiens le journal de travail et les décisions d'une tâche dans Notarium,
  pas dans les fichiers du dépôt.
```

Les identifiants de notes sont stables : ils survivent à un renommage comme à un déplacement, la carte ne se périme donc pas quand vous réorganisez la base. Un lien `[[par titre]]` ne se casse pas non plus lors d'un renommage — l'ancien titre part dans l'historique des alias.

## Deux couches de règles

Séparez les instructions selon leur durée de vie — vous n'aurez ainsi pas à les dupliquer dans chaque dépôt :

- **La couche globale** (un fichier de règles partagé ou le prompt système) — ce qui est vrai en toutes circonstances : appeler `start_session` en premier, chercher avant d'écrire, où vont les faits sur le propriétaire. Pas de handle de projet ici.
- **La couche projet** (un fichier dans le dépôt) — le handle de ce projet précis, la carte du canon, les accords locaux.

Brancher un nouveau dépôt sur la base de connaissances se résume alors à quelques lignes et un seul handle, tandis que les règles communes tiennent en un seul endroit.

## Ce qui n'a pas sa place dans les règles

> [!warning] Les règles de l'agent ne sont pas un mécanisme de sécurité
> Un fichier de règles est une indication, pas une frontière. Ce qu'un agent **peut** faire est déterminé par les permissions du jeton et le jeu d'outils : un jeton en lecture ne voit physiquement pas les outils d'écriture, et l'espace d'autrui reste hors d'atteinte par principe. N'essayez pas d'enfermer un agent avec du texte là où c'est la portée du jeton qu'il faut — voir [Sécurité et visibilité](/docs/agents/security/).

Deux autres choses qui ne doivent pas y atterrir :

- **Les jetons.** Un fichier de règles finit généralement dans git. Un jeton personnel se déclare dans la configuration de votre client MCP, pas dans une instruction.
- **Une paraphrase de la documentation de référence des outils.** L'agent voit déjà les noms et les descriptions dans `tools/list` ; ils sont statiques et toujours à jour. Une copie dans le fichier de règles s'écarte vite de la réalité — écrivez des intentions et des accords, pas un doublon de la documentation.

## Comment cela s'articule avec la curation du contexte

Deux moitiés d'une même tâche, dont aucune ne remplace l'autre :

- **Le fichier de règles** garantit que l'appel à `start_session` **a bien lieu**.
- **La section Agents → Context** décide de **ce que** cet appel rapporte : épingles always-load, jeux de contexte et mise en sourdine des catégories de mémoire bruyantes — le tout sous un budget de tokens commun.

Donc, si l'agent démarre avec du contexte mais pas le bon, le correctif n'est pas dans le fichier de règles — il est dans les [jeux de contexte et épingles](/docs/agents/context-pins/).

## Ensuite

- [Connecter un agent](/docs/agents/connect/) — jeton, connecteur OAuth, transport.
- [Jeux de contexte et épingles](/docs/agents/context-pins/) — ce qui entre dans `start_session`.
- [Outils d'intention](/docs/agents/intent-tools/) — le jeu complet et l'ordre des appels.
- [Mémoire de l'agent](/docs/agents/memory/) — en quoi `remember_*` diffère de `create_note`.