Déploiement automatique de Claude Code / Cursor vers Vercel — Trois workflows avec MCP, Plugin et GitHub Actions

« Claude Code a fait la correction ; maintenant je pousse à la main et j'ouvre le tableau de bord Vercel dans le navigateur... » Pour réduire ces allers-retours, Vercel propose officiellement trois outils : Vercel MCP (un serveur qui permet aux outils d'IA de travailler avec vos projets, déploiements et logs Vercel), le Vercel Plugin (une extension qui ajoute la connaissance de Vercel et des commandes slash à Claude Code, à Cursor et à d'autres) et les Agent Skills (des lots d'instructions installés avec npx skills add). Les noms se ressemblent et les rôles semblent se chevaucher, d'où des explications mélangées comme « connecter les Agent Skills via MCP ».

La conclusion d'abord : il est utile de penser le déploiement d'un agent IA vers Vercel en trois approches. ① L'intégration Git (git push → déploiement automatique) suffit pour l'essentiel du travail en solo. ② Directement depuis l'éditeur (Vercel MCP, Vercel Plugin) convient à ceux qui veulent que l'IA gère aussi ce qui entoure un déploiement : lire les logs, toucher aux variables d'environnement. ③ GitHub Actions + Claude Code Action s'adresse aux équipes qui veulent que @claude corrige depuis les commentaires de PR et ne publier qu'après des tests ou des validations. Il n'y a pas de « meilleure » option : tout dépend de ce que vous confiez à l'IA et de l'endroit où un humain l'arrête.

Cet article a été rédigé après avoir relu la documentation originale de Vercel et d'Anthropic le 30 septembre 2026. Les exemples de configuration, les commandes et les conditions des offres datent de ce jour (les deux évoluent vite : vérifiez les pages liées avant de vous y fier). À lire en complément : L'IA recommande Vercel, Qu'est-ce que Cursor et L'IA peut-elle gérer l'infrastructure ?.

1. « Agent Skills », « MCP » et « Plugin » ne sont pas la même chose

Même quand l'IA écrit le code, la vérification du déploiement se fait sur un autre écran : retour au terminal pour git add . && git commit -m "fix" && git push, ouverture du tableau de bord Vercel dans le navigateur, copie de l'URL de preview, collage dans Slack. Vercel a ajouté peu à peu des portes d'entrée pensées pour l'IA afin de réduire ces changements de contexte.

Les remettre dans l'ordre dissipe la confusion. Le 4 août 2025, Vercel MCP est passé en bêta publique (annonce de Vercel) : un serveur MCP distant avec authentification OAuth, à l'adresse https://mcp.vercel.com. Le même mois, en août 2025, la Claude Code GitHub Action d'Anthropic est passée en v1.0 (le tag v1.0.0 date du 2025-08-25). Le 17 mars 2026 est arrivé le Vercel Plugin (annonce), et le 23 juillet 2026, Vercel MCP a pu déployer du code directement (annonce).

Et les Agent Skills ne sont pas du MCP. La page Agent Skills de Vercel les décrit comme des capacités empaquetées, installées avec npx skills add <owner/repo>, qui apprennent à un agent une façon précise de travailler, utilisables dans plus de 18 agents dont Claude Code, GitHub Copilot et Cursor. Si MCP est le moyen d'agir sur votre compte, les Skills sont le savoir-faire. Voir aussi Qu'est-ce que MCP et Claude Agent SDK.

2. Les cinq portes d'entrée de Vercel : ce que fait chacune et comment elle s'authentifie

Voici les voies par lesquelles un agent IA peut atteindre Vercel, telles que les décrit la documentation officielle (au 30 septembre 2026). La colonne d'authentification — ce que vous confiez à l'IA — détermine la gravité possible d'un accident.

Sources : Vercel MCP, référence des outils MCP, Vercel Plugin, Agent Skills, pourquoi les commits ne déclenchent pas de déploiement (KB Vercel).

