Mémoire Claude Code : les 6 niveaux expliqués

Mémoire Claude Code : les 6 niveaux expliqués

J'ai failli casser toute mon opération de contenu mardi dernier en upgradant mon système de mémoire à un niveau dont je n'avais pas besoin.

Le setup qui fait tourner mon business : 232 articles publiés sur mejba.me, quatre voix de marque, un agent @aria qui écrit des articles de 3 000 mots d'une traite, et une couche mémoire qui doit retenir le ton de chaque marque, chaque cluster, chaque expression bannie, chaque modèle de pied de page. Pendant à peu près trois mois, cette couche mémoire n'était que deux fichiers markdown. Puis j'ai lu un fil affirmant que les « vrais » utilisateurs de Claude Code font tourner des palais de mémoire adossés à du RAG avec des index vectoriels, et j'ai passé un après-midi entier à essayer d'en câbler un.

À la fin de cet après-midi, j'avais cassé trois skills, corrompu l'auto-mémoire d'un projet, et produit exactement zéro nouveau contenu. Alors j'ai tout rollback, j'ai ouvert un doc vierge, et je me suis forcé à cartographier ce à quoi ressemble vraiment la mémoire Claude Code en 2026 — chaque niveau, ce que ça coûte, à qui c'est destiné. Pas en théorie. Sur la base de ce que j'ai vraiment fait tourner, ce que j'ai vu d'autres opérateurs faire tourner, et ce que j'ai vu partir en vrille.

Il y a six niveaux. La plupart des gens qui utilisent Claude Code n'ont jamais besoin de monter au-dessus du niveau trois. Quelques-uns en ont besoin. Choisir le mauvais niveau — trop simple ou trop complexe — c'est ce qui brûle des week-ends. Ce billet est la carte que j'aurais aimé avoir avant de commencer à grimper.

Pourquoi la mémoire Claude Code compte vraiment en 2026

Si vous utilisez Claude Code comme un autocomplete glorifié, la mémoire est sans intérêt. Ouvrez un onglet, tapez un prompt, fermez-le, fini. Le modèle n'a pas besoin de se souvenir de quoi que ce soit sur vous parce qu'il n'y a rien à retenir.

Mais à l'instant où votre workflow prend forme — tâches récurrentes, voix de marque, conventions de code, décisions que vous avez prises et que vous ne voulez pas réexpliquer chaque lundi — la mémoire devient le plus gros levier entre « Claude est utile parfois » et « Claude est un coéquipier ». Ce n'est pas du baratin marketing. C'est moi, en train de regarder le même agent passer de la génération d'articles SEO génériques à la maîtrise de ma voix de marque dès la première tentative, juste parce que je lui ai donné une couche de mémoire structurée dans laquelle puiser.

Le problème en 2026, c'est que « mémoire Claude Code » désigne désormais au moins six architectures différentes, allant d'un fichier markdown à la racine de votre projet à une base Postgres auto-hébergée avec des embeddings partagés entre Claude, ChatGPT et Cursor. La doc officielle couvre bien la première. La communauté a construit les cinq autres. Presque personne n'explique où chacune cesse de valoir la complexité.

C'est la question qui m'intéresse vraiment. Parce que chaque niveau au-dessus de celui dont vous avez besoin n'est que de la taxe — taxe d'ingénierie, taxe de débogage, taxe d'attention. Alors parcourons-les.

Niveau 1 : mémoire native basique (claude.md + memory.md)

C'est ce avec quoi Claude Code est livré. Pas de plugin. Pas de base vectorielle. Pas de hooks. Juste deux fichiers markdown que le modèle charge au démarrage de la session.

claude.md est votre fichier d'instructions au niveau projet. C'est vous qui l'écrivez. Il contient les règles, les conventions, les voix de marque, les expressions bannies, les chemins de fichiers — tout ce que vous voulez que le modèle sache à chaque ouverture de session dans ce répertoire. Selon la doc officielle de Claude Code, le fichier est chargé automatiquement dans le contexte et traité comme une consigne projet faisant autorité.

