david-samurai/LandingPageSkill

Construire une page d'atterrissage dans Claude Code

Une configuration opérationnelle pour créer, déployer et améliorer des pages marketing avec Claude Code. Cinq éléments font l'essentiel du travail : un dépôt, un hébergeur, un kit de marque, les performances et les données d'entonnoir. Maîtrisez-les, tout le reste n'est qu'itération.

Deux façons de voir la page avant son déploiement (section 4) : un serveur de développement local pour vous et Claude, et Claude Design pour toute personne non technique. Si vous utilisez Design, lisez d'abord la règle absolue de la section 4 — il n'y a pas d'annulation là-bas.

Le fil conducteur : le travail ne s'arrête pas au déploiement. Une page en ligne et non suivie est une page que vous ne pouvez pas améliorer.

Ordre des opérations

Effectuez-les dans cet ordre. Chacune rend la suivante moins coûteuse.

1. Dépôt en premier — avant tout code. Le contrôle de version est le bouton d'annulation pour tout le reste.
2. Hébergeur et pipeline de déploiement en deuxième — pendant que le site est trivial et qu'un déploiement défectueux ne coûte rien.
3. Kit de marque en troisième — avant d'écrire un mot de copie, afin que la première ébauche soit déjà conforme à la marque.
4. Construire la page — visuel/statique d'abord, interactivité ensuite, suivi en dernier.
5. Déployer avec un suivi minimal dès le premier jour — puis optimiser la vitesse et la copie à partir de données réelles.

---

1. Utiliser un dépôt (GitHub ou équivalent)

Si vous utilisez déjà Claude Code, cela va de soi. Si vous ne faites que tremper un orteil, ceci est l'échauffement : un dépôt vous donne le contrôle de version, une sauvegarde dans le cloud et — surtout — une stratégie de déploiement.

main est la production et rien n'y atterrit sauf via une pull request que vous fusionnez. Mettez cette règle dans CLAUDE.md explicitement — voir starters/CLAUDE.md.

La boucle

Voici le cycle complet. Exécutez-le pour chaque tâche, aussi petite soit-elle.

1. Convenez d'un numéro de version. Claude en recommande un, vous l'approuvez — ou vous dites simplement lequel vous voulez. Dans les deux cas, le numéro est fixé avant le début du travail, et la décision vous appartient, pas à Claude.
2. Claude crée la branche — git checkout -b v1.03.
3. Vous effectuez le travail dans la branche. Les commits y atterrissent et nulle part ailleurs.
4. Claude pousse la branche sur GitHub.
5. Claude ouvre la pull request.
6. Vous examinez et approuvez la pull request sur GitHub, et vous la fusionnez. C'est le déploiement. C'est le seul moment où la production change, et c'est toujours une décision humaine.
7. git checkout main puis git pull. Ne sautez pas cette étape. Votre main local est maintenant en retard d'exactement une fusion, et démarrer la branche suivante à partir d'un main obsolète est la façon d'obtenir des divergences, des conflits fantômes et un git pull qui refuse le fast-forward.
8. Répétez à partir de l'étape 1 avec le numéro de version suivant.

Claude propose, vous décidez, Claude exécute. Les numéros de version, les fusions et les déploiements sont vôtres ; la création de branche, le push et l'ouverture de la PR sont ceux de Claude. Si un appel est ambigu, Claude demande.

Nommage de version qui fonctionne : v1.0x pour les correctifs (copie, configuration, petites corrections), v1.x pour les travaux mineurs (une nouvelle page, une nouvelle fonctionnalité), v2.x pour une refonte.

Deux points de contrôle de révision à conserver :

• Examinez l'intégralité du diff de la branche avant de fusionner, pas seulement chaque commit. Des commits individuellement corrects peuvent se combiner en un vrai bug. Un passage complet "tout lire depuis le point de branche" — idéalement par un second examinateur ou un nouvel agent — attrape ce que la révision par tâche ne peut structurellement pas attraper.
• Effectuez une révision de sécurité avant tout déploiement qui collecte des données utilisateur. Un seul passage de révision sur une branche de gestion de formulaire a attrapé une véritable vulnérabilité où un spread d'objet brut permettait à un visiteur de soumettre des valeurs pour des champs gérés par le serveur. Traitez-la comme un point de contrôle, pas une commodité.

