ouvrir guide/chapitre-04 --plan
Chapitre 4 · Acte I · Changer de regard
Le plan
de la maison
13 min · espace pour avancer, flèches pour revenir
Retour au chapitre 1
1 240lignes dans un seul fichier
Tout le site de Talia dans un seul app.js, réécrit en entier à chaque retouche. Je l'avais présenté comme un défaut du code.
C'était le plus grave des quatre symptômes. Il mérite son propre chapitre.
Ce n'est plus une affaire de goût
L'architecture décide de ce que Claude doit lire pour comprendre, et de ce qu'il doit réécrire pour modifier.
Donc de votre facture, de vos régressions, de votre testabilité. Et surtout de ce que vous pourrez mener en parallèle : plusieurs chantiers à la fois, ou la file indienne.
Six dégâts simultanés, pas un seul
- 01 · Le coûtPour changer une ligne dans un fourre-tout, Claude lit tout et réécrit tout. À chaque retouche.
- 02 · Les régressionsFacturation, e-mails et calendrier dans le même fichier : corriger l'un casse l'autre, sans prévenir.
- 03 · La testabilitéLà où tout se mélange, il n'y a pas d'unité à tester. Le levier n°1 du guide devient inopérant.
- 04 · La performanceUn bloc unique se charge, se compile et se teste en bloc. Chaque itération paie la taxe.
- 05 · La sécuritéUne frontière de module est une frontière de sécurité. Sans elle, secrets et données sensibles circulent partout.
- 06 · La scalabilitéSans frontières, la complexité ne grandit pas : elle explose. Le projet ralentit quand il faudrait accélérer.
Une pièce unique où chaque modification traverse tout. Ou six pièces où elle reste dans une seule.
La question n'est plus « ce découpage est-il élégant ? » mais « combien de fichiers Claude doit-il ouvrir pour cette modification ? ».
À vous
Vous demandez à Claude de changer la règle d'annulation. Sa réponse commence par « il faut que je regarde partout ». Qu'est-ce que ça dit ?
Choisissez : la scène vous répond.
Avant d'écrire la moindre ligne
❯ claude ❯ Avant de coder : audit d'architecture. Projet de prise de ❯ rendez-vous, un praticien, forfaits, annulation, rappels. ❯ Propose 2 ou 3 structures, compare-les sur la scalabilité, ❯ la testabilité et le coût de modification. Argumente. · Claude compare les options... A. Monolithe par couches (ui/, api/, db/) : rapide à démarrer, mais toute évolution traverse les trois. B. Modules par feature, clean architecture interne : plus de fichiers, chaque changement reste local. Recommandation : B. ADR rédigé, avec les conséquences.
Notez le critère qu'on oublie presque toujours : le coût de modification. Une architecture ne se juge pas sur un schéma, mais à ce qu'elle coûte six mois plus tard, un vendredi soir.
Le découpage qui change tout
Par couche technique
Un dossier par nature de fichier
- Une modification traverse cinq dossiers
- Impossible de voir ce qu'englobe une fonctionnalité
- Claude ouvre tout le projet pour une règle
Par module fonctionnel
Un dossier par fonctionnalité
- Ses propres couches à l’intérieur
- Une modification reste dans un dossier
- La frontière dit ce qui peut casser
Clean architecture au cœur, MVVM côté écrans, et surtout : une fonctionnalité, un dossier, une frontière.
Le geste qui change tout
Chaque module porte son propre CLAUDE.md et son propre PRODUCT.md. À la racine, on ne garde que le transverse.
Vingt lignes par module, chacune utile à cent pour cent quand elle se charge. Claude trouve le bon fichier immédiatement, et ne charge que le brief pertinent.
Le contexte dépensé devient proportionnel à la fonctionnalité, plus à la taille du dépôt.
La même demande, sur une maison qui a un plan
❯ Le forfait 10 séances ne se recrédite pas à l'annulation. · Claude ouvre le module concerné... Lu : annulation/CLAUDE.md (18 lignes) + 3 fichiers du module. Le reste du dépôt n'a pas été ouvert. Règle trouvée dans annulation/domain/RegleForfait.kt Corrigé, test unitaire ajouté. ✓ 12/12 verts. Rien d'autre que le module n'a été touché.
Même modèle, même prompt, même développeur derrière le clavier. Seule l'architecture a changé.
Trois sessions sur un fichier unique : trois versions concurrentes. Trois sessions sur trois modules : trois chantiers.
Ce qui rend le parallélisme possible n'est pas le nombre d'agents. C'est la frontière.
Un module indépendant est un chantier isolé
- Paralléliser→un module par session. Plus une fonctionnalité à la fois : un portefeuille de chantiers.
- Extraire→un module part vers un autre projet tel quel, avec ses tests et son mode d'emploi.
- Supprimer→une fonctionnalité abandonnée se retire en supprimant son dossier. Les tests confirment.
- Ajouter→une nouveauté naît dans son dossier, sans toucher à l'existant. Elle ne peut donc pas le casser.
Et si le projet existe déjà ?
La plupart des projets que je reprends arrivent avec leur fichier de 1 240 lignes. Tout réécrire d'un coup est rarement la bonne réponse.
- CartographierQuelles fonctionnalités cohabitent, où sont leurs frontières naturelles.
- ExtraireUn seul module, le plus autonome, avec ses tests et son CLAUDE.md.
- VérifierTout tourne encore. On livre.
- RecommencerChaque module extrait rend le suivant moins cher.
Fin du chapitre 4
Ce découpage n'est pas une astuce pour économiser des tokens : c'est la fondation de tout ce que le guide enseigne ensuite. Le projet a maintenant sa mémoire et son plan. Reste à apprendre à travailler dedans.
Rien de tout cela n'a été inventé pour les IA. Les agents ont seulement rendu la facture des mauvaises structures immédiate et chiffrable.