Copilot CLI : le guide pour travailler dans le terminal

Comment installer GitHub Copilot CLI et se connecter ?

Installez le paquet npm stable de GitHub, @github/copilot, avec Node.js 22 ou une version ultérieure. Sous Windows, GitHub exige également PowerShell v6 ou une version ultérieure. Si votre organisation vous fournit Copilot, son administrateur doit activer la politique d’accès à Copilot CLI. Prérequis d’installation.

Exécutez cette commande dans le terminal :

npm install -g @github/copilot

Si votre fichier ~/.npmrc contient ignore-scripts=true, GitHub propose cette variante : npm_config_ignore_scripts=false npm install -g @github/copilot. La documentation présente aussi winget install GitHub.Copilot sous Windows, brew install --cask copilot-cli sous macOS ou Linux, et curl -fsSL https://gh.io/copilot-install | bash sous macOS ou Linux. Le prérequis Node concerne l’installation par npm. Commandes d’installation de GitHub.

Placez-vous dans le dépôt sur lequel vous souhaitez travailler, puis lancez copilot. Confirmez que vous faites confiance à ce dossier, pour la session en cours ou pour les suivantes. Si vous n’êtes pas connecté, saisissez /login dans Copilot lorsque l’invite le demande. Premier lancement.

Sélectionnez GitHub.com, ou le nom d’hôte GitHub Enterprise Cloud associé à la résidence de vos données. Sur un ordinateur local avec interface graphique, choisissez la connexion par navigateur ; dans un environnement distant ou sans interface graphique, le parcours par code d’appareil est généralement proposé en premier. Terminez l’autorisation dans le navigateur, autorisez les organisations concernées si elles utilisent SAML SSO, puis approuvez l’application GitHub Copilot CLI. Revenez au terminal une fois la connexion terminée. Vous pouvez aussi lancer l’authentification depuis le shell avec copilot login. Procédure d’authentification.

Si la CLI utilise le mauvais compte, vérifiez les variables COPILOT_GITHUB_TOKEN, GH_TOKEN et GITHUB_TOKEN déjà définies : les jetons explicitement exportés prennent le pas sur la connexion enregistrée. Pour l’automatisation, GitHub accepte un jeton à permissions fines rattaché à un compte personnel, avec la permission de compte Copilot Requests. Les jetons d’accès personnels classiques ne sont pas pris en charge. Authentification et priorité des jetons.

Premiers usages : comprendre le dépôt, corriger un test, ouvrir une PR

Commencez par une question, poursuivez avec une modification vérifiable, puis ouvrez une pull request. Voyez la CLI comme un développeur à vos côtés : elle peut explorer le projet et utiliser des outils, tandis que vous décidez des actions autorisées.

Le tableau distingue les commandes à exécuter dans le shell des saisies dans une session interactive copilot. Chaque commande ou prompt ci-dessous figure dans la documentation de GitHub. Toute interaction avec un modèle consomme des crédits IA ; GitHub ne publie pas de coût fixe en crédits pour ces tâches. Facturation de la CLI.

Comprendre le dépôt avant de le modifier

Pour prendre en main un projet inconnu, un développeur peut commencer par la commande d’explication du tableau. L’exemple de GitHub utilise Claude Haiku 4.5 : -p envoie un seul prompt puis termine l’exécution, -s masque les sorties supplémentaires et --model sélectionne le modèle. Si votre abonnement ou les politiques de votre organisation n’autorisent pas ce modèle, ouvrez une session interactive et utilisez /model pour choisir parmi les options disponibles. Les comptes Free et Student utilisent la sélection Auto. Exemple d’utilisation en mode programmatique, accès aux modèles.

Servez-vous de l’explication pour repérer les points d’entrée et la configuration des tests, puis vérifiez vous-même les fichiers concernés. Vous obtenez ainsi une carte de départ concrète, que vous pouvez interroger, plutôt qu’une nouvelle exploration des dossiers sans fil conducteur.

Corriger un test en échec avec un résultat vérifiable

Face à un test qui échoue, un mainteneur peut lancer la véritable commande de test du dépôt, transmettre la sortie d’erreur à Copilot, puis utiliser le prompt interactif du tableau. GitHub propose cette formulation dans son workflow de développement piloté par les tests, après la création et la vérification de tests en échec. Pour une erreur déjà présente, fournissez le même contexte : quel test échoue et quel comportement doit être préservé. Examinez le diff et relancez le test concerné avant d’accepter la modification. Workflow de test de GitHub.

