Utiliser GitHub Copilot CLI : le guide pas à pas

Pour utiliser GitHub Copilot CLI, installez-le (npm install -g @github/copilot, Homebrew, WinGet ou le script d’installation), lancez copilot dans un dossier de projet, confirmez que vous faites confiance au dossier, connectez-vous avec /login et décrivez la tâche en langage courant. Copilot lit votre code, propose des modifications et des commandes, et demande avant d’exécuter quoi que ce soit.

Voilà la boucle de base. Ce guide couvre ce dont vous aurez besoin après la première session : l’offre nécessaire, l’usage interactif et programmatique, les permissions des outils, les commandes slash utiles, les modèles, les serveurs MCP et les instructions personnalisées. Tout ce qui suit s’appuie sur la documentation officielle de GitHub sur docs.github.com, telle qu’elle était en octobre 2026. Si vous hésitez encore entre plusieurs agents, Copilot CLI vs Claude Code compare les deux en détail ; cet article est le mode d’emploi.

Ce qu’est Copilot CLI

Copilot CLI est l’agent de code de GitHub pour le terminal. Il travaille sur le dossier depuis lequel vous le lancez : il peut lire et modifier des fichiers, exécuter des commandes shell et dialoguer avec GitHub grâce à un serveur MCP GitHub intégré, ce qui lui permet aussi de consulter les issues et les pull requests. Il fonctionne sous Linux, macOS et Windows (PowerShell et WSL).

Étape 1 : vérifier votre offre

En octobre 2026, la page des offres de GitHub indique que toutes les offres Copilot incluent Copilot CLI. L’usage est décompté en GitHub AI Credits, et la vitesse à laquelle vous les consommez dépend du modèle et de la quantité de travail.

Si votre Copilot vient d’une organisation, un administrateur peut désactiver le CLI : vérifiez ce point en premier s’il refuse de démarrer. L’article comparatif détaille davantage les crédits et les prix.

Étape 2 : installer Copilot CLI

Sous Windows, il vous faut PowerShell 6 ou plus récent. Si votre configuration npm définit ignore-scripts, installez avec npm_config_ignore_scripts=false npm install -g @github/copilot. Dans une session, /update met le CLI à jour.

Étape 3 : le lancer et se connecter

cd ~/code/my-project
copilot

La première fois que vous lancez Copilot dans un dossier, il vous demande si vous faites confiance aux fichiers qu’il contient. Vous pouvez lui faire confiance pour cette session, lui faire confiance et mémoriser ce choix, ou refuser. Les dossiers de confiance sont ceux où Copilot peut lire, modifier et exécuter des choses : lancez-le donc dans le dossier du projet, pas dans votre dossier personnel.

Si vous n’êtes pas connecté, tapez /login et suivez la procédure dans le navigateur. Depuis un shell normal, copilot login fait la même chose, avec --device-code pour les machines sans navigateur. Pour l’automatisation, Copilot lit un token dans COPILOT_GITHUB_TOKEN, puis GH_TOKEN, puis GITHUB_TOKEN ; un personal access token fine-grained doit avoir la permission « Copilot Requests ». /user affiche ou change le compte connecté et /logout vous déconnecte.

Étape 4 : travailler en mode interactif

Tapez ce que vous voulez :

Trouve où nous validons les adresses e-mail, ajoute un test pour les
adresses contenant un signe plus, et lance la suite de tests.

Quelques astuces de saisie :

• @path/to/file insère un fichier dans le prompt.
• !command exécute directement une commande shell, sans l’envoyer au modèle.
• Shift+Tab fait défiler les modes. En mode plan, Copilot pose des questions de clarification et construit un plan avant d’écrire du code. /plan fait la même chose depuis le prompt.
• /autopilot laisse Copilot continuer seul jusqu’à ce que la tâche soit terminée, et /ask (ou /btw) pose une question annexe sans faire dérailler la tâche.

Pour tout ce qui touche plus de deux ou trois fichiers, planifiez d’abord :

/plan Découpe l’OrderService de 900 lignes en services plus petits. Garde
la même API publique et liste tous les fichiers que tu vas modifier.

Étape 5 : approbations et permissions des outils

