Intégration GitHub

Jusqu’ici, Claude Code a vécu dans votre terminal, sur votre machine, sous votre regard. L’intégration officielle avec GitHub déplace le même assistant là où votre équipe discute réellement du code : les issues et les pull requests. Claude ne tourne plus alors sur votre poste mais dans GitHub Actions, déclenché par les événements du dépôt et non par vos frappes au clavier. De ce déplacement naissent deux workflows : le support des mentions sur les issues et les pull requests, et les revues automatiques de PR.

Mise en place

Tout part d’une seule commande, /install-github-app, que vous lancez depuis Claude. Elle vous guide à travers le processus au lieu de vous laisser assembler les pièces vous-même :

Installer l’application Claude Code sur GitHub
Ajouter votre clé API
Générer automatiquement une pull request avec les fichiers de workflow

Le troisième point mérite qu’on s’y arrête. Vous ne récupérez pas une documentation à recopier : Claude ouvre une pull request contenant les fichiers de workflow prêts à l’emploi. Vous la relisez comme n’importe quelle contribution d’un collègue, vous la fusionnez, et l’intégration est active. C’est également le premier endroit où vous reviendrez le jour où il faudra ajuster la configuration.

Les deux workflows par défaut

Le premier workflow répond aux mentions. Vous écrivez @claude dans une issue ou dans un commentaire de PR, exactement comme vous interpelleriez un coéquipier, et vous décrivez ce que vous attendez. Claude analyse la demande, se construit un plan de tâches, exécute ce plan, puis répond directement dans le fil de discussion. Un rapport de bug déposé le matin peut ainsi repartir l’après-midi avec un diagnostic et une proposition de correction, sans que personne ait ouvert son éditeur.

Le second workflow n’attend aucune interpellation : il se déclenche à la création de chaque pull request. Claude passe en revue les changements proposés, analyse leur impact sur le reste du projet et publie un rapport détaillé en commentaire. Le relecteur humain arrive donc sur une PR déjà annotée, les points sensibles remontés à la surface, ce qui change la nature même de sa lecture.

Personnaliser les workflows

Les workflows livrés par défaut ne connaissent rien de votre projet. Ils ignorent comment l’installer, sur quel port il tourne, où il écrit ses journaux. C’est exactement ce vide que la personnalisation vient combler, à trois endroits complémentaires du fichier de workflow.

La configuration du projet indique comment amener le dépôt dans un état exploitable avant que Claude ne commence à travailler :

- name: Project Setup
  run: |
    npm run setup
    npm run dev:daemon

Les instructions personnalisées tiennent le rôle que joue CLAUDE.md en local : elles évitent à Claude de redécouvrir à chaque exécution ce que vous savez déjà.

custom_instructions: |
  Le projet est deja configure avec toutes les dependances.
  Le serveur tourne sur localhost:3000.
  Les logs sont ecrits dans logs.txt.

La configuration des serveurs MCP, enfin, donne à Claude les mêmes capacités étendues que sur votre poste. Dans l’exemple ci-dessous, Playwright lui permet de piloter un navigateur contre le serveur local que l’étape de setup vient précisément de démarrer — les trois blocs se répondent, et c’est leur cohérence qui fait qu’un workflow tient debout :

mcp_config: |
  {
    "mcpServers": {
      "playwright": {
        "command": "npx",
        "args": ["@playwright/mcp@latest",
                 "--allowed-origins", "localhost:3000"]
      }
    }
  }

Permissions des outils

C’est ici que l’expérience s’écarte le plus du développement local. Dans GitHub Actions, vous devez lister explicitement tous les outils autorisés :

allowed_tools: "Bash(npm:*),Bash(sqlite3:*),mcp__playwright__browser_snapshot,..."

Contrairement au développement local, chaque outil de chaque serveur MCP doit être listé individuellement. Aucune boîte de dialogue ne viendra vous demander une autorisation en cours de route, pour la raison évidente que personne ne surveille l’exécution. Un outil oublié dans cette liste se traduit donc par une tâche qui s’interrompt en plein milieu, et c’est presque toujours la première explication quand un workflow personnalisé refuse de fonctionner.

La méthode la plus sûre consiste à partir des workflows par défaut et à les personnaliser progressivement, en éprouvant chaque évolution sur une tâche simple avant de confier à Claude un travail complexe. Vous saurez ainsi lequel de vos ajouts a cassé quoi, au lieu de démêler cinq changements simultanés dans les journaux d’une action. L’intégration GitHub fait de Claude un membre automatisé de votre équipe, mais un membre qui a besoin, comme les autres, qu’on lui explique le projet et qu’on lui donne les bons accès.