Pour un test qui échoue déjà en CI, c’est-à-dire dans les vérifications automatisées associées à une pull request existante, GitHub propose /pr fix ci focus on test failures. Cette commande analyse les journaux, applique des corrections et peut pousser des modifications. Elle relève donc d’un autre workflow que la correction d’un test local. Une PR doit déjà exister pour la branche courante. Correction des échecs de CI.

Ouvrir une pull request après avoir vérifié la modification

Pour livrer un petit correctif, un fondateur peut utiliser /pr create depuis sa branche de travail, après avoir examiné la modification et créé le commit. Le dépôt Git doit être hébergé sur GitHub. Copilot pousse les commits locaux et crée la PR en suivant le modèle de pull request du dépôt pour le titre et la description. Si la branche possède déjà une PR, la commande la met à jour. Création d’une pull request.

Vous transmettez ainsi un travail prêt à être relu dans le workflow GitHub de l’équipe. Vous restez responsable du contenu de la branche.

Quelles autorisations Copilot demande-t-il avant d’exécuter des commandes ?

La confiance accordée au dossier et l’autorisation d’utiliser un outil sont deux décisions distinctes. Lorsqu’une action exige votre accord, vous pouvez l’autoriser une fois, autoriser l’outil pour la session en cours, ou refuser en donnant des indications. L’autorisation de session couvre l’outil et ses options. Demandes d’autorisation.

Les opérations en lecture seule peuvent s’exécuter automatiquement. Les actions potentiellement destructrices, les écritures et l’accès aux URL demandent une autorisation, sauf si elle a déjà été accordée. Certaines invites permettent d’enregistrer une autorisation pour le dépôt ou le dossier. Les domaines d’URL autorisés de façon permanente le restent d’une session à l’autre. Autorisations enregistrées.

GitHub donne cet exemple de permissions préconfigurées :

copilot --allow-tool='shell(git:*)' --deny-tool='shell(git push)'

Cette configuration autorise les commandes Git, mais interdit les push. Les règles d’interdiction priment sur les règles d’autorisation et sur les accords enregistrés. /reset-allowed-tools efface les autorisations de session et les autorisations d’outils enregistrées pour l’emplacement courant, puis rétablit les permissions définies au lancement. Règles d’autorisation et d’interdiction.

--allow-all-tools autorise tous les outils disponibles. --allow-all ou --yolo autorise également tous les chemins et toutes les URL. GitHub recommande de réserver ces autorisations étendues à un environnement isolé. Pour vos premières tâches, gardez le parcours habituel de demandes d’autorisation. Options de permissions étendues.

GitHub Copilot : quels prix, quels crédits et quel accès à la CLI ?

Tous les abonnements Copilot incluent la CLI : Free, Student, Pro, Pro+, Max, Business et Enterprise. Aucun abonnement CLI distinct n’est à ajouter à votre licence Copilot actuelle. Voici les tarifs mensuels et les crédits actuellement indiqués sur la page des offres de GitHub. Abonnements Copilot.

La dotation flex est variable : les totaux actuels ne garantissent donc pas une capacité permanente. Un crédit IA équivaut à $0.01 USD. La consommation dépend des tarifs du modèle choisi et des tokens d’entrée, de sortie et mis en cache. Le chat et la CLI puisent dans la même enveloppe. Avec un abonnement payant, les complétions de code et les suggestions de modification suivante restent illimitées et ne consomment pas de crédits IA. Facturation des comptes individuels.

Pour un abonné Pro, le tarif reste de $10 par mois ; le travail des modèles dans le terminal utilise une part de l’enveloppe actuelle de 1,500 crédits. C’est le calcul utile : essayez l’accès dont vous disposez déjà, puis voyez si les crédits partagés suffisent à votre activité. Les abonnés individuels payants peuvent prévoir un budget pour une consommation supplémentaire, changer d’offre ou attendre le renouvellement mensuel des crédits. Le tableau public des tarifs ne propose pas l’achat de crédits supplémentaires avec Free. Enveloppes individuelles, limites d’achat de l’offre Free.

