Déployer sur Vercel depuis la CI quand l'auteur du commit n'est pas membre de l'équipe

J'ai déplacé landee dans une organisation GitHub pour que mes commits comptent dans mon propre graphe de contributions. Au tout premier push suivant, la production a cessé de se déployer.

Le tableau de bord Vercel disait juste ceci — à chaque push. L'intégration Git native s'était discrètement transformée en barrière :

Deployment Blocked
The deployment was blocked because the commit could not be
matched to a team member.

Pourquoi Vercel bloque le déploiement

L'intégration Git native de Vercel est un déploiement par webhook : GitHub envoie un événement de push, Vercel lit l'auteur du commit, vérifie s'il est membre de l'équipe Vercel, et bloque le déploiement sinon. C'est un contrôle de sécurité : il empêche un contributeur quelconque, ou la pull request d'un fork, de déployer automatiquement en production.

C'est raisonnable, jusqu'à ce que la personne qui écrit le code ne soit pas un membre payant. Mon compte GitHub signe les commits, mais il n'est pas membre de l'équipe Vercel. Donc pour l'intégration, chaque déploiement vient d'un « non-membre », et chaque déploiement est bloqué.

Déploie avec la CLI, pas avec l'intégration Git

La CLI est la sortie. vercel deploy s'authentifie avec un token, pas avec l'auteur du commit — il n'exécute jamais la vérification d'appartenance. Alors déconnecte l'intégration Git native et déploie depuis GitHub Actions : push → le workflow tourne → vercel deploy avec un token → Vercel build et livre.

name: Deploy Production (Vercel CLI)

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
      VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
    steps:
      - uses: actions/checkout@v7
      - run: npm install -g vercel@latest
      - run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}
      - run: vercel deploy --prod --token=${{ secrets.VERCEL_TOKEN }}

Deux choses en font le seul chemin de déploiement, pour que la CLI et le webhook ne se marchent pas dessus : vercel.json désactive l'auto-déploiement natif, et tu cliques sur Disconnect sur le dépôt Git dans le tableau de bord Vercel.

{
  "git": { "deploymentEnabled": false },
  "installCommand": "pnpm install --frozen-lockfile"
}

Garde ton graphe de contributions GitHub

Tout l'intérêt du passage en organisation, c'était que les commits comptent dans mon graphe — donc le commit sur GitHub doit rester signé par moi. C'est déjà le cas ici : le déploiement CLI tourne sur un checkout tout neuf dans le runner, et rien de tout ça n'est repoussé vers GitHub.

Donc je commite en mon nom, je pousse, et les cases vertes se remplissent. Le token qui autorise le déploiement appartient au propriétaire du compte, pas à moi — c'est précisément le but d'un déploiement en CI.

Fais afficher qui a poussé dans le tableau de bord

Un simple déploiement CLI apparaît dans la liste Vercel comme un hash nu — pas de message, pas de branche, pas d'auteur. Pour obtenir une vraie ligne façon git (message + branche + avatar), Vercel doit reconnaître le déploiement comme un commit git — et cette reconnaissance est justement ce qui relance la vérification de l'auteur.

L'astuce : dans le runner, réécris l'auteur de HEAD vers un membre de l'équipe, puis déploie. L'amend n'est jamais repoussé, donc sur GitHub le commit reste le tien. Vercel lit l'auteur-membre depuis .git — le déploiement est reconnu et non bloqué — et tu mets celui qui a vraiment poussé dans le message du commit pour que la ligne dise encore qui a livré.

# In the runner only — this amend is NEVER pushed back, so on GitHub the
# commit stays authored by the real pusher (your contribution graph is intact).
MSG="$(git log -1 --pretty=%s)"
git -c user.name="CI Bot" -c user.email="ci@your-org.dev" \
  commit --amend --author="CI Bot <ci@your-org.dev>" \
  -m "[$GITHUB_ACTOR] $MSG"

# Vercel now reads a team-member author from .git → recognized AND not blocked.
vercel deploy --prod --token="$VERCEL_TOKEN"

Un compte de service par lequel tout le monde déploie

Généralise : un compte de service possède l'équipe Vercel et détient le token de déploiement. Tout le monde commite en son nom ; la CI réécrit l'auteur vers le compte de service et déploie avec son token. La ligne du tableau de bord affiche [toi] ton message de commit, et GitHub garde ta vraie paternité.

C'est la version ennuyeuse et honnête de ce que beaucoup d'équipes cherchent. Tu paies pour les sièges de ceux qui ont besoin d'accéder au tableau de bord — pas un par contributeur. Un token de CI qui déploie le code de tous, c'est le modèle documenté par Vercel ; tu n'achètes pas un siège à quelqu'un juste parce que son code part en prod.

Les détails qui mordent

Deux ou trois choses qui m'ont coûté une soirée, pour qu'elles ne te la coûtent pas :

• pnpm sur Vercel. L'image de build peut figer un vieux pnpm quel que soit ton champ packageManager. Passe --build-env ENABLE_EXPERIMENTAL_COREPACK=1 à vercel deploy pour que corepack utilise la version que tu as réellement épinglée.
• Commits vérifiés. La signature est indépendante : configure la signature SSH des commits et enregistre la clé sur GitHub, et tes (vrais) commits obtiennent le badge vert Verified. L'amend jetable du runner n'a pas besoin de signature.
• Exécutions lisibles. Découpe l'unique gros pas de shell en étapes nommées (re-author → deploy → summary) pour que l'interface Actions montre l'étape d'un coup d'œil.
• Tests. Le déploiement build sur Vercel mais ne lance jamais tes tests — ajoute un workflow CI dédié pour ça, et active Dependabot au passage.

Le déploiement CLI est autorisé par un token, pas par celui qui a écrit le commit. C'est tout le déblocage — et c'est une façon documentée et de premier ordre de livrer.

Où est la limite

Soyons honnêtes sur la limite, car on la franchit facilement en se justifiant. Déployer le code des contributeurs via un token de CI est légitime et prévu. Créer de faux comptes pour contourner la facturation au siège ne l'est pas — c'est du multi-comptes, et c'est contraire aux conditions de toute plateforme.

À retenir

• L'intégration Git native de Vercel bloque les déploiements dont l'auteur du commit n'est pas membre de l'équipe — une barrière de sécurité, pas un bug.
• vercel deploy avec un token ne vérifie jamais l'auteur ; déconnecte l'intégration native et déploie depuis la CI.
• Commite en ton nom et ne pousse jamais l'amend du runner, et ton graphe GitHub reste intact.
• Réécrire l'auteur de HEAD vers un membre dans le runner donne une vraie ligne de tableau de bord sans blocage — mets celui qui a poussé dans le message.
• Tu paies pour des sièges de tableau de bord, pas par contributeur : un token de CI qui déploie le code de tous, c'est le modèle prévu.
• Créer de faux comptes pour contourner la facturation, c'est du multi-comptes. C'est là la limite.

Aucune de ces pièces n'est exotique — la CLI, un token, un git amend qui ne quitte jamais le runner. Le déclic, c'est de comprendre que le mur « pas membre » ne te dit pas d'acheter un autre siège ; il te dit de déployer comme la CI est censée le faire. Déconnecte le webhook, confie le token au runner — et laisse celui qui a écrit le code en garder le mérite.