Communitygithub.com

Conception de pages d’atterrissage

Concevoir et construire des pages marketing mémorables et compréhensibles, que les agents IA lisent avec précision – pages produit, de lancement, d’accueil, de tarification, d’attente, de fonctionnalités, mono-page, d’événement ou de campagne.

Qu'est-ce que Conception de pages d’atterrissage ?

Cette compétence guide la conception de pages d’atterrissage performantes, centrées sur le sujet plutôt que sur des tendances éphémères. Elle s’applique à tous types de pages marketing (accueil, tarification, liste d’attente, etc.) et repose sur un brief précis, une direction artistique issue du produit lui-même, une rédaction factuelle et des preuves réelles. Elle interdit les témoignages inventés, l’urgence artificielle et les pages génériques. La compétence consomme les tokens de marque de `brand-identity` et respecte les principes de `interface-guidelines`. Elle s’exécute sur les assistants comme Claude Code, Cursor ou Codex, avec un ordre de construction progressif : brief → direction artistique → wireframe texte → HTML sémantique → tokens → états → performances → vérification.

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/thecatthatflies/interface/tree/HEAD/skills/landing-page-design

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Que fait Conception de pages d’atterrissage ?

Une page d’atterrissage a une seule mission : faire comprendre à un visiteur spécifique de quoi il s’agit, l’en convaincre et l’amener à une prochaine action. Elle attire l’attention par une idée distincte et la retient par des faits clairs. Les modèles commettent deux erreurs opposées. Le plus souvent, ils produisent la page interchangeable : un titre vague, trois cartes avec icônes, des témoignages inventés et un mur de logos, dans un style choisi pour paraître moderne. Lorsqu’on leur demande d’éviter cela, ils traquent les « signes d’IA » et remplacent un ensemble d’artifices à la mode par un autre. Le remède est le même pour les deux : partir du sujet, dire quelque chose de spécifique et de vrai, et donner à la page une idée que seul ce produit pourrait posséder.

Appliquer les principes hiérarchisés de interface-guidelines (tout le monde peut l’utiliser > elle dit la vérité > elle dit ce qu’elle veut dire > la réponse vient en premier > les erreurs sont réparables > elle reste en place > le possible est visible > convention > polissage). Si cette compétence est installée, lire d’abord son SKILL.md.

Brief

Répondre à ces questions en moins de 20 lignes avant toute maquette. Si l’utilisateur est absent, énoncer les hypothèses et continuer.

  • Qui arrive, d’où, en sachant quoi ? Un clic publicitaire, une recherche sur le problème, un lien d’un ami, un investisseur. Leur connaissance préalable détermine ce que le premier écran doit expliquer.
  • La prochaine action et ce qu’elle coûte : email, carte, appel, téléchargement. Tout le reste sur la page est secondaire.
  • L’affirmation : une phrase disant ce que c’est, pour qui, et ce qui change pour eux. Si vous ne pouvez pas l’écrire, la page n’est pas prête à être conçue.
  • Preuves disponibles : vrais clients, citations avec permission, chiffres avec source et date, démo, offre gratuite. Lister ce qui existe. Une preuve manquante est une lacune à signaler, pas à combler.
  • Prix : public, à partir de, cas représentatifs, ou vraiment inconnu.
  • État de la marque : la sortie de brand-identity existe-t-elle (jetons, logo, typographie, voix) ? Sinon, l’exécuter d’abord, ou travailler à partir d’une direction provisoire et le préciser.
  • Le matériel du sujet : à quoi ressemblent le produit, ses utilisateurs et son univers (section « Direction artistique »).
  • Lecteur agent : les assistants vont-ils comparer ce produit, citer son prix ou inscrire quelqu’un ? Supposez oui.
  • Contraintes : pile technique, CMS, budget de performance, langues, aspects juridiques (allégations réglementées, droit des prix, consentement).

Direction artistique

