Context window : ce que votre IA peut vraiment prendre en compte

La fenêtre de contexte (« context window » en anglais) désigne l’espace total, exprimé en tokens, dont dispose un grand modèle de langage (LLM) pour traiter une requête : les données qu’il lit et la réponse qu’il génère. Dans une fenêtre de 1M tokens, les instructions, les documents et la conversation doivent laisser de la place à la réponse, ainsi qu’au raisonnement lorsque le modèle en produit. Faire entrer tous ces éléments dans la fenêtre ne garantit pas que le modèle exploitera correctement chaque détail.

Context window : de quoi parle-t-on en IA ?

Imaginez un établi : documents, consignes et travaux en cours en occupent la surface. Un établi plus grand permet d’étaler davantage de matériel, mais il faut encore garder de la place pour travailler. Et avoir tous les documents sous les yeux ne garantit pas de repérer la clause qui compte.

Un token est une unité traitée par le modèle, souvent un fragment de mot plutôt qu’un mot entier. Le texte, le code et les autres données d’entrée sont convertis en tokens selon les règles propres au modèle. Comptez les tokens de la requête réelle au lieu d’estimer sa taille à partir du nombre de pages ou du poids des fichiers. Le guide de Google sur les tokens explique cette distinction.

L’entrée peut contenir des éléments que vous n’avez jamais saisis dans la conversation :

• Les instructions système qui définissent le comportement de l’assistant.
• Votre message actuel et l’historique de conversation conservé.
• Les définitions des outils, qui décrivent les actions accessibles au modèle.
• Les résultats des outils, les passages récupérés, les images et les documents.

Anthropic inclut explicitement ces éléments dans son calcul du contexte. Une question très courte peut donc faire partie d’une requête très volumineuse.

Fenêtre de contexte et limite de tokens : quelle différence ?

La fenêtre de contexte borne la requête dans son ensemble ; la limite de sortie plafonne la partie générée. Les modèles de raisonnement peuvent consacrer une partie de ce budget de génération à leur réflexion avant de produire la réponse visible. OpenAI précise que l’entrée, la sortie et le raisonnement consomment la même fenêtre.

Pour une fenêtre partagée, la règle de calcul est la suivante :

Les tokens d’entrée et les tokens réservés à la génération doivent, ensemble, tenir dans la fenêtre de contexte.

Incluez le raisonnement dans cette réserve lorsque le modèle le décompte ainsi. Respectez également le plafond de sortie propre au modèle. Augmenter la limite de sortie ne crée pas d’espace supplémentaire.

Que détermine la fenêtre de contexte d’un outil d’IA ?

Elle détermine la quantité d’informations que le modèle peut examiner ensemble pour une requête donnée. Elle ne dit rien de la précision avec laquelle il les exploitera, des données que l’application conserve entre les sessions, ni de celles qu’elle lui renverra à la prochaine requête.

Pour une équipe de support, la différence est concrète : un ticket peut rester enregistré dans l’outil de gestion sans figurer dans l’entrée actuelle de l’assistant. Côté développement, enregistrer une conversation et assembler la prochaine requête envoyée au modèle sont deux responsabilités distinctes.

Quelle taille de fenêtre contextuelle pour Claude, GPT-6 et Gemini 4 ?

Les principaux modèles accessibles par API ci-dessous proposent des fenêtres d’environ un million de tokens. Mais leurs règles de sortie comptent autant que cette capacité affichée. Données vérifiées sur les pages officielles des modèles le 16 octobre 2026. Chaque ligne renvoie directement à son fournisseur : il s’agit des spécifications de l’API, pas d’un engagement sur les limites d’un abonnement de chat grand public ou d’une application.

La page actuelle des modèles Claude indique la même fenêtre et le même plafond de sortie pour tous les modèles présentés. La taille de la fenêtre aide donc peu à les départager : mieux vaut comparer leurs réponses sur votre tâche.

GPT-6 Astra, GPT-6.1 Sol et GPT-6 Luna partagent eux aussi la capacité indiquée. À fenêtre égale, les modèles peuvent se comporter différemment en extraction, en planification ou en programmation. La fiche technique indique ce qui tient dans la requête ; elle ne classe pas la qualité des modèles.

Le décodage long de Gemini 4 Argon utilise sa fenêtre partagée. Selon Google, l’API plafonne la sortie demandée à l’espace disponible après l’entrée ; le raisonnement consomme lui aussi ce budget. On ne peut pas ajouter un gros volume de sortie à une fenêtre déjà remplie par l’entrée. Le guide de calcul des tokens de Gemini donne la règle précise.

Exemple chiffré : le prompt tient, mais pas la réponse

