Connecter Claude à GitHub : repos, issues et PR

Demandez à Claude de « résumer ce repo et d'ouvrir une pull request qui corrige le test en échec » : avec le connecteur GitHub branché, il va réellement lire votre code, rédiger un patch et pousser une branche avec une PR que vous pouvez relire. Cette leçon présente les deux voies par lesquelles Claude atteint GitHub, les permissions exactes en jeu, et un workflow concret « résumer puis corriger ».

Deux voies vers GitHub : le connecteur ou le serveur MCPMCPUn standard ouvert qui permet aux assistants IA de se connecter aux outils et données de l'entreprise de façon cohérente et gouvernée, sans intégration sur mesure à chaque fois.Voir la définition complète →

Claude dialogue avec GitHub via l'un de ces deux mécanismes, et savoir lequel vous utilisez compte, parce que leurs modèles de confiance et de permissions diffèrent.

Le connecteur GitHub est l'option gérée, en quelques clics, à l'intérieur des applications Claude. Vous l'ajoutez depuis l'annuaire de connecteurs, vous vous authentifiez auprès de GitHub via OAuth, et Claude obtient un ensemble d'outils GitHub sélectionnés (lire des fichiers, lister les issues, commenter, ouvrir des PR). Anthropic le maintient. Vous n'exécutez rien. Parcourez ce qui est disponible dans l'annuaire des connecteurs Claude.

Le serveur MCP GitHub est l'option de plus bas niveau, auto-hébergée (ou hébergée à distance). MCP, le Model Context Protocol, est le standard ouvert qui permet à n'importe quel outil de s'exposer à un client IA. GitHub publie un serveur MCP officiel, et vous y pointez Claude Code ou l'application desktop Claude. Cela vous donne un contrôle plus fin sur les scopes, peut tourner à l'intérieur de votre réseau, et expose plus d'outils que le connecteur grand public. La spec et les SDK sont sur modelcontextprotocol.io.

Règle empirique : utilisez le connecteur dans les applications Claude pour le triage et la lecture au quotidien. Utilisez le serveur MCP quand vous êtes dans Claude Code, quand vous en avez besoin en CI, ou quand vous voulez scoper vous-même un tokentokenUn token est l'unité de base de texte que traitent les modèles de langage : le plus souvent un fragment de mot, un mot entier ou un signe de ponctuation, plutôt qu'un simple caractère.Voir la définition complète → fine-grained.

Où se trouve chacun

Installer le serveur MCP dans Claude Code

Claude Code est l'agent de terminal qui opère déjà sur votre checkout local. Ajouter le serveur MCP GitHub lui permet de passer de vos fichiers locaux au remote : issues, PR, runs d'Actions, reviews.

La configuration la plus propre utilise le serveur MCP GitHub distant avec OAuth. Depuis votre repo :

claude mcp add --transport http github https://api.githubcopilot.com/mcp/

À la première utilisation, Claude Code déclenche un flow OAuth dans le navigateur. Vérifiez la connexion à tout moment avec :

claude mcp list

Si vous préférez un token plutôt qu'OAuth (courant en CI), définissez un personal access token fine-grained comme variable d'environnement et passez-le. Nous allons voir juste après quelles permissions exactes ce token nécessite, car c'est là que la plupart des gens accordent trop.

Permissions du token : accordez le strict nécessaire

C'est la partie à ne pas rater. **Un token GitHub capable de lire et d'écrire *partout* est un risque**, surtout quand c'est un agent autonomeagent autonomeLogiciel qui poursuit un objectif seul : il planifie, utilise des outils et agit avec une intervention humaine limitée.Voir la définition complète → qui le détient.

GitHub propose des personal access tokens fine-grained qui se limitent à des dépôts et des catégories de permissions spécifiques. Pour un workflow Claude qui lit un repo, trie les issues et ouvre des PR, il vous faut :

• Contents : Read and write (lire les fichiers source, crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éererLe rapport entre les interactions (likes, commentaires, partages) et le reach d'un contenu, utilisé pour mesurer la réaction de l'audience au regard du nombre de personnes touchées.Voir la définition complète → des branches, pousser des commits)
• Pull requests : Read and write (ouvrir et mettre à jour des PR)
• Issues : Read and write (triage, commentaires, labels)
• Metadata : Read (socle obligatoire ; GitHub le sélectionne automatiquement)

