Site vitrine avec Claude Code jusqu'à Vercel : les étapes

Peut-on publier un site vitrine avec Claude Code ?

Oui, on peut créer un site vitrine avec Claude Code et le mettre en ligne sur Vercel, à condition de suivre six étapes dans l’ordre : brief écrit dans un fichier CLAUDE.md, choix d’Astro ou de Next.js, contenus et formulaire, déploiement via GitHub, domaine avec HTTPS, puis vérifications légales, de performance et de SEO.

Ce guide s’adresse à un dirigeant ou à un responsable web qui veut comprendre le parcours réel, et pas seulement la phase où l’IA génère des pages. Générer du code est la partie rapide. L’ordre des étapes et les contrôles avant publication sont ce qui sépare un site correct d’un site fragile. Pour la question de fond, lis aussi notre analyse du vibe coding appliqué à un site pro.

Prérequis

• Un compte GitHub et un compte Vercel (l’offre gratuite suffit pour démarrer).
• Claude Code installé sur ton poste, avec un abonnement ou une clé API Claude.
• Node.js à jour et un terminal.
• Un nom de domaine dont tu contrôles la zone DNS (si ce n’est pas le cas, commence par récupérer le contrôle de ton domaine).
• Tes textes, tes logos et tes photos, même en version brouillon.

Étape 1 : cadre le brief dans un CLAUDE.md

CLAUDE.md est un fichier markdown placé à la racine du projet, que Claude Code lit au début de chaque session. source : Claude Code Docs

C’est là qu’on fixe les standards de code, les décisions d’architecture et les bibliothèques préférées. Sans lui, Claude réinvente tes choix à chaque session et le site dérive. La commande /memory liste les fichiers de mémoire chargés, au niveau utilisateur comme au niveau projet. source : Claude Code Docs, mémoire

Écris un brief court et vérifiable :

# Brief du projet
- Site vitrine, 5 pages : accueil, services, à propos, contact, mentions légales
- Stack : Astro, CSS sans framework lourd, aucun script tiers
- Ton : direct, vouvoiement, pas de jargon
- Contraintes : accessibilité (contrastes, labels, navigation clavier), pas de traceur
- Avant toute mise en ligne : lancer la checklist de pré-lancement

Tu peux aussi packager cette checklist en skill pour la relancer à chaque version, voir comment ajouter des Skills à Claude Code. Si tu hésites sur le contenu du brief, la checklist de brief avant agence donne les bonnes questions.

Étape 2 : choisis Astro ou Next.js

Pour un site vitrine surtout composé de pages de contenu, Astro est le choix le plus simple : il produit des pages statiques légères. Next.js devient pertinent quand le site doit aussi porter de vraies fonctions applicatives (espace client, contenu personnalisé). Notre comparatif WordPress ou Astro détaille ce raisonnement.

Vercel reconnaît Astro et Next.js et applique les réglages de build adaptés, sans que tu aies à saisir de commande. source : Vercel Knowledge Base, 2026

Demande à Claude Code de créer le squelette, puis relis l’arborescence avant d’ajouter du contenu. Si une page ou un dossier n’a pas été prévu dans le brief, supprime-le.

Étape 3 : contenus et formulaire de contact

Fournis les vrais textes avant de demander la mise en page. Un site rempli de lorem ipsum ou de formules génériques écrites par l’IA se repère tout de suite, et il ne convertit pas. Si tes contenus ne sont pas prêts, prépare-les d’abord avec l’IA.

Le formulaire demande plus d’attention que les pages :

1. Fais envoyer le message par une route serveur (route handler Next.js, ou endpoint Astro avec l’adaptateur Vercel).
2. Stocke la clé de ton service d’e-mail dans les variables d’environnement de Vercel, jamais dans le dépôt GitHub.
3. Valide les champs côté serveur, et ajoute un champ piège (honeypot) contre le spam.
4. Affiche une confirmation claire, et teste l’envoi réel jusqu’à ta boîte de réception.

Pour l’envoi, la configuration de l’API Resend est détaillée à part. Si le message n’arrive jamais, passe par le diagnostic du formulaire de contact.

