Flux de travail IA fiable avec GitHub Copilot : guide complet avec exemples

Bonjour ! Aujourd'hui, je partage un guide rapide sur la façon de configurer un projet pour travailler avec GitHub Copilot.

Flux de travail IA fiable avec GitHub Copilot : guide complet avec exemples

Ce guide montre comment créer des processus IA (flux de travail) prévisibles et reproductibles dans votre référentiel et votre IDE/CLI à l'aide de primitives d'agent et d'ingénierie de contexte. Vous y trouverez la structure des fichiers, des modèles prêts à l'emploi, des règles de sécurité et des commandes.

⚠️ Remarque : les fonctionnalités des fichiers de prompts et du mode agent dans l'IDE/CLI peuvent changer - adaptez le guide aux versions spécifiques de Copilot et VS Code que vous utilisez.

1) Aperçu : de quoi se compose un flux de travail

L'objectif principal est de décomposer le travail de l'agent en étapes transparentes et de le rendre contrôlable. Pour cela, il existe les outils suivants :

• Instructions personnalisées (.github/copilot-instructions.md) — règles globales du projet (comment compiler, comment tester, style de code, politiques de PR).
• Instructions spécifiques au chemin (.github/instructions/*.instructions.md) — règles pour des domaines spécifiques, appliquées via applyTo (glob-patterns).
• Modes de discussion (.github/chatmodes/*.chatmode.md) — modes de discussion spécialisés (par exemple, Plan/Frontend/DBA) avec des outils et un modèle fixes.
• Fichiers de prompts (.github/prompts/*.prompt.md) — scénarios/"programmes" réutilisables pour des tâches typiques (revue, refactoring, génération).
• Aide au contexte (docs/*.spec.md, docs/*.context.md, docs/*.memory.md) — spécifications, références et mémoire du projet pour un contexte précis.
• Serveurs MCP (.vscode/mcp.json ou via UI) — outils et ressources externes que l'agent peut utiliser.

2) Structure des fichiers du projet

La structure suivante correspond aux outils décrits ci-dessus et aide à construire un flux de travail complet pour les agents.

1.github/
2  copilot-instructions.md
3  instructions/
4    backend.instructions.md
5    frontend.instructions.md
6    actions.instructions.md
7  prompts/
8    implement-from-spec.prompt.md
9    security-review.prompt.md
10    refactor-slice.prompt.md
11    test-gen.prompt.md
12  chatmodes/
13    plan.chatmode.md
14    frontend.chatmode.md
15.vscode/
16  mcp.json
17docs/
18  feature.spec.md
19  project.context.md
20  project.memory.md

3) Fichiers et leur rôle — explication technique

Examinons maintenant chaque outil séparément et son rôle. Vous trouverez ci-dessous une explication du fonctionnement interne : ce que sont ces fichiers, pourquoi ils existent, comment ils influencent la compréhension des tâches par l'agent et dans quel ordre ils sont combinés / remplacés. Les exemples de code ci-dessous correspondent aux spécifications.

Ordre de combinaison des règles et des paramètres : Frontmatter du prompt → Mode de discussion → Instructions Repo/Chemin → Valeurs par défaut.

Et maintenant, examinons chaque outil séparément.

3.1. Règles globales — .github/copilot-instructions.md

Qu'est-ce que c'est : Un fichier Markdown avec des règles courtes et vérifiables : comment compiler, comment tester, style de code et politiques de PR.

Pourquoi : Pour que toutes les réponses s'appuient sur un ensemble de normes unifiées (sans duplication dans chaque prompt).

Comment ça marche : Le fichier devient automatiquement le contexte système pour toutes les requêtes dans le référentiel. Il n'y a pas de applyTo (cela vient plus bas) — il s'applique partout.

Exemple minimal :

1# Normes de codage du référentiel
2- Compilation : `npm ci && npm run build`
3- Tests : `npm run test` (couverture ≥ 80 %)
4- Lint/Vérification de type : `npm run lint && npm run typecheck`
5- Commits : Conventional Commits ; garder les PR petits et ciblés
6- Docs : mettre à jour `CHANGELOG.md` dans chaque PR de release

Conseils.

1. Gardez les points courts.
2. Évitez les phrases générales.
3. Incluez uniquement ce qui peut affecter le résultat (build/test/lint/type/politique de PR).

3.2. Instructions spécifiques au chemin — .github/instructions/*.instructions.md

Qu'est-ce que c'est : Règles modulaires avec frontmatter YAML applyTo — glob-patterns de fichiers pour lesquels elles s'appliquent.

Pourquoi : Pour différencier les normes dans différentes zones (frontend/backend/CI). Permet de contrôler le contexte en fonction du type de tâche.

Comment ça marche : Lors du traitement d'une tâche, Copilot trouve tous les *.instructions.md dont applyTo correspond au contexte actuel (fichiers que vous discutez/modifiez). Les règles correspondantes s'ajoutent aux règles globales.

Exemple :

1---
2applyTo: "apps/web/**/*.{ts,tsx},packages/ui/**/*.{ts,tsx}"
3---
4- React : composants fonctionnels et hooks
5- État : Zustand ; récupération de données avec TanStack Query
6- Style : Tailwind CSS ; éviter les styles en ligne sauf cas dynamiques
7- Tests : Vitest + Testing Library ; éviter les snapshots instables

Remarque.

1. Évitez de dupliquer les règles globales existantes.
2. Assurez-vous que le glob cible bien les bons chemins.

3.3. Modes de discussion — .github/chatmodes/*.chatmode.md

Qu'est-ce que c'est : Fichiers de configuration qui définissent le mode de fonctionnement de l'agent pour le dialogue : description courte, modèle (si nécessaire) et liste des outils autorisés.

Pourquoi : Pour séparer les phases de travail (planification/frontend/DBA/sécurité) et restreindre les outils à chaque étape. Cela rend les résultats plus prévisibles.

Structure du fichier :

1---
2description: "Plan - analyser le code/les spécifications et proposer un plan ; outils en lecture seule"
3model: GPT-4o
4tools:[ "search/codebase"]
5---
6Dans ce mode :
7- Produire un plan structuré avec les risques et les inconnues
8- Ne pas modifier les fichiers ; afficher une liste de tâches concise à la place

Comment ça marche :

• Le mode de discussion s'applique au chat actuel dans l'IDE.
• Si vous activez un fichier de prompt, son frontmatter a la priorité sur le mode de discussion (peut changer le modèle et restreindre les tools).
• La liste effective des outils autorisés : outils du mode de discussion, restreints par les outils du prompt et les flags CLI --allow/--deny.

Gestion et basculement :

• Dans l'IDE (VS Code) :

1. Ouvrez le panneau Copilot Chat.
2. Dans la ligne supérieure, sélectionnez le mode de discussion souhaité dans la liste déroulante (la liste est construite à partir de .github/chatmodes/*.chatmode.md + modes intégrés).
3. Le mode s'applique uniquement à cette branche de discussion. Pour changer, sélectionnez-en un autre ou créez une nouvelle branche avec le mode souhaité.
4. Vérifiez le mode actif dans l'en-tête/panneau de conversation ; dans References, vous verrez le fichier *.chatmode.md.

• En CLI : (un peu hacky, mieux vaut passer par les prompts)

  • Il n'y a généralement pas de flag CLI spécial pour basculer les modes ; encodez les restrictions souhaitées dans le frontmatter du fichier de prompt et/ou via les flags --allow-tool/--deny-tool.
  • Vous pouvez indiquer dans la première ligne : «Utiliser le mode de discussion i18n.» — si la version le prend en charge, l'agent peut basculer ; sinon, le frontmatter du prompt appliquera quand même les restrictions d'outils.

• Sans basculement de mode : lancez un prompt avec les tools: souhaités dans le frontmatter — cela restreindra les outils indépendamment du mode de discussion.

Diagnostic : si l'agent utilise des outils "superflus" ou n'en voit pas de nécessaires — vérifiez : (1) quel mode de discussion est sélectionné ; (2) tools dans le frontmatter du prompt ; (3) flags CLI --allow/--deny ; (4) References dans la réponse (fichiers *.chatmode.md/*.prompt.md visibles).

3.4. Fichiers de prompts — .github/prompts/*.prompt.md

Qu'est-ce que c'est : Fichiers de scénarios pour des tâches réutilisables. Ils se composent d'un frontmatter YAML (configuration) et d'un corps (instructions/étapes/critères d'acceptation). Ils sont appelés dans le chat via /nom ou via la CLI.

Quand utiliser : Lorsque un processus prévisible et automatisable est nécessaire : revue de PR, génération de tests, implémentation d'une fonction selon une spécification, etc.

Structure du frontmatter

• description — objectif court du scénario.
• mode — ask (Q&R, sans modification de fichiers) · edit (modification locale des fichiers ouverts) · agent (processus multi-étapes avec outils).
• model — profil de modèle souhaité.
• tools — liste des outils autorisés pour le scénario (restreint même ce qui est autorisé par le mode de discussion).

Algorithme d'exécution (séquence)

1. Où exécuter :

• Dans le chat : tapez /nom-du-prompt et les arguments dans le champ de message.
• En CLI : appelez copilot et transmettez la chaîne /nom-du-prompt … (interactivement ou via heredoc / flag -p).

2. Collecte du contexte : Copilot construit le contexte d'exécution dans l'ordre suivant : instructions-repo → instructions-chemin (applyTo) → mode de discussion → frontmatter du prompt (le frontmatter du prompt a la priorité la plus élevée et peut restreindre les outils/changer le modèle).

3. Analyse des paramètres (où et comment) :

   • Dans le chat : les paramètres suivent dans le même message après le nom, par exemple : /security-review prNumber=123 target=apps/web.
   • En CLI : les paramètres suivent dans la même chaîne /… en stdin ou après le flag -p.
   • Dans le fichier de prompt, ils sont accessibles comme ${input:nom}. Si un paramètre obligatoire est manquant, le prompt peut le demander par texte dans la conversation.

4. Résolution des autorisations pour les outils :

• La liste effective des outils autorisés : outils du mode de discussion, restreints par les outils du prompt et les flags CLI --allow/--deny.
• Si un outil est interdit, l'étape correspondante est sautée ou nécessite une confirmation / un changement de politique.

5. Exécution des étapes du corps du prompt : l'agent suit strictement l'ordre des étapes, n'exécutant que ce qui est autorisé par les politiques/outils (recherche dans la base de code, génération de diff, exécution de tests, etc.). Pour les actions potentiellement risquées, il demande confirmation.

6. Portes de validation : à la fin, le prompt lance des vérifications (build/tests/lint/typecheck). Si une vérification échoue, l'agent renvoie la liste des problèmes et propose des étapes supplémentaires (sans fusion/enregistrement automatique des modifications).

7. Où apparaît le résultat (ce qui est visible et où) :

• Réponse principale — dans le panneau de chat (IDE) ou dans stdout (CLI) : tableaux, listes, rapports textuels, blocs de code avec diff.
• Modifications de fichiers — dans votre espace de travail : dans l'IDE, les diff/patches proposés sont visibles ; en CLI, les fichiers sont modifiés localement (si autorisé par les outils).
• Artefacts supplémentaires — par exemple, un commentaire sur un PR, si les outils GitHub sont autorisés et que le prompt l'indique.

Format de sortie et vérifications (recommandations)

• Indiquez toujours le format de sortie (par exemple, tableau "issue | file | line | severity | fix").
• Ajoutez des portes de validation : build/tests/lint/typecheck ; exigez un unified-diff pour les modifications proposées ; une liste de TODO pour les questions non résolues.

Exemple de fichier de prompt complet

1---
2mode: 'agent'
3model: GPT-4o
4tools: ['search/codebase']
5description: 'Implémenter une fonctionnalité à partir d'une spécification'
6---
7Objectif : Implémenter la fonctionnalité décrite dans @docs/feature.spec.md.
8
9Étapes :
101) Lire @docs/feature.spec.md et produire un court plan d'implémentation (puces)
112) Lister les fichiers à ajouter/modifier avec les chemins
123) Proposer des patches de code sous forme de diff unifié ; demander avant d'installer de nouvelles dépendances
134) Générer des tests minimaux et les exécuter (rapporter les résultats)
14
15Portes de validation :
16- Build, tests, lint/typecheck doivent passer
17- La sortie inclut le diff final et une liste TODO pour tout ce qui est différé
18- Si une porte échoue, renvoyer un plan de remédiation au lieu de "fait"

Anti-modèles

• Descriptions floues : gardez le description en 1-2 lignes.
• Format de sortie absent.
• Trop d'outils : n'autorisez que ceux nécessaires (tools).

Démarrage rapide

• Chat : /implement-from-spec
• CLI : copilot <<<'/implement-from-spec' ou copilot -p "Exécuter /implement-from-spec"

3.5. Fichiers de contexte — specs/context/memory

Qu'est-ce que c'est : Fichiers Markdown auxiliaires (pas de types spéciaux) que vous mentionnez via @ dans la conversation/prompt. Ils sont généralement stockés comme documentation.

• docs/*.spec.md — définitions précises des tâches (objectif, critères d'acceptation, cas extrêmes, non-objectifs).
• docs/*.context.md — références courtes (politiques d'API, sécurité, guide de style UI, SLA).
• docs/*.memory.md — "journal des décisions" avec dates et justifications, pour que l'agent ne revienne pas sur des questions déjà résolues.

Exemple :

1# Fonctionnalité : Exporter le rapport en CSV
2Objectif : Les utilisateurs peuvent exporter le tableau filtré en CSV.
3Critères d'acceptation :
4- Bouton "Exporter CSV" sur /reports
5- Le serveur génère le fichier en ≤ 5s pour 10k lignes
6- Ordre des colonnes/en-têtes correspondant à l'UI ; valeurs indépendantes de la locale
7Cas extrêmes : valeurs vides, grands nombres, caractères spéciaux
8Non-objectifs : XLSX, filtres simultanés multi-colonnes

3.6. MCP — .vscode/mcp.json

Qu'est-ce que c'est : Configuration des serveurs Model Context Protocol (par exemple, GitHub MCP) qui fournissent des outils à l'agent.

Pourquoi : Pour que l'agent puisse lire les PR/issues, exécuter des tests, interagir avec la DB/le navigateur — dans la limite des autorisations accordées.

Exemple :

1{
2  "servers": {
3    "github-mcp": {
4      "type": "http",
5      "url": "https://api.githubcopilot.com/mcp"
6    }
7  }
8}

Sécurité. N'utilisez que des serveurs approuvés ; utilisez les listes allow/deny d'outils dans les prompts/modes de discussion/CLI.

3.7. Ordre général de combinaison du contexte et priorités (règles & outils)

1. Instructions : copilot-instructions + tous les *.instructions.md avec applyTo correspondant aux chemins actuels. L'instruction spécifique s'ajoute au contexte général.
2. Mode de discussion : restreint l'ensemble des outils et (si nécessaire) le modèle pour la session.
3. Frontmatter du prompt : a la priorité la plus élevée ; peut restreindre les outils et remplacer le modèle.
4. Contexte : tout ce que vous mentionnez via @ est garanti d'être pris en compte par le modèle.

Diagnostic. Vérifiez la section References dans les sorties — elle indique quels fichiers d'instructions ont été pris en compte et quel prompt a été exécuté.

3.8. Exemple : cycle complet i18n avec Goman MCP (création/mise à jour/suppression)

Ci-dessous, le processus exact et les modèles pour assurer ce qui suit : (a) lors de la création de composants UI, les clés de localisation sont créées/mises à jour dans Goman ; (b) lors de la suppression de composants, les entrées inutilisées sont détectées et (après confirmation) supprimées.

Les extraits de code et le frontmatter sont en anglais.

3.8.1. Configuration MCP — connexion de Goman

/.vscode/mcp.json

1{
2  "servers": {
3    "goman-mcp": {
4      "type": "http",
5      "url": "https://mcp.goman.live/mcp",
6      "headers": {
7        "apiKey": "<VOTRE_CLE_API>",
8        "applicationid": "<VOTRE_ID_APPLICATION>"
9      }
10    }
11  }
12}

3.8.2. Règles Repo/Chemin — forçage de l'i18n par défaut

/.github/instructions/frontend.instructions.md (ajout)

1---
2applyTo: "apps/web/**/*.{ts,tsx}"
3---
4- Toutes les chaînes destinées à l'utilisateur **doivent** utiliser des clés i18n (pas de texte codé en dur en JSX/TSX).
5- Nommage des clés : `<zone_composant_ui>.<numéro>` (ex: `ui_button_primary.label`)
6- Lors de la création de composants, exécutez `/i18n-component-scaffold` et commitez le code et les clés créées.
7- Lors de la suppression de composants, exécutez `/i18n-prune` et confirmez la suppression des clés inutilisées.

3.8.3. Mode de discussion — outils i18n restreints

/.github/chatmodes/i18n.chatmode.md

1---
2description: "i18n - gestion des clés de localisation via Goman MCP ; forcer l'absence de chaînes codées en dur"
3model: GPT-4o
4tools:
5  - "files"
6  - "goman-mcp:*"
7---
8Dans ce mode, privilégier :
9- La création/mise à jour de clés dans Goman avant d'écrire le code
10- La vérification de clés existantes et leur réutilisation
11- La production d'un tableau des modifications (créées/mises à jour/ignorées)

3.8.4. Prompt — scaffolding de composant + clés dans Goman

/.github/prompts/i18n-component-scaffold.prompt.md

1---
2mode: 'agent'
3model: GPT-4o
4tools: ['files','goman-mcp:*']
5description: 'Scaffolding d'un composant React avec synchronisation des clés i18n vers Goman'
6---
7Inputs : nom du composant, namespace (ex: `ui.button`), chemin (ex: `apps/web/src/components`)
8
9Objectif : Créer un composant React et s'assurer que toutes les chaînes visibles par l'utilisateur utilisent des clés i18n stockées dans Goman.
10
11Étapes :
121) Planifier la structure du composant et lister toutes les chaînes visibles par l'utilisateur
132) Pour chaque chaîne, proposer une clé sous `${namespace}` ; réutiliser si elle existe
143) Utiliser Goman MCP pour créer/mettre à jour les traductions pour les langues : en, be, ru (les valeurs peuvent être des placeholders)
154) Générer le composant en utilisant `t('<clé>')` et l'exporter ; ajouter un test basique
165) Afficher un tableau Markdown : clé | en | be | ru | action (créé/mis à jour/réutilisé)
17
18Portes de validation :
19- Pas de littéraux codés en dur dans le .tsx produit
20- Confirmer que les actions Goman ont réussi (rapporter les réponses des outils)
21- Les tests et la vérification de type réussissent

