Copilot et VS Code : usage avancé
Utiliser GitHub Copilot dans VS Code de façon avancée : modes Ask, Edit, Plan, Agent, Auto, Chat Settings, Tools Set, contexte, historique et instructions de projet.
Cette page reprend les sujets qui deviennent importants dès qu'on veut utiliser un agent de code de façon plus maîtrisée dans VS Code : modes de conversation, capacités réelles de l'outil, paramètres de chat, droits accordés, contexte visible et instructions de projet.
Le but n'est pas de mémoriser un vocabulaire marketing. Le but est de savoir quand demander une explication, quand exiger un plan, quand laisser un agent travailler sur plusieurs fichiers et quand limiter volontairement ses droits.
Prérequis et repères rapides
- Extensions présentes : vérifier que l'assistant et le chat associé sont bien installés.
- Compte relié : vérifier que VS Code est connecté au bon compte et au bon abonnement.
- Panneaux visibles : repérer l'icône Copilot, le chat et les options de mode avant de démarrer.
- Workspace clair : ouvrir le bon dossier et fermer les sujets sans rapport avant une tâche importante.
Lire du code, proposer des analyses, produire des plans, suggérer des tests, rédiger de la documentation et modifier plusieurs fichiers si le mode et les droits l'autorisent.
L'agent ne "comprend" pas tout par magie, ne maîtrise pas votre machine sans autorisation et ne doit pas recevoir un périmètre flou pour une tâche critique.
Completion pour de petits blocs, chat pour comprendre ou cadrer, agent ou "Build with Agent" pour une tâche multi-étapes avec plan, éditions et vérification locale.
Ask pour analyser, Edit pour une correction locale, Plan pour cadrer, Agent pour exécuter un plan sur plusieurs fichiers, Auto si vous acceptez que l'outil choisisse.
Chat Settings, niveau de détail, contexte autorisé et outils disponibles influencent directement la qualité et le niveau d'action de la réponse.
L'historique correspond à ce que vous avez déjà dit, le contexte à ce que l'outil peut lire dans le projet. Ce sont deux choses différentes.
Les modes Ask, Edit, Plan, Agent et Auto
Ask : comprendre, expliquer, comparer, diagnostiquer. Edit : corriger ou transformer une zone locale et bien délimitée. Plan : obtenir une démarche détaillée avant d'agir. Agent : exécuter une tâche multi-fichiers avec étapes, modifications et contrôles. Auto : laisser l'outil choisir le mode le plus adapté.
En pratique, une bonne séquence consiste souvent à commencer par Ask pour clarifier, passer par Plan pour structurer, puis utiliser Edit ou Agent quand le périmètre et les validations sont suffisamment nets.
Quand choisir chaque mode
- Ask : pour expliquer une requête SQL lente, comprendre un fichier PHP ou analyser un symptôme.
- Edit : pour corriger une validation, renommer une variable, simplifier un bloc ou ajuster une page HTML.
- Plan : pour refactorer sans casser une API, organiser une migration JS vers TS ou cadrer un lot de tests.
- Agent : pour un chantier avec plusieurs fichiers, documentation associée, commandes locales et validations à enchaîner.
- Auto : quand la tâche est claire mais que vous acceptez que l'outil arbitre entre analyse, plan et exécution.
Chat Settings et Tools Set
Les réglages du chat servent à ajuster le comportement du copilote à votre façon de travailler. Il faut surtout surveiller quatre leviers : niveau de détail, contexte autorisé, outils disponibles et possibilité d'écriture ou d'exécution.
- Niveau de détail : court pour aller vite, détaillé pour audit, plan, reprise ou documentation.
- Contexte du projet : à autoriser quand vous voulez des réponses ancrées dans les fichiers ouverts ou le workspace.
- Tools Set : lecture seule pour diagnostic prudent, écriture pour petites corrections, terminal seulement quand cela a du sens.
- Mode de travail : plus les droits sont larges, plus il faut serrer le périmètre et exiger un format de sortie stable.
Règle pratique : 1) Diagnostic sensible -> Ask + lecture seule. 2) Correction locale -> Edit + périmètre court. 3) Refactor structurel -> Plan puis Agent. 4) Tâche risquée -> contexte explicite + validations imposées.
Profils de réglage concrets
Mode Ask, détail moyen ou élevé, contexte limité aux fichiers utiles, lecture seule si la tâche touche à la sécurité, aux données ou à la configuration.
Plan d'abord, contexte projet autorisé, outils d'écriture ensuite, avec validations imposées et contrôle de l'API publique.
Ask ou Plan, détail élevé, contexte documentaire large, sortie imposée de type plan, synthèse, fiche de passation ou runbook.
Agent ou Build with Agent avec périmètre très nommé, points de contrôle explicites et vérification finale avant d'accepter les changements.
Historique vs contexte
L'historique est la mémoire conversationnelle immédiate : ce que vous avez déjà demandé, les hypothèses formulées, les validations annoncées. Le contexte, lui, correspond aux fichiers, extraits, logs et documents que l'outil peut réellement voir.
Si vous changez de sujet, videz votre ambiguïté : redonnez le périmètre, citez les fichiers utiles et rappelez le format attendu. Un historique long n'est pas un contexte technique fiable.
Instructions de projet
Quand l'outil est utilisé souvent dans le même projet, il devient utile de lui donner un cadre stable via un fichier d'instructions de projet. Dans l'écosystème Copilot, on rencontre souvent un fichier .github/copilot-instructions.md qui sert de ligne directrice pour les conversations du workspace.
# .github/copilot-instructions.md - Réponds en français. - Commence par analyser avant de proposer une modification importante. - Ne change pas l'API publique sans le signaler. - Termine par les validations ou risques restants. - Pour les scripts, précise prérequis, erreurs et retour arrière.
Ce type de fichier ne remplace pas un bon prompt, mais il réduit les oublis récurrents sur le style, le niveau d'exigence et la forme attendue des réponses.
Prompt files et génération d'instructions
Les prompt files servent à stocker des demandes réutilisables pour les plans de tests, les refactors, la documentation ou les revues de sécurité. Ils se complètent bien avec les instructions de projet : les instructions donnent le cadre général, les prompt files portent les cas d'usage répétitifs.
La fonction de type generate chat instructions sert à produire une première base d'instructions de projet. Il faut ensuite la relire, la raccourcir et la recaler sur les besoins réels.
Si vous voulez aller plus loin sur la structuration des agents, des prompt files et des skills, ouvrez aussi la page agents, skills et instructions.
Prompts rapides selon le besoin
- Choisir le bon mode : "Dis-moi si cette demande relève plutôt de Ask, Edit, Plan ou Agent, et justifie le choix en trois lignes."
- Préparer un refactor : "Avant toute modification, propose un plan détaillé, les impacts probables et les validations à rejouer."
- Régler le niveau d'accès : "Indique quel niveau de contexte et quels outils sont nécessaires pour cette tâche, sans accorder plus de droits que nécessaire."
- Nettoyer le contexte : "Résume l'historique utile, liste les fichiers à garder en contexte et signale les zones qui ne devraient pas influencer la réponse."
- Préparer des instructions : "Génère une première version d'instructions de projet très courtes pour ce workspace, puis liste ce qu'il faut encore relire à la main."
Checklist avant de lancer un agent
- Le périmètre est-il nommé avec des fichiers, dossiers ou commandes précis ?
- Le bon mode est-il choisi ou l'outil risque-t-il de sur-agir en Auto ?
- Le niveau de contexte est-il suffisant sans être trop large ?
- Les droits d'écriture ou de terminal sont-ils vraiment nécessaires ?
- Le format attendu et les validations finales sont-ils imposés ?
Cas du site
- Ask : demander pourquoi get-fiches-list.php ou get-sujets-list.php peuvent poser des problèmes de validation ou de structure.
- Plan : cadrer un refactor progressif autour de save-fiche.php et fiches.json.
- Agent : enchaîner documentation, correctifs et tests autour de l'interface locale avec un périmètre étroit et des contrôles clairs.
- Settings prudents : utiliser un mode plus contraint avant de toucher config.php, les scripts PowerShell ou les fichiers de données.
Version débutant vers intermédiaire
- Débutant : apprendre à séparer Ask, Plan et Edit, sans donner de droits trop larges d'un coup.
- Intermédiaire : régler détail, contexte et outils selon la tâche réelle.
- Plus avancé : combiner instructions de projet, prompt files et agents spécialisés avec validations explicites.
Complétion inline et contexte visible
La complétion inline est efficace pour prolonger une intention locale. Un nom précis, une signature typée, un commentaire directif court et un premier exemple valent souvent mieux qu'une longue conversation. N'acceptez que la partie comprise et vérifiable.
- Ouvrir uniquement les fichiers réellement utiles au contexte.
- Écrire la signature, les types et le comportement attendu avant de demander le corps.
- Accepter partiellement une suggestion lorsque seule sa première partie est correcte.
- Relire imports, gestion d'erreurs et tests après toute génération multi-ligne.
Contexte multimodal
Analyse cette capture ou ce diagramme dans le contexte suivant : [CONTEXTE]. Commence par décrire uniquement ce qui est visible. Sépare ensuite observations, interprétations et informations illisibles. Relie l'image aux fichiers ou exigences fournis, puis propose les questions et vérifications nécessaires avant toute modification.
Une capture ne remplace pas le code, les logs ou une spécification. Évitez d'exposer données personnelles, secrets, URL internes ou informations de production.