---

2. Hébergez-le quelque part avec un véritable pipeline de déploiement

AWS Amplify fonctionne bien : un niveau gratuit qui couvre une page d'atterrissage à faible trafic, et une petite facture au-delà. Vérifiez les conditions actuelles — AWS a restructuré son niveau gratuit en 2025. Netlify, Vercel et Cloudflare Pages offrent la même structure.

Le vrai avantage est le chemin de déploiement : fusionnez une PR, le site se reconstruit et se met en ligne.

Connecter le dépôt à l'hébergeur est l'étape sur laquelle les gens butent, et c'est un chemin de clics, pas un fichier de configuration : dans la console de l'hébergeur, créez une nouvelle application web → autorisez-la sur votre compte GitHub → choisissez le dépôt et la branche main → il détecte votre spécification de build → le premier déploiement s'exécute. Ensuite, il se reconstruit à chaque push sur cette branche. Faites cela pendant que le site est une simple page "bonjour", afin qu'un pipeline défectueux ne vous coûte rien à déboguer.

Configurez dès le premier jour, pendant que c'est peu coûteux :

• Déploiement automatique depuis main.
• Un nom de domaine personnalisé avec HTTPS.
• Une alerte de facturation. Vous venez d'enregistrer une carte bancaire pour un compte cloud. Définissez une alerte de budget à un montant qui vous surprendrait — cela prend deux minutes, et cela transforme une surprise désagréable de faible probabilité en un email.
• En-têtes de sécurité — les hébergeurs statiques n'en fournissent aucun par défaut.
• Cache-Control à longue durée sur les actifs de build avec empreinte de contenu. Facile, permanent, et autrement repoussé éternellement car cela ne bloque jamais rien.

Domaine et DNS, où les pièges sont prévisibles :

• Un domaine nu ne peut pas utiliser un CNAME — www.exemple.com le peut, exemple.com ne le peut pas. Vous avez besoin de l'enregistrement ALIAS/ANAME de votre fournisseur DNS ou de l'option apex de l'hébergeur. Décidez tôt si votre URL canonique comprend le www, et redirigez l'autre vers celui-ci.
• Le certificat HTTPS a besoin d'un enregistrement DNS pour se valider et ne sera pas émis tant que cet enregistrement ne sera pas résolu. Laissez quelques heures à tout changement DNS avant de décider qu'il est erroné — le délai de propagation ressemble exactement à un échec.

Pièges de déploiement qui coûtent du temps réel :

• Sachez exactement quelles parties se déploient automatiquement et lesquelles ne le font pas. Si une pièce de votre pile (une fonction sans serveur, un backend, un worker) se déploie par une commande manuelle séparée, écrivez-le dans CLAUDE.md en lettres majuscules. L'échec silencieux classique est la fusion d'une branche où le site visible est mis à jour, le backend ne l'est pas, et tout semble correct.
• Le déploiement automatique supprime votre dernier point de contrôle. Avec la fusion au déploiement, la révision de la PR est le point de contrôle. La vérification doit avoir lieu avant la fusion, pas après.
• npm ci sur l'hébergeur de build est plus strict que votre npm install local. Un fichier de verrouillage subtilement désynchronisé avec package.json s'installe correctement localement avec un npm récent et échoue sur l'hébergeur avec un npm plus ancien. Le build échoue sur l'hébergeur mais pas localement ? Soupçonnez le fichier de verrouillage en premier.
• Épinglez votre runtime dans la spécification de build, pas seulement dans un fichier de version. Un .nvmrc seul n'est pas honoré de manière fiable — invoquez également le gestionnaire de version dans les commandes de build.
• Chaque nouvelle variable d'environnement doit être ajoutée dans la console de l'hébergeur, séparément du code qui la lit. C'est une réponse étonnamment fréquente à "pourquoi c'est cassé".
• Content-Security-Policy est l'en-tête qui vous mordra. Chaque origine tierce avec laquelle votre page communique réellement — analytics, tag manager, pixels, polices, endpoints de formulaire — doit être autorisée dans la directive appropriée, ou elle est silencieusement bloquée en production tout en fonctionnant parfaitement en développement local. Symptôme : "le suivi fonctionne localement, ne déclenche rien en ligne." Vérifiez la console du navigateur pour les violations CSP avant de déboguer autre chose.
• Vérifiez l'artefact déployé, pas le fichier source. Confirmez une correction en inspectant la réponse de production réelle (curl -I, outils de développement du navigateur), pas en lisant la configuration qui était censée la produire. Idem pour "mon changement a-t-il vraiment été déployé" — vérifiez l'ID/timestamp du build, pas seulement que la fusion a eu lieu.

