Vous savez maintenant faire les gestes. On va les confier à Claude.
Ce qu'on installe ici s'appelle un skill : un mode d'emploi rangé dans votre projet, que Claude charge automatiquement quand il en a besoin. Celui-ci s'appellera deployer, et il se déclenchera dès que vous direz « déploie ».
À partir de là, la Pull Request, la fusion, la vérification : c'est lui.
Un prompt à envoyer une seule fois
Collez le texte ci-dessous dans votre session, juste après que Claude a fini de travailler. Il crée le fichier, l'enregistre dans votre dépôt, et l'utilise immédiatement.
Toutes vos sessions futures, sur ce projet, en hériteront.
Le site est construit. On va maintenant installer la procédure de déploiement, pour que je n'aie plus jamais à la refaire à la main.
Crée un fichier .claude/skills/deployer/SKILL.md dans le dépôt, avec cet en-tête YAML :
---
name: deployer
description: Met le site en ligne, de bout en bout. À utiliser dès que je dis « déploie », « mets en ligne », « publie », ou dès qu'une modification est terminée et validée.
---
Le corps du skill décrit la procédure à suivre, dans cet ordre, en t'adressant à toi-même :
1. VÉRIFIER — lancer `npm run build`. S'il échoue, corriger et relancer jusqu'à ce qu'il passe. Ne jamais déployer un projet qui ne se construit pas.
2. RELIRE — vérifier qu'aucune valeur de couleur ou de police n'a été écrite en dur hors du bloc @theme de app/globals.css.
3. TENIR À JOUR — mettre à jour CLAUDE.md : les pages ajoutées, les choix de design, ce qui reste à faire.
4. COMMITTER ET POUSSER — un message de commit clair en français décrivant ce qui change, puis pousser la branche de travail.
5. OUVRIR LA PULL REQUEST — charger l'outil create_pull_request du serveur MCP GitHub, puis l'appeler avec : le propriétaire du dépôt, le nom du dépôt, la branche de travail comme source, main comme cible, un titre court en français, et un corps qui résume les changements en trois points. Vérifier au passage s'il existe un gabarit de PR dans .github/, et le respecter le cas échéant.
6. FUSIONNER — charger l'outil merge_pull_request, puis l'appeler avec le numéro de la PR et la méthode `merge`, qui conserve la trace de la branche dans l'historique.
7. VÉRIFIER POUR DE VRAI — faire `git fetch origin main` puis `git log`, et confirmer que le commit de fusion est bien arrivé. Ne jamais se contenter de la réponse « merged: true » de l'API GitHub.
8. ANNONCER — me dire en français : ce qui a changé, le lien de la PR, et que Vercel publie la nouvelle version dans la minute.
Ajoute au skill deux règles de prudence :
- Si la modification touche à la structure du site, à la navigation, ou supprime du contenu, me demander confirmation AVANT l'étape 5.
- Si le build échoue et que la correction n'est pas évidente, s'arrêter et m'expliquer, plutôt que d'accumuler les tentatives.
Puis ajoute dans CLAUDE.md, section des règles de travail : « Pour mettre le site en ligne, suis le skill deployer. »
Quand c'est fait, applique-le tout de suite pour déployer le site.
Pourquoi un skill plutôt qu'une consigne dans CLAUDE.md ?
Parce que les deux ne servent pas au même moment.
Le CLAUDE.md est lu au début de chaque session : il porte ce qui est vrai en permanence — votre activité, vos couleurs, vos interdits. Une procédure en huit points noyée dedans se dilue à mesure que la conversation avance.
Un skill, lui, se déclenche sur une intention. Vous dites « déploie », et le mode d'emploi arrive frais, complet, au moment exact où il sert.
Et comme il vit dans votre dépôt, il suit le projet. Nouvelle session dans six mois, nouvel ordinateur, peu importe : la procédure est toujours là.
Est-ce que c'est prudent de le laisser publier tout seul ?
Pour un site personnel, oui — et le skill contient trois garde-fous.
Il ne déploie jamais un projet cassé. La construction doit passer avant tout le reste.
Il demande votre accord avant de publier une modification qui touche à la structure du site ou supprime du contenu.
Il vérifie vraiment. Plutôt que de croire la réponse de GitHub, il redépose la question au dépôt lui-même avant d'annoncer que c'est fait.
Et de toute façon, rien n'est perdu : chaque version reste dans l'historique. Une publication ratée se rattrape en demandant à Claude de revenir en arrière.
Claude n'arrive pas à créer ou fusionner la Pull Request
Deux causes possibles.
Le connecteur GitHub n'est pas actif. C'est celui que vous avez branché à l'étape 2. Vérifiez dans Paramètres → Connecteurs que la ligne Intégration GitHub affiche bien une coche.
La branche main est protégée. Sur un dépôt personnel, ce n'est pas le cas par défaut. Si vous avez activé une règle de protection, la fusion automatique sera refusée : faites-la à la main comme à l'étape 4.