Modèles d'efficacité

Problème : Livrer des features quasi identiques une par une brûle des heures et laisse le code incohérent entre les rounds.

Gain rapide : Colle ce bloc dans ton CLAUDE.md. La cohérence s'améliore dès que Claude le lit :

# Component Generation Framework
 
When creating new [cards/forms/modals], follow the pattern in /components/examples/:
 
1. Copy the closest existing example
2. Replace data fields (keep structure identical)
3. Update types to match new data model
4. Run existing tests as template for new tests

Une règle courte comme ça empêche Claude de réinventer des patterns qui existent déjà dans ton repo.

Ce que sont les frameworks de permutation

Un framework de permutation, c'est une astuce. Tu construis 8 à 12 features proches à la main, puis tu écris un template CLAUDE.md qui permet à Claude de créer les variations 11, 12 et 13 à partir du même moule. Le pattern est capturé une fois. Claude remplit tout le reste.

Ton rôle change. Tu arrêtes de coder chaque feature et tu commences à passer en revue les variations que Claude tire d'un blueprint validé.

Les trois phases

Phase 1 : Construction manuelle des fondations

Commence par coder 8 à 12 features proches toi-même. Au fur et à mesure, note chaque décision, pattern et contrainte. Ce relevé devient la bibliothèque de référence dont Claude apprendra plus tard.

# Track your patterns
mkdir patterns/user-interfaces
# Build: LoginForm, SignupForm, ProfileForm, etc.
# Document decisions in each component

Un dashboard SaaS avec quelques tables de données rend ça concret. UsersTable, OrdersTable, InvoicesTable, ProductsTable. Construis les trois premières à la main. Round après round, les mêmes décisions reviennent : forme des colonnes, signature du gestionnaire de tri, composant de pagination, layout de l'état vide, skeleton de chargement.

Au troisième round, tu peux nommer ce qui change entre les instances (définitions de colonnes, types de données, endpoint API) et ce qui reste fixe (wrapper de table, logique de pagination, état de tri, sélection de lignes). Cet inventaire alimente la Phase 2.

Avant (construction de chaque table from scratch) :

// Each table re-implements pagination, sorting, selection...
// UsersTable: 180 lines
// OrdersTable: 195 lines (slightly different pagination)
// InvoicesTable: 210 lines (different sort logic)

Après (pattern extrait) :

// Shared DataTable component: 120 lines
// UsersTable config: 35 lines (just column definitions + endpoint)
// OrdersTable config: 40 lines
// InvoicesTable config: 38 lines

Phase 2 : Reconnaissance de patterns et templating

Repasse sur les builds manuels et extrait :

• Les structures de code répétées qui apparaissent dans chaque implémentation
• Les éléments variables qui changent d'une instance à l'autre
• Les garde-fous qualité (type safety, accessibilité, couverture de tests)
• Les vérifications qui confirment que chaque nouvelle variation fonctionne vraiment

Maintenant, écris une section CLAUDE.md qui encode ces patterns avec de vrais exemples de ce qui passe et de ce qui ne passe pas. L'astuce, c'est la concrétude. Évite "suis les patterns existants." Pointe directement vers les fichiers : "utilise l'interface de props exacte de UsersTable.tsx lignes 12-28, en remplaçant le type d'entité."

Instruction de framework faible :

Create new table components following existing patterns.

Instruction de framework solide :

# Data Table Framework
 
Reference: /components/tables/UsersTable.tsx (canonical)
 
To create a new [Entity]Table:
 
1. Props: { columns: ColumnDef<Entity>[], endpoint: string, defaultSort: SortConfig }
2. Use DataTable wrapper from /components/shared/DataTable.tsx
3. Column definitions follow the format in UsersTable lines 12-28
4. Include loading skeleton matching the column count
5. Empty state uses /components/shared/EmptyState.tsx with entity-specific message
6. Tests: copy UsersTable.test.tsx, replace User fixtures with [Entity] fixtures

La spécificité fait toute la différence. La version solide nomme des fichiers exacts, des numéros de lignes et des composants partagés. Claude n'a rien à deviner. Il suit un chemin vérifié plutôt que d'improviser.

Phase 3 : Génération automatisée

Utilise maintenant le framework. Commence par les cas faciles et laisse la difficulté augmenter au fur et à mesure que Claude prouve qu'il reste dans tes contraintes.

La première variation générée revient rarement parfaite. Compare-la ligne par ligne avec tes exemples manuels et tu trouveras un ou deux endroits où le framework n'était pas assez précis. Affine ces points, génère à nouveau, et recommence. Après trois ou quatre passes, le framework produit du code qui passe la review sans retouches manuelles.

Stratégies d'affinage du framework

Contrôle qualité par contraintes

Des règles de framework strictes réduisent la plage créative de Claude sans tuer la variation utile. Énonce les contraintes dans CLAUDE.md :

CONSTRAINTS:
 
- All components must include PropTypes / TypeScript interfaces
- Use established naming conventions (camelCase for props)
- Include accessibility attributes (aria-label, role, tabIndex)
- Follow existing file structure in /components/
- Every new component gets a co-located test file

Test de variance

Mets le framework sous pression en générant 5 à 10 variations et en les comparant côte à côte. Si elles dérivent trop, reviens et ajoute des exemples plus précis et des contraintes plus strictes dans le template CLAUDE.md.

