Ingénierie du contexte : gérer des fenêtres d’un million de tokens sans dégradation

En 2026, Gemini, GPT-5 et Claude avec réflexion étendue prennent tous en charge des fenêtres de contexte d’un million de tokens. Les démonstrations montrent des modèles lisant des livres entiers en une seule passe. Le rêve semble se réaliser : placer tout le contenu dans le contexte et laisser le modèle agir.

La réalité est plus nuancée. Un million de tokens représente une capacité technique, pas une garantie de performance. Les modèles fonctionnent généralement mieux avec 5 000 à 50 000 tokens. Au-delà de 100 000, des problèmes subtils apparaissent ; au-delà de 500 000, des informations importantes sont régulièrement omises ; à un million, le modèle est submergé.

Ce phénomène — la « dégradation du contexte » — est réel, bien documenté et visible dans les évaluations. L’implication : vous ne pouvez pas simplement tout mettre dans le contexte et considérer la tâche accomplie. Vous avez besoin d’ingénierie du contexte : des décisions délibérées sur ce qu’inclure, ce qu’il faut résumer, ce qu’il faut récupérer dynamiquement, et comment structurer le contexte résultant.

Cet article couvre les modèles et la discipline de l’ingénierie du contexte efficace pour les systèmes de production sérieux.

Qu’est-ce que la dégradation du contexte ?

La « dégradation du contexte » désigne l’observation empirique selon laquelle les performances des grands modèles de langage diminuent lorsque le contexte augmente, même sous la limite technique.

Modes de défaillance spécifiques :

Perdu au milieu (Liu et al., 2023). Les modèles accordent davantage d’attention au début et à la fin du contexte. Un fait placé à la position 50 000 sur 100 000 risque davantage d’être omis que le même fait aux positions 1 000 ou 99 000.

Biais de récence. Les modèles surpèsent le contenu récent. Dans l’historique de la conversation, le contexte ancien devient effectivement invisible.

Sensibilité aux distracteurs. Le contenu irrélevant dans le contexte dégrade la performance même sur les tâches qui n’ont pas besoin de ce contenu. Le modèle doit filtrer ; certains signaux de filtrage fuient.

Qualité de raisonnement en baisse. Le raisonnement à plusieurs étapes devient moins fiable à mesure que le contexte augmente. Le modèle a plus à suivre ; la qualité du suivi souffre.

Coût et latence. Indépendamment de la qualité : les grands contextes sont coûteux (tarification par token) et lents (linéaire en fonction du nombre de tokens pour de nombreux modèles).

Ce ne sont pas des préoccupations théoriques. Les déploiements en production avec des contextes larges naïfs sous-performent systématiquement les déploiements avec des contextes curés.

Le principe : moins c’est plus

Idée centrale : le contexte est une ressource précieuse dont la valeur se dégrade. Utilisez-le stratégiquement.

Un contexte de 30 000 tokens soigneusement sélectionnés surpasse généralement un contexte de 300 000 tokens sans filtrage. La qualité, le coût et la latence favorisent tous le contexte le plus compact.

Cela change le travail d’ingénierie. Au lieu de « trouver un moyen de mettre plus de choses dans le contexte », il s’agit de « décider ce qui a vraiment besoin d’être dans le contexte, et de le mettre bien là ».

Le budget de contexte

Pensez au contexte comme à un budget que vous allouez.

Un budget typique pour un agent de support client :

Total context budget: 30K tokens

- System prompt: 1500 tokens (5%)
- Tool descriptions: 1000 tokens (3%)
- User profile / context: 500 tokens (2%)
- Conversation history summary: 1000 tokens (3%)
- Recent conversation turns (full): 4000 tokens (13%)
- Retrieved relevant knowledge: 12000 tokens (40%)
- User's current message: 500 tokens (2%)
- Output token budget (response): 10K tokens (33%)

Chaque composant se dispute cet espace. Lorsque le contexte augmente, des arbitrages deviennent nécessaires.

La discipline : soyez explicite sur l’allocation. Ne laissez aucun composant croître sans limites.

Schéma 1 : mémoire conversationnelle hiérarchique

Pour les conversations à plusieurs tours, l’historique complet augmente indéfiniment. La plupart des systèmes de production utilisent une mémoire hiérarchique :

