Tutoriel du connecteur Claude Code : trier des dépôts GitHub en 20 minutes

Dans ce tutoriel, je vous montre comment connecter Claude Code à GitHub à l'aide d'un connecteur Claude (basé sur le Model Context Protocol) et l'utiliser pour trier de bout en bout un dépôt open source. 

Ce flux de travail ne clone rien, n'exige aucun vecteur de recherche et ne touche à aucune ligne du dépôt cible. À la place, Claude Code lit les issues via le connecteur et écrit des artefacts sur votre système de fichiers local, que vous relisez avant de décider ce qu'il convient (ou non) de publier.

À la fin de ce tutoriel, vous aurez :

• Une configuration fonctionnelle de Claude Code et du GitHub MCP avec un jeton en lecture seule,
• Des invites réutilisables que vous pouvez pointer sur n'importe quel dépôt public,
• Un artefact de triage complet pour langchain-ai/langchain pour comparaison.

Qu'est-ce que le connecteur GitHub Claude Code (MCP) ?

Claude Code est l'agent de développement en ligne de commande d'Anthropic. 

Dès l'installation, il a accès à votre système de fichiers, votre shell et git. Les connecteurs Claude Code l'étendent pour atteindre des contextes externes — issues GitHub, tickets Linear, messages Slack, requêtes Postgres, etc. — que le terminal ne peut pas gérer seul.

Le protocole de connecteur s'appelle MCP (Model Context Protocol), une norme ouverte pour exposer des outils et des données aux agents LLM. 

Anthropic maintient un annuaire de connecteurs prêts à l'emploi ; vous pouvez aussi créer les vôtres ou vous connecter à des serveurs MCP tiers.

Pour ce tutoriel, nous utiliserons le serveur GitHub MCP officiel, qui s'exécute en local via Docker. Principes clés de la configuration :

• S'exécute en conteneur Docker local sans intermédiaire cloud, vos identifiants restent sur votre machine.
• Authentifié avec un GitHub Personal Access Token (PAT) standard, sans besoin d'enregistrer une application OAuth.
• Prend en charge des permissions restreintes, par exemple un PAT sans portée, offrant un accès en lecture seule aux dépôts publics, ce qui rend toute écriture impossible au niveau de l'API GitHub.
• Exposé à Claude Code via la commande claude mcp add ; les outils sont ensuite disponibles dans chaque session.

Le triage open source implique surtout de la lecture, du jugement et un faible coût à se tromper. 

Lire 50 issues et les regrouper est fastidieux pour un humain, mais bien adapté à un modèle qui peut tout garder en contexte d'un coup. 

De plus, nous écrivons d'abord les sorties en fichiers locaux ; un mauvais regroupement ou un brouillon maladroit ne coûte rien, et vous pouvez le corriger à la relecture.

Tutoriel du connecteur GitHub Claude Code : construire un triage pour langchain-ai/langchain

Dans cette section, nous allons configurer le connecteur GitHub dans Claude Code et exécuter quatre invites de triage sur langchain-ai/langchain. C'est un grand dépôt ML avec un suivi d'issues véritablement encombré. En bref, voici ce que nous allons construire :

• Connecter Claude Code à GitHub via le serveur MCP officiel exécuté dans Docker,
• Utiliser un PAT sans portée pour que le connecteur soit en lecture seule par conception,
• Exécuter des invites de triage qui enregistrent les résultats dans des fichiers locaux,
• Relire les sorties, y compris des cas où Claude refuse de regrouper des issues en doublons.

Passons à la construction étape par étape.

Étape 1 : installer les prérequis pour Claude Code et Docker

Avant de configurer le connecteur, vous aurez besoin de trois éléments :

• Claude Code : vous pouvez l'installer depuis le guide officiel d'Anthropic,
• Docker Desktop : le serveur GitHub MCP officiel s'exécute en conteneur, Docker doit donc être installé et démarré,
• Un compte GitHub : nécessaire pour générer le PAT à l'étape suivante.

Une fois les prérequis en place, vérifiez que Docker est en cours d'exécution :

docker info | head -5

Si Docker n'est pas installé ou si le démon n'est pas démarré, vous verrez l'erreur "Cannot connect to the Docker daemon". Sur macOS, lancez Docker Desktop avec :

open -a Docker

Docker Desktop met 15 à 60 secondes à être pleinement prêt, et docker info retournera des erreurs pendant cet intervalle. Plutôt que de vérifier à la main, utilisez une petite boucle d'attente qui interroge jusqu'à ce que le démon soit prêt :

until 

docker info >/dev/null 2>&1; do sleep 2; echo "waiting..."; done && echo "Docker ready"

Dès que Docker ready s'affiche, vous pouvez continuer.

Étape 2 : créer un jeton GitHub en lecture seule

