La fenêtre de contexte est la limite supérieure du nombre de tokens qu'un modèle peut « voir » d'un coup : le prompt, l'historique de la conversation, les documents récupérés et la réponse déjà générée par le modèle — le tout rangé dans l'ordre au sein d'une même séquence. Elle détermine la taille de l'établi du modèle, pas son intelligence. Une fenêtre d'1M de tokens peut contenir des milliers de pages de documents — mais cela ne signifie pas que le modèle saura vraiment exploiter chaque page.
Que contient réellement une fenêtre de contexte ?
La fenêtre ne contient pas des fichiers, mais des tokens. Le prompt, l'historique, les passages récupérés, les résultats d'outils sont découpés en tokens et entassés dans l'ordre dans une même séquence ; le modèle distingue l'avant et l'après uniquement grâce à l'encodage positionnel — la notion de « dossiers » lui est inconnue. 1M de tokens, c'est de l'ordre de 750 000 mots anglais, soit bien plus d'un millier de pages de documents. Mais attention : cela veut seulement dire « ça tient », pas « c'est retenu ».
La facture cachée du mécanisme d'attention
Le modèle lit cette séquence grâce à l'auto-attention : pour chaque nouveau token, il calcule sa pertinence par rapport à chacun des tokens précédents, un par un — le coût de calcul croît donc de façon quadratique avec la longueur de la séquence : longueur doublée, calcul d'attention quadruplé. La facture la plus lourde est le cache KV : les vecteurs clé et valeur de chaque token doivent rester résidents en mémoire GPU pendant l'inférence pour éviter tout recalcul. Prenons Llama-3.1-8B : environ 128 Ko de cache par token — soit près de 16 Go pour 128K de contexte, et environ 128 Go de VRAM pour 1M de tokens. « Doubler la fenêtre » n'est jamais gratuit : cela dévore la VRAM, retarde la première réponse et fait grimper le prix des appels API à long contexte.
Ça tient — alors pourquoi le modèle ne le trouve-t-il pas ?
Pouvoir payer la facture ne veut pas dire savoir bien l'utiliser. Les poids d'attention sont normalisés par softmax pour une somme toujours égale à 1 : plus il y a de tokens, plus l'attention accordée à chacun se dilue. L'expérience « Lost in the Middle » de Stanford (2023) l'a montré de façon saisissante : placez l'information clé au début ou à la fin du contexte, et le modèle la trouve vite et bien ; cachez-la au milieu, et la précision peut chuter de plus de 20 points — pire que sans contexte du tout. Le fossé le plus grand se cache dans notre façon de tester : le test de « l'aiguille dans la botte de foin » ne vérifie que la capacité à retrouver une phrase — presque tous les modèles y excellent. Mais le benchmark RULER de NVIDIA passe à des tâches réalistes comme le suivi multi-sauts ou l'agrégation, et seule la moitié des modèles annonçant 32K reste à un niveau acceptable à cette longueur. Entre la fenêtre nominale et la fenêtre effective, l'écart est souvent de plusieurs fois.
Trois idées reçues très répandues
Idée reçue n° 1 : plus la fenêtre est grande, plus le modèle retient. La fenêtre est un établi, pas un disque dur. L'agrandir n'ajoute rien aux « connaissances à long terme » contenues dans les paramètres du modèle — elle lui permet seulement d'étaler plus de matière à la fois. La conversation terminée, la fenêtre vidée, le modèle ne « retient » rien ; la mémoire d'une conversation à l'autre relève de mécanismes externes comme la génération augmentée par récupération.
Idée reçue n° 2 : le long contexte rend le RAG obsolète. Verser toute une base de connaissances dans la fenêtre coûte cher et va lentement : les tokens d'entrée sont facturés au volume, et la latence du premier token comme la consommation de VRAM coûtent de l'argent réel sur les contextes ultralongs. La pratique courante fait exactement l'inverse — d'abord filtrer avec la recherche sémantique pour ne garder que les passages les plus pertinents, puis les lire attentivement dans la fenêtre ; pour les questions dont la réponse doit être assemblée à travers plusieurs documents, il existe des approches structurées comme GraphRAG. Longue fenêtre et récupération sont des partenaires, pas des rivales.
Idée reçue n° 3 : le nombre de tokens égale la mémoire effective. Sur des tâches exigeant un véritable raisonnement, la longueur effective d'un modèle annoncé à 1M de tokens peut n'être qu'une fraction de ce chiffre — « tenir » et « bien utiliser » sont deux choses différentes. La prochaine fois que vous verrez ce nombre sur une fiche modèle, posez une question de plus : à la longueur dont ma tâche a besoin, combien de précision reste-t-il ?
Comment bien lire le chiffre de la taille de fenêtre
D'abord la tâche : lire quelques contrats ou analyser un dépôt de code — quelques dizaines de K à 128K suffisent généralement. Pour du Q&A sur tout un corpus, le goulot d'étranglement est le plus souvent la qualité de la récupération, pas le plafond de la fenêtre. Ensuite l'efficacité : consultez des benchmarks de long contexte comme RULER ou LongBench pour la performance réelle à la longueur visée, pas seulement le maximum annoncé. Enfin le coût : les tokens d'entrée en long contexte coûtent plus cher à l'unité, et le cache KV limite la concurrence — la fenêtre n'est pas meilleure parce qu'elle est plus grande ; la bonne est celle qui, à longueur suffisante, est la plus stable et la moins chère.