Niveau 1 : échanges récents complets. Les 5 à 10 derniers échanges sont conservés mot pour mot.

Niveau 2 : Résumés des tournées plus anciennes. Plus tôt dans la conversation, compressé en un court résumé.

Niveau 3 : Faits extraits. Informations clés de la conversation (nom de l’utilisateur, préférences, décisions prises) stockées sous forme de faits structurés.

Implémentation :

On each turn:
1. Take the conversation history.
2. The last 10 turns are kept verbatim.
3. Turns 11-30 are summarized into 200 words ("Earlier, the user discussed X and we agreed Y").
4. Turns 31+ are reduced to extracted facts ("User prefers Python. User is on enterprise tier.").
5. Total memory: ~2K tokens regardless of conversation length.

Ce modèle est fondamental pour toute conversation prolongée. Sans lui, les conversations se dégradent à mesure qu’elles s’allongent.

Une nuance : le résumé doit préserver les informations dont l’agent aura besoin. Si l’utilisateur a mentionné un numéro de compte à la tournée 5 et que l’agent ne l’insère pas dans la mémoire à long terme, à la tournée 50 le numéro de compte est perdu.

Exécutez le résumé avec des instructions explicites sur ce qu’il faut préserver :

Summarize the conversation so far. Preserve:
- All facts about the user (name, role, preferences, account info).
- All decisions made.
- All open commitments or follow-ups.
- The current goal of the conversation.

Discard:
- Pleasantries.
- Repeated information.
- Detailed reasoning that's been resolved.

Schéma 2 : recherche juste à temps

Au lieu de charger le contexte à l’avance, recherchez les informations pertinentes au moment où elles deviennent nécessaires.

Contre-modèle : insérez tous les documents d’un utilisateur dans le contexte « au cas où le modèle en aurait besoin ». La plupart des requêtes n’ont besoin qu’un petit sous-ensemble. Le contexte est gaspillé ; la performance souffre.

Meilleur : récupérez les documents en fonction de la requête actuelle. Différentes requêtes obtiennent différents documents. Le contexte total par appel reste petit ; la pertinence reste élevée.

C’est simplement RAG, appliqué de manière disciplinée. La clé : ne pas être tenté de « simplement inclure tout parce que nous le pouvons ». Même les équipes expérimentées sont tentées quand les modèles à grand contexte sont disponibles.

Schéma 3 : représentations compressées

Pour les informations qui doivent persister dans le contexte, utilisez des représentations compressées.

Original (verbeux) :

The user has been working in software engineering for 8 years. They started at a small startup called Acme Corp where they worked on backend systems. After 3 years they moved to a larger company called Beta Inc where they did frontend work. They're currently at Gamma LLC working on machine learning systems.

Compressé :

User: SWE, 8 years, currently ML at Gamma LLC. Prior: backend@Acme (3yr), frontend@Beta.

La version compressée préserve les faits pertinents en moins de tokens. Le modèle peut utiliser l’une ou l’autre également bien pour la plupart des fins.

Appliquez cette technique à :

• Profils utilisateur.
• Résumés de documents.
• Contexte de conversation passé.
• Entrées de base de connaissances (quand le contenu complet n’est pas nécessaire).

Le compromis : la compression perd de la nuance. Utilisez le texte complet quand la nuance compte ; la version compressée quand elle ne compte pas.

Schéma 4 : recherche hiérarchique

Pour de très grandes bases de connaissances, récupérez hiérarchiquement.

Étape 1 : Récupérez des catégories larges ou des résumés de documents en fonction de la requête.

Étape 2 : dans les catégories les plus pertinentes, recherchez des segments précis.

Étape 3 : incluez uniquement les segments sélectionnés à l’étape 2 dans le contexte final.

Cela évite « J’ai 10K documents ; laissez-moi les intégrer tous dans le contexte ». Au lieu de cela, le filtrage maintient le contexte serré.

Variante : un petit appel LLM sélectionne les segments les plus pertinents avant l’appel principal. Le léger surcoût réduit sensiblement l’encombrement du contexte.

Schéma 5 : réflexion sur le contexte

Pour les agents en tâches prolongées, réfléchissez périodiquement à ce qui est dans le contexte et à ce qui devrait y être.