Exemple de code de composant :

1import { t } from '@/i18n';
2import React from 'react';
3
4type Props = { onClick?: () => void };
5
6export function PrimaryButton({ onClick }: Props) {
7  return (
8    <button aria-label={t('ui.button.primary.aria')} onClick={onClick}>
9      {t('ui.button.primary.label')}
10    </button>
11  );
12}

3.8.5. Prompt — suppression des clés inutilisées lors de la suppression de composants

/.github/prompts/i18n-prune.prompt.md

1---
2mode: 'agent'
3model: GPT-4o
4tools: ['files','goman-mcp:*']
5description: 'Trouver et supprimer les clés de localisation inutilisées dans Goman après suppression de code'
6---
7Inputs : chemin/diff (ex: un chemin de composant supprimé ou un numéro de PR)
8
9Objectif : Détecter les clés qui ne sont plus référencées dans la base de code et les supprimer de Goman après confirmation.
10
11Étapes :
121) Calculer l'ensemble des éléments UI supprimés/renommés (scanner le diff git ou les chemins fournis)
132) Inférer les clés candidates par namespace (ex: `ui.<composant>.*`) et vérifier les références dans le code
143) Pour les clés n'ayant **aucune** référence, demander confirmation et les supprimer via Goman MCP
154) Afficher un tableau Markdown : clé | statut (conservé/supprimé) | raison | notes
16
17Portes de validation :
18- Ne jamais supprimer les clés qui ont encore des références
19- Exiger une confirmation explicite avant la suppression
20- Fournir une liste de récupération des clés supprimées

