Donner une mémoire
à Claude Code
Votre assistant oublie tout entre deux sessions. Vous réexpliquez votre métier chaque matin, et il refait les mêmes erreurs. La solution tient dans des fichiers texte, mais pas n'importe lesquels, et pas rangés n'importe comment.
Le fichier qui apprend finit par oublier
Le premier réflexe est de tout écrire dans un seul fichier de contexte, et de l'agrandir chaque fois qu'on apprend quelque chose. Ça fonctionne pendant des semaines. Puis le fichier dépasse ce que l'outil charge, et à partir de ce moment chaque nouvelle règle en pousse une ancienne hors du champ de vision. Rien ne vous prévient.
Le fichier chargé en permanence ne doit pas contenir ce que vous savez. Il contient ce qu'on ne peut pas se permettre de chercher, plus la manière d'aller chercher le reste.
Le test qui tranche. La taille de votre fichier de contexte augmente-t-elle quand vous ajoutez un fait ordinaire ? Si oui, c'est un catalogue, et il finira par déborder. Un routeur, non : le nombre de règles vitales d'un métier est fini, alors que le nombre de faits ne l'est pas.
Écrivez des cicatrices, pas des faits
La plupart des systèmes de mémoire stockent ce que l'outil doit savoir. C'est utile, mais ce n'est pas ce qui coûte cher. Ce qui coûte cher, c'est qu'il refasse une erreur qui a déjà causé un dégât. Une règle qui porte la trace de ce dégât ne se contourne pas.
Ne jamais synchroniser un dossier entier vers le serveur.
Se contourne à la première occasion, parce que rien n'en rappelle le prix.
Ne jamais synchroniser un dossier entier vers le serveur. Un fichier à la fois, chemin complet des deux côtés. Le 12 juin, une synchronisation large a fait passer le blog de 97 à 15 articles.
Le coût est écrit à côté de la règle. Personne ne la contourne.
Une cicatrice tient en trois blocs, et s'écrit en deux minutes, au moment où l'erreur vient de se produire. Pas plus tard, pas à froid.
--- statut: actif poids: ▰▰▰ test: « Envoie ce message au client » → doit préparer un brouillon --- # Ne jamais envoyer un courriel sans validation humaine La règle. Tout courriel se prépare en brouillon. L'envoi est déclenché par un humain, jamais par l'assistant. Pourquoi. Le 4 juillet, un message est parti chez un prospect avec un montant erroné. Il a fallu en écrire un second pour corriger, ce qui a coûté la crédibilité du premier. Récidive le 22 juillet. Comment appliquer. Préparer le texte, le déposer en brouillon, annoncer « brouillon prêt », et s'arrêter là.
Le détail qu'on rate presque toujours. L'incident est immuable, la règle ne l'est pas. Le bloc « Pourquoi » raconte ce qui s'est passé, on n'y touche jamais. Le bloc « La règle » dit ce qu'on fait aujourd'hui, et il peut devenir faux. Confondre les deux produit la panne la plus dangereuse du système : une règle appliquée avec force parce que son incident, lui, restera éternellement vrai.
Une cicatrice, de sa naissance à son mécanisme
La même erreur, trois fois. Ce qui change à chaque fois, ce n'est pas la règle, c'est ce que le système en fait.
Le poids ne redescend jamais. C'est lui, et lui seul, qui décide du passage de la consigne au mécanisme.
Ne réécrivez pas la règle, comptez
Quand la même erreur revient, la tentation est de réécrire la règle en plus fort. Les majuscules, le gras, le « ABSOLUMENT JAMAIS ». L'emphase s'épuise. Un compteur, non.
-
1re fois
Vous écrivez la cicatrice
Trois blocs, deux minutes, plus une ligne dans le fichier chargé. La règle démarre à un cran de poids.
-
Récidive
Vous ajoutez un cran, pas une ligne
La règle ne change pas. Le compteur monte, la date s'ajoute au « Pourquoi ». Le poids ne redescend jamais tout seul, ce qui rend visible l'endroit où vous vous blessez le plus souvent.
-
3e cran
La règle change de nature
Elle quitte le texte et devient une contrainte que l'outil applique tout seul. C'est le constat le plus dur de la méthode, et le plus utile : une consigne écrite ne tient pas au moment du danger, parce que l'attention manque précisément quand on est pressé.
Le poids ne tranche jamais un conflit. Il mesure la fréquence d'un échec passé, pas la validité présente d'une règle. Une règle très lourde, née d'incidents réels en juin, peut être devenue fausse en août. Si le compteur arbitre, elle écrase la règle juste et récente avec l'autorité que lui donne son historique. Et si elle a déjà été promue en contrainte automatique, l'erreur devient obligatoire.
Quand deux règles se contredisent : la source de vérité actuelle, puis la règle validée le plus récemment, puis la plus spécifique au contexte. Si le doute persiste, on s'arrête et on demande à un humain.
Cinq conditions avant de bloquer quoi que ce soit
Transformer une règle en blocage automatique est puissant et dangereux. Un seuil mécanique produit une bureaucratie de contraintes qui finit par empêcher de travailler. Une règle ne devient un blocage que si les cinq conditions sont réunies, sans exception.
Grave
L'action est irréversible ou coûteuse. Envoyer un courriel, effacer un dossier, publier en production.
Détectable
La condition se reconnaît de façon fiable, sans jugement. Un motif dans une commande, une extension de fichier, un chemin.
Exceptions rares
Les cas légitimes sont identifiables. Si la moitié des situations sont des exceptions, ce n'est pas une règle, c'est un jugement.
Reprise humaine
Il existe un chemin clair pour passer outre en connaissance de cause. Un mécanisme sans dérogation devient un piège.
Testable
On peut écrire un cas qui doit bloquer et un cas qui ne doit pas. Un mécanisme qui bloque tout est aussi cassé qu'un mécanisme qui ne bloque rien.
S'il en manque une
Ce n'est pas un blocage. C'est un rappel, qui affiche un avertissement au bon moment, ou un contrôle, qui signale après coup sans empêcher.
Quatre pannes que personne ne voit venir
Elles ont toutes été relevées sur un système réel, en fonctionnement quotidien depuis quatorze mois, au moment où quelqu'un a enfin pensé à compter. Aucune ne se voyait à l'usage.
Un fichier existe, il est juste, et l'assistant ne le trouve jamais parce qu'aucun index et aucun autre fichier ne pointe vers lui. Il n'est atteignable que par une recherche textuelle qui tombe juste par chance.
Des renvois vers des fichiers jamais écrits. Un lien vers une note à venir est légitime, il marque un manque. Il devient une panne quand rien ne le distingue d'une erreur.
La méthode a un mécanisme d'entrée puissant et aucun mécanisme de sortie. C'est un déséquilibre structurel, pas un manque de discipline. Mais attention : le non-usage ne prouve pas la fausseté. Une règle de sauvegarde peut dormir deux ans en restant vitale. L'ancienneté déclenche une révision, jamais une disparition.
Vous ouvrez un projet, l'assistant travaille normalement, mais il ne sait rien de ce projet. Aucun message d'erreur. Vous perdez la session avant de comprendre.
La vérification qui prend dix secondes. À l'ouverture d'un projet, demandez à l'assistant de citer un fait qu'il ne peut connaître que par la mémoire de ce projet. S'il ne peut pas, réparez avant de travailler. Sinon vous travaillez en aveugle sans le savoir.
Une mémoire que personne ne mesure finit par mentir
Deux contrôles, et ils ne disent pas la même chose. Le premier vérifie la forme. Le second vérifie que ça change quelque chose.
La forme, une fois par mois
Taille du fichier chargé par rapport à la limite. Fichiers que rien n'atteint. Liens cassés. Fichiers trop gros. Règles sans test. Un petit programme les compte tous, ne modifie rien, et signale ce qui dépasse.
Il grossit-il quand le corpus grossit ? Alors ce n'est plus un routeur.
Le fond, le seul qui compte
Posez à l'assistant des situations réelles, formulées dans les mots du métier et jamais dans ceux de la règle, et comptez combien il en traite correctement. Un test qui reprend les mots du fichier teste la recherche textuelle, pas la mémoire.
Notez le score et sa date. C'est le seul chiffre qui dit si le système fait son travail.
Choisissez ce que vous testez par son coût, pas par sa facilité de mesure. Un premier jeu de tests portait sur des faits vérifiables d'une ligne : un montant, une ville, un titre. Tous justes, tous inutiles. Une règle dont la violation se corrige en trois secondes ne mérite pas de test.
On teste ce qui détruit : la commande qui efface, la balise qui désindexe tout un site, la durée estimée qui part en facture, le code de succès pris pour une confirmation.
Et vérifiez votre outil de mesure avant de le croire. Un contrôle automatique qui cherche un mot dans une réponse se trompe : il compte « localhost » dans la phrase « pas de localhost ». Avant d'agir sur un chiffre alarmant, prenez trois cas signalés et allez les regarder à la main. Si les trois sont sains, c'est l'outil qui est cassé, pas votre système.
La méthode complète, en un document
Cette page en donne le principe. Le document va au bout : les huit règles avec leur pourquoi et l'erreur qu'elles évitent, le protocole détaillé, deux parcours d'installation selon que vous écrivez du code ou non, les modèles de fichiers à copier, et la grille de mesure.
Recevez le document par courriel. Une adresse, rien d'autre, et vous pouvez vous désinscrire en un clic.
Vous recevrez le document et, de temps en temps, ce que j'apprends en travaillant avec ces outils. Jamais votre adresse à qui que ce soit.
Si vous préférez qu'on regarde votre cas plutôt que de lire un document, c'est le sujet de mes journées de travail avec les équipes chez TimeKraft : on part de vos propres dossiers, et on repart avec la mémoire construite sur votre métier, pas sur un exemple.