Clone un design que tu aimes — avec les bons garde-fous

Le nouveau chantier de Léa : un site qui en jette

Le système de contenu de Léa tourne tout seul — et son trafic monte. Problème : sa page d'accueil, bricolée il y a deux ans, ne suit plus. Elle a repéré le site d'une marque de thé japonaise dont le design l'émerveille : une mise en page aérée, une palette douce, une typographie élégante. Elle aimerait ce niveau de finition pour sa propre marque. La bonne nouvelle : Claude Code lit les images. La méthode de ce chapitre lui permet d'analyser ce design, d'en extraire les principes, et de reconstruire sa version — pas une copie.

Retiens cette distinction dès maintenant, car tout le chapitre repose dessus : on ne clone pas un site, on clone ce qui le rend bon — sa grille, ses proportions, son rythme, sa hiérarchie visuelle. Le contenu, les couleurs de marque et les images seront ceux de Léa. C'est la différence entre apprendre d'un maître et plagier son tableau.

Étape 1 : capturer et faire analyser

Commence par des captures d'écran du site admiré : la page entière, puis des zooms sur les zones clés (header, section héros, grille de produits, footer). Glisse-les directement dans Claude Code — il lit les images nativement, dans l'extension comme dans le terminal. Mais ne demande pas « fais-moi le même site » : tu obtiendrais une imitation approximative. Demande d'abord une analyse structurée, car c'est elle qui transforme une impression visuelle en spécifications exploitables :

analyse cette capture d'écran de site web comme un designer senior.
donne-moi une analyse structurée :

1. LAYOUT : structure de la page, grille (nombre de colonnes, gouttières), largeur max du contenu
2. PALETTE : chaque couleur en hex, son rôle (fond, texte, accent, bordures), les ratios d'usage
3. TYPOGRAPHIE : familles probables, tailles (titre/sous-titre/corps), graisses, interlignage, casse
4. ESPACEMENTS : le rythme vertical entre sections, les paddings internes des cartes/boutons
5. HIÉRARCHIE : dans quel ordre l'œil circule, et quels procédés créent cet ordre (taille, contraste, espace)
6. SIGNATURE : les 3 choix qui donnent sa personnalité à ce design

ne génère AUCUN code pour l'instant.

Le « ne génère aucun code pour l'instant » est volontaire : c'est le Plan Mode du chapitre 2 appliqué au design. Tu veux d'abord valider que l'analyse capte ce que tu aimes dans ce site. Lis le point 6 en particulier — la « signature » — et corrige si besoin : « non, ce qui me plaît surtout, c'est le contraste entre les grandes photos et le texte minuscule ». Cette conversation cadre tout ce qui suit.

Étape 2 : extraire les design tokens

L'analyse validée, on la convertit en design tokens : des variables CSS qui codifient chaque décision visuelle (couleurs, tailles, espacements). C'est l'étape qui change tout par rapport à un clonage naïf : les tokens séparent le système de design (réutilisable) des valeurs (que Léa remplacera par les siennes). Voici le prompt complet :

à partir de ton analyse, génère un fichier tokens.css contenant les design tokens en variables CSS :

:root {
  /* couleurs : fond, surface, texte, texte-secondaire, accent, accent-hover, bordure */
  /* typo : familles, tailles (échelle modulaire), graisses, interlignages */
  /* espacements : échelle (xs, sm, md, lg, xl, 2xl) cohérente avec le rythme observé */
  /* divers : radius, ombres, largeur max du contenu */
}

contraintes :
- chaque variable est commentée avec son rôle
- l'échelle d'espacement doit être une vraie échelle (ratio constant), pas des valeurs au hasard
- propose ensuite une SECONDE palette : même logique de contrastes, mais avec les couleurs de ma marque (vert sauge #87A96B, crème #F5F0E8, brun #5C4033)

Regarde bien la dernière contrainte : on demande la transposition vers la palette de Léa dès cette étape. Le design admiré fournit la logique des contrastes (fond clair, accent saturé utilisé avec parcimonie, texte presque noir mais pas tout à fait) ; les valeurs deviennent celles de la marque. C'est le moment précis où le projet cesse d'être une copie pour devenir une création informée.

Étape 3 : reconstruire TA version

Maintenant seulement, on construit — avec les contenus de Léa : ses produits, ses photos, ses textes (que ton skill /post sait déjà rédiger dans sa voix). Demande une page qui consomme exclusivement les tokens : aucune couleur ni taille en dur dans le HTML. Cette discipline paie doublement : changer un token met à jour tout le site, et tu peux faire évoluer la palette sans toucher à la structure.

construis ma page d'accueil en HTML/CSS en utilisant exclusivement
les variables de tokens.css (aucune valeur en dur).

structure : header épuré, section héros avec ma photo de la gamme solaire,
grille de 3 produits, bandeau « engagements », footer.
contenus : utilise les textes de content/accueil.md.
images : uniquement celles du dossier assets/ (mes photos).

respecte le layout et le rythme analysés, PAS les contenus du site d'origine.

Étape 4 : itérer par écarts

La première version sera proche mais pas juste — c'est normal, et la pire réaction serait de tout redemander en vrac (« c'est pas encore ça, recommence »). La bonne méthode est l'itération par écarts : on compare systématiquement, on liste, on corrige point par point. C'est la même boucle d'affinage qu'au chapitre 4 pour la voix de marque, appliquée au pixel :