3.8.6. Prompt — synchronisation et vérification des traductions manquantes (facultatif)

/.github/prompts/i18n-sync.prompt.md

1---
2mode: 'agent'
3model: GPT-4o
4tools: ['files','goman-mcp:*']
5description: 'Synchroniser les clés i18n nouvelles/modifiées et vérifier les traductions manquantes'
6---
7Objectif : Comparer les références de code et Goman et combler les lacunes.
8
9Étapes :
101) Scanner le code pour les clés `t('...')` sous les namespaces fournis
112) Pour les clés manquantes dans Goman - les créer (texte placeholder ok)
123) Pour les langues manquantes - créer des placeholders et rapporter la couverture
134) Afficher un tableau de couverture : clé | en | be | de | manquant

4) Comment utiliser (IDE et CLI)

4.1. Dans VS Code / autre IDE

• Ouvrez Copilot Chat — sélectionnez Agent/Edit/Ask dans la liste déroulante.
• Pour les fichiers de prompts, tapez simplement /nom-fichier sans extension (par exemple, /security-review).
• Ajoutez du contexte via des mentions @ de fichiers et de répertoires.
• Basculez le mode de discussion (Plan/Frontend/DBA) lors du changement de type de tâche.

4.2. Dans Copilot CLI (terminal)