Un prompt d’un million de tokens laisse moins de place à la réponse que ne le suggère le plafond de sortie du modèle.

Prenons les limites documentées de GPT-6 Astra. Supposons que la requête assemblée contienne 1,000,000 tokens d’entrée, instructions, outils, historique et documents sources compris. Il s’agit d’un budget donné à titre d’exemple, pas d’une charge de travail mesurée. Vous souhaitez réserver la totalité des 128,000 tokens générés autorisés par le modèle.

Voici le calcul :

• Fenêtre : 1,050,000 tokens.
• Espace restant après l’entrée : 1,050,000 − 1,000,000 = 50,000 tokens.
• Total prévu pour l’entrée et la sortie : 1,000,000 + 128,000 = 1,128,000 tokens.
• Espace manquant : 78,000 tokens.

L’entrée tient. Le budget prévu pour la réponse, lui, dépasse la limite. L’espace restant doit accueillir à la fois le raisonnement et la réponse visible.

Pour réserver la totalité de cette capacité de sortie, l’entrée doit être limitée à 922,000 tokens, soit 1,050,000 − 128,000, avant toute marge supplémentaire nécessaire à votre workflow. Vous n’avez pas à réserver le maximum pour chaque tâche : adaptez la réserve à la sortie attendue.

Pourquoi une grande fenêtre ne garantit-elle pas de retrouver tous les détails ?

Une requête peut tenir dans la fenêtre et produire malgré tout une réponse qui ignore des éléments présents dans le contexte. C’est un défaut de qualité, même si l’API accepte le prompt.

Dans ses recommandations sur l’ingénierie du contexte, Anthropic décrit une baisse de la capacité à retrouver l’information à mesure que le contexte s’allonge. Le problème ne prend pas forcément la forme d’un refus manifeste. Un assistant peut oublier une exception, confondre une ancienne règle avec celle qui la remplace ou s’appuyer sur un passage voisin qui semble pertinent.

L’étude Lost in the Middle, de Nelson F. Liu et ses collègues, a montré que les performances en réponse à des questions sur des documents et en recherche de paires clé-valeur dépendaient de la position des informations pertinentes. Les éléments placés au milieu pouvaient être plus difficiles à exploiter que ceux situés près des extrémités. Il s’agit d’une étude antérieure, pas d’un benchmark des modèles actuels du tableau.

La qualité sur les longs contextes se mesure sur vos propres tâches. Il n’existe pas ici de seuil universel de tokens au-delà duquel tous les modèles deviendraient soudain peu fiables.

Pour un assistant de support, constituez un petit jeu d’évaluation autour d’exceptions aux règles dont vous connaissez déjà les bonnes réponses. Comparez une requête ciblée, contenant la règle applicable, à une requête plus longue qui inclut aussi des règles sans rapport. Placez le passage décisif au début, au milieu, puis vers la fin. Vérifiez que la réponse applique la bonne exception et cite la bonne source.

Pour un assistant de programmation, posez une question qui nécessite de consulter un fichier d’implémentation et le code qui l’appelle. N’ajoutez des fichiers sans rapport qu’après avoir établi la réponse avec le contexte ciblé. Si la version longue donne de moins bons résultats, acheter davantage de capacité n’explique pas l’erreur.

Retrouver une phrase distinctive apporte une indication utile sur la capacité de recherche. Cela ne prouve pas que le modèle sait concilier des documents contradictoires ou respecter chaque contrainte tout au long d’une tâche.

Que faire quand le contexte est trop long ?

Côté développement, inspectez la requête assemblée. Côté utilisation, conservez l’état de la tâche en cours avant de poursuivre la session. Dans les deux cas, il faut distinguer une entrée refusée d’une réponse interrompue faute de place.

Pour les modèles Claude actuels, Anthropic documente une erreur de prompt trop long lorsque l’entrée seule dépasse la fenêtre. Si l’entrée tient mais que la génération atteint la limite, la réponse peut s’arrêter avec le motif model_context_window_exceeded. Vérifiez l’erreur ou le motif d’arrêt réel au lieu de supposer que le système a discrètement supprimé d’anciens messages. Voir le comportement de Claude en cas de dépassement.

1. 1

   Comptez ce que l’application envoie réellement

   Examinez ensemble les instructions, les messages de la conversation, les définitions d’outils, les passages récupérés et les résultats d’outils. Utilisez le service de comptage des tokens du fournisseur lorsqu’il prend en charge le format de votre requête, puis comparez son estimation à l’usage indiqué dans la réponse. Le point d’accès de comptage d’Anthropic accepte des messages structurés et de nombreux types d’entrées, mais impose des restrictions pour les outils côté serveur et certaines sources de fichiers.

