Compétence Création de Site Web v2.0
Origine : Le produit final a été jugé « ringard ». J'ai donc ouvert des sites créés par un autre service IA sur le même sujet, je les ai mesurés moi-même, et j'ai transformé les bonnes pratiques en procédures dans mes propres mots. Ceci n'est pas une question de goût, mais uniquement de valeurs mesurées et de ce que j'avais négligé à ce moment-là.
Ce qu'il faut savoir en premier (prémisse de tout le reste)
La différence majeure, révélée par la comparaison, résidait dans la préparation avant de commencer à créer. La démarche la plus efficace a été la suivante :
Avant de commencer à écrire, verbaliser la philosophie de conception et la fixer dans un fichier avec des contraintes négatives.
Le site de référence contenait, en haut de sa feuille de style, une brève description de la stratégie d'affichage et de ce qu'il ne fallait pas faire.
(La méthode d'écriture et les modèles se trouvent dans reference/DESIGN_THESIS.md. La structure à utiliser à l'étape 0 s'y trouve également.)
Ma version ratée était exactement ce qui est interdit : une répétition de cartes centrées et uniformes. Je savais que si on ne faisait rien, on finissait inévitablement par là, alors je l'avais interdite en amont. C'est la seule différence.
Ces 6 points sont tout ce qui compte
- Écrire la thèse avant d'écrire, et la fixer dans un fichier. Les déclarations dans une conversation disparaissent.
- Inclure au moins 2 contraintes négatives. Sans interdire explicitement la valeur par défaut, on ne peut pas s'en éloigner.
- Utiliser deux polices : Mincho + Gothic. Une seule police donne l'air d'un panneau d'administration, quoi qu'on fasse.
- Ne pas aligner de cartes centrées uniformes. Diviser en asymétrie. Placer au moins une bande de couleur foncée.
- Aucune image n'est inacceptable. Si vous n'avez pas de matériel, générez-le. Dans ce cas, indiquez clairement qu'il s'agit d'une « image ».
- Le rendu n'est pas terminé tant que vous ne l'avez pas vu de vos propres yeux. « Ce n'est pas cassé » n'est pas une évaluation.
⚠ Accidents passés réels (3 cas)
Accident 1 — Confondre « pas cassé » avec « bon »
J'ai vérifié qu'il n'y avait pas de défilement horizontal et que les tableaux tenaient, puis j'ai expédié. Ce n'étaient que des vérifications de non-dysfonctionnement, sans aucune évaluation de l'attrait. Le résultat : un livret sans points négatifs, mais aussi sans points positifs.
Méthode de détection : cet accident se produit lorsque les logs de vérification ne contiennent que des expressions comme « X ne s'affiche pas », « X tient dans son espace ».
Accident 2 — Accepter la contrainte « pas de matériel » sans chercher de solution de contournement
« Je ne peux pas obtenir de photos réelles » → décidé « pas d'images ». J'avais la capacité de générer des images, mais je ne l'ai pas utilisée. L'honnêteté n'est pas une raison pour abandonner les images. La garantie se fait par des annotations.
Méthode de détection : si vous supprimez du livret final un élément demandé (par exemple « des photos aussi »), suspectez toujours ce problème.
Accident 3 — Une inspection mécanique réussie à 100%, puis un défaut visuel détecté à l'œil nu
Après que verify.py soit passé au vert, en zoomant à 25% j'ai vu que le h1 était coupé et s'affichait sur deux lignes
(par exemple Brûlé à point, livré. / sur place., avec 1 ou 2 caractères en fin de phrase tombant sur la ligne suivante. L'exemple est fictif).
C'est un type de défaut qu'une inspection numérique ne pourra jamais capturer.
Contre-mesure : ne pas omettre l'inspection visuelle en §5.
verify.pyexporte automatiquement une image pour l'inspection visuelle. Vous devez la lire absolument.
§1 Procédure
Étape 0. Écrire la thèse (avant le HTML, obligatoire)
Lire reference/DESIGN_THESIS.md. On y trouve les 6 modèles et un catalogue de contraintes négatives.
Choisir un modèle → adapter le nom au sujet → choisir au moins 2 contraintes négatives →
au moins une doit être remplacée par une contrainte spécifique au sujet → inscrire dans le commentaire d'en-tête de template.html.
Design : « XXXX » — {déclaration visuelle en une phrase}.
Règles visuelles : {contrainte négative 1} ; {contrainte négative 2} ; {contrainte négative 3}.
Règle d'information : {règle de disposition de l'information}.
Ensuite, une seule déclaration à la personne qui a passé la commande. Si une dissonance apparaît, on peut arrêter avant de commencer à écrire.
◆ Politique de design
Thèse : « XX » — {déclaration} / Interdits : {au moins 2 contraintes négatives}
Palette : Montagne (vert) / Indigo / Céramique ← l'une d'elles, ou nouvelle
Tailles : h1=1280px à 70px / h2=51px / Marges : sections haut/bas 120px
Images : {photos réelles / illustrations générées N points (avec annotation d'image) / figures}
Composition : hero → {bloc} → bande foncée → tableau de faits → conclusion
Étape 1. Collecter les faits (si le sujet existe réellement)
- Priorité aux bases de données publiques. Site de consultation des numéros d'entreprise, systèmes de publication des autorisations et agréments par secteur (ceux gérés par l'État ou les collectivités locales). Ils ont une autorité supérieure aux portails sectoriels et permettent souvent d'obtenir le numéro d'autorisation ou d'agrément. Exemple (fictif) : « Le numéro d'agrément de l'école XX de la ville de Midori, qui n'avait que le nom et le numéro de téléphone sur le portail sectoriel, a pu être vérifié sur la page de publication de la collectivité locale. »
- **Si les sources divergent, écrivez honnêtement les deux comme « différence de notation ». ** Ne vous rapprochez pas silencieusement de l'une ou l'autre.
- **S'il n'y a aucun avis, ne créez pas de section d'avis. ** Ne jamais inventer.
Étape 2. Préparer le matériel (ne pas avancer sans image)
Examiner dans l'ordre et ne pas déclarer « pas d'image » sans pouvoir en donner la raison par écrit.
- Obtenir des photos réelles du client
- Générer (si l'environnement le permet, utiliser un outil de création d'image) + ajouter obligatoirement une annotation de source
- Remplacer par des figures, schémas, datavisualisations
- Se contenter de typographie et de surfaces colorées (= le préciser comme un choix intentionnel)
Les consignes de style et les interdictions sont dans reference/DESIGN_SYSTEM.md §6. Ne pas générer de visages humains.
Après génération, compresser pour le Web (référence : 7,4 Mo → 566 Ko. Ne pas publier une image à 1,8 Mo).
Étape 3. Assembler
assets/satoyama.css … lien <link> directement (la palette change par la classe body)
assets/template.html … remplacer tous les {{ }}
**Conserver impérativement le héro asymétrique et la bande foncée. ** L'affectation de chaque bloc est dans reference/DESIGN_SYSTEM.md §5.
⚠ **Le h1 ne doit pas dépasser 7 caractères par ligne. ** Au-delà, le retour automatique casse la mise en page (accident 3).
Étape 4. Mesurer
python ~/.claude/skills/homepage/verify.py path/to/index.html
Mesure la présence de la thèse, le nombre de contraintes négatives, les tailles de police, les marges, le nombre d'images, la séparation des polices, la bande foncée, la répétition de structure,
le dépassement horizontal sur 3 largeurs, et exporte une image pour inspection visuelle dans _review/.
Étape 5. Voir (ne pas sauter, ne peut pas être remplacé par une machine)
Lire impérativement _review/review-25percent.png et review-desktop.png exportés par verify.py.
- Regarder en réduction — le contraste persiste-t-il ? Si tout ressemble à une bande grise uniforme, manque de bande foncée ou de marge.
- Lire uniquement les titres — le sens est-il cohérent ? S'il n'y a qu'une liste de mots-clés, violation de R-11.
- Regarder le premier écran seul — sans défilement, donne-t-il une idée claire de « de qui, de quel lieu il s'agit » ?
- Chercher les défauts — coupures de titres, débordements, images manquantes. L'accident 3 n'est détectable qu'ici.
- **Verbaliser le bien et le mal en une phrase. ** « Pas de dysfonctionnement » n'est pas une évaluation. Ne pas expédier sans pouvoir le verbaliser.
§2 Valeurs de référence des mesures (déterminées par comparaison avec des livrets d'autres IA)
| Élément | Référence | Valeur d'échec passée |
|---|---|---|
| Thèse présente dans le fichier | Obligatoire | Absente |
| Nombre de contraintes négatives | ≥2 | 0 |
| h1 rendu (1280px) | ≥56px (recommandé 70px) | 46px ← plafonné par le clamp() |
| h2 rendu (1280px) | ≥40px (recommandé 51px) | 30px |
| Padding haut/bas de section | ≥100px (recommandé 120px) | 76px |
| Nombre d'images | ≥1 (recommandé 4) | 0 |
| Polices | Différentes pour titres et corps | 1 police |
| Bande pleine largeur foncée | ≥1 emplacement | 0 |
| Diversité des structures | Plus de la moitié des blocs principaux de structure différente | Tous identiques |
⚠ Le nombre de couleurs n'a pas fait la différence. La version ratée avait 15 jetons de couleur, soit plus que les 10 de la version réussie. Ce qui fonctionne, c'est la thèse, la police, la taille, la marge, l'image et la copie.
§3 Exigences (ne pas expédier sans les satisfaire)
- R-1 Séparer les polices pour les titres et le corps. Pour les titres en japonais, privilégier le Mincho comme première option.
- R-2 Pour un rendu à 1280px, h1≥56px / h2≥40px. Mesurer si la limite supérieure de
clamp()n'est pas plafonnée. - R-5 Padding haut/bas de section sur desktop ≥100px. La quantité d'information n'est pas une raison pour réduire la densité.
- R-7 Aucune image n'est inacceptable (passer par les 4 étapes de l'étape 2).
- R-8 Pour les images générées, mentionner clairement en position visible « image (pas une représentation réelle de XX) ».
- R-9 Toutes les sections ne doivent pas avoir le même motif. Placer au moins une bande de couleur foncée pleine largeur.
- R-11 Ne pas utiliser d'étiquettes fonctionnelles pour les titres de sections. Déporter les mots de table des matières vers
.label. - R-13 Ne pas omettre l'accessibilité (skip-link / focus visible / alt / reduced-motion).
- R-14 Fixer la thèse en tête de fichier et y inscrire au moins 2 contraintes négatives.
- R-15 Regarder l'image rendue de vos propres yeux, verbaliser le bien et le mal en une phrase, puis expédier.
§4 Interdictions de contenu (lorsqu'il s'agit de magasins ou d'établissements réels)
- Ne pas inventer d'avis ou de témoignages d'utilisateurs. Si 0, écrivez 0, et placez uniquement un appel à contribution.
- Ne pas faire comme s'il y avait des photos réelles alors qu'il n'y en a pas. Les images générées doivent être impérativement annotées.
- Ne pas copier les photos ou textes d'autres sites. Les intégrations (Instagram embed officiel, etc.) sont autorisées.
- Ne pas promettre d'effets ou d'améliorations (particulièrement dans le médical, le social, l'éducation). Se contenter de publier des faits.
- Ne publier qu'après autorisation du client. Ne pas publier sans permission une page se présentant comme une organisation réelle. Si c'est pour un exercice ou une étude, laisser un commentaire en tête de fichier à cet effet.
- Lorsqu'on traite du matériel avec des enfants, vérifier impérativement l'autorisation de publication.
§5 Fichiers
~/.claude/skills/homepage/
├── SKILL.md Ce manuel de procédure
├── verify.py Inspection par mesures réelles + export d'image pour inspection visuelle
├── assets/
│ ├── satoyama.css Système de design principal, inclut 3 palettes
│ ├── template.html Structure (avec cadre de thèse en en-tête)
│ └── placeholder.svg Image temporaire pour fonctionner même sans matériel défini
└── reference/
├── DESIGN_THESIS.md ★ Très important. Comment écrire la thèse, 6 modèles, catalogue de contraintes négatives
└── DESIGN_SYSTEM.md Justification de chaque valeur, 10 types de blocs, comment créer le texte
Ordre de lecture au démarrage : DESIGN_THESIS.md → DESIGN_SYSTEM.md → template.
Copier uniquement les chiffres ne reproduira pas les modèles. La thèse vient en premier.
§6 Situations où ce système n'est pas utilisé
Tableaux de bord d'administration, tableaux de comparaison, LP centrés sur des comparaisons, annonces urgentes, UI de jeux, contenus déjà soumis à une charte graphique. Les grands titres en Mincho et les grandes marges y auraient l'effet inverse.