• Exemple d'installation : npm install -g @github/copilot → lancer copilot.
• Interactivement : « Exécuter /implement-from-spec sur @docs/feature.spec.md ».
• Par programme / en CI : copilot -p "Implémenter la fonctionnalité à partir de @docs/feature.spec.md" --deny-tool shell("rm*").
• Ajoutez / restreignez les outils via les flags : --allow-all-tools, --allow-tool, --deny-tool (globalement ou par pattern, par exemple shell(npm run test:*)).

4.3. Recettes de commandes pour CLI (modes de discussion et prompts)

Ci-dessous des recettes prêtes à l'emploi. Toutes les commandes doivent être exécutées depuis la racine du référentiel et respecter vos listes deny/allow.

A. Exécution d'un fichier de prompt en session interactive

1copilot
2# dans la session (tapez la ligne telle quelle)
3/security-review prNumber=123

B. Exécution d'un fichier de prompt en mode non interactif (heredoc)

1copilot <<'EOF'
2/security-review prNumber=123
3EOF

C. Passage de paramètres à un fichier de prompt

1copilot <<'EOF'
2/implement-from-spec path=@docs/feature.spec.md target=apps/web
3EOF

À l'intérieur du prompt, les valeurs peuvent être lues comme ${input:target} et ${input:path}.

D. Exécution d'un prompt avec droits d'outils sécurisés

