Installation rapide : un Claude structuré

La carte : à quoi ressemble un Claude structuré

Tel quel, Claude Code est un amnésique brillant. Chaque session repart de zéro : aucune mémoire de vos projets, aucune connaissance de vos règles, aucune leçon accumulée. Tout ce que vous lui avez appris hier a disparu ce matin. Ce module corrige cela. C'est un guide de montage pratique : à la fin, vous aurez un Claude structuré, capable de se souvenir, de suivre vos règles, de s'améliorer avec le temps et de s'entretenir lui même. Prévoyez environ une heure d'installation.

Un Claude structuré est composé de sept éléments, chacun couvert par une leçon de ce module :

• Le moteur : Claude Code lui même, installé et connecté (leçon suivante).
• La constitution : un fichier CLAUDE.md global avec vos règles absolues, chargé à chaque début de session.
• La mémoire : un dossier de notes Markdown que Claude lit et écrit d'une session à l'autre, ouvert dans Obsidian pour que vous puissiez voir et naviguer dans ce même savoir sous forme de graphe.
• Le transport : le dossier mémoire versionné avec git, pour que votre cerveau soit sauvegardé et synchronisé entre machines (y compris un téléphone).
• Les réflexes : les hooks, de petits scripts qui s'exécutent automatiquement à des événements du cycle de vie (début de session, fin de session, après chaque tour) et maintiennent la mémoire synchronisée sans que vous ayez à y penser.
• Les capacités : les skills, des packs d'expertise installables. Nous installerons deux collections éprouvées, ECC (everything-claude-code) et superpowers, et apprendrons à sélectionner plutôt qu'à accumuler.
• Le battement de coeur : des tâches planifiées qui font une consolidation nocturne et hebdomadaire, pour que la structure s'entretienne même pendant votre sommeil.

Pourquoi s'en donner la peine ? Parce que la valeur d'un assistant ne s'accumule que si son savoir s'accumule aussi. Un Claude non structuré résout deux fois le même problème pour vous et refait deux fois la même erreur. Un Claude structuré écrit la leçon dès la première fois, la relie aux leçons connexes, et la rappelle au bon moment le mois suivant. La différence après trois mois d'usage quotidien n'a rien de subtil : tout ce cours a été construit avec (et est en grande partie le produit de) exactement l'installation que vous vous apprêtez à mettre en place.

Ce module est délibérément autonome. Il recoupe les modules d'approfondissement sur l'extension de Claude Code et sur le second cerveau : ceux là expliquent le pourquoi et les rouages internes ; celui ci vous donne le chemin ordonné, prêt à copier coller. Si une étape vous intrigue, suivez le renvoi vers la leçon complète. Si vous voulez juste une installation fonctionnelle dès aujourd'hui, suivez les commandes dans l'ordre et revenez à la théorie plus tard.

Un principe avant de commencer : la structure vit dans des fichiers, pas dans le chat. Tout ce que nous installons ci dessous est du texte brut sur votre disque : règles Markdown, notes Markdown, paramètres JSON, petits scripts. Rien n'est enfermé dans une base de données propriétaire, tout est versionnable, inspectable et portable. C'est ce qui rend cette installation durable à travers les versions de Claude : les fichiers survivent même quand l'outil change.

Installer Claude Code et se connecter

Premier composant : le moteur. Depuis 2026, la voie recommandée par Anthropic est l'installateur natif, un binaire autonome qui se met à jour tout seul et ne dépend pas de Node.js à l'exécution :

• macOS / Linux / WSL : curl -fsSL https://claude.ai/install.sh | bash
• Windows (PowerShell) : irm https://claude.ai/install.ps1 | iex

Les gestionnaires de paquets fonctionnent aussi si vous les préférez (brew install --cask claude-code, winget install Anthropic.ClaudeCode, ou npm install -g @anthropic-ai/claude-code), avec un bémol : les installations brew et winget ne se mettent pas à jour automatiquement, et la voie npm exige Node.js 22 ou plus récent depuis la v2.1.198. Sur Windows natif, installez aussi Git for Windows : cela donne à Claude Code un véritable outil Bash au lieu de tout faire retomber sur PowerShell.

