Mémoire interprojets Claude Code : guide en 3 niveaux

Une session Claude Code connaît le dépôt ouvert, mais oublie souvent la décision prise hier dans un autre dépôt ou réapplique une procédure au mauvais projet.

La solution la plus fiable est une architecture en trois niveaux : CLAUDE.md pour les faits stables, Claude Code Skills pour les procédures réutilisables, et un composant Agent Memory externe pour les préférences ou états de tâche qui doivent survivre aux sessions. Cette organisation évite de transformer tout l’historique en invite globale et limite les erreurs de contexte.

Cet article s’adresse aux développeurs qui maintiennent plusieurs dépôts, aux responsables qui veulent partager des conventions sans partager les données métier, et aux équipes qui préparent un environnement d’Agent Code durable, isolé et restaurable.

Dernière mise à jour : 10 août 2026. Les mécanismes de fichiers, de portée et de chargement ont été vérifiés dans la documentation officielle de Claude Code et doivent être retestés après chaque mise à niveau.

Pourquoi une mémoire unique finit par produire de mauvaises décisions

Le premier piège consiste à appeler « mémoire » des mécanismes très différents. Un fichier chargé au démarrage n’est pas une mémoire autobiographique du modèle. Une procédure décrite dans un Skill n’est pas une préférence personnelle. Une base externe contenant les décisions passées n’est pas automatiquement fiable parce qu’elle a été consultée auparavant.

Trois coûts apparaissent rapidement lorsque tout est mélangé :

• Le coût du contexte inutile. Une longue liste de commandes de livraison, de conventions de test et de décisions historiques est injectée alors que la session travaille peut-être uniquement sur une miniature vidéo ou un composant audio.
• Le risque de contamination entre dépôts. Une règle valable pour le projet fictif AtelierAudio peut être appliquée par erreur au projet fictif StudioVisuel, alors que les deux utilisent des systèmes de livraison différents.
• Le risque de divulgation. Une mémoire globale peut conserver un nom de client, un extrait de code propriétaire, une URL interne ou une information d’incident qui ne devrait jamais sortir de son périmètre.

Il faut également distinguer le rechargement de configuration de la mémoire permanente. Claude Code peut lire à nouveau un CLAUDE.md lorsqu’une nouvelle session démarre, mais ce comportement ne prouve pas que l’agent se souvient des conversations précédentes. La documentation officielle décrit des emplacements de mémoire et leur chargement ; elle ne doit pas être interprétée comme une promesse de mémoire universelle entre tous les dépôts et toutes les sessions. La commande /memory permet notamment d’inspecter les fichiers chargés. Documentation officielle sur la gestion de la mémoire Claude Code

Avant toute configuration, chaque équipe devrait classer les informations selon cette règle :

Type d’information	Emplacement recommandé	Exemple acceptable	À ne pas y placer
Fait stable du dépôt	CLAUDE.md du projet	Architecture, commandes de test, conventions de nommage	Historique complet des tickets
Procédure réutilisable	Skill avec SKILL.md	Revue de code, préparation d’une livraison, export audio	Secrets ou données client
Préférence ou état évolutif	Agent Memory externe isolé	Préférence de format, tâche interrompue, décision datée	Code source confidentiel en clair

Cette grille constitue le premier outil de décision : si l’information change rarement et concerne le dépôt, elle appartient au projet ; si elle décrit une action répétable, elle appartient à un Skill ; si elle évolue au fil des sessions, elle peut relever d’une mémoire externe, mais uniquement avec des contrôles d’accès.

Première étape : stabiliser un seul dépôt avec CLAUDE.md

La configuration doit commencer par un dépôt unique, même si l’objectif final concerne plusieurs projets. Dans le dépôt fictif AtelierAudio, il est préférable de créer un CLAUDE.md court contenant :

# AtelierAudio

## Architecture
- Le traitement audio est séparé du module d’export.
- Les composants d’interface ne doivent pas accéder directement au stockage.