C'est tout. Vous n'avez pas besoin d'admin, vous n'avez pas besoin de workflow write sauf si Claude modifie des fichiers sous .github/workflows/, et vous devriez limiter le token au seul repo sur lequel vous travaillez, pas à tout votre compte.

Créez-en un dans GitHub → Settings → Developer settings → Fine-grained tokens, sélectionnez le repo cible, définissez les quatre permissions ci-dessus, et donnez-lui une expiration courte. Puis :

export GITHUB_PERSONAL_ACCESS_TOKEN="github_pat_xxx"

Un modèle mental clé : le flow OAuth du connecteur et votre token fine-grained constituent le *plafond* de ce que Claude peut faire. Le modèle ne peut pas dépasser ces scopes, quel que soit le prompt. Les permissions sont votre vrai contrôle de sécurité, pas le prompt.

Le workflow concret : résumer un repo, puis ouvrir une PR

Voici l'exemple de bout en bout annoncé en introduction. Supposons que vous êtes dans Claude Code, dans un repo checkouté, avec le serveur MCP GitHub connecté.

Étape 1 : résumer le dépôt

Vous n'avez pas besoin d'un prompt astucieux. Soyez précis sur ce que « résumé » signifie pour vous :

Lis la structure de ce repo, le README et les principaux points d'entrée. Donne-moi un résumé d'un paragraphe de ce qu'il fait, la stack technique principale, et les trois zones les plus susceptibles de contenir des bugs. Ensuite, liste les issues ouvertes labellisées bug, triées selon leur caractère actionnable apparent.

Claude utilise les outils MCP pour lister les fichiers, lire le README et le manifeste de package, et appeler l'endpoint des issues. Comme Claude Code a aussi vos fichiers locaux, il lit le code source directement et utilise surtout le serveur MCP pour l'état *remote* (issues, liste des PR, statut CI). Le résultat est un résumé fondé, pas une supposition, parce qu'il a réellement chargé le contenu en contexte.

Étape 2 : choisir un correctif et le rédiger

Disons qu'une issue indique : *« parse_date lève une exception sur une chaîne vide au lieu de retourner None. »* Dites à Claude :

Reproduis l'issue #42 avec un test rapide, corrige parse_date pour qu'une chaîne vide ou composée uniquement d'espaces retourne None, et assure-toi que les tests existants passent toujours.

Claude localise la fonction, écrit le correctif, exécute votre suite de tests en local, et itère si quelque chose échoue. C'est la partie que la version connecteur-dans-l'application gère moins bien, parce qu'elle ne peut pas *exécuter* vos tests. Claude Code, oui.

Étape 3 : ouvrir la pull request

Vient l'étape spécifique à GitHub. Claude crée une branche, commite, pousse et ouvre une PR via l'outil pull-request du serveur MCP :

Crée une branche fix/parse-date-empty, commite le changement avec un message clair, pousse-la, et ouvre une PR contre main. Référence l'issue #42 dans la description et explique le correctif en deux phrases.

En coulisses, cela correspond à des appels d'API GitHub que le token a autorisés : create-ref, create-commit et create-pull-request. Vous récupérez une vraie URL de PR. Rien ne se merge automatiquement. Vous relisez, votre CI tourne, et un humain approuve.

Si vous voulez cela entièrement scripté plutôt que conversationnel, la même capacité est disponible via le Claude Agent SDK, où vous attachez le serveur MCP comme outil et laissez un agent géré exécuter la boucle. Un attachement d'outil minimal ressemble à ceci :

from claude_agent_sdk import ClaudeSDKClient, ClaudeAgentOptions

options = ClaudeAgentOptions(
    mcp_servers={
        "github": {
            "type": "http",
            "url": "https://api.githubcopilot.com/mcp/",
            "headers": {"Authorization": "Bearer ${GITHUB_PERSONAL_ACCESS_TOKEN}"},
        }
    },
    allowed_tools=["mcp__github__create_pull_request", "mcp__github__get_issue"],
)

async with ClaudeSDKClient(options=options) as claude:
    await claude.query("Triage issue #42 and open a fix PR against main.")
    async for message in claude.receive_response():
        print(message)