1copilot --allow-tool "shell(npm run test:*)" \
2        --deny-tool  "shell(rm*)" \
3        <<'EOF'
4/security-review prNumber=123
5EOF

E. Utilisation du mode de discussion (mode spécialisé) en CLI

1copilot
2# dans la session — demandez de basculer vers le mode souhaité et d'exécuter le prompt
3Utilise le mode de discussion i18n.
4/i18n-component-scaffold componentName=PrimaryButton namespace=ui.button path=apps/web/src/components

Si votre client prend en charge la sélection du mode via un menu, sélectionnez i18n avant de lancer le prompt. Sinon, spécifiez les restrictions dans le frontmatter du prompt (tools et règles dans le corps du prompt).

F. Passage de références de fichiers/diff comme contexte

1copilot <<'EOF'
2Veuillez revoir ces modifications :
3@apps/web/src/components/PrimaryButton.tsx
4@docs/feature.spec.md
5/security-review prNumber=123
6EOF

G. Changement de modèle pour une exécution spécifique

Nous recommandons de spécifier le modèle dans le frontmatter du prompt. Si pris en charge, vous pouvez également passer un flag de modèle lors de l'exécution :

1copilot --model GPT-4o <<'EOF'
2/implement-from-spec
3EOF

H. Cycle i18n avec Goman MCP (CHAT)

Exécutez séquentiellement dans la même branche de chat :

1/i18n-component-scaffold componentName=PrimaryButton namespace=ui.button path=apps/web/src/components
2/i18n-prune pathOrDiff=@last-diff
3/i18n-sync namespace=ui.button

Ce que vous obtenez :

• tableaux/rapports finaux dans le panneau de chat ;
• modifications de code dans votre espace de travail (l'IDE affiche les diffs) ;
• il n'est pas nécessaire d'exécuter les commandes CLI pour Goman MCP ici.

5) Ingénierie de contexte : comment ne pas surcharger de contexte inutile

1. Séparez les sessions par phases : Plan → Implémentation → Revue/Tests. Chaque phase a son propre mode de discussion.
2. Joignez uniquement les instructions nécessaires : utilisez des *.instructions.md spécifiques au chemin au lieu de tout charger.
3. Mémoire du projet : enregistrez de courtes ADR dans project.memory.md — cela réduit "l'oubli" de l'agent entre les tâches.
4. Assistants contextuels : stockez les références fréquentes (API/sécurité/UI) dans *.context.md et référencez-les depuis les fichiers de prompts.
5. Focalisation sur la tâche : dans les fichiers de prompts, spécifiez toujours l'objectif, les étapes et le format de sortie (tableau, diff, checklist).

6) Sécurité et gestion des outils

• Exigez une confirmation explicite avant d'exécuter des commandes/outils. En CI, utilisez --deny-tool par défaut et ajoutez des listes allow locales.
• Patterns d'autorisations : n'autorisez que ce qui est nécessaire (shell(npm run test:*), playwright:*), interdisez les patterns dangereux (shell(rm*)).
• Secrets : ne placez pas de clés dans les prompts et les instructions ; utilisez les environnements GitHub ou les gestionnaires de secrets locaux et .env avec .gitignore.
• Tout MCP — uniquement à partir de sources fiables ; vérifiez le code/la configuration avant la connexion.
• Vérifications des patches : exigez des unified-diff et des explications dans les fichiers de prompts — cela simplifie la revue.

7) Recette CI/CD (exemple facultatif)

Assurez-vous que "tout compile" : lancez Copilot CLI en mode sécurisé pour générer un commentaire de PR.

1# .github/workflows/ai-review.yml
2name : Revue IA (Copilot CLI)
3on:
4  pull_request:
5    types: [opened, synchronize, reopened]
6
7jobs:
8  ai_review:
9    runs-on: ubuntu-latest
10    permissions:
11      contents: read
12      pull-requests: write
13    steps:
14      - uses: actions/checkout@v4
15      - uses: actions/setup-node@v4
16        with:
17          node-version: 22
18      - name: Installer Copilot CLI
19        run: npm install -g @github/copilot
20      - name: Exécuter le prompt de revue de sécurité (pas d'outils dangereux)
21        env:
22          PR: ${{ github.event.pull_request.number }}
23        run: |
24          copilot -p "Exécuter /security-review avec prNumber=${PR}" \
25            --deny-tool shell("rm*") --deny-tool shell("curl*") \
26            --allow-tool shell("npm run test:*") \
27            --allow-tool "github:*" \
28            > ai-review.txt || true
29      - name: Commenter le PR avec les résultats
30        if: always()
31        run: |
32          gh pr comment ${{ github.event.pull_request.number }} --body-file ai-review.txt

Conseil : gardez des listes deny/allow strictes ; ne donnez pas à l'agent une "liberté totale" en CI.

8) Petits scénarios et astuces utiles

• De l'idée au PR : /plan — discuter du plan — /implement-from-spec → tests locaux — PR — /security-review.
• Maintenance : /refactor-slice pour des améliorations locales sans changement de comportement.
• Tests : /test-gen pour de nouveaux modules + ajouts manuels pour les cas extrêmes.
• Introduction progressive : commencez avec 1 à 2 fichiers de prompts et un mode de discussion ; développez plus tard.

9) Vérifications de qualité (validation gates)

Dans chaque fichier de prompt, spécifiez "ce qui est considéré comme prêt" :

• Format de sortie : tableau des risques, unified-diff, checklist.
• Vérifications automatiques : build, tests unitaires/d'intégration, lint/typecheck.
• Vérification manuelle : "OK pour fusionner ?" avec justification et risques résiduels.

10) Anti-modèles et hacks

