# Gestion du contexte (/fr/docs/verdent-for-vscode/best-practices/context)
> Gérer efficacement le contexte pour de meilleurs résultats
***
Une gestion efficace du contexte garantit que Verdent dispose des bonnes informations au bon moment, tout en évitant la dégradation des performances due à une surcharge de contexte.
### Ce que vous allez apprendre [#ce-que-vous-allez-apprendre]
* Comprendre les fenêtres de contexte et leurs limites
* Sélectionner les fichiers de manière stratégique pour un contexte optimal
* Reconnaître et réagir à la surcharge de contexte
* Quand réinitialiser le contexte pour de meilleures performances
* Comment l'organisation de l'espace de travail affecte le contexte
***
## Comprendre les fenêtres de contexte [#comprendre-les-fenêtres-de-contexte]
La taille de la fenêtre de contexte de Verdent for VS Code dépend du modèle utilisé.
La plupart des modèles utilisent des fenêtres de contexte `200K` standard :
* **Claude 4.5 Sonnet** - Équilibré pour les tâches complexes
* **Claude 4.5 Haiku** - Rapide et efficace
* **GPT-5** - Excellent pour le raisonnement (Bêta)
* **GPT-5-Codex** - Optimisé pour le code (Bêta)
**Capacité :**
* Environ `200,000` tokens de capacité mémoire totale
* Suffisant pour la plupart des tâches de développement et des projets de taille moyenne
**Ce qui est inclus :**
* Tous les messages de la conversation
* Le contenu des fichiers chargés dans le contexte
* Les sorties et réponses des outils
* Les prompts système et instructions
* Les définitions des serveurs MCP
**Performances :**
* Se dégradent nettement à l'approche des limites
* Surveillez les signes de surcharge de contexte (réponses plus lentes, résultats moins précis)
* Réinitialisez le contexte plus fréquemment pour des performances optimales
Claude Sonnet 4.5 propose un contexte étendu (`1M` tokens) lorsqu'il est explicitement sélectionné ou lorsque l'entrée dépasse `200K` tokens.
**Capacité :**
* `1,000,000` tokens de mémoire totale
* 5 fois plus grande que les modèles standard
**Avantages :**
* Parfait pour charger des bases de code volumineuses entières sans les découper
* Élimine la plupart des préoccupations liées à la gestion du contexte pour les grands projets
* Permet de travailler plus longtemps avant d'atteindre les limites de contexte
* Moins de réinitialisations de session nécessaires
**Quand l'utiliser :**
* Bases de code volumineuses comportant des fichiers `1000+`
* Refactorisation complexe multi-fichiers sur des projets entiers
* Sessions de développement longues couvrant plusieurs tâches liées
* Lorsque vous souhaitez minimiser la charge de gestion du contexte
***
## Sélection stratégique des fichiers [#sélection-stratégique-des-fichiers]
Soyez stratégique dans la sélection des fichiers pour optimiser l'utilisation du contexte et éviter d'atteindre les limites.
Commencez avec moins de fichiers et n'en ajoutez que si nécessaire, Verdent peut toujours lire des fichiers supplémentaires au cours de la conversation.
### Utiliser les mentions @ pour une inclusion explicite [#utiliser-les-mentions--pour-une-inclusion-explicite]
```
@filename.js
```
Verdent charge automatiquement les fichiers associés, mais `@-mentions` garantit un contexte exact. Soyez sélectif - n'incluez que les fichiers directement pertinents pour la tâche en cours.
### Surveiller l'utilisation du contexte [#surveiller-lutilisation-du-contexte]
* Surveillez la dégradation des performances au fur et à mesure que les sessions s'allongent
* Restez attentif à la longueur de la conversation et au nombre de fichiers
* Retirez les fichiers inutiles du contexte lorsque c'est possible
### Éviter la surcharge de contexte [#éviter-la-surcharge-de-contexte]
* Découpez les grandes tâches en éléments plus petits avec moins de fichiers par tâche
* Concentrez-vous uniquement sur les fichiers liés - ne chargez pas toute la base de code à la fois
* Utilisez la gestion des serveurs MCP pour désactiver les intégrations inutilisées
### Bonnes pratiques [#bonnes-pratiques]
* N'incluez que les fichiers qui doivent être modifiés ou référencés
* Référencez les patterns existants plutôt que de charger des fichiers d'exemple
* Pour les bases de code volumineuses, travaillez sur un module à la fois
* Utilisez la documentation du projet (`AGENTS.md`) plutôt que de charger de nombreux fichiers
* Évitez le dernier cinquième de la fenêtre de contexte pour les tâches gourmandes en mémoire
### Pour le contexte étendu (1M tokens) [#pour-le-contexte-étendu-1m-tokens]
La sélection des fichiers devient beaucoup moins critique - vous pouvez souvent charger des dépôts de projets entiers sans atteindre les limites.
***
## Reconnaître la surcharge de contexte [#reconnaître-la-surcharge-de-contexte]
**Signes :**
* Réponses moins précises ou incomplètes
* Perte d'informations importantes évoquées plus tôt dans la conversation
* Difficulté à maintenir la cohérence sur des sessions longues
* Confusion sur les changements récents ou le contexte
**Exemples concrets :**
* Suggère des solutions que vous avez déjà rejetées plus tôt dans la session
* Ignore les conventions de code que vous avez établies il y a `20` messages
* Génère du code qui entre en conflit avec des modifications effectuées plus tôt dans la conversation
* Propose des implémentations qui ne correspondent pas à l'architecture de projet discutée précédemment
**Signal principal :** les réponses de Verdent deviennent moins précises ou incohérentes
**Signes :**
* Temps de réponse nettement plus lents
* Délais de traitement plus longs avant le début des réponses
* Latence accrue entre les messages
**Exemples concrets :**
* Des réponses qui prennent normalement `5-10` secondes en prennent désormais `30+`
* Délai visible avant l'apparition de l'indicateur de saisie après l'envoi d'un message
* Les réponses en streaming démarrent beaucoup plus lentement que d'habitude
* L'exécution des outils (lectures de fichiers, recherches) prend nettement plus de temps
**Signal principal :** les réponses prennent nettement plus de temps que d'habitude
**Signes :**
* Demandes de clarification sur des informations déjà fournies
* Oubli de patterns ou de conventions établis précédemment
* Incapacité à référencer des fichiers ou du code discutés précédemment
* Questions redondantes sur la structure du projet
**Exemples concrets :**
* Demande "Quel framework utilisez-vous ?" alors que vous avez précisé React il y a `30` messages
* Redemande des chemins de fichiers déjà `@-mentioned` à plusieurs reprises
* Ne se souvient pas de la convention de nommage établie au début de la session
* Réexplique des concepts ou approches que vous avez déjà rejetés avec des justifications
**Signal principal :** Verdent interroge sur des sujets déjà abordés
**Signes :**
* Approche du dernier cinquième de la limite de tokens `200K` (environ `160K+` tokens utilisés)
* Longues conversations avec de nombreuses lectures de fichiers et sorties d'outils
* Plusieurs serveurs MCP activés avec des définitions d'outils lourdes
* Fichiers volumineux chargés dans le contexte de manière répétée
**Exemples concrets :**
* La session est en cours depuis `2+` heures avec `100+` messages
* Vous avez chargé `20+` fichiers avec `@-mentions` tout au long de la conversation
* Plusieurs fichiers volumineux (chacun `>1000` lignes) sont dans le contexte
* Vous avez `5+` serveurs MCP activés avec des définitions d'outils étendues
* La conversation comprend de nombreux résultats de grep/recherche et lectures de fichiers
**Signal principal :** sessions très longues avec une utilisation intensive de fichiers/outils
**Quand agir :** la dégradation des performances est votre signal principal. Si les réponses de Verdent deviennent moins précises, plus lentes ou incohérentes - démarrez une nouvelle session ou utilisez des stratégies de gestion du contexte.
Si les réponses de Verdent deviennent vagues ou répétitives, une surcharge de contexte peut être en cours. Réinitialisez la conversation pour restaurer les performances complètes.
**Remarque :** avec le contexte de `1M` tokens (Claude Sonnet 4.5), ces problèmes sont beaucoup plus rares.
***
## Quand réinitialiser le contexte [#quand-réinitialiser-le-contexte]
* Temps de réponse nettement plus lents
* Réponses moins précises ou incohérentes
* Verdent oublie le contexte ou les patterns précédents
* Approche des limites de la fenêtre de contexte (surveillez les signes de dégradation)
**Action :** démarrez une nouvelle session lorsque la qualité se dégrade
* Basculement entre fonctionnalités ou modules non liés
* Achèvement d'une tâche et passage à la suivante
* Après des tâches gourmandes en mémoire (grandes refactorisations, travail architectural)
* Passage de la phase de recherche à la phase d'implémentation
**Action :** nouvelle session pour une nouvelle tâche majeure
* Après avoir commité des fonctionnalités terminées dans le contrôle de version
* Entre les points de contrôle logiques du flux de travail de développement
* Suite aux cycles de test-vérification-commit
**Action :** commit → test → nouvelle session
* Avant de démarrer de nouvelles fonctionnalités majeures
* Lorsque l'historique de conversation devient très long
* Après avoir terminé des modifications multi-fichiers
* Entre différents types de travail (débogage → développement de fonctionnalités)
**Action :** démarrez proactivement une nouvelle session avant que le contexte ne se dégrade
**Flux de travail recommandé :** terminer une unité de travail atomique → tester → commiter → effacer le contexte → repartir à neuf pour la tâche suivante.
**Remarque :** démarrez une nouvelle session pour réinitialiser le contexte. Pour les contextes de `1M` tokens, l'effacement est nécessaire beaucoup moins fréquemment.
***
## Impact de l'organisation de l'espace de travail [#impact-de-lorganisation-de-lespace-de-travail]
L'organisation de l'espace de travail a un impact direct sur l'efficacité de l'utilisation du contexte et sur la facilité avec laquelle Verdent peut naviguer dans votre base de code.
**Fichiers plus petits et ciblés :**
* De nombreux petits fichiers consomment le contexte plus efficacement que quelques gros fichiers
* Plus facile de ne charger que les modules pertinents
* Meilleur contrôle granulaire de ce qui se trouve dans le contexte
* Réduit la nécessité de charger des fichiers volumineux entiers
**Structure de répertoires claire :**
* Une organisation logique aide Verdent à localiser les fichiers associés
* Une organisation par fonctionnalité ou par module améliore le ciblage du contexte
* Réduit la nécessité de charger du code non lié
**`Documentation in AGENTS.md:`**
* La documentation du projet remplace la nécessité de charger de nombreux fichiers d'exemple
* Les patterns architecturaux sont décrits une fois, référencés à plusieurs reprises
* Les normes de codage sont documentées de manière centralisée
* Réduit la charge de contexte liée aux lectures de fichiers exploratoires
**Avantages :**
* Travailler sur des modules isolés sans charger toute la base de code
* Des limites claires permettent des sessions ciblées
* Le découpage du travail devient naturel selon les limites des modules
**Problèmes :**
* Les fichiers monolithiques imposent de charger des contextes volumineux entiers
* Une structure floue nécessite de charger de nombreux fichiers pour comprendre l'architecture
* Le mélange des responsabilités dans les mêmes fichiers gaspille du contexte sur du code non pertinent
**Impact :**
* Problèmes fréquents de limite de contexte
* Tokens gaspillés sur du code non pertinent
* Difficulté à isoler le travail sur des modules spécifiques
* Besoin plus fréquent de réinitialisations de session
**Anti-patterns courants :**
* Fichiers uniques de `5000+` lignes avec de multiples responsabilités
* Structure de répertoires plate avec `100+` fichiers à la racine
* Aucune séparation claire entre les fonctionnalités/modules
* Absence de documentation centralisée
**Approches de refactorisation :**
* Découpez les gros fichiers en modules plus petits et ciblés
* Organisez par fonctionnalité ou domaine (pas par type de fichier)
* Créez une hiérarchie de répertoires claire
* Extrayez le code partagé dans des modules distincts
**Documentation :**
* Créez `AGENTS.md` avec les patterns architecturaux
* Documentez les normes de codage de manière centralisée
* Maintenez des fichiers `README` par module
* Conservez les décisions de conception documentées
**Impact sur le contexte :** pour les contextes standard de `200K` tokens, des espaces de travail organisés font la différence entre atteindre les limites fréquemment ou rarement. Pour les contextes de `1M` tokens, l'organisation compte moins mais améliore quand même l'efficacité.
***
## Stratégies d'optimisation du contexte [#stratégies-doptimisation-du-contexte]
Une optimisation efficace du contexte combine surveillance, planification stratégique et configuration technique.
**Surveiller les signes de performance :**
* Surveillez la qualité et la vitesse des réponses tout au long des sessions
* Remarquez lorsque les réponses deviennent plus lentes ou moins précises
* Suivez manuellement la longueur de la conversation et le nombre de fichiers
* Soyez proactif pour démarrer de nouvelles sessions
**Ce qu'il faut surveiller :**
* Précision et cohérence des réponses
* Temps jusqu'à la première réponse (délai de l'indicateur de saisie)
* Temps total d'achèvement de la réponse
* Mémoire des détails de conversation précédents
**Gestion des sous-agents :**
* Désactivez les sous-agents personnalisés inutilisés lorsqu'ils ne sont pas nécessaires
* Chaque sous-agent activé ajoute des définitions à la charge système
* Ne conservez activés que les sous-agents réellement utilisés
* Réactivez-les selon les besoins pour des tâches spécifiques
**Seuil d'action :** lorsque vous constatez des signaux de dégradation `2-3`, il est temps de démarrer une nouvelle session.
Surveillez la qualité des réponses comme indicateur avancé de la santé du contexte, des réponses dégradées signalent qu'il est temps de réinitialiser.
**Approche par découpage :**
* Découpez les grandes tâches en éléments plus petits
* Réalisez le travail lié dans des sessions ciblées
* Évitez de mélanger différents types de tâches dans de longues conversations
* Évitez le dernier cinquième de la fenêtre de contexte pour le travail gourmand en mémoire
**Gestion de session :**
* Démarrez de nouvelles sessions entre les tâches majeures
* Effacez le contexte après les commits : test → vérification → commit → nouvelle session
* Utilisez des listes de tâches pour la planification multi-étapes
* Traitez les éléments de la liste de tâches dans des sessions distinctes ciblées
**Schéma de bonne pratique :**
1. Planifiez la tâche en Plan Mode
2. Exécutez une implémentation ciblée dans une nouvelle session
3. Testez et vérifiez les modifications
4. Commitez dans le contrôle de version
5. Démarrez une nouvelle session pour la tâche suivante
**Isolation des tâches :** séparez le débogage du développement de fonctionnalités, la recherche de l'implémentation.
**Inclusion stratégique :**
* Utilisez `@-mentions` pour l'inclusion explicite de fichiers uniquement lorsque nécessaire
* Exploitez la documentation `AGENTS.md` plutôt que de charger de nombreux fichiers
* Travaillez sur un module à la fois pour les grands projets
* Découpez les gros fichiers en composants plus petits et ciblés
**Principes de sélection des fichiers :**
* N'incluez que les fichiers nécessitant une modification ou une référence directe
* Préférez la documentation au chargement de fichiers d'exemple
* Retirez les fichiers du contexte lorsqu'ils ne sont plus nécessaires
* Chargez les fichiers juste à temps, pas de manière préventive
**Gestion des fichiers volumineux :**
* Envisagez de découper les fichiers de plus de `500` lignes
* Extrayez les utilitaires et fonctions d'aide dans des fichiers distincts
* Utilisez des limites de modules claires
* Documentez les relations entre fichiers dans `AGENTS.md`
**Flux de travail d'optimisation :**
Surveiller les performances → identifier la surcharge de session → désactiver les sous-agents inutilisés → démarrer proactivement de nouvelles sessions → se concentrer sur la qualité de la tâche
**Pratique quotidienne :**
* Démarrez chaque fonctionnalité majeure avec un contexte neuf
* Commitez fréquemment et réinitialisez entre les commits
* Gardez les sessions centrées sur des objectifs uniques
* Passez en revue l'utilisation du contexte aux points de rupture naturels
**`For Extended Context (1M tokens):`** Avec la fenêtre de contexte plus grande de Claude Sonnet 4.5, l'optimisation devient moins critique - concentrez-vous sur la qualité de la tâche plutôt que sur une gestion agressive du contexte. Cela dit, de bonnes pratiques continuent d'améliorer l'efficacité et l'organisation.
***
## FAQ [#faq]
Les modèles standard (Claude 4.5 Sonnet, Haiku, GPT-5, GPT-5-Codex, MiniMax-M2) disposent de fenêtres de contexte de `200K` tokens, suffisantes pour la plupart des tâches. Claude Sonnet 4.5 propose un contexte étendu de `1M` tokens (5 fois plus grand) pour les bases de code volumineuses comportant des fichiers `1000+`, une refactorisation complexe multi-fichiers, ou des sessions de développement longues. Le contexte `1M` s'active automatiquement lorsque l'entrée dépasse `200K` tokens, ou peut être sélectionné explicitement.
Vous devez démarrer manuellement une nouvelle session pour réinitialiser le contexte - Verdent n'efface pas automatiquement le contexte. Bonne pratique : réinitialisez après avoir terminé une unité de travail atomique, testé, et commité dans le contrôle de version. Pour les contextes de `1M` tokens, les réinitialisations sont nécessaires beaucoup moins fréquemment.
Il n'y a pas de limite fixe de fichiers - cela dépend de la taille des fichiers et du nombre total de tokens. Pour les contextes `200K`, évitez de charger `20+` gros fichiers (chacun `>1000` lignes). Concentrez-vous sur les fichiers directement pertinents pour votre tâche en cours. Utilisez `@-mentions` de manière sélective et exploitez la documentation `AGENTS.md` plutôt que de charger de nombreux fichiers d'exemple. Avec le contexte de `1M`, la sélection des fichiers devient beaucoup moins critique.
Tout ce qui se trouve dans votre session : tous les messages de la conversation, le contenu des fichiers chargés dans le contexte, les sorties des outils (résultats de grep/recherche, lectures de fichiers), les prompts système et instructions, et les définitions des serveurs MCP. Chacun de ces éléments consomme des tokens de votre capacité de contexte totale.
Non - la réinitialisation du contexte efface uniquement l'historique de conversation et les fichiers chargés en mémoire. Vos modifications de code réelles, commits et modifications de fichiers sont préservés. Commitez toujours votre travail dans le contrôle de version avant de réinitialiser le contexte, par sécurité. Réinitialisez → démarrez une nouvelle session → continuez à travailler sur la tâche suivante.
***
## Voir aussi [#voir-aussi]
Bonnes pratiques pour rédiger des prompts efficaces
Comprendre les modes d'exécution et leurs implications en termes de ressources
Surveillez l'utilisation des tokens, des crédits et des performances