Lancez ensuite claude dans un terminal. Au premier démarrage, un navigateur s'ouvre pour la connexion OAuth. Deux types de compte fonctionnent, et la distinction compte pour votre portefeuille :

• Un abonnement Claude (Pro, Max, Team, Enterprise) : l'usage est couvert par le forfait mensuel fixe, dans les limites de débit du plan. Le plan gratuit claude.ai n'inclut pas Claude Code.
• Un compte Claude Console (API) : facturation à l'usage, au token. Adapté aux équipes avec un budget API, dangereux pour un usage personnel, car une journée agentique intense peut coûter plus cher qu'un mois d'abonnement.

Pour une installation personnelle structurée, la voie abonnement est presque toujours la bonne. Attention à un piège : si la variable d'environnement ANTHROPIC_API_KEY est définie, elle peut prendre le pas sur votre abonnement et vous facturer silencieusement au token. Si une ancienne clé traîne dans votre profil shell, supprimez-la ou restreignez-la aux projets qui en ont besoin.

Vérifiez l'installation avec claude --version, puis, depuis une session, lancez /doctor (alias /checkup). Doctor est une skill de diagnostic intégrée qui vérifie la santé de votre installation, les problèmes de PATH, les fichiers de configuration illisibles, les hooks lents, et signale même les skills ou serveurs MCP inutilisés qui vous coûtent du contexte pour rien. Lancez-le maintenant pour confirmer une base saine, et retenez qu'il existe : c'est la première chose à lancer dès que votre installation se comporte mal après les personnalisations que nous allons ajouter.

Où vivent les choses désormais : le dossier ~/.claude/ est votre répertoire Claude. ~/.claude/CLAUDE.md contiendra vos règles globales (prochaine leçon), ~/.claude/settings.json votre configuration et vos hooks, ~/.claude/skills/ vos skills installées, et ~/.claude/projects/ les données par projet, mémoire comprise. Chaque composant de ce module est un fichier quelque part sous cette arborescence, ou y fait référence.

Extras optionnels, utiles à connaître mais non bloquants : les extensions IDE (VS Code, JetBrains) intègrent le même moteur dans votre éditeur ; les applications bureau et web proposent des sessions Claude Code hors du terminal ; et oui, Claude Code tourne nativement sur un téléphone Android via Termux, ce qui devient vraiment utile une fois votre mémoire synchronisée par git. Le module second cerveau comporte une leçon dédiée à cette installation de poche.

Votre CLAUDE.md global : une constitution, pas un roman

Deuxième composant : la constitution. Le fichier ~/.claude/CLAUDE.md est injecté dans chaque session, sur tous les projets, avec la priorité d'instruction la plus forte que le harnais accorde à du contenu utilisateur. C'est le fichier le plus à effet de levier de toute votre installation : une ligne ici change le comportement de toutes les sessions futures. Ce levier joue dans les deux sens, donc le fichier doit être élagué sans pitié.

Une structure éprouvée, affinée sur des mois d'usage sur l'installation de l'auteur du cours :

• Les règles absolues d'abord. Les non-négociables, formulés comme des ordres, tout en haut : interdictions de formatage, règles de sécurité (archiver, jamais supprimer), la manière de traiter les secrets (variables d'environnement, jamais collés dans le chat), et où s'arrête l'autonomie de Claude (pour l'auteur : les coûts externes payants, les décisions de sécurité et les décisions produit remontent à l'humain ; tout le reste technique relève de Claude).
• Le démarrage de session. Ce que Claude doit faire au début de chaque session : quel index mémoire lire, comment router vers le bon contexte projet quand vous en nommez un.
• Des pointeurs, pas du contenu. Une ligne par protocole récurrent, qui pointe vers le fichier qui en est propriétaire (une skill, une note mémoire). Le protocole détaillé vit à un seul endroit ; CLAUDE.md se contente d'y router.