• Anti-modèle : un seul instructions.md énorme. Préférez plusieurs *.instructions.md avec applyTo.
• Anti-modèle : mots généraux au lieu de règles. Préférez des commandes/étapes spécifiques.
• Anti-modèle : exécution de commandes shell dangereuses sans vérification. Utilisez deny/allow et confirmation manuelle.
• Anti-modèle : spécifications/mémoire oubliées. Maintenez feature.spec.md et project.memory.md.
• Anti-modèle : mélange des tâches dans une même session. Créez un mode de discussion pour chaque phase.

11) Liste de contrôle de mise en œuvre

1. Ajoutez .github/copilot-instructions.md (au moins 5 à 8 points sur build/tests/style).
2. Créez 1 à 2 *.instructions.md avec applyTo (frontend/backend ou workflows).
3. Ajoutez plan.chatmode.md et un prompt (par exemple, implement-from-spec.prompt.md).
4. Créez docs/feature.spec.md et docs/project.memory.md.
5. Connectez le MCP (au moins GitHub MCP) via .vscode/mcp.json.
6. Lancez le flux de travail dans VS Code : /implement-from-spec — vérifiez — PR.
7. (Facultatif) Ajoutez une revue IA simple en CI via Copilot CLI avec des listes deny/allow strictes.

12) Questions et réponses (FAQ)

Q : Comment m'assurer que Copilot "voit" mes instructions ? R : Vérifiez le résumé/Références dans la réponse ; gardez également les règles courtes et spécifiques.

Q : Est-il possible de passer des paramètres dynamiquement aux fichiers de prompts ? R : Oui, généralement via des variables d'espace réservé (comme ${prNumber}) ou simplement via une requête textuelle lors de l'exécution de /prompt dans le chat.

Q : Où stocker les secrets pour MCP ? R : Dans les environnements GitHub ou les gestionnaires de secrets locaux ; pas dans .prompt.md/.instructions.md.

Q : Que choisir : Chat Mode ou Prompt File ? R : Le Chat Mode définit le "cadre" (modèle/outils/rôle). Le Prompt File est le "scénario" à l'intérieur de ce cadre.

13) Prochaines étapes

• Ajoutez un deuxième prompt pour votre processus manuel le plus fréquent.
• Rendez project.memory.md obligatoire après toutes les décisions architecturales.
• Déplacez progressivement les connaissances collectives vers *.context.md et référez-vous-y depuis les fichiers de prompts.

Annexe A — Modèles de démarrage rapide

Toutes les clés, chemins et flags correspondent à la documentation (28 octobre 2025).

/.github/copilot-instructions.md — règles pour tout le référentiel

1# Normes de codage du référentiel
2- Compilation : `npm ci && npm run build`
3- Tests : `npm run test` (couverture ≥ 80 %)
4- Lint/Vérification de type : `npm run lint && npm run typecheck`
5- Commits : Conventional Commits ; garder les PR petits et ciblés
6- Docs : mettre à jour `CHANGELOG.md` dans chaque PR de release

/.github/instructions/frontend.instructions.md — instructions spécifiques au chemin

1---
2applyTo: "apps/web/**/*.{ts,tsx},packages/ui/**/*.{ts,tsx}"
3---
4- React : composants fonctionnels et hooks
5- État : Zustand ; récupération de données avec TanStack Query
6- Style : Tailwind CSS ; éviter les styles en ligne sauf cas dynamiques
7- Tests : Vitest + Testing Library ; éviter les snapshots instables

/.github/instructions/backend.instructions.md — instructions spécifiques au chemin

1---
2applyTo: "services/api/**/*.{ts,js},packages/server/**/*.{ts,js}"
3---
4- HTTP : Fastify ; versionner les API sous `/v{N}`
5- Accès DB : Prisma ; migrations via `prisma migrate`
6- Sécurité : validation de schéma (Zod), limites de taux, journaux d'audit
7- Tests : tests d'intégration via `vitest --config vitest.integration.ts`

/.github/instructions/actions.instructions.md — GitHub Actions

1---
2applyTo: ".github/workflows/**/*.yml"
3---
4- Garder les jobs petits ; réutiliser via des actions composites
5- Cache : `actions/setup-node` + cache intégré pour npm/pnpm
6- Secrets : uniquement via les environnements GitHub ; jamais codé en dur

/.github/chatmodes/plan.chatmode.md — mode de discussion personnalisé

1---
2description: "Plan - analyser le code/les spécifications et proposer un plan ; outils en lecture seule"
3model: GPT-4o
4tools:
5  - "search/codebase"
6---
7Dans ce mode :
8- Produire un plan structuré avec les risques et les inconnues
9- Ne pas modifier les fichiers ; afficher une liste de tâches concise à la place

/.github/prompts/security-review.prompt.md — fichier de prompt

1---
2mode: 'agent'
3model: GPT-4o
4tools: ['search/codebase']
5description: 'Effectuer une revue de sécurité d'une pull request'
6---
7Objectif : Examiner le PR ${input:prNumber} pour les problèmes de sécurité courants.
8
9Checklist :
10- Couverture authentification/autorisation
11- Validation des entrées et encodage des sorties (XSS/SQLi)
12- Gestion des secrets et configuration
13- Versions des dépendances et CVE connus
14
15Sortie :
16- Un tableau Markdown : problème | fichier | ligne | sévérité | correction
17- Si trivial, inclure une suggestion de diff unifié

/.github/prompts/implement-from-spec.prompt.md — fichier de prompt

1---
2mode: 'agent'
3model: GPT-4o
4tools: ['search/codebase']
5description: 'Implémenter une fonctionnalité à partir d'une spécification'
6---
7Votre tâche est d'implémenter la fonctionnalité décrite dans @docs/feature.spec.md.
8
9Étapes :
101) Lire @docs/feature.spec.md et résumer le plan
112) Lister les fichiers à ajouter ou modifier
123) Proposer des modifications de code ; demander avant d'installer de nouvelles dépendances
134) Générer des tests minimaux et les exécuter
14
15Portes de validation :
16- Build, tests, lint/typecheck doivent passer
17- Fournir une liste TODO pour tout ce qui est différé