voici une capture de MA page actuelle et la capture du site de référence.
compare les deux comme un directeur artistique et liste les 10 différences
les plus visibles, classées par impact visuel décroissant.

pour chaque différence : ce que fait la référence, ce que fait ma version,
et la correction précise (quel token ou quelle règle CSS modifier).

ensuite corrige-les UNE PAR UNE en me montrant le résultat à chaque étape.

Le « une par une » a la même fonction que dans le cadrage du chapitre 3 : il rend chaque changement observable. Si une correction dégrade l'ensemble (ça arrive — l'espacement parfait de la référence peut étouffer tes contenus plus denses), tu la refuses isolément au lieu de jeter tout le lot. Deux ou trois passes de cette boucle suffisent généralement à passer de « ressemblant » à « finition professionnelle ».

Aller plus loin : analyser la structure réelle d'une page publique

Les captures montrent le rendu, pas la mécanique. Pour comprendre comment un effet est obtenu (cette grille qui se réorganise élégamment sur mobile, ce header qui se condense au scroll), tu peux demander à Claude de récupérer une URL publique et d'analyser le HTML/CSS réel — c'est l'outil WebFetch, que tu as autorisé au chapitre 2 :

récupère https://exemple-de-marque.com et analyse la structure :
- comment la grille des produits est construite (grid ? flex ? breakpoints ?)
- comment le header gère le scroll et le mobile
- quelles variables CSS ou conventions de nommage ils utilisent

objectif : comprendre la TECHNIQUE pour appliquer la même logique
à ma page, avec mes tokens. ne copie aucun contenu ni aucun asset.

flowchart LR
  A["Capture d'écran du site admiré"] --> B["Analyse structurée (designer senior)"]
  B --> C["Design tokens : tokens.css"]
  C --> D["Reconstruction avec TES contenus et TA palette"]
  D --> E["Comparaison côte à côte : 10 écarts"]
  E -->|"Corrections une par une"| D
  E -->|"Finition atteinte"| F["Page de Léa en ligne"]

La frontière éthique et légale : s'inspirer, pas copier

Parlons franchement de la ligne à ne pas franchir, parce qu'elle est plus nette que ce qu'on croit. Les idées de design — une grille, des proportions, un rythme d'espacements, le principe d'une palette douce — ne s'approprient pas : tout le web s'inspire de tout le web, et c'est ainsi que les standards progressent. En revanche, les assets sont des œuvres protégées : logos, illustrations, photos, icônes dessinées sur mesure, textes. Les copier n'est pas de l'inspiration, c'est de la contrefaçon — peu importe que ce soit « juste pour s'inspirer » ou que Claude l'ait fait pour toi.

Garde-fous techniques : verrouiller le projet avec allow/deny

Un chantier de refonte implique beaucoup de commandes : installation de dépendances, serveurs locaux, manipulations de fichiers. C'est le bon moment pour approfondir les permissions du chapitre 2 avec une vraie politique allow/deny écrite dans .claude/settings.json — donc commitée et partagée avec quiconque rejoindra le projet :

{
  "permissions": {
    "allow": [
      "Bash(npm run:*)",
      "Bash(npm install:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "WebFetch(domain:fonts.google.com)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)",
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

Lis la liste deny ligne par ligne, car chaque règle raconte un accident évité : rm -rf (la suppression récursive qui emporte un dossier entier sur un chemin mal construit), git push --force (qui peut écraser l'historique partagé), et la lecture de .env — oui, on peut interdire à Claude de lire un fichier : tes clés API n'apparaîtront jamais dans le contexte, donc jamais dans une réponse. Et souviens-toi du chapitre 2 : deny l'emporte toujours sur allow, même si une règle d'autorisation large l'englobe.

Complète avec CLAUDE.local.md pour tes préférences personnelles de chantier : « le serveur de prévisualisation tourne sur le port 4321 », « mes captures de référence sont dans ~/Bureau/refs/ ». Ces détails t'appartiennent ; ils n'ont rien à faire dans la mémoire commune du projet.

Permission ou hook : deux serrures complémentaires

Tu disposes maintenant de deux mécanismes de protection, et il est utile de voir précisément comment ils s'articulent :

La règle de répartition : ce qui est interdit toujours et partout relève des permissions — c'est binaire, autant le déclarer une fois. Ce qui dépend du contenu (« ce post dépasse-t-il la limite ? respecte-t-il la voix ? ») relève d'un hook, car il faut examiner pour décider. Les deux couches ensemble, plus la validation humaine au point de levier (chapitre 7), forment la défense en profondeur de ton système : Léa peut laisser Claude travailler vite précisément parce que les garde-fous, eux, ne dorment jamais.