Création de Pages d'Atterrissage

Que fait Création de Pages d'Atterrissage ?

Ce document capture la façon dont Favour construit réellement des pages d'atterrissage qui n'ont pas l'air de modèles, distillée à partir de ses propres conversations passées pour la construction d'Allowance, didii, Revolut Founder Mode, TrashPay et le site de la conférence FlutterBytes, et affinée à plusieurs reprises par ses retours directs sur des maquettes de test réalisées avec cette compétence. Ce n'est pas un guide générique des « bonnes pratiques » — c'est spécifique à ce qu'il continue de rechercher, de corriger et de refuser. C'est aussi un document vivant : consultez references/build-log.md avant de commencer, et ajoutez-y après avoir terminé.

L'objectif à chaque fois : quelque chose avec un véritable point de vue, pas un modèle compétent avec le nom du client échangé. Et surtout : un concept qui se lit comme évident et intentionnel au premier regard, pas un qui n'a de sens qu'une fois expliqué.

---

Avant toute chose : y a-t-il assez de matière pour travailler ?

Si le brief ne donne pas un véritable produit auquel accrocher un concept — pas de nom, pas d'idée de son public, pas d'indice de ton, rien qui le distingue de la version générique de cette idée — arrêtez-vous et demandez. Une ou deux questions précises valent mieux qu'inventer une direction provisoire et découvrir plus tard qu'elle ne convenait pas.

Deux moments plus spécifiques où il faut demander plutôt que de supposer :

