Comment CLAUDE.md a changé ma façon de créer des apps (et pourquoi tu en as besoin)
Le problème : se répéter à chaque session
Si tu utilises Claude Code, tu connais le rituel. Tu ouvres une nouvelle session, et les 15 premières minutes sont gaspillées à tout réexpliquer. La structure du projet. La stack. Les conventions de nommage. Où vont les fichiers. Quels patterns suivre.
À. Chaque. Session.
C'est comme avoir un collègue brillant qui a une amnésie totale chaque nuit. Lundi : "mets les services dans lib/core/services/." Mardi : "non, je te l'ai dit hier, les services vont dans lib/core/services/." Mercredi : pareil.
Après 3 mois de ce cirque, j'étais prêt à tout laisser tomber. Puis j'ai découvert CLAUDE.md.
C'est quoi un CLAUDE.md ?
Un fichier markdown à la racine de ton projet. C'est tout.
Claude Code le lit automatiquement au début de chaque session. C'est un briefing permanent. Au lieu de répéter tes instructions à chaque fois, tu les écris une seule fois, et Claude s'en souvient pour toujours.
Pas de plugin. Pas d'extension. Pas de clé API. Pas de config. Tu crées un fichier `CLAUDE.md` à la racine, et Claude Code le prend en compte.
Sans CLAUDE.md, Claude Code est un stagiaire brillant mais amnésique. Avec, c'est un développeur senior qui connaît ton code par cœur.
Avant vs Après : chiffres réels
Voici ce qui a changé pour moi après avoir mis en place CLAUDE.md :
| Métrique | Avant | Après |
|---------|-------|--------|
| Temps par feature | 2-3 heures | 30-45 minutes |
| Erreurs de structure | Chaque session | Quasi zéro |
| Refactoring majeur | Toutes les 2 semaines | 1 fois en 3 mois |
| Rejets App Store | 3 avant approbation | Première soumission acceptée |
| Frustration | 8/10 | 2/10 |
La première session après avoir créé mon CLAUDE.md, j'ai demandé : "ajoute un écran settings avec dark mode toggle." Claude a créé le fichier au bon endroit, utilisé le bon pattern de state management, suivi ma convention de nommage, et ajouté la route. Sans que je précise quoi que ce soit.
C'est là que j'ai compris que c'était un game-changer.
Les 4 sections clés d'un bon CLAUDE.md
Après avoir itéré sur le mien à travers 2 apps publiées, j'ai identifié 4 sections essentielles.
### 1. Vue d'ensemble du projet
Le pitch en 30 secondes de ton projet. Ce qu'il fait, pour qui, quelle stack. Ça donne à Claude le contexte global pour qu'il comprenne le *pourquoi* de ton code, pas juste le *quoi*.
Court : 5-10 lignes max. Stack, plateformes cibles, dépendances clés.
### 2. Architecture
La section la plus importante. Un arbre de dossiers complet montrant où chaque type de fichier va. Pas juste "il y a un dossier features/" mais la hiérarchie complète avec des commentaires.
Mon erreur initiale : Une description vague. Résultat : Claude mettait un service dans widgets/, un modèle dans screens/, un utilitaire dans lib/. Le chaos total.
La solution : Un arbre littéral. Maintenant Claude sait que les services API vont dans `lib/core/services/`, les écrans dans `lib/features/{name}/screens/`, et les modèles dans `lib/features/{name}/models/`. Zéro ambiguïté, zéro fichier au mauvais endroit.
### 3. Conventions
Des règles strictes, pas des suggestions. Claude suit les ordres parfaitement, mais il suit les suggestions vagues… vaguement. Sois direct.
Mauvais : "Essaie d'utiliser const quand possible."
Bon : "TOUJOURS const. JAMAIS var. JAMAIS let sauf si mutation nécessaire."
Mauvais : "Le nommage devrait être cohérent."
Bon : "Fichiers : kebab-case. Classes : PascalCase. Variables : camelCase. Sans exception."
Inclus 2-3 snippets de code réels de ton projet montrant tes patterns. Un exemple de 5 lignes de ton pattern d'appel API vaut plus que 3 paragraphes d'explication.
### 4. Journal d'erreurs
L'arme secrète que la plupart des gens ignorent. Chaque fois que Claude fait une erreur ou que tu rencontres un bug inattendu, documente-le ici. "Firebase Auth : utiliser signInWithCredential, PAS signInWithPopup sur mobile" ou "Build iOS : toujours lancer pod install --repo-update avant archive."
Avec le temps, ça devient la mémoire institutionnelle de ton projet. Claude ne refera jamais la même erreur deux fois parce qu'il lit le journal d'erreurs au début de chaque session.
Mon journal a 50+ entrées sur 2 apps. Ça me fait gagner des heures chaque semaine.
Résultats concrets : 2 apps publiées
Je ne suis pas développeur. Pas de diplôme en info. Pas de bootcamp. Je crée des apps avec Claude Code comme copilote IA, et CLAUDE.md est ce qui fait que ça marche.
Résultats :
- 2 apps publiées sur l'App Store et Google Play
- 30-45 minutes par feature au lieu de 2-3 heures
- 47 fichiers dans un projet, tous suivant exactement la même architecture
- Première soumission acceptée sur les deux stores (après 3 rejets avant CLAUDE.md)
- Projet laissé 2 mois, au retour tout était clair grâce au CLAUDE.md
Le ROI n'est pas juste la vitesse. C'est la cohérence (chaque fichier suit le même pattern), la maintenabilité (tu comprends ton propre projet des mois plus tard), et la confiance (Claude ne cassera pas ton architecture si les règles sont claires).
Comment créer le tien en 15 minutes
- Ouvre ton projet, regarde la structure des dossiers
- Écris la vue d'ensemble (stack, plateformes, objectif)
- Documente l'arbre d'architecture complet avec commentaires
- Liste 5-7 conventions strictes (utilise "TOUJOURS" et "JAMAIS")
- Ajoute 2-3 patterns de code réels de ton projet
- Commence un journal d'erreurs (même vide pour l'instant)
- Sauvegarde en `CLAUDE.md` à la racine du projet
15 minutes de travail. Des mois de temps gagné.
4 templates prêts à l'emploi
J'ai packagé les CLAUDE.md exacts que j'utilise dans le ByNeel Starter Kit. Quatre variantes : Flutter, Next.js, Python/FastAPI, et un template Universel adaptable à n'importe quelle stack.
Plus un guide de 60+ pages, 15 prompts prêts à coller, une checklist App Store, et des scripts de setup. Tout ce que j'aurais voulu avoir quand j'ai commencé.