Installer et utiliser GitHub Copilot en mode agent

Au 2 octobre 2026, GitHub Copilot existe sous trois formes agentiques : le mode agent dans Visual Studio Code (Visual Studio Code), qui modifie les fichiers et lance des commandes sur le poste ; l’agent cloud (Copilot cloud agent, appelé Copilot coding agent jusqu’à son renommage annoncé en avril 2026), qui travaille seul dans un environnement GitHub Actions et livre une branche ou une pull request ; et Copilot CLI (Command-Line Interface, interface en ligne de commande), qui fait la même chose dans le terminal. Le sens précis du mot « agentique » est posé sur la page Agentique : définition, lectures d’OpenAI et d’Anthropic, Claude Code. La position défendue ici : ces agents font gagner du temps sur les tâches bornées et vérifiables, à condition de leur donner le moins de droits possible et de relire tout ce qu’ils produisent comme le code d’un inconnu.

→ Lire l’explication complète de la marmotte

Prérequis et compromis central

Avant toute activation, il faut réunir :

un compte GitHub avec un abonnement Copilot. D’après la page des offres consultée le 2 octobre 2026, Copilot CLI est inclus dans toutes les offres ; l’agent cloud demande une offre payante (Pro, Pro+, Max, Business, Enterprise) ou l’offre Student. La facturation se fait désormais en crédits IA (intelligence artificielle) consommés selon le modèle et le nombre de jetons, et l’agent cloud consomme en plus des minutes GitHub Actions ;
pour une organisation en Copilot Business ou Enterprise, l’accord d’un propriétaire de l’organisation : l’agent cloud y est désactivé par défaut, alors qu’il est activé par défaut pour les abonnés individuels Pro, Pro+ et Max ;
Visual Studio Code 1.99 ou plus récent pour le mode agent (exigence du réglage chat.agent.enabled) ;
Node.js 22 ou plus récent pour installer Copilot CLI par npm (Node Package Manager), et PowerShell 6 ou plus sous Windows.

Le compromis : on gagne un exécutant qui enchaîne lecture, modification, tests et correction en autonomie ; on paie un programme qui agit avec les droits de son utilisateur et lit des contenus (issues, pages web, dépendances) qu’un tiers peut avoir écrits. Le risque n’est pas l’incompétence de l’agent, c’est sa docilité.

Étapes 1 à 3 : activation des trois agents

Étape 1. Mode agent dans Visual Studio Code. Installer l’extension GitHub Copilot, se connecter avec le compte GitHub, ouvrir la vue Chat (Ctrl+Alt+I sous Windows et Linux, ⌃⌘I sous macOS) et choisir l’agent dans le sélecteur de la zone de saisie. Le réglage chat.agent.enabled vaut true par défaut ; une organisation peut le forcer à false par la gestion centralisée des réglages de Visual Studio Code.

Étape 2. Agent cloud sur GitHub. Côté organisation, un propriétaire ouvre la page des politiques Copilot de l’organisation, passe la politique « Copilot cloud agent » à Enabled, puis restreint la liste des dépôts autorisés (« Repository access », de préférence Selected repositories). Si l’organisation appartient à une entreprise, ce choix peut être verrouillé au niveau de l’entreprise. Un dépôt peut aussi être exclu par son propriétaire. Pour qu’il compile et teste, l’agent a besoin d’un environnement préparé par un flux de travail dédié :

# Le nom du job est imposé : copilot-setup-steps
name: "Copilot Setup Steps"
on:
  workflow_dispatch:
  push:
    paths:
      - .github/workflows/copilot-setup-steps.yml
jobs:
  copilot-setup-steps:
    runs-on: ubuntu-latest      # exécuteur par défaut de l'agent
    timeout-minutes: 30         # 59 minutes au maximum
    permissions:
      contents: read            # moindre privilège : lecture seule
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v7
        with:
          node-version: "22"
          cache: "npm"
      - run: npm ci             # dépendances installées avant le pare-feu

Seules les clés steps, permissions, runs-on, services, snapshot et timeout-minutes sont prises en compte dans ce job.

Étape 3. Copilot CLI. L’outil s’installe par l’un des canaux officiels, puis s’authentifie au premier lancement :

# Installation (au choix)
npm install -g @github/copilot          # Node.js 22 ou plus
brew install --cask copilot-cli         # macOS et Linux
winget install GitHub.Copilot           # Windows

# Premier lancement depuis le dossier du projet, jamais depuis $HOME
cd ~/projets/facturation
copilot
# Dans la session : /login si aucune session GitHub n'est ouverte

Pour un usage automatisé, un jeton d’accès personnel à granularité fine portant la seule permission « Copilot Requests » peut être exporté dans COPILOT_GITHUB_TOKEN (prioritaire sur GH_TOKEN puis GITHUB_TOKEN). Le script curl | bash également proposé s’exécute sans relecture : à éviter.