Quand Copilot veut lancer un outil qui peut changer quelque chose (une commande shell, une écriture de fichier, le téléchargement d’une URL), il demande. Vous pouvez approuver une fois, approuver cet outil pour le reste de la session, ou refuser et lui dire quoi faire à la place.

Pour décider à l’avance, utilisez des motifs de permission de la forme Kind(argument) :

# git is fine, pushing is not
copilot --allow-tool='shell(git:*)' --deny-tool='shell(git push)'

# allow everything except deleting files and pushing
copilot --allow-all-tools --deny-tool='shell(rm)' --deny-tool='shell(git push)'

Les règles de refus l’emportent toujours, même sur --allow-all. Dans une session, /permissions passe d’un mode de permission à l’autre (default, assisted, allow-all) et /permissions show affiche le mode actuel ; /sandbox enable active le sandbox. --allow-all (alias --yolo) supprime toutes les demandes : réservez-le aux conteneurs jetables. La sécurité des agents de code IA explique pourquoi.

Étape 6 : usage programmatique avec -p

Pour les scripts et la CI, -p exécute un seul prompt puis quitte. -s n’affiche que la réponse, et comme personne n’est là pour approuver, vous autorisez les outils dès le départ :

copilot -p 'Write a commit message in plain text for the staged changes' \
  -s --allow-tool='shell(git:*)'

copilot -p 'Write unit tests for src/utils/validators.ts' \
  --allow-tool='write, shell(npm:*), shell(npx:*)'

Vous pouvez aussi envoyer un prompt par un pipe : echo "Explain this file: ./complex.ts" | copilot. Quelques options utiles : --no-ask-user empêche Copilot de poser des questions, --output-format=json produit des lignes JSON et --share=PATH enregistre la session en Markdown. À la fin d’une exécution, Copilot affiche une indication copilot --resume=SESSION-ID pour que vous puissiez continuer en mode interactif.

Dans GitHub Actions, placez dans COPILOT_GITHUB_TOKEN un token disposant de la permission Copilot Requests :

- name: Coverage summary
  env:
    COPILOT_GITHUB_TOKEN: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
  run: copilot -p "Run the test suite and produce a coverage summary" -s --allow-tool='shell(npm:*), write' --no-ask-user

Étape 7 : les commandes slash à connaître

Depuis le shell, copilot --resume (ou --continue pour la session la plus récente) reprend là où vous vous étiez arrêté, et -n NAME nomme une session pour pouvoir la reprendre par son nom.

Étape 8 : choisir un modèle

/model ouvre le sélecteur de modèle ; --model=NAME ou la variable d’environnement COPILOT_MODEL le définit au lancement, et auto laisse Copilot choisir. --effort (ou --reasoning-effort) règle low, medium, high, xhigh ou max pour les modèles qui le prennent en charge. Les modèles consomment les AI Credits à des rythmes différents, et les longs contextes ainsi qu’un raisonnement plus poussé coûtent plus cher : jetez donc un œil à /usage de temps en temps.

Vous pouvez aussi utiliser votre propre fournisseur de modèles. Définissez COPILOT_PROVIDER_BASE_URL, COPILOT_PROVIDER_TYPE (openai, azure ou anthropic), COPILOT_PROVIDER_API_KEY et COPILOT_MODEL. Cela fonctionne avec Ollama pour les modèles locaux, à condition que le modèle prenne en charge l’appel d’outils et le streaming ; GitHub recommande une fenêtre de contexte d’au moins 128k tokens. copilot help providers donne les détails.

Étape 9 : ajouter des serveurs MCP

Le serveur MCP GitHub est déjà configuré. Pour en ajouter d’autres, utilisez le CLI ou /mcp add dans une session :

# a local server started with a command
copilot mcp add my-server -- npx -y @example/mcp-server

# a remote server over HTTP
copilot mcp add --transport http my-remote https://mcp.example.com/mcp

Les serveurs sont enregistrés dans ~/.copilot/mcp-config.json, et un .mcp.json dans le dépôt ajoute des serveurs pour ce projet :

{
  "mcpServers": {
    "my-internal-server": {
      "command": "npx",
      "args": ["-y", "@example/mcp-server"],
      "tools": ["*"]
    }
  }
}

