Connecteur GitHub
Sur cette page
Mise à jour du 2 novembre 2026 — Le Chat devient Vibe. Depuis le 28 mai 2026, Le Chat s’appelle Vibe (toujours sur chat.mistral.ai) : un seul agent pour le travail et le code, avec vos conversations, réglages et abonnements repris. L’ancienne expérience Le Chat reste accessible dans le mode Chat ; dans le mode Work, les agents sont devenus des skills (invoquées avec
@), les mémoires la base de connaissances et la recherche approfondie la skill Deep Research. Les offres s’appellent désormais Mistral Free, Pro, Team et Enterprise. Cette leçon emploie désormais le nom Vibe ; certains menus décrits ici ont pu changer de nom ou de place.
GitHub directement depuis Vibe
GitHub est l’une des intégrations MCP les plus puissantes du répertoire du Chat. Elle donne accès à vos repositories, issues, pull requests et branches sans quitter la conversation. Pour une équipe de développement, l’économie n’est pas anecdotique : les tâches courantes — trier des issues, ouvrir une PR, vérifier un fichier sur une branche — cessent d’imposer un aller-retour vers l’interface web ou un rappel de la bonne commande Git.
Connexion et authentification
Le connecteur s’authentifie par Personal Access Token (PAT). La configuration se déroule en quatre temps :
- Rendez-vous sur GitHub dans Settings > Developer settings > Personal access tokens
- Créez un nouveau token en sélectionnant les scopes nécessaires (repositories, issues, pull requests, etc.)
- Dans Vibe, ouvrez l’onglet Connectors et sélectionnez GitHub
- Collez votre token et validez
Le token est stocké de manière sécurisée et rattaché à votre seul compte utilisateur. Si vous appartenez à une organisation sur Vibe, vos collègues ne le voient pas et ne peuvent pas s’en servir : chacun se connecte avec ses propres identifiants, et le périmètre visible par Vibe est exactement celui de la personne connectée.
Le choix des scopes mérite quelques secondes de réflexion. Voici les principaux :
- repo : accès complet aux repositories (lecture, écriture, création de branches et PRs)
- read:org : lecture des informations d’organisation
- write:discussion : participation aux discussions
- admin:repo_hook : gestion des webhooks (rarement nécessaire)
Appliquez le principe de moindre privilège : commencez avec des droits limités, quitte à régénérer un token plus large le jour où un usage précis le justifie. Un PAT repo complet donné pour simplement consulter des issues est un risque gratuit.
Ce que le connecteur sait faire
Une fois branché, Vibe couvre quatre domaines. Sur la consultation d’abord, il liste vos repositories et leurs branches, affiche le contenu d’un fichier donné, parcourt l’historique des commits et vérifie le statut des checks CI/CD. Sur les issues, il liste celles qui sont ouvertes, en crée avec titre, description et labels, commente les existantes et modifie leur statut.
Le travail sur les pull requests suit la même logique : lister les PR ouvertes, en créer une depuis une branche, consulter les diffs et les commentaires de review, puis fusionner. Enfin, sur le code lui-même, Vibe crée une branche à partir d’une autre, crée ou modifie un fichier sur une branche précise et y pousse les changements. C’est cette dernière catégorie qui demande le plus de vigilance, puisqu’elle écrit dans le repository.
Trois situations concrètes
Prenons une matinée ordinaire. Vous voulez faire le point sur les tâches en attente :
“Montre-moi les issues ouvertes sur le repo company/backend qui ont le label ‘bug’ et sont assignées à personne.”
Vibe appelle le connecteur, applique les filtres et vous présente une liste synthétisée. Vous enchaînez dans la même conversation pour assigner, labelliser ou commenter, sans jamais ouvrir GitHub.
Deuxième situation, vous venez d’identifier un manque dans la documentation et vous dictez le travail :
“Crée un fichier docs/guide-migration.md sur la branche docs/migration du repo company/documentation avec un guide expliquant comment migrer de la v2 à la v3.”
Le fichier est créé sur la branche indiquée, et vous demandez dans la foulée l’ouverture de la pull request associée. Troisième situation, vous préparez une revue de code et souhaitez une vue d’ensemble avant d’entrer dans le détail :
“Quelles sont les pull requests ouvertes sur company/frontend ? Donne-moi un résumé des changements pour chacune.”
Vibe liste les PR, lit les diffs et produit un résumé structuré qui vous indique où concentrer votre attention.
Deux réflexes à installer
Le premier concerne l’activation. Le connecteur GitHub expose beaucoup d’outils ; dans une conversation qui ne parle pas de code, désactivez-le. Vous constaterez que le modèle sélectionne plus sûrement l’outil pertinent lorsque sa liste est courte — c’est le même principe que pour n’importe quel système d’agents.
Le second concerne les écritures. À chaque fois que Vibe propose de créer un fichier, une branche ou une pull request, l’interface affiche les arguments JSON avant exécution. Lisez-les. Vérifiez en particulier le nom de la branche cible, car une confusion entre main et une branche de travail se paie cher ; contrôlez ensuite le contenu du fichier créé ou modifié, puis le titre et la description de la PR.
Le connecteur au sein d’un workflow
GitHub prend toute sa dimension combiné à d’autres connecteurs MCP. Un enchaînement type consiste à scanner un outil de support pour repérer un bug remonté par un utilisateur, vérifier sur GitHub si un ticket existe déjà, créer l’issue si ce n’est pas le cas, puis créer une branche, pousser un correctif et ouvrir la pull request. L’ensemble se pilote depuis Vibe, chaque écriture restant soumise à votre validation.
Points clés à retenir
- Le connecteur GitHub utilise un Personal Access Token avec des scopes configurables
- Vous pouvez consulter, créer et modifier des repositories, issues et pull requests
- Chaque action d’écriture nécessite votre approbation explicite dans l’interface
- Désactivez le connecteur quand vous ne l’utilisez pas pour améliorer la précision du modèle
- La combinaison avec d’autres connecteurs MCP crée des workflows automatisés puissants