Accueil › GitHub Copilot › Prompts

GitHub Copilot prompts : exemples et techniques

Un bon prompt Copilot décrit un objectif clair, fournit le contexte nécessaire, impose des contraintes précises et donne un exemple du résultat attendu. La différence entre un output médiocre et du code production-ready tient souvent à la qualité de votre prompt, pas à celle du modèle.

Les principes fondamentaux

Le prompt engineering pour Copilot n’est pas une science obscure. C’est un ensemble de bonnes pratiques qui aident le modèle à comprendre exactement ce que vous voulez. GitHub recommande officiellement quatre principes : décrire le but, être spécifique, donner des exemples, et itérer.

Objectif d’abord, détails ensuite

Commencez chaque prompt par une description large de l’objectif, puis listez les exigences spécifiques. Le modèle lit le prompt de haut en bas et calibre sa réponse en conséquence.

Le premier prompt est trop vague : Copilot ne sait pas quoi écrire. Le second définit clairement la fonction, ses entrées, sa sortie, et son comportement d’erreur. Le modèle comprend exactement votre intention.

Fournissez du contexte ciblé

Plus le contexte est pertinent, meilleure est la réponse. Dans le chat, utilisez les variables de contexte pour pointer Copilot vers les bons fichiers :

#file:src/auth/login.ts injecte le contenu d’un fichier spécifique. #codebase lance une recherche dans l’ensemble du projet. @workspace donne accès à tous les fichiers du workspace. #terminalLastCommand injecte la dernière commande exécutée et sa sortie.

Pour les suggestions inline (autocomplétion), le contexte vient des fichiers ouverts dans votre éditeur. Ouvrez les fichiers pertinents et fermez ceux qui ne le sont pas. Si vous écrivez un service d’authentification, avoir le modèle utilisateur et les routes d’auth ouverts améliore drastiquement les suggestions.

Donnez des exemples

Les exemples sont le levier le plus puissant. Un input/output concret, un cas de test, ou un snippet montrant le pattern attendu guide le modèle bien mieux qu’une description verbale.

Écris une fonction qui formate un montant en euros.

Exemples :
- formatEuros(1234.5) → "1 234,50 €"
- formatEuros(0) → "0,00 €"
- formatEuros(-50.123) → "-50,12 €"

Utilise Intl.NumberFormat avec locale 'fr-FR'.
Arrondi à 2 décimales.

Ce prompt contient un objectif, trois exemples concrets, et des contraintes techniques. Copilot produira exactement la fonction attendue dans la grande majorité des cas.

Découpez les tâches complexes

Ne demandez pas à Copilot de construire un système complet en un seul prompt. Décomposez :

Étape 1 : Écris une fonction pour générer une grille 10x10 de lettres
Étape 2 : Écris une fonction pour trouver tous les mots dans la grille à partir d'une liste
Étape 3 : Combine les fonctions pour générer une grille contenant au moins 10 mots
Étape 4 : Ajoute un affichage de la grille et 10 mots aléatoires

Chaque étape est vérifiable individuellement. Si une étape produit un résultat incorrect, vous corrigez avant de passer à la suivante. C’est plus efficace que de demander « Génère un jeu de mots croisés complet » et d’essayer de corriger un bloc de code monolithique.

La structure en 5 parties pour les prompts avancés

Pour les tâches non triviales, structurez votre prompt en cinq parties. Vous n’aurez pas toujours besoin des cinq, mais quand Copilot rate sa cible, cette structure est le moyen le plus rapide de le recadrer.

1. Rôle et contexte

Décrivez le rôle que Copilot doit jouer et le contexte du projet.

Tu es un développeur senior TypeScript travaillant sur une API REST
avec Express, Prisma et PostgreSQL. Le projet suit une architecture
hexagonale avec séparation domaine/infra.

2. Tâche précise

Décrivez exactement ce que vous voulez. Un objectif, une phrase.

Crée un endpoint POST /api/invoices qui crée une facture
et envoie un e-mail de confirmation.

3. Contraintes

Les contraintes protègent votre architecture. Sans elles, Copilot « résout » le problème en changeant tout autour.

Contraintes :
- TypeScript strict, pas de any
- Validation avec Zod
- Ne pas modifier le schéma de la base de données
- Ne pas ajouter de nouvelles dépendances
- Pas de N+1 queries
- Logs structurés avec Pino

4. Exemples

Un input/output, un test unitaire, ou un snippet montrant le pattern attendu.