Every 10 steps, the agent does:

1. Reviews its current context.
2. Identifies what's relevant to ongoing work.
3. Summarizes or drops anything no longer needed.
4. Notes what additional context might help.
5. Replaces the old context with the curated version.

C’est une « collecte de déchets » pour le contexte. Sans cela, les agents accumulent des informations obsolètes qui déplacent les informations pertinentes nouvelles.

L’implémentation nécessite une orchestration personnalisée — la plupart des cadres ne gèrent pas cela nativement. Le modèle : entre les étapes, l’agent a une phase de « consolidation de la mémoire » qui ajuste ce qui est dans le contexte.

Schéma 6 : fenêtres de contexte dynamiques

Différentes parties d’une exécution d’agent peuvent avoir des tailles optimales de contexte différentes.

• Étapes de décision : Petit contexte, axé sur la décision immédiate.
• Étapes de synthèse : Contexte plus grand, incluant de nombreuses sources.
• Étapes de génération : Contexte moyen, avec des références de style et de format.

Un modèle : chaque étape dans le workflow de l’agent utilise une forme de contexte différente. L’orchestration gère quel contenu va dans quelle étape.

Cela nécessite de diviser le travail de l’agent en étapes explicites plutôt qu’en une grande boucle. Le choix du cadre est important ici (LangGraph gère cela naturellement ; l’API directe nécessite un travail manuel).

Schéma 7 : placement tenant compte de la position

Étant donné que les modèles portent plus d’attention au début et à la fin du contexte, placez le contenu important là.

Moins efficace : Instruction critique enfouie au milieu d’un long prompt système.

Plus efficace : Instruction critique au tout début ET reformulée près de la fin.

Pour le RAG avec plusieurs documents récupérés : le document le plus pertinent au début, le second le plus pertinent à la fin, moins pertinent au milieu.

C’est une optimisation tactique mais a un effet mesurable sur les sorties.

Schéma 8 : résumé sélectif

Pas tous les résumés sont égaux. Adaptez le résumé à ce dont les tâches suivantes ont besoin.

Mauvais : résumé générique qui omet les préférences de l’utilisateur.

Meilleur : résumé explicitement préservant les préférences de l’utilisateur pertinentes pour la tâche suivante.

Summarize this document focusing on:
- Technical decisions made.
- Stakeholders mentioned.
- Open questions or risks.

Drop:
- General context already known to the team.
- Repeated points.

Le prompt de résumé est conçu pour l’utilisation suivante.

Schéma 9 : contexte structuré

Le texte brut est une option. Le contexte structuré (JSON, XML ou balisage spécifique) peut être beaucoup plus dense.

Prose verbeuse :

The customer's name is John Smith. He's been a customer since March 2023. His current plan is Pro, billed monthly at $29. He has 3 active integrations: Slack, Notion, and Linear. His usage in the last 30 days has been moderate — 1,250 API calls.

Structuré :

{
  "customer": {
    "name": "John Smith",
    "since": "2023-03",
    "plan": "Pro",
    "billing": "monthly $29",
    "integrations": ["Slack", "Notion", "Linear"],
    "usage_30d": {"api_calls": 1250, "tier": "moderate"}
  }
}

La version structurée est plus courte et (souvent) plus facile à utiliser par le modèle. Le modèle peut rapidement trouver des faits spécifiques.

Avertissement : tous les modèles ne sont pas également bons avec l’entrée structurée. Testez les deux formats pour votre cas d’utilisation.

Schéma 10 : contexte par couches

Organisez le contexte en couches de priorité. Le contenu prioritaire est toujours inclus, le contenu intermédiaire seulement lorsqu’il est pertinent et le contenu secondaire à la demande.

Toujours inclus :

• Prompt système (identité, comportement).
• Contexte utilisateur actuel (faits essentiels).
• Conversation récente.

Quand pertinent :

• Documents récupérés correspondant à la requête.
• Sorties d’outils des étapes récentes.

Sur demande :

• Données spécifiques que l’agent demande via des appels d’outils.
• Contexte historique au-delà de la fenêtre récente.

Le modèle « sur demande » est crucial pour l’échelle : l’agent récupère ce dont il a besoin, quand il en a besoin, plutôt que de tout charger à l’avance.