• Si une section bénéficierait clairement d'une vraie photo (pas d'une représentation abstraite ou vectorielle), demandez-en une avant de continuer. Si elle n'est pas disponible, dites-le et improvisez avec des dégradés et des traits au lieu de simuler une photo d'archives.
• Si une section a besoin d'un contenu d'exemple représentatif (noms d'exemple, cartes types, données factices), proposez-en d'abord une version et invitez explicitement à des modifications, plutôt que de finaliser silencieusement votre propre estimation.

S'il y en a assez — un vrai nom, un vrai public, un véritable point de différence, même approximatif — continuez.

---

Stack de construction

La cible par défaut est Next.js, TypeScript, Tailwind CSS et Framer Motion. C'est la stack réelle derrière chaque projet dont cette compétence est tirée. Jamais de HTML simple ou de JS vanilla comme livrable.

Si l'environnement de travail ne peut pas interpréter cette stack en direct, dites-le clairement plutôt que de substituer silencieusement quelque chose de plus faible. Construisez quand même de vrais composants React, jamais de JS vanilla, et approximez le mouvement prévu avec des transitions CSS ou l'API Web Animations pour l'aperçu — mais proposez aussi le véritable codebase Next.js/TypeScript/Framer Motion sous forme de fichiers téléchargeables, et dites clairement si un environnement qui peut réellement exécuter et capturer cette stack (Claude Code, par exemple) est l'endroit approprié, surtout quand le jugement visuel réel sur le résultat commence à compter plus qu'un coup d'œil rapide.

---

Les formulaires envoient toujours vers un Google Form

Tout formulaire sur le site — liste d'attente, contact, demande, inscription en tant qu'orateur, commande/réservation, peu importe — est un formulaire personnalisé, construit sur mesure dans le design du site dont les soumissions sont transmises à un Google Form en arrière-plan via le lien de pré-remplissage de ce formulaire. Le visiteur ne voit jamais un Google Form brut ; il voit le style du site, et les données atterrissent dans les réponses du Google Form (et sa feuille de calcul de réponses liée).

Demandez cela tôt, dès qu'il est clair que le site aura besoin d'un formulaire — c'est une dépendance envers la personne, comme les photos. Demandez-lui de créer un Google Form avec des champs qui correspondent à ce que le formulaire du site collecte, et de vous renvoyer son lien de pré-remplissage. Mappez ensuite chaque champ du site à l'ID d'entrée correspondant du Google Form extraite de ce lien, et soumettez-y via le gestionnaire d'envoi du formulaire (l'approche standard est un POST vers le endpoint /formResponse du formulaire avec les paramètres entry.<id>, ou l'équivalent). Si la personne n'a pas encore fourni le lien, construisez l'interface du formulaire personnalisé complètement mais laissez la cible de soumission clairement en placeholder et signalée, plutôt que d'inventer un endpoint.

Donnez toujours à la personne les étapes pour obtenir le lien de pré-remplissage d'un Google Form, car la plupart des gens ne savent pas où il se trouve :

1. Ouvrez le Google Form en mode édition.
2. Cliquez sur le menu débordement à trois points ⋮ en haut à droite.
3. Choisissez "Obtenir un lien de pré-remplissage".
4. Remplissez chaque champ avec une valeur de placeholder reconnaissable (par exemple, tapez le nom du champ lui-même), puis cliquez sur "Obtenir le lien" en bas.
5. Cliquez sur "Copier le lien" dans la popup et envoyez-le.

Ce lien contient le entry.<id> de chaque champ et est exactement ce dont vous avez besoin pour mapper les champs du formulaire personnalisé au Google Form.

---

Typographie et couleur, choisies avec la personne, pas décidées seules

Avant de vous engager sur l'une ou l'autre, faites un court point visuel plutôt que de décider silencieusement :

• Typographie : consultez references/typeface-library.md pour des candidates pas trop récemment utilisées, puis proposez trois candidates de police d'affichage distinctives et non évidentes et rendez réellement le nom du produit dans chacune d'elles, de la manière que l'environnement permet (une image, un aperçu rapide, un composant live) — ne listez jamais seulement les noms de polices sous forme de texte. Laissez la personne choisir à partir de véritables formes de lettres, pas d'une supposition sur ce qu'un nom évoque. Une police véritablement nouvelle en dehors de la bibliothèque est aussi une option bienvenue — si elle est choisie, ajoutez-la à references/typeface-library.md après. Ne sautez jamais cette étape de proposition et de confirmation — même lorsqu'une recommandation forte est évidente ou qu'une police de la bibliothèque va déjà être utilisée, présentez quand même les candidates et confirmez plutôt que de décider silencieusement.
• Couleur et thème : proposez une palette (4 à 6 valeurs nommées) avec le raisonnement derrière chaque choix ancré dans le sujet, et décidez délibérément du thème clair vs. sombre ici plutôt que de prendre le sombre par défaut (voir la règle du thème dans references/taste-rules.md — beaucoup de marques sont mieux lues en clair). Confirmez les deux avant qu'ils ne soient finaux.
• Direction stylistique : en même temps que la typographie et la couleur, choisissez une famille de style dominante pour toute la page parmi les familles nommées dans references/section-bank.md (aurore/lueur pastel, néo-lueur tech sombre, tech-bio organique, éditorial/brutaliste, minimaliste haute luminosité, luxe/premium vitrine, corporate B2B/fintech) — choisie pour une raison spécifique au brief, pas par habitude. C'est la voie dans laquelle la banque de sections sera explorée plus tard ; emprunter en dehors est un accent délibéré, pas un défaut.

Les deux maquettes de test jusqu'à présent ont sauté cela et ont décidé seules — c'est tombé juste deux fois par chance, mais ce n'est pas le processus qui fonctionne comme prévu.

---

D'abord, le type de site

Déterminez lequel des sept formats il s'agit avant toute chose — les règles de goût et le cadre ci-dessous s'appliquent à tous, mais l'inventaire des sections et, pour les types entreprise, européen et micro-entreprise, l'approche visuelle diffèrent :

• Page d'atterrissage produit (Allowance, didii, TrashPay) — axée sur liste d'attente ou téléchargement, tarification, cas d'usage, grille de fonctionnalités.
• Page de portfolio / étude de cas (Revolut Founder Mode) — un pitch de concept de designer : un bloc bio, des statistiques réelles pour justifier la pertinence, "contactez-moi" au lieu d'une liste d'attente.
• Page d'événement / conférence (FlutterBytes) — vitrine des orateurs, historique des éditions passées, crédits de l'équipe organisatrice, sponsors, agenda.
• Page d'entreprise (une marque de mode, une boulangerie, un salon, un studio — une entreprise réelle établie, pas une startup) — vend un produit ou service réel qui existe déjà, donc elle est axée sur l'image et l'atmosphère plutôt que sur une grille de fonctionnalités. Visez environ 75 % des sections construites autour de photographies réelles (menu/lookbook/galerie/espace), avec les règles de signature et d'animation superposées sur l'imagerie plutôt que de la remplacer.
• Hybride — un mélange délibéré de deux ou trois des types ci-dessus (un produit qui fait aussi la promotion d'un événement, une entreprise avec un portfolio de travaux passés). Choisissez le type dominant pour la structure globale et l'espacement, puis empruntez les sections spécifiques nécessaires au type secondaire.
• Site web européen — un site propre, sobre, premium dans le style des travaux de studio/modèles Framer européens haut de gamme. Mêmes fondations que les autres, mais le héros est délibérément simple : une ou plusieurs photographies réelles appropriées (récupérées et téléchargées depuis Unsplash, Pexels ou Pixabay) placées en arrière-plan du héros à l'intérieur d'un cadre rectangulaire arrondi d'environ 98 % de largeur, sans signature visuelle chargée superposée. Pas de liste d'attente. Simple, mais pas ennuyeux.
• Page d'atterrissage micro-entreprise — une page unique, serrée et premium, exactement quatre sections (héros, offre, preuve, contact), construite pour présenter des entreprises établies, souvent traditionnelles, qui n'ont pas encore de présence en ligne — revendeurs de machines, exportateurs en vrac, fabricants, fournisseurs industriels, grossistes. Celle-ci doit être suffisamment convaincante par elle-même pour faire croire à une entreprise sans site web qu'il faut en avoir un, donc elle mise fortement sur des photographies réelles premium, des signaux de confiance réels (statistiques, logos clients, certifications) et un héros confiant et varié — voir references/site-types.md pour les cinq itérations de héros entre lesquelles alterner et la section Contactez-nous obligatoire.

Consultez references/site-types.md pour l'inventaire des sections et les notes structurelles pour chaque type. Si ce n'est vraiment aucun de ceux-ci, traitez-le comme le plus proche d'une page d'atterrissage produit et adaptez.

---

Le processus

1. Orientez-vous. Nom de la marque, ce qu'elle fait, pour qui, tout site ou ambiance de référence mentionné. S'il est clair que le site aura besoin d'un formulaire (liste d'attente, contact, demande, commande), soulevez la dépendance Google Form maintenant conformément à la section sur les formulaires ci-dessus — demandez à la personne de créer le Google Form et d'envoyer son lien de pré-remplissage, pour que ce ne soit pas une course à la fin.

2. Trouvez le concept central unique avant de toucher à une section. Pas une liste de fonctionnalités — la seule chose que l'utilisateur obtient ou ressent réellement de ce produit, exprimée en une phrase simple, plus deux ou trois idées de soutien. La signature de chaque section sera ensuite vérifiée par rapport à cela. Demandez également directement à la personne si elle a déjà des concepts, des visuels ou des idées qu'elle aimerait inclure ou illustrer — surtout pour le héros — afin que sa propre vision alimente le concept plutôt que d'être écrasée par un concept inventé.

3. Choisissez la typographie et la couleur avec la personne (ci-dessus), ancrées dans le sujet, pas décidées seules.

4. Décidez du type de site (ci-dessus) et parcourez son inventaire de sections. Consultez references/build-log.md pour voir ce que les projets récents ont utilisé, afin que celui-ci ne rime pas accidentellement avec le dernier.

5. Exécutez chaque section à travers la liste de contrôle d'admission ci-dessous, côte à côte, puis évaluez honnêtement avant d'écrire une mise en page ou du code.

   Admission, par section :

   • Qu'est-ce que cette section, et combien de poids visuel mérite-t-elle ? Un héros mérite plus qu'un petit texte de confiance.
   • De quoi parle le produit en général, et de quoi parle cette section en particulier, sur la base de son titre réel, de son sous-titre et de son contenu — pas d'une étiquette générique pour sa catégorie ?
   • Quel concept découle de ce contenu, spécifiquement ? Consultez references/concept-gallery.md pour les concepts déjà inventés — réutilisez-en un qui n'est pas refroidi, adaptez-en un, ou inventez-en un nouveau et ajoutez-le après.
   • Qu'offre la banque de conception de sections ? Tirez deux ou trois rangées candidates de references/section-bank.md (correspondant par catégorie de section, puis par direction stylistique du projet), pesez-les par rapport à une option inventée de toutes pièces, et adaptez la gagnante selon les règles d'adaptation-ne-jamais-transplanter de la banque — la palette, les polices et les spécifications en pixels de la rangée sont remappées sur celles de ce projet, et la section doit toujours passer le test des deux secondes pour cette marque spécifique.
   • Quelle animation ou interaction au survol lui donne vie ? La colonne des mouvements de la banque est un vocabulaire à utiliser ici (traits décalés, compteurs kilométriques, expansions flex-grow, entrées échelonnées, révélations par masque) — toujours jamais la même primitive deux fois sur une page.
   • Quelle est la longueur du titre et du sous-titre ? Les courts peuvent supporter un traitement centré/entouré (voir les archétypes de mise en page dans references/taste-rules.md) ; les longs ne le peuvent pas.
   • Quelle mise en page et quelle signature la section immédiatement avant celle-ci a-t-elle utilisées, et qu'a utilisé le dernier projet ? Ne répétez ni l'un ni l'autre.

   Évaluez honnêtement, en utilisant des vérifications réfutables plutôt que des chiffres confortables :

   • Le concept atterrit-il sur l'un des trois défauts par défaut de la conception IA générique (crème chaleureuse + sérif + terre cuite, quasi-noir + un accent acide, ou style journal à la large feuille) sans raison spécifique au brief ? C'est un échec — revenez à l'admission.
   • Ce choix exact apparaîtrait-il si la même invite était exécutée pour un produit complètement différent ? Si oui, ce n'est pas encore assez spécifique.
   • Un étranger comprendrait-il ce qu'il représente en environ deux secondes, sans légende ? Un concept qui ne fonctionne qu'une fois expliqué a échoué, quelle que soit la finesse du raisonnement.

   L'évaluation est une discipline qui s'applique toujours, pas quelque chose à montrer — la personne voit le concept résultant et un verdict clair, pas un tableau de bord. Et soyez honnête quant à la véritable limitation : sans moyen de voir un rendu, l'auto-évaluation est plus proche d'une relecture de code minutieuse que d'un jugement visuel réel, donc penchez-vous du côté sceptique plutôt que généreux. Si l'environnement peut réellement exécuter et capturer la construction, utilisez-le — un vrai regard vaut mieux qu'une prédiction.

6. Construisez le premier brouillon complet, en utilisant les concepts évalués plus les règles permanentes dans references/taste-rules.md.

7. Passez section par section et vérifiez la qualité de chacune individuellement, par rapport à la page construite. Pour chaque section, demandez :

   • Cette section se connecte-t-elle visiblement au concept central de l'étape 2, ou illustre-t-elle simplement sa propre fonctionnalité en isolation ?
   • Le côté non-textuel de toute section à deux colonnes est-il réellement vivant — une mini-interface animée, un extrait d'écran, ou un concept autonome — ou est-ce une image plate morte ? Pas "est-ce deux colonnes", mais "y a-t-il quelque chose de statique ici qui ne devrait pas l'être" ?
   • S'agit-il d'une simple carte bordée là où un diviseur dégradé ou quelque chose de plus réfléchi ferait mieux ? La page entière reste-t-elle dans une ou deux sections utilisant des cartes au total ? Si c'est une carte, a-t-elle une véritable touche de personnalisation (remplissage dégradé brillant, bordure vitreuse, icône animée) et une véritable interaction au survol ?
   • Toutes les icônes sont-elles issues de la bibliothèque d'icônes personnalisée choisie (Lucide/Phosphor/Heroicons/Tabler), sans émoji tenant lieu...