Contexte, entrées et construction du prompt

7.1 Comment Copilot reçoit le contexte 👀

Définition simple

Le contexte est l’ensemble des informations que Copilot peut utiliser pour produire une réponse ou une suggestion.

Ce contexte peut venir de plusieurs endroits :

• le fichier ouvert ;
• le code autour du curseur ;
• les fichiers ouverts dans l’IDE ;
• le texte sélectionné ;
• le prompt utilisateur ;
• l’historique de la conversation ;
• certains fichiers du repository ;
• des instructions personnalisées ;
• des prompt files ;
• des Spaces ;
• des sources externes via MCP ;
• des issues ou pull requests selon la surface utilisée.

GitHub recommande explicitement d’ouvrir les fichiers pertinents et de fermer les fichiers non pertinents, car Copilot utilise les fichiers ouverts pour comprendre une demande dans l’IDE. (docs.github.com)

Exemple simple

Tu ouvres ce fichier :

# user_service.py

def normalize_email(email: str) -> str:
    return email.strip().lower()

Puis tu commences à écrire :

def is_valid_email(email: str) -> bool:

Copilot peut utiliser le contexte du fichier pour proposer une fonction cohérente :

import re

def is_valid_email(email: str) -> bool:
    normalized_email = normalize_email(email)
    return re.match(r"^[^\s@]+@[^\s@]+\.[^\s@]+$", normalized_email) is not None

Il a probablement utilisé :

• le nom de la fonction
• le type
• la fonction normalize_email déjà présente
• le style du fichier

Exemple avec fichiers ouverts

Tu as deux fichiers ouverts :

payment_service.ts
retry_policy.ts

Tu demandes :

Add retry logic to the payment service.

Copilot peut utiliser le fichier retry_policy.ts comme contexte, parce qu’il est ouvert et pertinent.

Mais si tu as aussi ouvert :

old_experimental_retry_policy.ts

Copilot pourrait être influencé par du contexte non souhaité.

D’où la bonne pratique :

Ouvre les fichiers utiles.
Ferme les fichiers inutiles.

Dans Copilot Chat, le contexte est ce que tu sélectionnes, joins ou références. Comment formuler la demande avec le bon contexte relève du chapitre 8 (8.4).

Sources de contexte possibles

GitHub indique aussi que Copilot peut être enrichi via des mécanismes comme Copilot Spaces et MCP, qui servent justement à fournir plus de contexte pertinent. (docs.github.com)

7.2 Données envoyées dans le prompt 📦

Définition

Quand tu demandes quelque chose à Copilot, l’outil construit une requête envoyée au modèle.

Cette requête peut contenir :

• ton prompt ;
• le code autour du curseur ;
• le fichier courant ;
• une sélection de code ;
• des fichiers ouverts pertinents ;
• l’historique récent de chat ;
• des instructions personnalisées ;
• des métadonnées nécessaires ;
• parfois du contexte repository ou GitHub selon la fonctionnalité.

Important

Le “prompt” envoyé au modèle n’est pas toujours exactement ce que tu as tapé.

Tu tapes :

Fix this function.

Mais Copilot peut construire un prompt enrichi avec :

• la fonction sélectionnée
• les imports du fichier
• les erreurs visibles
• le langage utilisé
• les instructions projet
• l’historique de conversation utile

C’est ça qui permet à Copilot de répondre de manière contextualisée.

Exemple

Tu sélectionnes :

def average(numbers):
    return sum(numbers) / len(numbers)

Tu demandes :

Fix this.

Copilot construit une demande enrichie. Voici une illustration pédagogique, pas le prompt réel : GitHub ne le publie pas et il varie selon la fonctionnalité.

User wants to fix the selected Python function.

Selected code:
def average(numbers):
    return sum(numbers) / len(numbers)

Task:
fix the function.

Retiens l’idée : le modèle reçoit ta demande et du contexte, pas seulement les quelques mots que tu as tapés. GitHub documente cette étape comme un pré-traitement du prompt, combiné au contexte (code autour du curseur, onglets ouverts, historique, dépôt), avant l’envoi à un grand modèle de langage.

Données qu’il ne faut pas mettre dans un prompt

Évite absolument :

• clés API
• tokens
• mots de passe
• secrets cloud
• données client réelles
• données médicales
• données financières
• données personnelles
• logs contenant des identifiants
• informations internes sensibles

Même si Copilot est conçu avec des protections, la bonne pratique reste :

Ne mets pas de données sensibles dans un prompt.

Mauvais prompt ❌

Here is our production Stripe API key: sk_live_xxxxx.
Write a script to test payments.

Bon prompt ✅

Write a Python script that calls a payment API using an API key loaded from an environment variable.
Use a placeholder base URL and do not hardcode secrets.

Exemple :

import os
import requests

api_key = os.getenv("PAYMENT_API_KEY")

response = requests.get(
    "https://api.example.com/payments",
    headers={"Authorization": f"Bearer {api_key}"}
)

Ne pas inclure les données sensibles dans le prompt.
Utiliser des placeholders.
Utiliser des variables d’environnement.
Appliquer les policies et content exclusions si besoin.

7.3 Prompt building 🧱

Définition