La famille ne prescrit pas un style. Le gras, l’étrange, le calme et le maximaliste sont tous autorisés. Ce qui est exigé, c’est que le style vienne d’une décision sur ce sujet, et qu’il laisse le terrain intact (lisible, rapide, opérable). Faire cette étape par écrit avant le code ; references/art-direction.md contient la méthode et des exemples travaillés.

  1. Rassembler le matériel du sujet [J]. Lister 10 à 20 noms concrets issus du produit et de son univers : objets qu’il manipule, ce que les utilisateurs créent avec, lieux, artefacts, sons, textures, le langage visuel propre au domaine (un tableau des marées, une fiche de recette, une trace de circuit, une étiquette d’expédition). Les mots génériques (« vitesse », « innovation », « sans couture ») ne comptent pas.
  2. Trouver le concept [J]. Une phrase qui transforme ce matériel en idée de page : « la page est le résultat du produit », « un guide de terrain », « un tableau des départs pour vos déploiements ». Appliquer le test de substitution : si un concurrent pouvait utiliser le concept sans changement, le réécrire.
  3. Choisir un geste mémorable [J]. Un élément porte le concept et reçoit le budget d’audace : un moment réel du produit montré en grand, une démo fonctionnelle, un geste typographique de la marque, un objet que l’on peut manipuler, une photo que seule cette entreprise pourrait prendre. Tout le reste sert la lecture. Une page avec cinq gestes signatures n’en a aucun.
  4. Composer [J]. Décider le chemin de lecture de chaque écran : où l’œil se pose en premier, deuxième, troisième, et quelle taille et contraste rendent cela possible. Définir la grille, puis la briser une fois, intentionnellement. Concevoir la composition téléphone comme une mise en page propre, pas une version réduite du bureau.
  5. Proposer deux ou trois directions en quelques lignes chacune (concept, geste signature, utilisation des jetons de marque, risque), en choisir une et expliquer pourquoi. Les directions doivent différer par l’idée, pas seulement par la palette.

Limite de la marque. Les couleurs, la typographie, le logo, la voix et les jetons proviennent de brand-identity (son tokens.css ou tokens.json). La direction artistique décide comment cette page les utilise : échelle, recadrage, densité, rythme, imagerie, mouvement. Ne pas ajouter de nouvelles couleurs de marque, redessiner le logo ou changer les polices pour une page. Si la page a besoin de quelque chose que la marque ne possède pas (un style d’illustration, une direction photographique), le noter comme un écart de marque et le proposer au propriétaire de la marque.

Le goût n’est pas une preuve. Supprimer les dégradés, les sourcils ou une police particulière n’améliore pas une page : les tests en aveugle du goût-compétence n’ont gagné que 4 des 16 tours de brief contre aucune compétence, malgré zéro échec de détection, et ses juges modèles ont préféré les pages plus riches remplies d’artifices de modèles [E, jurés modèles uniquement]. Juger donc les directions par le test de substitution et la tâche du lecteur, pas par une liste d’éléments interdits.

Règles

Message

  • Le premier écran indique ce que c’est, pour qui, et la prochaine étape, en mots compréhensibles par un inconnu [E]. Les visiteurs décident de partir dans les 10 à 20 premières secondes (Liu, White, Dumais 2010, via NN/g), et la première page écran reçoit environ 57 % du temps de visionnage (NN/g 2018, n=120). Une ligne astucieuse peut mener, mais une ligne descriptive simple doit se trouver juste à côté.
  • Le h1 est l’affirmation, pas le nom de la marque ni un salut [S]. C’est la racine du plan de la page pour les lecteurs d’écran et les agents (WCAG 2.4.6).
  • Le concret bat le promotionnel [E]. Un texte concis, scannable et objectif a obtenu 124 % de meilleure convivialité qu’un texte promotionnel (Nielsen 1997, n=51 ; ancien, mais la tendance s’est maintenue). Dites « Envoie des factures à partir de vos feuilles de temps », pas « Boostez votre flux de travail ».
  • Chaque section fait une affirmation et montre sa preuve ; supprimer les sections sans preuve [J]. Écrire la page comme une liste d’affirmations avant de la concevoir (idée empruntée au goût-compétence).
  • Montrer le produit lui-même [J] : écrans réels, résultats réels, photographies réelles. Une abstraction dessinée de « productivité » ne dit rien et une interface inventée dénature le produit.
  • Les gens défilent, donc éviter les faux planchers [P]. En dessous du premier écran, l’attention diminue mais ne disparaît pas (NN/g 2018). Un héros en plein écran qui semble complet cache tout ce qui le suit.

