CLAUDE.md pret a l'emploi pour un projet data
Le fichier qui evite de re-expliquer ton projet a chaque session.
Temps de lecture : 8 min | Niveau : Debutant
Ce que tu sauras faire apres
- Ecrire un
CLAUDE.mdqui fait vraiment changer le comportement de Claude Code - Distinguer ce qui merite d'y figurer de ce qui l'encombre
- Adapter le modele fourni a ton projet en 10 minutes
- Eviter les trois erreurs qui rendent un
CLAUDE.mdinutile
Le principe en une phrase
Le CLAUDE.md est lu au demarrage de chaque session. Tout ce que tu y ecris, tu n'auras plus a le repeter. Tout ce que tu n'y ecris pas, tu le repeteras dix fois par jour.
Le modele complet
Copie ce contenu dans un fichier CLAUDE.md a la racine de ton projet, puis remplace les [CROCHETS].
# Projet [NOM_DU_PROJET]
## Contexte metier
[EN 3 LIGNES : ce que fait l'entreprise, ce que ce projet sert a piloter,
qui consomme les donnees.]
Exemple : plateforme de reporting commercial. Ce depot alimente les tableaux de
bord CA / marge / panier moyen consultes par les directeurs regionaux.
## Stack technique
- Langage : Python 3.12, gestion des dependances avec [uv|poetry|pip]
- Entrepot : [BigQuery|Snowflake|Postgres|SQL Server]
- Transformation : dbt-core [VERSION]
- Orchestration : [Airflow|Dagster|cron]
- Visualisation : [Power BI|Looker|Metabase]
## Structure du depot
- `models/staging/` : nettoyage 1 pour 1 des sources, aucun calcul metier
- `models/intermediate/` : jointures et logique intermediaire
- `models/marts/` : tables finales exposees au reporting
- `pipelines/` : scripts d'ingestion Python
- `tests/` : tests pytest du code Python
- `docs/` : dictionnaire de donnees
## Commandes utiles
```bash
uv run pytest # tests Python
dbt build --select state:modified+ # construire les modeles modifies
dbt docs generate # regenerer la documentation
ruff check . && ruff format . # lint et formatage
```
## Conventions de code
- SQL : mots-cles en majuscules, un champ par ligne, CTE nommees en snake_case.
- Jamais de `SELECT *` dans les modeles `marts`.
- Nommage des modeles : `stg_<source>__<objet>`, `int_<sujet>`, `fct_<fait>`, `dim_<dimension>`.
- Python : type hints obligatoires, fonctions de moins de 40 lignes, docstrings au format Google.
- Tout nouveau modele `marts` doit avoir un test `unique` et `not_null` sur sa cle.
## Definitions metier (a respecter absolument)
- **CA** : montant TTC, hors frais de port, hors commandes annulees.
- **Exercice** : du 1er juillet au 30 juin. "Cette annee" = exercice en cours, jamais annee civile.
- **N-1** : meme periode decalee de 364 jours, pour aligner les jours de semaine.
- **Perimetre constant** : uniquement les magasins ouverts sur les deux periodes comparees.
## Ce que j'attends de toi
- Propose un plan avant toute modification qui touche plus de 3 fichiers.
- Ne lance jamais `dbt run` sur l'environnement de production.
- Avant de proposer une requete, verifie le schema reel dans `models/` ou `docs/`.
- Si une definition metier est ambigue, demande-moi plutot que de choisir.
- Reponds en francais.
## A ne pas faire
- Ne modifie pas `dbt_project.yml` ni `profiles.yml` sans me demander.
- N'ajoute pas de dependance sans justification.
- Ne colle jamais de donnees clients reelles dans un exemple ou un test.Les trois erreurs qui rendent un CLAUDE.md inutile
| Erreur | Pourquoi ca rate | Correction |
|---|---|---|
| Ecrire un roman de 400 lignes | Les instructions se diluent, les plus importantes passent inapercues | Vise 60 a 120 lignes. Le detail va dans des fichiers separes |
| Ne mettre que des generalites (« ecris du code propre ») | Ca ne change rien au comportement | Mets des regles verifiables : noms, seuils, commandes exactes |
| Documenter ce que le code dit deja | C'est redondant et ca se perime | Mets ce qui ne se devine pas : conventions, definitions metier, interdits |
Le test pour savoir si une ligne merite d'y etre
Pose-toi cette question : « est-ce que je l'ai deja explique deux fois cette semaine ? » Si oui, ca va dans le CLAUDE.md. Sinon, ca reste dans ta tete.
Deux astuces utiles
1. Ajouter une regle a chaud. Pendant une session, commence ton message par # : Claude Code te proposera de l'enregistrer dans un fichier de memoire.
# Toujours utiliser des CTE plutot que des sous-requetes imbriquees.2. Separer le general du projet. Tes preferences personnelles (langue, ton, habitudes) vont dans ~/.claude/CLAUDE.md et s'appliquent a tous tes projets. Les regles du projet restent dans le depot, versionnees dans Git.
Exemple de ~/.claude/CLAUDE.md personnel :
# Preferences personnelles
- Reponds-moi en francais, avec des phrases courtes.
- Quand tu m'expliques quelque chose, donne toujours un exemple concret.
- Quand je te demande du SQL, precise le dialecte que tu utilises.
- Quand tu rediges pour moi un mail ou un ticket, propose une version courte
et une version detaillee.Template a remplir en 10 minutes
Si tu n'as pas le temps de tout remplir, ces cinq blocs suffisent pour 80 % du benefice :
# Projet [NOM]
## Contexte
[TROIS LIGNES SUR LE BUT DU PROJET]
## Stack
[LANGAGES, BASE DE DONNEES, OUTILS]
## Commandes
[LA COMMANDE DE TEST, LA COMMANDE DE BUILD, LA COMMANDE DE LINT]
## Conventions
[TROIS REGLES DE NOMMAGE OU DE STYLE QUE TU REPETES SOUVENT]
## Interdits
[CE QU'IL NE FAUT JAMAIS TOUCHER OU LANCER]A retenir
- Le
CLAUDE.mdest lu a chaque session : c'est le meilleur investissement de temps. - Court et precis bat long et vague.
- Mets-y ce qui ne se devine pas : definitions metier, conventions, interdits.
- Versionne-le dans Git, il devient la memoire commune de l'equipe.
Sources
- Claude Code - gerer la memoire du projet
- Claude Code - vue d'ensemble
- centminmod/my-claude-code-setup - trois modeles de
CLAUDE.mdcomplets a comparer (CLAUDE-template-1.mda-3.md) - ChrisWiles/claude-code-showcase - un
CLAUDE.mdreel a la racine d'un projet deja configure