Le principe du pointeur mérite d'être souligné, car c'est là que la plupart des installations pourrissent. Si vous collez un protocole complet dans CLAUDE.md et dans une skill et dans une note mémoire, les trois copies divergent en quelques semaines et Claude suit celle qu'il a lue en dernier. La règle : CLAUDE.md est un routeur. Le détail vit dans la skill ou la note vers laquelle il pointe, et n'est mis à jour qu'à cet endroit. Cela garde aussi le fichier court, ce qui compte doublement : chaque octet est chargé dans le contexte de chaque session, et une constitution courte est une constitution que Claude suit vraiment. Moins de 5 Ko est un bon objectif ; si le vôtre dépasse 10 Ko, il a presque certainement absorbé du contenu qui devrait vivre dans une skill.

Un squelette minimal pour démarrer :

# Rules (absolute)
- Never delete: archive to _ARCHIVES/ instead.
- Secrets never in chat: set env vars, verify by length, never echo.
- Technical decisions: decide and execute. Escalate only paid costs,
  security, and product decisions.
- Update the memory after every delivered batch of work.

# Session start
- Read the memory index. When I name a project, load its memory notes
  before acting.

# Protocols (pointers)
- Memory sync protocol: see the sync-memory note.
- New project: attach the code-graph tool, reuse existing patterns first.

Trois détails opérationnels. Premièrement, les changements s'appliquent à la prochaine session, pas à la session en cours : CLAUDE.md est lu une seule fois au démarrage, donc testez vos modifications en ouvrant une session neuve. Deuxièmement, conservez une archive des versions précédentes (une copie datée dans un dossier d'archive) avant toute réécriture : votre constitution est exactement le genre de fichier que vous voudrez restaurer un jour. Troisièmement, si vous travaillez sous Windows avec des scripts PowerShell qui touchent vos fichiers, envisagez de garder le fichier en ASCII pur : cela évite toute une classe de corruption d'encodage quand des outils le réécrivent.

Les fichiers CLAUDE.md de niveau projet (à la racine de chaque dépôt) se superposent au fichier global et portent des faits spécifiques au projet : commandes de build, notes d'architecture, conventions. Les mêmes principes s'appliquent : court, impératif, des pointeurs plutôt que de la prose. Le fichier global porte qui vous êtes et comment vous travaillez ; le fichier projet porte ce qu'est ce code.

Brancher Obsidian sur la mémoire de Claude

Troisième composant : la mémoire, et la fenêtre qui donne dessus. Claude Code persiste sa mémoire sous forme de notes Markdown simples, dans un dossier par projet situé sous ~/.claude/projects/<project-slug>/memory/, avec un fichier index, MEMORY.md, chargé en contexte au démarrage de chaque session. Ce dossier, c'est le cerveau. Obsidian est l'outil gratuit qui transforme ce même dossier en quelque chose qu'un humain peut parcourir : rétroliens, recherche plein texte, et une vue en graphe où vos connaissances deviennent visibles.

L'astuce de configuration qui fait tout fonctionner est trompeusement simple : ouvrir le dossier mémoire lui-même comme coffre (vault) Obsidian. Pas une copie, pas un export, le dossier lui-même. Téléchargez Obsidian depuis obsidian.md (gratuit, aucun compte requis ; sous Windows, winget install Obsidian.Obsidian), choisissez "Open folder as vault", et pointez vers le dossier mémoire. À partir de là, il n'existe qu'une seule source de vérité : ce que vous voyez et modifiez dans Obsidian est exactement ce que Claude charge et écrit. Aucune synchronisation, puisqu'il n'y a rien à synchroniser.

À l'intérieur du coffre, trois conventions maintiennent le cerveau en bonne santé à mesure qu'il passe de dix notes à plusieurs centaines :

• Notes atomiques. Un fait par note, avec un en-tête frontmatter portant un name, une description d'une ligne (utilisée pour la pertinence du rappel), et un type : s'agit-il de l'utilisateur, d'un retour sur la manière de travailler, de l'état d'un projet, ou d'une référence externe ? Une note avec deux idées est une note que vous ne pouvez pas relier précisément.
• Des wikilinks partout. Chaque note renvoie vers ses notes connexes avec des liens [[nom-de-note]]. Reliez sans compter : la valeur du graphe réside dans les connexions. Un lien vers une note qui n'existe pas encore n'est pas une erreur, c'est le marqueur de quelque chose qui mérite d'être écrit.
• Des cartes de contenu. Une poignée de notes carrefours (une convention courante les préfixe _MOC_) qui rassemblent les liens par thème : projets, retours d'expérience, références. Plus l'index MEMORY.md : une ligne par note avec son accroche. La règle de fer : aucune note orpheline. Chaque nouvelle note obtient une ligne dans l'index et un lien depuis le carrefour concerné, sinon elle ne sera jamais rappelée.

