Claude Code auto memory ou Obsidian : contexte vérifiable

Pour des préférences personnelles, commencez avec l’auto memory de Claude Code. Pour les décisions que l’équipe doit discuter et transporter entre outils, préférez des notes Markdown distinctes avec un responsable et une source. Obsidian peut servir d’éditeur à ce dépôt ; son installation ne relie pas, à elle seule, les notes à l’agent.

Il n’est pas nécessaire de choisir une méthode unique pour toute information. Répartissez le contexte selon la personne responsable de l’exactitude. Une préférence peut rester dans une mémoire privée ; une décision de migration doit vivre dans une note commune liée à la décision. Vérifiez dans le dépôt les chemins et commandes déjà présents dans le code, afin de ne pas entretenir une copie supplémentaire des faits.

Ce qui est réellement stocké

La documentation Claude Code décrit l’auto memory comme des fichiers Markdown locaux au projet. Vous pouvez les ouvrir, modifier et supprimer par /memory. Les worktrees d’un même dépôt Git partagent la mémoire, mais celle-ci ne passe pas automatiquement d’une machine à l’autre. La commande /context permet de contrôler les memory files chargés. La présence d’une note sur le disque ne prouve pas que son contenu soit dans la session en cours.

Un vault Obsidian est un dossier de notes et de réglages. Les fichiers Markdown ordinaires restent disponibles hors de l’application. Pour que l’agent les utilise, indiquez les fichiers à lire et donnez-lui accès. Cette méthode ne demande ni plugin Obsidian ni serveur MCP.

Question	Auto memory	Vault Markdown séparé
Qui propose le contenu ?	Claude pendant le travail ; une personne vérifie	Auteur de la note ou agent chargé explicitement
Qui corrige un fait contesté ?	Utilisateur du projet	Responsable désigné de la décision
Comment montrer un changement ?	Partager l’entrée choisie	Partager le fichier ou un Git diff validé
Comment passer à une autre machine ?	Organiser le transfert	Organiser l’accès ou la synchronisation
Où repérer une information périmée ?	Dans les notes enregistrées	Dans la source et la date de prochaine revue

La colonne de droite propose une organisation de travail. Ouvrir un dossier dans Obsidian ne crée pas automatiquement Git, un responsable ni une date de revue.

Préparez une connexion modèle pour tester la mémoire

Pour tester les deux méthodes dans Claude Code via API, BetterToken fournit une connexion compatible Anthropic. Configurez le client avec le guide BetterToken pour Claude Code : utilisez votre API Key et la Base URL https://bettertoken.ai sans /v1, redémarrez le client, puis obtenez une réponse à un court message. Cela vérifie l’accès au modèle ; les étapes suivantes vérifient les notes.

Gardez la même model et la même tâche : faites d’abord lire l’enregistrement, modifiez-le, puis répétez la question dans une nouvelle session. Le changement de connexion ne devient ainsi pas une variable de l’essai. BetterToken fournit les appels API ; auto memory et vault restent gérés par votre outil. Les extraits lus par l’agent peuvent figurer dans la requête au modèle : utilisez donc une note pédagogique non secrète et ne placez pas l’API Key dans le vault.

Configurez Claude Code avec BetterToken et testez une note, puis passez à l’exemple.

Donnez à chaque fait un emplacement principal

Commencez avec une note non secrète. Dans cet exemple, l’équipe discute du format d’export ; les valeurs et noms sont fictifs. Enregistrez decisions/report-export.md :

# Report export decision

Status: proposed
Owner: reporting-team
Verified: 2026-09-08
Review-by: 2026-09-22
Source: team decision record to be attached

The proposed export format is CSV.
This is not an approved production requirement.
Before implementation, ask the owner for the approved decision.

Cette formulation distingue une proposition d’une exigence obligatoire. Dans un projet réel, indiquez une source accessible : tâche, compte rendu ou document de décision. Tant que la confirmation manque, l’agent doit conserver l’incertitude.

Envoyez cette tâche précise dans une nouvelle session :

Read decisions/report-export.md.
What export format is proposed, and is it approved for production?
Cite the file and identify the missing evidence.
Do not change code or infer approval from the proposal.

Le résultat attendu est : CSV est proposé, aucune approbation de production n’existe et la source de décision manque. C’est un critère de vérification, pas une promesse de réponse correcte. Si l’agent propose d’implémenter CSV, regardez le fichier lu et cité : une note en double, une ancienne conversation ou une mauvaise lecture du statut est possible.

Vérifiez la mise à jour et la suppression

Modifiez la note pédagogique : le format devient JSONL et le statut reste proposed. Ouvrez une nouvelle session et répétez la question. L’agent doit indiquer JSONL et la même limite. S’il répond CSV, n’ajoutez pas une règle contradictoire ; retrouvez la source de l’ancienne valeur.

Supprimez ensuite la note avec le gestionnaire de fichiers et demandez, dans une autre session, où se trouve la décision confirmée. Sans autre source, signaler le manque de données est utile. Une réponse avec l’ancienne valeur indique une autre copie ou une autre source : vérifiez /memory, les fichiers du projet et les instructions.

Supprimer une note ne l’efface pas automatiquement de l’historique Git, des sauvegardes, des appareils synchronisés ou d’une conversation déjà ouverte. Ce test concerne une nouvelle session, pas l’effacement complet des données. N’incluez ni API keys, ni mots de passe, ni données personnelles dans l’exercice.

Adaptez le mode au coût de l’erreur

Si vous travaillez seul et que la mémoire contient surtout des préférences, gardez l’auto memory et relisez les entrées après des changements importants. Quand une action de l’équipe dépend d’un fait, placez sa version principale dans un document contrôlé. L’auto memory peut seulement indiquer où chercher la source actuelle, sans recopier la décision.

Au besoin, désactivez l’auto memory par /memory ; le paramètre officiel autoMemoryEnabled contrôle cette fonction. La désactivation ne remplace pas la vérification des fichiers existants et du contexte déjà chargé.

Dans un vault d’équipe, attribuez un responsable aux entrées importantes et un événement de revue : changement d’API, abandon du projet ou fin de migration. Une date aide à trouver les notes oubliées, sans créer une expiration automatique. Avec Git, relisez les fichiers précis avant le commit ; n’ajoutez pas tout le dossier avec réglages personnels et pièces jointes.

Commencez avec une décision et trois questions en nouvelles sessions : ce qui est connu, ce qui a changé et ce qui n’est plus confirmé. Si les réponses citent les fichiers actuels et gardent l’incertitude, cette méthode répond au besoin. Sinon, corrigez d’abord la source et l’ordre de lecture ; changer seulement d’éditeur ne résout pas les contradictions.