Preuve et honnêteté

  • Seulement des preuves réelles [S]. Les avis et témoignages faux ou générés par IA sont illégaux aux États-Unis (FTC 16 CFR Part 465, 2024), et les recommandations doivent refléter une expérience réelle (FTC Endorsement Guides, 16 CFR Part 255). Logos uniquement avec permission et uniquement de clients réels.
  • Quand la preuve manque, la signaler [J]. Utiliser des espaces réservés visibles comme {{citation : client, nom, rôle}} et les lister dans la remise. Ne jamais écrire un faux convaincant pour combler le vide.
  • Les chiffres portent une source et une date [J]. « 12 000 équipes » nécessite « en mars 2026 ». Un chiffre que personne ne peut vérifier est au mieux une décoration.
  • Pas d’urgence fabriquée [E]. Les faux comptes à rebours et la fausse rareté faisaient partie des motifs trompeurs trouvés à grande échelle (Mathur et al. 2019), et ils induisent aussi les agents en erreur : six agents web ont succombé aux dark patterns en moyenne 41 % du temps (Ersoy et al. 2025, preprint).

Tarification

  • Afficher les prix [P]. Les prix manquants poussent les acheteurs vers les concurrents (Nielsen 2002). Lorsque le prix varie vraiment, montrer des cas représentatifs avec leurs prix (Nielsen 2006).
  • Les prix sont du texte : montant, devise, période et ce qui est inclus, jamais uniquement dans une image [J]. La comparaison des plans est un vrai <table> avec les fonctionnalités en mots.
  • Indiquer le total que l’acheteur paiera, y compris les frais obligatoires [S]. La loi américaine l’exige pour les billets d’événements en direct et l’hébergement de courte durée (FTC Rule on Unfair or Deceptive Fees, 2025) ; ailleurs, c’est une pratique honnête. Les allégations de remise dans l’UE doivent montrer le prix le plus bas des 30 jours précédents (Directive 98/6/CE, Art. 6a).
  • Les bascules de facturation montrent l’état et la valeur par défaut [J]. Si le prix annuel est affiché par défaut, dire « facturé annuellement » à côté du chiffre.

Prochaine étape

  • Une action principale, répétée aux points de décision, étiquetée avec ce qui se passe [J] : « Commencer un essai de 14 jours, sans carte », « Rejoindre la liste d’attente ». Les actions secondaires semblent secondaires.
  • Les formulaires de liste d’attente et d’inscription demandent le minimum et disent ce qui suit [J] : ce qu’ils obtiennent, quand, et à quelle fréquence vous enverrez des emails. Les cases de consentement commencent non cochées. Confier les flux plus longs à form-design.
  • Le succès est un état, pas un toast [J]. Après soumission, remplacer le formulaire par ce qui s’est passé et à quoi s’attendre.

Rapidité et robustesse

  • Atteindre les Core Web Vitals de Google au 75e centile : LCP 2,5 s, INP 200 ms, CLS 0,1 [S]. Ce sont des cibles en partie fixées par la faisabilité, pas des seuils de perception humaine. Les pages mobiles plus rapides étaient corrélées à une conversion plus élevée dans le commerce de détail selon une étude commandée par Google (Deloitte 2020) [E, corrélation].
  • Le héros est généralement l’élément LCP [S] : une vraie <img> avec width, height et fetchpriority="high", jamais chargée paresseusement, jamais un arrière-plan CSS derrière du texte qui attend le script (web.dev).
  • Le contenu est visible sans JavaScript et sans mouvement [J]. Les révélations au défilement commencent depuis l’état visible et s’animent uniquement si pris en charge ; avec mouvement réduit, rien ne se cache. Les agents et les captures d’écran obtiennent sinon des blancs.
  • Pas de carrousels à avancement automatique [P]. Les héros rotatifs cachaient l’offre aux utilisateurs lors des tests (Nielsen 2013), et un mouvement de plus de 5 secondes nécessite un contrôle de pause (WCAG 2.2.2).