Premier usage

Dans Visual Studio Code, la demande se formule comme un ticket : « Ajouter une validation d’IBAN (International Bank Account Number) dans src/paiement/, avec tests, sans toucher à l’API (Application Programming Interface) publique ». L’agent lit les fichiers, propose des modifications, lance les tests et itère. Chaque requête crée un point de restauration : survoler une requête antérieure et choisir Restore Checkpoint annule les modifications de fichiers. Interrompre une requête n’annule pas ce qui a déjà été exécuté : partir d’un dépôt propre.

Sur GitHub, le geste le plus simple consiste à ouvrir une issue, cliquer sur Assignees et choisir Copilot. L’agent travaille sur une branche copilot/..., ouvre une pull request en brouillon et demande une revue. Il se lance aussi depuis l’onglet Agents du dépôt ou par /delegate dans Copilot CLI. Depuis avril 2026, il peut aussi travailler sur une branche sans ouvrir de pull request, produire un plan avant d’écrire du code, ou mener une recherche dans le code. Pour corriger le tir, mentionner @copilot dans un commentaire de la pull request ; seuls les commentaires de personnes ayant l’accès en écriture sont pris en compte.

Dans le terminal, copilot ouvre une session interactive (le mode plan s’obtient par Shift+Tab), et copilot -p "..." exécute une invite unique pour un script.

Niveaux d’autonomie et approbations

Dans Visual Studio Code, le sélecteur de permissions de la zone de saisie propose Manual permissions (par défaut : toute action non pré-approuvée demande confirmation), Assisted permissions (expérimental : un modèle juge chaque appel d’outil) et Allow all. Le mode Autopilot va plus loin : il approuve tout, réessaie seul et répond lui-même aux questions bloquantes. Le niveau par défaut se règle par chat.permissions.default. Les autres réglages utiles :

// settings.json de l'espace de travail
{
  "chat.agent.maxRequests": 25,                // borne la boucle (25 par défaut)
  "chat.tools.global.autoApprove": false,      // ne jamais passer à true
  "chat.tools.terminal.autoApprove": {
    "rm": false, "curl": false, "wget": false, // déjà refusés par défaut
    "git push": false                          // ajout local
  },
  "chat.tools.edits.autoApprove": {
    "**/.github/workflows/**": false           // retouche d'intégration continue
  }
}

Le bac à sable d’agent (préversion sous macOS, Linux et WSL2, Windows Subsystem for Linux) restreint fichiers et réseau pour les commandes du terminal, quel que soit le niveau de permission : à activer.

Dans Copilot CLI, le dossier de lancement doit d’abord être déclaré de confiance, puis chaque outil est approuvé une fois ou pour la session. Les options en ligne de commande permettent une liste blanche étroite : --allow-tool='shell(git:*)' --deny-tool='shell(git push)'. Une règle de refus l’emporte toujours, même sur --allow-all-tools ou --yolo. La documentation officielle déconseille explicitement de mettre ces options dans un alias : ce serait signer un chèque en blanc permanent à un programme qui lit Internet.

Instructions de dépôt

L’agent lit des fichiers d’instructions versionnés, qui remplacent l’explication orale qu’on ferait à un nouvel arrivant :

.github/copilot-instructions.md : consignes pour tout le dépôt (commande de build, commande de test, conventions) ;
.github/instructions/NOM.instructions.md : consignes ciblées, avec un en-tête applyTo: "src/paiement/**/*.ts" ;
AGENTS.md, n’importe où dans l’arborescence, le plus proche du fichier traité l’emportant ; l’agent cloud lit aussi CLAUDE.md et GEMINI.md à la racine.

Ces fichiers sont un vecteur d’injection : une modification externe de AGENTS.md se relit comme une modification de la chaîne d’intégration. Aucun secret ne doit y figurer (voir les secrets dans les prompts).

Bonnes pratiques de sécurité

Secrets. L’agent cloud n’accède ni aux secrets Actions, ni à ceux de Codespaces ou de Dependabot : seuls les secrets du type Agents (Settings, Secrets and variables, Agents) lui sont passés, en variables d’environnement. Ceux préfixés COPILOT_MCP_ ne sont visibles que des serveurs MCP (Model Context Protocol). N’y placer que des identifiants de test, à durée de vie courte.

Moindre privilège. L’agent cloud ne pousse que sur une seule branche, la branche copilot/... ou celle de la pull request où il est invoqué. Seules les personnes ayant l’accès en écriture peuvent le déclencher. En local, lancer Copilot CLI dans une machine virtuelle ou un conteneur pour toute tâche peu encadrée, comme le recommande GitHub.

