Comment relire ce que les agents IA modifient dans vos notes

Quand vous laissez un agent IA travailler dans vos notes, il vous faut un moyen de vérifier ses changements avant de vous y fier. Un agent de code est rapide et s’exprime avec aisance, et c’est bien là le problème : une phrase fausse se lit exactement comme une phrase juste. Dans du code, un test échoue souvent quand un agent se trompe. Dans une base de connaissances, rien n’échoue. La date fausse reste simplement là.

Quelques problèmes reviennent sans cesse :

• Des réécritures discrètes. Vous demandez une nouvelle note et l’agent « range » au passage trois anciennes, en changeant le sens d’une phrase que vous aviez soigneusement écrite.
• Des modifications écrasées. Hier, vous avez corrigé un chiffre à la main. Aujourd’hui, l’agent réécrit la note à partir d’une source plus ancienne et votre correction disparaît.
• Des erreurs qui se propagent. La session suivante lit le fait erroné comme contexte, le répète dans deux autres notes, et le voilà qui a l’air confirmé.
• Aucune trace. Un mois plus tard, vous ne savez plus quelles notes vous avez écrites, lesquelles un agent a écrites, ni lesquelles quelqu’un a déjà vérifiées.

La solution a deux volets : voir chaque changement avant qu’il ne s’installe, et noter qui a vérifié quoi. Ce guide montre comment faire les deux à la main avec git et quelques champs de frontmatter, et après chaque étape, comment Knowtarium s’en charge. Nous construisons Knowtarium pour cela : les changements des agents y sont signés et annulables par défaut, et la relecture avant qu’un changement ne s’installe est un interrupteur que vous activez dossier par dossier.

Git est le meilleur outil gratuit pour ce travail. Si vos notes sont un dossier de fichiers markdown, mettez-les sous git et faites un commit avant chaque session d’agent. Tout ce que fait l’agent devient alors un diff que vous pouvez lire, garder en partie ou jeter.

# une seule fois, dans votre dossier de notes
$ git init$ git add -A && git commit -m "Notes before agents"
 
# avant chaque session d’agent : un point de départ propre, sur sa propre branche
$ git switch -c agent/2026-09-26-cleanup

Travailler sur une branche garde votre historique principal propre : si toute la session était une erreur, vous revenez en arrière et supprimez la branche. Quand l’agent a fini, lisez ce qu’il a changé :

# quels fichiers ont changé, et dans quelle mesure
$ git status$ git diff --stat
 
# lire les changements mot par mot, ce qui convient mieux à la prose que les lignes entières
$ git diff --word-diff
 
# garder les blocs avec lesquels vous êtes d’accord (y = garder, n = passer, s = découper, e = modifier)
$ git add -p$ git commit -m "Keep claude-code edits to pricing notes"
 
# jeter tout ce que vous n’avez pas gardé
$ git restore .
 
# de retour sur main, intégrer ce que vous avez approuvé
$ git switch main$ git merge agent/2026-09-26-cleanup

git add -p est ce qui en fait une vraie relecture. Il vous fait passer en revue chaque bloc modifié et vous laisse l’indexer ou le passer : vous pouvez ainsi garder la nouvelle note et écarter la réécriture non demandée d’une ancienne. Appuyez sur s pour découper un gros bloc en blocs plus petits et sur e pour en modifier un à la main.

Mettez le nom de l’agent dans le message de commit. git log vous dit alors quelle session a écrit quoi, et git log -p -- path/to/note.md montre l’historique complet d’une note.

Dans Knowtarium

Dans Knowtarium, chaque changement d’agent est enregistré comme une nouvelle version signée avec la propre clé de l’agent : l’historique de la note liste donc chaque version avec son auteur et sa date, See changes montre la modification de l’agent sous forme de diff, et Undo restaure la version précédente. Pour les dossiers que vous voulez lire d’abord, activez la relecture (« Ask me first ») : les changements des agents y attendent sous forme de diffs jusqu’à ce que vous les approuviez, ou que vous les rejetiez avec un commentaire.

(s’ouvre en grand dans un nouvel onglet) (s’ouvre en grand dans un nouvel onglet)

Si vous utilisez Claude Code, trois de ses fonctions vous aident. Aucune ne remplace git, mais elles repèrent les problèmes plus tôt.

Les modes de permission