Comment le lire : si vous avez seulement besoin que « ça se déploie », l'intégration Git suffit. MCP et le Plugin deviennent rentables quand vous voulez que la conversation couvre ce qui entoure un déploiement : faire lire les logs à l'IA pour comprendre pourquoi un build a échoué, montrer les écarts de variables d'environnement, ramener la production un cran en arrière.

3. Les trois approches en un coup d'œil

Voici les trois approches selon ce que reçoit l'IA × la profondeur d'automatisation × l'endroit où un humain l'arrête.

Repères : si vous ouvrez souvent le tableau de bord après un déploiement juste pour lire les logs, optez pour ②. Si la revue de PR est la routine et que vous ne voulez publier que des changements testés, optez pour ③. Pour un blog perso ou une petite appli, ① suffit : en faire trop coûte plus en maintenance que ça ne rapporte. Les trois ne s'excluent pas ; la forme habituelle est ① comme socle, avec ② ou ③ par-dessus.

4. Approche 1 : intégration Git (déploiement automatique au git push)

La configuration la plus simple. Reliez Vercel à GitHub : Vercel lance un build à chaque git push et publie à la fin du build. Le travail de l'IA se limite à écrire le code, écrire le message de commit et pousser. Le guide GitHub Actions de Vercel lui-même explique que, puisque l'intégration Git gère déjà les URL de preview, les déploiements immuables et le rollback instantané, la plupart des équipes n'ont besoin d'aucun pipeline.

# Configuration (une seule fois)
1. Tableau de bord Vercel → Add New → Project
2. Choisir le dépôt GitHub → Import
3. Framework Preset : détection automatique (Next.js, etc.)
4. Environment Variables : ajouter si besoin
5. Deploy

# Flux quotidien (dans Cursor / Claude Code)
> Passe ce bouton en rouge. Quand c'est fait, pousse sur une branche feature/red-button.

# Commandes lancées par l'IA
git switch -c feature/red-button
git add app/components/Button.tsx
git commit -m "feat: change primary button to red"
git push -u origin feature/red-button

# Vercel construit une preview → la PR reçoit une URL de preview

La vraie valeur ici, c'est que chaque branche reçoit automatiquement son URL de preview. Les URL de preview de Vercel sont de deux types : une URL de branche qui pointe toujours vers le dernier état de la branche et une URL de commit qui pointe vers ce déploiement précis (Environments). Si seuls les merges dans main partent en production, l'IA peut pousser autant qu'elle veut : tout s'arrête en preview.

Attention : l'offre Hobby est réservée à un usage personnel et non commercial (offre Hobby). On peut créer 100 déploiements par jour en Hobby et 6 000 en Pro, et Hobby exécute un build à la fois (Limits). Si l'IA pousse par toutes petites étapes, vous toucherez ces limites en premier. Pour les pièges tarifaires, voir le §5 de L'IA recommande Vercel.

5. Approche 2 : directement depuis l'éditeur (Vercel MCP et Vercel Plugin)

Pour laisser l'IA gérer ce qui entoure un déploiement, utilisez Vercel MCP ou le Vercel Plugin. Ni l'un ni l'autre n'exige d'écrire un token dans un fichier.

Configurer Vercel MCP (Cursor) : selon les instructions officielles, il suffit de mettre une URL dans .cursor/mcp.json (au niveau du projet ou global).

{
  "mcpServers": {
    "vercel": {
      "url": "https://mcp.vercel.com"
    }
  }
}

Une fois le serveur ajouté, Cursor tente de se connecter et affiche Needs login. Cliquez pour vous connecter à Vercel dans le navigateur et choisir les équipes que Cursor peut utiliser. Dans Claude Code, deux lignes suffisent :

claude mcp add --transport http vercel https://mcp.vercel.com
# puis lancer claude et s'authentifier avec /mcp

La documentation cite aussi npx add-mcp https://mcp.vercel.com, qui déclare le serveur dans plusieurs clients d'un coup. Attention : ajouter le serveur ne termine pas l'autorisation. Tant que vous ne vous êtes pas connecté et n'avez pas autorisé une équipe, l'IA ne voit ni ses déploiements ni ses logs (référence des outils).