Une fois Docker configuré, allez sur github.com/settings/tokens et générez un nouveau jeton classique.

Remarque : laissez toutes les portées décochées. Un jeton sans portée peut tout de même lire les dépôts publics via l'API GitHub, ce qui est tout ce dont notre agent a besoin. Sans aucune portée sélectionnée, le jeton ne peut rien écrire, modifier ou supprimer sur GitHub, quoi que nous demandions à Claude. C'est une garantie stricte appliquée côté GitHub, pas une simple promesse sur le comportement de l'agent.

Copiez et enregistrez le jeton immédiatement après sa création, puis exportez-le dans votre shell :

export GITHUB_PERSONAL_ACCESS_TOKEN="ghp_your_token_here"

Si vous êtes déjà dans une session Claude Code, vous pourriez être tenté d'utiliser le préfixe ! pour exécuter directement la commande d'export dans votre shell (par ex., ! export GITHUB_PERSONAL_ACCESS_TOKEN="..."). 

Cependant, comme ! lance un sous-shell temporaire, la variable disparaîtra dès la fin de la commande et Claude ne la verra pas.

Pour définir le jeton en toute sécurité sans le coller dans l'invite du modèle, vous avez deux options :

1. Tapez /exit pour quitter Claude, exécutez la commande d'export dans votre terminal habituel, puis relancez claude.
2. Ou enregistrez le jeton dans un fichier local .env dans votre répertoire de travail, que Claude Code lit automatiquement au démarrage.

Vérifiez que les deux prérequis sont prêts sans afficher le jeton lui-même :

docker info | head -3
echo "Token set: ${GITHUB_PERSONAL_ACCESS_TOKEN:+yes}"

La deuxième commande affiche Token set: yes si la variable existe, et Token set: (rien après les deux-points) si elle est vide. 

C'est plus sûr que d'afficher directement le jeton, car il n'y a aucune chance qu'il se retrouve en clair dans l'historique de votre shell.

Étape 3 : enregistrer le connecteur GitHub auprès de Claude Code

Le serveur GitHub MCP officiel est fourni sous forme d'image Docker. 

Nous l'enregistrons dans Claude Code avec claude mcp add :

claude mcp add github \
  -e GITHUB_PERSONAL_ACCESS_TOKEN=$GITHUB_PERSONAL_ACCESS_TOKEN \
  -- docker run -i --rm \
  -e GITHUB_PERSONAL_ACCESS_TOKEN \
  ghcr.io/github/github-mcp-server

Les deux indicateurs -e ne sont pas une faute de frappe :

• Le premier -e (avant --) définit une variable d'environnement pour le processus MCP lancé par Claude Code,
• Le second -e (dans les arguments de docker run) demande à Docker de transmettre cette variable au conteneur.

Si vous en oubliez un et que le conteneur démarre avec un jeton vide, l'authentification à l'API GitHub échouera.

Pour vérifier que le connecteur est bien enregistré :

claude mcp list

Vous devriez voir :

github — docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/github/github-mcp-server —  Connected

Si vous voyez Failed to connect, les deux causes les plus probables sont Docker qui ne tourne pas ou GITHUB_PERSONAL_ACCESS_TOKEN non exportée dans le même shell que celui où vous avez exécuté claude mcp add.

Étape 4 : test de bon fonctionnement de la connexion

Notre jeton GitHub est en place. Créons maintenant un répertoire de travail et ouvrons l'interface CLI de Claude Code :

mkdir demo && cd demo
claude

La commande claude lance une session interactive dans le répertoire courant. 

Tous les fichiers que Claude écrira durant le triage seront stockés ici. 

Posez ensuite une question simple en lecture seule pour confirmer l'utilisation du connecteur :

En utilisant le connecteur GitHub MCP, récupérez les 5 issues ouvertes les plus récemment mises à jour dans langchain-ai/langchain. Ne listez que les titres et les numéros.

La première fois que Claude Code utilise un outil GitHub, il demande une approbation. 

Approuvez les outils en lecture seule comme list_issues, get_issue, search_issues, etc. 

Si Claude se rabat sur curl vers l'API publique GitHub au lieu d'utiliser les outils MCP, le connecteur n'est pas chargé. Quittez alors votre session et redémarrez-la.

Une exécution réussie renvoie quelque chose comme :

Dès que vous voyez de vrais numéros d'issues revenir via MCP, vous pouvez lancer le triage proprement dit.

Étape 5 : générer un résumé du backlog

La mise en jambe est purement en lecture. Nous voulons maintenant cartographier le contenu du suivi d'issues avant toute autre action.