Une subtilité structurelle si vous travaillez sur plusieurs projets : Claude conserve un dossier mémoire distinct par répertoire de travail, si bien que les connaissances se fragmentent entre plusieurs magasins. La solution retenue dans la configuration de l'auteur : des liens au niveau du système de fichiers (jonctions sous Windows, liens symboliques ailleurs) : les dossiers mémoire par projet sont montés comme sous-dossiers (par exemple _projets/<nom>) à l'intérieur d'un unique coffre principal. Obsidian voit un cerveau unifié unique ; chaque magasin de projet reste physiquement là où Claude l'attend ; éditer via le point de montage édite le magasin réel. Un seul coffre, plusieurs magasins, zéro copie.

Deux détails de confort qui valent le coup d'être repris : colorer le graphe par type de note (groupes de graphe Obsidian : une couleur pour les notes project_, une autre pour feedback_, une autre pour reference_), pour que la forme de vos connaissances soit lisible d'un coup d'oeil ; et garder le contenu volumineux et régénérable (journaux de conversation exportés, graphes de code générés) exclu du filtre de graphe principal, pour qu'il ne noie pas le signal.

C'est toute l'astuce. Pas besoin de fouiller une marketplace de plugins, pas de synchronisation payante : un seul dossier, ouvert par deux programmes, chacun voyant ce que l'autre écrit. Les leçons approfondies plus tôt dans le module second cerveau couvrent la mécanique du rappel et la discipline de rédaction des notes ; la prochaine leçon rend ce cerveau durable et portable grâce à git.

Versionner son cerveau avec git

Quatrième composant : le transport. Votre vault mémoire est maintenant le dossier le plus précieux de votre machine, et il vit dans un dot-folder auquel aucun outil de sauvegarde ne pense. La solution est la même que pour le code : faire du vault un dépôt git avec un remote privé. Vous gagnez un historique (chaque modification de note est un commit que vous pouvez inspecter et annuler), une sauvegarde (le remote survit à votre disque), et une synchronisation (le même cerveau sur votre ordinateur de bureau, votre portable, et même votre téléphone).

Avant le premier push, auditez les secrets. Cette étape n'est pas optionnelle. Des mois de notes de travail accumulent exactement les choses qui ne doivent jamais atteindre un remote : jetons collés en plein débogage, mots de passe cités dans des résumés de session. Passez le vault au grep pour les motifs classiques (sk_live, ghp_, AKIA, longues chaînes hexadécimales, les mots password et token) et occultez les résultats en remplaçant la valeur par un marqueur avant de committer. Le premier scan de l'auteur sur un vault mature a révélé un mot de passe administrateur de production niché dans une note de session ; supposez que le vôtre en contient l'équivalent.

Ensuite, délimitez ce qui voyage. Un bon .gitignore par défaut exclut ce qui est volumineux, régénérable, ou porteur de risque :

• Les journaux de conversations exportés (ils peuvent contenir tout ce que vous avez jamais collé, secrets inclus),
• Les artefacts générés comme les graphes de code (régénérables depuis la source),
• Les dossiers d'archives et les fichiers d'état d'espace de travail d'Obsidian.

Les notes atomiques, l'index, les notes carrefours : voilà le cerveau, et ceux-là voyagent.

Le protocole quotidien tient en deux habitudes : pull en début de toute session qui touchera la mémoire, commit et push après chaque mise à jour mémoire, avec un message nommant le sujet. Si cela ressemble à une discipline que vous allez oublier, vous avez raison, c'est pourquoi la leçon suivante automatise les deux bouts avec des hooks. En cas de conflit, appliquez la règle spécifique à la mémoire : ne jamais écraser, garder les deux versions dans la note et signaler la contradiction pour relecture. Un cerveau fusionne par accrétion, pas par force-push.

