Réinstaller son environnement Claude Code sur un nouvel ordi

Nouvel ordinateur. On installe Claude Code. Et là : Claude ne sait plus rien. Les règles de développement encodées dans le CLAUDE.md global, les guides de référence, la statusline qui affichait la consommation de tokens en temps réel, les plugins — tout est resté sur l'ancienne machine.

La mauvaise nouvelle : rien de tout ça n'est synchronisé automatiquement. La bonne : tout est dans des fichiers. Un prompt suffit à reconstruire l'environnement complet en quelques minutes, à condition d'avoir préparé ce prompt en amont.

Ce qui vit dans ~/.claude/

L'environnement Claude Code global est concentré dans un seul dossier : ~/.claude/. Ce qu'on y trouve :

CLAUDE.md — les instructions globales : comment travailler, quelles règles s'appliquent à tous les projets
settings.json — configuration technique : permissions, statusline, hooks
hooks/ — scripts exécutés à des événements Claude Code
commands/ — slash commands personnalisées (/audit-memory, etc.)
memory/ — mémoires globales
projects/<cwd>/memory/ — mémoires par projet

Ce dossier n'est ni versionné ni synchronisé par défaut. Si la machine change, le dossier disparaît. Tout ce qu'on a construit au fil des sessions aussi.

Les fichiers de référence qu'on peut y stocker — guides de développement, bonnes pratiques spécifiques à un langage — ne sont pas chargés automatiquement. Claude les lit sur demande explicite. Eux aussi, ils ne survivent pas à un changement de machine sans intervention.

Le CLAUDE.md global : les règles du jeu

~/.claude/CLAUDE.md est chargé dans toutes les sessions, tous projets confondus. C'est là qu'on encode ce qui doit s'appliquer partout : comment Claude doit travailler, quelles restrictions sont actives, comment les commits doivent être rédigés, comment la mémoire automatique fonctionne.

C'est aussi le fichier le plus dense à reconstruire de mémoire — parce que chaque règle qu'il contient vient d'une expérience concrète. Une convention de commit encodée après avoir découvert qu'on n'en voulait pas dans les messages. Une restriction sur les fichiers .env ajoutée après un incident. Un principe d'économie de contexte qui a pris des semaines à calibrer.

La structure qui fonctionne bien en pratique :