Prompt:
En utilisant le connecteur GitHub MCP, récupérez les 50 issues ouvertes les plus récemment mises à jour de langchain-ai/langchain. 
Lisez leurs titres, corps et labels. Regroupez-les par nature probable — bugs, demandes de fonctionnalités, documentation, questions et "besoin de plus d'infos". 
Pour chaque groupe, donnez-moi un décompte et 3 à 5 numéros d'issues représentatifs avec une raison en une ligne. Enregistrez sous backlog-summary.md dans le répertoire courant.

Claude Code récupère les issues via le connecteur, les lit et écrit un fichier markdown les regroupant par thématique avec des numéros représentatifs. Ce fichier seul est utile : un mainteneur peut le parcourir en 60 secondes et savoir à quoi ressemble la semaine à venir.

Étape 6 : signaler des candidats doublons

La détection de doublons est là où un agent se rentabilise. 

Lire 50 issues de bout en bout et les regrouper par problème sous-jacent est pénible pour un humain, mais un modèle peut tout garder en contexte et repérer des recouvrements qu'une recherche par mots-clés manquerait.

Prompt:
À partir des mêmes 50 issues déjà récupérées, identifiez des grappes de doublons probables : des issues décrivant le même problème sous-jacent, même si les titres diffèrent. Pour chaque grappe, indiquez les numéros d'issues, une description du problème commun en une phrase et un niveau de confiance (élevé/moyen/faible). Enregistrez sous duplicate-candidates.md.

Voici ce que Claude a réellement produit lors de mon exécution :

La partie la plus intéressante de cette sortie concerne les grappes 2 à 4. 

Un détecteur de doublons naïf basé sur des mots-clés aurait fermé les quatre grappes en doublons. 

Claude a explicitement refusé de les qualifier de doublons. 

Il les a signalées comme des grappes de composants partageant le même sous-système mais avec des causes racines distinctes, et m'a indiqué lesquelles fermer réellement (seulement la grappe 1) et lesquelles trier conjointement mais laisser ouvertes.

C'est le comportement attendu d'un·e triagiste consciencieux·se, et exactement pourquoi le schéma fichiers locaux puis relecture vaut l'étape supplémentaire. 

Si nous avions branché cela directement à l'API GitHub et auto-fermé tout ce que Claude signalait, nous aurions fermé trois vrais bugs.

Étape 7 : relire, puis décider quoi publier

C'est tout l'intérêt du schéma fichiers locaux. 

Avant que quoi que ce soit ne touche GitHub, ouvrez chaque fichier .md enregistré par Claude et vérifiez si le regroupement correspond à votre intuition. 

Les grappes à forte confiance ressemblent-elles vraiment à des doublons ? Lisez 2 ou 3 réponses brouillon et vérifiez si elles sonnent comme vous.

Si vous souhaitez effectivement publier des commentaires ou appliquer des labels, deux options s'offrent à vous :

• Manuel : vous pouvez coller vous-même les brouillons dans GitHub. Pour un triage ponctuel sur le dépôt de quelqu'un d'autre, c'est très bien et souvent le meilleur choix.
• Autoriser les écritures sur un dépôt que vous possédez : générez un PAT distinct avec la portée repo, ajoutez-le comme une entrée de connecteur distincte (ex. github-write), puis réexécutez les invites en demandant à Claude d'appliquer les labels et de publier les commentaires. Claude Code demandera une approbation lors du premier usage de chaque outil d'écriture.

La mesure de sécurité clé pour la voie d'écriture est de garder séparés les jetons de lecture et d'écriture. 

Conclusion

Dans ce tutoriel, j'ai montré comment connecter Claude Code à GitHub via MCP et l'utiliser pour trier de bout en bout un vrai dépôt open source. 

Plutôt que de créer un bot GitHub sur mesure ou de câbler des webhooks, le flux lit les issues via le serveur GitHub MCP officiel, écrit quatre artefacts de triage en fichiers locaux et vous laisse tout relire avant de décider quoi publier.

La conclusion plus large, c'est que les connecteurs transforment Claude Code d'un agent de code en un outil capable de lire vos outils et de préparer du travail à valider.

Le bon réflexe par défaut est de garder ce travail en local jusqu'à l'avoir vu, puis, une fois le schéma éprouvé, d'autoriser sélectivement l'agent à agir là où le coût d'une erreur est faible.

À partir d'ici, vous pouvez étendre le projet de plusieurs façons :

• Ajouter des connecteurs en écriture sur des dépôts que vous possédez afin que les labels et commentaires soient appliqués automatiquement après relecture,
• Chaîner des connecteurs Linear ou Slack pour synchroniser les décisions de triage avec le flux de travail de votre équipe,
• Transformer les invites en job CI planifié qui produit une PR de triage hebdomadaire,
• Ou généraliser les invites ci-dessus en une commande slash Claude Code réutilisable qui fonctionne sur n'importe quelle URL de dépôt.