La récompense qui surprend le plus : le téléphone. Claude Code tourne nativement sur Android dans Termux, et une fois votre vault transformé en dépôt git, le téléphone le clone et le monte comme sa propre mémoire de session (un lien symbolique du ~/.claude/projects/<slug>/memory du téléphone vers le clone). Claude de bureau et Claude de poche lisent et écrivent alors le même cerveau, à un commit près. Une leçon dédiée du module second cerveau de ce cours détaille cette installation de poche, pièges compris.

Une dernière mise en garde pour conclure : un dépôt privé est privé au compte d'hébergement. Traitez le remote du vault avec le même soin qu'un export de gestionnaire de mots de passe : authentification forte sur le compte, pas de partage du dépôt à la légère, et souvenez-vous que l'occultation avant commit vaut mieux que la suppression après push, car l'historique git se souvient de ce que vous avez poussé même après l'avoir retiré.

Les hooks qui maintiennent la structure en vie

Cinquième composant : les réflexes. Tout ce qui a été installé jusqu'ici dépend d'habitudes : pull avant de travailler, mise à jour de la mémoire après un lot, push à la fin. Les habitudes s'effritent. Les hooks sont le mécanisme de Claude Code pour les transformer en automatisation : des commandes shell que le harnais lui-même exécute à des événements du cycle de vie. Ils se configurent dans ~/.claude/settings.json (à l'échelle de l'utilisateur) ou dans le .claude/settings.json d'un projet, et à la mi-2026 on compte environ trente événements sur lesquels s'accrocher, de SessionStart et SessionEnd à Stop (fin de chaque tour de l'assistant), PreToolUse, PostToolUse et bien d'autres.

Pour une installation structurée, deux hooks portent l'essentiel de la valeur :

• SessionStart tire le cerveau (pull). Un script qui exécute git pull --ff-only sur le vault, avec un délai court, et qui ne bloque jamais la session si le réseau est coupé. Chaque session démarre avec la mémoire la plus fraîche, automatiquement.
• SessionEnd (ou Stop) le pousse (push). L'image miroir : commit et push des changements de mémoire à la fermeture de la session, pour que rien de ce que vous avez appris ne reste coincé sur une seule machine.

La forme dans settings.json :

{
  "hooks": {
    "SessionStart": [{ "hooks": [{ "type": "command",
      "command": "bash ~/.claude/hooks/pull-brain.sh" }] }],
    "SessionEnd": [{ "hooks": [{ "type": "command",
      "command": "bash ~/.claude/hooks/push-brain.sh" }] }]
  }
}

Un motif plus avancé, tiré de l'installation de l'auteur, résout un vrai manque : il n'existe pas d'événement natif "session devenue inactive", alors qu'on veut pourtant que la mémoire se synchronise quand on s'éloigne en cours de session. La solution est une architecture en deux étages. Premier étage, un hook Stop global : après chaque tour de l'assistant, un petit script enregistre la session (id, chemin de la transcription, dossier de travail) dans un fichier en attente, pour un coût de quelques millisecondes. Second étage, une tâche planifiée toutes les 15 minutes : elle vérifie les sessions en attente, et pour toute session dont la transcription n'a pas changé depuis 30 minutes, elle lance Claude en mode headless sur cette même session (claude -p --resume <session-id> "sync memory...") afin que le modèle lui-même écrive les enseignements de la session dans le vault. Les sessions inactives voient leur mémoire sauvegardée sans que personne ne touche le clavier.

Toute automatisation qui appelle Claude depuis une chaîne de hooks a besoin de garde-fous anti-boucle, et cela mérite d'être intériorisé même si vous ne copiez rien d'autre : les exécutions headless posent une variable d'environnement marqueur pour que le hook Stop ignore leurs propres tours (sinon chaque synchronisation génère des enregistrements qui génèrent d'autres synchronisations) ; un fichier d'empreinte enregistre ce qui a déjà été synchronisé pour qu'une même session inactive ne soit jamais traitée deux fois ; un verrou empêche les exécutions qui se chevauchent ; et des plafonds bornent les dégâts (au maximum deux synchronisations par passage, avec un délai maximal strict à chaque fois). Tout hook capable de déclencher ce qui l'a lui-même déclenché doit porter ce genre de garde-fou.