Les crédits Business et Enterprise sont mutualisés au niveau de l’entité de facturation. La consommation payante supplémentaire est activée par défaut ; les administrateurs peuvent la désactiver. Un budget utilisateur ou un plafond de dépenses de l’entreprise peut bloquer l’accès, même s’il reste des crédits dans une autre enveloppe. GitHub recommande la CLI 1.0.48 ou une version ultérieure pour afficher correctement la facturation et la consommation. Facturation des organisations.

Après une tâche, consultez /usage pour connaître les crédits de la session et les tokens consommés par les modèles. Dans une session interactive, vous pouvez définir /limits set max-ai-credits NUMBER en remplaçant NUMBER par l’enveloppe souhaitée. Le minimum est de 30 crédits. Cette fonctionnalité est en préversion publique et applique un plafond souple : une réponse déjà en cours se termine et peut légèrement dépasser la limite. Affichage de la consommation, limites de session.

Quels modèles peut-on utiliser avec Copilot CLI ?

Utilisez /model dans Copilot pour afficher les options disponibles, ou --model lors d’un lancement depuis le shell. Le tableau actuel des clients de GitHub indique que les modèles suivants sont pris en charge par la CLI ; votre abonnement et les politiques de votre administrateur peuvent en restreindre l’accès. Modèles pris en charge.

Le tableau distinct consacré au mode Auto de la CLI inclut aussi GPT-6.1 Sol. Free et Student utilisent exclusivement Auto. La disponibilité évolue : consultez le sélecteur pour voir les options actuellement accessibles à votre compte. Mode Auto et disponibilité par abonnement.

Ajouter les consignes du projet et des outils MCP

Rédigez les règles de travail du dépôt avant de demander des modifications récurrentes. Les instructions personnalisées sont des fichiers Markdown que Copilot intègre à son contexte. Placez les commandes de build, les commandes de test et les conventions communes au projet dans .github/copilot-instructions.md. Pour les règles propres à certains chemins, utilisez .github/instructions/**/*.instructions.md avec des motifs applyTo. Instructions personnalisées.

La CLI détecte aussi AGENTS.md, CLAUDE.md, .claude/CLAUDE.md et GEMINI.md. Les préférences personnelles applicables à tous vos projets peuvent être placées dans ~/.copilot/copilot-instructions.md ou ~/.copilot/instructions/**/*.instructions.md. Les instructions applicables se combinent ; GitHub ne définit pas d’ordre général de priorité entre elles. Veillez à leur cohérence et utilisez /instructions pour examiner ou désactiver les fichiers détectés. Détection et combinaison des instructions.

MCP, Model Context Protocol, relie un agent à des outils et des données externes. C’est une façon de connecter un service à votre environnement de travail. Le serveur MCP GitHub est déjà intégré. Pour ajouter un autre serveur, utilisez /mcp add, passez d’un champ à l’autre avec Tab et enregistrez avec Ctrl+S. Les serveurs locaux ou stdio lancent un processus ; les serveurs HTTP se connectent à un point de terminaison distant. L’ancien transport SSE reste également pris en charge. Ajout de serveurs MCP.

L’exemple de GitHub dans le terminal est copilot mcp add --transport http sentry https://mcp.sentry.dev/mcp. La configuration utilisateur se trouve dans ~/.copilot/mcp-config.json ; celle du projet peut utiliser .mcp.json ou .github/mcp.json. Le guide MCP précise que les politiques configurées de registre et de liste d’autorisation de l’organisation s’appliquent à la CLI. Exemple dans le terminal, configuration et politiques.

Quand choisir la CLI, l’IDE ou un autre agent ?

Mon conseil : commencez par Copilot CLI si votre tâche se déroule déjà dans le terminal et que vous disposez d’une licence Copilot. Choisissez l’extension IDE si vous préférez travailler à côté du fichier que vous modifiez, examiner visuellement les changements et rester dans votre éditeur. Notre comparatif Cursor et GitHub Copilot aide à faire ce choix.

Au-delà des premières tâches, voici des usages possibles :