MCP fournit des outils, pas des commandes slash. Vous demandez par exemple « regarde les erreurs de mon dernier déploiement », et l'IA choisit et appelle des outils comme ceux-ci (extrait de la liste au 30 septembre 2026) :

Le Vercel Plugin (npx plugins add vercel/vercel-plugin) ajoute la connaissance de Vercel et cinq commandes slash, avec espace de noms : /vercel-plugin:deploy (ajoutez prod pour la production), /vercel-plugin:env (list, pull, add, remove, diff), /vercel-plugin:status, /vercel-plugin:bootstrap et /vercel-plugin:marketplace (Vercel Plugin). En lisant la définition de la commande deploy, on voit qu'elle pilote votre Vercel CLI locale (vercel, vercel --prod), fait une preview par défaut et attend un « oui » explicite avant la production. Il n'existe pas de commandes /logs ou /rollback ; les logs et le rollback passent par les outils MCP ou par la CLI (vercel rollback).

Le vrai gain, c'est que tout reste dans la conversation. Demandez « ajoute cette API, déploie-la en preview et, s'il y a une erreur, lis les logs et corrige », et l'IA enchaîne modification du code → déploiement → lecture du log de build → correction → redéploiement. Dans les termes de L'IA peut-elle gérer l'infrastructure ?, on est dans la zone « capable mais dangereuse ». Vercel indique clairement qu'une connexion MCP donne à l'IA les mêmes accès que votre compte utilisateur Vercel, et recommande de toujours activer la confirmation humaine. Ne passez pas les appels d'outils en validation automatique.

6. Approche 3 : GitHub Actions (@claude et portes de contrôle)

La configuration d'équipe. Avec Claude Code GitHub Actions, vous mentionnez @claude dans un commentaire d'issue ou de PR, et Claude commite une correction puis répond dans le même fil. Le déploiement de preview reste assuré par l'intégration Git de l'approche 1 : quand Claude pousse sur la branche de la PR, Vercel reconstruit la preview.

# Configuration
1. Lancer /install-github-app dans Claude Code (dépôts github.com uniquement)
2. Installer la Claude GitHub App ; stocker ANTHROPIC_API_KEY (ou CLAUDE_CODE_OAUTH_TOKEN) dans les Secrets
3. .github/workflows/claude.yml arrive sous forme de pull request

# .github/workflows/claude.yml (exemple de la documentation officielle)
name: Claude Code
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
jobs:
  claude:
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    timeout-minutes: 30          # stopper les jobs qui s'emballent (conseillé par la doc)
    permissions:
      contents: write
      pull-requests: write
      issues: write
      id-token: write            # requis pour l'authentification par défaut via la GitHub App
      actions: read              # lire les résultats de CI sur les PR
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          claude_args: "--max-turns 10"   # plafonner les tours par exécution

timeout-minutes et --max-turns sont ajoutés à titre d'exemple : ce sont les deux mesures que recommande la section « Manage costs » de la documentation (adaptez les valeurs à votre projet). Aucune limite de tours ne s'applique par défaut : fixez-la vous-même.

Si vous voulez aussi que GitHub Actions déploie — uniquement si vous avez besoin de tests, d'analyses de sécurité, de budgets de performance ou d'une validation humaine avant le déploiement —, suivez le guide officiel de Vercel. Il faut trois secrets : VERCEL_TOKEN, VERCEL_ORG_ID et VERCEL_PROJECT_ID (les deux derniers se trouvent dans le .vercel/project.json créé par vercel link).

# .github/workflows/vercel-preview.yml (forme reprise de la KB Vercel)
name: Vercel Preview Deployment
env:
  VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
  VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
on:
  push:
    branches-ignore:
      - main
