Comment créer une landing page avec WeWeb (étape par étape)

Ce que vous allez construire

À la fin de ce guide, vous aurez une landing page complète avec : Section hero avec titre, sous-titre et bouton CTA Rangée de preuves sociales (logos ou témoignage) Section fonctionnalités (grille en 3 colonnes) Section tarification Accordéon FAQ Formulaire de capture de leads (connecté à Supabase ou un webhook Make) Publiée sur un domaine personnalisé avec HTTPS

Temps de construction total : 4 à 6 heures pour une première construction, 1 à 2 heures une fois que vous l'avez déjà fait. Avec un peu de pratique, une landing page WeWeb complète devient une journée de travail, bien moins que les 2 à 3 semaines d'un développement sur mesure.

Étape 1 : configurer votre projet

Créez un nouveau projet WeWeb. Choisissez "Vide", n'utilisez pas de template si vous voulez un contrôle total de la structure.

Premières étapes de configuration : 1. Définissez votre police par défaut dans Paramètres du projet → Polices. Importez une police Google (Inter ou Plus Jakarta Sans fonctionnent bien pour les SaaS). 2. Définissez vos couleurs de marque comme tokens de design dans le panneau Styles : primaire, secondaire, texte, arrière-plan, bordure. 3. Définissez la largeur de la page : max-width 1280px, centré, avec 24px de padding horizontal sur mobile.

Investissez 20 minutes ici. Bien configurer les tokens maintenant économise des heures d'incohérence plus tard. C'est l'étape que les débutants sautent et qu'ils regrettent toujours, un système de design cohérent est la différence entre une landing page qui ressemble à du no-code et une qui ressemble à un vrai produit.

Les tokens de design sont le fondement d'un projet WeWeb maintenable. Chaque couleur, unité d'espacement et taille de police devrait référencer un token plutôt qu'une valeur codée en dur. Quand votre client veut changer la couleur de marque du bleu au vert, un système basé sur des tokens signifie qu'un seul changement met à jour chaque bouton, lien et surbrillance dans tout le projet. Sans tokens, vous changez les couleurs élément par élément, une tâche qui prend des heures et introduit des incohérences.

Étapes 2 et 3 : hero et preuve sociale

Hero (étape 2) : c'est la section la plus importante, construisez-la en premier. Structure : Section (hauteur plein viewport, contenu centré), badge optionnel, H1 (titre principal, le résultat), paragraphe (sous-titre), div (boutons CTA), div (image hero ou screenshot produit).

Conseils WeWeb pour le hero : Utilisez un élément Section, pas un Container, pour que l'arrière-plan s'étende sur toute la largeur Réglez la taille de police du H1 à une variable de breakpoint WeWeb : 56px bureau, 40px tablette, 32px mobile Ajoutez un dégradé ou une texture subtile à l'arrière-plan, les heros purement noirs/blancs paraissent plats

La section hero prendra plus de temps à construire que n'importe quelle autre, car elle demande le plus d'itérations. Attendez-vous à écrire et réécrire le titre 3 à 5 fois avant qu'il ne semble juste. Testez-le auprès de vraies personnes, pas seulement votre équipe, avant de valider le design. Le texte du titre et du sous-titre compte plus que n'importe quel élément visuel du hero. Un titre fort sur un fond blanc uni bat systématiquement un titre faible sur un hero sombre magnifiquement designé.

Preuve sociale (étape 3) : placez-la directement sous le hero. Utilisez une rangée Flexbox avec justify-content: center, gap: 32px. Ajoutez des logos d'entreprises (SVG ou WebP, gris/opacité 60%). Puis la section fonctionnalités : grille CSS à 3 colonnes, chaque carte avec icône 24px, H3 (nom de la fonctionnalité), P (description en une phrase).

