Déployer sur Vercel

Déployez n'importe quel projet sur Vercel. Déployez toujours en aperçu (et non en production) sauf si l'utilisateur demande explicitement la production.

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

Étape 1 : Collectez l'état du projet

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

# 1. Vérifiez s'il existe une télécommande git
git remote get-url origin 2>/dev/null

# 2. Vérifiez 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érifiez si Vercel CLI est installé et authentifié
vercel whoami 2>/dev/null

# 4. Listez 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 lequel utiliser pour le déploiement. Une fois que l'utilisateur choisit une équipe, passez immédiatement à l'étape suivante — ne demandez pas de confirmation supplémentaire.

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

vercel deploy [path] -y --no-wait --scope <team-slug>

Si le projet est déjà lié (.vercel/project.json ou .vercel/repo.json existe), l'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 l'invite 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 repo). Contient orgId, remoteName, et un tableau projects associant les répertoires aux ID de projets Vercel.

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

Ne pas utiliser vercel project inspect, vercel ls, ou vercel link pour détecter l'état dans un répertoire non lié — sans la config .vercel/, ils inviteront de manière interactive (ou avec --yes, lieront silencieusement comme effet secondaire). Seul vercel whoami est sûr à exécuter n'importe où.

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

Lié (`.vercel/` existe) + a une télécommande git → Git Push

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

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

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

Commitez et poussez :
```
git add .
git commit -m "deploy: <description des modifications>"
git push
```
Vercel crée automatiquement à partir du push. Les branches de non-production obtiennent des déploiements en aperçu ; la branche de production (généralement main) obtient un déploiement en production.
Récupérez l'URL en aperçu. Si le CLI est authentifié :
```
sleep 5
vercel ls --format json
```
La sortie JSON a un tableau deployments. Trouvez l'entrée la plus récente — son champ url est l'URL en aperçu.

Si le CLI n'est pas authentifié, dites à l'utilisateur de vérifier le tableau de bord Vercel ou les contrôles de statut de commit sur son fournisseur git pour l'URL en aperçu.

Lié (`.vercel/` existe) + pas de télécommande git → `vercel deploy`

Le projet est lié mais il n'y a pas de repo git. Déployez directement avec le CLI.

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

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

vercel inspect <deployment-url>

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

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

Non lié + CLI authentifié → Liez d'abord, puis déployez

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

Demandez à l'utilisateur à 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 qu'une équipe est sélectionnée, procédez directement à la liaison. Dites à l'utilisateur ce qui va se passer mais ne demandez pas de confirmation supplémentaire :
```
Liaison de ce projet à <team name> sur Vercel. Cela créera un projet Vercel
pour déployer et activera les déploiements automatiques lors des prochains git push.
```
Si une télécommande git existe, utilisez la liaison basée sur le repo avec le scope d'équipe sélectionné :
```
vercel link --repo --scope <team-slug>
```
Cela lit l'URL de la télécommande git et la met en correspondance avec les projets Vercel existants qui déploient depuis ce repo. Cela crée .vercel/repo.json. C'est beaucoup plus fiable que vercel link (sans --repo), qui essaie de mettre en correspondance par nom de répertoire et échoue souvent quand le dossier local et le projet Vercel ont des noms différents.

S'il n'y a pas de télécommande git, revenez à la liaison standard :
```
vercel link --scope <team-slug>
```
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 une télécommande git existe → commitez et poussez (voir la méthode git push ci-dessus)
- Si pas de télécommande git → vercel deploy [path] -y --no-wait --scope <team-slug>, puis vercel inspect <url> pour vérifier le statut

Non lié + CLI non authentifié → Installez, authentifiez, liez, déployez

Le CLI Vercel n'est pas du tout configuré.

Installez le CLI (s'il n'est pas déjà installé) :
```
npm install -g vercel
```
Authentifiez-vous :
```
vercel login
```
L'utilisateur complète l'authentification dans son navigateur. Si vous êtes dans un environnement non interactif où la connexion n'est pas possible, passez au secours sans authentification ci-dessous.
Demandez à 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é, procédez immédiatement.

Liez le projet avec le scope d'équipe sélectionné (utilisez --repo si une télécommande git existe, sinon vercel link simple) :

vercel link --repo --scope <team-slug>   # si une télécommande git existe
vercel link --scope <team-slug>          # si pas de télécommande git

Déployez en utilisant la meilleure méthode disponible (git push si le remote existe, sinon vercel deploy -y --no-wait --scope <team-slug>, puis vercel inspect <url> pour vérifier le statut).

Secours sans authentification — sandbox claude.ai

Quand l'utiliser : Dernier recours quand le CLI ne peut pas être installé ou authentifié dans le sandbox claude.ai. Cela ne nécessite aucune authentification — il retourne une URL en aperçu (site actif) et une URL de réclamation (transférer vers votre compte Vercel).

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

Arguments :

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

Exemples :

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

# Déployez un projet spécifique
bash /mnt/skills/user/deploy-to-vercel/resources/deploy.sh /path/to/project

# Déployez une tarball existante
bash /mnt/skills/user/deploy-to-vercel/resources/deploy.sh /path/to/project.tgz

Le script détecte automatiquement le framework à partir de package.json, empaquette le projet (en excluant node_modules, .git, .env), l'envoie 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. »

Secours sans authentification — sandbox Codex

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

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

Si vercel n'est pas installé, ou si le CLI échoue avec « No existing credentials found », utilisez le script de secours :

skill_dir="<path-to-skill>"

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

# Déployez un projet spécifique
bash "$skill_dir/resources/deploy-codex.sh" /path/to/project

# Déployez une tarball existante
bash "$skill_dir/resources/deploy-codex.sh" /path/to/project.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é : Escaladez uniquement la commande de déploiement réelle si le sandboxing bloque l'appel réseau (sandbox_permissions=require_escalated). Ne pas escalader la vérification command -v vercel.

Notes spécifiques aux agents

Claude Code / agents basés sur le terminal

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

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

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

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

Environnements sandboxés (claude.ai)

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

Codex

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

Sortie

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

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

Secours sans authentification : Montrez à la fois l'URL en aperçu et l'URL de réclamation :

Déploiement réussi !

URL en aperçu : https://my-app-abc123.vercel.app
URL de réclamation :   https://vercel.com/claim-deployment?code=...

Consultez votre site sur l'URL en aperçu.
Pour transférer ce déploiement vers votre compte Vercel, visitez l'URL de réclamation.

Ne pas faire de curl ou de fetch sur l'URL déployée pour vérifier qu'elle fonctionne. Renvoyez simplement le lien.

Dépannage

Erreur d'égress réseau (claude.ai)

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

Le déploiement a échoué en raison de restrictions réseau. Pour corriger cela :

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

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é du CLI — escaladez uniquement la commande de déploiement réelle.

Exemple de conseils à 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 continue ?

Échec d'authentification CLI

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