tools détermine quels outils du serveur Copilot peut appeler ; ["*"] signifie tous. copilot mcp list montre ce qui est configuré, et --additional-mcp-config ajoute des serveurs pour une seule session. Vous découvrez MCP ? Commencez par qu’est-ce qu’un serveur MCP.

Étape 10 : les instructions personnalisées

Copilot CLI fusionne les instructions de plusieurs sources :

• AGENTS.md, CLAUDE.md et GEMINI.md à la racine du dépôt et dans le dossier courant
• .github/copilot-instructions.md
• .github/instructions/**/*.instructions.md, qui peuvent être limités à certains chemins avec le frontmatter applyTo:
• ~/.copilot/copilot-instructions.md pour vos règles personnelles dans tous les projets

/init (ou copilot init) écrit un .github/copilot-instructions.md de départ à partir de votre dépôt. Restez bref : commandes de build et de test, conventions et ce que l’agent ne doit pas faire. Si vous tenez déjà un AGENTS.md pour d’autres agents, Copilot l’utilisera tel quel. CLAUDE.md et AGENTS.md donne des conseils pour écrire des règles que les agents suivent vraiment. Pour démarrer une session sans aucun de ces fichiers, passez --no-custom-instructions.

Pièges courants

• Démarrer dans votre dossier personnel. Ne faites confiance qu’au dossier du projet ; l’accès de Copilot aux fichiers suit les dossiers de confiance.
• Trop autoriser en CI. --allow-all dans un pipeline qui contient des secrets, c’est chercher les ennuis. N’autorisez que les outils dont le job a besoin et refusez git push sauf si le job doit pousser.
• Oublier la permission du token. Un personal access token sans « Copilot Requests » ne s’authentifie pas, et les tokens appartenant à une organisation ne sont pas pris en charge.
• Une session sans fin. Les longues conversations consomment plus de crédits. Utilisez /compact ou /clear entre deux tâches sans rapport.
• Attendre des outils MCP sans tools. Une entrée de serveur a besoin d’une liste tools ; utilisez ["*"] pour tout exposer.

Utiliser Copilot CLI dans AgentVera

AgentVera est une application de bureau pour macOS, Windows et Linux qui exécute des agents CLI côte à côte dans de vrais terminaux, avec vos propres installations et connexions. Copilot CLI fait partie des agents pris en charge ; la page Copilot CLI dans AgentVera donne les détails :

• Votre connexion GitHub. Copilot utilise sa propre connexion. S’il est déconnecté, lancez /login dans le terminal de l’agent ; un abonnement Copilot existant suffit.
• Modèle et effort par agent. Le modèle est passé avec --model, et l’effort, de minimal à max, avec --reasoning-effort.
• Des sessions qui reviennent. Chaque agent reçoit son propre identifiant de session, et une session enregistrée se rouvre avec --resume après un redémarrage. /compact fonctionne comme d’habitude.
• MCP sans modifier la configuration. Les serveurs du MCP manager d’AgentVera et de son navigateur sont ajoutés avec --additional-mcp-config à chaque lancement, si bien que votre mcp-config.json reste intact. Le rôle de l’agent est ajouté comme dossier d’instructions supplémentaire.
• Panneaux, worktrees et relecture. Lancez Copilot dans la grille du Workspace à côté de Claude Code ou Aider, donnez à chaque agent son propre worktree depuis le panneau Git, et obtenez une code review automatique à la fin de chaque tour. Les agents Copilot fonctionnent aussi dans les flows (Pro et Team), les diffusions et les tâches planifiées.

La grille, les worktrees, la code review et le MCP manager sont dans l’offre gratuite. Téléchargez AgentVera pour l’essayer.

En résumé

Installez Copilot CLI, lancez copilot dans votre projet, faites confiance au dossier et connectez-vous avec /login. Planifiez les modifications importantes avec Shift+Tab ou /plan, n’autorisez que les outils avec lesquels vous êtes à l’aise, et utilisez copilot -p avec des règles --allow-tool explicites pour les scripts et la CI. Mettez vos règles dans AGENTS.md ou .github/copilot-instructions.md et ajoutez des serveurs MCP quand vous en avez besoin. Si vous voulez aussi un agent centré sur git qui fonctionne avec n’importe quel modèle, lisez comment utiliser Aider.