Le prompt building est le processus par lequel GitHub Copilot construit la requête envoyée au modèle.

Cette requête peut combiner :

prompt utilisateur + contexte code + instructions + historique + métadonnées utiles

Le guide GH-300 mentionne explicitement l’input processing et le prompt building comme compétences à connaître. (learn.microsoft.com)

Définition technique

Tu peux voir le prompt building comme une étape de préparation de payload.

Ce schéma est un modèle conceptuel, une simplification pédagogique. GitHub documente le principe (le prompt est pré-traité, combiné au contexte, puis envoyé au modèle), pas chaque étape interne. Retiens le rôle de l’étape, pas une implémentation.

Conceptuellement :

Exemple simple

Tu demandes :

Generate tests for this function.

Copilot peut enrichir avec :

• fonction sélectionnée
• langage détecté : Python
• framework probable : pytest
• fichier de test ouvert
• style des tests existants
• instructions projet

Si un fichier de test existant contient :

def test_normalize_email_trims_spaces():
    assert normalize_email(" TEST@EXAMPLE.COM ") == "test@example.com"

Copilot peut générer des tests dans le même style.

Exemple avec instructions file

Instructions projet :

# Copilot instructions

- Use TypeScript strict mode.
- Use Jest for tests.
- Do not use `any`.
- Prefer explicit return types.

Prompt utilisateur :

Generate tests for this service.

Prompt final conceptuel :

Generate tests for this TypeScript service.
Follow project instructions:
- Use Jest
- Avoid any
- Use explicit return types
Use the selected service as context.

Bon prompt building côté utilisateur

Le chapitre 8 prend ensuite le relais pour décider quel contexte fournir ou omettre. Ici, retiens seulement comment la demande et le contexte sont assemblés avant le modèle.

Supporting concept : Fill-in-the-Middle (FIM)

FIM décrit une façon de construire une suggestion dans un trou du code :

• PREFIX : le code situé avant le curseur ;
• SUFFIX : le code situé après le curseur ;
• FIM : la complétion proposée entre les deux.

Cela complète le modèle mental gauche-vers-droite ou prefix-only, où le modèle ne reçoit que ce qui précède le curseur. FIM est une connaissance de soutien pour comprendre la construction de l’entrée et le cycle de suggestion, pas un nouvel objectif officiel du GH-300. Toutes les surfaces Copilot n’emploient pas nécessairement la même implémentation.

Même si Copilot construit le prompt final, tu peux l’aider en donnant un prompt clair :

Generate Jest unit tests for the selected TypeScript service.

Include:
- success path
- invalid input
- dependency failure
- edge cases

Constraints:
- do not modify production code
- follow existing test style
- mock external dependencies

7.11 Cas d’examen : que voit Copilot ? que ne voit-il pas ? 🧪

Cette section est la plus importante pour l’examen.

Règle mentale

Quand tu lis une question, demande-toi :

• Quelle surface Copilot utilise-t-il ?
• Quel contexte est disponible ?
• Quelles policies s’appliquent ?
• Des exclusions existent-elles ?
• Le contexte externe est-il activé ?

Tableau de décision rapide

Cas 1 : Fichier fermé

Scénario :

Tu as un fichier BillingRules.md fermé et non référencé.

Tu demandes dans l’IDE :

Implement the billing rules.

Réponse attendue :

Copilot ne connaît pas forcément ce fichier.

Bonne action :

Ouvrir ou référencer le fichier pertinent.

Cas 2 : Fichiers ouverts non pertinents

Scénario :

Tu as ouvert :

new_payment_service.ts
old_payment_service.ts
experimental_payment_service.ts

Tu demandes :

Follow the existing payment service style.

Risque :

Copilot peut être influencé par le mauvais fichier.

Bonne action :

Fermer les fichiers non pertinents ou préciser explicitement la source de vérité.

Cas 3 : Données sensibles

Scénario :

Un développeur colle un log de production contenant des emails et tokens dans Copilot Chat.

Bonne réponse :

• ne pas envoyer de données sensibles ;
• anonymiser ou utiliser un extrait nettoyé ;
• respecter les policies de l’organisation.

Cas 4 : Content exclusions

Scénario :

Une organisation exclut un dossier contenant des secrets.

Question :

Copilot doit-il utiliser ce dossier comme contexte ?

Bonne réponse :

Non, si la fonctionnalité utilisée respecte les content exclusions configurées.
Mais il faut connaître les limites selon la surface Copilot.

Cas 5 : MCP

Scénario :

Une équipe veut que Copilot utilise un outil de ticketing interne.

Bonne réponse :

• configurer une intégration via MCP si disponible et autorisée ;
• contrôler les permissions ;
• éviter l’accès excessif.

Cas 6 : Copilot CLI

Scénario :

Copilot CLI demande si tu fais confiance au dossier courant.

Bonne réponse :

Il demande cela parce qu’il peut lire, modifier ou exécuter des fichiers dans ce dossier pendant la session.

Cas 7 : Suggestion incorrecte mais plausible

Scénario :

Copilot propose une commande cloud inexistante.

Bonne réponse :

• traiter cela comme une hallucination possible ;
• vérifier dans la documentation officielle ;
• ne pas exécuter aveuglément.