Exemple d'input :
{ "clientId": "abc-123", "items": [{"desc": "Consulting", "amount": 500}] }

Exemple d'output (201 Created) :
{ "id": "inv-456", "status": "pending", "total": 500 }

5. Format de sortie

Spécifiez comment vous voulez la réponse : code seul, plan d’action, tests d’abord, diff, ou explication.

Génère d'abord les tests Vitest, puis l'implémentation.
Inclus la route Express, le service domaine, et le repository Prisma
dans des fichiers séparés.

Prompts par cas d’usage

Debugging

/fix L'appel API à /api/users retourne 500.
L'erreur dans le terminal est : "Cannot read property 'email' of undefined"
Le problème est probablement dans #file:src/routes/users.ts
Corrige le bug sans changer la signature de la route.

La slash command /fix indique l’intention. Le message d’erreur exact fournit le contexte. Le fichier est référencé précisément. La contrainte (ne pas changer la signature) empêche Copilot de contourner le problème.

Génération de tests

/tests #file:src/utils/formatCurrency.ts
Utilise Vitest avec describe/it.
Couvre les cas : nombre positif, zéro, nombre négatif,
nombre avec beaucoup de décimales, entrée non-numérique (doit throw).
Chaque test doit avoir un nom descriptif en français.

Refactoring

@workspace Refactore la logique de validation des formulaires.
Actuellement dispersée dans chaque composant React.
Centralise dans un hook custom useFormValidation.
Les règles de validation doivent être déclaratives (objet de config).
Ne casse pas les tests existants.
Montre le plan avant de modifier le code.

Le participant @workspace donne accès à tout le projet. La demande de plan préalable évite que Copilot ne se lance dans des modifications hasardeuses.

Documentation

/doc #file:src/services/paymentService.ts
Ajoute des commentaires JSDoc à toutes les méthodes publiques.
Inclus : description, @param avec types, @returns, @throws.
Style : concis, technique, en anglais.

Agent Mode : fonctionnalité complète

Implémente un système de notifications push pour l'app.

Spécification :
- Endpoint POST /api/notifications/subscribe (enregistre un token FCM)
- Endpoint POST /api/notifications/send (envoie une notif à un utilisateur)
- Service NotificationService avec Firebase Cloud Messaging
- Middleware d'authentification requis sur les deux endpoints
- Tests d'intégration avec un mock FCM

Stack : Express, TypeScript, Prisma, Vitest.
Suis les conventions dans .github/copilot-instructions.md.

Ce prompt est conçu pour le mode Agent. L’agent planifiera les fichiers à créer, implémentera chaque partie, exécutera les tests, et itérera pour corriger les erreurs.

Autocomplétion inline : commentaires guides

Pour les suggestions inline (pas le chat), les commentaires dans votre code servent de prompts :

