IAMaîtriser l'IA générative Plan du corpus
Accueil/Exemples prets a l'emploi/CLAUDE.md pret a l'emploi pour un projet data

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.md qui 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.md inutile

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

ErreurPourquoi ca rateCorrection
Ecrire un roman de 400 lignesLes instructions se diluent, les plus importantes passent inapercuesVise 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 comportementMets des regles verifiables : noms, seuils, commandes exactes
Documenter ce que le code dit dejaC'est redondant et ca se perimeMets 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.md est 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

Corpus personnel de formation · genere le 26/09/2026 · source : 01-claude-md-projet-data.md