Notez allowed_tools : même avec le serveur connecté, vous placez en allowlist exactement les outils GitHub que l'agent peut appeler. C'est une deuxième couche de contrôle par-dessus le scope du token. Voir la documentation du Claude Agent SDK pour l'API d'outils complète.

Le triage à l'échelle : les issues comme flux

Ouvrir des PR est la démo spectaculaire, mais le gain quotidien plus discret est le triage des issues. Avec un accès read/write sur les issues, Claude peut :

• Labelliser les issues entrantes par domaine et sévérité en utilisant votre taxonomie de labels existante
• Détecter les doublons en comparant une nouvelle issue à celles ouvertes
• Rédiger un premier commentaire de réponse demandant une repro quand elle manque
• Résumer un thread bruyant de 40 commentaires en une décision et une action suivante

Un pattern qui fonctionne bien : gardez cela dans un Project de l'application Claude avec le connecteur GitHub attaché et un Style qui impose le ton de votre équipe pour les commentaires d'issues. Le Project contient le contexte permanent (vos définitions de labels, vos règles de triage) ; le connecteur fournit les données d'issues en direct ; le Style maintient la cohérence des commentaires publics de Claude. Vous combinez trois fonctionnalités de Claude que vous connaissez déjà en un seul workflow reproductible.

Pour les repos à fort volume, poussez le triage dans la CI : une GitHub Action exécute Claude Code sur chaque nouvelle issue avec un token étroitement scopé et un prompt fixe. Le token plafonne toujours ce à quoi il peut toucher, donc au pire un raté labellise mal une issue, il ne peut pas pousser de code.

Ce que le connecteur ne peut pas faire, et pourquoi c'est une bonne chose

Le connecteur GitHub grand public ne peut délibérément pas exécuter de code arbitraire, ne peut pas lancer votre suite de tests, et ne peut pas atteindre une infrastructure privée. Si vous demandez à l'application de « corriger et vérifier », elle peut lire et proposer, mais la vérification demande Claude Code ou votre CI.

Cette frontière est une fonctionnalité. Le connecteur de l'application sert à lire, raisonner et rédiger. Dès que vous avez besoin d'exécution, vous êtes passé dans Claude Code ou l'Agent SDK, où vous avez explicitement accordé un token et mis des outils en allowlist. La capacité n'augmente que dans la mesure où vous le décidez.

Quelques garde-fousgarde-fousRègles et contrôles qui maintiennent un système d'IA dans des limites sûres, légales et conformes à la marque, en bloquant les sorties et actions hors cadre.Voir la définition complète → à standardiser dans votre équipe :

• Protection de branche sur `main` pour qu'aucune PR ouverte par un agent ne puisse se merger sans review et CI verte.
• Expiration courte du token et scoping par repo, avec rotation régulière.
• Allowlists d'outils dans toute config de SDK ou d'agent, jamais « tous les outils ».
• Relisez chaque PR. Claude rédige ; les humains mergent. Traitez les PR d'agents exactement comme la première PR d'un nouveau contributeur.

Points clés

• Choisissez la bonne voie : le connecteur GitHub dans les applications Claude pour la lecture et le triage, le serveur MCP GitHub dans Claude Code ou l'Agent SDK quand vous avez besoin de lancer des tests et de pousser de vraies PR.
• Scopez un token fine-grained à quatre permissions : Contents, Pull requests et Issues (read/write) plus MetadataMetadataDonnées sur les données, informations décrivant le contexte, la structure, la provenance et les caractéristiques d'un asset de données (auteur, date, format, source, définition). (read), limité à un seul repo avec une expiration courte. Les permissions, pas les prompts, sont votre contrôle de sécurité.
• La boucle résumer-puis-corriger est concrète : lire le repo et les issues, reproduire et corriger en local avec Claude Code, puis créer une branche → commit → push → PR via l'outil pull-request du MCP. Rien ne se merge sans vous.
• Empilez vos contrôles : le scope du token plafonne la capacité, allowed_tools met en allowlist des actions précises, et la protection de branche garantit une review humaine avant le merge.
• Combinez des fonctionnalités que vous avez déjà : un Project pour les règles de triage permanentes, un Style pour le ton des commentaires, et le connecteur pour les données en direct transforment une aide ponctuelle en workflow d'équipe reproductible.