jobs:
  Deploy-Preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install --global vercel@latest
      - run: vercel pull --yes --environment=preview --token=${{ secrets.VERCEL_TOKEN }}
      # placer ici les tests et les analyses
      - run: vercel build --token=${{ secrets.VERCEL_TOKEN }}
      - run: vercel deploy --prebuilt --token=${{ secrets.VERCEL_TOKEN }}

# vercel.json — couper les déploiements déclenchés par Git pour éviter un double déploiement
{ "git": { "deploymentEnabled": false } }

Le même guide liste les pièges : si l'intégration Git reste active pendant qu'Actions déploie aussi, les deux se déclenchent sur le même commit ; sans --prebuilt, Vercel reconstruit la même chose une seconde fois. À l'inverse, si vous voulez seulement lancer des tests, il est plus léger de garder l'intégration Git, de lancer les tests contre la preview sur l'événement deployment_status et d'utiliser les Deployment Checks pour bloquer la promotion en production.

# À quoi ça ressemble en pratique
# Un développeur ouvre une PR → l'intégration Git construit une preview
[Bot] Vercel Preview: https://<url-de-preview>

# Un relecteur commente la PR
@claude fais aussi changer la couleur de ce bouton au survol

# Claude ajoute un commit et répond → Vercel reconstruit la preview
# Le relecteur vérifie → approve → merge → déploiement en production

Attention : pour un dépôt privé, l'auteur du commit doit être membre de l'équipe Vercel (ou, en Hobby, le propriétaire), sinon rien n'est déployé (KB Vercel). Si des commits créés dans Actions ne produisent pas de preview, vérifiez d'abord le commentaire du Vercel Bot et l'auteur du commit.

Cette configuration rend réaliste le scénario « personne ne touche au code avant que la PR soit prête ». Comme vu dans Seniors contre juniors et L'IA va-t-elle supprimer les emplois de bureau ?, l'équipe se concentre sur la revue pendant que l'IA implémente.

7. Utiliser les environnements de preview : branche → URL → partage

Ce qui paie dans les trois approches, c'est d'exploiter à fond les environnements de preview. Vercel crée automatiquement des déploiements de preview pour les branches hors production et pour les PR : vous pouvez donc mettre plusieurs versions d'un même changement côte à côte sans configuration supplémentaire.

Sources : Environments (options de staging et offres), Password Protection (tarif), Sharable Links (un seul en Hobby), le tout au 30 septembre 2026. La protection par défaut sans mot de passe est Vercel Authentication (seuls les membres de l'équipe peuvent voir), que Vercel présente comme la méthode recommandée.

8. Quatre pièges : fuite d'env, limites et coûts, conflits, rollback

Confiez les déploiements à un agent IA et vous risquez de tomber sur ces quatre pièges. Chacun peut être contenu par une configuration faite à l'avance.

Sources : outils MCP pour les variables d'environnement (get_project_env renvoie la valeur déchiffrée), Spend Management (sans surcoût en Pro et sur certaines offres Enterprise ; l'usage est vérifié toutes les quelques minutes, donc la mise en pause arrive avec un léger retard), Instant Rollback, configuration Git.

Le conseil souvent répété de « placer un proxy Cloudflare devant Vercel » n'est pas une protection que nous recommandons. Dans un article officiel de la KB, Vercel indique ne pas recommander un proxy externe en frontal, car le Vercel Firewall perd la visibilité complète sur le trafic et les performances baissent.

Une précaution de plus : nous ne recommandons pas d'automatiser entièrement les déploiements en production par l'IA. Même avec les approches ② et ③, gardez la validation finale d'un humain pour la production. Comme vu dans Ce qu'il ne faut pas donner à une IA, l'IA peut casser la production par des erreurs tout à fait involontaires. Automatisez jusqu'à la preview et au staging, et exigez une validation humaine pour la production : une porte à deux niveaux.

Résumé

Pour déployer sur Vercel depuis Claude Code ou Cursor, commencez par distinguer l'intégration Git, la CLI, Vercel MCP, le Vercel Plugin et les Agent Skills. MCP est le moyen d'agir, connecté par OAuth ; le Plugin apporte les commandes /vercel-plugin:* et de la connaissance ; les Skills sont des instructions. Le déploiement lui-même est, dans la plupart des cas, très bien assuré par l'intégration Git.