Étape 4 : déploie sur Vercel via GitHub

Pousse le projet sur GitHub, importe le dépôt dans Vercel, puis lance le déploiement. Vercel te donne un sous-domaine en .vercel.app pour tester.

Un preview deployment est une version de test du site, avec une URL partageable, créée à chaque branche poussée. Le merge sur la branche principale crée le déploiement de production. source : Next.js Learn

Travaille donc toujours sur une branche : tu relis la preview, puis tu fusionnes. Si le déploiement échoue ou reste bloqué sans message, consulte les causes d’échec d’un déploiement Vercel et le cas du fichier .vercelignore manquant.

Étape 5 : branche le domaine et vérifie le HTTPS

Dans le projet Vercel, ouvre l’onglet Domains, ajoute ton domaine, puis modifie les enregistrements DNS avec les valeurs que Vercel affiche. Pour éviter toute coupure sur un site existant, garde l’ancien DNS actif, ajoute le domaine côté Vercel, puis bascule les enregistrements. source : Vercel Knowledge Base, 2026

HTTPS est activé par défaut, y compris sur les domaines personnalisés, et les certificats SSL sont renouvelés automatiquement. source : Next.js Learn

Reste à choisir une seule adresse canonique (avec ou sans www) et à rediriger l’autre vers elle. Le détail est dans le guide domaine perso sur Vercel et celui de la redirection canonique.

Étape 6 : les vérifications avant mise en ligne

C’est ici qu’une agence passe du temps, et qu’un site généré en direct saute souvent des points.

Cookies : ce que dit la CNIL

La CNIL indique qu’aucun traceur non essentiel ne peut être déposé sans consentement préalable, et que la simple poursuite de la navigation ne vaut plus consentement valide. source : CNIL, FAQ cookies

Refuser doit être aussi simple qu’accepter : la CNIL recommande un bouton « tout refuser » à côté de « tout accepter ». source : CNIL, lignes directrices

Mon raisonnement : un site vitrine sans outil d’analyse ni contenu intégré tiers (carte, vidéo, widget) peut n’utiliser que des traceurs strictement nécessaires, donc se passer de bannière. Cette lecture est une inférence, pas une phrase de la CNIL : vérifie dans l’onglet Réseau du navigateur que rien n’est déposé avant d’y compter. Pour le cadre général, voir RGPD et site web en 2026.

Performance : les seuils à respecter

Les trois mesures de référence sont le LCP à 2,5 secondes maximum, l’INP à 200 millisecondes ou moins, et le CLS à 0,1 ou moins. source : web.dev, 2024

Le LCP (Largest Contentful Paint) désigne le temps d’affichage du plus grand élément visible de la page, souvent l’image principale.

Lighthouse ne mesure pas l’INP et utilise le TBT comme substitut. Le rapport Core Web Vitals de la Search Console s’appuie sur des données d’utilisateurs réels et restera vide les premières semaines d’un site neuf, donc contrôle avec PageSpeed Insights en attendant. source : Search Console Help

Les causes habituelles d’un mauvais score sont des images trop lourdes, une police chargée tard et des scripts tiers ajoutés sans réfléchir.

Pièges courants

• Oublier que la mise en ligne n’est pas la fin. Dépendances à mettre à jour, formulaire à surveiller, contenus à revoir : un site en ligne demande un suivi.
• Laisser les secrets dans le dépôt. Une clé d’API poussée sur GitHub doit être révoquée, pas seulement supprimée.
• Ne jamais ouvrir la preview sur mobile. Beaucoup de défauts (débordements, menu, formulaire) n’apparaissent pas sur grand écran.
• Ajouter une carte ou une vidéo intégrée en dernier. Elle peut déposer des traceurs et remettre en cause l’absence de bannière.
• Faire confiance au code sans le relire. L’IA construit le site, pas sa mise en production : les contrôles de l’étape 6 restent à ta charge.

Avant de partager l’adresse, relance la checklist de pré-lancement sur la version de production, pas sur la preview.