CLAUDE.md, le fichier qui change tout
Le contexte permanent de ton projet : stack, conventions, commandes, interdits. Écris-le une fois, gagne à chaque session.
🧠 Concept — La mémoire longue durée du projet
À chaque nouvelle session, Claude Code repart de zéro… sauf s'il trouve un CLAUDE.md à la racine du projet : il le lit automatiquement à chaque session. C'est LE levier au meilleur ratio effort/impact.
Ce qu'on y met :
- La stack : langages, frameworks, versions.
- Les conventions : style de code, nommage, format de commits.
- Les commandes : comment builder, tester, linter — pour qu'il vérifie lui-même son travail.
- Les interdits : ce qu'il ne doit jamais toucher sans demander.
Bonus : les CLAUDE.md peuvent être imbriqués. Un CLAUDE.md racine pour le repo, un autre dans billing/ avec les règles spécifiques de la facturation des sessions. Claude lit celui du dossier où il travaille.
Pense-y comme au dossier technique d'une station : le technicien qui arrive en intervention ne redécouvre pas le site, il lit la fiche et travaille selon les règles du lieu.
Template Electra copiable
# CLAUDE.md ## Stack - Python 3.12, FastAPI, PostgreSQL 16 - Gestion des dépendances : uv ## Commandes - Tests : pytest (lancer avant tout commit) - Lint/format : ruff check . && ruff format . - Lancer en local : make dev ## Conventions - Commits conventionnels : feat:, fix:, chore:, docs: - Documentation et commentaires en francais ; code en anglais (variables, fonctions, noms de fichiers) - Une fonction = une responsabilite ; typage explicite partout ## Interdits - Ne JAMAIS modifier les migrations (dossier migrations/) sans demander - Pas de secrets en clair : utiliser les variables d'environnement (.env est gitignore et doit le rester) - Ne pas toucher aux integrations paiement sans validation humaine ## Contexte metier - Ce service gere les sessions de charge : demarrage, suivi kWh, arret - "station" = site physique ; "borne" = point de charge ; une station a 4 a 16 bornes
💡 Réflexe pro — Le test du nouveau collègue
Un bon CLAUDE.md répond à la question : « qu'est-ce que je dirais à un nouveau dev le premier jour pour qu'il ne casse rien ? ». S'il manque une règle et que Claude fait une bêtise, ne t'énerve pas : ajoute la règle au CLAUDE.md. Le fichier s'améliore bêtise après bêtise — comme une base de connaissance d'incidents.
🛠️ À toi de jouer — 🛠️ Rédige le CLAUDE.md d'un vrai projet
Choisis un projet réel sur lequel tu travailles (repo de code, mais aussi dossier de scripts data, projet n8n…). Pas de projet sous la main ? Utilise le projet fictif du prompt : ev-uptime-reporter, un outil interne qui calcule l'uptime des bornes à partir des logs de supervision. Fais rédiger un premier jet par Claude, puis corrige-le toi-même : c'est TOI qui connais les interdits.
Aide-moi à rédiger le CLAUDE.md d'un projet. Contexte : le projet s'appelle ev-uptime-reporter, un outil interne Electra qui lit les logs de supervision des bornes (exports Datadog en JSON), calcule l'uptime par borne et par station, et génère un rapport hebdomadaire Markdown pour l'équipe ops. Stack : Python 3.12, pandas, pytest, ruff. Le rapport est envoyé sur Slack par un job n8n — le script ne doit JAMAIS poster sur Slack lui-même. Les seuils d'alerte (uptime < 97 %) sont dans config/thresholds.yaml et ne doivent pas être modifiés sans validation de l'équipe ops. Structure attendue : ## Stack, ## Commandes, ## Conventions, ## Interdits, ## Contexte métier. Sois concis : un CLAUDE.md se lit en 1 minute.
Checklist de validation