Le choix dépend de ce que vous confiez à l'IA et de l'endroit où un humain l'arrête : ① travail solo → intégration Git ; ② vous voulez que l'IA fouille les logs et gère l'env → Vercel MCP / Plugin (pas de token dans un fichier : connexion par OAuth) ; ③ équipes où la revue de PR est la routine → GitHub Actions (@claude corrige ; le déploiement vient de l'intégration Git, ou d'Actions + CLI quand il faut des portes de contrôle). Utilisez les previews pour la comparaison A/B, le staging et la validation client, et parez les quatre pièges avec la confirmation des appels d'outils, des réglages de limites et de dépenses, une procédure de rollback et une validation humaine pour la production.

Pour aller plus loin, voir L'IA recommande Vercel, Vercel AI SDK, v0 vs Bolt vs Lovable, Qu'est-ce que Cursor et L'IA peut-elle gérer l'infrastructure ?.

FAQ

Q. Peut-on faire la même chose avec d'autres hébergeurs (Cloudflare, Netlify) ?
R. Oui. Les deux publient des serveurs MCP officiels. Cloudflare propose un catalogue de serveurs MCP distants auxquels on se connecte par OAuth, dont un pour les builds Workers (serveurs MCP de Cloudflare). Netlify propose le Netlify MCP Server. Choisissez selon l'adéquation avec votre framework et le prix plutôt que selon l'existence d'une intégration avec les agents. Voir aussi les critères de L'IA recommande Vercel.

Q. Claude Code ou Cursor : lequel est le mieux adapté au déploiement sur Vercel ?
R. Les deux sont pris en charge par Vercel MCP et par le Vercel Plugin, donc ce qu'on peut faire côté Vercel est presque identique. La différence tient à la façon de travailler : Claude Code est centré sur le terminal, avec une intégration officielle à GitHub Actions ; Cursor est centré sur l'éditeur, avec un ajout de MCP en un clic. Si vous vivez dans VS Code, Cursor est naturel ; si vous vivez dans le terminal, Claude Code.

Q. Peut-on laisser l'IA automatiser entièrement les déploiements en production ?
R. Ce n'est pas recommandé. Automatisez jusqu'à la preview et au staging, mais gardez toujours la validation finale d'un humain pour la production. Les raisons : l'IA peut casser la production sans la moindre malveillance, et la responsabilité devient floue en cas d'incident. Utilisez la Branch Protection de GitHub pour interdire le push direct sur main et exiger des PR approuvées.

Q. Peut-on versionner .cursor/mcp.json dans git ?
R. Avec la configuration officielle de Vercel MCP, il ne contient aucun secret. Il ne contient que l'URL https://mcp.vercel.com ; l'authentification se fait par OAuth et reste côté navigateur, donc le versionner pour le partager avec l'équipe ne pose pas de problème. C'est différent si vous écrivez en dur la clé d'API d'un autre serveur MCP dans un en-tête : ce fichier-là ne doit pas aller dans git. Le VERCEL_TOKEN utilisé en CI se range dans les Secrets GitHub, jamais dans le fichier de workflow.

Q. Le coût de GitHub Actions m'inquiète.
R. D'après la documentation officielle, le coût vient de deux choses : les minutes GitHub Actions et les tokens de l'API Claude (si vous vous authentifiez avec un token OAuth d'abonnement, les exécutions consomment votre abonnement Claude au lieu d'une facturation à l'usage de l'API). Le montant par exécution dépend de la longueur du prompt, de la complexité de la tâche et de la taille du code. Les leviers cités par la documentation : plafonner les tours avec --max-turns dans claude_args, mettre des timeouts au workflow, formuler des demandes @claude précises et garder CLAUDE.md concis. Aucune limite de tours n'existe par défaut : fixez-la vous-même.