Un mode de permission décide de ce que Claude peut faire sans demander. En mode Manual (valeur de configuration default), il demande avant de modifier des fichiers. acceptEdits le laisse modifier sans demander, ce qu’Anthropic suggère si vous préférez relire ensuite avec git diff. Le mode plan fait étudier et proposer des changements à Claude sans les appliquer tant que vous n’avez pas approuvé le plan. Appuyez sur Shift+Tab pour passer d’un mode à l’autre pendant une session. Les versions récentes démarrent les sessions interactives en mode auto, où un classifieur examine les actions à votre place : passez donc en mode Manual ou plan pour les sessions dans des notes auxquelles vous tenez.

Les checkpoints

Claude Code enregistre un checkpoint avant chaque prompt que vous envoyez. Lancez /rewind, ou appuyez deux fois sur Esc avec un prompt vide, pour restaurer les fichiers, la conversation, ou les deux. Connaissez-en les limites : les checkpoints ne suivent pas les fichiers modifiés par des commandes shell comme mv ou rm, ne restaurent en général pas les modifications faites par des sous-agents, et sont supprimés au bout d’environ 30 jours par défaut. La documentation d’Anthropic le dit clairement : les checkpoints ne remplacent pas un système de gestion de versions.

Les règles de permission

Les règles de .claude/settings.json bloquent ou encadrent les modifications de certains dossiers. Les règles deny l’emportent sur tout le reste et s’appliquent dans tous les modes :

{
  "permissions": {
    "ask": ["Edit(/decisions/**)"],
    "deny": ["Edit(/journal/**)", "Edit(/people/**)"]
  }
}

Ici, Claude ne peut jamais modifier journal/ ni people/, et il doit demander avant de toucher à decisions/. Les règles Edit couvrent les outils de fichiers intégrés de Claude et les commandes de fichiers qu’il reconnaît dans le shell, mais pas un script qui ouvre lui-même des fichiers. Pour une garantie stricte, Anthropic renvoie à son sandbox.

La plupart des agents lisent un fichier d’instructions avant de commencer : AGENTS.md pour Codex, Cursor et beaucoup d’autres, CLAUDE.md pour Claude Code. Mettez-y vos règles de modification. Gardez-les courtes et assez concrètes pour pouvoir les vérifier :

## Modifier des documents
 
- Ne supprime jamais un document. Mets `status: deprecated` et explique pourquoi.
- Ne modifie jamais les fichiers de journal/ ou de people/.
- Ne réécris pas un paragraphe qu’on ne t’a pas demandé de changer.
- Signe chaque document que tu écris dans `generated`, avec ton nom et ta version.
- N’ajoute jamais d’entrée `human:` à `verified`. Seule une personne le fait.
- Termine la session par la liste de tous les fichiers que tu as créés, modifiés ou déplacés.

La dernière règle est celle qui sert à la relecture : une liste de chaque fichier touché, que vous pouvez comparer à git status. Si elles diffèrent, regardez de plus près.

Les instructions sont du contexte, pas un verrou. La documentation d’Anthropic décrit CLAUDE.md comme quelque chose que Claude lit, pas comme une configuration qu’il applique de force, et c’est pour cela que les règles de permission ci-dessus existent. Notre guide AGENTS.md et CLAUDE.md pour une base de connaissances propose un modèle complet.

Sous macOS et Linux, vous pouvez aussi mettre un dossier en lecture seule avec chmod -R a-w journal/. Voyez-le comme un ralentisseur : un agent qui peut lancer des commandes shell peut aussi rétablir les permissions.

Un diff vous dit ce qui a changé aujourd’hui. Il ne dit pas au lecteur du mois prochain si quelqu’un a vérifié une note. Pour cela, écrivez-le dans la note elle-même. L’Open Knowledge Format (OKF), une spécification ouverte publiée par Google Cloud, a des champs exactement pour cela :

---
type: Decision
title: Passer la facturation aux offres annuelles
generated: { by: claude-code/2.1, at: 2026-09-26T09:12:00Z }
verified:
  - { by: human:maya, at: 2026-09-26T11:40:00Z }
stale_after: 2027-03-31T00:00:00Z
---

• generated indique qui a écrit le contenu actuel, et quand. Les agents signent sous la forme name/version, les personnes sous la forme human:name.
• verified liste tous ceux qui l’ont vérifié depuis, avec l’heure. Un document sans entrée est unverified, un document vérifié seulement par des agents ou des processus est machine-confirmed, et un document vérifié par un acteur human: est human-reviewed.
• stale_after est le moment où l’on ne peut plus citer le document sans risque.

La routine est simple. L’agent écrit et signe generated, jamais verified. Vous relisez le diff, puis vous ajoutez votre propre entrée verified. Une fois cela en place, retrouver ce que personne n’a vérifié tient en une commande :