Règles de mémoire automatique (quand sauvegarder, quoi éviter)
Restrictions sécurité (fichiers interdits, limites git)
Conventions de commit (ce qu'on ne veut pas voir dans les messages)
Principes de conception (YAGNI, les 4 questions avant un refactoring)
Mode de délégation entre modèles (ce qu'Opus fait directement, ce qu'il délègue)
Économie de contexte (taille max des fichiers lus directement, quand déléguer)

Cible : moins de 100 lignes. Au-delà, le fichier commence à charger du contexte inutile pour la plupart des tâches. Les sections rarement utiles (bonnes pratiques Go, guide de développement détaillé) vont dans des fichiers séparés référencés en texte simple.

Les fichiers de référence

Certaines connaissances sont trop volumineuses pour le CLAUDE.md principal mais trop spécifiques pour aller dans un CLAUDE.md de projet. La solution : des fichiers de référence dans ~/.claude/, lus sur demande.

Exemples concrets :

DEVELOPPEMENT-PROPRE.md — les principes fondamentaux : YAGNI, triangle robustesse/testabilité/simplicité, checklist code review, anti-patterns à éviter
go-best-practices.md — patterns Go spécifiques avec exemples de code : error handling, concurrence, PostgreSQL, testing table-driven, logging structuré

Le CLAUDE.md global contient juste une ligne de référence :

Guide Développement : `~/.claude/DEVELOPPEMENT-PROPRE.md`
Go Best Practices (patterns, exemples code) : `~/.claude/go-best-practices.md`

Claude lit ces fichiers quand ils sont pertinents pour la tâche. Le reste du temps, ils n'occupent pas de contexte.

La statusline : scraper les tokens en temps réel

Claude Code supporte une statusline configurable dans ~/.claude/settings.json :

{
  "statusLine": {
    "type": "command",
    "command": "bash /home/TON_USER/.claude/hooks/statusline.sh"
  }
}

Le script affiche dans la barre de Claude Code des informations qui ne sont pas disponibles nativement : consommation de contexte en pourcentage, estimation de tokens restants, branche git courante.

🌿 main │ 🤖 Sonnet 4.6 │ 🟢 Ctx: ▓▓░░░░░░ 34% │ ⏱ 46% → 19h00 (3h20m) │ 📅 ~59% (lun 14h)

Le script scrape l'endpoint /usage en background via tmux, met en cache les résultats 5 minutes dans ~/.claude/usage-exact.json. Prérequis : bash 4+, jq, tmux, python3.

Sans ce script, la seule indication de consommation est la barre de progression dans l'interface — pas de chiffre, pas d'estimation.

Les plugins

Claude Code supporte un système de plugins (skills) qui enrichissent les sessions avec des workflows spécialisés. Ils s'installent via :

claude plugins install <nom-du-plugin>

Les plugins qui changent réellement la façon de travailler :

superpowers — brainstorming structuré, plans d'implémentation, debugging systématique, TDD, revue de code
frontend-design — génération d'interfaces avec qualité production
code-simplifier — revue automatique du code changé pour détecter les sur-ingénieries

Ils se réinstallent en une commande. Le seul prérequis est d'avoir la liste des plugins qu'on utilisait — d'où l'utilité de la noter quelque part avant de changer de machine.

Les mémoires : ce qui se reconstruit seul vs ce qui ne se reconstruit pas

Les mémoires projet (~/.claude/projects/<cwd>/memory/) ne méritent pas toujours d'être migrées manuellement. Elles vieillissent vite — les mémoires de type project en particulier. Rouvrir un projet sur un nouvel environnement est l'occasion de les laisser se reconstruire naturellement, session après session, avec des informations à jour.

Ce qui mérite d'être migré en priorité : les mémoires globales (~/.claude/memory/). Ce sont les préférences transversales — le profil utilisateur (niveau technique, domaines de connaissance), les feedbacks qui s'appliquent à tous les projets (style de réponse attendu, règles de communication). Ces informations prennent du temps à reconstruire parce qu'elles viennent d'expériences cumulées sur plusieurs projets.

Pour les mémoires de feedback en particulier : chaque règle encode une correction passée. "Ne pas résumer ce qu'on vient de faire en fin de message" — Claude doit se faire corriger plusieurs fois avant que ça entre dans une mémoire. Sur un nouvel environnement sans cette mémoire, on recommence les corrections depuis zéro.

Le prompt de bootstrap

La vraie solution au problème n'est pas de synchroniser les fichiers — c'est d'avoir un prompt de bootstrap qui recrée tout à partir de zéro. Un document qui contient :

Le contenu exact de ~/.claude/CLAUDE.md
Le contenu de chaque fichier de référence
La configuration settings.json
Le script statusline
La liste des plugins
Les mémoires globales à restaurer

On donne ce document à Claude sur le nouvel environnement avec l'instruction "recrée tout ça". Claude crée les fichiers, configure les settings, installe ce qu'il peut installer. En 10 minutes, l'environnement est fonctionnel.

L'avantage sur une synchronisation de fichiers : c'est l'occasion de relire et d'actualiser. Un prompt de bootstrap qu'on maintient au fil du temps reflète l'état réel de ce qu'on veut — pas un snapshot figé de l'ancienne machine.

Le contexte CLAUDE.md associé en bas de page contient un exemple concret complet : le CLAUDE.md global, la configuration settings.json, la liste des plugins, et la checklist de vérification post-installation.

Conclusion

Tout ce que Claude sait sur la façon dont on veut travailler est dans des fichiers. Ces fichiers ne se synchronisent pas, ne se sauvegardent pas, et ne survivent pas à un changement de machine sans intervention consciente.

La discipline à avoir : traiter ~/.claude/ comme on traite les dotfiles — quelque chose qu'on versionne, qu'on maintient, et dont on sait comment restaurer l'état complet depuis zéro. Le contexte CLAUDE.md associé ci-dessous contient le prompt de bootstrap complet.