## Commandes
- Tests unitaires : `npm run test`
- Vérification de style : `npm run lint`
- Construction : `npm run build`

## Contraintes
- Ne jamais modifier les fichiers d’échantillons sans validation.
- Toute modification du pipeline audio doit comporter un test de régression.

Le fichier doit répondre à une question précise : quelles informations Claude Code doit-il connaître dès qu’il entre dans ce dépôt ? Les commandes de construction, les conventions réellement obligatoires et les frontières d’architecture sont de bons candidats. Une description exhaustive de chaque procédure de livraison ne l’est pas.

La commande /init peut aider à produire un premier fichier, mais le résultat doit être relu, simplifié et validé par un développeur. La documentation officielle recommande notamment d’y conserver les commandes fréquentes, les conventions de code et les schémas d’architecture importants. Guide officiel de démarrage et d’initialisation d’un projet

Pour les préférences personnelles, il est possible d’utiliser une mémoire utilisateur ou d’importer un fichier séparé. Les importations @chemin/vers/fichier peuvent être imbriquées, avec une profondeur maximale documentée de 5 niveaux ; ce chiffre est une limite de fonctionnement à vérifier dans la documentation correspondant à la version installée. Règles officielles de recherche et d’importation des fichiers de mémoire

La validation doit se faire dans une nouvelle session, et non uniquement dans la session qui vient de créer le fichier :

• [ ] Ouvrir le dépôt depuis son répertoire racine.
• [ ] Lancer Claude Code dans une session neuve.
• [ ] Demander une synthèse de l’architecture sans fournir manuellement le contenu du fichier.
• [ ] Demander les commandes de test et vérifier qu’elles correspondent au dépôt.
• [ ] Poser une question volontairement ambiguë afin de vérifier que les contraintes sont appliquées avec prudence.
• [ ] Contrôler que le fichier ne contient aucun secret, identifiant client ou extrait propriétaire inutile.

Si Claude Code cite une commande inexistante ou confond le module audio avec le module d’export vidéo, il ne faut pas ajouter immédiatement davantage de texte. Il faut d’abord supprimer les formulations ambiguës, puis refaire le test. Un CLAUDE.md plus long ne corrige pas toujours un classement incorrect de l’information.

Deuxième étape : transformer les opérations répétées en Claude Code Skills

Les Skills doivent contenir des actions que l’agent peut exécuter ou suivre à la demande. Une procédure de revue de code, de préparation d’une version, de contrôle des tests ou de validation d’un rendu vidéo est mieux placée dans un SKILL.md que dans la mémoire permanente du projet.

Un Skill de revue peut prendre une forme volontairement explicite :

---
name: revue-atelier-audio
description: Vérifie les changements audio, les tests associés et les risques de régression avant une revue de code.
---

# Revue du projet AtelierAudio

1. Examiner le diff sans modifier les fichiers.
2. Identifier les changements dans le traitement du signal.
3. Vérifier la présence d’un test de régression.
4. Exécuter les commandes autorisées du projet.
5. Résumer les risques avec les chemins de fichiers concernés.
6. Demander confirmation avant toute modification.

La description est importante : elle doit indiquer quand le Skill est pertinent, pas seulement son nom. « Revue » est trop vague ; « vérifie les changements audio et les tests de régression avant une revue de code » fournit à l’agent un signal de sélection plus utile.

La portée doit ensuite être documentée et testée. Une organisation typique distingue :

• les Skills propres au projet, versionnés avec le dépôt ;
• les Skills personnels, utiles à un développeur sur plusieurs dépôts ;
• les Skills distribués par un plugin ou une configuration d’équipe.

La priorité exacte dépend de la version et du mode d’installation utilisés. Il est donc préférable de consulter la documentation officielle correspondant à l’édition active avant de figer une hiérarchie de fichiers. La référence officielle de la ligne de commande Claude Code permet également de vérifier les commandes de diagnostic, de reprise de session et les options d’exécution non interactive.