2. 2

   Réservez l’espace nécessaire à la génération

   Notez la taille de la fenêtre du modèle, son plafond de sortie et la réserve dont vous avez besoin pour la réponse. Incluez le raisonnement lorsqu’il entre dans ce calcul. Réduisez d’autant le budget d’entrée ; chaque token restant n’est pas forcément une place disponible pour un document de plus.

3. 3

   Repérez ce qui continue à grossir

   Cherchez les résultats de recherche répétés, les journaux complets, les documents en double et les pistes abandonnées dans la conversation. Un agent de programmation peut avoir besoin du test qui échoue et de la fonction concernée ; il a rarement besoin, à chaque tour, de la sortie intégrale de toutes les commandes précédentes qui ont réussi. Conservez les éléments nécessaires pour vérifier la prochaine action.

4. 4

   Préparez une note de reprise

   Avant de redémarrer ou de compacter la conversation, conservez l’objectif, les décisions confirmées, les questions non résolues, l’emplacement des sources utiles et la prochaine action. Pour une personne qui traite un dossier client, gardez la demande en cours et l’exception applicable. Revenez à la source originale dès que la formulation exacte compte.

5. 5

   Vérifiez la justesse de la réponse après la modification

   Relancez la tâche qui échouait avec la requête réduite. Confirmez que les éléments nécessaires sont présents et que la réponse est correcte. Si le prompt tient désormais mais que le modèle manque toujours le détail décisif, examinez la sélection des informations et la capacité du modèle à les retrouver, au lieu de continuer à couper à l’aveugle.

Si un workflow court et stable fournit déjà des réponses correctes sans dépasser ses limites, conservez le modèle choisi. Une fenêtre annoncée plus grande ne justifie pas, à elle seule, une migration.

Recherche, résumé, compaction ou cache : quelle solution choisir ?

Choisissez la méthode en fonction de ce qui occupe l’espace. Ces techniques répondent à des problèmes différents et peuvent se compléter.

Utilisez la recherche documentaire lorsque le corpus dépasse largement les besoins de la question. La génération augmentée par récupération (RAG) fournit au modèle une sélection de sources avant qu’il réponde. Un assistant de support devrait récupérer la politique de retour applicable et le détail de la commande au lieu de lire toute la base de connaissances. Le guide du RAG agentique explique comment un agent peut relancer une recherche lorsque les premiers éléments ne suffisent pas.

La limite tient à la sélection : si la recherche manque l’exception décisive, le modèle ne peut pas l’utiliser. Gardez un ensemble limité de documents complets dans le contexte lorsque la tâche exige de comparer leurs détails tout au long du travail, et vérifiez qu’une sélection plus restreinte ne fait pas disparaître des éléments nécessaires.

Utilisez un résumé lorsque les anciens détails peuvent être remplacés par un état de la tâche à conserver. Un résumé doit préserver les décisions prises, les incertitudes restantes et l’emplacement des sources qui les étayent. Pour une modification de code, il peut s’agir de l’approche retenue, du dysfonctionnement actuel et des chemins des fichiers concernés. Ne remplacez pas une clause contractuelle précise ou un message d’erreur par une reformulation approximative lorsque la prochaine décision dépend de ses termes exacts.

Utilisez la compaction lorsque la conversation elle-même occupe l’essentiel de l’espace. La compaction remplace l’historique accumulé par un contexte de reprise plus court. Anthropic avertit qu’une compression trop agressive peut faire perdre des détails importants : vérifiez ce qui subsiste, sans considérer la conversation compactée comme une archive sans perte. Les explications d’Anthropic sur la compaction détaillent ce compromis.

Le guide de l’ingénierie du contexte explique plus largement comment sélectionner et maintenir ces contenus au fil du travail d’un agent.

Utilisez la mise en cache des prompts lorsque des entrées utiles se répètent. Elle réutilise le traitement d’un préfixe de prompt identique, c’est-à-dire le début inchangé de la requête. Placez les instructions stables et les éléments communs avant les contenus variables, et respectez les règles de cache du modèle. Le guide actuel d’OpenAI décrit notamment le fonctionnement des points de délimitation explicites du cache, tandis que la page de Gemini 4 Argon n’indique qu’une mise en cache implicite. Voir la mise en cache chez OpenAI et la prise en charge du cache par Gemini.

Les longs prompts ajoutent des tokens d’entrée facturables. Les accès réussis au cache peuvent réduire la facture des entrées répétées, sous réserve des règles d’écriture du cache, mais ces tokens occupent toujours la fenêtre. Les mécanismes du cache font l’objet d’un article distinct.