Astuce WeWeb : créez une carte de fonctionnalité, stylez-la, puis dupliquez-la 2 fois et mettez à jour le contenu. Ne construisez pas chaque carte depuis zéro. Résistez à la tentation d'ajouter plus de 4 fonctionnalités à la grille : chaque fonctionnalité supplémentaire réduit l'attention portée à chacune. Les meilleures sections de fonctionnalités présentent 3 à 4 capacités soigneusement choisies qui représentent les raisons les plus convaincantes de choisir votre produit. Si vous avez 8 fonctionnalités à mettre en avant, regroupez-les par thème (par exemple "Collaborer", "Automatiser", "Analyser") et montrez 3 groupes plutôt que 8 éléments individuels.

Étapes 4 et 5 : tarification et FAQ

Tarification (étape 4) : un layout de tarification en trois colonnes est le standard SaaS. Construisez-le avec une CSS Grid : trois colonnes égales, colonne centrale mise en évidence (arrière-plan différent, badge "Plus populaire").

Chaque carte de tarification a besoin de : nom du plan (H3), prix + période de facturation, 4 à 6 bullet points de fonctionnalités, bouton CTA.

Astuce WeWeb : liez le contenu de la carte de tarification à une variable WeWeb (tableau d'objets). Cela vous permet de changer les prix et les fonctionnalités depuis un objet de données sans éditer chaque carte individuellement. Quand votre tarification change, mettez à jour un tableau, les trois cartes se mettent à jour automatiquement.

La psychologie de la page tarifs compte ici : le plan du milieu devrait toujours être visuellement mis en avant et positionné comme la recommandation par défaut. Donnez-lui une couleur de fond différente (légèrement plus claire ou avec une bordure colorée), ajoutez un badge "Le plus populaire" dans votre couleur d'accent principale, et rendez le bouton CTA du plan du milieu plein tandis que les deux autres plans utilisent des boutons avec contour. Cette hiérarchie visuelle guide la majorité des visiteurs vers le plan que vous voulez qu'ils choisissent.

FAQ accordéon (étape 5) : créez une variable WeWeb openFaqIndex (type : Nombre, défaut : -1). Sur chaque clic de question, définissez openFaqIndex = index de cet élément (ou -1 s'il est déjà ouvert). Affichez/masquez chaque div de réponse : ajoutez une condition "openFaqIndex === thisIndex". Zéro JavaScript écrit.

Pour le bénéfice SEO, ajoutez aussi un schema FAQPage dans le <head> de la page qui correspond au contenu de l'accordéon FAQ. Google peut extraire le contenu FAQ à la fois du HTML visible et du schema JSON-LD, avoir les deux augmente les chances que votre FAQ apparaisse en résultat enrichi dans les recherches. Le schema doit être mis à jour à chaque ajout ou modification de contenu FAQ. Si vous liez votre accordéon FAQ à une table Supabase, vous devrez aussi mettre à jour manuellement le schema JSON-LD codé en dur, ou implémenter un script au moment du build qui génère le schema à partir de la même source de données.

Étape 6 : formulaire de capture de leads

Ajoutez un formulaire au-dessus du pied de page. Gardez-le minimal : Nom, Email professionnel, bouton CTA ("Réserver une démo" ou "Commencer l'essai gratuit").

Connexion du formulaire à Supabase : 1. Dans WeWeb, ajoutez un composant Form 2. Ajoutez une Action à la soumission : "Insérer une ligne" → votre table Supabase "leads" 3. Ajoutez une deuxième Action : afficher un message de succès (basculer la visibilité d'un div de remerciement)

Connexion à Make à la place : 1. Créez un scénario webhook Make 2. Dans WeWeb, utilisez l'action "Requête HTTP" à la soumission du formulaire → POST vers votre URL de webhook Make 3. Dans Make : ajoutez notification email + création de ligne HubSpot/Notion/Airtable

Ajoutez toujours un champ honeypot (input caché que les vrais utilisateurs ne remplissent jamais, les bots le font). Filtrez toute soumission où le champ honeypot n'est pas vide. Conforme RGPD : ajoutez également une case à cocher de consentement explicite liée à votre politique de confidentialité.

Le nombre de champs de formulaire est l'une des variables de conversion les plus importantes. Chaque champ obligatoire supplémentaire réduit le taux de complétion du formulaire d'environ 10 à 15 %. Pour une landing page de premier contact, demandez le minimum : typiquement le prénom et l'email professionnel. Les champs de qualification supplémentaires (taille de l'entreprise, cas d'usage, numéro de téléphone) devraient être déplacés vers la séquence de suivi ou la confirmation de réservation de démo. L'objectif du formulaire de la landing page est d'obtenir l'email, tout le reste peut être récupéré plus tard.

Le CMS WeWeb pour les landing pages

La fonctionnalité CMS de WeWeb permet de gérer le contenu de la landing page sans retourner dans l'éditeur WeWeb. C'est particulièrement précieux pour les équipes où une personne marketing non-technique doit mettre à jour un texte, changer un témoignage ou modifier un prix sans attendre la disponibilité d'un développeur.

Configurez des collections CMS pour les types de contenu répétables de votre landing page : témoignages, cartes de fonctionnalités, questions FAQ et formules de tarification. Chaque collection est un type de données structuré avec des champs qui correspondent au contenu de la page. Liez vos composants WeWeb aux données de la collection CMS au lieu de valeurs codées en dur. Désormais, un membre de l'équipe peut se connecter à l'éditeur CMS de WeWeb, mettre à jour un témoignage ou une question FAQ, et republier la page, sans toucher un seul composant.

Pour les clients entreprise, le CMS de WeWeb peut pointer vers une table Supabase externe plutôt que vers le CMS interne de WeWeb. Cela signifie que le contenu appartient au client dans sa propre base de données, éditable via une interface d'administration personnalisée que vous construisez dans WeWeb, et non dépendant de la plateforme WeWeb pour la gestion de contenu. Cette architecture offre une flexibilité maximale et évite le verrouillage de plateforme pour le contenu.

Configurer l'A/B testing dans WeWeb

WeWeb n'a pas d'A/B testing natif, mais c'est simple à implémenter avec des paramètres d'URL et des variables WeWeb. L'approche : montrez la variante A aux visiteurs sans paramètre (le contrôle), montrez la variante B aux visiteurs avec ?variant=b dans l'URL. Vos campagnes publicitaires envoient 50 % du trafic vers chaque variante d'URL.

Implémentation : créez une variable WeWeb appelée pageVariant avec une valeur par défaut de 'a'. Ajoutez une action On Page Load qui lit le paramètre d'URL et définit pageVariant sur 'a' ou 'b'. Ajoutez ensuite un affichage conditionnel sur les éléments que vous voulez tester : montrez heroHeadlineA quand pageVariant = 'a', montrez heroHeadlineB quand pageVariant = 'b'. Suivez les conversions par variante avec un événement PostHog qui inclut la variante comme propriété.

Pour un test plus sophistiqué, utilisez les feature flags de PostHog pour assigner la variante de façon cohérente par session utilisateur plutôt que par paramètre d'URL. Le plugin WeWeb de PostHog fait cette connexion sans code. L'avantage de l'assignation par session est qu'un visiteur qui revient sur la page sans le paramètre d'URL voit la même variante, ce qui évite l'effet confondant d'un visiteur qui verrait les deux variantes.

Gestion des formulaires et capture de leads

La capture de leads est l'objectif central de la plupart des landing pages, et le chemin entre la soumission du formulaire et votre CRM ou processus commercial devrait être testé de bout en bout avant le lancement. Beaucoup d'équipes lancent une landing page et découvrent seulement 3 semaines plus tard que les soumissions de formulaire échouaient silencieusement à cause d'une policy RLS Supabase mal configurée ou d'un scénario Make qui avait été mis en pause.

Mettez en place un protocole de test de soumission : après chaque changement de formulaire, soumettez un lead de test avec un email reconnaissable (test+landingpage@votreentreprise.com) et vérifiez qu'il apparaît dans votre table Supabase leads, déclenche l'email de notification Make, et crée une fiche contact dans votre CRM. Cela prend 5 minutes et détecte immédiatement les échecs d'intégration.

Pour les landing pages à fort volume (plus de 100 soumissions par jour), ajoutez un rate limiting à votre endpoint de soumission de formulaire. Dans Xano, c'est un middleware simple qui vérifie le nombre de soumissions depuis une adresse IP donnée au cours de la dernière heure. Sans rate limiting, une seule campagne de bots peut remplir votre table de leads avec des milliers d'enregistrements de spam qui corrompent vos données de conversion et nécessitent un nettoyage manuel. Combinez le rate limiting avec le champ honeypot et vous éliminez plus de 95 % des soumissions de spam.

Intégration du tracking et des analytics

Une landing page sans analytics, c'est deviner. Les analytics transforment une landing page d'une construction ponctuelle en un projet d'optimisation continue. Les deux outils que nous recommandons pour les landing pages WeWeb sont PostHog (pour les analytics produit et l'enregistrement de session) et Plausible (pour des analytics de trafic respectueux de la vie privée), ils servent des objectifs différents et fonctionnent bien ensemble.

Configuration de PostHog dans WeWeb : ajoutez le snippet JavaScript de PostHog dans le code personnalisé du <head> de votre projet. Ajoutez ensuite des événements personnalisés dans les Actions WeWeb : déclenchez un événement posthog.capture('cta_clicked', {location: 'hero'}) quand le CTA du hero est cliqué, un événement posthog.capture('form_submitted') à la soumission du formulaire, et un événement posthog.capture('pricing_viewed') quand la section tarification entre dans le viewport (utilisez la liaison Intersection Observer de WeWeb). Ces trois événements vous donnent les données de funnel de conversion nécessaires pour identifier où les visiteurs abandonnent.

Plausible fournit des données de trafic sans les implications de vie privée de Google Analytics et ne nécessite pas de bannière de consentement cookies sous le RGPD, un gain UX significatif pour les landing pages européennes. Ajoutez le script Plausible dans votre code <head> et configurez des objectifs personnalisés pour les clics CTA et les soumissions de formulaire. Le dashboard Plausible vous donne des sources de trafic propres, les pages les plus vues et les taux de conversion des objectifs en une seule vue. Partagez le lien du dashboard avec votre client pour qu'il puisse suivre le trafic sans avoir besoin d'accéder à votre configuration analytics complète.

Étape 7 : publier sur votre domaine

Dans WeWeb, allez dans Hébergement → Domaine personnalisé. 1. Ajoutez votre domaine (ex. app.votresite.com ou votresite.com) 2. WeWeb vous donne un enregistrement CNAME à ajouter chez votre fournisseur DNS 3. Ajoutez le CNAME, attendez la propagation DNS (généralement 5 à 30 minutes) 4. WeWeb provisionne automatiquement un certificat SSL via Let's Encrypt

Avant de publier : Vérifiez chaque section à 375px, 768px et 1280px Lancez un audit Lighthouse (Chrome DevTools → onglet Lighthouse), visez 90+ en performance Vérifiez le titre de page et la meta description dans les paramètres SEO de WeWeb Ajoutez votre extrait Google Analytics ou Plausible dans Paramètres du projet → Code personnalisé → <head> Assurez-vous que votre bannière de cookies est conforme au RGPD (via Axeptio ou Cookiebot, les deux ont une intégration WeWeb)

Publiez et vous êtes en ligne. Temps total : une journée.

Après la publication, soumettez votre URL à Google Search Console via l'outil d'inspection d'URL et demandez l'indexation. Cela ne garantit pas une indexation plus rapide, mais cela signale à Google que la page existe et est prête à être crawlée. Pour une landing page qui reçoit du trafic payant, vérifiez aussi que le pixel de tracking de conversion de votre plateforme publicitaire se déclenche correctement en utilisant l'onglet Réseau du navigateur, les échecs de tracking de conversion sont une cause fréquente de données de campagne mal attribuées qui mènent à de mauvaises décisions de dépense publicitaire.