[Aller au contenu principal](#main-content) # Context Window (Fenêtre de Contexte) ia ## 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 seul appel, englobant à la fois le prompt fourni en entrée, l'historique de conversation le cas échéant, et la réponse générée en sortie, définissant ainsi la limite structurelle de mémoire immédiate disponible pour une interaction donnée. Cette limite varie considérablement selon les modèles et leurs générations : des fenêtres historiques de quelques milliers de tokens équivalant à quelques pages de texte, jusqu'à des capacités récentes atteignant plusieurs centaines de milliers voire au-delà d'un million de tokens chez certains modèles de pointe, permettant de traiter en une seule requête l'équivalent d'ouvrages entiers ou de bases de code volumineuses. Techniquement, l'extension de la fenêtre de contexte pose un défi computationnel majeur car le mécanisme d'attention des architectures Transformer présente historiquement une complexité quadratique par rapport à la longueur de la séquence traitée, nécessitant des optimisations architecturales spécifiques pour rendre les grandes fenêtres exploitables en pratique à un coût raisonnable. Une fenêtre de contexte plus large ne garantit pas une exploitation optimale de l'ensemble de l'information fournie, un phénomène documenté sous le nom de « lost in the middle » où les modèles exploitent mieux les informations situées au début et à la fin du 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). ## **Articles liés Un projet cybersécurité ? Expert dispo · Réponse 24h Devis ** **