Si tu as l’impression que Copilot Chat est devenu plus lent, plus verbeux et plus “moyen” depuis quelques versions, tu n’es pas fou. Le pattern que je vois partout, c’est le même : au lieu de répondre avec 2-3 fichiers pertinents, il se met à scanner tout le workspace. Résultat : contexte énorme, compaction agressive, et précision qui s’effondre. Bonus pas drôle : tu élargis mécaniquement le périmètre de ce que tu fournis au modèle, donc tu augmentes le risque si ton repo traîne des trucs sensibles.
Le but de cet article est simple : retrouver des réponses rapides et utiles, et garder un workflow où c’est toi qui choisis le contexte, pas l’extension.
Quand Copilot Chat “prend tout le workspace”, voilà ce qui se passe vraiment
Copilot Chat n’est pas juste un autocompléteur. Pour répondre, il fabrique un paquet de contexte. Et selon le mode, les réglages et la version, ce contexte peut inclure beaucoup plus que ce que tu imagines : fichiers ouverts, arborescence, extraits de code voisins, et parfois une logique “workspace” très large (le fameux “scan”).
Le problème n’est pas moral, il est mécanique. Les modèles ont un budget de contexte. Si tu remplis ce budget avec du bruit (des fichiers non liés, des configs, des fixtures, des migrations, des dumps…), tu forces ensuite le système à compacter, résumer, ou jeter des morceaux. Et là, tu te retrouves avec un assistant qui “sait tout mais mal”. Il a lu trop large, donc il est moins sûr, donc il généralise. Et quand il doit choisir, il choisit parfois les mauvais détails.
La compaction, c’est le moment où tu sens qu’il te répond avec une version “résumée” du projet. C’est pratique sur une longue discussion, mais catastrophique quand tu veux débugger un cas précis. Tu perds les noms exacts, les signatures, les invariants. Tu récupères du vague.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Les symptômes : latence, réponses génériques, oublis… et hallucinations plus crédibles
En pratique, ça se voit vite. D’abord, la latence : tu poses une question simple, et tu attends. Tu relances, tu attends encore. Souvent, ça coïncide avec un moment où le chat est en train de “collecter” du contexte (même si l’UI n’est pas toujours transparente là-dessus).
Ensuite, la qualité. Le signe le plus clair, c’est quand Copilot te ressort des réponses bien écrites mais trop larges, avec des suppositions qui ne collent pas à ton code. Exemple classique : il t’explique comment est censée marcher une feature “standard”, alors que ton repo fait exprès d’être différent. Ou il te propose une modification dans un fichier qui n’existe pas chez toi, parce qu’il a inféré une structure de projet “typique”.
Et puis il y a le truc le plus vicieux : les hallucinations deviennent plus convaincantes. Parce qu’avec un contexte énorme et compacté, le modèle peut produire une réponse cohérente… basée sur une version résumée et partiellement fausse de ton code. C’est exactement le genre de bug qui te fait perdre une heure : tu essayes de suivre une piste “logique”, mais elle n’est pas ancrée sur la réalité du repo.
Pourquoi “plus de contexte” donne parfois de moins bonnes réponses
On a tous eu le réflexe “donne-lui plus d’infos, il sera meilleur”. Sauf qu’en debug, en refacto, en décision d’archi, la bonne info vaut mille infos. Si tu balances tout le repo, tu mélanges des couches (legacy, WIP, scripts internes, POC, code mort). Tu crées des contradictions. Le modèle ne peut pas “exécuter” ton projet, il ne fait que prédire la suite la plus plausible. Si tu lui fournis plusieurs versions d’une même vérité, il va lisser.
Autre point très concret : certains fichiers “aspirent” le contexte. Les gros fichiers de config, les fichiers générés, les dumps JSON, les migrations en série, les lockfiles. Tu ne veux pas payer ton budget de contexte avec ça. Toi non plus tu ne lis pas un package-lock.json pour comprendre un bug métier.
Le contournement le plus efficace : forcer un chat “sans workspace par défaut”
Un retour qui remonte (et que j’ai déjà vu fonctionner) consiste à passer par un agent custom ou un mode de chat qui ne s’autorise pas à ingérer le workspace en large. L’idée est bête : tu crées un profil/agent dont les instructions disent explicitement “ne pas utiliser le workspace sauf si je te donne des fichiers”. Et tu l’utilises par défaut pour le debug et les questions chirurgicales.
Je ne te donne pas une clé de réglage magique ici, parce que ça bouge selon les versions de l’extension Copilot Chat et l’éditeur. Mais la logique est stable : un agent = une règle de contexte. Si ton outil te permet de définir un agent, profite-en pour en avoir deux : un “workspace-large” pour l’exploration, et un “focus” pour le quotidien.
Ce qui compte, c’est l’intention : tu veux un assistant qui part du principe que le contexte est interdit tant que tu ne l’as pas autorisé. C’est ce seul switch mental qui te rend du temps.
Le workflow qui marche vraiment : “spec-first” et fichiers explicitement autorisés
Quand je veux des réponses rapides, je fais l’inverse de “scanne tout”. Je donne un point d’entrée clair, et je borne. Concrètement, j’écris une mini spec dans un fichier dédié (ou un commentaire de PR) et je dis à Copilot de se baser sur ça, plus 1 ou 2 fichiers max. Ça paraît scolaire, mais en vrai c’est juste de l’hygiène de contexte.
Le gros gain, c’est que tu crées une source de vérité stable. Au lieu de “devine mon intent dans le repo”, tu lui donnes l’intent en 15 lignes. Et tu évites le piège du chat qui part lire 80 fichiers pour répondre à une question qui en nécessite 2.
Voici un template que j’utilise, volontairement court. Il te force à choisir le périmètre, et il rend le résultat beaucoup plus prédictible.
Contexte autorisé : uniquement les fichiers que je cite.
But : [1 phrase].
Contraintes : [perf/sécurité/compat].
Fichiers à utiliser :
- path/to/entrypoint.ts
- path/to/service.ts
- docs/spec.md
Tâche : propose une solution + un patch minimal. Si tu as besoin d’un autre fichier, demande-le avant d’inventer.Tu noteras la dernière phrase. Je la mets presque systématiquement. Pas pour “rassurer”, mais parce que ça casse un comportement courant : l’assistant qui comble le vide avec des suppositions. Là, tu l’obliges à réclamer un morceau de contexte au lieu de l’imaginer.
Limiter le contexte, c’est aussi une histoire de workspace (et d’organisation locale)
Le truc que beaucoup de devs oublient : ton “workspace” est souvent un fourre-tout. Un monorepo, des sous-projets, un dossier _archive, un dossier client-X, des exports, des scripts one-shot. Si tu ouvres tout ça dans la même fenêtre VS Code, tu invites l’outil à considérer que tout est “disponible”.
Mon approche est un peu radicale mais elle marche : je sépare. Un workspace par client, un workspace par produit, et surtout pas de dossier “Downloads/export” dans le même arbre que le code. Quand j’ai besoin de comparer deux choses, j’utilise un workspace multi-root, mais je garde la main sur ce que j’ajoute. Oui, ça fait un onglet de plus. Oui, c’est plus propre.
Secrets : le vrai problème, c’est ce qui traîne déjà dans ton repo
Parlons franchement. Si “scanner tout le repo” te fait peur, ce n’est pas seulement à cause de Copilot. C’est parce que beaucoup de repos contiennent déjà des trucs qui n’ont rien à faire là : des .env committés “temporairement”, des fixtures qui incluent des tokens, des exports SQL anonymisés à moitié, des JSON de prod, des clés d’API de services tiers, ou des fichiers de config copiés-collés depuis une machine qui avait tout dedans.
Le bon réflexe, c’est d’agir sur deux plans. D’un côté, tu réduis le contexte consommé par le chat. De l’autre, tu réduis la surface sensible dans tes dossiers de dev. Parce que même si tu fais attention aujourd’hui, il suffit d’un “oui oui c’est juste pour tester” pour que le prochain scan avale une horreur.
Je sais que ça a l’air basique, mais commence par être impitoyable sur les fichiers qui ne doivent pas vivre dans le repo ni dans le workspace. Et si tu bosses sur des projets clients, évite de tout ouvrir sous un même dossier racine “Clients”. C’est la meilleure façon de mélanger des configs, et de ne plus savoir ce qui a été exposé à quoi.
# Ne laisse pas traîner ça dans un repo.
.env
.env.*
*.pem
*.key
**/secrets.*
**/*backup*
**/*dump*
**/*.sql
**/*.sqlite
Ce n’est pas une solution “Copilot”. C’est juste la base pour ne pas vivre avec une grenade dégoupillée dans le dossier projet. Et si tu as la possibilité d’activer des contrôles côté plateforme (secret scanning, règles de push, etc.), fais-le. Pas parce que “on ne sait jamais”, mais parce que la fuite la plus probable vient presque toujours d’une erreur humaine banale.
Les erreurs que je vois tout le temps (et qui font perdre les bénéfices de Copilot)
La première, c’est de vouloir un assistant omniscient en permanence. Sur le papier, ça fait rêver. Dans la vraie vie, ça transforme une question simple en une requête lente, et une réponse précise en réponse moyenne. Tu ne veux pas “un copilote”, tu veux un collègue qui lit le bon fichier.
La deuxième, c’est de confondre “ça marche” et “c’est safe”. Si ton repo contient des secrets, le problème est déjà là. Le scan ne fait que l’exposer plus souvent. Et même sans parler d’exfiltration volontaire, tu peux te retrouver à copier-coller une réponse qui contient un bout de secret, ou à coller un log complet dans le chat parce que tu es pressé. Le risque, il est surtout dans la routine.
La troisième, c’est de ne pas avoir de protocole. Quand tu es en incident, tu vas au plus vite. Et au plus vite, tu fais exactement ce qu’il ne faut pas : tu ouvres tout, tu demandes “analyse tout”, tu colles des fichiers entiers. Le bon protocole doit être faisable quand tu es stressé. Sinon il ne sera jamais suivi.
Ma “definition of done” : un prompt court, un périmètre, et une demande de contexte explicite
Le réglage parfait n’existe pas. Par contre, tu peux viser une routine stable. Pour moi, une interaction Copilot “saine”, c’est une question qui cite explicitement les fichiers autorisés, qui contient un but en une phrase, et qui autorise l’assistant à demander un fichier manquant plutôt que de combler avec du faux.
Quand tu travailles comme ça, tu récupères trois bénéfices d’un coup. La latence baisse, parce que tu réduis le travail de collecte. La qualité remonte, parce que tu supprimes le bruit. Et côté sécurité, tu arrêtes d’élargir le contexte “par défaut”, ce qui est déjà un gros filet de protection.
Et si un jour tu veux repasser en mode “exploration du repo”, tu peux le faire consciemment, dans un agent dédié, sur un workspace propre. Le point n’est pas de se priver. Le point, c’est d’arrêter l’automatique.