Schéma 11 : stratégies d’éviction

Quand le contexte approche les limites, quoi évincer ?

• Basé sur la récence : le contenu le plus ancien est évincé en premier.
• Basé sur la pertinence : le contenu le moins lié à la tâche actuelle est évincé en premier.
• Basé sur l’importance : le contenu marqué comme à faible importance est évincé en premier.

Un modèle pratique : étiquetez les éléments de contexte avec des niveaux de priorité. Quand l’éviction est nécessaire, supprimez dans l’ordre de priorité.

context_items = [
    {"content": "...", "priority": "critical"},   # Never evict
    {"content": "...", "priority": "high"},        # Evict last
    {"content": "...", "priority": "medium"},     # Evict if needed
    {"content": "...", "priority": "low"},         # Evict first
]

def evict_to_fit(items, budget):
    items_by_priority = sorted(items, key=lambda x: priority_value(x.priority))
    while total_tokens(items) > budget:
        items.remove(items_by_priority.pop(0))  # Remove lowest priority
    return items

Schéma 12 : mise en cache du contexte répétitif

Beaucoup d’appels réutilisent le même contexte — même prompt système, mêmes descriptions d’outils, même profil utilisateur.

La plupart des fournisseurs prennent désormais en charge la mise en cache des prompts :

• Anthropic : marqueurs explicites cache_control dans les messages.
• OpenAI : automatique pour les requêtes avec correspondance de préfixe.
• Google : contenu mis en cache explicitement via l’API.

Quand le même préfixe est réutilisé, la version mise en cache est plus rapide et moins chère (souvent 90 % moins chère).

Pour les agents qui effectuent de nombreux appels pendant une session, mettez en cache les parties statiques — prompt système, outils et contexte utilisateur — puis placez le contenu dynamique après ce préfixe.

C’est l’une des optimisations les plus rentables. Pour un préfixe statique de 10 000 tokens réutilisé lors de 50 appels, seul le premier est facturé au plein tarif ; les suivants bénéficient d’une réduction de 90 %.

Schéma 13 : prompts sensibles au contexte

Les prompts peuvent encourager le modèle à utiliser bien le contexte :

Reference the documents below to answer the user's question. Always cite the specific document and quote relevant passages.

If you cannot find the answer in the provided documents, say so explicitly. Do not invent information.

When information from multiple documents is relevant, synthesize them and note any disagreements.

Ce type de prompting réduit les hallucinations sur les tâches ancrées dans le contexte et améliore la qualité des citations.

Quand adopter un contexte plus long

Malgré la dégradation du contexte, un contexte plus long est effectivement meilleur pour certaines tâches :

Analyse d’un seul document. Si la tâche est « analyser ce contrat », mettre tout le contrat dans le contexte est souvent meilleur que la récupération par morceaux.

Comparaison entre de nombreux éléments. Comparer 10 contrats côte à côte bénéficie de tous les 10 dans le contexte.

Édition de code dans le contexte. Modifier une fonction dans un fichier de 5K lignes de code est plus facile avec le fichier dans le contexte que avec des extraits récupérés.

Résumé de conversation complète. Produire un résumé d’une longue conversation fonctionne mieux avec un contexte complet (jusqu’à un point).

Le modèle : quand la tâche nécessite fondamentalement de comprendre les relations entre les contenus, un contexte plus long aide. Quand la tâche peut être accomplie avec un petit morceau, un contexte plus petit est meilleur.

Une heuristique pratique : les contextes jusqu’à 50K tokens sont généralement acceptables. 50 à 200K tokens fonctionnent mais la qualité diminue. 200K+ tokens sous-performent souvent les contextes plus courts. Testez empiriquement.

Discipline d’évaluation

Comment savez-vous que votre ingénierie du contexte fonctionne ? Évaluez.

Évaluations spécifiques :

Tests de rappel. Insérez des faits clés à différentes positions dans des contextes longs. Testez si le modèle les utilise. Mesurez le rappel par rapport à la position.

Tests de distracteurs. Comparez les performances sur la même requête avec et sans contexte irrélevant. Mesurez la dégradation.

Comparaison long-contexte vs RAG. Mêmes requêtes répondues avec un contexte complet vs avec des morceaux récupérés. Comparez la qualité.

