Déployer sur Vercel

Déployez n'importe quel projet sur Vercel. Toujours déployer en prévisualisation (pas en production) sauf si l'utilisateur le demande explicitement.

L'objectif est de placer l'utilisateur dans la meilleure configuration à long terme : son projet lié à Vercel avec des déploiements par git push. Chaque méthode ci-dessous tente de rapprocher l'utilisateur de cet état.

Étape 1 : Rassembler l'état du projet

Exécutez les quatre vérifications avant de décider de la méthode à utiliser :

# 1. Vérifier s'il existe un dépôt distant git
git remote get-url origin 2>/dev/null

# 2. Vérifier si le projet est lié localement à un projet Vercel (l'un ou l'autre fichier signifie lié)
cat .vercel/project.json 2>/dev/null || cat .vercel/repo.json 2>/dev/null

# 3. Vérifier si la CLI Vercel est installée et authentifiée
vercel whoami 2>/dev/null

# 4. Lister les équipes disponibles (si authentifié)
vercel teams list --format json 2>/dev/null

Sélection d'équipe

Si l'utilisateur appartient à plusieurs équipes, présentez tous les slugs d'équipe disponibles sous forme de liste à puces et demandez vers laquelle déployer. Une fois que l'utilisateur a choisi une équipe, passez immédiatement à l'étape suivante — ne demandez pas de confirmation supplémentaire.

Transmettez le slug d'équipe via --scope sur toutes les commandes CLI suivantes (vercel deploy, vercel link, vercel inspect, etc.) :

vercel deploy [chemin] -y --no-wait --scope <slug-equipe>

Si le projet est déjà lié (.vercel/project.json ou .vercel/repo.json existe), le orgId dans ces fichiers détermine l'équipe — pas besoin de demander à nouveau. S'il n'y a qu'une seule équipe (ou juste un compte personnel), ignorez la demande et utilisez-la directement.

À propos du répertoire .vercel/ : Un projet lié possède soit :

.vercel/project.json — créé par vercel link (liaison de projet unique). Contient projectId et orgId.
.vercel/repo.json — créé par vercel link --repo (liaison basée sur le dépôt). Contient orgId, remoteName, et un tableau projects mappant les répertoires aux ID de projet Vercel.

L'un ou l'autre fichier signifie que le projet est lié. Vérifiez les deux.

N'utilisez PAS vercel project inspect, vercel ls, ou vercel link pour détecter l'état dans un répertoire non lié — sans configuration .vercel/, ils demanderont de manière interactive (ou avec --yes, ils lieront silencieusement en effet de bord). Seulement vercel whoami peut être exécuté en toute sécurité n'importe où.

Étape 2 : Choisir une méthode de déploiement

Lié (`.vercel/` existe) + dépôt git distant → `git push`

C'est l'état idéal. Le projet est lié et dispose de l'intégration git.

Demandez à l'utilisateur avant de pusher. Ne poussez jamais sans approbation explicite :

Ce projet est connecté à Vercel via git. Je peux commiter et pusher pour
déclencher un déploiement. Voulez-vous que je procède ?

Commitez et pushez :
```
git add .
git commit -m "deploy : <description des changements>"
git push
```
Vercel construit automatiquement à partir du push. Les branches non-production reçoivent des déploiements de prévisualisation ; la branche de production (généralement main) reçoit un déploiement de production.
Récupérez l'URL de prévisualisation. Si la CLI est authentifiée :
```
sleep 5
vercel ls --format json
```
La sortie JSON contient un tableau deployments. Trouvez l'entrée la plus récente — son champ url est l'URL de prévisualisation.

Si la CLI n'est pas authentifiée, dites à l'utilisateur de vérifier le tableau de bord Vercel ou les vérifications de statut du commit sur leur fournisseur git pour l'URL de prévisualisation.

Lié (`.vercel/` existe) + pas de dépôt git distant → `vercel deploy`

Le projet est lié mais il n'y a pas de dépôt git. Déployez directement avec la CLI.

vercel deploy [chemin] -y --no-wait

Utilisez --no-wait pour que la CLI retourne immédiatement avec l'URL de déploiement au lieu de bloquer jusqu'à la fin de la construction (les constructions peuvent prendre du temps). Vérifiez ensuite l'état du déploiement avec :

vercel inspect <url-deploiement>