Le second tableau aide à décider où placer un processus :

Besoin opérationnel	Projet	Personnel	Équipe ou plugin
Construire un dépôt particulier	Oui	Non	Seulement si la procédure est standardisée
Revue de code commune	Possible	Possible	Souvent préférable
Export audio propre à un client	Oui, avec données génériques	Non	Non, si le contenu est confidentiel
Vérification vidéo récurrente	Oui si les outils diffèrent	Oui si la méthode est personnelle	Oui si toute l’équipe suit le même contrôle
Déploiement en production	Oui pour les contraintes locales	Non	Oui pour le cadre commun, avec garde-fous locaux

Une modification de Skill doit être testée dans une session neuve et, lorsque la version le permet, après un rechargement à chaud. Le test ne consiste pas seulement à demander « le Skill est-il disponible ? ». Il faut lancer une tâche réaliste : préparer une revue, contrôler un rendu vidéo ou simuler une livraison, puis vérifier que le bon Skill est sélectionné et que les règles du dépôt restent prioritaires.

Troisième étape : n’ajouter Agent Memory qu’en cas de besoin réel

Une mémoire externe devient pertinente lorsque le développeur doit conserver une préférence durable, reprendre une tâche interrompue ou retrouver une décision prise dans plusieurs dépôts. Elle ne doit pas servir de décharge à toutes les conversations.

Un enregistrement utile ressemble davantage à ceci :

{
  "project_id": "atelier-audio",
  "user_id": "developpeur-07",
  "type": "decision",
  "content": "Le projet conserve le format WAV pour les fichiers intermédiaires.",
  "source": "session-2026-08-10-atelier-audio",
  "created_at": "2026-08-10",
  "expires_at": null
}

Même dans cet exemple fictif, la mémoire conserve un identifiant de projet, un utilisateur et une source. Elle ne contient ni clé d’accès, ni transcription complète, ni extrait de code client. La date sert à retrouver l’origine de la décision ; elle ne transforme pas cette décision en vérité permanente.

La couche Agent Memory doit appliquer au minimum quatre contrôles :

1. Identifiant de projet obligatoire. Une entrée sans projet associé ne doit pas être rappelée dans un dépôt arbitraire.
2. Séparation des utilisateurs. Les préférences personnelles ne doivent pas devenir des règles d’équipe.
3. Traçabilité. Chaque souvenir doit indiquer sa source, son âge et, si possible, la décision ou la session qui l’a produit.
4. Suppression vérifiable. Une équipe doit savoir supprimer une entrée, un projet entier ou toutes les données d’un utilisateur.

Les informations sensibles doivent rester hors de cette couche : secrets, jetons, données personnelles, code client, chemins internes révélateurs et détails d’incident. Les outils externes connectés à Claude Code peuvent également élargir le périmètre des données accessibles ; le guide officiel sur MCP rappelle que ces serveurs peuvent relier l’agent à des outils, bases de données et API. Le raccordement doit donc être traité comme une extension de privilèges, pas comme une simple fonction de confort.

Pour une équipe, il faut aussi décider où s’effectue le contrôle réseau. La documentation officielle indique que Claude Code prend en charge les variables de proxy HTTP et HTTPS, mais pas les proxys SOCKS ni la variable NO_PROXY. Configuration officielle des proxys d’entreprise Cela peut changer la manière dont une mémoire externe est isolée dans un réseau d’entreprise.

Questions fréquentes sur la mémoire entre projets

Claude Code se souvient-il automatiquement des anciens projets ?

Claude Code peut recharger des fichiers de mémoire disponibles dans le contexte courant, mais ce mécanisme ne signifie pas qu’il conserve automatiquement l’historique de tous les projets. Un CLAUDE.md partagé contient des instructions ; il ne restitue pas une conversation passée. Pour reprendre une tâche ou retrouver une préférence, il faut utiliser une session reprise, un fichier explicitement importé ou une couche Agent Memory externe avec isolation.

