Prompts GitHub Copilot : commentaires, contexte et chat

Un développeur écrit // calcule le total au-dessus d'une fonction vide. Copilot propose dix lignes qui additionnent les prix, sans la TVA, sans la remise fidélité, avec des flottants là où le projet utilise des centimes entiers. Le code compile et il est faux, parce que le commentaire était la seule information donnée.

GitHub Copilot se pilote de trois manières : ce que tu écris dans le fichier, ce que tu lui demandes dans le chat, et les règles que tu fixes pour tout le dépôt. Chacune a ses réflexes.

Les suggestions en ligne : le commentaire est ton prompt

Quand Copilot complète ton code au fil de la frappe, il se base sur ce qui entoure le curseur : le nom de la fonction, les fichiers ouverts, les commentaires. Un nom explicite et un commentaire qui décrit le comportement valent mieux qu'un long préambule.

Compare ces deux débuts de fonction.

// calcule le total
function total(items) {

// Total d'un panier en centimes (entiers).
// Applique la remise fidélité de 5 % si client.fidele est vrai,
// puis ajoute la TVA de 20 %. Arrondi au centime inférieur.
// Panier vide : renvoie 0.
function totalPanier(items, client) {

Le second dit l'unité, l'ordre des opérations, l'arrondi et le cas limite. Copilot n'a plus à deviner. Si tu n'es pas sûr de la règle de gestion, ne demande pas au code de la deviner à ta place : écris-la d'abord.

Deux habitudes aident aussi. Garde ouverts les fichiers qui montrent comment le projet fait les choses (un module voisin, un test existant), car ils servent d'exemples. Et relis chaque suggestion avant de l'accepter, surtout les plus longues : accepter d'un coup dix lignes que tu n'as pas lues, c'est rédiger du code que personne ne comprend.

Le chat : choisis ce qu'il voit

Dans le chat, la qualité de la réponse dépend de ce que Copilot a sous les yeux. Selon ton éditeur, il peut voir le fichier ouvert, le code que tu as sélectionné, et les fichiers que tu ajoutes explicitement au contexte (dans Visual Studio Code, par exemple, en les nommant avec #). Regarde ce que ton interface propose, car les options changent d'un éditeur à l'autre.

Le réflexe utile est de sélectionner le code concerné avant de poser ta question. Un exemple de demande pour corriger un bug :

La fonction sélectionnée renvoie 0 pour un panier de deux articles quand le client est fidèle. Sans remise elle donne le bon total.

Cherche la cause, explique-la en deux phrases, puis propose le correctif le plus petit possible. Ne réécris pas le reste de la fonction et ne change pas sa signature.

« Le plus petit possible » protège ton historique de commits. Sans cette limite, l'outil réorganise volontiers tout le fichier, et la revue de code devient un cauchemar.

Pour les tâches courantes, des commandes comme /explain, /fix ou /tests existent dans le chat de plusieurs éditeurs. Elles évitent de réécrire la même demande, mais complète-les d'une phrase de contraintes. Par exemple, après /tests :

Écris les tests de la fonction sélectionnée avec le framework déjà utilisé dans le dossier tests/. Couvre le panier vide, le client fidèle, un prix à zéro, un arrondi qui tombe entre deux centimes. Un test par cas, avec un nom qui décrit le cas.

Lance ensuite les tests. Un test que Copilot a écrit peut passer parce qu'il vérifie ce que le code fait, et non ce qu'il devrait faire. Relis les valeurs attendues une par une.

Les règles du projet : un fichier d'instructions

Tu en as assez de répéter « on utilise des centimes entiers » et « pas de dépendance nouvelle sans en parler » ? GitHub permet de déposer dans le dépôt un fichier .github/copilot-instructions.md, écrit en Markdown et en langage naturel. Copilot le lit pour les demandes concernant ce dépôt. Sa prise en charge varie selon l'éditeur et la fonctionnalité, donc regarde la documentation de GitHub pour ton cas.

# Règles du projet

- Les montants sont des entiers en centimes. Jamais de flottants pour de l'argent.
- Tests avec Vitest, dans le dossier tests/, un fichier par module.
- N'ajoute pas de dépendance sans me le signaler dans la réponse.
- Les messages d'erreur destinés à l'utilisateur sont en français, les noms de code en anglais.

Garde ce fichier court et vérifiable. Dix règles précises valent mieux que trois pages de principes, et une règle que tu ne relis jamais finit par contredire le code. Le même raisonnement vaut pour les instructions système et pour les instructions des agents : écris ce qu'un nouveau collègue devrait savoir le premier jour.

Ce que Copilot ne sait pas

Il ne connaît pas tes décisions d'architecture, ton historique de bugs ni les règles qui sont dans la tête de l'équipe. Il peut aussi proposer une fonction d'une bibliothèque qui n'existe pas ou une syntaxe d'une ancienne version. Si une suggestion utilise un appel que tu ne reconnais pas, ouvre la documentation de la bibliothèque avant de continuer.

Pense aussi au contenu de ton code : clés d'accès, mots de passe, données de clients. Ne les place pas dans un commentaire ni dans le chat, et lis les conditions de ton offre et les règles de ton employeur sur l'envoi de code à un service extérieur. Les bases de la relecture et du débogage avec une IA sont dans notre article sur les prompts pour développeurs.

À essayer aujourd'hui

Prends la prochaine fonction que tu t'apprêtes à écrire. Avant de taper la première ligne, écris en commentaire son comportement complet : entrées, sorties, un cas limite. Regarde ce que Copilot propose, puis corrige le commentaire, pas le code, si la suggestion s'éloigne de ce que tu voulais.