Le lecteur agent

  • Les faits qu’un assistant citera sont du texte sur la page : ce que c’est, le prix, les limites du forfait, les plateformes, les conditions d’essai, le contact [J]. Les agents comparent les produits exactement à partir de ces éléments.
  • Les données structurées et les balises méta reflètent la page visible et n’ajoutent rien [S] : title, méta-description, Open Graph et JSON-LD (Organization, SoftwareApplication ou Product) avec le même prix et le même nom que la page affiche. Un balisage ajouté n’a pas aidé les agents lors des tests (Affora, dans interface-guidelines).
  • Pas de texte adressé aux agents IA, caché ou visible [J]. Il est perçu comme une injection d’invite, et le texte caché est un signal de spam.

Ordre de construction

  1. Brief, puis la liste d’affirmations et preuves, avec des espaces réservés pour les lacunes.
  2. Direction artistique : matériel du sujet, concept, un geste, deux ou trois propositions, choix.
  3. Maquette texte : sections dans l’ordre, chacune avec son affirmation, sa preuve et son action.
  4. HTML sémantique avec vrai contenu : un h1, points de repère, titres qui résument l’argument, tableau de tarifs, formulaires avec étiquettes.
  5. Jetons de marque de brand-identity, puis mise en page et le geste signature.
  6. États : validation de formulaire, succès, échec, liste d’attente fermée ou épuisée, sans JS, mouvement réduit.
  7. Images, polices et scripts dans le budget de performance.
  8. Vérifier, corriger au maximum deux fois, remettre.

Vérifier

  • node <interface-guidelines>/scripts/audit.mjs <dist|url> --out audit-output, puis regarder chaque capture d’écran aux trois largeurs, en clair et en sombre si les deux existent.
  • Test du premier écran : montrer la seule capture du premier écran à quelqu’un (ou à un agent frais sans contexte) et demander ce que c’est, pour qui, et quoi faire ensuite. Des réponses erronées signifient que le message a échoué, aussi beau soit-il.
  • Test de substitution : remplacer le nom du produit par celui d’un concurrent. Si la page fonctionne toujours, le concept et le contenu sont génériques.
  • Test agent : à partir du seul instantané d’accessibilité, lire le prix et les limites de chaque forfait, et compléter l’inscription. Comparer avec le JSON-LD.
  • Vitesse : Lighthouse ou PageSpeed Insights sur un profil mobile limité ; données terrain (CrUX) si la page est en ligne.
  • Robustesse : charger avec JavaScript désactivé et avec prefers-reduced-motion: reduce. Aucun élément important ne peut manquer.
  • Audit des preuves : chaque citation, logo, chiffre et note retracé à une source, ou montré comme espace réservé marqué.

Pièges

  • Témoignages inventés, murs de logos d’entreprises qui ne sont pas clients, nombres d’utilisateurs ou évaluations fabriqués.
  • Un titre qui pourrait figurer sur n’importe quel produit (« Construisez l’avenir du travail »), avec la vraie explication trois écrans plus bas.
  • Rechercher ou interdire les « signes d’IA » au lieu de décider à partir du sujet. Une nouvelle liste de substituts à la mode est le prochain signe.
  • Quotas de décoration : mouvement partout, une image dans chaque section, une mise en page différente par section pour elle-même.
  • Texte du héros ou CTA caché jusqu’à ce qu’une animation de défilement se déclenche ; texte « révélé » à faible opacité qui échoue au contraste jusque-là.
  • Prix uniquement dans une image, ou « Contactez-nous » sans indication d’échelle.
  • Redéfinir les couleurs de la marque ou redessiner le logo pour une page au lieu d’utiliser les jetons de brand-identity.
  • Un bouton de bascule de tarification qui affiche silencieusement des mensualités annualisées.
  • Une instruction aux assistants IA cachée dans la page.