Comment le formulaire soumet réellement

L'hébergement statique n'a pas de backend. Un <form> simple sur une page statique ne fait rien d'utile — cela surprend les gens dès le premier jour, et c'est tout l'intérêt de la page. Trois options réalistes :

Option	Bon quand	Attention à
Un service de formulaire hébergé	Vous voulez que cela fonctionne cet après-midi	Coût mensuel par volume ; leur branding ; vos données vivent chez eux
Une fonction sans serveur (Lambda, Netlify/Cloudflare Functions)	Vous voulez le contrôle et un coût quasi nul	Vous gérez maintenant la validation, le spam et le CORS
Le formulaire intégré ou le webhook de votre CRM	Le lead doit atterrir dans un CRM de toute façon	Poids d'intégration et limitations de style ; souvent lent à charger

Quel que soit votre choix :

• CORS sera votre première erreur. Un endpoint sans serveur sur une origine différente de votre page doit explicitement autoriser cette origine, sinon le navigateur bloque la requête avant même qu'elle ne soit envoyée. Ajoutez localhost à la liste d'autorisation également, sinon vous ne pouvez pas tester localement.
• Ajoutez un champ pot de miel (une entrée cachée que les humains ne remplissent jamais et les robots oui) et rejetez tout ce qui le remplit. Le filtre anti-spam le moins cher qui existe.
• Ne dispersez jamais un corps de requête brut directement dans votre écriture de base de données. C'est ainsi qu'un visiteur finit par définir des champs que vous aviez l'intention de contrôler côté serveur. Choisissez explicitement les champs que vous voulez.
• Gardez l'endpoint chaud si possible. Une fonction sans serveur qui démarre à froid donne l'impression que le moment le plus important de la page — appuyer sur envoyer — est cassé.

---

3. Donnez à Claude un kit de marque — et forcez-le à le charger

C'est l'élément le plus rentable de la liste. Au minimum, le kit contient :

votre offre · votre marché cible / profil client · votre stratégie de messagerie · vos couleurs · vos polices · votre logo

Mettez-le dans un dossier (brand/). Modèle : starters/brand-kit/brand.md.

Ensuite, faites-le charger automatiquement. Une instruction dans CLAUDE.md disant "lisez le kit de marque" est consultative — elle est suivie de manière incohérente. Un hook SessionStart qui cat les fichiers dans le contexte n'est pas facultatif et n'est pas sauté. Ce seul changement fait la différence entre "parfois conforme à la marque" et "conforme à la marque par défaut." Voir starters/settings.json.

Chargez au début de la session : le kit de marque, un court document d'architecture (comment le site est construit, hébergé, déployé), et le journal de session le plus récent.

Bien le structurer :

• Séparez "l'apparence de la marque" de "la façon dont la marque parle." Gardez le fichier toujours actif simple — palette, polices, logos, offre, public. Pointez vers du matériel de voix/messagerie plus profond avec "lisez ceci lorsque vous travaillez sur la copie." Tout ce qui est chargé automatiquement coûte du contexte à chaque session, pour toujours.
• Donnez aux couleurs des rôles, pas seulement des codes hexadécimaux ("accent principal — utilisé pour le CTA principal"). Les rôles empêchent Claude d'inventer une couleur quand il en a besoin. Énoncez la règle simplement : aucune couleur en dehors du kit n'apparaît nulle part. Les couleurs non conformes des modèles et des générateurs s'infiltrent silencieusement autrement.
• Deux ou trois exemples de ton avant/après enseignent la voix plus rapidement que toute liste d'adjectifs.
• Si votre messagerie est commercialement sensible, mettez-la dans .gitignore mais référencez-la toujours depuis CLAUDE.md — vous obtenez un chargement cohérent sans publier de stratégie ou de tarification sur un dépôt.
• Les documents de marque synchronisés en externe se périments. Si un document de voix ou d'audience est copié à partir d'un lecteur partagé, revérifiez-le par rapport à sa source avant un passage de copie — les décisions marketing sont prises dans des conversations qui ne sont jamais retranscrites dans le document.