Notes opérationnelles. Les hooks se chargent au démarrage de la session : les sessions déjà ouvertes au moment où vous modifiez settings.json n'héritent pas du nouveau hook tant qu'elles ne sont pas relancées. Gardez les hooks rapides et non bloquants : un hook SessionStart lent retarde chaque session que vous ouvrirez désormais (le contrôle /doctor signale d'ailleurs les hooks lents pour cette raison précise). Loggez les échecs quelque part de visible plutôt que de faire échouer bruyamment : les scripts de l'auteur ajoutent une ligne à une note d'alertes dans le vault, qui remonte dans Obsidian où un humain regarde vraiment. Et traitez les hooks comme du code : ils s'exécutent sans surveillance avec vos permissions, versionnez-les donc avec le vault.

Skills : installer ECC et superpowers, curater sans pitié

Sixième brique : les capacités. Les skills sont des dossiers d'instructions (un SKILL.md plus des scripts optionnels) qui apprennent à Claude un flux de travail, et l'écosystème autour d'elles a mûri jusqu'à former de vraies collections installables en quelques minutes. Deux valent d'être installées dès le premier jour d'une configuration structurée, et une discipline les empêche de se retourner contre vous.

ECC (everything-claude-code) est la plus grande collection organisée, par Affaan Mustafa, sous licence MIT. Notez que le dépôt a été renommé en 2026 : l'adresse canonique est désormais github.com/affaan-m/ECC (l'ancienne URL everything-claude-code redirige). En juillet 2026, elle regroupe 278 skills, 67 agents, 34 règles et un ensemble d'automatisations par hooks, couvrant l'orchestration d'agents, les patterns front-end, les tests, les flux git, l'analyse de sécurité et bien plus. Installez-la comme plugin :

/plugin marketplace add https://github.com/affaan-m/ECC
/plugin install ecc@ecc

superpowers, par Jesse Vincent, est l'autre pierre angulaire : non pas un tas de capacités mais une discipline de processus. Elle installe des skills de flux de travail qui imposent de bonnes habitudes d'ingénierie : brainstormer avant de construire, déboguer méthodiquement avant de corriger, développer piloté par les tests, vérifier avant de déclarer une tâche terminée. Elle vit dans la marketplace officielle de plugins Anthropic, donc l'installation tient en une seule commande, sans ajout de marketplace :

/plugin install superpowers@claude-plugins-official

Sa règle centrale mérite d'être adoptée telle quelle : si un skill pourrait s'appliquer à la tâche en cours, l'invoquer avant d'agir. Les skills que vous possédez mais n'invoquez jamais sont du poids mort.