Pour les déploiements de production (uniquement si l'utilisateur le demande explicitement) :

vercel deploy [chemin] --prod -y --no-wait

Non lié + CLI authentifiée → Lier d'abord, puis déployer

La CLI fonctionne mais le projet n'est pas encore lié. C'est l'occasion de placer l'utilisateur dans le meilleur état.

Demandez à l'utilisateur vers quelle équipe déployer. Présentez les slugs d'équipe de l'étape 1 sous forme de liste à puces. S'il n'y a qu'une seule équipe (ou juste un compte personnel), ignorez cette étape.

Une fois une équipe sélectionnée, passez directement à la liaison. Dites à l'utilisateur ce qui va se passer mais ne demandez pas de confirmation séparée :

Liaison de ce projet à <nom équipe> sur Vercel. Cela créera un projet Vercel
pour déployer et activera les déploiements automatiques sur les futurs pushes git.

Si un dépôt git distant existe, utilisez la liaison basée sur le dépôt avec le scope d'équipe sélectionné :
```
vercel link --repo --scope <slug-equipe>
```
Cela lit l'URL du dépôt distant et la fait correspondre aux projets Vercel existants qui déploient à partir de ce dépôt. Cela crée .vercel/repo.json. C'est beaucoup plus fiable que vercel link (sans --repo), qui essaie de faire correspondre par nom de répertoire et échoue souvent lorsque le dossier local et le projet Vercel ont des noms différents.

S'il n'y a pas de dépôt git distant, revenez à la liaison standard :
```
vercel link --scope <slug-equipe>
```
Cela invite l'utilisateur à sélectionner ou créer un projet. Cela crée .vercel/project.json.
Ensuite, déployez en utilisant la meilleure méthode disponible :
- Si un dépôt git distant existe → commitez et pushez (voir méthode git push ci-dessus)
- Si pas de dépôt git distant → vercel deploy [chemin] -y --no-wait --scope <slug-equipe>, puis vercel inspect <url> pour vérifier l'état

Non lié + CLI non authentifiée → Installer, authentifier, lier, déployer

La CLI Vercel n'est pas du tout configurée.

Installez la CLI (si pas déjà installée) :
```
npm install -g vercel
```
Authentifiez :
```
vercel login
```
L'utilisateur termine l'authentification dans son navigateur. Si l'exécution se fait dans un environnement non interactif où la connexion n'est pas possible, passez directement à la solution de secours sans authentification ci-dessous.
Demandez vers quelle équipe déployer — présentez les slugs d'équipe de vercel teams list --format json sous forme de liste à puces. Si une seule équipe / compte personnel, ignorez. Une fois sélectionnée, passez immédiatement.

Liez le projet avec le scope d'équipe sélectionné (utilisez --repo si un dépôt git distant existe, vercel link simple sinon) :

vercel link --repo --scope <slug-equipe>   # si dépôt git distant existe
vercel link --scope <slug-equipe>          # si pas de dépôt git distant

Déployez en utilisant la meilleure méthode disponible (git push si dépôt distant existe, sinon vercel deploy -y --no-wait --scope <slug-equipe>, puis vercel inspect <url> pour vérifier l'état).

Solution de secours sans authentification — sandbox claude.ai

Quand l'utiliser : En dernier recours lorsque la CLI ne peut pas être installée ou authentifiée dans le sandbox claude.ai. Cela ne nécessite aucune authentification — il retourne une URL de prévisualisation (site en ligne) et une URL de réclamation (transfert vers votre compte Vercel).

bash /mnt/skills/user/deploy-to-vercel/resources/deploy.sh [chemin]

Arguments :

chemin - Répertoire à déployer, ou un fichier .tgz (par défaut le répertoire courant)

Exemples :

# Déployer le répertoire courant
bash /mnt/skills/user/deploy-to-vercel/resources/deploy.sh

# Déployer un projet spécifique
bash /mnt/skills/user/deploy-to-vercel/resources/deploy.sh /chemin/vers/projet

# Déployer une archive existante
bash /mnt/skills/user/deploy-to-vercel/resources/deploy.sh /chemin/vers/projet.tgz

Le script détecte automatiquement le framework depuis package.json, empaquète le projet (en excluant node_modules, .git, .env), le télécharge, et attend la fin de la construction.

Dites à l'utilisateur : « Votre déploiement est prêt sur [previewUrl]. Réclamez-le sur [claimUrl] pour gérer votre déploiement. »

Solution de secours sans authentification — sandbox Codex

Quand l'utiliser : Dans le sandbox Codex où la CLI peut ne pas être authentifiée. Codex s'exécute dans un environnement sandboxé par défaut — essayez d'abord la CLI, et utilisez le script de secours si l'authentification échoue.

Vérifiez si la CLI Vercel est installée (aucune escalade nécessaire pour cette vérification) :
```
command -v vercel
```
Si vercel est installé, essayez de déployer avec la CLI :
```
vercel deploy [chemin] -y --no-wait
```

Si vercel n'est pas installé, ou si la CLI échoue avec « Aucune information d'identification existante trouvée », utilisez le script de secours :

skill_dir="<chemin-vers-la-competence>"

# Déployer le répertoire courant
bash "$skill_dir/resources/deploy-codex.sh"

# Déployer un projet spécifique
bash "$skill_dir/resources/deploy-codex.sh" /chemin/vers/projet

# Déployer une archive existante
bash "$skill_dir/resources/deploy-codex.sh" /chemin/vers/projet.tgz

Le script gère la détection du framework, l'empaquetage et le déploiement. Il attend la fin de la construction et retourne du JSON avec previewUrl et claimUrl.

Dites à l'utilisateur : « Votre déploiement est prêt sur [previewUrl]. Réclamez-le sur [claimUrl] pour gérer votre déploiement. »

Accès réseau escaladé : N'escaladez que la commande de déploiement réelle si le sandbox bloque l'appel réseau (sandbox_permissions=require_escalated). N'escaladez pas la vérification command -v vercel.

Notes spécifiques aux agents

Claude Code / agents en terminal

Vous avez un accès complet au shell. N'utilisez PAS le chemin /mnt/skills/. Suivez le flux de décision ci-dessus en utilisant la CLI directement.

Pour la solution de secours sans authentification, exécutez le script de déploiement depuis l'emplacement installé de la compétence :

bash ~/.claude/skills/deploy-to-vercel/resources/deploy.sh [chemin]

Le chemin peut varier selon l'endroit où l'utilisateur a installé la compétence.

Environnements sandboxés (claude.ai)

Vous ne pouvez probablement pas exécuter vercel login ou git push. Allez directement à la solution de secours sans authentification — sandbox claude.ai.

Codex

Codex s'exécute dans un sandbox. Vérifiez d'abord si la CLI est disponible, puis utilisez le script de secours. Allez à la solution de secours sans authentification — sandbox Codex.

Sortie

Affichez toujours l'URL de déploiement à l'utilisateur.

Git push : Utilisez vercel ls --format json pour trouver l'URL de prévisualisation. Si la CLI n'est pas authentifiée, dites à l'utilisateur de vérifier le tableau de bord Vercel ou les vérifications de statut du commit.
Déploiement CLI : Affichez l'URL retournée par vercel deploy --no-wait. Utilisez vercel inspect <url> pour vérifier l'état de la construction et le signaler à l'utilisateur.

Solution de secours sans authentification : Affichez à la fois l'URL de prévisualisation et l'URL de réclamation :

Déploiement réussi !

URL de prévisualisation : https://mon-app-abc123.vercel.app
URL de réclamation :      https://vercel.com/claim-deployment?code=...

Consultez votre site sur l'URL de prévisualisation.
Pour transférer ce déploiement vers votre compte Vercel, visitez l'URL de réclamation.

Ne faites pas de curl ou de requête HTTP sur l'URL déployée pour vérifier son fonctionnement. Retournez simplement le lien.

Dépannage

Erreur de sortie réseau (claude.ai)

Si le déploiement échoue en raison de restrictions réseau sur claude.ai, dites à l'utilisateur :

Le déploiement a échoué en raison de restrictions réseau. Pour résoudre ce problème :

1. Allez sur https://claude.ai/settings/capabilities
2. Ajoutez *.vercel.com aux domaines autorisés
3. Réessayez de déployer

Accès réseau escaladé (Codex / environnements sandboxés)

Si le déploiement échoue en raison de problèmes réseau (timeouts, erreurs DNS, réinitialisations de connexion) dans un environnement sandboxé, réexécutez avec des permissions escaladées (sandbox_permissions=require_escalated). N'escaladez pas la vérification initiale de disponibilité de la CLI — n'escaladez que la commande de déploiement réelle.

Exemple de message à l'utilisateur :

Le déploiement nécessite un accès réseau escaladé pour déployer sur Vercel. Je peux réexécuter
la commande avec des permissions escaladées — voulez-vous que je procède ?

Échec d'authentification CLI

Si vercel login ou vercel deploy échoue avec des erreurs d'authentification, utilisez le script de déploiement sans authentification (variante claude.ai ou Codex, selon l'environnement).

PhuongDeveloper/landingpage

Qu'est-ce que landingpage ?

Demander à votre IA préférée

Documentation