Que faut-il mettre dans CLAUDE.md et que faut-il réserver aux Skills ?

CLAUDE.md doit rester centré sur les faits stables : architecture, commandes, conventions et limites du dépôt. Les Skills conviennent aux procédures déclenchées selon le besoin, comme une revue de code, une validation de rendu ou une préparation de livraison. Si une procédure est copiée dans tous les projets, elle devient difficile à maintenir et augmente le risque de divergences silencieuses.

Comment partager une configuration Claude Code entre plusieurs dépôts ?

Le partage doit commencer par les règles réellement communes, par exemple une convention de revue ou une politique de test. Les contraintes propres au dépôt restent dans son propre CLAUDE.md. Une mémoire utilisateur ou un fichier importé peut porter des préférences personnelles, mais il faut tester chaque dépôt afin de détecter les conflits de nommage, de commande ou d’outillage.

Comment éviter qu’une mémoire interprojets expose du code confidentiel ?

Il faut refuser par défaut les secrets, les transcriptions complètes et les extraits de code dans la mémoire globale. Chaque entrée doit être liée à un projet et à un utilisateur, avec une source et une règle de suppression. Les journaux, les serveurs MCP, les proxys et les sauvegardes doivent suivre la même politique d’accès que le dépôt source, car une fuite peut se produire en dehors du fichier de mémoire lui-même.

Quatrième étape : tester l’isolation comme un changement de production

Une architecture de mémoire n’est terminée que lorsqu’elle résiste aux erreurs de contexte. Le test doit utiliser au moins deux dépôts fictifs, par exemple AtelierAudio et StudioVisuel, avec des conventions incompatibles mais des tâches comparables.

Dans AtelierAudio, la tâche peut demander une vérification du pipeline de traitement sonore. Dans StudioVisuel, elle peut demander un contrôle d’export vidéo. Les résultats doivent montrer que :

• les règles communes sont disponibles dans les deux dépôts ;
• les contraintes propres à AtelierAudio ne sont pas rappelées dans StudioVisuel ;
• le Skill audio ne s’active pas pour une tâche vidéo ;
• une préférence personnelle ne devient pas une règle d’équipe ;
• un redémarrage ne supprime pas les données qui doivent être persistantes ;
• une entrée supprimée ne réapparaît pas par une sauvegarde ou un index secondaire.

La commande /memory est utile pour vérifier les fichiers chargés, tandis que les options de reprise comme --continue ou --resume servent à distinguer la continuité d’une session de la mémoire d’un nouveau projet. Ces commandes sont documentées dans la référence officielle de l’interface en ligne de commande.

Un contrôle de sécurité doit aussi inspecter le contenu transmis par les outils et les journaux. Anthropic documente notamment les comportements liés aux rapports d’erreur, à la télémétrie et à la commande /bug dans son document officiel sur l’utilisation des données. Les équipes qui traitent du code sensible doivent vérifier ces réglages dans leur propre environnement plutôt que supposer qu’un fichier local suffit à empêcher toute transmission.

Cinquième étape : préparer la sauvegarde et la migration

La migration doit couvrir les trois couches, mais pas de la même manière.

Le CLAUDE.md versionné suit normalement le dépôt. Les Skills d’équipe doivent être sauvegardés avec leur documentation, leurs tests et leur responsable. La mémoire externe doit disposer d’une exportation structurée contenant au minimum l’identifiant du projet, l’utilisateur, la source, la date de création, la date d’expiration et le statut de suppression.

Avant une mise à niveau de Claude Code ou du composant de mémoire :

• [ ] Exporter les fichiers de configuration et les Skills.
• [ ] Sauvegarder la base de mémoire sans inclure de secrets inutiles.
• [ ] Noter les versions utilisées et les chemins de chargement.
• [ ] Rejouer une tâche audio, une tâche vidéo et une tâche de revue de code.
• [ ] Vérifier les conflits entre règles personnelles, projet et équipe.
• [ ] Tester un redémarrage complet de l’environnement.
• [ ] Vérifier que les données supprimées restent absentes.
• [ ] Conserver le résultat de la régression pour comparaison.

