Copilot Memory vs instructions personnalisées : où sont stockées les mémoires et comment les supprimer
GitHub Copilot Memory est une mémoire hébergée par GitHub et limitée à un seul dépôt, actuellement en aperçu public — et ce n'est pas le dossier que vous avez peut-être trouvé sur votre disque. Ce guide montre où est stockée chaque sorte de mémoire, comment la consulter et la supprimer, comment activer ou désactiver la version cloud pour vous-même et pour une organisation, et fournit un modèle d'instructions personnalisées à copier-coller pour les règles que les mémoires ne doivent jamais remplacer. Douze étapes, recoupées avec docs.github.com et la documentation mémoire de VS Code.
L'essentiel
- Les mémoires ne sont pas un dossier dans votre dépôt. GitHub Copilot Memory est une mémoire stockée par GitHub et limitée à un seul dépôt ; vous la consultez et la supprimez dans Repository → Settings → Code & automation → Copilot → Memory. Le dossier de mémoire que l'on trouve sur le disque appartient à l'outil de mémoire local de VS Code, qui est distinct.
- Trois portées locales, une portée cloud. L'outil de mémoire de VS Code conserve les notes User, Session et Repository sur votre machine, sous /memories/, /memories/session/ et /memories/repo/ ; GitHub Copilot Memory remplace la portée dépôt par une mémoire hébergée et partagée entre agents, que lisent Copilot coding agent, la revue de code et Copilot CLI.
- Votre formule décide de la valeur par défaut. Copilot Memory est activé par défaut pour Copilot Pro et Pro+ ; il reste désactivé pour Copilot Business et Enterprise tant qu'un propriétaire d'entreprise ou d'organisation ne l'a pas activé, et si deux organisations vous attribuent une licence, c'est le paramètre le plus restrictif qui l'emporte.
- Les mémoires expirent, pas les instructions. Une mémoire est écrite par Copilot, validée par rapport au code qui l'a produite, puis supprimée après 28 jours si elle n'est pas réutilisée régulièrement. Les règles que vous ne pouvez pas perdre — la commande de test, l'exigence de sécurité — ont leur place dans .github/copilot-instructions.md, et c'est pour cela que cette page se termine par un modèle.
I tried out all the memory features in GitHub Copilot (User / Session / Repository / Copilot Memory)
Chaîne:Yuzubon — ゆずぼん15:00
Instruction Files & /chronicle — Teaching Copilot Your Codebase
Chaîne:Casey Irvine17:37
The latest in managing and auditing GitHub Copilot agents
Chaîne:GitHub4:12
Managing and curating Copilot Memory (official docs, public preview)
Documentation officielle:docs.github.com
Copilot Memory est en aperçu public et le chemin des réglages évolue encore. Les chemins d'activation, l'expiration à 28 jours et la page de mémoire du dépôt décrits ici proviennent du guide « Managing and curating Copilot Memory » sur docs.github.com et de la référence « Use memory with agents » de VS Code ; le chemin du dossier de mémoire local vient de l'enregistrement lui-même, considérez-le donc comme propre à Windows et attendez-vous aux équivalents macOS et Linux dans le même répertoire de stockage global de VS Code.
Les captures sont créditées à l'enregistrement dont elles sont issues, et chaque étape renvoie par lien profond à la seconde exacte. Les étapes rédigées, le tableau comparatif et le modèle sont originaux et propres à cette page ; aucune transcription n'a été reproduite.
Les 12 étapes : du dossier sur le disque au modèle d'instructions versionné
Ce que Copilot retient, et où c'est stocké
- 1
Trouver le dossier de mémoire avant de toucher aux réglages
L'outil de mémoire de VS Code écrit de simples fichiers Markdown sur votre machine ; il ne les envoie pas à GitHub. Sous Windows, ils se trouvent dans %APPDATA%\Code\User\globalStorage\github.copilot-chat\memory-tool\memories\ — la capture montre coding-style.md dans exactement ce dossier. L'équivalent macOS se trouve dans ~/Library/Application Support/Code/User/globalStorage/ et l'équivalent Linux dans ~/.config/Code/User/globalStorage/, avec le même chemin github.copilot-chat/memory-tool/memories. Rien ici n'est versionné : aucun collègue ne peut le lire, et supprimer le fichier supprime la mémoire.
L'Explorateur de fichiers ouvert dans le dossier memory-tool : les fichiers Markdown qui se cachent derrière l'outil de mémoire local de VS Code.Voir à 3:26 - 2
La mémoire utilisateur, le fichier chargé en premier
Demandez une préférence dans le chat — « je préfère les retours anticipés et des noms de variables plus longs et descriptifs » — et l'outil de mémoire crée un fichier de mémoire utilisateur et l'indique dans sa réponse. La capture montre coding-style.md ouvert depuis globalStorage › github.copilot-chat › memory-tool › memories, le panneau de chat affichant « Reviewed memory file coding-style.md » et confirmant la création du fichier. La mémoire utilisateur est la seule portée injectée automatiquement dans chaque conversation : la documentation de VS Code en limite la taille aux 200 premières lignes. Écrivez dix lignes utiles, pas deux cents.
Une mémoire utilisateur volontairement courte, avec le chat qui confirme le fichier qu'il a écrit.Voir à 3:56 - 3
La mémoire de session : le plan que vous n'avez plus à réexpliquer
C'est en Plan mode que la mémoire de session est vraiment utile. Sélectionnez Plan mode, demandez une modification, et l'agent enregistre son plan d'implémentation dans /memories/session/plan.md, où il ne reste disponible que pour cette conversation — la documentation de VS Code décrit Session comme limitée à la conversation en cours. Repassez en Agent mode et renvoyez au plan au lieu de le retaper. La mémoire de session est aussi la portée la plus éphémère : elle est supprimée 14 jours après son dernier accès, alors n'y rangez jamais une décision dont vous aurez besoin le mois suivant.
Plan mode dans Copilot Chat : la requête qui pousse l'agent à écrire un plan de session au lieu de modifier des fichiers.Voir à 7:06
La mémoire de dépôt et la couche cloud de GitHub
- 4
La mémoire de dépôt reste locale jusqu'à ce que vous l'activiez
Dites « dans ce dépôt, retiens que chaque nouvelle fonction doit avoir un test » et l'agent l'écrit dans /memories/repo/ — toujours sur votre disque, toujours invisible pour votre équipe, et toujours absent des serveurs de GitHub jusqu'à ce qu'un réglage change. La capture montre cette requête en cours de saisie. C'est la portée que l'on désigne généralement par « dossier de mémoire Copilot » : le dossier existe bel et bien, mais il se trouve dans le stockage global de VS Code et non dans le dépôt, d'où l'absence de résultat quand on le cherche dans le projet.
Demander à Copilot de retenir une règle de dépôt — l'écriture qui atterrit dans la portée dépôt locale.Voir à 10:00 - 5
Activez le cloud : seules les nouvelles mémoires basculent
Copilot Memory est la moitié hébergée par GitHub de ce système, et dans VS Code il faut l'activer explicitement : github.copilot.chat.copilotMemory.enabled, à ajouter dans .vscode/settings.json. La documentation de VS Code présente copilotMemory comme une option à activer, distincte de l'outil de mémoire local. Une fois le réglage sur true, les écritures qui allaient dans /memories/repo/ partent vers GitHub. Deux choses ne changent pas : vos mémoires de dépôt locales existantes ne sont pas migrées, et l'outil ne fait que créer — pour consulter ou supprimer une mémoire hébergée, il faut passer par GitHub.
La modification de .vscode/settings.json qui redirige la mémoire de dépôt vers GitHub plutôt que vers le dossier local.Voir à 13:10 - 6
Consulter et supprimer les mémoires dans le dépôt, pas dans vos réglages
C'est la page vers laquelle renvoie la documentation officielle : Repository → Settings → Code & automation → Copilot → Memory, marquée Preview. Les mémoires sont listées de la plus récente à la plus ancienne, avec leur texte et leurs tags ; l'icône de corbeille en supprime une et les cases à cocher en suppriment plusieurs d'un coup. La suppression compte, car une mémoire erronée est pire que pas de mémoire du tout. Copilot valide chaque mémoire par rapport aux citations qui l'ont produite et l'ignore dès que ce code a changé, mais une mémoire issue d'une mauvaise lecture continue de passer ce contrôle. Les mémoires expirent aussi d'elles-mêmes au bout de 28 jours.
La page Copilot memory de GitHub dans les paramètres du dépôt, avec une mémoire enregistrée et son bouton de suppression.Voir à 12:09
Activer la fonctionnalité pour une équipe, puis écrire les instructions
- 7
Les propriétaires d'entreprise et d'organisation doivent d'abord l'activer
Votre formule décide qui fait quoi. Les abonnés individuels Copilot Pro et Pro+ ont Copilot Memory activé par défaut et peuvent le désactiver dans Settings → Copilot → Features. Copilot Business et Enterprise, c'est l'inverse : les mémoires restent désactivées tant qu'un propriétaire ne les active pas — les propriétaires d'entreprise via AI Controls → Copilot → Features, avec le choix Let organizations decide, Enabled everywhere ou Disabled everywhere, et les propriétaires d'organisation via Organization settings → Code, planning and automation → Copilot → Policies → Features → Copilot Memory → Enabled. Si deux organisations vous attribuent une licence, c'est le paramètre le plus restrictif qui s'applique.
Enterprise AI Controls, la famille de pages qui porte la politique d'activation de Copilot Memory.Voir à 1:06 - 8
Les instructions personnalisées commencent dans le dossier .github
Copilot écrit les mémoires ; vous écrivez les instructions, et vous les versionnez. Deux fichiers font le travail : .github/copilot-instructions.md pour les règles qui s'appliquent à tout le dépôt, et .github/instructions/NAME.instructions.md pour celles qui ne concernent que certains chemins, ces dernières étant mises en correspondance avec les fichiers que Copilot touche. La capture est le dépôt VS Code de Microsoft lui-même, où .github contient copilot-instructions.md à côté de instructions/, agents/, skills/, prompts/ et hooks/ — copiez la structure d'un dépôt qui applique cela publiquement depuis des mois.
Le dossier .github de microsoft/vscode, avec copilot-instructions.md à côté du dossier instructions.Voir à 1:40 - 9
Les règles limitées à un chemin passent par applyTo
Un fichier .instructions.md porte un frontmatter YAML qui détermine son chargement. name est le libellé affiché dans l'interface, description indique à l'agent à quelles tâches le fichier sert, et applyTo est un glob relatif à la racine du dépôt — la capture montre applyTo: src/vs/workbench/contrib/chat/browser/aiCustomization/** sur un vrai fichier d'instructions VS Code. VS Code joint le fichier automatiquement quand son applyTo correspond à un fichier que l'agent crée ou modifie, et peut aussi le charger à la demande quand la description correspond à la tâche. Si vous omettez ces deux champs, le fichier n'est chargé que si vous le joignez vous-même.
Un vrai fichier d'instructions dont le glob applyTo le rattache à un seul dossier.Voir à 5:20
Le modèle d'instructions personnalisées
- 10
Les instructions personnelles sont aussi un fichier
Avant le modèle de dépôt, sachez où placer vos propres préférences, car elles ont la priorité. Copilot CLI et l'hôte d'agent lisent ~/.copilot/copilot-instructions.md, et la capture montre un exemple fonctionnel avec les sections ## Output, ## Working style et ## AI disclosure — remarquez sa brièveté. Sur github.com, l'équivalent se trouve dans Copilot Chat → votre photo de profil → Personal instructions, où GitHub propose aussi des modèles intégrés et des espaces réservés comme [format]. L'ordre de priorité est : instructions personnelles, puis dépôt, puis organisation, et tous les ensembles correspondants sont quand même envoyés, donc ne laissez jamais deux d'entre eux se contredire.
Un copilot-instructions.md personnel dans le dossier personnel .copilot, avec les sections output, working style et AI disclosure.Voir à 4:10 - 11
Générer une première version avec /init, puis la remplacer
Pas besoin de partir d'un fichier vide. Copilot CLI affiche « No copilot instructions found. Run /init to generate a copilot-instructions.md file for this project » quand un dépôt n'en contient aucun — la capture montre ce message. Lancez /init, puis retravaillez le résultat à partir du modèle ci-dessous. Gardez la liste des commandes exacte, supprimez tout ce que l'agent pourrait déduire en lisant le code, et ne collez jamais de secrets, de jetons ou de données client : ce fichier est versionné et chaque collègue, comme chaque agent, le lira.
Copilot CLI signalant qu'un dépôt n'a pas encore de fichier d'instructions, et proposant /init.Voir à 10:00 - 12
Vérifier les fichiers réellement chargés par une session
Un modèle que vous ne pouvez pas auditer relève de la devinette. Dans Copilot CLI, /instructions liste chaque fichier d'instructions récupéré par la session — la capture montre la commande avec, au-dessus, la ligne « Loading environment: 18 custom instructions, 3 extensions, 26 hooks, 27 skills, 4 MCP servers » — et chaque fichier peut être désactivé pour la session en cours sans être supprimé. Dans VS Code, l'équivalent est l'éditeur Agent Customizations accessible via Chat: Open Customizations, et pour les instructions de dépôt, vous pouvez déplier la liste des références en haut d'une réponse du chat pour confirmer que .github/copilot-instructions.md a bien été utilisé.
La commande /instructions dans Copilot CLI, le moyen le plus rapide de voir le contexte chargé par une session.Voir à 7:10
Copilot Memory, instructions personnalisées et instructions par chemin : quelles différences ?
Trois choses différentes sont appelées « mémoire Copilot ». Seule la première est écrite par l'agent ; les deux autres sont des fichiers que vous versionnez et maintenez. Cette comparaison n'a pas pour but de désigner un gagnant — elle explique pourquoi les deux fonctionnalités coexistent : utilisez les mémoires pour les conventions que personne n'a écrites, et les instructions pour les règles que vous pouvez prouver.
| Critère | Copilot Memory (hébergée) | Instructions personnalisées (.github/copilot-instructions.md) | Instructions par chemin (.github/instructions/*.instructions.md) |
|---|---|---|---|
| Ce que c'est | Des faits que Copilot a déduits en travaillant dans le dépôt, stockés sous forme d'un sujet accompagné des citations qui l'étayent. | Des règles que vous écrivez une fois et qui s'appliquent à chaque requête dans le dépôt. | Des règles que vous écrivez pour un chemin, un langage ou un dossier précis du dépôt. |
| Qui l'écrit | Copilot, automatiquement, en réaction au travail des utilisateurs qui ont activé la fonctionnalité. | Vous, à la main, en Markdown. | Vous, à la main, en Markdown avec un frontmatter YAML. |
| Où elle est stockée | Sur GitHub, limitée à un seul dépôt. Consultez-la et supprimez-la dans Repository → Settings → Copilot → Memory ; aucun fichier n'existe dans votre arborescence de travail. | Dans le dépôt, à la racine du projet, dans .github/copilot-instructions.md. | Dans le dépôt, sous .github/instructions/, un fichier par portée. |
| Quand elle est chargée | Automatiquement, mais seulement après validation des citations par rapport à la branche courante. | À chaque requête dans ce dépôt, pour le chat, les agents et la revue de code. | Uniquement quand son glob applyTo correspond à un fichier concerné, ou quand l'agent juge la description pertinente. |
| Combien de temps elle dure | 28 jours ; une mémoire validée et réutilisée est réécrite, ce qui prolonge sa durée de vie. | Jusqu'à ce que quelqu'un modifie ou supprime le fichier — il est versionné avec le code. | Jusqu'à ce que quelqu'un modifie ou supprime le fichier. |
| Qui peut la voir | Toute personne travaillant dans ce dépôt et ayant activé Copilot Memory ; les mémoires ne quittent jamais le dépôt. | Toute personne ayant accès au dépôt, ainsi que chaque agent et chaque relecteur qui le lit. | Toute personne ayant accès au dépôt. |
| Comment vous la modifiez | Supprimez-la dans les paramètres du dépôt — l'outil de mémoire ne fait que créer, il ne peut ni consulter ni supprimer. | Ouvrez une pull request, comme n'importe quel autre fichier. | Ouvrez une pull request, comme n'importe quel autre fichier. |
| Idéal pour | Les conventions que personne n'a documentées, la forme d'une correction que le relecteur répète sans cesse, les patterns sûrs propres à cette base de code. | La stack et les versions, les commandes exactes de build et de test, la carte des dossiers, les règles de sécurité et de revue. | Les règles de framework dans un monorepo, les conventions des fichiers de test, le style d'un dossier, les idiomes d'un langage. |
Un modèle d'instructions personnalisées qui couvre les six éléments dont Copilot a vraiment besoin
La recommandation de GitHub est de garder le fichier court et précis : quelle est la stack, comment lancer les choses, où vit le code, quelles conventions sont obligatoires et ce qu'il faut éviter. Les blocs ci-dessous sont faits pour être copiés, puis allégés — supprimez toute ligne que l'agent pourrait déduire en lisant le dépôt, car un fichier d'instructions trop volumineux dilue les règles qui comptent. Enregistrez-le sous .github/copilot-instructions.md, à la racine du dépôt.
# .github/copilot-instructions.md
## Project and stack
- Next.js 15 app router, TypeScript strict, Node 22.
- Package manager: pnpm. Never run npm or yarn install.
## Commands
- Build: pnpm build
- Lint: pnpm lint
- Test everything: pnpm test
- Test one file: pnpm test -- path/to/file.test.ts
## Layout
- Routes: src/app/**
- UI components: src/components/**
- Data access: src/lib/db.ts and src/lib/repositories/**
- Tests live next to the file they cover: *.test.ts
## Conventions
- Named exports only; no default exports from src/lib.
- Handle errors at the boundary and return early instead of nesting.
- Import order: node builtins, external packages, then @/ aliases.
## Testing and review
- Every behaviour change ships with a test in the same pull request.
- Run the single-file test before requesting review.
- Commit messages follow Conventional Commits.
## Do not
- Do not edit files under src/generated/**.
- Do not add a dependency without calling it out in the pull request.
- Do not log secrets, tokens or full request bodies.- 1Projet et stack — indiquez le framework, le mode de langage et le gestionnaire de paquets sur une seule ligne. C'est le bloc qui empêche l'agent d'hésiter entre npm, pnpm et yarn et de générer un lockfile que vous n'avez pas demandé.
- 2Commandes — les commandes exactes de build, de lint, de test et de test d'un seul fichier, copiées depuis votre configuration CI plutôt que de mémoire. Une commande de test erronée est la ligne la plus coûteuse que vous puissiez omettre.
- 3Structure — où se trouvent les routes, les composants, l'accès aux données et les tests. Indiquez des dossiers plutôt que de décrire l'architecture en prose ; un chemin se vérifie, pas un paragraphe.
- 4Conventions — nommage, gestion des erreurs, ordre des imports et règles de formatage que votre équipe applique réellement. Gardez chaque règle binaire : le code la respecte ou non.
- 5Tests et revue — ce qui doit être livré avec un test, ce qu'une revue doit vérifier et votre convention de commit ou de branche. C'est le bloc qui transforme en garantie une mémoire dont vous auriez sinon besoin.
- 6À ne pas faire — les anti-patterns. Fichiers générés, nouvelles dépendances non signalées, refactorisations hors sujet, secrets dans les logs. Les règles négatives sont le moyen le moins coûteux d'éviter toute une catégorie de mauvaises pull requests.
Réduire la portée avec un second fichier
Gardez le fichier de dépôt court en déplaçant les règles propres à un dossier dans leurs propres fichiers sous .github/instructions/. C'est le frontmatter qui fait fonctionner le mécanisme : applyTo rattache automatiquement le fichier aux chemins correspondants, et description permet à l'agent de le charger pour la bonne tâche. VS Code documente name, description et applyTo comme les champs pris en charge.
---
name: 'React components'
description: 'Use when creating or updating components under src/components.'
applyTo: 'src/components/**/*.tsx'
---
# React components
- One component per file, named after the file.
- Props are typed with an explicit interface; no React.FC.
- Colocate styles with the component; no global class names.Gardez vos préférences personnelles hors du fichier de dépôt
Tout ce qui vous concerne vous plutôt que le projet — longueur des réponses, ton, façon dont vous voulez que les diffs soient expliqués — va dans les instructions personnelles. Copilot CLI et l'hôte d'agent lisent ~/.copilot/copilot-instructions.md ; sur github.com, ouvrez Copilot Chat, cliquez sur votre photo de profil et choisissez Personal instructions, où GitHub fournit aussi des modèles avec des espaces réservés comme [format]. Les instructions personnelles ont la priorité sur celles du dépôt et de l'organisation, donc une préférence définie à cet endroit n'a pas besoin d'être répétée dans chaque dépôt.
Deux dernières règles valables pour tous les blocs : ne mettez jamais de secrets, de jetons ou de données client dans un fichier d'instructions versionné, et ne laissez jamais les instructions du dépôt et une mémoire dire des choses différentes — en cas de conflit, Copilot suit les deux ensembles de contexte comme il peut et le résultat est imprévisible. Si une mémoire contredit sans cesse une règle que vous avez écrite, supprimez la mémoire plutôt que d'affaiblir la règle.