# les documents que personne n’a encore vérifiés : aucune ligne verified
$ grep -rL "^verified:" --include="*.md" .

1. Faites un commit, puis créez une branche pour la session.
2. Lancez l’agent en mode Manual ou plan, avec des règles deny pour les dossiers qu’il ne doit jamais toucher.
3. Donnez-lui une seule tâche. Demandez la liste des fichiers touchés à la fin.
4. Comparez cette liste à git status, puis lisez git diff --word-diff.
5. Gardez ce avec quoi vous êtes d’accord avec git add -p, et restaurez le reste.
6. Ajoutez votre entrée verified à chaque note que vous avez vérifiée, faites un commit avec le nom de l’agent dans le message, et fusionnez.

Chaque outil repère quelque chose de différent :

Pour quelques dizaines de notes et un seul agent, git et cette routine peuvent suffire. Cela devient fastidieux quand des agents écrivent tous les jours, quand un changement touche dix notes, ou quand votre propre modification rend cinq autres notes fausses sans que vous le remarquiez. C’est pour cette partie que Knowtarium est conçu : chaque changement d’agent est signé et annulable en un clic, et là où vous activez la relecture, les changements des agents vous attendent et vos propres modifications attendent que vous demandiez à un agent de les vérifier.

Knowtarium intègre la routine ci-dessus dans une base de connaissances chiffrée de bout en bout. Vos agents se connectent via MCP et travaillent sur les mêmes documents OKF, et l’application vous montre ce qu’ils ont fait et ce qui mérite encore un coup d’œil. La relecture existe en deux intensités : l’annulation de chaque changement par défaut, et l’approbation préalable là où vous la demandez.

Chaque changement signé et annulable

Par défaut, le changement d’un agent est enregistré aussitôt comme la version suivante du document, signé avec la propre clé de l’agent. Un point dans la barre latérale signale les documents qu’il a modifiés jusqu’à ce que vous les ouvriez, une ligne sous le titre indique quel agent et quand, avec un lien vers les changements et un Undo, et la page de l’espace de travail liste ce que les agents ont modifié ces 14 derniers jours. Undo restaure la version précédente comme un changement à votre nom, et l’historique garde chaque version à restaurer aussi longtemps que vous le réglez (30 jours au départ, jusqu’à un an).

Ask me first : les diffs, puis l’approbation

Activez la relecture pour un espace de travail ou un dossier, et les changements des agents y attendent alors sous forme de propositions. Ouvrez-en une et vous voyez le diff, avec le résumé de l’agent et qui l’a proposé. Approuvez-la, rejetez-la avec un commentaire, ou approuvez-en plusieurs à la fois. Approuver vous ajoute à verified avec l’heure : c’est l’entrée human: que vous auriez sinon tapée à la main. La proposition de l’agent porte déjà sa propre vérification : une fois que vous l’approuvez, la note est donc entièrement vérifiée.

(s’ouvre en grand dans un nouvel onglet) (s’ouvre en grand dans un nouvel onglet)

Dans ces dossiers, une seule file rassemble tout ce qui attend une vérification :

• les changements proposés par un agent, qui vous attendent ;
• les modifications que vous avez faites, qui attendent la vérification d’un agent ;
• les conflits qu’un agent a trouvés en vérifiant.

Les documents qui ont dépassé leur date stale_after, et ceux qui arrivent à échéance, sont listés sur la page Stale and expiring, où qu’ils se trouvent.

Des vérifications dans les deux sens

Dans les dossiers où la relecture est activée, elle marche aussi dans l’autre sens. Quand vous modifiez vous-même un document, la modification est signée à votre nom et attend dans la file jusqu’à ce qu’un agent la compare à chaque document lié. Knowtarium n’appelle aucune IA lui-même : vous demandez à votre agent de vérifier les modifications du jour, et il enregistre sa vérification, ou signale un conflit partout où quelque chose ne concorde plus.

Les niveaux de confiance

Dans les dossiers où la relecture est activée, chaque document a un niveau de confiance :

Les mêmes règles valent pour chaque agent : les agents ne peuvent rien marquer comme vérifié par une personne, ils ne suppriment un document que si vous leur en avez donné la permission, et dans les dossiers où la relecture est activée, ils ne peuvent pas passer outre votre relecture. Vos documents sont chiffrés de bout en bout : nous ne pouvons donc pas les lire ; les agents que vous connectez voient ce qu’ils lisent. Voir les fonctionnalités et la façon dont les agents se connectent.