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.
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.
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.
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.
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.
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.
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.
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.
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.