Ce qu'un rm -rf m'a appris sur ma configuration Claude Code

Il y a trois jours, j’ai tapé rm -rf ~/.claude dans mon terminal, délibérément, parce que je pensais vider un cache. Je ne vidais pas un cache. Je supprimais toute ma couche opérationnelle Claude Code : le fichier de configuration global, une soixantaine de fichiers mémoire accumulés, quatre agents personnalisés, chaque commande slash que j’avais construite, et un hook qui classait automatiquement les sessions dans mes notes. Des mois de connaissance opérationnelle accumulée, disparus le temps d’appuyer sur entrée.

Je veux être précis sur ce que signifie cette phrase, parce que « connaissance opérationnelle » sonne abstrait tant qu’on ne l’a pas réellement perdue. Ce n’était pas un dossier de documents. C’était la forme accumulée de la manière dont j’avais appris à un outil à fonctionner comme je fonctionne : quelles tâches sont routées où, quelles sont mes erreurs récurrentes, à quoi ressemble une bonne réponse pour le type de questions que je pose chaque semaine. Rien de tout ça ne se trouve dans les poids d’un modèle. Tout se trouvait dans ce répertoire. Et je ne l’avais jamais sauvegardé, pas une seule fois.

Voici la partie de l’histoire qui compte réellement, cela dit, et ce n’est pas la suppression. C’est ce qui y a survécu.

La couche qui m’a sauvé était la plus ennuyeuse

Deux choses m’ont évité de tout perdre complètement. D’abord, j’avais une session Claude Code encore ouverte dans une autre fenêtre, et cette session avait chargé mon index mémoire dans son contexte avant que la suppression n’ait lieu, si bien que les résumés en une ligne de ces soixante fichiers mémoire étaient toujours présents dans une transcription de conversation, même après la disparition des fichiers eux-mêmes. Ensuite, et surtout : la connaissance durable que ces fichiers mémoire pointaient n’avait en réalité jamais vécu dans ~/.claude. Elle vivait dans un coffre de notes en markdown brut. Le répertoire de configuration n’était qu’un pointeur, un index, une couche de confort posée sur la vraie chose.

Donc la partie ingénieuse de ma configuration, les fichiers mémoire, les agents personnalisés, les commandes slash, tout ce qui avait été conçu spécifiquement pour cet outil, est mort instantanément et complètement. La partie bête, des fichiers texte brut dans des dossiers, sans format propriétaire, sans dépendance à un quelconque logiciel encore présent, n’a même pas remarqué le choc. J’aurais pu supprimer ~/.claude depuis l’orbite, et le coffre de notes se serait retrouvé là, intact, le mardi matin suivant.

C’est l’asymétrie que je retourne dans ma tête. La plupart des gens qui construisent une forme quelconque de workflow IA, instructions personnalisées, systèmes de mémoire, configurations d’agents, peu importe comment l’outil du mois les appelle, versionnent leur code de façon obsessionnelle et ne pensent jamais une seule fois à versionner la couche qui indique à l’IA comment se comporter. On a intégré « sauvegarder son code » comme un réflexe. Personne n’a encore intégré « sauvegarder la couche opérationnelle de son IA », parce que l’outillage est encore trop récent pour ressembler à de l’infrastructure. Ça ressemble à des paramètres. On ne sauvegarde pas des paramètres.

Sauf que ce n’était pas des paramètres. C’était le résultat cumulé de chaque session où j’avais corrigé l’outil, où je lui avais enseigné une préférence, ou où j’avais écrit une règle pour ne pas avoir à la répéter. Les paramètres sont statiques. Ceci s’était accrété. Et les choses accrétées sont exactement celles qu’on regrette de ne pas avoir versionnées, parce qu’on ne peut pas les régénérer à partir d’une spécification, il faudrait revivre chaque correction qui les a produites.

Une suppression catastrophique est le meilleur audit gratuit que vous obtiendrez jamais

L’autre chose à laquelle je ne m’attendais pas : reconstruire m’a obligé à regarder ce que j’avais réellement construit, au lieu de ce que je supposais avoir construit. L’accumulation silencieuse cache la pourriture. Un crash vous oblige à lire chaque ligne.

Le fichier de configuration global reconstruit est passé de 8,5 Ko à 6,5 Ko, et je n’ai perdu aucune règle dans l’opération, j’ai simplement coupé le rembourrage autour des règles qui faisaient un vrai travail. Ce fichier compte plus que sa taille ne le laisse penser, parce qu’il n’est pas chargé une seule fois. Il est expédié avec chaque session que je fais tourner. Chaque phrase superflue qu’il contient est une taxe payée sur chaque conversation, pour toujours, que la session ait besoin de la règle ou non. Le gonflement dans un fichier de ce genre n’est pas un coût ponctuel qu’on remarque et corrige. C’est une charge récurrente qu’on ne voit jamais sur aucune facture, parce que la surcharge en tokens n’apparaît jamais comme une ligne de dépense, elle se manifeste par des réponses légèrement moins bonnes, légèrement plus lentes, qui composent invisiblement sur des centaines de sessions jusqu’à ce qu’on finisse par s’asseoir et lire le fichier entier d’un bout à l’autre, ce qui est exactement ce que sa perte m’a forcé à faire.

Les skills ont révélé leur propre pourriture. Trois d’entre eux référençaient des commandes slash qui n’existaient plus, des liens morts que je transportais apparemment en silence depuis on ne sait combien de temps, jamais remarqués parce qu’un skill avec une référence cassée ne lève pas d’erreur, il sous-performe simplement en silence. Et quatre agents nommés directement dans ma configuration n’existaient sous forme de fichiers nulle part sur le disque. Pas « difficiles à trouver ». Absents. Référencés avec une confiance totale, invoqués par leur nom, et absents, et rien ne s’était jamais plaint, parce que rien dans le système ne vérifiait.

Rien de tout cela n’aurait remonté à la surface tout seul. Je n’allais pas auditer une configuration qui fonctionnait. Les choses qui fonctionnent ne se font pas auditer ; on les laisse tranquilles jusqu’à ce qu’elles cassent, et le temps qu’elles cassent, on a généralement oublié qu’il y avait quelque chose à vérifier. La suppression a fait l’audit à ma place, au pire moment possible, ce qui est le seul moment où un audit de ce genre a réellement lieu.

Ce que j’ai reconstruit, et pourquoi chaque pièce est honnête plutôt qu’ingénieuse

Je n’ai pas reconstruit la même chose. J’ai reconstruit trois protections précises, chacune visant un mode d’échec précis de l’incident lui-même.

La première est ennuyeuse dans le bon sens : tout le répertoire de configuration est désormais versionné, via un répertoire git détaché, un script wrapper de trois lignes qui fait tourner git --git-dir=~/.claude/config.git --work-tree=~/.claude au lieu d’un dossier .git classique posé à l’intérieur du répertoire. Cette distinction compte plus qu’il n’y paraît. Un dossier .git classique dans ~/.claude risque d’être ramassé comme un dépôt de projet par un autre outil, ou pire, de se retrouver imbriqué dans les règles d’exclusion d’un autre dépôt et ignoré en silence. Le répertoire git détaché fait que le dossier de configuration continue de ressembler, pour tout le reste, à un dossier ordinaire, tout en étant entièrement suivi. Il est aussi répliqué vers un dépôt GitHub privé. Toute la valeur de ceci, c’est qu’un rm -rf coûte maintenant un git clone au lieu de coûter des mois. Je n’ai rien construit de sophistiqué. J’ai construit l’équivalent d’une ceinture de sécurité.

La deuxième est un arbre de répartition budgétaire vivant à l’intérieur même de la configuration globale : des règles de routage strictes qui envoient les tâches de code vers un CLI de codage bon marché, les questions de recherche vers un outil de recherche ancré dans des sources, et les longs brouillons vers des modèles de niveau gratuit, en réservant le plan Claude payant spécifiquement pour l’orchestration et le raisonnement réellement difficile. À côté, chaque réponse se termine désormais par un pied de page d’attribution de modèle nommant précisément quel modèle a fait quelle partie du travail, avec un signalement automatique dans les rares cas où le modèle payant a fait quelque chose que les règles de routage disaient devoir être déporté. L’important n’est pas les économies, même s’il y en a. L’important, c’est que la discipline de coût cesse d’être quelque chose qu’on déduit d’un tableau de bord de facturation mensuel trois semaines après coup, et devienne quelque chose de lisible dans chaque réponse, en temps réel, où l’on peut réellement rattraper une dérive avant qu’elle ne s’accumule.

La troisième est un hook SessionEnd qui classe automatiquement dans le coffre toute session substantielle, cinq messages ou plus : une entrée de journal d’une ligne plus une note datée, résumée par un modèle de niveau gratuit, vérifiée par rapport aux comptes rendus manuels pour qu’il n’y ait pas de doublon, et écrite de façon suffisamment défensive pour ne jamais pouvoir bloquer ou faire planter la session à la sortie. C’est celle à laquelle je tiens le plus, honnêtement, parce qu’elle referme la boucle réelle issue de l’échec. La base de connaissances s’auto-alimente désormais. Oublier de noter les choses cesse d’être un mode d’échec, parce que le système ne dépend plus de ma mémoire.

Le dépôt, si vous voulez les fichiers réels

J’ai assaini l’ensemble du système reconstruit et je l’ai mis en ligne publiquement : claude-code-os. C’est le modèle CLAUDE.md, huit skills, dont plusieurs construits sur le travail de skills sous licence MIT de Matt Pocock, crédité dans le dépôt, les quatre agents routés par modèle, le hook SessionEnd, et le script wrapper du répertoire git détaché. Pas un produit. Une trace de ce que j’ai reconstruit après trois jours à découvrir, à mes frais, quelles parties de ma configuration étaient structurantes et lesquelles n’étaient que de la décoration.

Si tout cela vous semble familier, un répertoire de configuration que vous n’avez jamais versionné, des agents ou des commandes dont vous vous souvenez à moitié avoir écrit et que vous n’avez pas vérifiés depuis des mois, vous avez probablement la même faille que j’avais, et vous ne la trouverez probablement pas avant que quelque chose ne force l’audit. Vous n’avez pas besoin du crash pour faire l’audit. Vous pouvez simplement aller lire le dépôt claude-code-os et voler les parties qui comblent la faille que vous avez déjà.