Context Window (Fenêtre de Contexte)

Définition

La context window (ou fenêtre de contexte) désigne la quantité maximale de tokens qu'un grand modèle de langage (LLM) peut traiter simultanément au sein d'un même appel d'inférence. Elle englobe à la fois l'entrée (prompt système, historique de conversation, documents injectés, résultats d'outils) et la sortie générée. Concrètement, il s'agit de la mémoire de travail du modèle : tout ce qui n'y tient pas est purement invisible pour lui.

Les ordres de grandeur ont explosé en quelques années : de 4 096 tokens sur les premières générations à 128 000, 200 000, voire 1 000 000 à 2 000 000 de tokens sur les modèles récents. À titre de repère, un token correspond en moyenne à 0,75 mot en anglais et plutôt 0,5 à 0,6 mot en français : une fenêtre de 200K tokens absorbe donc environ 500 pages de texte.

Fonctionnement technique

La limite n'est pas arbitraire. Elle découle directement de l'architecture Transformer et du mécanisme d'attention, dont le coût de calcul et de mémoire croît de façon quadratique avec la longueur de séquence : doubler la fenêtre multiplie par quatre le travail nécessaire. Plusieurs briques techniques encadrent ce comportement :

• Tokenisation : le texte est découpé en sous-mots par un algorithme de type BPE. Le code, les logs bruts, les hashes ou les chaînes en Base64 se tokenisent très mal et consomment bien plus de fenêtre qu'un texte naturel équivalent.
• Encodage positionnel : des techniques comme RoPE (Rotary Position Embedding) ou ALiBi permettent au modèle de situer chaque token. Leur extrapolation au-delà de la longueur d'entraînement est la principale contrainte à l'allongement des fenêtres.
• KV cache : les clés et valeurs d'attention déjà calculées sont mises en cache en mémoire GPU. Ce cache grandit linéairement avec le contexte et devient souvent le vrai goulot d'étranglement en production.
• Troncature et fenêtre glissante : lorsque la limite est atteinte, l'orchestrateur élague — généralement les messages les plus anciens. Un prompt système mal positionné peut ainsi disparaître silencieusement.

Attention également au phénomène du « lost in the middle » : la performance de rappel n'est pas uniforme sur toute la fenêtre. Les informations placées au début et à la fin sont nettement mieux exploitées que celles enfouies au milieu d'un contexte très long. Une grande fenêtre disponible n'équivaut donc pas à une grande fenêtre effective.

Exemples concrets en cybersécurité

• Triage SOC : injecter 50 000 lignes de logs Sysmon ou d'événements EDR pour corréler une chaîne d'attaque. Le volume de logs dépasse quasi systématiquement la fenêtre — d'où le recours au pré-filtrage et à l'échantillonnage.
• Revue de code et SAST assisté : analyser un dépôt entier plutôt que fichier par fichier permet de détecter des vulnérabilités inter-fonctions (flux de données non assaini traversant plusieurs modules), impossibles à voir avec une fenêtre courte.
• Rédaction de rapports de pentest : conserver l'intégralité des preuves, sorties d'outils et notes de mission dans un seul contexte pour produire un livrable cohérent.
• Analyse de renseignement sur la menace : ingérer plusieurs rapports APT complets pour croiser TTPs et IoC.

Implications sécurité

La fenêtre de contexte constitue une surface d'attaque à part entière. Tout contenu qui y entre est traité par le modèle, sans distinction native entre instruction légitime et donnée non fiable :

• Prompt injection indirecte : un document, une page web ou un ticket contenant des instructions malveillantes est chargé dans le contexte et détourne le comportement de l'agent.
• Context overflow / dilution des garde-fous : noyer le prompt système sous un volume massif de texte pour affaiblir les consignes de sécurité, ou provoquer leur troncature.
• Fuite de données : un contexte partagé entre utilisateurs, ou un KV cache mal cloisonné, peut exposer des informations sensibles. Les données classifiées injectées dans un prompt transitent chez le fournisseur du modèle.
• Empoisonnement de la base RAG : compromettre les documents indexés revient à contrôler ce qui remplira la fenêtre.

Bonnes pratiques

• Délimiter explicitement les contenus non fiables (balises, séparateurs) et rappeler au modèle qu'ils sont des données, jamais des instructions.
• Placer les consignes critiques en début et en fin de contexte, jamais uniquement au milieu.
• Privilégier le RAG à la force brute : récupérer 5 000 tokens pertinents surpasse souvent l'injection de 500 000 tokens bruts, tout en réduisant coût et latence.
• Pré-traiter les logs : normaliser, dédupliquer, agréger avant l'injection. Un fichier JSON compacté consomme 2 à 3 fois moins de tokens que sa version indentée.
• Compter les tokens avant l'appel plutôt que de subir une troncature silencieuse, et journaliser tout dépassement.
• Appliquer le moindre privilège aux données : ne jamais placer dans le contexte des secrets, clés ou PII dont le modèle n'a pas strictement besoin.
• Utiliser le prompt caching pour les préfixes stables (politiques, référentiels) : gain de coût et de latence sans réduire la qualité.

Concepts liés

La fenêtre de contexte s'articule avec la tokenisation, le RAG (Retrieval-Augmented Generation), la prompt injection, le jailbreak, les hallucinations (souvent aggravées quand l'information nécessaire est hors contexte) et le fine-tuning, qui inscrit la connaissance dans les poids du modèle plutôt que dans sa mémoire de travail. Elle est explicitement visée par plusieurs entrées de l'OWASP Top 10 for LLM Applications, notamment LLM01 (Prompt Injection) et LLM02 (Sensitive Information Disclosure).