Efficacité en tokens. Qualité par dollar. À mesure que le contexte augmente, vous payez plus — la qualité augmente-t-elle en conséquence ?

Ces évaluations révèlent si vos choix de contexte sont effectivement utiles. Sans eux, vous devinez.

Exemple travaillé : assistant de recherche

Exemple concret : un assistant de recherche fondé sur l’IA pour une petite équipe.

Tâche : Répondre aux questions sur un corpus de 200 documents (articles, documents internes, notes de réunion).

Approche naïve : Intégrez tous les documents dans le contexte (300K tokens). La qualité est acceptable ; le coût est élevé ; la latence est mauvaise.

Approche ingénierie du contexte :

Context budget: 25K tokens

- System prompt: 1500 tokens (cached)
- Tool descriptions (search, fetch_doc, etc.): 800 tokens (cached)
- Conversation memory: 1500 tokens (last 10 turns)
- Retrieved chunks for current query: 18000 tokens (top 12 chunks via RAG)
- User's current question: 200 tokens
- Output budget: ~3000 tokens

L’agent récupère dynamiquement des morceaux en fonction de la question. La mémoire de conversation conserve le contexte récent. Les éléments statiques sont mis en cache.

Résultat :

• Latence : 2 à 3 secondes (vs 10 à 15 avec 300K contexte).
• Coût : ~0,01 €/requête (vs ~0,10 €).
• Qualité : meilleure, mesurée sur l’ensemble d’évaluation, car le contenu pertinent est correctement porté.

C’est ce que ressemble l’ingénierie du contexte disciplinée. Pas une décision unique mais un réglage continu.

Erreurs courantes

Quelques modèles :

Erreur 1 : « Plus de contexte = meilleur. » Recourir à un contexte plus long comme solution aux problèmes de qualité. Souvent, le contraire est vrai.

Erreur 2 : Aucun budget de contexte. Les composants croissent indéfiniment. La section du profil utilisateur devient 5K tokens ; la section des morceaux récupérés devient 50K. Aucune discipline.

Erreur 3 : Ignorer les positions. Instructions critiques enfouies au milieu, en espérant que le modèle les trouve. Parfois, c’est le cas ; souvent, ce n’est pas le cas.

Erreur 4 : Prose verbeuse pour les faits. Longues phrases où les données structurées suffiraient. Gaspillent les tokens.

Erreur 5 : Aucun résumé de conversation. Les conversations grandissent jusqu’à dépasser les limites. Puis, soit elles s’arrêtent, soit elles se cassent.

Erreur 6 : aucune mise en cache. Les préfixes statiques répétés sont facturés au plein tarif à chaque appel, ce qui gaspille inutilement de l’argent.

Erreur 7 : Aucune évaluation des choix de contexte. Faire confiance à « une meilleure ingénierie du contexte » qui fonctionne. Parfois, ce n’est pas le cas.

Erreur 8 : Résumé générique. Résumer sans penser à ce dont les tâches suivantes ont besoin. Perdre des informations pertinentes.

À retenir

Les fenêtres de contexte longues sont réelles, mais elles ne sont pas une licence d’ignorer l’ingénierie du contexte. La qualité se dégrade bien avant les limites techniques. Le coût et la latence sont réels.

La discipline de l’ingénierie du contexte :

• Traitez le contexte comme un budget.
• Hiérarchisez la mémoire (récents verbatim, plus anciens résumés, les plus anciens en tant que faits).
• Récupérez juste à temps, pas à l’avance.
• Compressez là où la compression préserve les informations.
• Placez le contenu critique aux positions à forte attention.
• Organisez le contexte en couches de priorité.
• Misez en cache les préfixes statiques.
• Évaluez continuellement.

Ces schémas produisent des systèmes plus performants, plus rapides et moins coûteux que l’approche naïve consistant à tout placer dans le contexte.

Pour les systèmes de production matures, l’ingénierie du contexte compte parmi les domaines les plus rentables. Les primitives techniques sont simples ; leur application rigoureuse distingue une démonstration fonctionnelle d’une production fiable.

Investissez dans ces schémas et instaurez cette discipline. Vous obtiendrez des systèmes d’IA capables de passer à l’échelle à mesure que les données, les conversations et la complexité augmentent.