Un run concret avec un framework d'endpoints API a illustré le problème. Sur les 3 premiers endpoints générés, la gestion d'erreurs tenait bon mais les formes de réponse divergeaient. L'un renvoyait { data: ... }. Un autre enveloppait le payload comme { result: ... }. Le troisième renvoyait l'objet brut sans wrapper. Une nouvelle ligne dans le framework a tout réglé : "Tous les endpoints renvoient { data: T, error: null } ou { data: null, error: ErrorShape }." La variance a disparu des 8 générations suivantes.

Amélioration itérative

Chaque passe de framework affine deux choses à la fois : à quel point Claude respecte ton pattern, et à quel point tu comprends ce qui rend le code généré par IA fiable.

Framework de permutation en action

Un walkthrough concret. Disons que tu as construit UserCard, ProductCard et OrderCard à la main. Tu ajoutes ça dans CLAUDE.md :

# Card Component Framework
 
Reference: /components/cards/UserCard.tsx (canonical example)
 
To create a new [Entity]Card:
 
1. Props: { data: [Entity], onClick?: () => void, variant?: 'compact' | 'full' }
2. Structure: Avatar/Icon + Title + Subtitle + Action buttons
3. Styling: Use existing Tailwind classes from UserCard
4. Tests: Copy UserCard.test.tsx, replace User with [Entity]

Demande à Claude de "créer une SubscriptionCard" et le résultat adopte la même forme. Même structure de props, même approche de styling, même couverture de tests. Tu ne pourrais pas la distinguer d'une carte construite à la main, parce qu'elle vient du même blueprint.

Patterns d'efficacité courants

Endpoints API : Frameworks pour des routes avec gestion d'erreurs, validation et formes de réponse correspondantes. Définis ton pattern de schéma Zod, ton format de réponse d'erreur et ta chaîne de middleware une fois chacun. Un nouvel endpoint passe d'une heure à 15 minutes.

Composants UI : Frameworks pour des composants de design system gérant différents types de données. L'exemple de carte s'applique directement aux modales, formulaires, éléments de liste et vues de détail. Si un composant existe déjà en 3+ variantes, il mérite d'être transformé en framework.

Opérations base de données : Frameworks pour le CRUD avec gestion de transactions partagée entre les modèles. Définis le query builder, l'approche de pagination et le comportement de soft-delete une fois. Les nouveaux modèles s'insèrent sur les mêmes rails.

Quand NE PAS construire un framework

Les frameworks ne sont pas gratuits. En construire un trop grand te coûte, de la même façon que du code sur-conçu.

Un ou deux exemples, c'est trop peu. Trois versions construites à la main est le minimum. À deux, le framework se verrouille sur ces cas exacts et ne généralise pas.

Évite les frameworks pour les features uniques. Un seul dashboard admin personnalisé sans homologues n'ajoute qu'une surcharge et ne rembourse rien. Garde le budget framework pour les patterns qui se répètent.

Attends que les patterns se stabilisent. Dans le premier mois d'un projet, les formes de composants changent chaque semaine. Un template rigide verrouillé en semaine un signifie du rework en semaine deux. Stabilise la forme avec 8 à 10 builds manuels d'abord.

Évite la sur-contrainte. Si les règles sont si strictes que Claude ne peut pas gérer la vraie variation, le framework coûte plus qu'il ne rapporte. Les bonnes contraintes verrouillent la structure et laissent de la place pour les détails spécifiques à l'entité.

Métriques de succès pour les frameworks

Surveille ces indicateurs pour confirmer que le framework gagne sa place :

• Score de cohérence : Les variations générées s'alignent-elles avec tes exemples manuels sur les imports, les formes de props et la structure de fichiers ? Un bon framework obtient un score élevé en correspondance structurelle.
• Vitesse d'implémentation : Un framework bien réglé raccourcit notablement le chemin de la demande à la feature fonctionnelle. Pas de vrai gain de vitesse signifie qu'il faut plus de détails, ou que les patterns ne sont pas encore bien définis.
• Temps de review : Combien de temps prend une passe de validation ? Ce chiffre doit baisser au fur et à mesure que le framework mûrit. Les premières sorties demandent une review attentive. Les sorties matures n'ont besoin que d'une lecture rapide.
• Fréquence de bugs : Compare les bugs par variation générée avec les bugs par feature construite à la main. Un bon framework réduit le nombre parce qu'il intègre des patterns que tu as déjà testés en production.

Du scaling linéaire au scaling exponentiel

Le développement classique scale linéairement. Un développeur produit une feature à la fois. Les frameworks de permutation réécrivent ce calcul. Un seul framework produit de nombreuses variations, et ta vélocité grimpe.

Le gain est le plus important dans les codebases où des patterns répétés servent différents utilisateurs mais partagent le même moule technique. Les retours s'accumulent. Une fois que tu as des frameworks pour les composants, les endpoints API et les opérations de base de données en place, une nouvelle feature qui couvre ces trois couches se livre en une fraction du temps habituel, parce que chaque couche a déjà son blueprint prêt.

Actions suivantes :

1. Aujourd'hui : Scanne ton repo à la recherche de 3 composants proches. Les cartes, formulaires et modales sont les meilleurs points de départ.
2. Cette semaine : Transforme ces proches en ton premier framework en notant exactement ce qui reste constant entre eux.
3. Approfondir : Étudie les techniques CLAUDE.md qui rendent la documentation de framework efficace.
4. Connexe : Utilise les modes de planification quand une demande de framework devient complexe.
5. Optimiser : Utilise les stratégies de sélection de modèle pour ajuster le coût par rapport à la qualité.
6. Automatiser : Configure des boucles de feedback pour que les améliorations s'accumulent.
7. Expérimenter : Lance des tests de variance systématiques pour confirmer que la sortie du framework tient la route.