Claude Code nécessite officiellement une connexion réseau pour l’authentification et le traitement, ainsi que Node.js 18 ou une version ultérieure dans le guide de démarrage consulté. Le même document indique une exigence minimale de 4 Go de mémoire vive pour l’environnement présenté. Ces paramètres concernent l’installation documentée, pas une garantie de performance pour un projet donné ; les besoins réels dépendent du dépôt, des outils et des tâches exécutées. Prérequis officiels de Claude Code

Pour les développeurs qui alternent entre plusieurs machines, un environnement Mac distant peut simplifier la continuité : même arborescence, mêmes outils, mêmes fichiers de configuration et même procédure de redémarrage. La présentation des environnements Mac de Zutcloud doit toutefois être évaluée selon la durée d’utilisation, la nécessité d’accéder à des périphériques physiques et les contraintes de confidentialité du projet.

La répartition recommandée pour une équipe multi-dépôts

La configuration la plus saine peut être résumée ainsi :

Dépôt
├── CLAUDE.md
│   ├── architecture
│   ├── commandes
│   └── contraintes locales
│
├── Skills
│   ├── revue de code
│   ├── tests
│   └── livraison
│
└── Agent Memory externe
    ├── préférences datées
    ├── décisions de tâche
    └── reprise de session avec projet et utilisateur

La répartition ne doit pas être appliquée mécaniquement. Un projet très confidentiel peut refuser toute mémoire externe et conserver uniquement des règles versionnées. À l’inverse, une équipe qui fait fonctionner un Agent Code en continu peut avoir besoin d’une mémoire durable, mais elle devra alors investir dans l’authentification, les journaux, les sauvegardes et les règles de suppression.

Le point de bascule est simple : si l’information doit être vraie pour chaque session du dépôt, elle va dans CLAUDE.md ; si elle décrit une action répétable, elle va dans un Skill ; si elle représente un état qui change au fil des tâches, elle peut aller dans Agent Memory, avec un périmètre strict.

Quand un Mac distant devient plus cohérent que le poste local

Pour un essai court, un poste local reste souvent le choix le plus simple. En revanche, les équipes qui doivent maintenir un Agent Code actif, reproduire un environnement pour plusieurs personnes ou redémarrer rapidement après une interruption rencontrent généralement trois limites avec un ordinateur personnel : la machine n’est pas toujours disponible, l’environnement change entre les utilisateurs et la sauvegarde des configurations reste souvent artisanale.

Un Mac distant ne règle pas automatiquement la gouvernance de la mémoire ; il fournit surtout un environnement stable à condition que les dépôts, les Skills et les données dynamiques soient séparés correctement. Il est moins adapté aux charges longues et constantes lorsque l’achat d’une machine dédiée est économiquement plus cohérent, ou lorsque le projet exige un accès physique permanent à des périphériques spécialisés.

Pour une expérimentation, une migration ou une équipe qui veut isoler un environnement de développement sans immobiliser immédiatement du matériel, la documentation d’aide de Zutcloud permet de vérifier les modalités opérationnelles avant de choisir une durée. Pour un besoin particulier d’accès, d’isolation ou de livraison, la page de contact de Zutcloud constitue le point de clarification approprié.

La décision ne devrait donc pas être « mémoire globale ou aucune mémoire ». Elle devrait être : règles stables dans CLAUDE.md, procédures autonomes dans Claude Code Skills, états dynamiques dans Agent Memory lorsque le besoin est démontré, puis validation par redémarrage, séparation des projets et restauration. Cette méthode réduit les rappels erronés sans prétendre que la simple relecture d’un fichier donne à Claude Code une mémoire permanente.

À lire aussi

• Concevoir un système de fichiers sécurisé pour les agents IA
• Mémoire d’agent : comparer l’auto-hébergement et le SaaS
• Calculer le coût mensuel réel de Claude Code