Maintenant la discipline : curater, pas accumuler. La tentation est forte d'installer les 278 skills d'ECC. Résistez. Le nom et la description de chaque skill installé participent à la mise en correspondance des skills ; des centaines de skills hors sujet polluent cette mise en correspondance et alourdissent le contexte. Quand l'auteur de ce cours a intégré ECC, il en a gardé 67 sur les 271 que comptait alors le dépôt : les catégories orchestration d'agents, front-end, ingénierie, QA et contenu qui correspondaient à sa pile technique réelle, en écartant délibérément des catégories entières (trading crypto, santé HIPAA, cinq piles backend qu'il ne touche jamais). Installez ce qui correspond au travail que vous faites réellement ; vous pourrez toujours ajouter un skill le jour où vous en aurez besoin. Le diagnostic /doctor signale désormais même les skills inutilisés comme un coût de contexte, ce qui indique à quel point le problème est réel.

Les skills tierces venant de sources non reconnues méritent un filtre de plus : un audit avant installation. Un skill s'exécute avec les pleines permissions de votre agent. Le protocole de vérification, traité en détail dans la leçon du module sécurité consacrée à l'audit des skills tierces : cloner dans un dossier de quarantaine sans rien exécuter, lire chaque script, chercher par grep les motifs dangereux (appels eval et exec, appels réseau, blobs en base64, commandes destructrices, formulations d'injection de prompt comme "ignore les instructions précédentes"), puis copier uniquement le dossier audité dans ~/.claude/skills/, jamais un paquet entier non audité. Pour la découverte au-delà des marketplaces : le skill find-skills explore l'écosystème ouvert, et des annuaires comme skills.sh classent les skills par installations réelles.

Après l'installation, redémarrez la session (ou lancez /reload-plugins) et testez un skill de bout en bout : demandez une tâche que le skill couvre et vérifiez que Claude annonce qu'il l'utilise. S'il ne se déclenche pas, la cause habituelle est un décalage de description : la description du skill ne contient pas les mots que vous employez naturellement. C'est réparable (modifier la description), et savoir le vérifier vous place devant la plupart des utilisateurs.

Le battement de coeur : tâches planifiées, rêve nocturne, statusline

Septième composant : le battement de coeur. Les hooks réagissent aux sessions ; les tâches planifiées agissent quand aucune session ne tourne. Cette couche est ce qui rend la structure auto-entretenue : consolidation, rafraîchissement et audits se produisent chaque nuit et chaque semaine, que vous vous soyez connecté ce jour-là ou non. Sur Windows, le planificateur est le Planificateur de tâches (schtasks ou le module ScheduledTasks de PowerShell) ; sur macOS et Linux, cron ou launchd. Chaque tâche est un petit script plus un horaire.

Le rythme sur l'installation de l'auteur, à titre de modèle :

• Le soir, les conversations affluent vers le cerveau. Une tâche quotidienne exporte les sessions Claude récentes en Markdown dans le vault (le paquet pip claude-conversation-extractor fait ce travail) et rafraîchit les graphes de connaissances dérivés. Les conversations passées deviennent une matière consultable au lieu d'un historique perdu. Une précaution durement acquise : faire passer les exports par un script de rédaction des secrets avant que quoi que ce soit ne les indexe, car les transcriptions brutes contiennent tout ce qui a un jour été collé.
• La nuit, le rêve (dream). Une tâche de consolidation quotidienne (l'auteur la lance à 21h00, après l'export) démarre Claude en mode headless avec une skill dédiée : relire les conversations et la mémoire récentes, extraire les faits durables en notes correctement formées, fusionner les doublons, tisser les wikilinks, garder l'index propre. Deux règles de sécurité sont intégrées : une sauvegarde datée des notes avant chaque exécution, et archiver, jamais supprimer : une note contredite reçoit une bannière d'obsolescence et part dans un dossier d'archive au lieu de disparaître. Le nom n'est pas un hasard : Anthropic a présenté exactement cette idée sous le nom de "dreaming" (le rêve), des agents qui consolident leur mémoire entre les sessions ; une version auto-hébergée tient en quelques dizaines de lignes de prompt.
• Toutes les 15 minutes, l'idle-sync issu de la leçon sur les hooks, qui rattrape les sessions que vous avez abandonnées en cours de réflexion.
• Chaque semaine, le lint du vault. Une tâche qui parcourt le vault à la recherche de wikilinks cassés, de notes orphelines, d'entrées d'index mortes et de notes surdimensionnées. L'entropie s'accumule dans tout système relié ; un passage hebdomadaire garde le graphe honnête.

Une convention relie la couche entre elle : les alertes atterrissent dans le vault. Chaque tâche ajoute ses échecs et constats à une seule note d'alertes à la racine du vault. Les logs vivent à côté des scripts pour l'analyse forensique, mais la note est ce qu'un humain voit, car elle apparaît dans Obsidian, là où vous regardez déjà. Une automatisation dont on n'entend jamais parler est une automatisation à laquelle on ne peut pas faire confiance ; une automatisation qui vous envoie des emails est une automatisation qu'on apprend à ignorer. Une note dans le cerveau est la voie du milieu.

Touche finale, la statusline : Claude Code affiche une barre de statut personnalisée en transmettant le JSON de session (modèle, usage de contexte, coût, état du rate-limit) à une commande que vous configurez sous statusLine dans settings.json. Un petit script transforme cela en tableau de bord vivant : pourcentage de contexte, barres de quota, coût de la session. Un piège documenté sur la machine de l'auteur : refreshInterval est exprimé en millisecondes. Réglé sur 1, cela lançait un nouveau processus interpréteur environ 28 fois par seconde et gelait visiblement le terminal ; 1000 (un tick par seconde) est une valeur raisonnable. Quand votre terminal bafouille mystérieusement, vérifiez d'abord ce chiffre.

Une fois le battement de coeur installé, prenez du recul et regardez ce que vous avez construit au fil de ce module : des règles qui se chargent elles-mêmes, une mémoire qui s'écrit elle-même, une synchronisation qui se produit sans vous, des skills qui se déclenchent sur leurs propres triggers, et une maintenance qui tourne pendant que vous dormez. La dernière leçon condense tout cela en une checklist que vous pourrez rejouer sur toute nouvelle machine.

La checklist en une heure

Tout le contenu de ce module, condensé dans le manuel opératoire que vous pouvez rejouer sur n'importe quelle nouvelle machine. Les durées sont des estimations honnêtes pour quelqu'un qui le fait pour la deuxième fois : la première fois, doublez-les et profitez du paysage.

Phase 1 : le moteur (10 min)

• Installateur natif pour votre système, puis claude --version.
• Connexion avec le compte d'abonnement, en traquant toute ANTHROPIC_API_KEY égarée.
• /doctor : base saine confirmée.

Phase 2 : la constitution (10 min)

• ~/.claude/CLAUDE.md : les règles absolues en premier, la routine de début de session, uniquement des pointeurs.
• Une session fraîche récite vos règles correctement.

Phase 3 : mémoire et Obsidian (10 min)

• Installer Obsidian, ouvrir le dossier mémoire actif comme coffre (vault).
• Première note atomique avec frontmatter, ligne dans MEMORY.md, wikilien depuis un carrefour.
• Une nouvelle session rappelle le fait de la note sans qu'on le lui demande.

Phase 4 : le transport git (10 min)

• .gitignore pour les conversations, les graphes générés, les archives.
• Scan des secrets, rédaction, PUIS premier push vers un dépôt distant privé.
• Modifier, committer, pousser : l'historique fonctionne.

Phase 5 : les hooks (10 min)

• Hook SessionStart qui tire la mémoire (ff-only, timeout, exit 0 systématique).
• Chemin SessionEnd ou Stop pour le push, avec des garde-fous anti-boucle si quoi que ce soit appelle Claude.
• Une session fraîche prouve que le pull s'est déclenché, /doctor confirme l'absence de hook lent.

Phase 6 : les skills (10 min)

• /plugin install superpowers@claude-plugins-official.
• Marketplace ECC ajoutée, installée, puis élaguée à votre pile réelle.
• Une skill se déclenche à partir d'une tâche formulée avec vos propres mots.

Phase 7 : le battement de coeur (10 min, plus une nuit pour vérifier)

• Export quotidien des conversations avec rédaction des secrets, dream nocturne avec sauvegarde et règle archiver jamais supprimer, lint hebdomadaire du coffre.
• Note d'alertes à la racine du coffre comme unique canal de reporting.
• Barre d'état configurée, refreshInterval à 1000 ms.

L'état d'esprit de vérification compte plus que la liste : chaque phase se termine par une preuve, pas par une impression. Une session fraîche qui récite les règles, une note rappelée sans invite, un hook dont on démontre le déclenchement, une skill qui s'active sans être nommée. Si vous ne pouvez pas montrer la preuve, la phase n'est pas terminée, quoi qu'en disent les fichiers de configuration.

Où aller à partir d'ici : le module sur l'extension pour les serveurs MCP et l'écriture de vos propres skills, le module sur le second cerveau pour la mécanique du rappel et l'installation de poche sur Android, le module sur l'orchestration quand un seul Claude ne suffit plus, et le module sur la sécurité avant que vos hooks et skills ne se multiplient. La structure que vous venez de construire est le socle sur lequel tout cela repose. Entretenez-la avec l'habitude qui surclasse tous les outils de ce cours : quand vous apprenez quelque chose de durable, écrivez-le dans le cerveau avant de fermer la session.