Revue des pull requests. L’agent ne peut ni marquer sa pull request « Ready for review », ni l’approuver, ni la fusionner, et la personne qui l’a sollicité ne peut pas l’approuver. Ces garde-fous ne valent que si la protection de branche exige au moins une revue. Par défaut, les flux GitHub Actions ne s’exécutent sur son code qu’après un clic sur Approve and run workflows : ce clic se donne après lecture du diff, pas avant. La méthode de relecture est détaillée dans la revue de sécurité du code généré par IA, et les paquets inventés par les modèles dans l’hallucination de paquets.

Pare-feu. L’accès Internet de l’agent cloud est filtré par défaut, avec une liste d’autorisations recommandée (dépôts de paquets, registres de conteneurs, autorités de certification). Les réglages se trouvent dans Settings, Copilot, Internet access, au niveau du dépôt ou de l’organisation. Limites documentées : le pare-feu ne couvre que les processus lancés par l’agent, ni les serveurs MCP ni les étapes de copilot-setup-steps.yml, et une attaque élaborée peut le contourner. Les risques propres aux agents outillés sont traités dans la sécurité des agents autonomes.

Utilité : quand l’agent apporte vraiment, et quand s’en abstenir

L’agent rend service sur les tâches bornées, testables et ennuyeuses : montée de version d’une dépendance avec correction des appels cassés, ajout de tests sur un module existant, correction d’un flux d’intégration continue en échec, migration mécanique d’une API, dette documentaire. L’agent cloud est à son meilleur sur un arriéré d’issues bien rédigées : il travaille pendant la réunion, et la relecture d’un diff de cinquante lignes coûte moins que son écriture. Le mode agent local et Copilot CLI conviennent à l’exploration d’un code inconnu et aux refactorisations surveillées.

Il ne faut pas l’utiliser pour du code cryptographique, d’authentification ou d’autorisation qu’aucun humain compétent ne relira ; sur un dépôt contenant des secrets réels ou des données personnelles ; sur une issue ouverte par un tiers non vérifié (le texte de l’issue devient une instruction) ; sur une tâche floue où « fini » n’a pas de définition testable ; ni dans un dépôt sans tests, où l’agent validera son travail avec la même assurance qu’un candidat qui corrige lui-même sa copie.

🐝 Ce qui arrive si on s’en passe

Un mode Allow all ou un alias --yolo laisse une instruction cachée dans une issue, un README de dépendance ou une page web lancer curl vers un serveur tiers avec le contenu du dépôt. Des secrets de production posés dans l’environnement de l’agent deviennent lisibles par un modèle qui obéit au dernier texte lu. Une branche principale sans revue obligatoire transforme la pull request de l’agent en fusion de fait par le premier relecteur pressé. Un pare-feu désactivé « pour que l’installation passe » supprime la seule barrière contre l’exfiltration. Et la faille introduite ne porte aucune signature d’attaque : elle ressemble à un commit ordinaire, signé et vérifié.

🦫 Explication de la marmotte 🍫

GitHub Copilot est un assistant de programmation fondé sur un modèle de langage. En mode agent, il peut recevoir une mission (« corrige ce bug », « ajoute des tests ») et agir lui-même : ouvrir des fichiers, les modifier, lancer des commandes, regarder si les tests passent et recommencer s’ils échouent. Il existe en trois endroits : dans l’éditeur de code Visual Studio Code, dans le terminal avec Copilot CLI, et sur le site GitHub, où il travaille seul sur un serveur temporaire puis propose ses modifications.

Le danger, c’est qu’un programme qui agit peut aussi mal agir. Il peut se tromper, ou être manipulé par un texte piégé qu’il lit en chemin. On le protège donc de plusieurs façons : il doit demander la permission avant les actions risquées, il ne voit que des mots de passe de test, son accès à Internet est filtré, et sur GitHub il ne peut jamais valider son propre travail. Un humain doit relire et accepter chaque proposition.

Bien utilisé, il fait gagner du temps sur les tâches répétitives. Mal utilisé, il produit très vite du code faux qui a l’air juste. La règle à retenir : lui confier des tâches précises, vérifiables par des tests, et toujours relire ce qu’il rend.

Pages voisines

La citent

L'IA actuelle : assistants conversationnels et agents

Installer et utiliser GitHub Copilot en mode agent

Elle cite

: les deux pages se citent l’une l’autre.

Installer et utiliser GitHub Copilot en mode agent

Installer et utiliser GitHub Copilot en mode agent

Prérequis et compromis central

Étapes 1 à 3 : activation des trois agents

Premier usage

Niveaux d’autonomie et approbations

Instructions de dépôt

Bonnes pratiques de sécurité

Utilité : quand l’agent apporte vraiment, et quand s’en abstenir

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines