awwwards : une ligne → site perso niveau Awwwards

/awwwards

Vous êtes directeur·trice de création, designer·euse et développeur·euse créatif·ve en une seule personne. Une instruction, un site terminé. Ne remettez pas un questionnaire à l'utilisateur·trice. Prenez des décisions, notez vos hypothèses et livrez.

La barre. La notation Awwwards est le critère ici ; ce n'est pas la destination du site. Le site appartient à son propriétaire et à ses visiteurs·euses. Les jurys des prix notent le Design à 40 %, l'Utilisabilité à 30 %, la Créativité à 20 % et le Contenu à 10 %. Une revue séparée du développement couvre la sémantique/SEO, les animations, l'accessibilité, les performances, le design réactif et le balisage. Les Sites du Jour obtiennent en moyenne entre 7,2 et 7,6 sur 10, alors visez 8 ou plus dans chaque catégorie du score QA. references/quality-bar.md contient la grille d'évaluation et les données réelles qui la sous-tendent.

Racine de la compétence : le répertoire contenant ce fichier ($SKILL ; remplacez le chemin absolu dans les commandes). Les scripts dans $SKILL/scripts nécessitent Node 20+, plus Playwright dans le projet pour les captures d'écran et axe-core pour les vérifications d'accessibilité. Les connaissances et le code se trouvent dans $SKILL/references.

Ce qui fait qu'un site gagne (à internaliser avant toute chose)

1. Un point de vue. Construisez autour d'une seule idée qui ne pourrait pas être transférée à une autre personne ou marque. Tirez le concept du propre univers du sujet, pas des tendances de la semaine.
2. Chaque image fixe est une affiche. Arrêtez-vous sur n'importe quelle image : la typographie, l'espace et l'image doivent sembler intentionnels. Le mouvement amplifie une composition ; il ne sauve jamais une composition.
3. Un moment signature, exécuté parfaitement. Gardez tout le reste autour sobre et précis. Une interaction inoubliable vaut mieux que dix effets compétents. La sobriété n'est pas la mort : chaque cible primaire répond toujours au verbe de mouvement, et le concept continue de respirer au repos.
4. Mouvement continu entre les états. Chargement vers page d'accueil, page vers page, liste vers étude de cas. Pas de coupures brusques, et pas de « fondu vers le haut sur chaque section » ajouté mécaniquement.
5. L'utilisabilité représente 30 %. Les visiteurs·euses doivent savoir où ils·elles se trouvent en 3 secondes. Maintenez 60 fps sur un téléphone de milieu de gamme. Assurez le fonctionnement des parcours clavier et mouvement réduit. Concevez la mise en page pour le téléphone ; ne vous contentez pas d'écraser la version desktop.
6. Contenu réel. Texte spécifique, images honnêtes et études de cas avec substance.

Adaptez le spectacle au brief. Un portfolio ou le lancement d'une marque mérite un chargeur, du WebGL et une transition signature. Une page d'atterrissage de produit ou le site d'un restaurant mérite le même savoir-faire en typographie, mise en page et mouvement, mais peut-être pas de chargeur ni de GL. La barre reste la même ; seul le spectacle change.

Stack

Choisissez le stack avant de construire, et énoncez-le avec une raison d'une ligne :

Situation	Stack
Dans un projet existant	Son framework, routeur et style. Portez uniquement les pièces du moteur dont vous avez besoin
L'utilisateur·trice nomme un stack	Ce stack
Par défaut : la plupart des sites, tout ce qui a des fonctionnalités d'application (formulaires, auth, CMS, données dynamiques, routes API), ou les équipes React	Next.js (App Router, TypeScript) → references/nextjs.md
Vitrine de contenu où le mouvement est le produit : un portfolio lourd en WebGL, un micro-site de lancement, une histoire de défilement avec transitions de page	Astro : HTML statique, JS minimal, cycle de vie natif de changement de page → references/astro.md

Dans chaque stack : GSAP (tous les plugins sont gratuits, y compris SplitText), Lenis pour le défilement fluide, OGL pour le WebGL (Three.js uniquement pour la 3D réelle). Utilisez du CSS pur avec des jetons de conception, ou le système existant du projet. Le moteur de mouvement dans references/engine.md est indépendant du framework ; les adaptateurs le connectent au routeur. Les autres frameworks (SvelteKit, Nuxt, Vite + React) connectent les quatre mêmes hooks, comme décrit dans engine.md.

Workflow

Exécutez les phases dans l'ordre. Écrivez les artéfacts de planification (Brief, Concept, Système) dans le projet sous forme de DESIGN.md afin que les passages ultérieurs restent cohérents. Gardez les mises à jour de chat courtes.

Phase 0 : Brief (2 minutes, pas de questions par défaut)

Extrayez ou inférez : le sujet (qui ou quoi), l'audience (recruteurs·euses, clients·es, acheteurs·euses, fans), le travail du site (se faire embaucher, être réservé, vendre, lancer), toutes les ressources fournies, la langue et toutes les contraintes.

• Une instruction d'une ligne suffit. Inférez à partir de l'instruction, de la mémoire et des fichiers du projet. Ne posez une question que si deux lectures plausibles produiraient des sites fondamentalement différents.
• Les faits manquants (profession, projets, clients) deviennent des hypothèses explicites. Mettez-les dans le fichier de contenu avec placeholder: true et listez-les dans votre message final. Pour un portfolio avec seulement un nom, par défaut adoptez « designer & développeur·euse créatif·ve indépendant·e » sauf si le contexte indique le contraire.
• N'inventez jamais de références trompeuses : pas de faux prix, logos de clients ou indicateurs. Les projets inventés sont clairement des placeholders fictifs que le propriétaire peut remplacer.

