Tu as un projet qui tourne en local, généré avec Claude ou codé main dans la main avec lui, et tu veux le mettre en ligne. Pas un déploiement académique : un site accessible sur un vrai domaine, en HTTPS, qui se met à jour quand tu pushes du code. Vercel fait ça en cinq minutes une fois le setup compris. Le reste de ce guide part du principe que tu as déjà pris en main Claude pour apprendre à coder avec lui et que ton projet fonctionne quand tu lances npm run dev. Si ce n'est pas encore le cas, reviens ici après.
Pourquoi Vercel est le meilleur match pour un site généré avec Claude
Vercel est édité par la même équipe que Next.js. Les deux sont pensés ensemble : détection auto du framework, build optimisé, edge network mondial, HTTPS géré, preview deploys à chaque branche. Tu n'as jamais à toucher à un serveur, ni à un fichier de config Nginx, ni à un certificat Let's Encrypt.
Pour un entrepreneur qui code avec Claude, ça compte : Claude génère majoritairement du Next.js, du Vite ou de l'Astro, et ces trois frameworks sont détectés automatiquement par Vercel. Tu importes le repo, tu cliques, c'est en ligne. Netlify fait la même chose, avec une expérience très proche ; le choix se joue à la marge (Vercel a l'avantage sur Next.js, Netlify sur les sites purement statiques). Si tu débutes, Vercel est le pari le plus sûr pour un site créé avec Claude.
Le tier Hobby est gratuit, avec 100 Go de bande passante par mois, un nombre illimité de déploiements, et le certificat SSL inclus. Restriction officielle : usage non commercial. En pratique, un site vitrine perso, un MVP en early access, un portfolio, un blog, tout ça rentre. Dès que tu factures depuis ce site ou que tu y branches une activité commerciale, tu passes sur le plan Pro (à partir de 20 $/mois environ).
Ce qu'il faut avant de déployer
Checklist minimale, à cocher avant de commencer :
- Un compte GitHub (gratuit, github.com).
- Un compte Vercel connecté à ce GitHub (vercel.com, sign up via GitHub).
- Node.js 20 ou plus, installé localement. Vérifie avec
node -v. - Un projet qui fonctionne en local. Concrètement : un dossier avec un
package.jsonà la racine, etnpm run devqui te sert le site sans erreur. - Git installé et configuré (
git config --global user.nameetuser.emailrenseignés).
Si tu n'as pas encore de projet fonctionnel, l'agent CLI d'Anthropic, Claude Code, peut te générer une base Next.js propre à partir d'un brief. Pour caler ton environnement (choix de plan, réglages, extensions), passe par la configuration de Claude pour un usage quotidien avant d'attaquer le déploiement.
Étape 1 : pousser le projet sur GitHub avec l'aide de Claude
Sur github.com, clique sur New repository. Nom du repo (par exemple mon-site), visibilité (privé si tu veux, Vercel gère les deux), pas de README ni de .gitignore (Claude va s'en charger, plus propre).
Dans ton dossier de projet en local, ouvre un terminal et lance :
git init
git add .
git commit -m "initial commit"
git branch -M main
git remote add origin https://github.com/ton-user/mon-site.git
git push -u origin mainAvant le premier git add, demande à Claude un .gitignore adapté à ton stack. Prompt qui marche : « Génère un .gitignore pour un projet Next.js 14 avec TypeScript, en excluant les .env, node_modules, .next, .vercel et les fichiers d'IDE (VSCode, JetBrains). » Colle le résultat à la racine du projet avant de committer.
Point critique : ne commite jamais un fichier .env, .env.local, ni aucune clé API en clair. Une clé Anthropic ou Stripe pushée sur un repo public est aspirée par des bots en quelques minutes. Si ça t'arrive, la clé est morte : révoque-la immédiatement dans la console concernée et régénères-en une neuve.
Étape 2 : importer le projet dans Vercel
Dans le dashboard Vercel, clique Add New puis Project. La liste de tes repos GitHub apparaît. Sélectionne celui que tu viens de pousser.
Vercel affiche un formulaire de configuration. Trois champs comptent :
| Champ | Valeur par défaut | Quand la modifier |
|---|---|---|
| Framework Preset | Détecté auto (Next.js, Vite, Astro...) | Presque jamais, la détection est fiable |
| Build Command | next build ou équivalent | Si tu as un script custom dans package.json |
| Output Directory | .next, dist, build | Si ton framework écrit ailleurs |
Dans 95 % des cas, tu ne touches à rien. Clique Deploy. Le premier build prend entre une et trois minutes selon la taille du projet. Tu vois défiler les logs en direct. À la fin, Vercel te sort une URL du type mon-site-abc123.vercel.app. C'est en ligne, en HTTPS, worldwide. Tu peux déjà partager le lien.
Étape 3 : configurer les variables d'environnement
Ton site a besoin d'une clé API (Anthropic pour un chatbot, Stripe pour des paiements, une URL de base de données Supabase). En local, tu la mets dans .env.local. En production, ce fichier n'existe pas sur Vercel (et heureusement, il n'est pas dans le repo).
Dans ton projet Vercel : Settings puis Environment Variables. Ajoute une variable : nom (par exemple ANTHROPIC_API_KEY), valeur (la clé), et coche les environnements où elle s'applique.
| Environnement | Quand il est utilisé | Cas typique |
|---|---|---|
| Production | Branche main, domaine principal | Clé Stripe live, base de données prod |
| Preview | Toutes les autres branches | Clé Stripe test, base staging |
| Development | vercel dev en local | Rarement utilisé, tu as déjà .env.local |
Piège classique en Next.js : le préfixe NEXT_PUBLIC_. Toute variable qui commence par ces mots est injectée dans le bundle JavaScript envoyé au navigateur. Elle devient publique. Tu ne mets jamais une clé secrète (API key privée, secret Stripe) derrière un NEXT_PUBLIC_. Réserve ce préfixe aux vraies valeurs publiques : URL d'API publique, ID Google Analytics, clé publique Stripe.
Après ajout d'une variable, il faut redéployer pour qu'elle soit prise en compte. Dans l'onglet Deployments, clique les trois points du dernier déploiement, puis Redeploy.
Étape 4 : brancher un domaine personnalisé
Ton domaine chez Vercel (achat direct dans Domains) : rien à configurer, DNS et SSL gérés en interne. Compte 20 à 50 $/an selon l'extension.
Domaine externe (OVH, Gandi, Namecheap, Google Domains) : va dans Settings puis Domains de ton projet, ajoute tondomaine.com. Vercel te donne les enregistrements DNS à créer chez ton registrar :
| Type | Nom | Valeur |
|---|---|---|
| A | @ (racine) | 76.76.21.21 |
| CNAME | www | cname.vercel-dns.com |
Chez OVH, ça se passe dans la zone DNS de ton domaine. Chez Gandi, dans les enregistrements DNS. La logique est la même partout : tu crées ces deux entrées, tu sauves. Propagation : quelques minutes en général, jusqu'à 24 h dans les cas tordus. Vercel provisionne le certificat SSL automatiquement dès que le DNS pointe correctement.
Debug des erreurs de build les plus fréquentes avec Claude
Un build échoue. Vercel te sort un log dans l'onglet Deployments. Le réflexe : copier le log complet (pas juste la ligne d'erreur, tout le contexte des 30-50 lignes autour), et le coller dans Claude avec le contexte du projet. Format de prompt qui marche : « Voici l'erreur de build Vercel sur mon projet Next.js 14 + TypeScript. Package.json ci-dessous. Diagnostique et donne-moi la correction exacte. »
Quatre cas qui reviennent :
- Module not found: Can't resolve 'xxx'. Une dépendance est importée dans le code mais absente de
package.json. Claude te dit laquelle installer. Solution :npm install xxx, commit, push. - Type error: Property 'yyy' does not exist. TypeScript strict bloque un accès non typé. Colle l'erreur et le fichier concerné à Claude : il te sort le typage manquant ou la correction propre.
- Environment variable ANTHROPIC_API_KEY is not defined. Variable oubliée côté Vercel. Retour étape 3, ajoute-la, redéploie.
- Build exceeded maximum duration of 45 minutes (tier Hobby : 45 min). Souvent une boucle infinie dans un script de build, ou un fetch bloquant. Claude aide à identifier le script fautif dans le log.
Dans la majorité des cas, un aller-retour avec Claude suffit à corriger. Pense à repartager le résultat du build après ta correction : si ça re-plante différemment, Claude a besoin du nouveau log.
Preview deploys : le workflow qui change tout
À chaque push sur une branche autre que main, Vercel crée automatiquement une URL de preview isolée : mon-site-git-feature-nouveau-header-tonuser.vercel.app. Le site en prod ne bouge pas.
Concrètement, ton workflow devient : tu crées une branche (git checkout -b feature/nouveau-header), tu demandes à Claude de coder la modif, tu pushes, tu ouvres l'URL de preview sur ton mobile pour vérifier le responsive, tu envoies le lien à un client ou associé pour validation. Si c'est OK, tu merges dans main via une pull request GitHub. Le merge déclenche le déploiement en prod. Si ça ne va pas, tu itères sur la branche sans jamais toucher au site public.
Ce workflow branche + preview est ce qui rend le duo Claude + Vercel réellement productif. Tu peux tester dix versions d'une landing page dans la journée sans stress, chacune avec sa propre URL.
Et après le déploiement
Ton site est en ligne. Quelques réflexes utiles pour la suite :
- Active Vercel Analytics dans Analytics. Gratuit jusqu'à 2 500 events/mois, aucun cookie tiers, RGPD-friendly. Tu vois d'où viennent tes visiteurs, sur quelles pages, avec quels Core Web Vitals.
- Garde un œil sur les logs runtime (onglet Logs). Une erreur 500 en prod est visible en temps réel.
- Si tu bosses sur d'autres projets, pousser un site sur la stack Vercel + Next.js avec les mêmes réflexes te fait gagner des heures.
- Un site vitrine ou un MVP sans contenu meurt vite. Enchaîne avec un pipeline de blog SEO alimenté par Claude pour le nourrir en articles. Et si l'identité visuelle mérite un coup de propre, travailler le design avec Claude se traite en parallèle.
Ce guide te donne le squelette technique. Le vrai levier arrive quand tu enchaînes les cycles : coder avec Claude, pousser sur une branche, valider en preview, merger, mesurer. Pour construire cette cadence sur toute ta stack (site, contenu, automatisations, marketing), Maîtriser Claude au quotidien couvre les cinq briques en cinq semaines, avec un projet livré à chaque module.