Compacter ou réécrire le début d’un prompt peut réduire la réutilisation du cache. Conservez un préfixe stable tant qu’il reste utile ; supprimez l’historique sans rapport lorsqu’il nuit à la requête. Un taux élevé d’accès réussis au cache ne garantit pas une bonne réponse.

Quelles promesses exagérées autour des longs contextes ?

On fait souvent dire au chiffre de capacité ce qu’il ne mesure pas. Il ne prouve ni une restitution parfaite des informations, ni une mémoire permanente, ni la possibilité de remplacer tous les workflows de recherche documentaire par un prompt plus long.

Une fenêtre plus grande a un intérêt concret lorsque votre tâche exige davantage d’éléments pertinents en même temps, que la requête réduite fait perdre des liens essentiels et que la version plus longue produit des résultats corrects dans votre évaluation. Voilà une raison d’utiliser cette capacité.

Intervenez lorsque les journaux, l’historique ou les corpus sources prennent la place de la réponse. Commencez par mieux choisir ce qui entre dans la requête. Envisagez une fenêtre plus grande si les informations pertinentes ne tiennent toujours pas. Attendez si votre workflow actuel est fiable et que seule une capacité supérieure sur la fiche technique vous attire.

Questions fréquentes sur la fenêtre de contexte

Qu’est-ce que la fenêtre de contexte d’un modèle de langage ?

C’est la capacité du modèle, en tokens par requête, pour l’entrée qu’il examine et la sortie qu’il génère. Pour les modèles de raisonnement, comptabilisez aussi la réflexion selon les règles du fournisseur.

À quoi correspond une fenêtre de contexte de 200K ?

200K signifie 200,000 tokens. Cela ne correspond pas à un nombre fixe de mots ou de pages, et une fenêtre partagée doit aussi accueillir la sortie générée. Comptez vos contenus avec le tokenizer du modèle choisi ou son point d’accès de comptage, s’il prend en charge votre requête.

Que signifie le contexte en programmation ?

Le contexte désigne les informations environnantes auxquelles une opération a accès. Dans une application utilisant un LLM, il correspond aux instructions, aux messages et aux éléments de référence assemblés pour la requête actuelle envoyée au modèle.

Quel est un exemple concret d’ingénierie du contexte ?

Un assistant de support reçoit le ticket en cours, la règle applicable et un bref relevé des décisions antérieures. Il récupère des éléments complémentaires au besoin, au lieu de recevoir l’archive complète des tickets.

Quel est le salaire d’un ingénieur du contexte ?

Une spécification de fenêtre de contexte ne permet pas d’établir un salaire. Pour recruter, précisez si le poste porte sur la recherche d’informations, l’ingénierie applicative, les évaluations ou l’infrastructure, puis comparez les postes de même périmètre dans votre région.

Comment apprendre l’ingénierie du contexte ?

Examinez les requêtes complètes d’une petite application. Modifiez séparément les instructions, les éléments récupérés ou l’historique conservé, puis comparez les réponses à des résultats dont vous connaissez la justesse. Apprenez à expliquer pourquoi un changement a amélioré la réponse, au-delà du simple raccourcissement du prompt.

Quelle différence entre ingénierie du contexte et prompt engineering ?

Le prompt engineering se concentre sur les instructions et les exemples fournis au modèle. L’ingénierie du contexte couvre aussi la sélection des éléments utiles, la mise à disposition d’outils et la conservation du bon état de travail au fil de la tâche.

Quelles sont les bonnes pratiques en ingénierie du contexte ?

Calculez le budget de la requête complète, réservez de la place pour la sortie, conservez les éléments pertinents et gardez des références aux sources dans vos résumés. Vérifiez que la réponse reste correcte après une réduction du contexte ou une compaction.

Quelles compétences donner aux agents pour bien gérer le contexte ?

Donnez à l’agent des moyens ciblés pour trouver des sources, examiner les passages utiles et préserver l’état de la tâche. Évaluez ces outils selon la capacité de leurs résultats à éclairer la prochaine décision sans noyer la requête sous des éléments superflus.

À mettre en pratique dès lundi

Prenez une requête qui a échoué ou dont la réponse a manqué un détail important. Comptez l’ensemble de l’entrée, réservez de la place pour la sortie attendue et repérez le plus gros bloc qui n’aide pas à répondre à la question. Remplacez-le par des éléments sélectionnés ou une note de reprise, puis relancez la tâche en comparant le résultat à une réponse connue. Ne conservez la requête réduite que si elle préserve les éléments nécessaires et le résultat.

Pour recevoir des guides pratiques sur la création de workflows d’IA fiables, abonnez-vous à la newsletter.