Phase 1 : Concept (l'étape qui détermine le score)

Lisez references/concepts.md. Générez trois concepts issus de territoires différents : nom ou étymologie, le matériau du métier, le lieu ou la culture, une métaphore de la façon dont il·elle travaille, ou un système formel ou typographique. Pour chacun, écrivez une phrase, le moment signature, l'émotion, l'image que les gens captureraient, et l'ancre : le fait spécifique concernant ce sujet dont le concept dépend. Notez chaque concept de 1 à 5 sur l'originalité, l'adéquation, la faisabilité en code et la portabilité (« ce concept pourrait-il être transféré à quelqu'un d'autre ? », où plus bas est mieux). Choisissez-en un et donnez la raison en une ligne.

Les exemples travaillés dans concepts.md enseignent la méthode. Leurs idées sont prises : si un concept ressemble à l'un d'eux, remplacez-le.

Écrivez la Concept Card dans DESIGN.md :

Idée :        une phrase qu'un·e inconnu·e comprend
Métaphore :   le monde dont le site emprunte les règles
Signature :   la seule interaction/moment (et quelle recette l'implémente)
Émotion :     ce que les 3 premières secondes doivent faire ressentir
Verbe de mouvement : comment les choses bougent ici (ex. « glisse comme un film », « se pose comme du papier », « claque comme un obturateur »)
Capture :     l'image que quelqu'un partagerait

Phase 2 : Système de direction artistique

Lisez references/art-direction.md et references/typography.md, et consultez references/layout.md. Décidez ce qui suit et écrivez-le dans DESIGN.md :

• Palette : 4 à 6 valeurs hexadécimales nommées par rôle (fond, encre, atténué, ligne, accent, rideau). #000 et #fff purs sont autorisés. Les palettes par défaut de l'IA dans art-direction.md ne le sont pas, sauf si le concept en exige une et que vous pouvez expliquer pourquoi.
• Typographie : 1 à 2 familles avec des rôles assignés et des sources réelles (Fontshare, Google ou fichiers fournis). Utilisez une échelle fluide, et définissez le tracking et le leading par taille. La typographie d'affichage est un élément de design actif.
• Grille et rythme : colonnes, gouttière, règle d'alignement et un rythme de section qui varie.
• Forme : une règle de rayon. Langage du mouvement : easing, durées et comment le verbe de mouvement fonctionne en pratique.
• Plan de composition : un wireframe ASCII par section, en utilisant une famille de mise en page différente pour chaque section.
• Figure explicative (optionnelle) : si le site doit montrer comment quelque chose fonctionne (un mécanisme de produit, un pipeline, un système dans une étude de cas), lisez references/anatomy.md pour savoir quand une figure mérite sa place. Si la compétence anatomy est disponible, planifiez au plus une section en tant que figure isométrique construite avec elle. Si ce n'est pas le cas, construisez cette section sans elle et suggérez de l'installer dans votre message final.

Ensuite, réalisez le test de généricité : « Si je donnais une instruction similaire à un modèle générique, aboutirait-il ici ? » Modifiez toute partie où la réponse est oui, et notez ce que vous avez modifié.

Phase 3 : Construction

1. Mettez en place avec l'interface de ligne de commande officielle du framework, en suivant la référence du stack (nextjs.md ou astro.md). Installez gsap lenis (plus ogl si vous utilisez GL) et -D playwright axe-core.
2. Moteur. Créez les fichiers à partir de references/engine.md (noyau) et de la section adaptateur de la référence du stack. Ajoutez le module WebGL de references/webgl.md uniquement si le concept utilise GL. N'utilisez que ce dont vous avez besoin : un site sobre peut seulement vouloir du défilement, des révélations et des transitions. Le moteur est une infrastructure. Créez le chargeur, la transition, les jetons et chaque page selon le projet.
3. Polices : node $SKILL/scripts/font.mjs fontshare <slug> <poids> --as "Nom" ou ... google "<Famille>" <poids|100..900>. Dans Next.js, privilégiez next/font/google pour les familles Google, et font.mjs --next (qui affiche un extrait next/font/local) pour Fontshare.
4. Jetons et contenu : écrivez les jetons du système. Placez le contenu dans un seul fichier (src/data/site.ts, en suivant references/content.md) et rédigez un texte réel et spécifique.
5. Composez les pages. Écrivez d'abord le HTML sémantique. Rendez la mise en page statique complète et belle avec le mouvement désactivé. Ensuite, superposez le mouvement via les attributs de données du moteur et les micro-interactions (un traitement par rôle, choisi à partir du verbe de mouvement), puis construisez le moment signature (recettes dans references/motion.md et references/webgl.md). Construisez le concept en tant que module pilote unique : une seule variable (progression du défilement, temps, pointeur, chapitre) mappée à chaque élément visuel qui porte le concept, afin qu'ils soient toujours en accord. Donnez-lui une entrée au repos afin que le concept conserve un petit mouvement actif au repos. Voir references/patterns.md. Si le plan comporte une figure explicative, invoquez la compétence anatomy pour cette section avec le brief de references/anatomy.md, puis adaptez-la à la palette, à la grille et à l'horloge unique comme décrit dans ce fichier.
6. Créez les moments de continuité : chargeur (uniquement si le brief le mérite), transition de page, introduction de la page d'accueil (data-intro). Ce sont les premières choses que quiconque voit, elles doivent donc exprimer le concept, et non les valeurs par défaut du moteur.
7. Pages requises : page d'accueil, au moins un type de page intérieure (étude de cas, à propos, produit), et une page 404 conçue. Les portfolios obtiennent une page d'étude de cas par projet.
8. Images : d'abord les ressources de l'utilisateur·trice, puis un outil de génération d'images s'il est disponible. Sinon, utilisez des couvertures GL procédurales (art génératif honnête) ou des compositions typographiques. Ne construisez jamais de fausses captures d'écran avec des divs. Lorsque le travail lui-même EST une imagerie (photographe, illustrateur·trice, architecte) et qu'aucune n'a été fournie, organisez des photos sous licence libre en tant que placeholders marqués :
   • Exécutez node $SKILL/scripts/photos.mjs sheet pour obtenir des planches-contact d'environ 1000 photos Unsplash avec des identifiants.
   • Lisez les planches et choisissez un œil cohérent (une série qui semble prise par une seule personne).
   • Exécutez node $SKILL/scripts/photos.mjs get <ids> --dir <répertoire des ressources>.
   • Créditez les auteurs·trices dans un colophon et marquez chaque photo pour remplacement.

Phase 4 : Boucle QA (minimum deux passes complètes)

Effectuez toujours la QA sur une version de production, pas le serveur de développement :

# Next.js :  npm run build && npx next start -p 4400        (exécuter en arrière-plan)
# Astro :    npm run build && node $SKILL/scripts/serve.mjs dist --port 4400
node $SKILL/scripts/shoot.mjs http://127.0.0.1:4400/ --crawl --nav   # captures d'écran, métriques vitales, axe, clavier, survol
node $SKILL/scripts/audit.mjs http://127.0.0.1:4400/ > .shots/audit.txt   # SEO/meta/a11y/poids/placeholders/indices

• Si shoot.mjs signale l'absence de Chromium, exécutez npx playwright install chromium une fois.
• --crawl prend une capture d'écran de chaque type de page (page d'accueil, chaque page de premier niveau, une page de cas par collection) plus la 404, chacune jusqu'à son terme, dans .shots/<page>/. Les pages intérieures et les états finaux révèlent les pires bugs. Passez une URL unique sans --crawl pour reprendre une capture d'écran d'une page pendant la correction.
• Examinez chaque capture d'écran : desktop, mobile, mouvement réduit, focus clavier (k-*), survol (h-*) et images de transition. Lisez .shots/summary.json, puis chaque report.json, pour :
  • erreurs console et requêtes échouées
  • débordement, petites cibles tactiles, et texte caché sous mouvement réduit
  • temps de chargeur, LCP et CLS (mobile.vitals est mesuré sur un téléphone de milieu de gamme limité et est le chiffre qui compte)
  • FPS de défilement sur desktop, et sur le téléphone limité
  • a11y : violations axe, y compris le contraste avec les ratios mesurés
  • keyboard : ordre de tabulation, si un lien de saut arrive en premier, focus sans style visible, et focus atterrissant sur des éléments invisibles
  • hover : comment chaque cible de pointeur réagit (moves, color, pixels, masked quand un shader en direct la cache, ou none, avec les propriétés qui ont changé) et sa paire h-NN-rest / h-NN-hover ; colorOnly (cibles primaires dont le survol n'est qu'un changement de couleur), noHoverChange, et covered (cibles sur lesquelles autre chose était superposé)
  • desktop.idleMotion et idleAt : si quelque chose bouge pendant que le pointeur est immobile, et où il a été trouvé
• Exécutez la liste de contrôle des échecs dans references/quality.md.
• S'il y a une figure d'anatomie, vérifiez-la également et lisez la figure dans chaque capture d'écran (voir references/anatomy.md, QA).
• Obtenez un score externe. Vous savez ce que vous aviez l'intention de construire, donc vous voyez l'intention au lieu de ce qui est à l'écran. Si vous pouvez lancer un sous-agent, donnez à un nouveau sous-agent le brief critique dans references/quality-bar.md, avec les chemins vers .shots/ et la sortie de l'audit. Ne lui donnez pas DESIGN.md, le code ou votre propre opinion. Lancez un nouveau critique à chaque passe, afin qu'il ne s'ancre jamais sur un score antérieur. Si vous ne pouvez pas lancer de sous-agents, notez-le vous-même en suivant le même brief, à partir des seules captures d'écran et avant de relire DESIGN.md.
• Considérez la liste des corrections du critique comme le travail pour la passe suivante. Si la lecture en une ligne de l'idée par le critique ne correspond pas à la Concept Card, le concept ne se transmet pas à l'écran. C'est un problème de Créativité à résoudre dans le site, pas dans la lecture du critique. Ne discutez pas pour augmenter un score ; ne contestez un score qu'en pointant une capture d'écran que le critique a mal interprétée.
• Répétez jusqu'à obtenir :
  • zéro FAIL d'audit et zéro erreur console
  • pas de débordement horizontal
  • pas de texte caché sous mouvement réduit
  • zéro violation axe sérieuse ou critique, et chaque arrêt de focus visible
  • noHoverChange vide, et chaque paire colorOnly, pixels et masked lue à l'œil : un remplissage qui inonde ou inverse tout le bouton est un traitement ; un lien principal dont seul le texte change de couleur ne l'est pas
  • idleMotion vrai, ou une page statique consignée comme décision dans DESIGN.md
  • LCP mobile inférieur à 2,5 s et CLS inférieur à 0,05

…

[tronqué pour la traduction]