Discipline de copie que le kit de marque devrait imposer :

• Ne promettez jamais "pas d'inscription / pas d'email requis" sur une page dont le travail est de capturer un email. Cela semble réduire les frictions jusqu'à ce que le formulaire apparaisse, puis c'est une contradiction au moment exact où vous avez besoin de confiance. Rassurez plutôt sur le temps, le coût et le résultat — "2 minutes · gratuit · votre résultat envoyé directement par email."
• Réauditez la microcopie rassurante chaque fois que l'offre change. Elle est copiée entre les variantes de page et survit à l'offre pour laquelle elle a été écrite, précisément parce qu'elle semble utile.
• La promesse de l'annonce, la promesse de la page et la demande réelle du formulaire doivent toutes concorder. Un décalage se manifeste par une baisse à l'étape où la vérité arrive, pas à l'étape où le décalage a été introduit. Lorsqu'une étape fuit, suspectez l'étape précédente.

---

4. Voyez-la avant de l'expédier

Deux façons de regarder une page sans la déployer. Utilisez les deux — elles sont destinées à des personnes différentes.

Serveur de développement local

Pour vous et Claude, en cours de construction. Claude peut démarrer le serveur de développement, piloter un vrai navigateur, capture d'écran du résultat, et lire les logs de la console et du réseau — donc "est-ce que cela s'affiche correctement" est répondu en regardant, pas en inspectant le code.

• N'exécutez jamais deux serveurs de développement pour le même projet en même temps. Vérifiez d'abord la présence d'un processus existant et tuez-le avant d'en démarrer un autre — surtout si des agents parallèles pourraient chacun en lancer un.
• Limitez les boucles de réessai automatiques à environ 3 tentatives. Une boucle ouverte "continuez à recharger et à essayer différents timings jusqu'à ce que cela fonctionne" autour d'un serveur de développement plus de l'automatisation du navigateur est un véritable risque d'épuisement des ressources, pas seulement une gêne — cela a déjà planté une machine complètement.
• Vérifiez le nettoyage plutôt que de lui faire confiance. "J'ai arrêté le serveur et fermé les onglets" est une affirmation non vérifiée comme toute autre — vérifiez la liste des processus.
• Attendez-vous à ce que le local diffère de la production par conception. Tout ce qui est derrière un véritable identifiant d'analyse ou un endpoint API en direct est généralement inactif localement. C'est un comportement attendu, pas un bug — documentez-le afin qu'il ne soit pas re-diagnostiqué toutes les quelques semaines.
• Gardez vos tests de bout en bout pointés vers localhost par défaut, avec le fait de les pointer vers l'URL réelle déployée un acte délibéré et séparé — sinon une exécution de test de routine effectue une soumission réelle contre la production.

Claude Design (claude.ai/design)

Pour tout le monde. Claude peut pousser une page dans un projet Claude Design, vous donnant une URL partageable où un client, un designer ou un partenaire non technique peut éditer la copie et la mise en page visuellement dans le navigateur avec zéro configuration locale. Excellent pour l'approbation avant qu'une page ne soit connectée au site réel.

La règle absolue : ne jamais écrire à l'aveugle sur Design

Avant d'écrire quoi que ce soit dans un projet Claude Design, Claude doit récupérer la version distante actuelle, la différer et vérifier avec vous avant de la remplacer. À chaque fois.

Il n'y a aucun historique de version, aucune annulation et aucune corbeille côté Design — un fichier canvas est plus fragile qu'un fichier local non suivi. Un remplacement aveugle des modifications d'un collaborateur est définitivement irrécupérable, et cela a déjà coûté une soirée entière de copie manuscrite.

• Créez la page sous forme de HTML/CSS/JS statique autonome. Le

…

[le reste du document a été tronqué pour la traduction]