Pour brancher Claude Code sur GitHub, on combine deux briques : le GitHub Action officiel (anthropics/claude-code-action), installé avec la commande /install-github-app, qui fait travailler l'agent dans vos pull requests et vos issues, et un serveur MCP GitHub ajouté avec claude mcp add, qui lui donne accès au dépôt depuis le terminal d'un développeur. Les serveurs MCP, eux, servent à relier l'agent à vos autres outils : tickets, bases de données, API internes.
Le branchement est rapide, quelques minutes. Ce qui prend du temps, c'est de décider ce que l'agent a le droit de faire, et qui relit ce qu'il produit. C'est le sujet de cet article, pensé pour un CTO, un lead tech ou un éditeur SaaS.
Les faits techniques ci-dessous viennent de la documentation officielle de Claude Code, consultée le 4 octobre 2026. Pour l'équipe qui démarre, notre guide Claude Code donne le panorama complet.
1. Claude Code et GitHub : trois niveaux de branchement
"Brancher Claude Code sur GitHub" recouvre trois usages différents, avec des risques différents. Les distinguer évite de tout ouvrir d'un coup.
| Niveau | Où ça tourne | Ce que ça permet | Qui le déclenche |
|---|---|---|---|
| Git en local | Poste du développeur | Branches, commits, diff, via la ligne de commande git | Le développeur, dans son terminal |
| Serveur MCP GitHub | Poste du développeur | Lire et créer des issues, lire des pull requests, commenter | Le développeur, avec son jeton |
| GitHub Action | Runner GitHub | Répondre à @claude, revoir une pull request, transformer une issue en pull request | Un événement GitHub (commentaire, ouverture de PR, planification) |
Le premier niveau ne demande aucune configuration : Claude Code utilise git comme le ferait un développeur. Les deux autres sont l'objet des sections suivantes.
2. GitHub Actions : @claude, revue de pull request et issues
Installer l'action en une commande
Depuis le dépôt concerné, lancez /install-github-app dans Claude Code. La commande fonctionne uniquement avec des dépôts github.com et suppose un accès administrateur au dépôt, ainsi que la CLI GitHub (gh) authentifiée. Elle installe l'application GitHub de Claude, enregistre le secret d'authentification, puis ouvre une pull request avec les fichiers de workflow à fusionner.
Deux modes d'authentification existent :
- ANTHROPIC_API_KEY : une clé API de la Claude Console, facturée au token.
- CLAUDE_CODE_OAUTH_TOKEN : un jeton lié à un abonnement Pro, Max, Team ou Enterprise, généré avec
claude setup-token.
Pour un déploiement sur toute une organisation, la documentation recommande plutôt une clé API stockée en secret d'organisation, car un jeton OAuth est rattaché à l'abonnement de la personne qui l'a généré.
Répondre aux mentions @claude et traiter les issues
Une fois le workflow en place, mentionner @claude dans un commentaire d'issue ou de pull request suffit à lancer l'agent. La documentation cite des demandes du type : implémenter une fonctionnalité décrite dans une issue, corriger une erreur signalée, ou répondre à une question d'architecture. Claude répond dans un commentaire et le met à jour pendant qu'il travaille.
Sur le plan de la gestion des tickets, c'est le cas d'usage le plus utile pour une équipe produit : une issue bien rédigée devient une pull request à relire, au lieu d'attendre dans le backlog. La qualité de l'issue détermine la qualité de la pull request.
Automatiser la revue de pull request
Avec une entrée prompt, l'action passe en mode automatisation : elle s'exécute sans attendre de mention, sur n'importe quel événement GitHub (ouverture de pull request, planification cron). La documentation fournit un exemple de revue : un workflow déclenché à l'ouverture, à la mise à jour, à la réouverture ou au passage en "prêt pour revue" d'une pull request, qui poste ses retours en commentaires en ligne. Les brouillons, les pull requests fermées et celles qui ont déjà un commentaire de Claude sont ignorés.
Anthropic propose aussi un produit distinct, Code Review, qui lance une revue automatique sans fichier de workflow à maintenir. Le workflow maison garde l'avantage du contrôle : vous choisissez le prompt, le modèle et les déclencheurs.
Ce que la revue automatique ne remplace pas
Une revue par agent est un premier filtre : elle repère les oublis, les incohérences et les cas limites avant qu'un humain y passe du temps. Elle ne décide pas de la fusion. Pour l'organisation de la relecture côté équipe, voir notre article sur le déploiement de Claude Code dans une équipe de développement.
Coût d'un workflow
Chaque exécution consomme des minutes GitHub Actions (runners hébergés par GitHub) et des tokens d'API, selon la taille des prompts, la complexité de la tâche et celle du dépôt. Avec un jeton OAuth, l'usage est imputé à l'abonnement plutôt qu'à la facturation API. Pour limiter la dépense, la documentation recommande de fixer --max-turns, des délais maximum par job et des contrôles de concurrence, et de garder un fichier CLAUDE.md concis puisqu'il est relu à chaque exécution.
3. Claude Code MCP : brancher vos outils et vos données
Ce qu'est un serveur MCP, en deux lignes
MCP (Model Context Protocol) est un protocole ouvert qui permet à un agent d'appeler des outils externes de façon standardisée. Chaque serveur expose des outils : lire une issue, interroger une base, créer un ticket. Pour la définition complète et les enjeux, voir l'article de ianas.fr sur le Model Context Protocol. Côté décideur, notre article sur l'agent IA connecté à un logiciel par API ou MCP compare les approches d'intégration.
Ajouter un serveur avec claude mcp add
La commande prend un nom, un transport et une adresse ou une commande. Les transports documentés sont http (serveurs distants, recommandé), stdio (processus local) et WebSocket ; le transport SSE est déprécié. Exemple de la documentation pour GitHub, avec un jeton d'accès personnel (PAT) :
claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
--header "Authorization: Bearer VOTRE_PAT_GITHUB"Ensuite, on parle à l'agent normalement : "Relis la pull request 456 et propose des améliorations", ou "Crée une issue pour le bug qu'on vient de trouver". Pour les serveurs qui utilisent OAuth, la connexion se fait avec la commande /mcp dans une session.
Portées : local, projet ou utilisateur
| Portée | Stockage | Partagé avec l'équipe |
|---|---|---|
| Local (par défaut) | ~/.claude.json | Non, ce projet seulement |
| Projet | .mcp.json à la racine du dépôt | Oui, via git |
| Utilisateur | ~/.claude.json | Non, tous vos projets |
Pour une équipe, la portée projet est la plus intéressante : le fichier .mcp.json est versionné, donc la liste des serveurs autorisés suit le dépôt et se relit en pull request comme le reste. En session interactive, Claude Code demande une approbation avant d'utiliser un serveur de portée projet. Le fichier accepte des variables d'environnement (${API_KEY}) pour ne jamais commiter de secret. Les organisations peuvent aussi distribuer des serveurs via les paramètres managés.
Quels serveurs MCP pour une équipe de développement
- Gestion de tickets : lire une demande, mettre à jour un statut, relier une pull request à son ticket.
- Base de données : interroger un schéma ou des données de test, en lecture seule de préférence.
- Supervision et erreurs : relire une alerte ou une trace avant de proposer un correctif.
- Outil interne : un petit serveur MCP maison devant une API métier (catalogue, facturation, support), pour que l'agent travaille sur vos vraies données plutôt que sur des hypothèses.
4. Sécurité et permissions : ce qu'on décide avant d'ouvrir
Allow, ask, deny : les règles de permission
Claude Code évalue chaque action selon des règles deny, ask, puis allow : la première règle qui correspond, dans cet ordre, décide. Une règle de refus large l'emporte donc toujours sur une autorisation plus précise. Les règles se déclarent dans .claude/settings.json (partagé via git) ou .claude/settings.local.json (personnel), et peuvent être imposées par des paramètres managés.
Pour GitHub et MCP, les exemples utiles tirés de la documentation :
Bash(git push *)en deny : aucun push direct, tout passe par une pull request.mcp__github__get_*en allow : les outils de lecture du serveur GitHub s'exécutent sans validation à chaque appel.mcp__*en deny : coupe tous les outils MCP, utile sur un dépôt sensible.Read(./.env)en deny : l'agent ne lit pas vos fichiers de secrets.
Une limite à connaître : une règle Bash en deny couvre la forme habituelle de la commande, pas toutes ses variantes. La documentation précise que ce n'est pas une frontière de sécurité, et recommande d'activer le sandbox quand la restriction doit être garantie au niveau du système.
Les risques propres aux workflows GitHub
Dans un workflow, l'agent s'exécute sans humain devant l'écran. Quatre garde-fous documentés :
- Qui peut déclencher : l'action exige un accès en écriture au dépôt et refuse les robots, sauf liste explicite (
allowed_bots). - Permissions du workflow : n'accorder que le nécessaire. Une revue de code se contente de
contents: readetpull-requests: read. - Secrets : jamais de clé dans le dépôt, uniquement des secrets GitHub, ou une fédération d'identité OIDC pour n'en stocker aucun.
- Pull requests de forks : sur un dépôt public, GitHub retient les secrets pour les forks, la revue ne tourne que sur les branches du dépôt.
Un point souvent découvert tard : l'application GitHub de Claude demande en bloc un jeu de permissions (contenu, issues, pull requests, workflows, etc.) que GitHub n'autorise pas à accepter partiellement. Si votre organisation exige le strict nécessaire, la documentation prévoit la création d'une application GitHub personnalisée limitée à Contents, Issues et Pull requests.
Injection de prompt et serveurs tiers
Un serveur MCP qui récupère du contenu externe (pages web, tickets rédigés par des tiers, commentaires publics) peut transporter des instructions malveillantes jusqu'à l'agent. La documentation d'Anthropic demande de vérifier la confiance accordée à chaque serveur avant de l'ajouter. Règle pratique : plus un serveur lit de contenu écrit par des inconnus, plus ses outils d'écriture doivent rester en ask.
Pour la question de ce qui quitte votre poste et ce qui reste, notre article sécurité des données avec Claude Code en entreprise détaille le périmètre.
5. Cas d'usage pour une équipe de développement ou un éditeur SaaS
| Cas d'usage | Brique | Point de contrôle humain |
|---|---|---|
| Pré-revue de chaque pull request | GitHub Action (mode automatisation) | Le relecteur reste décisionnaire |
| Correctif de bug mineur depuis une issue | GitHub Action (@claude) | Revue et fusion de la PR |
| Tri et rédaction d'issues à partir de retours clients | Serveur MCP GitHub ou de tickets | Validation avant publication |
| Rapport quotidien des commits et issues ouvertes | GitHub Action planifiée | Lecture par le lead tech |
| Assistance sur une API métier propre à l'éditeur | Serveur MCP interne | Outils en lecture seule au départ |
Pour un éditeur SaaS, le serveur MCP interne est le cas le plus structurant : exposer proprement son API, ses données de test et sa documentation à un agent, de façon contrôlée. C'est un petit chantier de développement, avec ses choix d'authentification, de périmètre et de journalisation. Quand il dépasse l'expérimentation, il rejoint nos projets de développement SaaS avec IA.
6. Par où commencer, en pratique
Une séquence qui limite les risques, en quatre étapes :
- Un dépôt pilote, non critique, avec un fichier
CLAUDE.mdqui décrit les conventions. - Permissions d'abord : règles deny et ask dans
.claude/settings.json, versionnées. - Lecture avant écriture : un serveur MCP GitHub en lecture, une revue automatique qui commente sans pouvoir pousser.
- Écriture ensuite : mentions @claude pour des correctifs, toujours via pull request relue.
Si l'équipe veut monter en compétence sur ces sujets en situation réelle, notre formation Claude Code couvre la configuration, les permissions et les intégrations sur vos propres dépôts.