memory.md (aussi appelé auto-mémoire) est ce que Claude écrit à votre sujet. Quand vous le corrigez (« n'utilise pas de points-virgules dans cette base de code »), ou qu'il déduit une commande de build, ou qu'il apprend une préférence de workflow, il vous demande s'il doit le sauvegarder en mémoire. Vous approuvez. À la session suivante, il s'en souvient.

Ensemble, ces deux fichiers forment une couche de mémoire de travail qui coûte zéro dollar, tourne entièrement sur votre machine, et gère peut-être 70 % de ce dont a besoin un workflow de développeur seul ou d'opérateur solo. Mon claude.md principal pour le repo ai-agents-team fait environ 180 lignes. Il définit les quatre voix de marque, le format de sortie, les contraintes dures, l'arborescence. C'est tout. Pas de vecteurs. Pas d'embeddings. Pas de daemons.

Le piège — et c'est le piège dont personne ne vous prévient — c'est la pourriture de contexte (context rot). Quand claude.md dépasse environ 200 lignes, le modèle commence à le survoler. Des règles spécifiques sont ignorées. Les expressions bannies reviennent dans la sortie. Vous commencez à penser que le modèle est cassé, mais en fait, vous avez juste trop bourré le slot le plus prioritaire de la fenêtre de contexte. J'ai vu ça arriver à mon propre setup à trois reprises. Le correctif est toujours le même : scinder le fichier, ou déplacer les règles permanentes dans quelque chose de plus structuré.

À qui s'adresse le niveau 1 : à toute personne qui débute avec Claude Code. À toute personne dont l'ensemble du workflow tient dans un projet. À toute personne qui peut répondre à « qu'est-ce que cette IA doit savoir sur moi ? » en moins de 200 lignes. Si vous ne pouvez pas encore répondre à cette question, vous n'avez pas un problème de mémoire — vous avez un problème de clarté, et ajouter de l'infrastructure n'y changera rien.

Là où ça casse : la semaine où vous réalisez que vous maintenez sept fichiers claude.md différents sur sept projets, tous en train de répéter les mêmes règles centrales.

Niveau 2 : injection de mémoire enrichie (hooks + structure de dossiers)

C'est là que j'ai vécu pendant la majeure partie de 2026. C'est aussi là que se sont stabilisées la plupart des personnes que je respecte dans cet espace.

L'idée est simple. Au lieu d'un seul énorme claude.md, vous scindez la mémoire en une structure de dossiers — généralement trois compartiments :

• general/ — règles inter-projets. Voix, éthique, formatage de sortie.
• domain/ — mémoire spécifique à un domaine. SEO, copywriting, sécurité, design.
• tool/ — mémoire spécifique à un outil. Skills Claude Code, usage du MCP Figma, pièges Webflow.

Puis vous ajoutez un hook session-start — un script qui se lance à l'instant où Claude Code démarre. Le hook lit un index de vos dossiers de mémoire et n'injecte que la tranche pertinente dans le contexte. Besoin de SEO ? Le hook injecte la mémoire SEO. Vous travaillez sur un système de design ? Il tire la mémoire design et zappe le reste.

Les hooks ne sont pas des instructions en langage naturel — ce sont des scripts qui se déclenchent sur des événements. PreToolUse, PostToolUse, SessionStart, UserPromptSubmit. La doc officielle en 2026 est claire sur cette distinction, et c'est important : les hooks sont déterministes. Ils s'exécutent que le modèle « en ait envie » ou non. C'est tout l'intérêt.

Ce que vous gagnez au niveau 2 :

1. Pas de pourriture de contexte. Chaque tranche injectée reste petite et spécifique.
2. Partage en équipe. Votre dossier de mémoire n'est que du markdown — commitez-le dans git, votre coéquipier le clone, il récupère vos standards.
3. Rappel sélectif. Vous travaillez sur un projet Laravel ? La mémoire Figma ne se charge pas. Votre fenêtre de contexte reste propre.
4. Versionnage. La mémoire est désormais un artefact tracké, pas un effet de bord à l'exécution.

Le coût est d'un après-midi de setup. Vous écrivez la structure de dossiers, vous écrivez un petit script de hook (le mien fait 40 lignes de Bash plus une config JSON), vous le testez une fois, et puis ça tourne tout seul. Je couvre le pattern hook plus large dans mon décryptage sur l'automatisation des contrôles SEO avec les routines Claude Code — même architecture, application différente.

À qui s'adresse le niveau 2 : à toute personne qui utilise Claude Code depuis plus d'un mois. À toute personne dont le fichier mémoire a passé les 200 lignes. À toute personne qui travaille avec une équipe. À toute personne qui fait tourner des workflows multi-projets où les règles se chevauchent sans être identiques.

Là où ça casse : quand votre dossier de mémoire atteint une certaine taille — disons plus de 50 fichiers — et que le hook d'index commence à injecter trop de tranches « pertinentes », ou pire, manque la vraiment pertinente. À ce stade, le scoring de pertinence par mots-clés ne suffit plus. Il vous faut de la sémantique.

Niveau 3 : recherche vectorielle sémantique avec MemSearch

C'est le niveau auquel je suis actuellement, et le niveau auquel je recommande de s'arrêter sauf raison spécifique d'aller plus loin.

MemSearch est un système de mémoire markdown-first publié par Zilliz, l'équipe derrière Milvus. Leur propre description le qualifie de « bibliothèque autonome pour tout agent IA, inspirée par OpenClaw ». Le plugin Claude Code se pose au-dessus du CLI principal, et l'architecture est honnête sur ce qu'elle est : une couche de récupération hybride au-dessus de fichiers markdown ordinaires.

Voici ce qui est intéressant. MemSearch ne remplace pas vos fichiers de mémoire. Il les indexe. Votre mémoire continue à vivre comme du markdown lisible par un humain — vous pouvez l'éditer dans n'importe quel éditeur de texte, le versionner dans git, le lire en avion sans Internet. L'index vectoriel est un cache. Selon le billet de blog Milvus sur MemSearch, l'index « se reconstruit depuis le Markdown à tout moment ».

Trois couches de rappel :

1. Faits long terme — connaissances durables. Règles de voix de marque, politiques de sécurité, décisions architecturales.
2. Notes journalières — résumés de session avec timestamp, ID de session, ID de tour. Texte brut. Entièrement lisible par un humain.
3. Dreaming / promotion — compaction périodique où les notes court-terme sont promues en faits long-terme si elles s'avèrent durables.

La récupération utilise une recherche hybride — vecteurs sémantiques pour « trouver du contenu lié à cette requête même si la formulation diffère », plus BM25 pour « trouver du contenu qui utilise ces mots-clés exacts », fusionnés via un reranking par Reciprocal Rank Fusion (RRF). Ce dernier point est ce qui bat la recherche par mots-clés à l'échelle. Quand ma mémoire compte 400 fragments markdown répartis sur quatre marques, la recherche sémantique trouvera la règle de voix de marque colorpark.io même si j'ai formulé mon prompt avec des mots complètement différents de ceux du fichier mémoire. La recherche par mots-clés rate ça. Sémantique + BM25 + RRF attrape les deux.

Le rappel est aussi étagé, ce que j'adore :

• L1 (automatique) : top-3 résultats sémantiques avec aperçus, injectés à chaque prompt. Couvre la plupart des cas d'usage.
• L2 (à la demande) : sections markdown complètes quand le contexte intégral est nécessaire.
• L3 (profond) : enregistrements bruts de conversation quand vous avez besoin du dialogue exact d'une session passée.

Pour moi, L1 répond à environ 90 % de mes besoins. L2 se déclenche quand j'écris quelque chose de dense et qu'il me faut le profil de voix complet d'une marque. L3, je l'ai utilisé peut-être deux fois en deux mois — les deux fois pour retrouver la formulation exacte d'une décision client.

Le setup, c'est une installation de plugin plus un store vectoriel (Milvus tourne en local ; vous pouvez aussi le pointer vers du managé). Le coût, c'est votre temps à apprendre ce que fait chaque couche. La première semaine paraît sur-ingénieuriée. La deuxième semaine, vous arrêtez de le remarquer parce que ça marche, simplement.

À qui s'adresse le niveau 3 : aux opérateurs avec une mémoire accumulée substantielle — disons plus de 100 fichiers markdown, ou un an d'historique de sessions, ou des workflows multi-marques comme le mien. Aux fondateurs solo qui font tourner un business AI-first. À toute personne dont le setup niveau 2 a commencé à manquer la tranche pertinente sur les prompts complexes.

Là où ça cesse de suffire : quand vous avez besoin d'un rappel verbatim des conversations passées, pas de paraphrases sémantiquement similaires. Ou quand votre mémoire doit vivre ailleurs que sur votre laptop.

C'est aussi là que la plupart des opérateurs de contenu devraient honnêtement s'arrêter. J'ai testé les niveaux 4, 5 et 6, et j'ai rollback au niveau 3 à chaque fois — parce que le gain marginal de rappel ne valait pas la complexité opérationnelle pour mon vrai job, qui est de publier des articles. Si votre job est autre chose, le calcul peut basculer. Voyons quand.

Niveau 4 : rappel verbatim avec palais de mémoire (RAG)

C'est là où l'architecture mémoire commence à ressembler à de la vraie ingénierie, et où vous devriez vous arrêter pour vous demander si vous en avez vraiment besoin.

Un palais de mémoire — parfois appelé Me Palace, MemPalace ou memory palace RAG — est un système de Retrieval-Augmented Generation qui stocke le texte exact des conversations dans une structure indexée symboliquement. La métaphore est la technique mnémonique antique : vous avez des ailes, des pièces dans ces ailes, des placards dans ces pièces, et des tiroirs dans ces placards. Chaque tiroir contient un fragment verbatim spécifique. Des pointeurs indexent le tout.

Les chiffres publiés sur les meilleures implémentations sont réels : environ 42 ms de latence de récupération via des pointeurs indexés, avec ce que leurs auteurs disent être le meilleur benchmark de rappel publié dans l'espace mémoire open source. L'architecture est typiquement SQL plus base vectorielle — SQL pour l'index de pointeurs structuré, vecteurs pour la correspondance sémantique. Local. Gratuit. Auto-hébergeable.

Pourquoi voudriez-vous ça ? Parce que la recherche sémantique au niveau 3 retourne des paraphrases et des résumés. Un palais de mémoire retourne les mots exacts que quelqu'un a dits, dans l'ordre exact, avec la ponctuation exacte. Pour certains workflows, ça compte énormément :

• Travail légal ou de conformité — vous avez besoin de la formulation verbatim d'une clause.
• Notes de thérapie ou de coaching — vous avez besoin de citer la formulation réelle du client.
• Transcriptions de recherche — vous avez besoin de citer exactement ce qui a été dit dans l'entretien 47, pas un résumé.
• JdR ou projets de fiction au long cours — vous avez besoin que le personnage se souvienne de ce qu'il a vraiment dit au chapitre 3.

Pour mon workflow de contenu ? Je n'ai pas besoin de rappel verbatim. Quand j'écris un article sur Claude Code, je n'ai pas besoin de citer ce que j'ai dit sur Claude Code il y a six mois — j'ai juste besoin de l'esprit. Donc le palais de mémoire serait une infrastructure coûteuse dans laquelle je n'irais jamais puiser.

À qui s'adresse le niveau 4 : aux gens dont le travail dépend de la formulation exacte. Légal, médical, recherche, certains pipelines d'écriture créative, analyse de voix-du-client où la paraphrase détruit la donnée.

Là où ça casse : quand vous passez plus de temps à régler la hiérarchie de l'index qu'à utiliser le rappel. Les palais de mémoire ont une vraie taxe de maintenance — vous faites désormais tourner une petite base de données, et les bases de données ont besoin d'attention.

Niveau 5 : base de connaissances interconnectée (LLM Wiki)

C'est le niveau qui récolte le plus de hype parce qu'Andrej Karpathy l'a mentionné. C'est aussi le niveau le plus souvent mal appliqué.

Le pattern, originaire du gist de Karpathy sur l'architecture de base de connaissances LLM, est : au lieu de faire du RAG au moment de la requête, vous avez un LLM qui compile vos sources entrantes — articles, podcasts, transcriptions, PDF — en un wiki markdown persistant et navigable. La synthèse se fait une seule fois, à l'ingestion. Après ça, chaque récupération n'est plus que la lecture d'une page finie. Comme VentureBeat l'a résumé, le LLM agit comme un « bibliothécaire de recherche à temps plein, qui compile, lint et interconnecte activement les fichiers markdown ».

Deux dossiers :

• raw/ — entrées en lecture seule. Transcriptions, articles, notes brutes. Jamais modifiés.
• wiki/ — géré par l'IA. Pages de synthèse de style encyclopédique avec backlinks entre concepts.

Vous pouvez visualiser le tout dans Obsidian, qui rend le wiki markdown sous forme de graphe de connaissances navigable — des boîtes connectées par des lignes, le genre de truc qui fait beau en capture d'écran et qui est réellement utile si votre métier est la recherche.

Plusieurs implémentations communautaires existent. Le plugin OpenClaw memory-wiki compile la mémoire d'un workspace en un répertoire wiki avec un catalogue d'index, des pages de synthèse de modules et des digests lisibles par machine. Il y a un Agent Skill LLM wiki à la Karpathy pour OpenClaw et Codex. Il y a obsidian-wiki, un framework pour que les agents IA construisent et maintiennent un wiki Obsidian en utilisant le pattern de Karpathy.

C'est de la magnifique architecture. C'est aussi inadapté pour de la mémoire de projet opérationnelle. Voici pourquoi.

Un wiki est une référence statique. Il est optimisé pour « je veux lire à propos de X ». Mais la mémoire de projet opérationnelle doit répondre à « quelle était la règle sur X ? » ou « qu'avons-nous décidé sur X au sprint dernier ? ». C'est un pattern d'accès différent. Essayer d'utiliser un wiki LLM comme mémoire opérationnelle, c'est comme utiliser une encyclopédie comme to-do list — techniquement possible, profondément inadapté.

Ce pour quoi un wiki LLM est bon : les projets de recherche en profondeur. Construire une vraie base de connaissances à partir de sources que vous ingérez avec le temps. L'organisation de contenu où vous synthétisez un sujet à travers des dizaines d'entrées et voulez un artefact navigable à la fin. J'ai envisagé d'en construire un pour toute l'archive mejba.me — plus de 230 articles synthétisés en un wiki à la Karpathy — purement comme artefact de recherche pour ma propre écriture future. Je n'ai pas appuyé sur la gâchette parce que le coût initial de synthèse est réel et que je ne suis pas encore sûr que le retour le justifie.

À qui s'adresse le niveau 5 : aux chercheurs. Aux travailleurs du savoir qui construisent au-dessus de grands corpus de sources. Aux écrivains qui font de la synthèse thématique en profondeur. Aux éducateurs qui construisent du matériel de cours. Aux gens qui bénéficieraient d'un graphe Obsidian de leur propre pensée.

Là où ça casse : comme mémoire de projet opérationnelle. N'utilisez pas un wiki pour ça. Utilisez le niveau 2 ou 3.

Niveau 6 : mémoire unifiée multi-outils (Open Brain / Mem.ai)

Le dernier niveau, et celui qui fait sauter la frontière du laptop.

Le postulat : votre mémoire ne devrait pas être liée à un seul outil. Si vous demandez quelque chose à Claude le lundi, puis posez une question liée à ChatGPT le mardi, puis écrivez du code dans Cursor le mercredi — les trois devraient puiser dans le même magasin de mémoire. Un cerveau. Plusieurs visages.

Deux saveurs principales en 2026 :

Hébergé (Mem.ai, Mem0, Zep, MemPalace) : mémoire multi-outils prête pour la production en tant que service. Selon la tarification de Mem0, le tier gratuit couvre 1 000 mémoires par mois, les plans payants démarrent à 19 $/mois pour 10 000 mémoires, et la mémoire en graphe est verrouillée derrière un plan Pro à 249 $/mois. Leur couverture d'intégration s'étend sur 21 frameworks et plateformes en Python et TypeScript. C'est désormais une infrastructure mature — pas un projet du soir.

Auto-hébergé (Open Brain, Postgres + pgvector custom) : même architecture, vous la possédez. Postgres (souvent via Supabase, qui fournit pgvector clés en main) stocke les fragments plus les embeddings. Moins cher à grande échelle parce que vous payez des coûts d'infrastructure, pas de tarification par mémoire. Plus de contrôle. Plus de setup. Plus de choses à maintenir.

L'une ou l'autre saveur ajoute une mémoire partagée en temps réel à travers Claude Desktop, Claude Code, ChatGPT, Cursor, et tout outil avec un serveur MCP ou un hook API. C'est ça la magie. Vous demandez à Claude une décision projet ; plus tard, dans Cursor, la génération de code la connaît déjà.

Les pièges ne sont pas théoriques :

1. Latence. Un appel réseau vers un magasin de mémoire distant ajoute 100-500 ms par récupération. Sur un prompt rapide, c'est OK. Sur une boucle serrée avec des récupérations fréquentes, ça se remarque.
2. Dépendance externe. La mémoire hébergée signifie faire confiance à un fournisseur avec votre contexte. L'auto-hébergement signifie babysitter une base de données.
3. Conflits de synchro. Deux outils qui écrivent dans la même mémoire en même temps créent des problèmes de fusion qu'aucune architecture n'a totalement résolus.
4. Surface de confidentialité. Tout ce qui vit dans votre mémoire unifiée est désormais accessible depuis chaque outil que vous avez connecté. C'est la fonctionnalité. C'est aussi le risque.

À qui s'adresse le niveau 6 : aux power users qui font tourner des workflows réellement multi-outils. Aux ingénieurs qui changent de contexte entre Claude, ChatGPT et Cursor plusieurs fois par jour. Aux équipes où le travail assisté par IA franchit les frontières d'outils en permanence. À toute personne qui fait tourner un vrai pipeline « second cerveau » qui dépasse déjà une seule IA.

Là où ça casse : pour la plupart des opérateurs solo, la taxe de latence et de complexité l'emporte sur la commodité multi-outils. J'ai testé à la fois le tier hébergé de Mem0 et un setup Supabase + pgvector. Les deux marchaient. Les deux ajoutaient 200-300 ms à chaque prompt. Les deux exigeaient une attention que je préfère consacrer à l'écriture.

Comment choisir votre niveau sans cramer un week-end

Voici le cadre de décision que je tendrais à mon moi passé avant ce mardi cassé.

Démarrez au niveau 1. Expédiez quelque chose. Voyez ce qui casse. Les deux questions qui comptent : claude.md dépasse-t-il 200 lignes, et maintenez-vous les mêmes règles centrales sur plusieurs projets ?

Passez au niveau 2 quand la réponse à l'une ou l'autre est oui, ou quand vous êtes sur Claude Code depuis plus d'un mois et que votre mémoire a clairement débordé de ce qu'un seul fichier devrait contenir. Structure de dossiers plus hook session-start. Un après-midi.

Passez au niveau 3 quand le niveau 2 commence à manquer la bonne tranche de mémoire sur les prompts complexes, ou quand votre mémoire dépasse les 100 fragments markdown environ. Plugin MemSearch, récupération hybride. Une journée de setup. C'est là que se stabilisent la plupart des opérateurs sérieux.

Envisagez le niveau 4 uniquement si votre travail dépend de la formulation verbatim — légal, médical, recherche, voix-du-client. Ne construisez pas un palais de mémoire parce que ça sonne cool.

Envisagez le niveau 5 uniquement si vous faites de la synthèse de recherche en profondeur sur de nombreuses sources et voulez un artefact navigable. Ce n'est pas de la mémoire opérationnelle. C'est un produit de connaissance.

Envisagez le niveau 6 uniquement si vous changez déjà de contexte entre trois outils IA ou plus quotidiennement et que l'écart de mémoire entre eux nuit activement à votre travail. Sinon, la taxe de latence ne vaut pas le coup.

Le pattern : chaque niveau au-dessus de celui dont vous avez besoin est de la friction. Chaque niveau en dessous est de la fuite. Le sweet spot est le plus bas niveau qui gère votre charge de travail réelle, pas le plus haut dont vos pairs se vantent.

Pour moi — du contenu multi-marques à grande échelle, faire tourner @aria sur quatre marques, parfois en coordonnant des stacks de skills comme celles que j'ai décortiquées dans mon billet sur le stack de skills Claude Code et les meilleurs skills Claude Code pour l'efficacité business — le niveau 3 est là où le calcul fonctionne. Le rappel verbatim ne change pas ma sortie. La mémoire unifiée multi-outils non plus, parce qu'@aria est un agent Claude Code qui vit dans un seul outil. Donc je reste au niveau 3, j'économise la taxe d'ingénierie, et je publie plus d'articles.

Si votre calcul est différent, grimpez. Sinon, ne grimpez pas.

Ce que je dirais à toute personne qui démarre aujourd'hui

Ce que j'ai sous-estimé, avant le mardi cassé et la reconstruction qui a suivi, c'est que la mémoire est un levier, mais seulement au niveau qui correspond à votre travail. Le niveau 1 est suffisant pour la plupart des gens. Le niveau 3 est suffisant pour presque tout le monde d'autre. Les niveaux restants existent pour des formes de travail spécifiques, et les traiter comme des objectifs aspirationnels, c'est ainsi qu'on gaspille des après-midis.

Ce qui m'a aidé à y penser correctement, c'est de regarder comment l'écosystème a réellement évolué. Le repo memsearch a été inspiré par OpenClaw, qui s'est construit sur des patterns communautaires, qui se sont construits sur la primitive claude.md originale d'Anthropic. Chaque niveau enveloppe le niveau en dessous. Aucun ne remplace la couche du dessous — il ne fait qu'ajouter. Ce qui veut dire que vous pouvez toujours grimper plus tard. Vous ne perdez rien à démarrer petit. Vous perdez juste du temps quand vous démarrez gros et que ça ne colle pas.

Si je démarrais Claude Code aujourd'hui, en sachant ce que je sais maintenant, je ferais exactement ceci :

1. Ouvrir un projet. Écrire claude.md. Le maintenir sous 200 lignes. L'utiliser pendant une semaine.
2. Remarquer ce qui manque. L'ajouter. Plafonner la longueur du fichier dès qu'il menace les 200.
3. Après un mois, scinder en un dossier de mémoire avec compartiments general / domain / tool. Ajouter un hook session-start.
4. Après trois mois, si votre mémoire a clairement débordé la récupération par mots-clés, installer MemSearch.
5. S'arrêter. Réévaluer uniquement si un workflow spécifique l'exige.

C'est le chemin. C'est ennuyeux. Ça marche. C'est comme ça que je fais tourner une opération de contenu multi-marques sur une couche mémoire qui tient dans un seul repo et se reconstruit à partir de markdown.

Le mardi où j'ai essayé de sauter ces étapes m'a coûté un après-midi de travail. Le mardi suivant, avec le niveau 3 vraiment réglé, @aria a expédié quatre articles à la première tentative. Même agent. Même modèle. Architecture mémoire différente, dimensionnée au vrai job.

Choisissez le niveau que votre travail exige. Pas le niveau que le fil vous a dit de faire tourner.

Foire aux questions

Quelle est la différence entre claude.md et memory.md dans Claude Code ?

claude.md est un fichier d'instructions au niveau projet que vous écrivez manuellement — il contient les règles, conventions et consignes permanentes chargées au démarrage de la session. memory.md est l'auto-mémoire, où Claude lui-même sauvegarde des notes issues des corrections et préférences au fil des sessions. Vous êtes l'auteur de l'un ; Claude maintient l'autre. Les deux se chargent dans le contexte ensemble.

Comment éviter la pourriture de contexte dans claude.md ?

Gardez claude.md sous environ 200 lignes, puis scindez en un dossier de mémoire avec compartiments general, domain et tool. Utilisez un hook session-start pour n'injecter que la tranche pertinente dans le contexte par session. Les fichiers de mémoire monolithiques longs poussent le modèle à survoler plutôt qu'à lire, ce qui est la cause racine de la pourriture de contexte.

MemSearch est-il meilleur que la mémoire Claude Code basique ?

MemSearch bat la mémoire basique dès que votre savoir accumulé dépasse environ 100 fragments markdown, parce que la récupération hybride sémantique + BM25 trouve du contexte pertinent que le chargement par mots-clés seul rate. Pour les setups plus petits sous ce seuil, ça ajoute de la complexité sans amélioration significative. La plupart des opérateurs n'en ont pas besoin dans leurs trois premiers mois.

Qu'est-ce qu'un palais de mémoire dans les workflows IA ?

Un palais de mémoire est un système RAG qui stocke le texte verbatim exact des conversations dans une structure indexée symboliquement — typiquement ailes, pièces, placards et tiroirs — en utilisant SQL plus une base vectorielle pour la récupération. Il est optimisé pour le rappel formulation-exacte, pas pour le sens paraphrasé. Utile pour les workflows légaux, médicaux ou de recherche où la formulation exacte compte.

Devrais-je utiliser Mem.ai ou construire ma propre mémoire multi-outils ?

Utilisez Mem.ai ou Mem0 si vous voulez une mémoire hébergée prête pour la production et ne voulez pas maintenir d'infrastructure — la tarification démarre à 19 $/mois pour 10 000 mémoires sur Mem0. Construisez la vôtre avec Supabase plus pgvector si vous avez besoin de pleine propriété des données, de coûts prévisibles à l'échelle, et que vous êtes à l'aise pour maintenir une base de données. La plupart des opérateurs solo n'ont besoin ni de l'un ni de l'autre.

Travaillons ensemble

Vous voulez construire des systèmes IA, automatiser des workflows, ou faire évoluer votre infrastructure tech ? Je serais ravi d'aider.

• Fiverr (builds & intégrations sur mesure) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design & branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io