Construis un site produit néo-brutaliste, multipage et sans JavaScript pour
[nom du produit ou de la startup] sur le site
[nom du serveur] de mon serveur d'hébergement Opus Growth. Produit :
[ce qu'il fait, pour qui]. Fonctionnement :
[trois étapes]. Fonctionnalités clés :
[4 à 6 fonctionnalités]. Tarifs :
[noms et prix des formules, ou "pas de page tarifs"]. Liens de téléchargement ou d'inscription :
[App Store, Google Play ou URL d'inscription]. Contact :
[e-mail],
[téléphone],
[numéro WhatsApp],
[adresse]. Domaine :
[domaine]. Couleurs de marque :
[couleurs, ou "tu choisis"]. Vraies photos ou captures d'écran :
[liens, ou "aucune"].
Pages : accueil (/), comment ça marche (/nasil-calisir/ ou /how-it-works/), tarifs (/fiyat/), à propos (/hakkimizda/), contact (/iletisim/), confidentialité (/gizlilik/) et 404.html. Sections de l'accueil dans l'ordre : hero (h1, intro en deux phrases, deux boutons, badges stickers et élément signature), bandeau de catégories, trois étapes, pour qui (avec une photo), fonctionnalités, FAQ et appel à l'action final. Pas de formulaire sur la page contact ; à la place, e-mail, téléphone, lien WhatsApp avec message prérempli et liens de téléchargement, car le serveur ne sert que des fichiers statiques.
Style : néo-brutaliste, mais comme un produit, pas comme un jouet. Bordures noires épaisses (3 pixels), ombres dures sans flou (noir uniquement, décalages de 4, 6 et 10 pixels), aplats de couleurs vives (cinq couleurs unies au maximum, par exemple tomate, citron, menthe, bleu ciel et lilas sur fond crème), badges légèrement inclinés qui ressemblent à des stickers. Typographie : une police d'affichage massive et pleine de caractère issue de Fontshare (par exemple Chubbo) avec une grotesque posée pour le texte courant (par exemple Supreme 400 et 700). Pas de dégradés, pas d'effet verre, pas d'ombres douces et pas de fondus violet-bleu. Le site n'a aucun JavaScript ; GSAP, Lenis et Swiper ne sont pas chargés. Élément signature : à droite du hero, une carte à bordure épaisse qui dessine l'écran principal du produit en vrai HTML plutôt qu'en image (par exemple les dépenses du mois d'un foyer et le règlement de fin de mois), avec des stickers collés tout autour.
Règles de couleur, de contraste et de mouvement (là où ce style perd le plus facilement des points) :
1. Écris le texte en noir sur tous les fonds colorés et n'utilise jamais de texte blanc. Calcule le ratio de contraste de chaque couleur contre le noir et note-le dans un tableau dans ART.md ; fonce toute couleur sous 4,5. Dans la démo, le ratio le plus bas était de 6,7 sur l'orange tomate, et l'accessibilité était à 100 sur chaque page.
2. Fais un anneau de focus de 3 pixels noir avec un décalage de 3 pixels, qui passe au jaune citron dans un pied de page noir. Utilise outline-offset pour que l'anneau de focus ne se confonde pas avec la bordure épaisse.
3. Réalise le décalage ludique des boutons et des cartes uniquement avec transform et box-shadow : au survol translate(-2px, -2px) et une ombre plus grande, à l'appui translate(4px, 4px) et aucune ombre. Les boutons font au moins 48 pixels de haut, les petits boutons au moins 44.
4. Mets l'inclinaison des stickers dans la propriété `rotate` séparée, pas dans transform, et définis l'angle avec une classe de propriété arbitraire Tailwind comme `
[--r:-4deg]`. Ainsi les stickers restent inclinés même quand la règle reduced-motion réinitialise transform, et aucun attribut style="" n'est nécessaire.
5. Fais l'entrée « slap » des stickers avec `scale` et `translate` uniquement, dans `@media (prefers-reduced-motion: no-preference)` et avec un attribut data-reveal="slap" (design-check reconnait le mouvement grace à cet attribut). Pas de masquage avec opacity, et le h1 ne bouge jamais. Avec prefers-reduced-motion: reduce, toutes les animations et transitions sont désactivées.
6. Marque les stickers décoratifs avec aria-hidden="true" ; les badges porteurs d'information (par exemple « gratuit jusqu'à 6 personnes ») restent de simples éléments de liste. Sur mobile, masque un sticker décoratif sous 640 pixels s'il chevauche un autre badge au coin de la carte ; dans la démo, le sticker « reçu ajouté » recouvrait le badge « 3 personnes » à 390 pixels.
Mise en place et pièges connus (chacun a couté des points ou fait échouer un contrôle dans la mesure de la démo, ne rien sauter) :
1. Si un site est déjà en ligne sur le serveur, préviens-moi d'abord, car la mise en place écrase index.html et le dossier assets. Prévisualise d'abord scaffold_site avec confirm=false, puis appelle confirm=true une fois que j'ai donné mon accord. Lis ensuite site_design_guide et site_seo_guide. Avant d'écrire du code, rédige la direction de design (typographie, couleur, grille, élément signature, langage de mouvement et bibliothèques qui ne seront PAS chargées) dans un court ART.md en dehors d'assets et montre-le-moi.
2. Compile Tailwind, ne le charge pas depuis le CDN. Installe `npm i -D tailwindcss@3` avec site_run_command et background=true, puis enchaine avec site_command_status. Les chemins content de `tailwind.config.js` doivent couvrir tous les fichiers HTML, sous-dossiers compris, les modèles `_src/*.tpl` et tout fichier JS qui écrit des classes. `_src/tw.css` contient la ligne `@import "../assets/app.css";` et les trois lignes `@tailwind` ; compile-le en un seul fichier avec `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Retire des pages le script cdn.tailwindcss.com, le tailwind.config en ligne, chrome.js et motion.js, et ne lie que `/assets/site.css`. Recompile après chaque modification du HTML. Ce site n'a aucun fichier JavaScript, donc la liste content n'a pas besoin d'entrées JS.
3. Auto-héberge les polices. Lis le CSS de Fontshare avec une requête par famille et par graisse (`https://api.fontshare.com/v2/css?f[]=family@weight`), télécharge chaque fichier woff2 dans `assets/fonts/` avec site_fetch et écris les règles @font-face avec `font-display: swap` dans `assets/app.css` ; design-check cherche la police personnalisée à cet endroit. Précharge CHAQUE graisse utilisée au-dessus de la ligne de flottaison (titres, texte courant et boutons) sur chaque page avec `<link rel="preload" as="font" type="font/woff2" crossorigin>` et place ces lignes avant le lien de la feuille de style. La plupart des polices Fontshare n'ont pas le signe ₺, écris donc les prix avec « TL ».
4. Fais du menu et du pied de page du HTML statique. Écris un petit `chrome-stamp.mjs` qui lit la liste de navigation dans site.config.js et estampille `_src/header.tpl` et `_src/footer.tpl` entre les marqueurs `<!-- nav:start --><!-- nav:end -->` et `<!-- footer:start --><!-- footer:end -->` sur chaque page, en ajoutant aria-current="page" au lien actif. Ne donne pas aux modèles l'extension .html et utilise des espaces réservés comme `
[[NAV]]` au lieu de `{{...}}`. Construis le menu mobile avec `<details>` et sans JS. Garde le nom de l'entreprise, l'adresse et le téléphone en texte brut dans le pied de page, et donne aux liens du pied de page et du fil d'Ariane une hauteur d'au moins 44 pixels.
5. Convertis les images pendant leur téléchargement avec site_fetch : écris la même photo dans des fichiers séparés avec resize="480x", "800x" et "1120x" (ou les largeurs dont la page a besoin), image_format="webp" et quality=65. Donne à chaque `<img>` srcset, sizes ainsi qu'une width et une height correspondant au vrai ratio. L'image principale au-dessus de la ligne de flottaison reçoit fetchpriority="high" et n'est pas en lazy ; ne donne fetchpriority qu'au véritable élément LCP, et loading="lazy" decoding="async" aux autres.
6. Écris un petit `favicon.svg` à la racine du site et ajoute `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` à chaque page ; s'il existe un logo PNG, fabrique une apple-touch-icon avec site_fetch, resize="180x180" et image_format="png". Sans favicon, le navigateur enregistre une erreur 404 pour /favicon.ico et Best Practices tombe à 96.
7. Règles du validateur HTML : commence chaque document par un `<!DOCTYPE html>` en majuscules, mets les attributs entre guillemets doubles, utilise ` ` pour les espaces dans le texte visible des liens tel:, n'utilise jamais d'attribut style="" (si tu as besoin d'une variable CSS, utilise une classe de propriété arbitraire Tailwind comme `
[--r:-4deg]`), donne à chaque bouton type="button", ne mets pas aria-label sur des éléments sans rôle comme `<ul>` ou `<div>`, et utilise `<section aria-label="...">` à la place de role="region".
8. Si le pied de page a un fond noir, mets ses liens en crème avec un survol citron, et garde chacun à au moins 44 pixels de haut.
SEO, AEO et GEO :
1. Utilise des URL de type répertoire avec une barre oblique finale (/nasil-calisir/, /fiyat/, /hakkimizda/, /iletisim/, /gizlilik/ ou leurs équivalents dans ta langue). Renseigne le bloc seo de site.config.js et exécute `node seo-stamp.mjs`. Pour une startup sans boutique physique, mets localBusiness:false dans site.config.js. Schémas par page : accueil WebPage et FAQPage ; comment ça marche WebPage et FAQPage ; tarifs SoftwareApplication (applicationCategory, operatingSystem et une Offer par formule) et FAQPage ; à propos AboutPage ; contact ContactPage ; BreadcrumbList sur les pages internes. Comme tu n'ajouteras pas d'avis ni de notes d'utilisateurs à SoftwareApplication, Google risque de ne pas afficher de résultat enrichi pour l'application ; ce n'est pas grave, n'invente pas de note. Écris chaque schéma propre à une page dans son propre bloc `<script type="application/ld+json">` et relie-le au graphe de base avec @id. N'imbrique pas BreadcrumbList dans @graph ; garde-le dans son propre bloc, car c'est la seule façon pour seo-check de le voir.
2. Titres de 48 à 60 caractères (seo-check considère plus de 65 comme une erreur), descriptions de 145 à 158 caractères, un seul h1 par page. Le contenu principal de chaque page fait au moins 150 mots. Dans la démo, les pages à propos, contact et confidentialité sont arrivées à 113-148 mots du premier coup ; ajoute de vraies informations, comme « quoi inclure dans une demande d'assistance » ou « avec qui les données sont partagées ».
3. Le premier paragraphe de chaque page répond directement à la question de la page, et le h1 est formulé comme cette question. Écris la FAQ propre à la page avec `<details>` et balise-la en FAQPage. Affiche l'organisation éditrice et une mention « Dernière mise à jour » avec `<time datetime>`.
4. Dans robots.txt, écris ta décision avec sa justification pour GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot et CCBot, et indique le sitemap. sitemap.xml contient un vrai lastmod. llms.txt contient un résumé exact du site en deux phrases et la liste des pages importantes.
5. Aucune invention : n'écris ni avis, ni notes, ni récompenses, ni nombre de clients, ni certificats, ni horaires d'ouverture, ni coordonnées, ni prix, ni chiffres produit sans me demander. Laisse totalement hors du schéma tout champ que tu ne connais pas.
Contrôles (dans l'ordre ; ne dis pas « terminé » avant qu'ils soient tous validés) :
1. Avec site_run_command, exécute dans l'ordre `node chrome-stamp.mjs`, la compilation Tailwind, `node seo-stamp.mjs`, `node seo-check.mjs` (0 erreur, 0 avertissement), `node design-check.mjs` (0 erreur ; justifie tout avertissement restant) et `npx html-validate "**/*.html"` (0 erreur).
2. Affiche chaque page avec site_preview, view="mobile" et view="desktop". site_preview capture la page avec le mouvement désactivé ; si le contenu n'est pas complet dans cette capture, l'état sans mouvement est cassé. Les images en lazy plus bas peuvent être vides dans une capture pleine page ; ne le compte pas comme une erreur, mais vérifie leurs chemins.
3. Lance core_web_vitals pour chaque page avec strategy="mobile" et strategy="desktop". Critères d'acceptation : sur mobile, Performance d'au moins 95 et Accessibility, Best Practices et SEO à 100 ; sur desktop, les quatre scores d'au moins 95, objectif 100. Pour une page qui échoue, trouve le fichier lent avec resources=true, corrige-le et mesure à nouveau. Lance ensuite seo_audit sur la page d'accueil avec strategy="mobile" et runs=2. La liste des requêtes réseau ne doit contenir aucune adresse extérieure à ton propre domaine (les liens vers les stores et WhatsApp sont des liens, pas des requêtes).
4. Aucun défilement horizontal à 360, 390, 768 et 1440 pixels de large, zones tactiles d'au moins 44 pixels, aucune erreur dans la console.
Contrôle d'interaction : comme site_preview ne peut pas montrer le mouvement, dis-moi ce qu'il faut observer dans mon propre navigateur : un bouton se soulève vers le haut et la gauche au survol et s'enfonce dans son ombre à l'appui ; les stickers se plaquent doucement au chargement de la page ; la navigation au clavier (Tab) montre un épais anneau de focus noir sur chaque lien ; avec « réduire les animations » activé dans le système d'exploitation, plus rien ne bouge mais les stickers restent inclinés ; avec JavaScript désactivé, le menu mobile s'ouvre toujours.
Après la publication : prévisualise la règle `/assets/* Cache-Control: public, max-age=31536000, immutable` avec site_headers et applique-la une fois que j'ai donné mon accord ; à partir de là, versionne le nom du fichier à chaque modification du CSS ou du JS (site-v2.css, etc.). Soumets sitemap.xml avec gsc_submit_sitemap et inspecte la page d'accueil avec gsc_url_inspect. À la fin, donne-moi : un tableau des scores par page (page, quatre scores mobile, quatre scores desktop, LCP, CLS), les résultats des contrôles et la liste des corrections appliquées.