// Fonction qui calcule le TTC à partir du HT
// Taux de TVA par défaut : 20%
// Retourne un nombre arrondi à 2 décimales
function calculateTTC(ht: number, tvaRate: number = 0.2): number {

Les commentaires décrivent l’intention, les paramètres, et le comportement attendu. Copilot complétera la fonction en s’appuyant sur ces indications.

Instructions projet : le prompt permanent

Le fichier .github/copilot-instructions.md agit comme un prompt système persistant appliqué à toutes les interactions Copilot dans votre repo. C’est le levier le plus puissant pour améliorer la qualité des réponses à long terme.

Exemple de fichier d’instructions

# Instructions pour Copilot

## Stack technique
- TypeScript 5.4 strict (noUncheckedIndexedAccess, exactOptionalPropertyTypes)
- React 19 avec hooks uniquement (pas de classes)
- Next.js 15 App Router
- Prisma ORM avec PostgreSQL
- Vitest pour les tests, Testing Library pour les composants

## Conventions de code
- Fonctions fléchées, pas de function classique
- Nommage : camelCase pour les variables, PascalCase pour les types
- Pas de any, utiliser unknown + type guard si nécessaire
- Imports absolus avec alias @/ pour src/
- Commentaires en anglais, messages utilisateur en français

## Architecture
- Services dans src/services/ (logique métier)
- Routes API dans src/app/api/ (Next.js route handlers)
- Composants UI dans src/components/ (React)
- Types partagés dans src/types/

## Patterns à suivre
- Validation d'entrée avec Zod sur chaque endpoint
- Gestion d'erreur centralisée via middleware
- Pas de logique métier dans les composants React
- Tests : un fichier .test.ts par fichier source

## Ce qu'il ne faut PAS faire
- Ne pas utiliser localStorage pour stocker des tokens
- Ne pas importer directement le client Prisma dans les composants
- Ne pas créer de routes catch-all sans validation

Ce fichier est lu automatiquement par Copilot (chat, Agent Mode, Coding Agent, code review). Chaque réponse respectera ces conventions sans que vous ayez à les répéter. Utilisez la commande /init dans le chat VS Code pour générer un fichier d’instructions initial basé sur votre codebase existant.

Context engineering : séparer le permanent du temporaire

L’approche la plus efficace consiste à séparer le contexte permanent (fichier d’instructions) du contexte temporaire (tâche spécifique). Le fichier .github/copilot-instructions.md contient votre stack, vos conventions, et votre architecture. Pour chaque tâche, vous écrivez un prompt qui ne décrit que ce qui est nouveau ou différent.

Ce pattern, appelé context engineering, réduit le bruit dans les prompts et maximise la pertinence des réponses. Vous ne répétez plus « utilise TypeScript strict avec Prisma » à chaque message : c’est déjà dans les instructions.

Prompt files réutilisables

Depuis les mises à jour de début 2026, VS Code supporte les prompt files : des fichiers de prompt réutilisables que vous stockez dans votre workspace. Créez un fichier .github/prompts/generate-api-endpoint.md avec un template de prompt, et réutilisez-le pour chaque nouveau endpoint.

# Template : Nouvel endpoint API

Crée un endpoint {METHOD} {PATH} qui {DESCRIPTION}.

## Spécification
- Authentification : {AUTH_REQUIRED}
- Validation input : schema Zod dans src/validators/
- Service : logique dans src/services/
- Repository : requêtes Prisma dans src/repositories/
- Tests : Vitest dans __tests__/

## Contraintes
- Respecte les conventions dans copilot-instructions.md
- Ne modifie pas les endpoints existants
- Inclus la gestion d'erreur (400, 401, 404, 500)

Utilisez la commande /create-* dans le chat pour générer des prompts, des skills, des agents ou des hooks directement depuis une conversation réussie.

Erreurs courantes à éviter

Prompts trop vagues

« Améliore ce code » ne donne pas de direction. Préférez : « Optimise cette requête SQL pour éviter les N+1 queries et ajoute un index sur la colonne user_id ».

Répéter le même prompt en espérant un résultat différent

Si Copilot rate, ne reformulez pas la même chose plus fort. Réduisez le scope, ajoutez une contrainte, ou fournissez un exemple. Changez l’angle d’attaque.

Prompts monolithiques

Un prompt de 50 lignes qui décrit un système entier va produire un résultat approximatif. Découpez en 5 prompts de 10 lignes. Chaque sous-tâche doit être vérifiable avant de passer à la suivante.

Pas de contraintes

Sans contraintes, Copilot prend les chemins les plus courts : ajouter des dépendances, changer les types existants, ignorer les conventions. Les non-goals (« Ne pas ajouter de bibliothèques », « Ne pas changer le schéma DB ») sont aussi importants que les objectifs.

Ignorer le contexte

Poser une question sur l’authentification sans référencer le fichier d’auth (#file:src/auth/...) force Copilot à deviner. Il devinera mal. Référencez toujours les fichiers pertinents avec #file ou @workspace.

Accepter sans review

Copilot génère du code plausible, pas du code garanti correct. Les bugs subtils (race conditions, edge cases, failles de sécurité) passent inaperçus si vous faites un Tab automatique. Traitez chaque suggestion comme un code de collègue junior : lisez-le, testez-le, challengez-le.

Sécurité dans les prompts

Quelques règles de sécurité à respecter systématiquement :

Ne collez jamais de secrets (clés API, mots de passe, tokens) dans vos prompts. Le contenu des prompts transite par les serveurs de GitHub. Utilisez des variables d’environnement dans vos exemples (process.env.API_KEY), pas des valeurs réelles.

Vérifiez le code généré pour les vulnérabilités courantes : injections SQL, secrets en dur, validation d’entrée manquante, exposition de données sensibles dans les logs. Le code de Copilot n’est pas audité automatiquement. Utilisez vos outils SAST/DAST habituels sur le code généré.

Sur les plans Business et Enterprise, les administrateurs peuvent exclure des fichiers sensibles (clés privées, configurations de production) pour empêcher Copilot d’y accéder.