/.github/prompts/refactor-slice.prompt.md — fichier de prompt

1---
2mode: 'agent'
3model: GPT-4o
4description: 'Refactoriser une tranche de code spécifique sans changer le comportement'
5---
6Objectif : Améliorer la lisibilité et réduire les effets secondaires dans @src/feature/* tout en conservant le comportement inchangé.
7Critères : moins d'effets secondaires, structure plus claire, tous les tests passent.

/.github/prompts/test-gen.prompt.md — fichier de prompt

1---
2mode: 'agent'
3model: GPT-4o-mini
4description: 'Générer des tests pour un fichier/module donné'
5---
6Demander à l'utilisateur de mentionner @ le fichier cible ; générer des tests unitaires/d'intégration et des cas extrêmes.

/docs/feature.spec.md — modèle de spécification

1# Fonctionnalité : Exporter le rapport en CSV
2Objectif : Les utilisateurs peuvent exporter le tableau filtré en CSV.
3Critères d'acceptation :
4- Bouton "Exporter CSV" sur /reports
5- Le serveur génère le fichier en ≤ 5s pour 10k lignes
6- Ordre des colonnes/en-têtes correspondant à l'UI ; valeurs indépendantes de la locale
7Cas extrêmes : valeurs vides, grands nombres, caractères spéciaux
8Non-objectifs : XLSX, filtres simultanés multi-colonnes

/.vscode/mcp.json — configuration MCP minimale

1{
2  "servers": {
3    "github-mcp": {
4      "type": "http",
5      "url": "https://api.githubcopilot.com/mcp"
6    }
7  }
8}

Annexe B — Compléments opérationnels (exemples CLI & CI)

Ces exemples complètent l'Annexe A ; ils décrivent l'utilisation dans le cadre de l'exécution / automatisation et ne dupliquent pas les modèles ci-dessus.

Copilot CLI — droits d'outils sécurisés (interactif / CI)

1# Lancement d'une session interactive dans votre référentiel
2copilot
3
4# Autoriser/interdire des outils spécifiques (flags exacts selon la documentation GitHub)
5copilot --allow-tool "shell(npm run test:*)" --deny-tool "shell(rm*)"
6
7# Lancement d'un fichier de prompt en mode non interactif (exemple)
8copilot <<'EOF'
9/security-review prNumber=123
10EOF

GitHub Actions — commentaire des résultats de revue dans un PR

1name: Revue IA de Sécurité (Copilot CLI)
2on:
3  pull_request:
4    types: [opened, synchronize, reopened]
5
6jobs:
7  review:
8    runs-on: ubuntu-latest
9    permissions:
10      contents: read
11      pull-requests: write
12    steps:
13      - uses: actions/checkout@v4
14      - uses: actions/setup-node@v4
15        with:
16          node-version: 22
17      - name: Installer Copilot CLI
18        run: npm install -g @github/copilot
19      - name: Exécuter le prompt de revue de sécurité
20        env:
21          PR: ${{ github.event.pull_request.number }}
22        run: |
23          copilot --allow-tool "shell(npm run test:*)" --deny-tool "shell(rm*)" <<'EOF'
24          /security-review prNumber=${PR}
25          EOF
26      - name: Poster les résultats
27        run: |
28          gh pr comment ${{ github.event.pull_request.number }} --body "Revue Copilot terminée. Voir les artefacts/logs pour plus de détails."

14) Configuration du contexte sur un projet existant

Cette section résout un problème spécifique : vous prenez un projet déjà en cours et en une seule fois, vous créez un contexte et des instructions complets pour GitHub Copilot. Nous n'inventons rien — tout est tiré de ce qui existe déjà dans le code.

Chaque étape est un prompt exécuté dans VS Code en mode Agent. Chaque étape suivante dépend du résultat de la précédente, donc l'ordre est important.

14.1. Étape 1 — Audit du projet

Objectif : obtenir une carte objective du projet. Sans cela, tout le reste est une supposition.

Ce que nous faisons : ouvrons Copilot Chat, sélectionnons le mode Agent, attachons le dossier racine via @, et lançons :

1@/
2
3Analysez la structure de ce projet. Déterminez :
4
5- stack : langage, frameworks, gestionnaire de paquets
6- commandes de build, test, lint (exactes, depuis package.json / pom.xml / Makefile, etc.)
7- flux de travail CI existants (.github/workflows) — qu'est-ce qui y est exécuté
8- dossiers principaux et leur rôle
9- configurations existantes : lint, prettier, typescript, et similaires
10
11Retournez le résultat sous forme de liste structurée.
12Ne supposez pas — seulement ce qui est réellement visible dans les fichiers.

Résultat : sauvegardez la réponse — elle sera nécessaire à l'étape 2. C'est la "carte initiale", la qualité de tout ce qui suit en dépend.

14.2. Étape 2 — Génération des instructions globales

Objectif : créer .github/copilot-instructions.md — une source unique de règles pour tout le référentiel.

Ce que nous faisons : prenons le résultat de l'étape 1 et lançons :

1Sur la base de cet audit de projet :
2
3[insérer le résultat de l'étape 1]
4
5Créez le fichier .github/copilot-instructions.md
6
7Exigences :
8- uniquement des faits de l'audit, rien d'inventé
9- commandes de build, test, lint — exactes, copiées des configurations
10- style de code — uniquement s'il existe une configuration prettier/eslint, et uniquement ce qui y est fixé
11- politique de commit — uniquement s'il existe commitlint ou un analogue
12- 8 à 12 points maximum
13- chaque point — une ligne spécifique

Résultat : le fichier .github/copilot-instructions.md est créé et enregistré dans l'espace de travail.

14.3. Étape 3 — Génération des instructions spécifiques au chemin

Objectif : créer des règles distinctes pour différentes zones de code, qui s'activent automatiquement par pattern de chemin.

Quand c'est nécessaire : si le projet a au moins deux zones logiquement distinctes — frontend et backend, apps et packages, plusieurs services. Si le projet est homogène — cette étape est sautée.

Ce que nous faisons : pour chaque zone, nous attachons le dossier correspondant et lançons un prompt séparé. Exemple pour le frontend :

1@src/components/
2@src/pages/
3
4Analysez cette partie du projet et déterminez :
5
6- quel framework et comment les composants sont écrits
7- patterns de gestion d'état (si visibles)
8- comment les tests sont organisés (s'il y en a)
9- style des imports et des noms de fichiers
10
11Créez le fichier .github/instructions/frontend.instructions.md
12
13Exigences :
14- applyTo — un glob exact, couvrant uniquement ces dossiers
15- règles — uniquement à partir de ce que vous voyez dans le code
16- ne duplique pas ce qui existe déjà dans copilot-instructions.md
17- pas plus de 6 à 8 points

Un prompt similaire pour le backend, s'il existe, avec les dossiers correspondants dans @.

Résultat : fichiers dans .github/instructions/ pour chaque zone.

14.4. Étape 4 — Génération du guide du projet

Objectif : créer docs/project.context.md — un guide stable qui réduit le "bruit" dans les conversations et ne nécessite pas de mise à jour à chaque changement.

Ce que nous faisons :

1@/
2@README.md
3@package.json
4
5Créez le fichier docs/project.context.md —
6c'est un guide du projet pour l'assistant IA.
7
8Inclure :
9- description courte : ce que fait le projet, pour qui
10- patterns d'architecture clés, s'ils sont visibles dans la structure des dossiers et les imports
11- dépendances externes et leurs rôles (pourquoi celles-ci, si c'est clair dans le contexte)
12- ce qu'il ne faut PAS faire : dossiers dépréciés, patterns encombrants, limitations connues
13
14Limitations :
15- 30 à 40 lignes maximum
16- uniquement ce qui est objectivement visible dans le projet
17- sans hypothèses ni recommandations

Résultat : fichier docs/project.context.md.

14.5. Étape 5 — Génération de la mémoire du projet

Objectif : enregistrer les décisions qui ont déjà été prises, pour que l'agent n'y revienne pas.

Ce que nous faisons :

1@/
2
3Examinez le projet et trouvez les décisions qui ont déjà été enregistrées dans le code :
4
5- choix des bibliothèques — si des alternatives évidentes sont visibles dans les fichiers de verrouillage ou les commentaires
6- structure des dossiers — si elle est non standard pour ce stack
7- tout TODO ou FIXME ayant un contexte expliquant pourquoi
8- configurations ayant des commentaires avec justification
9
10Créez le fichier docs/project.memory.md au format :
11
12## [date ou "inconnu"] | Décision | Pourquoi
13
14Chaque entrée — maximum 2 lignes.
15Pas plus de 10 à 12 entrées.
16Uniquement ce qui est réellement visible.

Résultat : fichier docs/project.memory.md.

14.6. Étape 6 — Premier fichier de prompt

Objectif : créer un prompt de travail pour la tâche la plus fréquente. Pas besoin des cinq des modèles tout de suite — on commence par un et on ajoute au besoin.

Quand quel prompt : si l'équipe implémente plus souvent de nouvelles fonctionnalités — on prend implement-from-spec. Si elle revoit plus souvent des PR — on prend security-review. On choisit ce qui est utilisé quotidiennement.

Ce que nous faisons (exemple pour implement-from-spec) :

1@.github/copilot-instructions.md
2
3Créez le fichier .github/prompts/implement-from-spec.prompt.md
4pour ce projet.
5
6Exigences :
7- mode : agent
8- tools : uniquement search/codebase
9- les étapes doivent utiliser les commandes de build et de test
10  de copilot-instructions.md
11- validation gates : build, tests, lint doivent passer
12- description — une ligne

Résultat : fichier .github/prompts/implement-from-spec.prompt.md, adapté à la pile technologique spécifique du projet.

14.7. Résultat et prochaines étapes

Après ces six étapes, le référentiel contiendra :

1.github/
2  copilot-instructions.md          ← règles globales (étape 2)
3  instructions/
4    frontend.instructions.md       ← règles pour frontend (étape 3)
5    backend.instructions.md        ← règles pour backend (étape 3)
6  prompts/
7    implement-from-spec.prompt.md  ← premier prompt (étape 6)
8docs/
9  project.context.md               ← guide du projet (étape 4)
10  project.memory.md                ← mémoire des décisions (étape 5)

C'est un ensemble minimal fonctionnel. Ensuite, itérativement :

• ajoutez des fichiers de prompts au fur et à mesure que de nouvelles tâches typiques apparaissent
• mettez à jour project.memory.md après chaque décision architecturale
• ajoutez des modes de discussion lorsque vous commencez à remarquer que différentes phases de travail se gênent mutuellement
• connectez les MCP uniquement après que le contexte de base fonctionne

Tout ce qui est décrit ci-dessus tient dans une seule session de travail. Chaque prompt peut être lancé séquentiellement, sans changer manuellement de fichiers — l'agent créera lui-même les fichiers dans l'espace de travail.

Sources

Modes de discussion personnalisés dans VS Code

Utilisation des serveurs MCP dans VS Code

Ajout d'instructions de référentiel personnalisées pour GitHub Copilot

Comment construire des flux de travail IA fiables avec des primitives d'agent et de l'ingénierie de contexte

🙌 PS :

Merci d'avoir lu jusqu'à la fin ! Si le matériel vous a semblé utile, nous serions ravis si vous :

Les technologies deviennent plus accessibles lorsqu'elles sont comprises. Et vous avez déjà fait le premier pas important 💪