• Un mainteneur qui prépare une revue peut demander une revue de code de sa branche de travail, examiner les points soulevés, puis transmettre le diff à un relecteur humain. Il obtient une liste de vérifications ciblée, à condition que les constats résistent à l’examen. GitHub documente les workflows de revue locale. Conseils pour la revue de code.
• Un développeur qui répond aux retours sur une PR peut utiliser /pr fix feedback, examiner les modifications proposées et autoriser les push qui en découlent. Les changements demandés restent ainsi liés à la discussion. La commande peut répondre aux fils de revue traités et les marquer comme résolus : vérifiez donc sa portée avant de l’autoriser. Traitement des retours de revue.

Envisagez un autre agent de terminal si vous avez besoin d’une enveloppe d’abonnement différente, d’un autre mode d’accès aux fournisseurs ou de davantage de contrôle sur l’agent lui-même. Notre comparatif des alternatives à Claude Code et de leurs coûts dans le terminal vous aide à prendre cette décision d’achat. Vérifiez d’abord si les modèles proposés par Copilot répondent à votre besoin : GitHub documente aussi l’utilisation de votre propre fournisseur, y compris avec des modèles locaux compatibles. Cette voie demande une configuration distincte du fournisseur et la prise en charge des appels d’outils et du streaming ; elle diffère de l’utilisation de votre enveloppe Copilot. Utiliser son propre modèle.

Quelles offres une petite équipe pourrait-elle créer autour de la CLI ?

Un kit de prise en main du dépôt est la piste la plus solide pour commencer. Les développeurs effectuent des recherches comme “how to understand a new codebase” et “ai tool to understand codebase.” Une équipe pourrait vendre aux responsables techniques un ensemble maintenu de notes d’architecture, de consignes de build vérifiées et de tâches de prise en main bien délimitées. La version minimale utile couvrirait le dépôt du client et montrerait le parcours d’explication, de test et de PR. La difficulté : les prompts génériques se copient facilement ; c’est la connaissance du projet, tenue à jour, qui justifierait l’achat.

Un workflow de préparation des revues est une autre piste. Les recherches “ai code review tools” et “ai powered code review platform” indiquent le besoin. Une équipe pourrait réunir les instructions du projet et le contexte des tickets connectés pour produire un dossier de revue comprenant les modifications, les éléments de validation des tests et les questions non résolues. L’acheteur serait un responsable d’équipe qui souhaite harmoniser la transmission du travail. La difficulté : les constats générés doivent être validés, et le workflow doit prouver son utilité aux côtés des fonctions de revue déjà présentes dans GitHub. Ce sont des pistes de produits, pas des résultats démontrés.

Quelles limites faut-il prévoir ?

La CLI peut proposer une modification convaincante, mais incorrecte. Le guide d’utilisation responsable de GitHub précise que les réponses générées peuvent être inexactes ou incomplètes et demande aux utilisateurs de vérifier le code et les commandes de la CLI. La réussite des tests concernés et l’examen du diff restent nécessaires. Utilisation responsable.

La confiance accordée à un dossier ne garantit pas l’isolation. GitHub décrit la délimitation des permissions de répertoire comme heuristique et ne garantit pas la protection de tous les fichiers situés hors des dossiers de confiance. Démarrez dans le dépôt sur lequel vous voulez travailler. Pour renforcer les restrictions, /sandbox enable active l’exécution locale des outils dans un environnement isolé ; les environnements isolés locaux et cloud de GitHub sont en préversion publique. Confiance dans les dossiers et isolation.

Les limites d’accès et de dépenses continuent de s’appliquer. Un modèle mentionné dans la documentation peut ne pas être accessible avec votre abonnement ou être désactivé par une politique. La CLI partage les crédits avec les autres usages de Copilot, et le plafond de session en préversion peut être légèrement dépassé. Les budgets de l’organisation peuvent interrompre l’utilisation sans bascule automatique vers un modèle moins cher. Accès aux modèles, plafonds de session, fonctionnement des budgets.

Lors de votre prochaine session, choisissez un véritable test en échec sur une branche dont vous pourrez examiner les changements. Faites expliquer le code concerné, autorisez les outils nécessaires à la correction, relancez le test, consultez /usage, puis ouvrez la PR. Vous aurez ainsi des éléments concrets pour juger si le workflow vous convient et si sa consommation est adaptée.

Pour un workflow de dépôt conçu autour des vérifications de votre équipe et de ses outils connectés, nous développons des automatisations IA.