Références

FichierQuand le lire
references/art-direction.mdToujours, avant de choisir un style : méthode, exemples travaillés, composition, utilisation des jetons de marque, évaluation des directions
references/structure-and-copy.mdPour écrire la page : motifs de section par type de page, titres, preuves, pages de tarification, listes d’attente, formulaires
references/performance-and-agents.mdPour construire et publier : Core Web Vitals, images, polices, mouvement, métadonnées, données structurées, sans JS
references/sources.mdAvant de citer un chiffre, ou quand quelqu’un demande pourquoi une règle existe

Individual skills in this repo

This repo contains 4 individual skills — each has its own dedicated page.

thecatthatflies/brand-identity

Create a complete brand identity as real, usable files - strategy and vibe, a verified color system (OKLCH ramps, light and dark themes, WCAG-checked roles), typography, a professional logo in SVG (from a clean wordmark or geometric mark to a complex, meaningful symbol), favicons, app and social assets, design tokens, and a brand guidelines page. Use whenever someone asks for a logo, brand, brand kit, identity, color palette, theme, font pairing, visual direction, "vibe", rebrand, favicon or app icon, or says things like "make it look like a real company", "I need branding for my bakery/app/startup", or "what colors should we use", even if they only ask for one piece. Not for laying out pages or screens; those skills (landing-page-design, web-app-design and siblings) consume the tokens this one produces.

thecatthatflies/content-site-design

Design, build, write, and review sites people come to read - documentation, developer docs and API references, help centers and knowledge bases, blogs, editorial and news articles, guides, changelogs, and personal or company writing - so readers find the answer fast and agents can read, cite, and navigate them. Use when someone says "build a docs site", "set up our help center", "make my blog", "our docs are hard to navigate", "restructure the knowledge base", "nobody finds anything with search", "write this page so people understand it", "make our docs work for AI coding agents", or when choosing page structure, headings, navigation, search, typography for long reading, or llms.txt and Markdown versions of pages. Not for marketing or launch pages meant to convert (use landing-page-design), app screens (use web-app-design), or visual identity (use brand-identity).

thecatthatflies/form-design

Design, build, and review forms and multi-step flows that people finish without errors and agents can fill without guessing - sign-up and sign-in, checkout and payment details, address and contact forms, applications, onboarding questionnaires, wizards, settings forms, validation and error messages, passwords and passkeys. Use whenever someone builds or fixes a form ("add a sign-up form", "our checkout converts badly", "make these errors better", "why won't autofill work", "turn this into a wizard"), even if they only mention one field. Includes a rendered-page checker for labels, autocomplete, input types, paste, and error wiring. Not for the surrounding app shell, tables, or settings navigation (web-app-design), store layout and product pages (ecommerce-design), or native desktop dialogs (desktop-app-design).

thecatthatflies/web-app-design

Design, build, and review SaaS and internal web application UI that people use for work and agents can operate - app shells and navigation, list and detail views, data tables with sorting, filtering, bulk actions and pagination, empty states, settings, onboarding, roles and permissions, workspace or tenant switching, optimistic updates and undo, command palettes, and URL-driven view state. Use whenever building or reviewing an admin panel, CRM, back office, internal tool, project tracker, or any logged-in product ("build me an admin for orders", "our app feels clunky", "add bulk delete", "make the table filterable", "add an org switcher"), even when the request names only one screen. Not for KPI and monitoring pages (dashboard-design), forms and wizards in depth (form-design), marketing pages (landing-page-design), native desktop shells (desktop-app-design), or AI chat surfaces (ai-chat-design).

Skills associés