Qu'est-ce que la fenêtre de contexte d'un modèle d'IA
La fenêtre de contexte est la quantité de texte qu'un modèle de langage « voit » dans une seule requête : votre prompt, l'historique du chat, les documents chargés et la réponse du modèle. Qu'une base de code entière, un long contrat ou seulement un chat court tienne dans un appel API dépend de la taille de la fenêtre. Ci-dessous : définition, mesure en tokens et pourquoi c'est l'un des paramètres clés au choix d'un modèle.
Définition en termes simples
La fenêtre de contexte (context window) est le nombre maximum de tokens qu'un modèle peut traiter dans une requête. Un token n'est ni un mot ni un caractère : c'est un fragment de texte après tokenisation. En russe et en anglais, un token correspond environ à 3-4 caractères ou à une partie de mot ; « programmation » peut occuper 2-3 tokens.
Le modèle ne « se souvient » pas seul des sessions passées. Tout ce qu'il sait au moment de répondre, c'est ce que vous avez passé dans la requête courante dans la limite de la fenêtre. Si le dialogue ou le document dépasse la limite, les fragments anciens sont coupés ou doivent être compressés par des techniques séparées (RAG, résumé, découpage).
Comment la fenêtre fonctionne en pratique
Dans une requête API typique, le contexte comprend :
- System prompt - instructions au modèle (rôle, format de réponse, contraintes).
- Historique des messages - tours user et assistant précédents dans le chat.
- Pièces jointes - texte de PDF, code du dépôt, extraits de base de connaissances.
- Sortie du modèle - sur beaucoup de modèles, la réponse compte aussi dans la limite totale par appel.
Le schéma est simple : input + output ≤ taille de la fenêtre de contexte (certains modèles limitent input et output séparément, mais la logique est la même - plafond par appel).
Exemple pour une fenêtre 128K :
| Composant | Taille approximative |
|---|---|
| System prompt | 500-2 000 tokens |
| Historique (20 messages) | 5 000-15 000 |
| Document chargé | 80 000 |
| Réponse du modèle | jusqu'à 8 000-16 000 |
Si la somme dépasse la limite, l'API renvoie une erreur ou la plateforme rogne automatiquement le début de l'historique - selon le client.
Contexte d'entrée et de sortie
Les développeurs confondent souvent deux notions :
- Input context - combien de tokens le modèle accepte (prompt + historique + fichiers).
- Max output tokens - borne supérieure de longueur de réponse par appel (paramètre API séparé, ex.
max_tokens).
Un modèle avec fenêtre 1M peut accepter presque un million de tokens en entrée, mais la réponse reste souvent plafonnée à, par exemple, 8K-64K tokens par appel. Les longs rapports exigent parfois plusieurs requêtes séquentielles ou du streaming avec continuation.
Sur certains tarifs, les requêtes long-context (au-delà d'un seuil, ex. 200K d'input) coûtent plus cher - charge d'inférence plus lourde.
Pourquoi une grande fenêtre de contexte compte
Un grand contexte aide quand une requête doit tenir beaucoup d'information liée :
- Analyse de documents - contrats, rapports, recherches sur des dizaines de pages sans compression préalable.
- Travail sur le code - plusieurs fichiers du projet, stack trace et historique des modifications dans un prompt.
- Dialogues longs - support et conseil où toute la conversation compte, pas seulement les 10 derniers messages.
- Scénarios agentic - un agent accumule observations, appels d'outils et résultats intermédiaires dans une session.
Une petite fenêtre (4K-32K) suffit pour des tâches courtes : classification, extraction de champs de formulaire, traduction d'un paragraphe, chatbot simple. Les scénarios enterprise avec documents et code visent en général 128K et plus.
Tailles typiques en 2026
Mi-2026, le marché se divise en plusieurs niveaux :
| Niveau | Taille de fenêtre | Exemples de modèles | Tâches typiques |
|---|---|---|---|
| Compacts | 8K-32K | Modèles locaux légers, anciennes API | Chat, classification |
| Standard | 128K-200K | GPT-5.5, Claude Sonnet 5, Gemini 3.1 Pro | Code, documents, agents |
| Étendus | 1M-2M | GPT-5.6, Claude Fable 5, Gemini 3.5 Flash | Grands dépôts, corpus |
Le contexte grandit plus vite que la longueur « utile » : un modèle accepte techniquement un million de tokens, mais la qualité sur la queue la plus longue peut baisser (effet « lost in the middle » - le modèle utilise moins bien l'information du milieu des longs contextes). Une grande fenêtre ne remplace pas une architecture réfléchie, elle élargit les capacités.
Limites et contournements
Même avec une fenêtre 2M, tout ne va pas dans un seul prompt :
- Coût - l'input est facturé au token ; un million de tokens par requête alourdit vite la production.
- Latence - le long contexte prend plus de temps sur GPU.
- Qualité - mieux vaut fournir explicitement les faits pertinents que les « enterrer » au milieu de 500 pages.
Patterns utiles quand la fenêtre est juste ou pour économiser :
- RAG (Retrieval-Augmented Generation) - chercher les fragments pertinents en base vectorielle et n'injecter que ceux-ci dans le prompt.
- Résumé - compresser les anciens messages ou sections du document par un appel modèle séparé.
- Chunking - découper le texte en parties et agréger les résultats.
- Fenêtre glissante - seulement les N derniers messages plus un bref résumé du passé dans l'historique.
En production, on combine souvent : RAG pour les faits de la base de connaissances + historique modéré + modèle 128K-1M pour les requêtes « lourdes ».
Choisir la taille de fenêtre selon la tâche
| Tâche | Minimum recommandé | Commentaire |
|---|---|---|
| Bot FAQ, classification d'intention | 8K-16K | Historique court, documents via RAG |
| Copilot pour un dépôt | 128K-1M | Selon la taille du codebase |
| Revue legal / compliance | 200K+ | Longs PDF, renvois croisés |
| Documents multimodaux | 1M+ | Texte + images consomment plus de tokens |
Avant de choisir un modèle, estimez le volume réel d'input : comptez les tokens d'une requête typique (tiktoken, tokenizer API ou count_tokens du fournisseur) et prévoyez 20-30 % de marge pour la réponse et la croissance de l'historique.
Conclusion
La fenêtre de contexte est la « mémoire de travail » du modèle de langage pour une requête. Elle se mesure en tokens et inclut prompt, historique, pièces jointes et souvent de la place pour la réponse. Les grandes fenêtres (128K-2M) permettent d'analyser de longs documents et bases de code sans rogner constamment, mais ne remplacent pas RAG, résumé et maîtrise des coûts. Au choix du modèle, regardez non seulement le chiffre de la fiche technique, mais aussi la qualité en long contexte, les tarifs long-context et la taille réelle de vos requêtes typiques.
Questions fréquentes
En quoi un token diffère-t-il d'un mot ?
Un token est une unité de texte après tokenisation du modèle. Un mot peut être un ou plusieurs tokens ; ponctuation et espaces comptent aussi. En moyenne pour le russe et l'anglais, 1000 tokens ≈ 750-900 mots ou 3000-4000 caractères, mais cela dépend de la langue et du modèle. Pour estimer, utilisez le tokenizer du fournisseur concerné, pas le nombre de mots dans Word.
Que se passe-t-il si le texte dépasse la fenêtre de contexte ?
Selon la plateforme : l'API peut renvoyer « context length exceeded », rogner le début de l'historique (les messages les plus anciens partent en premier) ou proposer une compression. Le modèle ne « lit pas au-delà » de la fenêtre - l'information hors limite n'existe pas pour lui. Solutions : RAG, résumé, découpage ou modèle à plus grande fenêtre.
Plus de contexte signifie-t-il toujours de meilleures réponses ?
Non. Une grande fenêtre donne la possibilité de passer plus de données, sans garantir une utilisation égale. Sur des entrées très longues, la précision sur les faits du milieu baisse souvent, coût et latence montent. Mieux vaut passer un contexte pertinent (recherche ou prompt structuré) que tout le corpus « au cas où ».
Comment compter combien de tokens prendra mon document ?
Utilisez les outils officiels : tiktoken pour modèles compatibles OpenAI, Anthropic tokenizer, Google AI Studio pour Gemini ou count_tokens dans le SDK du fournisseur. Règle grossière : 1 page de texte (≈500 mots) - de l'ordre de 650-800 tokens ; code et tableaux peuvent produire plus de tokens par caractère à cause des symboles spéciaux.
Faut-il un modèle 1M tokens pour un chatbot ordinaire ?
Pour un chatbot typique avec réponses courtes et FAQ - non, 32K-128K plus RAG sur base de connaissances suffisent. Une fenêtre 1M+ se justifie pour l'analyse de gros PDF, dépôts entiers, longues sessions agentic ou quand on ne peut pas découper les données sans perdre la cohérence. Mesurez d'abord les tailles réelles de requête en production - souvent 128K suffit avec la bonne architecture.