Avez-vous déjà essayé d'expliquer ce qu'est une « pull request » à un ami non-technique et vu ses yeux se vitrifier comme une chaîne de production de Krispy Kreme ? Imaginez maintenant lui dire qu'une IA peut non seulement comprendre votre dépôt, mais aussi ouvrir des PR à votre place. Bienvenue en 2025, où votre éditeur de code est à la fois un copilote, un passager arrière un peu relou et, si vous le configurez correctement, un stagiaire plutôt compétent.
Ce guide vous montre comment connecter GitHub à Claude Code et générer automatiquement des « pull requests ». Nous passerons de « Hein ? » à « Valider » grâce à une configuration étape par étape, des flux de travail concrets et quelques pièges à éviter. Vous allez connecter GitHub, permettre à Claude Code de voir ce qui se passe, et lui faire ouvrir et mettre à jour des PR que vous pouvez réellement fusionner sans avoir l'impression d'avoir pactisé avec le diable algorithmique.
Attention : Vous allez voir deux chemins principaux ici : utiliser l'intégration GitHub Actions de Claude Code et utiliser les serveurs Model Context Protocol (MCP) pour donner à Claude un accès sûr et limité aux API GitHub. Lequel choisir ? Si vous voulez une aide « plug-and-play » pour les PR directement dans GitHub, la voie Actions est votre meilleure option. Si vous voulez un contrôle local de votre dépôt, basé sur le chat et avec des permissions granulaires, MCP est votre outil de prédilection.
Ce que nous allons construire
- Connecter GitHub à Claude Code de manière sécurisée.
- Permettre à Claude d'analyser votre dépôt, de proposer des modifications et d'ouvrir des PR.
- Automatiser les revues, les étiquettes, les listes de contrôle et même les « commits » de suivi.
- Ajouter des garde-fous pour qu'il ne renomme pas tout votre monorepo en « final_final_v2 ».
Pourquoi c'est important
Parce que le changement de contexte est l'impôt sur la productivité que personne n'a voté. Une IA capable d'ouvrir une PR avec la même rigueur que celle attendue d'un développeur junior (les bons jours) est un véritable gain de temps. Pas pour remplacer les humains (calmez-vous), mais pour remplacer les parties « pff, code répétitif » de l'ingénierie.
Chemin A : Générer automatiquement des PR avec Claude Code GitHub Actions
Si vous vivez dans GitHub toute la journée (bienvenue au club), ce chemin vous donne un bot qui peut analyser le code dans les « issues » et les PR, suggérer des modifications, et même ouvrir ou mettre à jour des PR, directement depuis votre dépôt.
Ce dont vous aurez besoin
- Un dépôt GitHub que vous contrôlez (ou une branche que vous pouvez casser sans pleurer).
- Un accès administrateur au dépôt pour configurer les Actions et les secrets.
- Une clé API Claude si votre action ou votre flux de travail en a besoin.
Étape 1 : Activer GitHub Actions dans votre dépôt
- Allez dans votre dépôt → Paramètres → Actions → Général.
- Activez « Autoriser toutes les actions et les flux de travail réutilisables » (ou limitez-vous aux actions approuvées par votre organisation si vos responsables de la sécurité vous surveillent déjà du coin de l'œil).
Étape 2 : Ajouter un flux de travail Claude Code
Créez .github/workflows/claude-pr-bot.yml avec un déclencheur basé sur votre flux de travail préféré. Voici deux modèles courants :
Option 1 : PR basées sur les « issues »
- Lorsque vous ouvrez une « issue » avec une étiquette spéciale (par exemple, ai-pr), le flux de travail s'exécute.
- Il lit l'invite de l'« issue » (par exemple, « Ajouter un interrupteur de mode sombre »), crée une nouvelle branche, modifie les fichiers à l'aide de Claude, pousse les « commits » et ouvre une PR avec un résumé détaillé.
Option 2 : Modifications basées sur les commentaires dans une PR existante
- Lorsque vous commentez @claude merci de refactoriser la modale des paramètres, le flux de travail s'exécute.
- Il analyse la « diff », propose des modifications et pousse les mises à jour vers la branche de la PR.
Flux de travail de démarrage (schéma général)
name: Claude PR Bot
on:
issues:
types: .
- Un guide rapide sur l'intégration et les cas d'utilisation vous donne une vue d'ensemble de ce qu'il est raisonnable d'automatiser (et de ce qui ne l'est pas) dans les équipes réelles.
- Si vous êtes plutôt visuel, cette présentation montre des PR générées automatiquement par l'IA en action, du début à la fin.
Chemin B : Connecter GitHub à Claude Code via MCP (pour les utilisateurs experts locaux)
Si vous voulez que Claude travaille avec le contexte de votre dépôt local (les fichiers sur votre machine, les branches que vous jonglez, les commandes auxquelles vous faites confiance), MCP vous donne un pont avec des permissions. Considérez-le comme un portier pour votre dépôt : il décide quelles portes Claude peut ouvrir.
Ce dont vous aurez besoin
- Claude Desktop ou une intégration IDE qui prend en charge les outils MCP.
- Un serveur GitHub MCP que vous exécutez localement, configuré avec un jeton qui limite les autorisations.
- Un jeton d'accès personnel (PAT) avec uniquement les autorisations dont vous avez vraiment besoin (par exemple, repo:status, public_repo, pull_request write).
Étape 1 : Récupérer un serveur GitHub MCP
- Il existe un serveur officiel « open-source » qui expose certaines opérations de l'API GitHub (rechercher des « issues », créer des branches, ouvrir des PR, etc.). Il est configurable pour que vous n'activiez que ce dont vous avez besoin, ce qui réduit également la confusion de l'IA et maintient la sécurité. Pour une vue d'ensemble plus large des serveurs MCP et des exemples, consultez le répertoire central.
Étape 2 : Configurer votre client pour qu'il communique avec le serveur
- Dans votre fichier de configuration client (par exemple, une configuration JSON pour votre application d'IA), enregistrez le serveur GitHub MCP, transmettez-lui votre jeton via des variables d'environnement et mettez en liste blanche les dépôts autorisés.
- Conseil de pro : Mettez le jeton dans votre trousseau système ou dans un fichier dotenv, pas dans votre fichier de configuration. Ne devenez pas l'exemple à ne pas suivre lors de votre prochaine réunion générale.
Étape 3 : Tester la surface d'attaque de l'outil
- Demandez à Claude de lister les « issues » ouvertes, de lire un fichier spécifique ou de créer une branche. Vérifiez qu'il ne peut rien faire que vous n'ayez pas explicitement autorisé.
- Ce n'est qu'après avoir vérifié la cohérence des commandes de base que vous devez activer create_pull_request.
Étape 4 : Laisser Claude proposer et ouvrir une PR
- Exemple d'invite : « Dans le dépôt org/app-frontend, crée une nouvelle branche feat/dark-toggle, implémente un interrupteur de paramètres pour le mode sombre dans SettingsPanel.tsx, mets à jour les tests et ouvre une PR avec une liste de contrôle pour l'assurance qualité. »
- Le serveur orchestre : lit l'état du dépôt, écrit les modifications (si vous avez configuré les outils de fichiers locaux), pousse une branche, ouvre une PR avec votre modèle et publie un résumé.
En toute honnêteté : Les garde-fous dont vous avez réellement besoin
- Simulations en lecture seule : Demandez à Claude de produire une « diff » unifiée (git diff) avant d'autoriser l'accès en écriture. Fusionnez après l'avoir examinée.
- Corps de PR modélisés : Incluez des notes sur les risques, des plans de test et des étapes de déploiement. Faites en sorte que le bot remplisse le modèle ; faites-le réviser par des humains.
- Règles d'étiquetage : Appliquez automatiquement des étiquettes telles que ai-generated et needs-tests pour que les choses restent détectables et honnêtes.
- Nommage des branches : Exigez un préfixe (ai/ ou bot/) avec des règles de protection des branches. Les robots ont aussi besoin d'uniformes.
Anecdote : J'ai demandé à une IA de « corriger le bug d'authentification ». Elle l'a « corrigé » en supprimant l'authentification. Génial pour la productivité ! Terrible pour tout le reste. Gardez les autorisations limitées, les invites spécifiques et les tests CI rigoureux.
De zéro à PR : Un scénario réaliste de bout en bout
Scénario : Corriger un test de « debounce » instable dans un projet React
- Vous ouvrez une « issue » : « Debounce util : flake on 200ms boundary in CI. » Vous l'étiquetez ai-pr.
- Le flux de travail se déclenche. Il recherche debounce.ts et les tests associés.
- Claude propose une « diff » : ajuste les minuteurs avec jest.useFakeTimers, ajoute une marge dans les assertions, met à jour la documentation.
- Le bot ouvre une PR avec : titre, résumé, justification, plan de test et évaluation des risques.
- Vous examinez la « diff », vous contestez : « Cas limite lorsque delay=0. »
- Vous commentez @claude gère delay=0 avec un flush immédiat ; ajoute un test. Le flux de travail se relance et pousse un « commit ».
- CI réussit. Vous écrasez et fusionnez. Quelque part, un test instable crie « à l'aide ».
À quoi ressemblent les bonnes invites (et ce qu'il faut éviter)
- Bien : « Ajoute un interrupteur de mode sombre à SettingsPanel.tsx ; persiste dans localStorage ; mets à jour SettingsPanel.test.tsx ; respecte nos règles ESLint ; modifie uniquement /src/ui/ et /src/utils/ ; 250 lignes maximum. »
- Bof : « Implémente le mode sombre. »
Sécurisez-le : Vérification rapide de la sécurité et de la conformité
- Autorisations des jetons : Utilisez repo:contents write uniquement si nécessaire ; préférez pull_request write pour la création de PR.
- Liste blanche des dépôts : Verrouillez le bot sur un seul dépôt ou une seule organisation.
- Journalisation : Assurez-vous que le bot enregistre ses actions et ses invites (sans les secrets). Vous voudrez des preuves lorsqu'il « améliorera » votre Dockerfile.
- Protections des branches : Exigez deux approbations humaines pour les branches ai/*.
Dépannage : Quand le bot ne veut pas « botter »
- Il ne peut pas pousser de branches : Vérifiez les autorisations Actions pour contents: write et que votre jeton a l'accès repo write.
- Il ouvre des PR vides : Votre générateur de contexte ne lui transmet pas les bons fichiers. Renforcez votre logique de sélection de fichiers.
- Il expire sur les grands dépôts : Limitez le contexte aux chemins modifiés ou à un manifeste. L'IA a des indigestions sur les monorepos de 10 Go, comme nous tous.
- Il ignore votre modèle de PR : Vérifiez que le modèle se trouve dans .github/pull_request_template.md ou qu'il est lié dans les paramètres de votre dépôt.
Quand utiliser quel chemin
- Utilisez GitHub Actions si vous voulez un moyen simple de générer automatiquement des PR à partir d'« issues » ou de commentaires, avec tout ce qui se passe dans GitHub.
- Utilisez MCP si vous voulez que Claude fonctionne dans votre environnement local ou sur plusieurs outils avec des contrôles très spécifiques.
Il est important de noter : Si vous souhaitez une vérification rapide de la cohérence du flux de travail ou générer une invite de démarrage solide, Sider.AI peut vous aider à rédiger des modèles de PR et des invites de garde-fous, puis à les itérer avec de vrais extraits de dépôt. C'est comme avoir un éditeur qui a des opinions bien arrêtées et qui écrit réellement du code. Et qui ne vous vole pas votre chaise de bureau. Modèles courants que vous voudrez copier
- Étiquettes de PR IA et CODEOWNERS : Dirigez les PR ai/* vers un groupe de relecture qui aime se disputer avec les robots.
- « Commits » étape par étape : Demandez à Claude de créer de petits « commits » atomiques avec des messages clairs au lieu d'un méga-« commit » nommé « trucs ».
- Mode « Test d'abord » : Demandez au flux de travail de générer d'abord les tests, d'exécuter CI, puis de générer l'implémentation. C'est plus lent. C'est mieux.
- Tâches après la fusion : Ajoutez un flux de travail pour ouvrir automatiquement une « issue » de suivi pour la documentation, les « feature flags » ou le nettoyage.
Un rapide coup d'œil à la concurrence
- Certaines personnes connectent d'autres LLM à des flux GitHub similaires. Cela fonctionne, mais le raisonnement de code de Claude Code et sa volonté de dire « Je ne suis pas sûr » peuvent vous faire gagner des heures d'essais et d'erreurs. L'intégration de GitHub Actions le maintient là où les relectures se font naturellement, et la voie MCP est flexible pour les utilisateurs experts.
La liste de contrôle de configuration en 10 minutes
- Choisissez un chemin : GitHub Actions (plus rapide) ou MCP (plus de contrôle).
- Créez votre jeton avec des autorisations minimales.
- Ajoutez le flux de travail ou configurez le serveur MCP.
- Créez un générateur de contexte strict : listes de fichiers, limites et règles.
- Ajoutez des protections de branche et des étiquettes.
- Testez d'abord sur une petite modification. Fusionnez. Célébrez. Dites à votre chef de projet que vous avez « augmenté le débit ».
Références rapides à garder à portée de main
- Documentation de Claude Code GitHub Actions (modèles, déclencheurs, exemples).
- Guide pratique de l'intégration et des meilleures pratiques.
- Présentation vidéo : PR générées par l'IA de bout en bout.
- Serveur GitHub MCP pour un accès granulaire et autorisé.
- Répertoire des serveurs MCP et exemples pour l'inspiration.
Le mot de la fin
L'automatisation des PR avec Claude Code ne remplacera pas votre équipe d'ingénierie. Elle remplacera les corvées les moins appréciées de votre équipe d'ingénierie. Commencez par des autorisations limitées, des invites claires et des relectures strictes. Laissez le bot gérer l'échafaudage pendant que vous vous occupez de la réflexion. Ensuite, revenez aux choses amusantes, comme enfin supprimer ce fichier utils2.ts que vous évitez parce que vous savez qu'il maintient l'application ensemble avec du ruban adhésif et des rêves.
Maintenant, allez rendre votre futur vous un peu moins grincheux. Et si le bot se déchaîne ? Vous savez où se trouve le bouton « Annuler ».
FAQ
Q1 : Claude Code peut-il ouvrir des « pull requests » tout seul ?
Oui. Avec GitHub Actions ou une configuration MCP, Claude Code peut créer une branche, pousser des modifications et ouvrir une « pull request » avec un résumé et une liste de contrôle. Gardez les autorisations limitées et exigez une relecture humaine afin qu'il n'« optimise » pas votre sécurité en la supprimant.
Q2 : Quelle est la façon la plus sûre de connecter GitHub à Claude Code ?
Utilisez des jetons avec des autorisations minimales, des listes blanches de dépôts et des protections de branche. Que vous choisissiez Actions ou MCP, activez les simulations et exigez que les tests soient réussis avant de fusionner une « pull request » générée par l'IA.
Q3 : Comment empêcher les PR d'IA de toucher à l'ensemble de mon monorepo ?
Limitez le contexte avec des répertoires en liste blanche et un manifeste de fichiers et limitez le nombre de fichiers par exécution. De bonnes invites aident également : soyez précis sur les chemins et les limites de taille.
Q4 : Pourquoi mes « pull requests » d'IA sont-elles vides ou de mauvaise qualité ?
Votre générateur de contexte alimente peut-être Claude avec les mauvais fichiers ou trop peu de détails. Fournissez des objectifs, des contraintes et des attentes de test clairs, et envisagez un flux en deux passes : générez d'abord les tests, puis l'implémentation.
Q5 : Dois-je utiliser GitHub Actions ou MCP pour Claude Code ?
Si vous voulez une automatisation rapide et native du dépôt pour les PR et les relectures, utilisez GitHub Actions. Si vous avez besoin d'un contrôle local, d'outils personnalisés ou d'autorisations affinées, MCP vous donne plus de puissance, avec un peu plus de configuration.
